海量數(shù)據(jù)處理分析的16條經(jīng)驗(yàn)總結(jié)

海量數(shù)據(jù)在分析處理時(shí)會(huì)有各種各樣無法預(yù)想的問題，比如說：

一、數(shù)據(jù)量過大，數(shù)據(jù)中什么情況都可能存在。

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

二、軟硬件要求高，系統(tǒng)資源占用率高。

對(duì)海量的數(shù)據(jù)進(jìn)行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統(tǒng)資源。一般情況，如果處理的數(shù)據(jù)過TB級(jí)，小型機(jī)是要考慮的，普通的機(jī)子如果有好的方法可以考慮，不過也必須加大CPU和內(nèi)存，就象面對(duì)著千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。

三、要求很高的處理方法和技巧。

這也是本文的寫作目的所在，好的處理方法是一位工程師長(zhǎng)期工作經(jīng)驗(yàn)的積累，也是個(gè)人的經(jīng)驗(yàn)的總結(jié)。沒有通用的處理方法，但有通用的原理和規(guī)則。

那么處理海量數(shù)據(jù)有哪些經(jīng)驗(yàn)和技巧呢，我把我所知道的羅列一下，以供大家參考：

1、選用優(yōu)秀的數(shù)據(jù)庫(kù)工具

現(xiàn)在的數(shù)據(jù)庫(kù)工具廠家比較多，對(duì)海量數(shù)據(jù)的處理對(duì)所使用的數(shù)據(jù)庫(kù)工具要求比較高，一般使用Oracle或者DB2，微軟公司SQL Server 2005性能也不錯(cuò)。另外在BI領(lǐng)域：數(shù)據(jù)庫(kù)，數(shù)據(jù)倉(cāng)庫(kù)，多維數(shù)據(jù)庫(kù)，數(shù)據(jù)挖掘等相關(guān)工具也要進(jìn)行選擇，像好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實(shí)際數(shù)據(jù)分析項(xiàng)目中，對(duì)每天6000萬條的日志數(shù)據(jù)進(jìn)行處理，使用SQL Server 2000需要花費(fèi)6小時(shí)，而使用SQL Server 2005則只需要花費(fèi)3小時(shí)。

2、編寫優(yōu)良的程序代碼

處理數(shù)據(jù)離不開優(yōu)秀的程序代碼，尤其在進(jìn)行復(fù)雜數(shù)據(jù)處理時(shí)，必須使用程序。好的程序代碼對(duì)數(shù)據(jù)的處理至關(guān)重要，這不僅僅是數(shù)據(jù)處理準(zhǔn)確度的問題，更是數(shù)據(jù)處理效率的問題。良好的程序代碼應(yīng)該包含好的算法，包含好的處理流程，包含好的效率，包含好的異常處理機(jī)制等。

3、對(duì)海量數(shù)據(jù)進(jìn)行分區(qū)操作

對(duì)海量數(shù)據(jù)進(jìn)行分區(qū)操作十分必要，例如針對(duì)按年份存取的數(shù)據(jù)，我們可以按年進(jìn)行分區(qū)，不同的數(shù)據(jù)庫(kù)有不同的分區(qū)方式，不過處理機(jī)制大體相同。例如SQL Server的數(shù)據(jù)庫(kù)分區(qū)是將不同的數(shù)據(jù)存于不同的文件組下，而不同的文件組存于不同的磁盤分區(qū)下，這樣將數(shù)據(jù)分散開，減小磁盤I/O，減小了系統(tǒng)負(fù)荷，而且還可以將日志，索引等放于不同的分區(qū)下。

4、建立廣泛的索引

對(duì)海量的數(shù)據(jù)處理，對(duì)大表建立索引是必行的，建立索引要考慮到具體情況，例如針對(duì)大表的分組、排序等字段，都要建立相應(yīng)索引，一般還可以建立復(fù)合索引，對(duì)經(jīng)常插入的表則建立索引時(shí)要小心，筆者在處理數(shù)據(jù)時(shí)，曾經(jīng)在一個(gè)ETL流程中，當(dāng)插入表時(shí)，首先刪除索引，然后插入完畢，建立索引，并實(shí)施聚合操作，聚合完成后，再次插入前還是刪除索引，所以索引要用到好的時(shí)機(jī)，索引的填充因子和聚集、非聚集索引都要考慮。

5、建立緩存機(jī)制

