我在一次社區活動中做過一次分享，演講題目為《大數據平臺架構技術選型與場景運用》。在演講中，我主要分析了大數據平臺架構的生態環境，并主要以數據源、數據采集、數據存儲與數據處理四個方面展開分析與講解，并結合具體的技術選型與需求場景，給出了我個人對大數據平臺的理解。本文講解數據采集部分。
數據采集的設計，幾乎完全取決于數據源的特性，畢竟數據源是整個大數據平臺蓄水的上游，數據采集不過是獲取水源的管道罷了。
在數據倉庫的語境下，ETL基本上就是數據采集的代表，包括數據的提取（Extract)、轉換(Transform)和加載(Load)。在轉換的過程中，需要針對具體的業務場景對數據進行治理，例如進行非法數據監測與過濾、格式轉換與數據規范化、數據替換、保證數據完整性等。
但是在大數據平臺下，由于數據源具有更復雜的多樣性，數據采集的形式也變得更加復雜而多樣，當然，業務場景也可能變得迥然不同。下圖展現了大數據平臺比較典型的數據采集架構：

以下是幾種比較典型的業務場景。
場景1：為了提升業務處理的性能，同時又希望保留歷史數據以備數據挖掘與分析。
業務處理場景訪問的數據庫往往是RDB，可伸縮性較差，又需要滿足查詢與其他數據操作的實時性，這就需要定期將超過時間期限的歷史數據執行清除。但是在大數據場景下，這些看似無用的歷史數據又可能是能夠煉成黃金的沙礫。因而需要實時將RDB的數據同步到HDFS中，讓HDFS成為備份了完整數據的冗余存儲。在這種場景下，數據采集就僅僅是一個簡單的同步，無需執行轉換。
場景2：數據源已經寫入Kafka，需要實時采集數據
在考慮流處理的業務場景，數據采集會成為Kafka的消費者，就像一個水壩一般將上游源源不斷的數據攔截住，然后根據業務場景做對應的處理（例如去重、去噪、中間計算等），之后再寫入到對應的數據存儲中。這個過程類似傳統的ETL，但它是流式的處理方式，而非定時的批處理Job。
場景3：數據源為視頻文件，需提取特征數據
針對視頻文件的大數據處理，需要在Extract階段加載圖片后，然后根據某種識別算法，識別并提取圖片的特征信息，并將其轉換為業務場景需要的數據模型。在這個場景下，數據提取的耗時相對較長，也需要較多的內存資源。如果處理不當，可能會成為整個數據階段的瓶頸。
在數據采集階段，一個棘手問題是增量同步，尤其針對那種可變（即可刪除、可修改）的數據源。在我們無法掌控數據源的情況下，通常我們會有三種選擇：
- 放棄同步，采用直連形式；
- 放棄增量同步，選用全量同步；
- 編寫定期Job，掃描數據源以獲得delta數據，然后針對delta數據進行增量同步
坦白說，這三種選擇皆非最佳選擇，但我也未嘗發現有更好的方案。如果數據源端可以控制，我們當然也可以偵聽數據源的變更，然后執行Job來更新采集后存儲的數據。這些又可能牽涉到數據存儲的選型，假設我們選擇了Parquet格式作為數據存儲，則Parquet是不允許變更的。若要應對這種場景，或許應該考慮ORC格式。
為了更高效地完成數據采集，通常我們需要將整個流程切分成多個階段，在細分的階段中可以采用并行執行的方式。在這個過程中，可能牽涉到Job的創建、提交與分發，采集流程的規劃，數據格式的轉換等。除此之外，在保證數據采集的高性能之外，還要考慮數據丟失的容錯。
文章列表
留言列表
