海量資料的處理和優化

筆者在實際工作中，有幸接觸到海量的資料處理問題，海量資料是指數據量過大，資料格式複雜，資料中的隨機情況多，不便於分類和處理的資料。對其進行處理是一項艱巨而複雜的任務，原因有以下幾個方面：

1. 數據量過大。資料中什麼情況都可能存在。如果說有10條資料，那麼大不了每條去逐一檢查，人為處 理；如果有上百條資料，也可以考慮；如果資料上到千萬級別，甚至過億，那就不是手工能解決的了，必須通過工具或者程式進行處理。而海量的資料中，什麼情況 都可能存在，例如，資料中某處格式出了問題，尤其在程式處理時，前面還能正常處理，突然到了某個地方問題出現了，程式終止了。

2. 軟硬體要求高。系統資源佔用率高。對海量的資料進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。一般情況，如果處理的資料超過TB級，小型機是要考慮的，普通的伺服器如果有好的方法也可以考慮，不過也必須加大CPU和記憶體。

3. 要求很高的處理方法和技巧。這也是本文的寫作目的所在，好的處理方法是一位元工程師長期工作經驗的積累，也是個人經驗的總結。沒有通用的處理方法，但有通用的原理和規則。

那麼處理海量資料有哪些經驗和技巧呢？我把我所知道的羅列一下，以供大家參考：

確定好的建模方法和處理方案。對海量資料的處理，明確切實可行的處理方法和流程最為關鍵。在建立處理模型時要充分考慮到海量資料資料量大、資料格式複雜的特點，建立好的處理模型。好的處理模型應該是處理中最快的，能夠便於擴展，便於處理更大的資料量，便於實施等等。

選用優秀的資料庫工具。 現在的資料庫工具廠家比較多，處理海量資料對所使用的資料庫工具要求比較高，一般使用Oracle或者DB2，微軟公司最近發佈的SQL Server 2005性能也不錯。另外在BI領域：資料庫，資料倉庫，多維資料庫，資料挖掘等相關工具也要進行選擇，像好的ETL工具和好的OLAP工具都十分必要， 例如Informatic、Eassbase等等。筆者在實際資料分析專案中，對每天6000萬條的日誌資料進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005只需要花費3小時。

編寫優良的程式碼。處理資料離不開優秀的程式碼，尤其在進行複雜資料處理時，必須使用程式。好的程式碼對資料的處理至關重要，這不僅僅是資料處理準確度的問題，更是資料處理效率的問題。良好的程式碼應該包含好的演算法、好的處理流程、好的效率、好的異常處理機制等等。

對海量資料進行分區操作。 對海量資料進行分區操作十分必要，例如針對按年份存取的資料，我們可以按年進行分區，不同的資料庫有不同的分區方式，不過處理機制大體相同。例如SQL Server的資料庫分區是將不同的資料存於不同的檔組下，而不同的檔組存於不同的磁片分區下，這樣將資料分散開，減小磁片I/O，減小了系統負荷， 而且還可以將日誌、索引存放於不同的分區下。

建立廣泛的索引。對海量的資料處理，對大表 建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等欄位，都要建立相應索引，一般還可以建立複合索引，對經常插入的表則建立索引時 要小心。筆者在處理資料時，曾經在一個ETL流程中，當插入表時，首先刪除索引，插入完畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索 引，所以索引要用到好的時機，索引的填充因數和聚集、非聚集索引都要考慮。

提高硬體條件，加大CPU和記憶體。 對海量資料資料處理，必須考慮硬體條件，使用高配置伺服器的。硬體條件包括加大記憶體，加入更多更強勁的CPU，加大硬碟空間等等。筆者在處理2TB資料 時，使用的是4個CPU，16GB記憶體，發現有時還會出現記憶體不足現象，需要進行其他方面的優化，如果這時沒有足夠的硬體條件做支撐，是萬萬不行的。

建立緩存機制。當資料量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好壞也關係到資料處理的成敗，例如，筆者在處理2億條資料聚合操作時，緩存設置為10萬條/Buffer，這對於這個級別的資料量是可行的。

加大虛擬記憶體。 如果系統資源有限，記憶體提示不足，則可以靠增加虛擬記憶體來解決。筆者在實際專案中曾經遇到針對18億條的資料進行處理，記憶體為1GB，1個P4 2.4G的CPU，對這麼大的資料量進行聚合操作是有問題的，提示記憶體不足，後來採用了加大虛擬記憶體的方法來解決，在6塊磁片分區上分別建立了6個 4096M的磁片分區，用於虛擬記憶體，這樣虛擬的記憶體則增加為4096*6 + 1024 = 25600 M，解決了資料處理中的記憶體不足問題。

