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

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

采集

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

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

導入/預處理

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

在特點和挑戰(zhàn)方面，主要是導入數(shù)據(jù)量大，每秒導入量經(jīng)常達到百兆，甚至GB級別。

統(tǒng)計/分析

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

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

挖掘

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

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

如何從“小”做起?

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

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

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

> 數(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秒;

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

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

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

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

最后，想和大家說一下，“羅馬不是一天建成的”，無論是Google的用于大數(shù)據(jù)處理的基礎(chǔ)設(shè)施，還是我們國內(nèi)淘寶的“云梯”都是一步步通過不斷積累和實踐而成，所以我們這些中小企業(yè)應該貫徹“大處著眼、小處著手”的方針來持續(xù)地驗證和推進。還有，我們?nèi)嗽瓶萍紝⒂诮衲晟习肽臧l(fā)布用于海量結(jié)構(gòu)化數(shù)據(jù)處理的YunTable，由于其性能指標非常出色，并且已經(jīng)有正式運行的大型集群，所以請各位朋友敬請期待。

zhouxiaoli