我在一次社群活動中做過一次分享，演講題目為《大資料平台架構技術選型與場景運用》。在演講中，我主要分析了大資料平台架構的生態環境，並主要以資料來源、資料採集、資料儲存與資料處理四個方面展開分析與講解，並結合具體的技術選型與需求場景，給出了我個人對大資料平台的理解。本文講解資料採集部分。資料採集的設計，幾乎完全取決於資料來源的特性，畢竟資料來源是整個大資料平台蓄水的上游，資料採集不過是獲取水源的管道罷了。
在資料倉儲的語境下，etl基本上就是資料採集的代表，包括資料的提取（extract)、轉換(transform)和載入(load)。在轉換的過程中，需要針對具體的業務場景對資料進行治理，例如進行非法資料監測與過濾、格式轉換與資料規範化、資料替換、保證資料完整性等。
但是在大資料平台下，由於資料來源具有更複雜的多樣性，資料採集的形式也變得更加複雜而多樣，當然，業務場景也可能變得迥然不同。下圖展現了大資料平台比較典型的資料採集架構：
以下是幾種比較典型的業務場景。
場景1：為了提公升業務處理的效能，同時又希望保留歷史資料以備資料探勘與分析。
業務處理場景訪問的資料庫往往是rdb，可伸縮性較差，又需要滿足查詢與其他資料操作的實時性，這就需要定期將超過時間期限的歷史資料執行清除。但是在大資料場景下，這些看似無用的歷史資料又可能是能夠煉成**的沙礫。因而需要實時將rdb的資料同步到hdfs中，讓hdfs成為備份了完整資料的冗餘儲存。在這種場景下，資料採集就僅僅是乙個簡單的同步，無需執行轉換。
場景2：資料來源已經寫入kafka，需要實時採集資料
在考慮流處理的業務場景，資料採集會成為kafka的消費者，就像乙個水壩一般將上游源源不斷的資料攔截住，然後根據業務場景做對應的處理（例如去重、去噪、中間計算等），之後再寫入到對應的資料儲存中。這個過程類似傳統的etl，但它是流式的處理方式，而非定時的批處理job。
在資料採集階段，乙個棘手問題是增量同步，尤其針對那種可變（即可刪除、可修改）的資料來源。在我們無法掌控資料來源的情況下，通常我們會有三種選擇：
坦白說，這三種選擇皆非最佳選擇，但我也未嘗發現有更好的方案。如果資料來源端可以控制，我們當然也可以偵聽資料來源的變更，然後執行job來更新採集後儲存的資料。這些又可能牽涉到資料儲存的選型，假設我們選擇了parquet格式作為資料儲存，則parquet是不允許變更的。若要應對這種場景，或許應該考慮orc格式。
為了更高效地完成資料採集，通常我們需要將整個流程切分成多個階段，在細分的階段中可以採用並行執行的方式。在這個過程中，可能牽涉到job的建立、提交與分發，採集流程的規劃，資料格式的轉換等。除此之外，在保證資料採集的高效能之外，還要考慮資料丟失的容錯。
大資料 資料採集平台之Scribe
apache flume 詳情請看文章 大資料 資料採集平台之apache flume fluentd 詳情請看文章 大資料 資料採集平台之fluentd logstash 詳情請看文章 大資料 資料採集平台之logstash apache chukwa 詳情請看文章 大資料 資料採集平台之apac...
剖析大資料平台的資料來源
我在一次社群活動中做過一次分享，演講題目為 大資料平台架構技術選型與場景運用 在演講中，我主要分析了大資料平台架構的生態環境，並主要以資料來源 資料採集 資料儲存與資料處理四個方面展開分析與講解，並結合具體的技術選型與需求場景，給出了我個人對大資料平台的理解。本文是演講內容的第一部分。大資料平台是乙...
大資料平台容量評估 大資料平台
系統概述 大資料應用支撐平台提供資料支撐服務，對外發布資料服務進行資料價值變現。包含資料採集 資料治理 資料交換 資料儲存 資料計算相關元件的搭建 驗證，並建立大資料倉儲。b 功能要求 2.資料治理，由於從資料採集工具採集過來的資料不具備統一的資料標準及資料格式，資料治理工具需要對到達的資料進行格式...