[[197640]]

無論是采集數(shù)據(jù)，還是存儲(chǔ)數(shù)據(jù)，都不是大數(shù)據(jù)平臺(tái)的最終目標(biāo)。失去數(shù)據(jù)處理環(huán)節(jié)，即使珍貴如金礦一般的數(shù)據(jù)也不過是一堆廢鐵而已。數(shù)據(jù)處理是大數(shù)據(jù)產(chǎn)業(yè)的核心路徑，然后再加上***一公里的數(shù)據(jù)可視化，整個(gè)鏈條就算徹底走通了。

如下圖所示，我們可以從業(yè)務(wù)、技術(shù)與編程模型三個(gè)不同的視角對(duì)數(shù)據(jù)處理進(jìn)行歸類：

業(yè)務(wù)角度的分類與具體的業(yè)務(wù)場(chǎng)景有關(guān)，但最終會(huì)制約技術(shù)的選型，尤其是數(shù)據(jù)存儲(chǔ)的選型。例如，針對(duì)查詢檢索中的全文本搜索，ElasticSearch會(huì)是***的選擇，而針對(duì)統(tǒng)計(jì)分析，則因?yàn)榻y(tǒng)計(jì)分析涉及到的運(yùn)算，可能都是針對(duì)一列數(shù)據(jù)，例如針對(duì)銷量進(jìn)行求和運(yùn)算，就是針對(duì)銷量這一整列的數(shù)據(jù)，此時(shí)，選擇列式存儲(chǔ)結(jié)構(gòu)可能更加適宜。

在技術(shù)角度的分類中，嚴(yán)格地講，SQL方式并不能分為單獨(dú)的一類，它其實(shí)可以看做是對(duì)API的封裝，通過SQL這種DSL來包裝具體的處理技術(shù)，從而降低數(shù)據(jù)處理腳本的遷移成本。畢竟，多數(shù)企業(yè)內(nèi)部的數(shù)據(jù)處理系統(tǒng)，在進(jìn)入大數(shù)據(jù)時(shí)代之前，大多以SQL形式來訪問存儲(chǔ)的數(shù)據(jù)。大體上，SQL是針對(duì)MapReduce的包裝，例如Hive、Impala或者Spark SQL。

Streaming流處理可以實(shí)時(shí)地接收由上游源源不斷傳來的數(shù)據(jù)，然后以某個(gè)細(xì)小的時(shí)間窗口為單位對(duì)這個(gè)過程中的數(shù)據(jù)進(jìn)行處理。消費(fèi)的上游數(shù)據(jù)可以是通過網(wǎng)絡(luò)傳遞過來的字節(jié)流、從HDFS讀取的數(shù)據(jù)流，又或者是消息隊(duì)列傳來的消息流。通常，它對(duì)應(yīng)的就是編程模型中的實(shí)時(shí)編程模型。

機(jī)器學(xué)習(xí)與深度學(xué)習(xí)都屬于深度分析的范疇。隨著Google的AlphaGo以及TensorFlow框架的開源，深度學(xué)習(xí)變成了一門顯學(xué)。我了解不多，這里就不露怯了。機(jī)器學(xué)習(xí)與常見的數(shù)據(jù)分析稍有不同，通常需要多個(gè)階段經(jīng)歷多次迭代才能得到滿意的結(jié)果。下圖是深度分析的架構(gòu)圖：

針對(duì)存儲(chǔ)的數(shù)據(jù)，需要采集數(shù)據(jù)樣本并進(jìn)行特征提取，然后對(duì)樣本數(shù)據(jù)進(jìn)行訓(xùn)練，并得到數(shù)據(jù)模型。倘若該模型經(jīng)過測(cè)試是滿足需求的，則可以運(yùn)用到數(shù)據(jù)分析場(chǎng)景中，否則需要調(diào)整算法與模型，再進(jìn)行下一次的迭代。

編程模型中的離線編程模型以Hadoop的MapReduce為代表，內(nèi)存編程模型則以Spark為代表，實(shí)時(shí)編程模型則主要指的是流處理，當(dāng)然也可能采用Lambda架構(gòu)，在Batch Layer(即離線編程模型)與Speed Layer(實(shí)時(shí)編程模型)之間建立Serving Layer，利用空閑時(shí)間與空閑資源，又或者在寫入數(shù)據(jù)的同時(shí)，對(duì)離線編程模型要處理的大數(shù)據(jù)進(jìn)行預(yù)先計(jì)算(聚合)，從而形成一種融合的視圖存儲(chǔ)在數(shù)據(jù)庫(kù)中(如HBase)，以便于快速查詢或計(jì)算。

不同的業(yè)務(wù)場(chǎng)景(業(yè)務(wù)場(chǎng)景可能出現(xiàn)混合)需要的數(shù)據(jù)處理技術(shù)不盡相同，因而在一個(gè)大數(shù)據(jù)系統(tǒng)下可能需要多種技術(shù)(編程模型)的混合。

我們?cè)跒槟硰S商實(shí)施輿情分析時(shí)，根據(jù)客戶需求，與數(shù)據(jù)處理有關(guān)的部分就包括：語義分析、全文本搜索與統(tǒng)計(jì)分析。通過網(wǎng)絡(luò)爬蟲抓取過來的數(shù)據(jù)會(huì)寫入到Kafka，而消費(fèi)端則通過Spark Streaming對(duì)數(shù)據(jù)進(jìn)行去重去噪，之后交給SAS的ECC服務(wù)器進(jìn)行文本的語義分析。分析后的數(shù)據(jù)會(huì)同時(shí)寫入到HDFS(Parquet格式的文本)和ElasticSearch。同時(shí)，為了避免因?yàn)槿ブ厝ピ胨惴ǖ恼`差而導(dǎo)致部分有用數(shù)據(jù)被“誤殺”，在MongoDB中還保存了一份全量數(shù)據(jù)。如下圖所示：

Airbnb的大數(shù)據(jù)平臺(tái)也根據(jù)業(yè)務(wù)場(chǎng)景提供了多種處理方式，整個(gè)平臺(tái)的架構(gòu)如下圖所示：

Panoramix(現(xiàn)更名為Caravel)為Airbnb提供數(shù)據(jù)探查功能，并對(duì)結(jié)果進(jìn)行可視化，Airpal則是基于Web的查詢執(zhí)行工具，它們的底層都是通過Presto對(duì)HDFS執(zhí)行數(shù)據(jù)查詢。Spark集群則為Airbnb的工程師與數(shù)據(jù)科學(xué)家提供機(jī)器學(xué)習(xí)與流處理的平臺(tái)。

行文至此，整個(gè)大數(shù)據(jù)平臺(tái)系列的講解就快結(jié)束了。***，我結(jié)合數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)與數(shù)據(jù)處理這四個(gè)環(huán)節(jié)給出了一個(gè)整體結(jié)構(gòu)圖，如下圖所示：

這幅圖以查詢檢索場(chǎng)景、OLAP場(chǎng)景、統(tǒng)計(jì)分析場(chǎng)景與深度分析場(chǎng)景作為核心的四個(gè)場(chǎng)景，并以不同顏色標(biāo)識(shí)不同的編程模型。從左到右，經(jīng)歷數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)處理四個(gè)相對(duì)完整的階段，可供大數(shù)據(jù)平臺(tái)的整體參考。