當(dāng)數(shù)據(jù)量增加時(shí)，一般的處理工具都要考慮到緩存問題。緩存大小設(shè)置的好差也關(guān)系到數(shù)據(jù)處理的成敗，例如，筆者在處理2億條數(shù)據(jù)聚合操作時(shí)，緩存設(shè)置為100000條/Buffer，這對(duì)于這個(gè)級(jí)別的數(shù)據(jù)量是可行的。

6、加大虛擬內(nèi)存

如果系統(tǒng)資源有限，內(nèi)存提示不足，則可以靠增加虛擬內(nèi)存來解決。筆者在實(shí)際項(xiàng)目中曾經(jīng)遇到針對(duì)18億條的數(shù)據(jù)進(jìn)行處理，內(nèi)存為1GB，1個(gè)P4 2.4G的CPU，對(duì)這么大的數(shù)據(jù)量進(jìn)行聚合操作是有問題的，提示內(nèi)存不足，那么采用了加大虛擬內(nèi)存的方法來解決，在6塊磁盤分區(qū)上分別建立了6個(gè)4096M的磁盤分區(qū)，用于虛擬內(nèi)存，這樣虛擬的內(nèi)存則增加為 4096*6 + 1024 = 25600 M，解決了數(shù)據(jù)處理中的內(nèi)存不足問題。

7、分批處理

海量數(shù)據(jù)處理難因?yàn)閿?shù)據(jù)量大，那么解決海量數(shù)據(jù)處理難的問題其中一個(gè)技巧是減少數(shù)據(jù)量?？梢詫?duì)海量數(shù)據(jù)分批處理，然后處理后的數(shù)據(jù)再進(jìn)行合并操作，這樣逐個(gè)擊破，有利于小數(shù)據(jù)量的處理，不至于面對(duì)大數(shù)據(jù)量帶來的問題，不過這種方法也要因時(shí)因勢(shì)進(jìn)行，如果不允許拆分?jǐn)?shù)據(jù)，還需要另想辦法。不過一般的數(shù)據(jù)按天、按月、按年等存儲(chǔ)的，都可以采用先分后合的方法，對(duì)數(shù)據(jù)進(jìn)行分開處理。

8、使用臨時(shí)表和中間表

數(shù)據(jù)量增加時(shí)，處理中要考慮提前匯總。這樣做的目的是化整為零，大表變小表，分塊處理完成后，再利用一定的規(guī)則進(jìn)行合并，處理過程中的臨時(shí)表的使用和中間結(jié)果的保存都非常重要，如果對(duì)于超海量的數(shù)據(jù)，大表處理不了，只能拆分為多個(gè)小表。如果處理過程中需要多步匯總操作，可按匯總步驟一步步來，不要一條語句完成，一口氣吃掉一個(gè)胖子。

9、優(yōu)化查詢SQL語句

在對(duì)海量數(shù)據(jù)進(jìn)行查詢處理過程中，查詢的SQL語句的性能對(duì)查詢效率的影響是非常大的，編寫高效優(yōu)良的SQL腳本和存儲(chǔ)過程是數(shù)據(jù)庫(kù)工作人員的職責(zé)，也是檢驗(yàn)數(shù)據(jù)庫(kù)工作人員水平的一個(gè)標(biāo)準(zhǔn)，在對(duì)SQL語句的編寫過程中，例如減少關(guān)聯(lián)，少用或不用游標(biāo)，設(shè)計(jì)好高效的數(shù)據(jù)庫(kù)表結(jié)構(gòu)等都十分必要。筆者在工作中試著對(duì)1億行的數(shù)據(jù)使用游標(biāo)，運(yùn)行3個(gè)小時(shí)沒有出結(jié)果，這是一定要改用程序處理了。

10、使用文本格式進(jìn)行處理

對(duì)一般的數(shù)據(jù)處理可以使用數(shù)據(jù)庫(kù)，如果對(duì)復(fù)雜的數(shù)據(jù)處理，必須借助程序，那么在程序操作數(shù)據(jù)庫(kù)和程序操作文本之間選擇，是一定要選擇程序操作文本的，原因?yàn)椋撼绦虿僮魑谋舅俣瓤欤粚?duì)文本進(jìn)行處理不容易出錯(cuò)；文本的存儲(chǔ)不受限制等。例如一般的海量的網(wǎng)絡(luò)日志都是文本格式或者csv格式（文本格式），對(duì)它進(jìn)行處理牽扯到數(shù)據(jù)清洗，是要利用程序進(jìn)行處理的，而不建議導(dǎo)入數(shù)據(jù)庫(kù)再做清洗。

