大多數大型組織都實現了一個或多個大數據應用程序。隨著他們積累越來越多的金融交易、銷售數據和客戶交互，他們就可以生成更加準確的銷售預報和預測客戶需求趨勢。這將轉換為更大的市場份額和更高的收益。
然而，隨著積累的數據越來越多，內部用戶和分析師會執行更多的報表和預報。這些都會導致額外的查詢、分析及報表。這個循環還在繼續：數據增長帶來更好的分析，而分析又會產生更多的報表。最終，大數據應用程序會充滿大量的數據，從而影響查詢性能。
如何避免這個問題呢?
大數據信息獲取與存儲
信息技術(IT)支持人員可以從幾個方面去主動解決大數據應用程序的性能問題。第一個是數據獲取與存儲，有時候也稱為提取、轉換與加載(ETL)。
大數據應用程序會將它們的數據存儲在一個大型數據庫或者一個特殊的混合硬件/軟件設備中。有時候也會混合使用這兩種方法。大型數據庫可能是關系數據庫(如IBM DB2)或數據庫機器(Teradata)。設備是一種整合大規模并行I/O通道和超大磁盤陣列的新數據存儲手段。在很多時候，它們還需要與一個現有數據倉庫協同工作，因為可能組織中大量現有分析數據都已經存儲在這個數據倉庫中。
數據的最后一個方面是幫助我們確定需要對運營數據執行多少預處理。這有時候稱為數據整理。常見的例子包括處理缺失或無效的數據，將代碼替換為描述性分類數據，以及為具有唯一自然鍵的實體分配代理鍵。
數據從運營系統和外部數據源到達應用程序。IT必須保證來自運營系統的數據元素的正確性，其格式要適合批量加載。數據通道既要有足夠快的數據傳輸速度，也要有足夠大的帶寬去支持多數據流的交行傳輸。大數據應用程序的日常增長每天都會增加GB數量級的數據。一定要保證這些數據能夠快速高效地傳輸。
大多數據數據庫管理系統(DBMS)和設備都有一些用于加載數據的專有工具。這些工具有時候要求輸入數據使用一種固定的格式。要檢查這些需求及其他選項，確定是否有一些方法可以保證數據加載速度滿足要求。對于關系數據庫，有一種常用方法是合適分區表。例如，在表中定義用4個分區來存儲一天的數據。這樣IT人員就可以設計一個加載流程來并發加載4個分區。
最后一領域是數據存檔和凈化。雖然表面上數據量越多就自然可以推出分析更好，但是一些歷史數據可能變老或失效。例如，一些已停止銷售產品的銷售數據，公司停止服務地區的客戶數據等。這些數據應該凈化或存檔。凈化可以減少所需要的數據存儲量，而存檔則允許在將來需要數據時重新加載數據。無論是哪一種情況，減小工作數據庫的大叔都可以加快查詢速度，因為它不再需要過時的數據。
大數據用戶
誰是你的用戶，他們如何查詢你的數據?典型的用戶是一位業務分析師和主題專家，他們理解你的業務數據，具有高明又高效地訪問大數據應用程序的技術知識。這可能意味著他們精通SQL等查詢語言。另一個方法是安裝分析軟件，展示圖形化業務數據視圖，并且基于用戶界面來構建查詢。
在許多組織中，他們安裝的第一個大數據應用程序就是為了解決一些特殊問題，或者為了分析預定問題，即用例。分析師已經知道哪一些查詢可以產生有用且可操作的智能。
接下來，第一次分析的結果是產生“如果……將會怎么樣(what if)”的問題，這會導致需要訪問更多數據的更多查詢。隨著這些查詢提供數量更多的有用結果，管理層自然會開始將它們調整為常規報表。
IT支持人員必須規劃查詢在數量與復雜度方面的增長需求。這比規劃未來數據存儲容量增長要復雜得多。復雜查詢要求數據庫管理系統選擇一條高效的數據訪問路徑。這可能要求增加給數據庫一些提升性能的特性，如索引或數據分區。有可能多個查詢使用同一個數據集合，如按區域劃分的銷售數據或按月份及客戶類型劃分的客戶數據。在這些情況下，就有可能預先計算好這些數據集合，將它們單獨存儲在不同的位置，從而大大提升查詢性能。
另一個關注的問題是系統資源。可能有一些資源是有限的或受性能約束，如CPU或磁盤存儲。這一類資源的可用性將決定大多數可見的性能指標和查詢耗時。
IT人員應該監控資源消耗和收集常規性能測量數據。將這些指標制成分時圖表就可能反映出一些趨勢。在一些時候，使用一種資源就有可能減輕另一種資源的結束。例如，如果CPU資源緊張，導致查詢速度變慢，那么就可以給數據表增加索引。這樣會占用更多的磁盤存儲空間，但是可以加快數據訪問速度。其他可用的方法包括增加專用于排序處理的磁盤存儲，給DBMS增加內存，以便有更多的內存用于緩沖數據。
大數據查詢
這自然就到了使用查詢優化方法的時候。大多數DBMS都有一個分析查詢訪問路徑的特性，它稱為解釋。解釋的輸入是一個查詢，它會分析多個可能的數據訪問路徑，然后每一個路徑指定成本，然后執行具有最低成本的訪問路徑。在這里，成本是指數據查詢時所需要的CPU使用率和磁盤I/O。
這種查詢路徑優化要求DBMS提供一個關于數據庫或設備所存儲數據的統計模板。這種統計信息包括每一個數據元素的最大值和最小值、平均值、最常見值及其他數據分布信息。
假設有一個表包含按日期劃分的銷售數據，其中交易日期從01-01-2014到12-31-2014。只查詢01-01-2014的數據查詢可能只需要訪問數據表中很小的一部分;因此，這時很可能需要增加一個索引訪問路徑。
類似地，在上面這個表中，假設將數據分割為12個數據集或分區，其中每一個分區對應一個月份。那么查詢一月份數據的查詢可能只需要訪問其中一個分區，從而篩選數據時不需要掃描整個數據表。
顯然，分析的需求會對所生成查詢的類型產生重大影響;同時，可用的存儲方法和數據訪問路徑將會影響查詢性能。最明顯的結論是IT支持人員必須與分析人員緊密協作，定期開會一起審查報表需求和文檔可行的數據訪問策略。此外，IT人員還應該開發一種捕捉所有已提交查詢的方法，這樣通過對它們分析就可能得到通用模式。
小結
為了避免大數據應用程序潛在的性能問題，IT人員應該主動與分析人員協調，收集數據訪問指標。在技術方面，要用文檔記錄數據提取、轉換和加載流程，確定有一些方法可以提升數據查詢速度或處理更大的數據容量。要考慮凈化過時數據，并且確定是否有一些提升數據性能的通用手段，如分區或索引會很有效。
開發一個用戶庫概要。用戶數量有多少，他們創建查詢的技術水平有多高，以及他們提交查詢的頻率有多快?這些數據在將來是否會繼續增長?
捕捉用戶查詢，執行解釋流程，然后保存訪問路徑。要用這些數據去分析性能問題和趨勢。
要監控用于支持大數據應用程序的系統資源。預報趨勢，特別是那些已經或可能會成為約束的資源。在這些情況下，要使用現有資源開發一些方法，抵消其中一些約束。
最后，要定期與業務分析人員會面，討論你得到的結果和將來可能的變化。這種交流和協調是與用戶保持良好關系的重要條件。
京公網安備 11010502049343號