海量數(shù)據(jù)的處理及優(yōu)化

1、海量數(shù)據(jù)的處理及優(yōu)化筆者在實際工作中，有幸接觸到海量的數(shù)據(jù)處理問題， 海量數(shù)據(jù)是指數(shù)據(jù)量過大，數(shù)據(jù)格式復雜，數(shù)據(jù)中的隨機情 況多，不便于分類和處理的數(shù)據(jù)。對其進行處理是一項艱巨 而復雜的任務，原因有以下幾個方面： 1. 數(shù)據(jù)量過大。 數(shù)據(jù) 中什么情況都可能存在。如果說有 10 條數(shù)據(jù)，那么大不了 每條去逐一檢查，人為處 理；如果有上百條數(shù)據(jù)，也可以 考慮；如果數(shù)據(jù)上到千萬級別，甚至過億，那就不是手工能 解決的了，必須通過工具或者程序進行處理。而海量的數(shù)據(jù) 中，什么情況 都可能存在，例如，數(shù)據(jù)中某處格式出了問 題，尤其在程序處理時，前面還能正常處理，突然到了某個 地方問題出現(xiàn)了， 程序終止了。

2、2. 軟硬件要求高。 系統(tǒng)資源 占用率高。對海量的數(shù)據(jù)進行處理，除了好的方法，最重要 的就是合理使用工具，合理分配系統(tǒng)資源。一般情況，如果 處理的數(shù)據(jù)超過 TB 級，小型機是要考慮的，普通的服務器 如果有好的方法也可以考慮， 不過也必須加大 CPU 和內存。 3. 要求很高的處理方法和技巧。 這也是本文的寫作目的所在， 好的處理方法是一位工程師長期工作經(jīng)驗的積累，也是個人 經(jīng)驗的總結。 沒有通用的處理方法， 但有通用的原理和規(guī)則。 那么處理海量數(shù)據(jù)有哪些經(jīng)驗和技巧呢？我把我所知道的 羅列一下，以供大家參考：確定好的建模方法和處理方案。對海量數(shù)據(jù)的處理，明確切實可行的處理方法和流程最為關 鍵。在

3、建立處理模型時要充分考慮到海量數(shù)據(jù)數(shù)據(jù)量大、數(shù) 據(jù)格式復雜的特點，建立好的處理模型。好的處理模型應該 是處理中最快的，能夠便于擴展，便于處理更大的數(shù)據(jù)量， 便于實施等等。選用優(yōu)秀的數(shù)據(jù)庫工具。 現(xiàn)在的數(shù)據(jù)庫工 具廠家比較多，處理海量數(shù)據(jù)對所使用的數(shù)據(jù)庫工具要求比 較高，一般使用 Oracle 或者 DB2 ，微軟公司最近發(fā)布的 SQL Server 2005 性能也不錯。另外在 BI 領域：數(shù)據(jù)庫，數(shù)據(jù)倉 庫，多維數(shù)據(jù)庫，數(shù)據(jù)挖掘等相關工具也要進行選擇，像好 的 ETL 工具和好的 OLAP 工具都十分必要， 例如 Informatic 、 Eassbase 等等。筆者在實際數(shù)據(jù)分析項目中，對

4、每天 6000 萬條的日志數(shù)據(jù)進行處理， 使用 SQL Server 2000 需要花費 6 小時，而使用 SQL Server 2005 只需要花費 3 小時。編寫 優(yōu)良的程序代碼。處理數(shù)據(jù)離不開優(yōu)秀的程序代碼，尤其在 進行復雜數(shù)據(jù)處理時，必須使用程序。好的程序代碼對數(shù)據(jù) 的處理至關重要，這不僅僅是數(shù)據(jù)處理準確度的問題，更是 數(shù)據(jù)處理效率的問題。良好的程序代碼應該包含好的算法、 好的處理流程、好的效率、好的異常處理機制等等。對海量 數(shù)據(jù)進行分區(qū)操作。 對海量數(shù)據(jù)進行分區(qū)操作十分必要， 例如針對按年份存取的數(shù)據(jù)，我們可以按年進行分區(qū)，不同 的數(shù)據(jù)庫有不同的分區(qū)方式，不過處理機制大體相同。例如