11、 定制強(qiáng)大的清洗規(guī)則和出錯(cuò)處理機(jī)制

海量數(shù)據(jù)中存在著不一致性，極有可能出現(xiàn)某處的瑕疵。例如，同樣的數(shù)據(jù)中的時(shí)間字段，有的可能為非標(biāo)準(zhǔn)的時(shí)間，出現(xiàn)的原因可能為應(yīng)用程序的錯(cuò)誤，系統(tǒng)的錯(cuò)誤等，這是在進(jìn)行數(shù)據(jù)處理時(shí)，必須制定強(qiáng)大的數(shù)據(jù)清洗規(guī)則和出錯(cuò)處理機(jī)制。

12、 建立視圖或者物化視圖

視圖中的數(shù)據(jù)來源于基表，對(duì)海量數(shù)據(jù)的處理，可以將數(shù)據(jù)按一定的規(guī)則分散到各個(gè)基表中，查詢或處理過程中可以基于視圖進(jìn)行，這樣分散了磁盤I/O，正如10根繩子吊著一根柱子和一根吊著一根柱子的區(qū)別。

13、 避免使用32位機(jī)子（極端情況）

目前的計(jì)算機(jī)很多都是32位的，那么編寫的程序?qū)?nèi)存的需要便受限制，而很多的海量數(shù)據(jù)處理是必須大量消耗內(nèi)存的，這便要求更好性能的機(jī)子，其中對(duì)位數(shù)的限制也十分重要。

14、考慮操作系統(tǒng)問題

海量數(shù)據(jù)處理過程中，除了對(duì)數(shù)據(jù)庫(kù)，處理程序等要求比較高以外，對(duì)操作系統(tǒng)的要求也放到了重要的位置，一般是必須使用服務(wù)器的，而且對(duì)系統(tǒng)的安全性和穩(wěn)定性等要求也比較高。尤其對(duì)操作系統(tǒng)自身的緩存機(jī)制，臨時(shí)空間的處理等問題都需要綜合考慮。

15、使用數(shù)據(jù)倉(cāng)庫(kù)和多維數(shù)據(jù)庫(kù)存儲(chǔ)

數(shù)據(jù)量加大是一定要考慮OLAP的，傳統(tǒng)的報(bào)表可能5、6個(gè)小時(shí)出來結(jié)果，而基于Cube的查詢可能只需要幾分鐘，因此處理海量數(shù)據(jù)的利器是OLAP多維分析，即建立數(shù)據(jù)倉(cāng)庫(kù)，建立多維數(shù)據(jù)集，基于多維數(shù)據(jù)集進(jìn)行報(bào)表展現(xiàn)和數(shù)據(jù)挖掘等。

16、使用采樣數(shù)據(jù)，進(jìn)行數(shù)據(jù)挖掘

基于海量數(shù)據(jù)的數(shù)據(jù)挖掘正在逐步興起，面對(duì)著超海量的數(shù)據(jù)，一般的挖掘軟件或算法往往采用數(shù)據(jù)抽樣的方式進(jìn)行處理，這樣的誤差不會(huì)很高，大大提高了處理效率和處理的成功率。一般采樣時(shí)要注意數(shù)據(jù)的完整性和，防止過大的偏差。筆者曾經(jīng)對(duì)1億2千萬行的表數(shù)據(jù)進(jìn)行采樣，抽取出400萬行，經(jīng)測(cè)試軟件測(cè)試處理的誤差為千分之五，客戶可以接受。

還有一些方法，需要在不同的情況和場(chǎng)合下運(yùn)用，例如使用代理鍵等操作，這樣的好處是加快了聚合時(shí)間，因?yàn)閷?duì)數(shù)值型的聚合比對(duì)字符型的聚合快得多。類似的情況需要針對(duì)不同的需求進(jìn)行處理。

海量數(shù)據(jù)是發(fā)展趨勢(shì)，對(duì)數(shù)據(jù)分析和挖掘也越來越重要，從海量數(shù)據(jù)中提取有用信息重要而緊迫，這便要求處理要準(zhǔn)確，精度要高，而且處理時(shí)間要短，得到有價(jià)值信息要快，所以，對(duì)海量數(shù)據(jù)的研究很有前途，也很值得進(jìn)行廣泛深入的研究。