關於海量數據處理分析的經驗總結

     對海量的數據進行處理是一項艱鉅而複雜的任務。緣由有如下幾個方面：

        1、數據量過大，數據中什麼狀況均可能存在。若是說有10條數據，那麼大不了每條去逐一檢查，人爲處理，若是有上百條數據，也能夠考慮，若是數據上到千萬級別，甚至過億，那不是手工能解決的了，必須經過工具或者程序進行處理，尤爲海量的數據中，什麼狀況均可能存在，例如，數據中某處格式出了問題，尤爲在程序處理時，前面還能正常處理，忽然到了某個地方問題出現了，程序終止了。
        2、軟硬件要求高，系統資源佔用率高。對海量的數據進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。通常狀況，若是處理的數據過TB級，小型機是要考慮的，普通的機子若是有好的方法能夠考慮，不過也必須加大CPU和內存，就象面對着千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。
        3、要求很高的處理方法和技巧。這也是本文的寫做目的所在，好的處理方法是一位工程師長期工做經驗的積累，也是我的的經驗的總結。沒有通用的處理方法，但有通用的原理和規則。

  那麼處理海量數據有哪些經驗和技巧呢，我把我所知道的羅列一下，以供你們參考：

1、選用優秀的數據庫工具
        如今的數據庫工具廠家比較多，對海量數據的處理對所使用的數據庫工具要求比較高，通常使用Oracle或者DB2，微軟公司SQL Server 2005性能也不錯。另外在BI領域：數據庫，數據倉庫，多維數據庫，數據挖掘等相關工具也要進行選擇，像好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實際數據處理項目中，對天天6000萬條的日誌數據進行處理，使用SQL Server 2000須要花費6小時，而使用SQL Server 2005則只須要花費3小時。
2、編寫優良的程序代碼
        處理數據離不開優秀的程序代碼，尤爲在進行復雜數據處理時，必須使用程序。好的程序代碼對數據的處理相當重要，這不只僅是數據處理準確度的問題，更是數據處理效率的問題。良好的程序代碼應該包含好的算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。
3、對海量數據進行分區操做
        對海量數據進行分區操做十分必要，例如針對按年份存取的數據，咱們能夠按年進行分區，不一樣的數據庫有不一樣的分區方式，不過處理機制大致相同。例如SQL Server的數據庫分區是將不一樣的數據存於不一樣的文件組下，而不一樣的文件組存於不一樣的磁盤分區下，這樣將數據分散開，減少磁盤I/O，減少了系統負荷，並且還能夠將日誌，索引等放於不一樣的分區下。
4、創建普遍的索引
        對海量的數據處理，對大表創建索引是必行的，創建索引要考慮到具體狀況，例如針對大表的分組、排序等字段，都要創建相應索引，通常還能夠創建複合索引，對常常插入的表則創建索引時要當心，筆者在處理數據時，曾經在一個ETL流程中，當插入表時，首先刪除索引，而後插入完畢，創建索引，並實施聚合操做，聚合完成後，再次插入前仍是刪除索引，因此索引要用到好的時機，索引的填充因子和彙集、非彙集索引都要考慮。
5、創建緩存機制
        當數據量增長時，通常的處理工具都要考慮到緩存問題。緩存大小設置的好差也關係到數據處理的成敗，例如，筆者在處理2億條數據聚合操做時，緩存設置爲100000條/Buffer，這對於這個級別的數據量是可行的。
6、加大虛擬內存
        若是系統資源有限，內存提示不足，則能夠靠增長虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理，內存爲1GB，1個P4 2.4G的CPU，對這麼大的數據量進行聚合操做是有問題的，提示內存不足，那麼採用了加大虛擬內存的方法來解決，在6塊磁盤分區上分別創建了6個4096M的磁盤分區，用於虛擬內存，這樣虛擬的內存則增長爲 4096*6 + 1024 = 25600 M，解決了數據處理中的內存不足問題。
7、分批處理
        海量數據處理難由於數據量大，那麼解決海量數據處理難的問題其中一個技巧是減小數據量。能夠對海量數據分批處理，而後處理後的數據再進行合併操做，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，若是不容許拆分數據，還須要另想辦法。不過通常的數據按天、按月、按年等存儲的，均可以採用先分後合的方法，對數據進行分開處理。