分批次處理。 海量資料處理難是因為資料量大，那麼解決海量資料處理難的問題其中一個技巧是減少資料量。可以對海量資料分批次處理，處理後的資料再進行合併操作，這樣逐個 擊破，有利於小資料量的處理，不至於面對大資料量帶來的問題。但這種方法也要因時因勢進行，如果不允許拆分數據，還需要另想辦法。不過一般按天、月、年等 存儲的資料，都可以採用先分後合的方法，對資料進行分開處理。

使用臨時表和中間表。資料量增加時，處理中要考慮提前匯總。這樣做的目的是化整為 零，大表變小表，分塊處理完成後，再利用一定的規則進行合併，處理過程中的臨時表的使用和中間結果的保存都非常重要，對於超海量的資料，如果大表處理不 了，只能拆分為多個小表。如果處理過程中需要多步匯總操作，可按匯總步驟一步步來，不要一條語句完成，一口氣吃成一個胖子。

優化查詢SQL語句。 在對海量資料進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的，編寫高效優良的SQL腳本和存儲過程是資料庫工作人員的職責，也是 檢驗資料庫工作人員水準的一個標準，在對SQL語句的編寫過程中，例如減少關聯，少用或不用游標，設計好高效的資料庫表結構等都十分必要。筆者在工作中試 著對1億行的資料使用游標，運行3個小時沒有出結果，這時一定要改用程式處理了。

使用文本格式進行處理。 對一般的資料處理可以使用資料庫，如果對複雜的資料處理，必須借助程式，那麼在程式操作資料庫和程式操作文本之間選擇，是一定要選擇程式操作文本的。原因 為：程式操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等等。例如一般的海量的網路日誌都是文本格式或者csv格式（文本格式），對它進 行處理牽扯到資料清洗，是要利用程式進行處理的，而不建議導入資料庫再做清洗。

定制強大的清洗規則和出錯處理機制。海量資料中存在著不一致性，極有可能出現某處的瑕疵。例如，同樣的資料中的時間欄位，有的可能為非標準的時間，出現的原因可能為應用程式的錯誤，系統的錯誤等等。在進行資料處理時，必須制定強大的資料清洗規則和出錯處理機制。

建立視圖或者物化視圖。視圖中的資料來源於基表，對海量資料的處理，可以將資料按一定的規則分散到各個基表中，查詢或處理過程中可以基於視圖進行，這樣分散了磁片I/O，正如10根繩子吊著一根柱子和一根繩子吊著一根柱子的區別。

避免使用32位元伺服器（極端情況）。目前的電腦很多都是32位元的，那麼編寫的程式對記憶體的需要便受限制，而很多的海量資料處理是必須大量消耗記憶體的，這便要求更好性能的伺服器，其中對位數的限制也十分重要。

考慮作業系統問題。海量資料處理過程中，除了對資料庫、處理程式等要求比較高以外，對作業系統的要求也放到了重要的位置，一般是必須使用伺服器的，而且對系統的安全性和穩定性等要求也比較高。尤其對作業系統自身的緩存機制、臨時空間的處理等問題都需要綜合考慮。

使用資料倉庫和多維資料庫存儲。資料量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鐘，因此處理海量資料的利器是OLAP多維分析，即建立資料倉庫，建立多維資料集，基於多維資料集進行報表展現和資料挖掘等等。

使用採樣資料，進行資料挖掘。 基於海量資料的資料挖掘正在逐步興起，面對著超海量的資料，一般的挖掘軟體或演算法往往採用資料抽樣的方式進行處理，這樣的誤差不會很大，大大提高了處理效 率和處理的成功率。一般採樣時要注意資料的完整性，防止過大的偏差。筆者曾經對1億2千萬行的表資料進行採樣，抽取出400萬行，經測試軟體測試處理的誤 差僅為千分之五，客戶可以接受。

還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數值型的聚合比對字元型的聚合快得多。類似的情況需要針對不同的需求進行處理。

海量資料是發展趨勢，對資料分析和挖掘也越來越重要，從海量資料中提取有用資訊重要而緊迫，這便要求處理要準確，精度要高，而且處理時間要短，得到有價值資訊要快，所以，對海量資料的研究很有前途，也很值得進行廣泛深入的研究。