本文來源於公衆號【胖滾豬學編程】,轉載請註明出處!前端
關於數據中臺的概念和架構,咱們在大白話 六問數據中臺和數據中臺全景架構及模塊解析!一文入門中臺架構師!兩篇文章中都說明白了。從這一篇文章開始分享中臺落地實戰。mysql
其實不管是數據中臺仍是數據平臺,數據無疑都是核心中的核心,因此閉着眼睛想都知道數據匯聚是數據中臺/平臺的入口。縱觀衆多中臺架構圖,數據採集與匯聚都是打頭陣的:git
本文將從如下幾個方面分享數據採集的方方面面:github
1、企業數據來源
2、數據採集概念和價值
3、數據採集經常使用工具
4、數據採集系統設計原則
5、數據採集模塊生產落地分享redis
有來源才能談採集,所以咱們先來概括下企業中數據來源。sql
企業中的數據來源極其多,但大都都離不開這幾個方面:數據庫,日誌,前端埋點,爬蟲系統等。shell
數據庫咱們不用多說,例如一般用mysql做爲業務庫,存儲業務一些關鍵指標,好比用戶信息、訂單信息。也會用到一些Nosql數據庫,通常用於存儲一些不那麼重要的數據。數據庫
日誌也是重要數據來源,由於日誌記錄了程序各類執行狀況,其中也包括用戶的業務處理軌跡,根據日誌咱們能夠分析出程序的異常狀況,也能夠統計關鍵業務指標好比PV,UV。編程
前端埋點一樣是很是重要的來源,用戶不少前端請求並不會產生後端請求,好比點擊,但這些對分析用戶行爲具備重要的價值,例如分析用戶流失率,是在哪一個界面,哪一個環節用戶流失了,這都要靠埋點數據。後端
爬蟲系統你們應該也不陌生了,雖然如今不少企業都聲明禁止爬蟲,但每每禁止爬取的數據纔是有價值的數據,有些管理和決策就是須要競爭對手的數據做爲對比,而這些數據就能夠經過爬蟲獲取。
剛剛說了這麼多數據,但是它們分散在不一樣的網絡環境和存儲平臺中,另外不一樣的項目組可能還要重複去收集一樣的數據,所以數據難以利用,難以複用、難以產生價值。數據匯聚就是使得各類異構網絡、異構數據源的數據,方便統一採集到數據中臺進行集中存儲,爲後續的加工建模作準備。
數據匯聚能夠是實時接入,好比Flume實時採集日誌,好比Canal實時採集mysql的binlog。
也能夠是離線同步,好比使用sqoop離線同步mysql數據到hive,使用DataX將mongo數據同步到hive。
數據採集經常使用框架有Flume、Sqoop、LogStash、DataX、Canal,還有一些不算很主流但一樣能夠考慮的工具如WaterDrop、MaxWell。這些工具的使用都很是簡單,學習成本較低。只不過實際使用中可能會有一些細節問題。可是整體來講難度不大。
因此重點仍是應該瞭解每種工具的適用範圍和優缺點。而後想清楚本身的需求是什麼,實時仍是離線?從哪一種數據源同步到哪裏?須要通過怎麼樣的處理?
Flume是一個分佈式、可靠、和高可用的海量日誌採集、聚合和傳輸的系統。
Flume能夠採集文件,socket數據包等各類形式源數據,又能夠將採集到的數據輸出到HDFS、hbase、hive、kafka等衆多外部存儲系統中。
Logstash 即大名鼎鼎的ELK中的L。Logstash最經常使用於ELK(elasticsearch + logstash + kibane)中做爲日誌收集器使用
Logstash主要組成以下:
Sqoop主要用於在Hadoop(HDFS、Hive、HBase)與傳統的數據庫(mysql、postgresql…)間進行數據的傳遞,能夠將一個關係型數據庫中的數據導進到Hadoop的HDFS中,也能夠將HDFS的數據導進到關係型數據庫中。
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 主要用途是基於 MySQL 數據庫增量日誌解析,提供增量數據訂閱和消費
怎麼用呢?啓動canal-server 連上MySQL,再使用canal-client鏈接canal-server接收數據變動消息,拿到對應表和變動數據以後自行觸發對應業務邏輯。更通用的是使用canal把數據變動直接投遞到消息隊列,使用消息隊列消費者來處理邏輯,另外還支持canal落地到ES等地方。圖中已經很詳細了!
因爲篇幅問題,本文不對這些工具作詳細對比,想知道它們的優缺點嗎?想知道該如何選型嗎?去公衆號【胖滾豬學編程】找答案吧!
採集以後必然須要將數據落地,即存儲層,常見的有:
學習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實時計算平臺,具備以下特性:
在設計原則上,也充分考慮了擴展性、易用性,source、process、sink\dim(維表)均爲插件化開發,方面後續擴展,界面化配置,自動生成DAG圖,使得不懂技術的人也能夠很快上手進行流計算任務開發:
因爲篇幅問題,細節問題不能一一說清,本人將在公衆號【胖滾豬學編程】持續分享,歡迎關注。
本文來源於公衆號【胖滾豬學編程】一個集顏值與才華於一身的女程序媛。以漫畫形式讓編程so easy and interesting。