效能驗證：驗證某系統在一定條件具有什麼樣的能力。
效能規劃：如何使系統達到我們要求的效能能力。
應用程式診斷：比如資源分配不合理，記憶體溢位和記憶體洩漏等問題，通過功能測試很難發現，但通過效能測試卻很容易發現。
效能調優：滿足使用者需求，進一步進行系統分析找出瓶頸，優化瓶頸，提高系統整體效能。
在進行效能測試的工作時，如果麼有乙個明確的目標，很容易在壓測過程中進行很多無用功，或者起不到很好的壓測的作用。
明確的效能需求能夠幫助我們進行有目的性的壓測場景設計，例如是需要驗證工程所能達到的最大效能指標，還是尋找工程資源配置的最優配比等，這些都需要在測試方案中體現出來，對後續的效能壓測工作將起到指導性的作用。
在方案設計的過程中經常通過引導式研討會和頭腦風暴方式進行壓測場景的設計收集。
確定壓測物件工程，清楚該工程中存在多少輸入輸出流，各實時流之間的邏輯關係，是否存在去重邏輯，資料輸出的過濾條件，以及該工程涉及到的hbase、mysql等維表，包括維表裡面的資料是否滿足壓測要求。
在壓測工作開始之前還需要提前準備好壓測資料，根據每個工程預期能力的不同，需要準備的資料量也不同。一般情況下需要準備2000w以上的資料量， 另外還需要考慮對於壓測資料有特殊要求的場景，可能需要利用指令碼構造壓測資料。
附：常見的幾種效能壓測型別
效能測試:系統在正常負載的情況的各項效能指標,即通過調整,找到合適的負載,使系統的資源的利用率處於中等的情況下,採集系統的各項指標
負載測試:系統在不同的負載的情況的效能表現,可以得到系統在不同負載下的效能變 化趨勢，尋求效能的拐點。例如其他條件相同，分別測試系統在20,50,100 併發使用者下的各項效能 指標，找到其變化的規律，找到系統的能達到的最大 tps，統計對應的響應時間和資源消耗。
壓力測試:系統在高負載的情況下的效能表現，尋找系統能夠承受的最大負載以及對應的系統吞吐率
基準測試：針對確定的測試系統，**版本執行的測試，採集效能指標，作為後期的版本對比
穩定性測試:以正常負載或者稍高於正常負載施加於系統，進行長時間的測試，檢測統能夠穩定的執行，以及系統的各項效能指標會不會隨著時間發生變化。
擴充套件性測試: 通常用於新系統，新環境的搭建，通過先測試單台伺服器的處理能力,然後逐漸增加伺服器數量，測試集群環境下的單台伺服器的處理能力是否有損耗。
一般指的是cpu、記憶體、網路i/o等方面的問題。
分為伺服器硬體瓶頸、網路瓶頸、中介軟體瓶頸（kafka平台的資源限制）
線性分析法
對於此類效能問題的驗證，我們一般是採用的通過有控制性的改變整體資源配置的方法來進行場景設計，這種場景設計的思想是最基礎的。
由於一般測試環境的資源配置很難達到真實生產環境那麼大的規模，因此需要通過將資源進行線性比例調整的方式來進行壓測，根據結果的對比和線性分析，從而估算出真實環境下的壓測情況。
舉例：對於dfp_eagle_spes日誌（storm程式）的消費能力，通過對伺服器，worker和excutor配置的線性增加，來觀察消費能力的變化趨勢。
一般指的是應用到一些軟體，如hbase、mysql，redis等軟體效能的限制。
單一變數控制法
對於程式涉及到的一些應用軟體，有可能因為本身的吞吐能力問題，而導致整體效能不理想。如hbase的讀寫能力和mysql中資料的讀寫等。
我們需要通過針對該效能點設計單一變數的形式，來驗證是否存在效能瓶頸。
舉例：對於某自定義路徑樹這個工程，存在著其中乙個將輸入資料中路徑樹所有節點遍歷查詢mysql進行匹配的邏輯，為了驗證匹配命中程度對整體效能的影響，我們設計了以下幾個場景：
1.資源配比為18c36g，mysql中資料量為50條，與生產者中的資料全匹配且滿足起始頁面的匹配規則
2.資源配比為18c36g，mysql中資料量為50條，與生產者中的資料全匹配且滿足結束頁面的匹配規則
3.資源配比為18c36g，mysql中資料量為50條，與生產者中的資料全匹配且滿足起始頁面和結束頁面的匹配規則
4.資源配比為18c36g，mysql中資料量為50條，與生產者中的資料完全未匹配
5.資源配比為18c36g，mysql中資料量為50條，使用真實生產資料（隨機匹配）
開發人員開發出來的程式本身，也可能是造成效能的主要瓶頸之一。
例如，程式本身設計有問題，程式中序列、並行的程序執行緒配置比例不合理，程式**實現方式冗餘等。
深入**層面的假設分析法
如果以上外部因素所造成的影響都已排除，那麼就需要從程式本身進行分析了。
首先需要清楚的了解程式內部的**處理邏輯，了解一條資料從開始進入程式處理過程，到輸出的整個流程，對**單元中每個關鍵的處理節點進行假設分析，假設是這個節點的問題，那麼我通過改變其程序的方式進行驗證。
舉例：對於某flink程式，其內部處理節點主要有souce、flatmap和sink三個節點組成，其中source為拉取資料節點，map為中間計算節點，sink為輸出節點。那麼可對其進行如下場景設計來進行驗證。
第一步：確定問題
硬體或平台限制：cpu利用率、記憶體大小，kafka平台資源限制等都是容易引起瓶頸的原因，因此這些都是分析的重點。
資料庫配置：有時候程式中會存在大量的關聯邏輯，例如與hbase ，mysql等進行關聯，在壓測過程中都是需要對其吞吐能力進行實時監控的。（比較常見）
應用程式**：在通常情況下，很多程式的效能問題都是寫出來的，因此對於發現瓶頸的模組，如果以上問題經過核實都不是主要原因，那麼應該從**本身進行分析。（比較常見）
網路：網路負載過重導致網路衝突和網路延遲。
第二步：確定調整目標和解決方案
第三步：驗證調整之後結果是否達到預期目標
資料倉儲準備階段分析
初始階段 1 需求分析 目標 收集業務需求與資料實現 實現過程 了解關鍵指標 競爭性商業問題 決策指定過程 支援分析需求 物件 通過與業務代表了解業務需求，以及與源系統專家交流 2 維度建模的四步法 1 選擇業務流程 2 宣告粒度 3 確定維度表 4 確定事實表 3 選擇模型 星型模式與olap多維...
資料倉儲 資料倉儲部署
1 首先用下面的語句查詢是否有要建立的表空間 hospdw tab 和 hospdw idx 如果沒有，則把d database zyhip改為對應的路徑，有的話直接建立使用者 select tablespace name,file name,round bytes 1024 1024 0 size...
資料倉儲,什麼是資料倉儲？
資料倉儲，英文名稱為data warehouse，可簡寫為dw或dwh。資料倉儲是為企業所有級別的決策制定過程提供支援的所有型別資料的戰略集合。它是單個資料儲存，出於分析性報告和決策支援的目的而建立。為企業提供需要業務智慧型來指導業務流程改進和監視時間 成本 質量和控制。資料倉儲是決策支援系統 ds...