我在一次社群活動中做過一次分享，演講題目為《大資料平臺架構技術選型與場景運用》。在演講中，我主要分析了大資料平臺架構的生態環境，並主要以資料來源、資料採集、資料儲存與資料處理四個方面展開分析與講解，並結合具體的技術選型與需求場景，給出了我個人對大資料平臺的理解。本文講解資料處理部分。
無論是採集資料，還是儲存資料，都不是大資料平臺的最終目標。失去資料處理環節，即使珍貴如金礦一般的資料也不過是一堆廢鐵而已。資料處理是大資料產業的核心路徑，然後再加上最後一公里的資料視覺化，整個鏈條就算徹底走通了。
如下圖所示，我們可以從業務、技術與程式設計模型三個不同的視角對資料處理進行歸類：
業務角度的分類與具體的業務場景有關，但最終會制約技術的選型，尤其是資料儲存的選型。例如，針對查詢檢索中的全文字搜尋，ElasticSearch會是最佳的選擇，而針對統計分析，則因為統計分析涉及到的運算，可能都是針對一列資料，例如針對銷量進行求和運算，就是針對銷量這一整列的資料，此時，選擇列式儲存結構可能更加適宜。
在技術角度的分類中，嚴格地講，SQL方式並不能分為單獨的一類，它其實可以看做是對API的封裝，通過SQL這種DSL來包裝具體的處理技術，從而降低資料處理指令碼的遷移成本。畢竟，多數企業內部的資料處理系統，在進入大資料時代之前，大多以SQL形式來訪問儲存的資料。大體上，SQL是針對MapReduce的包裝，例如Hive、Impala或者Spark SQL。
Streaming流處理可以實時地接收由上游源源不斷傳來的資料，然後以某個細小的時間視窗為單位對這個過程中的資料進行處理。消費的上游資料可以是通過網路傳遞過來的位元組流、從HDFS讀取的資料流，又或者是訊息佇列傳來的訊息流。通常，它對應的就是程式設計模型中的實時程式設計模型。
機器學習與深度學習都屬於深度分析的範疇。隨著Google的AlphaGo以及TensorFlow框架的開源，深度學習變成了一門顯學。我瞭解不多，這裡就不露怯了。機器學習與常見的資料分析稍有不同，通常需要多個階段經歷多次迭代才能得到滿意的結果。下圖是深度分析的架構圖：
針對儲存的資料，需要採集資料樣本並進行特徵提取，然後對樣本資料進行訓練，並得到資料模型。倘若該模型經過測試是滿足需求的，則可以運用到資料分析場景中，否則需要調整演算法與模型，再進行下一次的迭代。
程式設計模型中的離線程式設計模型以Hadoop的MapReduce為代表，記憶體程式設計模型則以Spark為代表，實時程式設計模型則主要指的是流處理，當然也可能採用Lambda架構，在Batch Layer（即離線程式設計模型）與Speed Layer（實時程式設計模型）之間建立Serving Layer，利用空閒時間與空閒資源，又或者在寫入資料的同時，對離線程式設計模型要處理的大資料進行預先計算（聚合），從而形成一種融合的檢視儲存在資料庫中（如HBase），以便於快速查詢或計算。
不同的業務場景（業務場景可能出現混合）需要的資料處理技術不盡相同，因而在一個大資料系統下可能需要多種技術（程式設計模型）的混合。
我們在為某廠商實施輿情分析時，根據客戶需求，與資料處理有關的部分就包括：語義分析、全文字搜尋與統計分析。通過網路爬蟲抓取過來的資料會寫入到Kafka，而消費端則通過Spark Streaming對資料進行去重去噪，之後交給SAS的ECC伺服器進行文字的語義分析。分析後的資料會同時寫入到HDFS（Parquet格式的文字）和ElasticSearch。同時，為了避免因為去重去噪演算法的誤差而導致部分有用資料被“誤殺”，在MongoDB中還儲存了一份全量資料。如下圖所示：
Airbnb的大資料平臺也根據業務場景提供了多種處理方式，整個平臺的架構如下圖所示：
Panoramix(現更名為Caravel)為Airbnb提供資料探查功能，並對結果進行視覺化，Airpal則是基於Web的查詢執行工具，它們的底層都是通過Presto對HDFS執行資料查詢。Spark叢集則為Airbnb的工程師與資料科學家提供機器學習與流處理的平臺。
行文至此，整個大資料平臺系列的講解就快結束了。最後，我結合資料來源、資料採集、資料儲存與資料處理這四個環節給出了一個整體結構圖，如下圖所示：

這幅圖以查詢檢索場景、OLAP場景、統計分析場景與深度分析場景作為核心的四個場景，並以不同顏色標識不同的程式設計模型。從左到右，經歷資料來源、資料採集、資料儲存和資料處理四個相對完整的階段，可供大資料平臺的整體參考。