【正文】 另外在BI領域：數(shù)據(jù)庫，數(shù)據(jù)倉庫，多維數(shù)據(jù)庫，數(shù)據(jù)挖掘等相關工具也要進行選擇，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實際數(shù)據(jù)分析項目中，對每天6000萬條的日志數(shù)據(jù)進行處理，使用SQLServer20XX需要花費6小時，而使用SQLServer20XX則只需要花費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ū)方式，不過處理機制大體相同。例如SQLServer的數(shù)據(jù)庫分區(qū)是將不同的數(shù)據(jù)存于不同的文件組下，而不同的文件組存于不同的磁盤分區(qū)下，這樣將數(shù)據(jù)分散開，減小磁盤I/O，減小了系統(tǒng)負荷，而且還可以將日志，索引等放于不同的分區(qū)下。 四、建立廣泛的索引 對海量的數(shù)據(jù)處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等字段，都要建立相應索引，一般還可以建立復合索引，對經(jīng)常插入的表則建立索引時要小心，筆者在處理數(shù)據(jù)時，曾經(jīng)在一個ETL流程中，當插入表時，首先刪除索引，然后插入完畢，建立索引，并實施聚合操作，聚合完成后，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。 五、建立緩存機制 當數(shù)據(jù)量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好差也關系到數(shù)據(jù)處理的成敗，例如，筆者在處理2億條數(shù)據(jù)聚合操作時，緩存設置為100000條/Buffer，這對于這個級別的數(shù)據(jù)量是可行的。 六、加大虛擬內(nèi)存 如果系統(tǒng)資源有限，內(nèi)存提示不足，則可以靠增加虛擬內(nèi)存來解決。筆者在實際項目中曾經(jīng)遇到針對18億條的數(shù)據(jù)進行處理，內(nèi)存為1GB，對這么大的數(shù)據(jù)量進行聚合操作是有問題的，提示內(nèi)存不足，那么采用了加大虛擬內(nèi)存的方法來解決，在6塊磁盤分區(qū)上分別建立了6個4096M的磁盤分區(qū)，用于虛擬內(nèi)存，這樣虛擬的內(nèi)存則增加為4096x6+1024=25600M，解決了數(shù)據(jù)處理中的內(nèi)存不足問題。 七、分批處理 海量數(shù)據(jù)處理難因為數(shù)據(jù)量大，那么解決海量數(shù)據(jù)處理難的問題其中一個技巧是減少數(shù)據(jù)量?？梢詫Ａ繑?shù)據(jù)分批處理，然后處理后的數(shù)據(jù)再進行合并操作，這樣逐個擊破，有利于小數(shù)據(jù)量的處理，不至于面對大數(shù)據(jù)量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分數(shù)據(jù)，還需要另想辦法。不過一般的數(shù)據(jù)按天、按月、按年等存儲的，都可以采用先分后合的方法，對數(shù)據(jù)進行分開處理。 八、使用臨時表和中間表 數(shù)據(jù)量增加時，處理中要考慮提前匯總。這樣做的目的是化整為零，大表變小表，分塊處理完成后，再利用一定的規(guī)則進行合并，處理過程中的臨時表的使用和中間結果的保存都非常重要，如果對于超海量的數(shù)據(jù)，大表處理不了，只能拆分為多個小表。如果處理過程中需要多步匯總操作，可按匯總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。 九、優(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ù)庫和程序操作文本之間選擇，是一定要選擇程序操作文本的，原因為：程序操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如一般的海量的網(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ī)則分散到各個基表中，查詢或處理過程中可以基于視圖進行，這樣分散了磁盤I/O，正如10根繩子吊著一根柱子和一根吊著一根柱子的區(qū)別。 十三、避免使用32位機子（極端情況） 目前的計算機很多都是32位的，那么編寫的程序?qū)?nèi)存的需要便受限制，而很多的海量數(shù)據(jù)處理是必須大量消耗內(nèi)存的，這便要求更好性能的機子，其中對位數(shù)的限制也十分重要。 十四、考慮操作系統(tǒng)問題 海量數(shù)據(jù)處理過程中，除了對數(shù)據(jù)庫，處理程序等要求比較高以外，對操作系統(tǒng)的要求也放到了重要的位置，一般是必須使用服務器的，而且對系統(tǒng)的安全性和穩(wěn)定性等要求也比較高。尤其對操作系統(tǒng)自身的緩存機制，臨時空間的處理等問題都需要綜合考慮。 十五、使用數(shù)據(jù)倉庫和多維數(shù)據(jù)庫存儲 數(shù)據(jù)量加大是一定要考慮OLAP的，傳統(tǒng)的報表可能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)測試軟件測試處理的誤差為千分之五，客戶可以接受。 還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數(shù)值型的聚合比對字符型的聚合快得多。類似的情況需要針對不同的需求進行處理。 海量數(shù)據(jù)是發(fā)展趨勢，對數(shù)據(jù)分析和挖掘也越來越重要，從海量數(shù)據(jù)中提取有用信息重要而緊迫，這便要求處理要準確，精度要高，而且處理時間要短，得到有價值信息要快，所以，對海量數(shù)據(jù)的研究很有前途，也很值得進行廣泛深入的研究。 26 / 26