5、SQL Server 的數(shù)據(jù)庫分區(qū)是將不同的數(shù)據(jù)存于不同的文件 組下，而不同的文件組存于不同的磁盤分區(qū)下，這樣將數(shù)據(jù) 分散開，減小磁盤 I/O ，減小了系統(tǒng)負荷， 而且還可以將日 志、索引存放于不同的分區(qū)下。建立廣泛的索引。對海量的 數(shù)據(jù)處理，對大表 建立索引是必行的，建立索引要考慮到 具體情況，例如針對大表的分組、排序等字段，都要建立相 應索引，一般還可以建立復合索引，對經(jīng)常插入的表則建立 索引時 要小心。筆者在處理數(shù)據(jù)時，曾經(jīng)在一個 ETL 流程 中，當插入表時，首先刪除索引，插入完畢，建立索引，并 實施聚合操作，聚合完成后，再次插入前還是刪除索 引， 所以索引要用到好的時機，索引的填充因

6、子和聚集、非聚集 索引都要考慮。提高硬件條件，加大 CPU 和內存。 對海量 數(shù)據(jù)數(shù)據(jù)處理，必須考慮硬件條件，使用高配置服務器的。 硬件條件包括加大內存， 加入更多更強勁的 CPU ，加大硬盤 空間等等。筆者在處理 2TB 數(shù)據(jù) 時，使用的是 4 個 CPU ， 16GB 內存，發(fā)現(xiàn)有時還會出現(xiàn)內存不足現(xiàn)象，需要進行其 它方面的優(yōu)化，如果這時沒有足夠的硬件條件做支撐，是萬 萬不行的。建立緩存機制。當數(shù)據(jù)量增加時，一般的處理工 具都要考慮到緩存問題。緩存大小設置的好壞也關系到數(shù)據(jù) 處理的成敗，例如，筆者在處理 2 億條數(shù)據(jù)聚合操作時，緩 存設置為10萬條/Buffer，這對于這個級別的數(shù)據(jù)量是可

7、行 的。加大虛擬內存。 如果系統(tǒng)資源有限，內存提示不足， 則可以靠增加虛擬內存來解決。筆者在實際項目中曾經(jīng)遇到針對 18 億條的數(shù)據(jù)進行處理，內存為 1GB，1 個 P4 2.4G的 CPU ，對這么大的數(shù)據(jù)量進行聚合操作是有問題的，提示內存不足，后來采用了加大虛擬內存的方法來解決，在 6 塊 磁盤分區(qū)上分別建立了 6 個 4096M 的磁盤分區(qū)，用于虛擬 內存，這樣虛擬的內存則增加為 4096*6 + 1024 = 25600 M ， 解決了數(shù)據(jù)處理中的內存不足問題。分批處理。 海量數(shù)據(jù) 處理難是因為數(shù)據(jù)量大，那么解決海量數(shù)據(jù)處理難的問題其 中一個技巧是減少數(shù)據(jù)量?？梢詫Ａ繑?shù)據(jù)分批處理，處

8、理 后的數(shù)據(jù)再進行合并操作，這樣逐個 擊破，有利于小數(shù)據(jù) 量的處理，不至于面對大數(shù)據(jù)量帶來的問題。但這種方法也 要因時因勢進行，如果不允許拆分數(shù)據(jù)，還需要另想辦法。 不過一般按天、月、年等 存儲的數(shù)據(jù)，都可以采用先分后 合的方法，對數(shù)據(jù)進行分開處理。使用臨時表和中間表。數(shù) 據(jù)量增加時，處理中要考慮提前匯總。這樣做的目的是化整 為 零，大表變小表，分塊處理完成后，再利用一定的規(guī)則 進行合并，處理過程中的臨時表的使用和中間結果的保存都 非常重要，對于超海量的數(shù)據(jù)，如果大表處理不 了，只能 拆分為多個小表。如果處理過程中需要多步匯總操作，可按 匯總步驟一步步來，不要一條語句完成，一口氣吃成一個胖 子

