本文來源于公衆号【胖滾豬學程式設計】，轉載請注明出處！
關于資料中台的概念和架構，我們在
大白話 六問資料中台和
資料中台全景架構及子產品解析！一文入門中台架構師！兩篇文章中都說明白了。從這一篇文章開始分享中台落地實戰。
其實無論是資料中台還是資料平台，資料無疑都是核心中的核心，是以閉着眼睛想都知道資料彙聚是資料中台/平台的入口。縱觀衆多中台架構圖，資料采集與彙聚都是打頭陣的：
本文将從以下幾個方面分享資料采集的方方面面：
一、企業資料來源
二、資料采集概念和價值
三、資料采集常用工具
四、資料采集系統設計原則
五、資料采集子產品生産落地分享
有來源才能談采集，是以我們先來歸納下企業中資料來源。
資料來源
企業中的資料來源極其多，但大都都離不開這幾個方面：資料庫，日志，前端埋點，爬蟲系統等。
- 資料庫我們不用多說，例如通常用mysql作為業務庫，存儲業務一些關鍵名額，比如使用者資訊、訂單資訊。也會用到一些Nosql資料庫，一般用于存儲一些不那麼重要的資料。
- 日志也是重要資料來源，因為日志記錄了程式各種執行情況，其中也包括使用者的業務處理軌迹，根據日志我們可以分析出程式的異常情況，也可以統計關鍵業務名額比如PV,UV。
- 前端埋點同樣是非常重要的來源，使用者很多前端請求并不會産生後端請求，比如點選，但這些對分析使用者行為具有重要的價值，例如分析使用者流失率，是在哪個界面，哪個環節使用者流失了，這都要靠埋點資料。
- 爬蟲系統大家應該也不陌生了，雖然現在很多企業都聲明禁止爬蟲，但往往禁止爬取的資料才是有價值的資料，有些管理和決策就是需要競争對手的資料作為對比，而這些資料就可以通過爬蟲擷取。
資料采集與抽取
剛剛說了這麼多資料，可是它們分散在不同的網絡環境和存儲平台中，另外不同的項目組可能還要重複去收集同樣的資料，是以資料難以利用，難以複用、難以産生價值。資料彙聚就是使得各種異構網絡、異構資料源的資料，友善統一采集到資料中台進行集中存儲，為後續的加工模組化做準備。
- 資料彙聚可以是實時接入，比如Flume實時采集日志，比如Canal實時采集mysql的binlog。
- 也可以是離線同步，比如使用sqoop離線同步mysql資料到hive，使用DataX将mongo資料同步到hive。
技術選型
資料采集常用架構有Flume、Sqoop、LogStash、DataX、Canal，還有一些不算很主流但同樣可以考慮的工具如WaterDrop、MaxWell。這些工具的使用都非常簡單，學習成本較低。隻不過實際使用中可能會有一些細節問題。但是總體來說難度不大。
是以重點還是應該了解每種工具的适用範圍和優缺點。然後想清楚自己的需求是什麼，實時還是離線？從哪種資料源同步到哪裡？需要經過怎麼樣的處理？
Flume
Flume是一個分布式、可靠、和高可用的海量日志采集、聚合和傳輸的系統。
Flume可以采集檔案，socket資料包等各種形式源資料，又可以将采集到的資料輸出到HDFS、hbase、hive、kafka等衆多外部存儲系統中。
Logstash
Logstash 即大名鼎鼎的ELK中的L。Logstash最常用于ELK（elasticsearch + logstash + kibane）中作為日志收集器使用
Logstash主要組成如下：
- inpust：必須，負責産生事件（Inputs generate events），常用：File、syslog、redis、beats（如：Filebeats）
- filters：可選，負責資料處理與轉換（filters modify them），常用：grok、mutate、drop、clone、geoip
- outpus：必須，負責資料輸出（outputs ship them elsewhere），常用：elasticsearch、file、graphite、statsd
Sqoop
Sqoop主要用于在Hadoop(HDFS、Hive、HBase)與傳統的資料庫(mysql、postgresql…)間進行資料的傳遞，可以将一個關系型資料庫中的資料導進到Hadoop的HDFS中，也可以将HDFS的資料導進到關系型資料庫中。
Datax
DataX 是阿裡巴巴集團内被廣泛使用的離線資料同步工具/平台，實作包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構資料源之間高效的資料同步功能。
所支援的資料源如下，也可自行開發插件：
| 類型 | 資料源 | Reader(讀) | Writer(寫) | 文檔 |
|---|---|---|---|---|
| RDBMS 關系型資料庫 | MySQL | √ | 讀 、 寫 | |
| Oracle | √ | |||
| SQLServer | ||||
| PostgreSQL | ||||
| DRDS | ||||
| 通用RDBMS(支援所有關系型資料庫) | ||||
| NoSQL資料存儲 | OTS | |||
| Hbase0.94 | ||||
| Hbase1.1 | ||||
| Phoenix4.x | ||||
| Phoenix5.x | ||||
| MongoDB | ||||
| Hive | ||||
| Cassandra | ||||
| 無結構化資料存儲 | TxtFile | |||
| FTP | ||||
| HDFS | ||||
| Elasticsearch | ||||
| 時間序列資料庫 | OpenTSDB | |||
| TSDB |
Canal
canal 主要用途是基于 MySQL 資料庫增量日志解析，提供增量資料訂閱和消費
怎麼用呢？啟動canal-server 連上MySQL，再使用canal-client連接配接canal-server接收資料變更消息，拿到對應表和變更資料之後自行觸發對應業務邏輯。更通用的是使用canal把資料變更直接投遞到消息隊列，使用消息隊列消費者來處理邏輯，另外還支援canal落地到ES等地方。圖中已經很詳細了！
由于篇幅問題，本文不對這些工具做詳細對比，想知道它們的優缺點嗎?想知道該如何選型嗎？去公衆号【胖滾豬學程式設計】找答案吧！
資料落地
采集之後必然需要将資料落地，即存儲層，常見的有：
- MYSQL、Oracle
- Hive、Hdfs
- HBase
- Redis
- ElasticSearch
- Tidb
- Mongo
學習Hive、HBase、ElasticSearch、Redis、請關注公衆号【胖滾豬學程式設計】吧！
需要說明的是，資料采集之後往往會先發送給Kafka這種消息隊列，然後才真正落地到各種存儲層中。
資料彙聚設計原則
從中台的角度來考慮，筆者認為，資料彙聚層的設計需要考慮幾個關鍵的因素:
- 設計之初就應該考慮支援各類資料源 ，支援不同來源、不同類型的資料源。資料彙聚層不是為某一種資料而生的，應該做到通用化。
- 需要支援不同時間視窗的資料采集，實時的、非實時的、曆史的。
- 操作友好簡單，即使是不懂技術的人，也可以友善的操作，進行資料同步；舉例mysql同步到hive，你不應該讓使用者去填寫複雜的sqoop任務參數，而是隻需要選擇源表和目的表，其他事情都交給中台去完成。
- 合理選擇存儲層，不同資料源應存儲在不同的地方，比如日志資料肯定不适合mysql。
生産落地分享
筆者馬上要開始分享公司真實落地案例了！網上文章千篇一律，極少數會有實戰落地分享！也歡迎各位大佬指教！
首先剛剛說到設計原則，應該考慮支援各類資料源 各類落地，應該分别考慮離線和實時采集、應該要操作友好簡單，不懂技術也可操作。我們整體的設計也是以這幾個原則作為指導的。想分别從離線和實時采集方面介紹一下公司落地方案：
離線采集
離線同步方面、在我司主要是會采集抽取如下圖所示的幾個資料源資料，最終落地到HIVE或者TIDB，落地到HIVE的作用我就不多說了，大家都比較熟悉。而落地到TIDB主要是支援實時查詢、實時業務分析以及各類定時跑批報表。
下面通過mysql自助化同步到hive為例，分享自助化離線資料采集子產品的系統設計。
首先通過資料中台源資料管理子產品，将資料源的資訊一一展示出來，使用者按需勾選同步：
同步支援全量同步以及增量同步，支援附加配置，比如脫敏、加密、解密等。由于需要規範數倉表名、是以目的表名由系統自動生成，比如mysql同步到hive統一字首ods_（後續在數倉規範中會詳細說明，敬請關注公衆号【胖滾豬學程式設計】）
使用者點選确認同步之後，首先會經過中繼資料管理系統，從中繼資料管理系統中查詢出同步任務所需要的元資訊(包括ip，端口，賬戶密碼，列資訊)，組裝成sqoop參數，将同步資訊(包括申請人、申請理由、同步參數等資訊)記錄到mysql表中。然後調用工單系統經過上級上司稽核。
工單系統稽核後發消息給到mq，通過mq可實時擷取到工單稽核狀态，如果稽核通過，則在排程系統（基于EasyScheduler）自動生成任務，早期我司選擇Azkaban，後來發現EasyScheduler多方面都完勝Azkaban，尤其在易用性、UI、監控方面。
從圖中可知mysql同步到hive涉及三個流程節點，以user表增量同步為例，第一步是通過sqoop任務将mysql資料同步到hive的ods_user_tmp表，第二步是将ods_user_tmp的資料merge到ods_user中（覆寫原有分區）,第三步是做資料檢驗。
除了mysql同步到hive，其他資料源的同步也大同小異，關鍵是定義好流程模闆(通常是shell腳本)和流程依賴，然後利用排程系統進行排程。
實時采集
實時采集子產品，我司是基于Flink實時計算平台，具有如下特性：
- 支援多種資料源：Kafka、RocketMq、Hive等
- 支援多種落地：Kafka、JDBC、HDFS、ElasticSearch、RocketMq、HIVE等
- 通用sql處理：資料處理直接配置一條sql即可
- 告警政策：支援多種告警政策，如流計算堆積batch的監測、應用的啟動退出等。
在設計原則上，也充分考慮了擴充性、易用性，source、process、sinkdim(維表)均為插件化開發，方面後續擴充，界面化配置，自動生成DAG圖，使得不懂技術的人也可以很快上手進行流計算任務開發：
由于篇幅問題，細節問題不能一一說清，本人将在公衆号【胖滾豬學程式設計】持續分享，歡迎關注。