為你剖析大數(shù)據(jù)平臺(tái)的數(shù)據(jù)源

大數(shù)據(jù) 平臺(tái) 數(shù)據(jù)源

張逸 | 2017-06-23 09:48

【數(shù)據(jù)猿導(dǎo)讀】大數(shù)據(jù)平臺(tái)是一個(gè)整體的生態(tài)系統(tǒng)，內(nèi)容涵蓋非常豐富，涉及到大數(shù)據(jù)處理過程的諸多技術(shù)。在這些技術(shù)中，除了一些最基礎(chǔ)的平臺(tái)框架之外，針對(duì)不同的需求場景，也有不同的技術(shù)選擇。

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

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

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

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

數(shù)據(jù)采集

數(shù)據(jù)存儲(chǔ)

數(shù)據(jù)處理

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

大數(shù)據(jù)_平臺(tái)_數(shù)據(jù)源-1

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

數(shù)據(jù)源的特點(diǎn)

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

大數(shù)據(jù)_平臺(tái)_數(shù)據(jù)源-2

來源

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

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

通常，我們會(huì)盡量避免直接將內(nèi)部系統(tǒng)的數(shù)據(jù)庫公開給大數(shù)據(jù)平臺(tái)。因?yàn)檫@種方式不僅會(huì)帶來潛在的安全威脅，還可能會(huì)因?yàn)橘Y源占用的緣故影響到業(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ù)的特點(diǎn)自主地選擇數(shù)據(jù)存儲(chǔ)。

結(jié)構(gòu)

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

鍵值數(shù)據(jù)庫

文檔數(shù)據(jù)庫

列族數(shù)據(jù)庫

圖數(shù)據(jù)庫

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

可變性

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

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

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

數(shù)據(jù)量

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

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

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

Batch Layer：針對(duì)批處理場景

Speed Layer：針對(duì)流處理場景

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

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

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

來源：36大數(shù)據(jù)

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會(huì)注明來源與作者；轉(zhuǎn)載我們?cè)瓌?chuàng)內(nèi)容時(shí)，也請(qǐng)務(wù)必注明“來源：數(shù)據(jù)猿”與作者名稱，否則將會(huì)受到數(shù)據(jù)猿追責(zé)。