9、。優(yōu)化查詢 SQL 語句。 在對海量數(shù)據(jù)進行查詢處理過程 中，查詢的 SQL 語句的性能對查詢效率的影響是非常大的， 編寫高效優(yōu)良的 SQL 腳本和存儲過程是數(shù)據(jù)庫工作人員的職責，也是 檢驗數(shù)據(jù)庫工作人員水平的一個標準， 在對 SQL 語句的編寫過程中，例如減少關聯(lián)，少用或不用游標，設計 好高效的數(shù)據(jù)庫表結構等都十分必要。筆者在工作中試 著 對 1 億行的數(shù)據(jù)使用游標，運行 3 個小時沒有出結果，這時 一定要改用程序處理了。使用文本格式進行處理。 對一般 的數(shù)據(jù)處理可以使用數(shù)據(jù)庫，如果對復雜的數(shù)據(jù)處理，必須 借助程序，那么在程序操作數(shù)據(jù)庫和程序操作文本之間選擇， 是一定要選擇程序操作文本的。原

10、因 為：程序操作文本速 度快；對文本進行處理不容易出錯；文本的存儲不受限制等 等。例如一般的海量的網(wǎng)絡日志都是文本格式或者 csv 格式 （文本格式） ，對它進 行處理牽扯到數(shù)據(jù)清洗，是要利用程 序進行處理的，而不建議導入數(shù)據(jù)庫再做清洗。定制強大的 清洗規(guī)則和出錯處理機制。海量數(shù)據(jù)中存在著不一致性，極 有可能出現(xiàn)某處的瑕疵。例如，同樣的數(shù)據(jù)中的時間字段， 有的可能為非標準的時間，出現(xiàn)的原因可能為應用程序的錯 誤，系統(tǒng)的錯誤等等。在進行數(shù)據(jù)處理時，必須制定強大的 數(shù)據(jù)清洗規(guī)則和出錯處理機制。建立視圖或者物化視圖。視 圖中的數(shù)據(jù)來源于基表，對海量數(shù)據(jù)的處理，可以將數(shù)據(jù)按 一定的規(guī)則分散到各個基表中

11、，查詢或處理過程中可以基于 視圖進行，這樣分散了磁盤 I/O ，正如 10 根繩子吊著一根柱 子和一根繩子吊著一根柱子的區(qū)別。避免使用 32 位服務器極端情況） 。目前的計算機很多都是 32 位的，那么編寫的 程序對內存的需要便受限制，而很多的海量數(shù)據(jù)處理是必須 大量消耗內存的，這便要求更好性能的服務器，其中對位數(shù) 的限制也十分重要?？紤]操作系統(tǒng)問題。海量數(shù)據(jù)處理過程 中，除了對數(shù)據(jù)庫、處理程序等要求比較高以外，對操作系 統(tǒng)的要求也放到了重要的位置，一般是必須使用服務器的， 而且對系統(tǒng)的安全性和穩(wěn)定性等要求也比較高。尤其對操作 系統(tǒng)自身的緩存機制、臨時空間的處理等問題都需要綜合考 慮。使用數(shù)據(jù)

12、倉庫和多維數(shù)據(jù)庫存儲。數(shù)據(jù)量加大是一定要 考慮 OLAP 的，傳統(tǒng)的報表可能 5、 6 個小時出來結果，而 基于 Cube 的查詢可能只需要幾分鐘，因此處理海量數(shù)據(jù)的 利器是 OLAP 多維分析，即建立數(shù)據(jù)倉庫， 建立多維數(shù)據(jù)集， 基于多維數(shù)據(jù)集進行報表展現(xiàn)和數(shù)據(jù)挖掘等等。使用采樣數(shù) 據(jù)，進行數(shù)據(jù)挖掘。 基于海量數(shù)據(jù)的數(shù)據(jù)挖掘正在逐步興 起，面對著超海量的數(shù)據(jù)，一般的挖掘軟件或算法往往采用 數(shù)據(jù)抽樣的方式進行處理，這樣的誤差不會很大，大大提高 了處理效 率和處理的成功率。一般采樣時要注意數(shù)據(jù)的完 整性，防止過大的偏差。筆者曾經(jīng)對 1 億 2 千萬行的表數(shù)據(jù) 進行采樣，抽取出 400 萬行，經(jīng)測試軟件測試處理的誤 差 僅為千分之五，客戶可以接受。還有一些方法，需要