大數(shù)據(jù)的常見處理流程

前面已經(jīng)介紹了了處理大數(shù)據(jù)的必要性和特點，那么接著將談到如何處理大數(shù)據(jù)，特別是常見的處理流程。具體的大數(shù)據(jù)處理方法其實有很多，但是根據(jù)長時間的實踐，筆者總結(jié)了一個基本的大數(shù)據(jù)處理流程(圖1)，并且這個流程應(yīng)該能夠?qū)Υ蠹依眄槾髷?shù)據(jù)的處理有所幫助。

圖1. 大數(shù)據(jù)的常見處理流程

整個處理流程可以概括為四步，分別是采集、導(dǎo)入和預(yù)處理、統(tǒng)計和分析，以及挖掘

采集

大數(shù)據(jù)的采集是指利用多個數(shù)據(jù)庫來接收發(fā)自客戶端(Web、App或者傳感器形式等)的數(shù)據(jù)，并且用戶可以通過這些數(shù)據(jù)庫來進行簡單的查詢和處理工作。比如，電商會使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫MySQL和Oracle等來存儲每一筆事務(wù)數(shù)據(jù)，除此之外，Redis和MongoDB這樣的NoSQL數(shù)據(jù)庫也常用于數(shù)據(jù)的采集。

在大數(shù)據(jù)的采集過程中，其主要特點和挑戰(zhàn)是并發(fā)數(shù)高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網(wǎng)站和淘寶，它們并發(fā)的訪問量在峰值時達到上百萬，所以需要在采集端部署大量數(shù)據(jù)庫才能支撐。并且如何在這些數(shù)據(jù)庫之間進行負載均衡和分片的確是需要深入的思考和設(shè)計。

導(dǎo)入/預(yù)處理

雖然采集端本身會有很多數(shù)據(jù)庫，但是如果要對這些海量數(shù)據(jù)進行有效的分析，還是應(yīng)該將這些來自前端的數(shù)據(jù)導(dǎo)入到一個集中的大型分布式數(shù)據(jù)庫，或者分布式存儲集群，并且可以在導(dǎo)入基礎(chǔ)上做一些簡單的清洗和預(yù)處理工作。也有一些用戶會在導(dǎo)入時使用來自Twitter的Storm來對數(shù)據(jù)進行流式計算，來滿足部分業(yè)務(wù)的實時計算需求。

導(dǎo)入與預(yù)處理過程的特點和挑戰(zhàn)主要是導(dǎo)入的數(shù)據(jù)量大，每秒鐘的導(dǎo)入量經(jīng)常會達到百兆，甚至千兆級別。

統(tǒng)計/分析

統(tǒng)計與分析主要利用分布式數(shù)據(jù)庫，或者分布式計算集群來對存儲于其內(nèi)的海量數(shù)據(jù)進行普通的分析和分類匯總等，以滿足大多數(shù)常見的分析需求，在這方面，一些實時性需求會用到EMC 的GreenPlum、Oracle的Exadata，以及基于MySQL的列式存儲Infobright等，而一些批處理，或者基于半結(jié)構(gòu)化數(shù)據(jù)的需求可以使用Hadoop。

統(tǒng)計與分析這部分的主要特點和挑戰(zhàn)是分析涉及的數(shù)據(jù)量大，其對系統(tǒng)資源，特別是I/O會有極大的占用。

挖掘

與前面統(tǒng)計和分析過程不同的是，數(shù)據(jù)挖掘一般沒有什么預(yù)先設(shè)定好的主題，主要是在現(xiàn)有數(shù)據(jù)上面進行基于各種算法的計算，從而起到預(yù)測(Predict)的效果，從而實現(xiàn)一些高級別數(shù)據(jù)分析的需求。比較典型算法有用于聚類的K-Means、用于統(tǒng)計學(xué)習(xí)的SVM和用于分類的Naive Bayes，主要使用的工具有Hadoop的Mahout等。

該過程的特點和挑戰(zhàn)主要是用于挖掘的算法很復(fù)雜，并且計算涉及的數(shù)據(jù)量和計算量都很大，還有，常用數(shù)據(jù)挖掘算法都以單線程為主。

如何從“小”做起?

由于筆者平時與中小企業(yè)的接觸非常頻繁，雖然技術(shù)方案與實際的問題相關(guān)，但卻很難在一篇文章當(dāng)中詳盡地道來。除了上述的基本處理流程之外，以下會將一些基本的從“小”做起的思路作闡述：

1. 認識自己的不足。主要是在技術(shù)、人力和財力等方面不僅無法與Google和Amazon這樣的國外巨頭比肩，而且與國內(nèi)三大互聯(lián)網(wǎng)BAT(百度、阿里巴巴和騰訊)也是無法比肩的，所以需要深刻認識;

2. 明確分析自己的需求。下面是幾個常見的需求選項：

數(shù)據(jù)類型，是結(jié)構(gòu)化，半結(jié)構(gòu)化，還是非結(jié)構(gòu)化為主;

數(shù)據(jù)大小，內(nèi)部數(shù)據(jù)級別是TB級別、PB級別或者PB以上的級別;

讀寫量級，比如每小時寫入的數(shù)據(jù)達到GB級別，或者每天寫入達到TB級別等;

讀寫比例，是寫為主，還是以讀為主;

并發(fā)數(shù)，大致的每秒并發(fā)數(shù);

一致性，只接受強一致性，或者可以接受最終一致性和弱一致性;

延遲度，最高能容忍的延遲度是多少，是10毫秒，100毫秒，還是1秒;

分析的復(fù)雜度，需不需要引入較復(fù)雜的數(shù)據(jù)挖掘算法等。

3. 要靈活使用現(xiàn)有的工具。首先，推薦使用一些開源，或者是價格可以承受的商業(yè)軟件。雖然個人并不排斥自建，但是一定要有具體的商業(yè)價值，并且最好是在現(xiàn)有工具上的畫龍點睛，而不是從頭開始構(gòu)建;其次，工具方面應(yīng)與具體的場景相關(guān)，在不同的場景要使用不同的工具。

4. 盡量不要走平臺思路，應(yīng)以具體的應(yīng)用和場景為主。因為建一個平臺有很多附加的成本和設(shè)計，比如，Amazon的云平臺是通過至少五年時間構(gòu)建而成。特別是項目初期，不建議走平臺這個方向，而是應(yīng)腳踏實地以具體的商業(yè)場景為主。

5. 找準(zhǔn)切入點。最好是找到一個技術(shù)難度小，并且有一定的商業(yè)價值的場景來做大數(shù)據(jù)技術(shù)落地的試點，并不斷地進行測試和迭代來驗證，而不是一味求復(fù)雜、求大，這樣比較容易說服企業(yè)管理層來進行長期的投入和支持;

最后，想強調(diào)一下，“羅馬不是一天建成的”。無論是Google的用于大數(shù)據(jù)處理的基礎(chǔ)設(shè)施，還是國內(nèi)淘寶的“云梯”都是一步步通過不斷的積累和實踐完成的，所以中小企業(yè)應(yīng)該貫徹“大處著眼、小處著手”的方針來持續(xù)地驗證和推進。