我在一次社區(qū)活動中做過一次分享，演講題目為《大數(shù)據(jù)平臺架構(gòu)技術(shù)選型與場景運用》。在演講中，我主要分析了大數(shù)據(jù)平臺架構(gòu)的生態(tài)環(huán)境，并主要以數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)存儲與數(shù)據(jù)處理四個方面展開分析與講解，并結(jié)合具體的技術(shù)選型與需求場景，給出了我個人對大數(shù)據(jù)平臺的理解。本文是演講內(nèi)容的***部分。

大數(shù)據(jù)平臺是一個整體的生態(tài)系統(tǒng)，內(nèi)容涵蓋非常豐富，涉及到大數(shù)據(jù)處理過程的諸多技術(shù)。在這些技術(shù)中，除了一些最基礎(chǔ)的平臺框架之外，針對不同的需求場景，也有不同的技術(shù)選擇。這其中，顯然有共性與差異性的特征。若從整個開發(fā)生命周期的角度看，無論是需求、架構(gòu)，還是開發(fā)、測試到***的部署與運維，各種技術(shù)都會牽扯其中，不同的角色關(guān)注點自然也有不同。

大數(shù)據(jù)平臺的核心功能

從大數(shù)據(jù)平臺工程師的角度看，決定整個大數(shù)據(jù)平臺關(guān)鍵質(zhì)量的不外三方面：

• 數(shù)據(jù)采集
• 數(shù)據(jù)存儲
• 數(shù)據(jù)處理

至于系統(tǒng)監(jiān)控、資源協(xié)調(diào)、部署運維及其他管理功能都是大數(shù)據(jù)平臺整個生態(tài)環(huán)境中不可缺少的拼圖，但對于面向數(shù)據(jù)的架構(gòu)，核心還是與數(shù)據(jù)打交道的一部分。如下圖所示：

根據(jù)我在大數(shù)據(jù)項目中的經(jīng)驗，我發(fā)現(xiàn)，無論是數(shù)據(jù)采集、存儲還是分析，在技術(shù)選型與方案設(shè)計上，似乎又與數(shù)據(jù)源的特征息息相關(guān)，甚至在某種程度上，可以認(rèn)為是數(shù)據(jù)源的特點決定了整個大數(shù)據(jù)平臺架構(gòu)的設(shè)計。

數(shù)據(jù)源的特點

于是，我將關(guān)注點首要放在了數(shù)據(jù)源上。分析數(shù)據(jù)源的數(shù)據(jù)特征，我從四個不同的維度對數(shù)據(jù)源進(jìn)行了分類：

來源

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

企業(yè)的內(nèi)部數(shù)據(jù)通常與具體業(yè)務(wù)緊密相關(guān)，且多數(shù)來自我們可以掌控(或者通過兄弟團(tuán)隊)的軟件系統(tǒng)，如CRM、ERP或者HR系統(tǒng)。從企業(yè)架構(gòu)的角度考慮，我們本身就應(yīng)該避免企業(yè)系統(tǒng)出現(xiàn)所謂的“煙囪系統(tǒng)”，規(guī)避“信息孤島”。設(shè)計良好的系統(tǒng)應(yīng)該要提供相關(guān)的接口允許其他系統(tǒng)有限度地訪問該系統(tǒng)的內(nèi)部數(shù)據(jù)，又或者主動地將內(nèi)部數(shù)據(jù)寫入到一個完全解耦合的系統(tǒng)中。例如，一個常見的做法是將內(nèi)部系統(tǒng)實時產(chǎn)生的輸入寫入到Kafka中。

通常，我們會盡量避免直接將內(nèi)部系統(tǒng)的數(shù)據(jù)庫公開給大數(shù)據(jù)平臺。因為這種方式不僅會帶來潛在的安全威脅，還可能會因為資源占用的緣故影響到業(yè)務(wù)系統(tǒng)。

外部數(shù)據(jù)的獲取方式不外乎兩種：

• API調(diào)用
• 通過網(wǎng)絡(luò)爬蟲抓取

