剖析大數據平台的數據源

摘要： 主要分析了大數據平台架構的生態環境，並主要以數據源、數據採集、數據存儲與數據處理四個方面展開分析與講解，並結合具體的技術選型與需求場景，給出了我個人對大數據平台的理解。

作者：張逸

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

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

大數據平台的核心功能

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

• 數據採集
• 數據存儲
• 數據處理

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

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

數據源的特點

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

來源

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

企業的內部數據通常與具體業務緊密相關，且多數來自我們可以掌控（或者通過兄弟團隊）的軟件系統，如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架構。

End.

轉貼自： 36大數據