我在一次社群活動中做過一次分享，演講題目為《大資料平臺架構技術選型與場景運用》。在演講中，我主要分析了大資料平臺架構的生態環境，並主要以資料來源、資料採集、資料儲存與資料處理四個方面展開分析與講解，並結合具體的技術選型與需求場景，給出了我個人對大資料平臺的理解。本文是演講內容的第一部分。

大資料平臺是一個整體的生態系統，內容涵蓋非常豐富，涉及到大資料處理過程的諸多技術。在這些技術中，除了一些最基礎的平臺框架之外，針對不同的需求場景，也有不同的技術選擇。這其中，顯然有共性與差異性的特徵。若從整個開發生命週期的角度看，無論是需求、架構，還是開發、測試到最後的部署與運維，各種技術都會牽扯其中，不同的角色關注點自然也有不同。

大資料平臺的核心功能

從大資料平臺工程師的角度看，決定整個大資料平臺關鍵質量的不外三方面：

• 資料採集
• 資料儲存
• 資料處理

至於系統監控、資源協調、部署運維及其他管理功能都是大資料平臺整個生態環境中不可缺少的拼圖，但對於面向資料的架構，核心還是與資料打交道的一部分。如下圖所示：

根據我在大資料專案中的經驗，我發現，無論是資料採集、儲存還是分析，在技術選型與方案設計上，似乎又與資料來源的特徵息息相關，甚至在某種程度上，可以認為是資料來源的特點決定了整個大資料平臺架構的設計。

資料來源的特點

於是，我將關注點首要放在了資料來源上。分析資料來源的資料特徵，我從四個不同的維度對資料來源進行了分類：

來源

資料的來源不同，意味著我們對資料的掌控也就不同，更意味著我們對資料的訪問機制也有所不同。

企業的內部資料通常與具體業務緊密相關，且多數來自我們可以掌控（或者通過兄弟團隊）的軟體系統，如CRM、ERP或者HR系統。從企業架構的角度考慮，我們本身就應該避免企業系統出現所謂的“煙囪系統”，規避“資訊孤島”。設計良好的系統應該提供相關的介面允許其他系統有限度地訪問該系統的內部資料，又或者主動地將內部資料寫入到一個完全解耦合的元件中。例如，一個常見的做法是將內部系統實時產生的輸入寫入到Kafka中。

通常，我們會盡量避免直接將內部系統的資料庫公開給大資料平臺。因為這種方式不僅會帶來潛在的安全威脅，還可能會因為資源佔用的緣故影響到業務系統。

外部資料的獲取方式不外乎兩種：

• API呼叫
• 通過網路爬蟲抓取

與內部資料不同，外部資料不可能聽指揮地“召之即來揮之即去”，我們需要定期或不定期地去獲取資料，好處是我們可以根據業務場景和資料的特點自主地選擇資料儲存。

結構

只要瞭解過大資料專案，都知道資料結構直接影響了儲存與處理技術的選擇。RDB之於結構型資料，NoSQL之於非結構資料，這是司空見慣的配對了。相當而言，RDB的選擇比較簡單，NoSQL則有更復雜的分類。Pramod J·Sadalage與Martin Fowler在NoSQL Distilled一書中將NoSQL分為四類：

• 鍵值資料庫
• 文件資料庫
• 列族資料庫
• 圖資料庫

針對不同結構型別的資料，我們可以借鑑這一分類作為選型的參考。

可變性

Datomic資料庫的設計哲學是將所有過去發生的事情（或事件）認為是一個“fact（事實）”，基於事實不能篡改的本質，則資料庫中儲存的資料也當是不變的。無論是新增、刪除還是修改，在資料庫層面都是增加一條記錄，而非直接更改。

然而，多數資料庫並未新增這種不變性的約束，雖然這種不變性帶來的好處是明顯的，不過也會給業務系統的設計與實現帶來不必要的複雜度。然而，作為大資料平臺的資料來源而言，情況則相反，若資料允許更改，資料採集過程就會變得更復雜。

一種簡單的應對辦法是採用直連的形式。由於資料分析可能會基於不同的資料場景對資料儲存提出不同的要求，直連的資料來源未必滿足這種要求。例如，假設我們的分析場景是要做基於關鍵字的全文字搜尋，在大資料量高效能的要求下，選擇ElasticSearch或者Solr會表現更好，若直連的資料來源是MySQL，事情就會變得較為棘手。

資料量

資料量小，則一切都可迎刃而解，這裡不再贅述。

針對大資料量，實則是兩個不同的場景。一種是批處理方式，典型地演算法是MapReduce，主要針對非實時需求場景，我們可以編寫定期以及批量執行的任務來完成資料的採集。需要費心的是對Job的監控、管理與排程。另一種則是流處理方式，（準）實時對產生的資料進行處理，這種場景對資料來源的限制更多，最常見的方案就是將源源不斷產生的資料寫入到Kafka中。

在真實場景下，批處理與流處理方式可能共存。Lambda架構提出創新的三層架構方式，將此二者有機地融合起來，分別為：

• Batch Layer：針對批處理場景
• Speed Layer：針對流處理場景
• Serving Layer：由流處理場景提供實時資料模型，再對批處理的大資料進行預計算，從而提供批處理資料模型（聚合計算後），合併後提供給Serving Layer。

Lambda架構圖如下所示：

OLAP分析平臺druid就採用了Lambda架構。