與內(nèi)部數(shù)據(jù)不同，外部數(shù)據(jù)不可能聽指揮地“召之即來揮之即去”，我們需要定期或不定期地去獲取數(shù)據(jù)，好處是我們可以根據(jù)業(yè)務(wù)場景和數(shù)據(jù)的特點自主地選擇數(shù)據(jù)存儲。

結(jié)構(gòu)

只要了解過大數(shù)據(jù)項目，都知道數(shù)據(jù)結(jié)構(gòu)直接影響了存儲與處理技術(shù)的選擇。RDB之于結(jié)構(gòu)型數(shù)據(jù)，NoSQL之于非結(jié)構(gòu)數(shù)據(jù)，這是司空見慣的配對了。相當(dāng)而言，RDB的選擇比較簡單，NoSQL則有更復(fù)雜的分類。Pramod J·Sadalage與Martin Fowler在NoSQL Distilled一書中將NoSQL分為四類：

• 鍵值數(shù)據(jù)庫
• 文檔數(shù)據(jù)庫
• 列族數(shù)據(jù)庫
• 圖數(shù)據(jù)庫

針對不同結(jié)構(gòu)類型的數(shù)據(jù)，我們將這一分類作為選型的參考。

可變性

Datomic數(shù)據(jù)庫的設(shè)計哲學(xué)是將所有過去發(fā)生的事情(或事件)認(rèn)為是一個“fact(事實)”，基于事實不能篡改的本質(zhì)，則數(shù)據(jù)庫中存儲的數(shù)據(jù)也當(dāng)是不變的。無論是添加、刪除還是修改，在數(shù)據(jù)庫層面都是增加一條記錄。

然而，多數(shù)數(shù)據(jù)庫并未添加這種不變性的約束，雖然這種不變性帶來的好處是明顯的，不過也會給業(yè)務(wù)系統(tǒng)的設(shè)計與實現(xiàn)帶來不必要的復(fù)雜度。然而，作為大數(shù)據(jù)平臺的數(shù)據(jù)源而言，情況則相反，若數(shù)據(jù)允許更改，數(shù)據(jù)采集過程就會變得更復(fù)雜。

一種簡單的應(yīng)對辦法是采用直連的形式。由于數(shù)據(jù)分析可能會基于不同的數(shù)據(jù)場景對數(shù)據(jù)存儲提出不同的要求，直連的數(shù)據(jù)源未必滿足這種要求。例如，假設(shè)我們的分析場景是要做基于關(guān)鍵字的全文本搜索，在大數(shù)據(jù)量高性能的要求下，選擇ElasticSearch或者Solr會表現(xiàn)更好，若直連的數(shù)據(jù)源是MySQL，事情就會變得較為棘手。

數(shù)據(jù)量

數(shù)據(jù)量小，則一切都可迎刃而解，這里不再贅述。

針對大數(shù)據(jù)量，實則是兩個不同的場景。一種是批處理方式，典型地算法是MapReduce，主要針對非實時需求場景，我們可以編寫定期以及批量執(zhí)行的任務(wù)來完成數(shù)據(jù)的采集。需要費心的是對Job的監(jiān)控、管理與調(diào)度。另一種則是流處理方式，(準(zhǔn))實時對產(chǎn)生的數(shù)據(jù)進(jìn)行處理，這種場景對數(shù)據(jù)源的限制更多，最常見的方案就是將源源不斷產(chǎn)生的數(shù)據(jù)寫入到Kafka中。

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

• Batch Layer：針對批處理場景
• Speed Layer：針對流處理場景
• Serving Layer：由流處理場景提供實時數(shù)據(jù)模型，再對批處理的大數(shù)據(jù)進(jìn)行預(yù)計算，從而提供批處理數(shù)據(jù)模型(聚合計算后)，合并后提供給Serving Layer。

Lambda架構(gòu)圖如下所示：

OLAP分析平臺druid就采用了Lambda架構(gòu)。

【本文為51CTO專欄作者“張逸”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文