如何更好地剖析大數(shù)據(jù)平臺(tái)的數(shù)據(jù)采集

剖析大數(shù)據(jù) 采集

張逸 | 2017-06-22 11:39

【數(shù)據(jù)猿導(dǎo)讀】為了更高效地完成數(shù)據(jù)采集，通常我們需要將整個(gè)流程切分成多個(gè)階段，在細(xì)分的階段中可以采用并行執(zhí)行的方式。

如何更好地剖析大數(shù)據(jù)平臺(tái)的數(shù)據(jù)采集

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

數(shù)據(jù)采集的設(shè)計(jì)，幾乎完全取決于數(shù)據(jù)源的特性，畢竟數(shù)據(jù)源是整個(gè)大數(shù)據(jù)平臺(tái)蓄水的上游，數(shù)據(jù)采集不過是獲取水源的管道罷了。

在數(shù)據(jù)倉(cāng)庫(kù)的語(yǔ)境下，ETL基本上就是數(shù)據(jù)采集的代表，包括數(shù)據(jù)的提取(Extract)、轉(zhuǎn)換(Transform)和加載(Load)。在轉(zhuǎn)換的過程中，需要針對(duì)具體的業(yè)務(wù)場(chǎng)景對(duì)數(shù)據(jù)進(jìn)行治理，例如進(jìn)行非法數(shù)據(jù)監(jiān)測(cè)與過濾、格式轉(zhuǎn)換與數(shù)據(jù)規(guī)范化、數(shù)據(jù)替換、保證數(shù)據(jù)完整性等。

但是在大數(shù)據(jù)平臺(tái)下，由于數(shù)據(jù)源具有更復(fù)雜的多樣性，數(shù)據(jù)采集的形式也變得更加復(fù)雜而多樣，當(dāng)然，業(yè)務(wù)場(chǎng)景也可能變得迥然不同。下圖展現(xiàn)了大數(shù)據(jù)平臺(tái)比較典型的數(shù)據(jù)采集架構(gòu)：

剖析_大數(shù)據(jù)_采集-1

以下是幾種比較典型的業(yè)務(wù)場(chǎng)景。

場(chǎng)景1：為了提升業(yè)務(wù)處理的性能，同時(shí)又希望保留歷史數(shù)據(jù)以備數(shù)據(jù)挖掘與分析。

業(yè)務(wù)處理場(chǎng)景訪問的數(shù)據(jù)庫(kù)往往是RDB，可伸縮性較差，又需要滿足查詢與其他數(shù)據(jù)操作的實(shí)時(shí)性，這就需要定期將超過時(shí)間期限的歷史數(shù)據(jù)執(zhí)行清除。但是在大數(shù)據(jù)場(chǎng)景下，這些看似無用的歷史數(shù)據(jù)又可能是能夠煉成黃金的沙礫。因而需要實(shí)時(shí)將RDB的數(shù)據(jù)同步到HDFS中，讓HDFS成為備份了完整數(shù)據(jù)的冗余存儲(chǔ)。在這種場(chǎng)景下，數(shù)據(jù)采集就僅僅是一個(gè)簡(jiǎn)單的同步，無需執(zhí)行轉(zhuǎn)換。

場(chǎng)景2：數(shù)據(jù)源已經(jīng)寫入Kafka，需要實(shí)時(shí)采集數(shù)據(jù)

在考慮流處理的業(yè)務(wù)場(chǎng)景，數(shù)據(jù)采集會(huì)成為Kafka的消費(fèi)者，就像一個(gè)水壩一般將上游源源不斷的數(shù)據(jù)攔截住，然后根據(jù)業(yè)務(wù)場(chǎng)景做對(duì)應(yīng)的處理(例如去重、去噪、中間計(jì)算等)，之后再寫入到對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)中。這個(gè)過程類似傳統(tǒng)的ETL，但它是流式的處理方式，而非定時(shí)的批處理Job。

場(chǎng)景3：數(shù)據(jù)源為視頻文件，需提取特征數(shù)據(jù)

針對(duì)視頻文件的大數(shù)據(jù)處理，需要在Extract階段加載圖片后，然后根據(jù)某種識(shí)別算法，識(shí)別并提取圖片的特征信息，并將其轉(zhuǎn)換為業(yè)務(wù)場(chǎng)景需要的數(shù)據(jù)模型。在這個(gè)場(chǎng)景下，數(shù)據(jù)提取的耗時(shí)相對(duì)較長(zhǎng)，也需要較多的內(nèi)存資源。如果處理不當(dāng)，可能會(huì)成為整個(gè)數(shù)據(jù)階段的瓶頸。

在數(shù)據(jù)采集階段，一個(gè)棘手問題是增量同步，尤其針對(duì)那種可變(即可刪除、可修改)的數(shù)據(jù)源。在我們無法掌控?cái)?shù)據(jù)源的情況下，通常我們會(huì)有三種選擇：

放棄同步，采用直連形式;

放棄增量同步，選用全量同步;

編寫定期Job，掃描數(shù)據(jù)源以獲得delta數(shù)據(jù)，然后針對(duì)delta數(shù)據(jù)進(jìn)行增量同步

坦白說，這三種選擇皆非最佳選擇，但我也未嘗發(fā)現(xiàn)有更好的方案。如果數(shù)據(jù)源端可以控制，我們當(dāng)然也可以偵聽數(shù)據(jù)源的變更，然后執(zhí)行Job來更新采集后存儲(chǔ)的數(shù)據(jù)。這些又可能牽涉到數(shù)據(jù)存儲(chǔ)的選型，假設(shè)我們選擇了Parquet格式作為數(shù)據(jù)存儲(chǔ)，則Parquet是不允許變更的。若要應(yīng)對(duì)這種場(chǎng)景，或許應(yīng)該考慮ORC格式。

為了更高效地完成數(shù)據(jù)采集，通常我們需要將整個(gè)流程切分成多個(gè)階段，在細(xì)分的階段中可以采用并行執(zhí)行的方式。在這個(gè)過程中，可能牽涉到Job的創(chuàng)建、提交與分發(fā)，采集流程的規(guī)劃，數(shù)據(jù)格式的轉(zhuǎn)換等。除此之外，在保證數(shù)據(jù)采集的高性能之外，還要考慮數(shù)據(jù)丟失的容錯(cuò)。

來源：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é)。