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

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

采集

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

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

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

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

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

統(tǒng)計(jì)/分析

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

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

挖掘

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

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

如何從“小”做起?

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

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

明確分析自己的需求，下面是幾個(gè)常見(jiàn)的需求選項(xiàng)：

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

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

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

> 讀寫(xiě)比例，是寫(xiě)為主，還是以讀為主;

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

> 一致性，只接受強(qiáng)一致性，或者可以接受最終一致性和弱一致性;

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

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

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

盡量不要走平臺(tái)思路，應(yīng)以具體的應(yīng)用和場(chǎng)景為主，因?yàn)榻ㄒ粋€(gè)平臺(tái)有很多附加的成本和設(shè)計(jì)，比如，Amazon的云平臺(tái)是通過(guò)至少五年時(shí)間構(gòu)建而成。特別是項(xiàng)目的初期，不建議走平臺(tái)這個(gè)方向，而是應(yīng)腳踏實(shí)地以具體的商業(yè)場(chǎng)景為主。

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

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

zhouxiaoli