8、使用臨時表和中間表
        數據量增長時，處理中要考慮提早彙總。這樣作的目的是化整爲零，大表變小表，分塊處理完成後，再利用必定的規則進行合併，處理過程當中的臨時表的使用和中間結果的保存都很是重要，若是對於超海量的數據，大表處理不了，只能拆分爲多個小表。若是處理過程當中須要多步彙總操做，可按彙總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。
9、優化查詢SQL語句
        在對海量數據進行查詢處理過程當中，查詢的SQL語句的性能對查詢效率的影響是很是大的，編寫高效優良的SQL腳本和存儲過程是數據庫工做人員的職責，也是檢驗數據庫工做人員水平的一個標準，在對SQL語句的編寫過程當中，例如減小關聯，少用或不用遊標，設計好高效的數據庫表結構等都十分必要。筆者在工做中試着對1億行的數據使用遊標，運行3個小時沒有出結果，這是必定要改用程序處理了。
10、使用文本格式進行處理
        對通常的數據處理可使用數據庫，若是對複雜的數據處理，必須藉助程序，那麼在程序操做數據庫和程序操做文本之間選擇，是必定要選擇程序操做文本的，緣由爲：程序操做文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如通常的海量的網絡日誌都是文本格式或者csv格式（文本格式），對它進行處理牽扯到數據清洗，是要利用程序進行處理的，而不建議導入數據庫再作清洗。
11、 定製強大的清洗規則和出錯處理機制
        海量數據中存在着不一致性，極有可能出現某處的瑕疵。例如，一樣的數據中的時間字段，有的可能爲非標準的時間，出現的緣由可能爲應用程序的錯誤，系統的錯誤等，這是在進行數據處理時，必須制定強大的數據清洗規則和出錯處理機制。
12、 創建視圖或者物化視圖
        視圖中的數據來源於基表，對海量數據的處理，能夠將數據按必定的規則分散到各個基表中，查詢或處理過程當中能夠基於視圖進行，這樣分散了磁盤I/O，正如10根繩子吊着一根柱子和一根吊着一根柱子的區別。
十3、 避免使用32位機子（極端狀況）
        目前的計算機不少都是32位的，那麼編寫的程序對內存的須要便受限制，而不少的海量數據處理是必須大量消耗內存的，這便要求更好性能的機子，其中對位數的限制也十分重要。
十4、考慮操做系統問題
        海量數據處理過程當中，除了對數據庫，處理程序等要求比較高之外，對操做系統的要求也放到了重要的位置，通常是必須使用服務器的，並且對系統的安全性和穩定性等要求也比較高。尤爲對操做系統自身的緩存機制，臨時空間的處理等問題都須要綜合考慮。
十5、使用數據倉庫和多維數據庫存儲
        數據量加大是必定要考慮OLAP的，傳統的報表可能五、6個小時出來結果，而基於Cube的查詢可能只須要幾分鐘，所以處理海量數據的利器是OLAP多維分析，即創建數據倉庫，創建多維數據集，基於多維數據集進行報表展示和數據挖掘等。
十6、使用採樣數據，進行數據挖掘
        基於海量數據的數據挖掘正在逐步興起，面對着超海量的數據，通常的挖掘軟件或算法每每採用數據抽樣的方式進行處理，這樣的偏差不會很高，大大提升了處理效率和處理的成功率。通常採樣時要注意數據的完整性和，防止過大的誤差。筆者曾經對1億2千萬行的表數據進行採樣，抽取出400萬行，經測試軟件測試處理的偏差爲千分之五，客戶能夠接受。
        還有一些方法，須要在不一樣的狀況和場合下運用，例如使用代理鍵等操做，這樣的好處是加快了聚合時間，由於對數值型的聚合比對字符型的聚合快得多。相似的狀況須要針對不一樣的需求進行處理。
       海量數據是發展趨勢，對數據分析和挖掘也愈來愈重要，從海量數據中提取有用信息重要而緊迫，這便要求處理要準確，精度要高，並且處理時間要短，獲得有價值信息要快，因此，對海量數據的研究頗有前途，也很值得進行普遍深刻的研究。