基于云原生的作業幫大數據采集體系建設與遷移實踐-伍思磊.pdf

《基于云原生的作業幫大數據采集體系建設與遷移實踐-伍思磊.pdf》由會員分享，可在線閱讀，更多相關《基于云原生的作業幫大數據采集體系建設與遷移實踐-伍思磊.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

1、基于云原生的作業幫大數據采集體系建設與遷移實踐伍思磊作業幫大數據中臺架構師一.背景二.作業幫數據采集體系的架構升級三.作業幫數據采集體系的遷移實踐 1.數據庫采集：從 Canal 到 Flink-CDC 2.日志采集：從虛擬機到容器化四.未來規劃一.背景背景/關于作業幫作業幫是一家什么樣的公司？背景/作業幫大數據中臺全景二.作業幫數據采集體系的架構升級架構升級/大數據采集架構演進的三個階段架構升級/采集2.0時代面臨的問題痛點1:新數據源難以擴展痛點2:采集組件虛機部署人肉運維穩定性差痛點3:入倉需求定制化：表級/點位級kafka分發、實時流done標記、離線數據漂移、特殊任務調優.痛點4:M

2、R任務缺乏物理隔離各BU爭搶資源數據時效性差架構升級/診斷思路與架構升級目標企業訴求業務場景需求本質架構目標支撐經營分析決策低成本數據安全工作臺工作臺實時/小時級數據在線系統，需求穩健迭代業務業務分析挖掘分析挖掘T+1數據深度洞察、查數廣泛、需求靈活管理者駕駛艙管理者駕駛艙T+N數據、大盤趨勢歷史數據、可視化、需求固化企業成本管理企業成本管理審計活動審計活動/法律法律合規合規面向核心經營活動實時OLAP,小時增量切塊數據系統高可用、準確業務試錯、需求挖掘T+1快照,天/小時增量切塊數據源多樣性、SQL易編寫經營決策T+1快照、數據產出穩定歷史快照保留、反復分析數據復用、避免煙囪用戶個人信息數據

3、脫敏 降低資源顆粒度、彈性擴縮大數據采集的架構升級/作業幫采集場景的需求本質抽象架構升級/采集架構3.0升級思路:采集鏈路視角架構升級/采集架構3.0升級思路:SAAS化產品視角三.作業幫數據采集體系的遷移實踐數據庫采集：從 Canal 到 Flink-CDC遷移實踐/關于Canal1.僅支持mysql，無法擴展其他數據源2.不支持全量CDC,入倉鏈路割裂3.基于云下的VM部署:機器粒度HA,人工運維成本高資源利用率低，預算成本居高不下實例數(mysql集群):300+接入表數量:含分表:十萬級 分表合并:萬級峰值QPS:200,000+均值QPS:50,000+日增量binlog大小:10T

4、+CanalCanal是優秀的解決方案是優秀的解決方案,但仍存在痛點但仍存在痛點數據庫入倉規模數據庫入倉規模作業幫在采集作業幫在采集2.02.0階段的解決方案階段的解決方案CanalCanal +Canal-AdminCanal-Admin增量采集HA+平臺化遷移實踐/CDC方案調研選型CDC機制日志+查詢(部分無鎖)日志+查詢日志+查詢(有鎖)日志數據源支持(僅對比作業幫需求)MySQLMongoDBPostgreSQL(Polardb-O)TiDBMySQLMongoDBPostgreSQLMySQL,MongoDB,PostgreSQL國外產品,部分數據源用不到MySQL底層機制Flin

5、k+DebeziumDebezium+KafkaDebezium自研內核同步方式增量/全量/增量+全量增量/全量/增量+全量增量/全量/增量+全量增量部署架構EMR基于作業幫Zlink平臺部署SAAS單機VM+分布式產品化自建廠商平臺自建Canal Admin定制化基于Flink自定制較困難基于Java自定制基于Client二開監控告警自建廠商提供自建自建SLA保證自建99.999%自建自建SQL支持支持支持否否遷移實踐/Flink-CDC對各類數據源的特性支持增量快照(無鎖/并發/續傳)支持支持不支持不支持啟動模式initital/latest/earliest/gtids/binlog f

6、ile+offset/timestampinitital/latestinitital/latestinitital/latest多庫多表捕獲支持支持支持支持動態加表僅支持Initial模式且會阻塞不支持不支持不支持獲取binlog時間戳支持支持支持支持獲取主鍵支持支持支持支持捕獲DDL支持支持支持支持數據類型支持全部支持但個別字段不完善(如enum)部分不支持部分不支持部分不支持Flink-CDC版本:2.3.0遷移實踐/CDC架構設計思路遷移實踐/CDC遷移場景與挑戰1.如何確保Canal和Flink-CDC的輸出在量級和數據上完全相同?2.如何盡量無縫、不丟數據地將任務平滑切換到CDC?

7、技術挑戰：遷移實踐/CanalCDC 遷移方案設計思路遷移實踐/CDC輕量化、整庫同步的落地現狀與挑戰MySQLTableTableTable基于CDC的數據異構目標數倉TableTableTable1.輕量化全量同步后自動切換增量3.DDL同步源表Schema變化自動同步到下游數倉2.動態加表整庫CDC任務動態新增表并從CK恢復輕量化的問題：整庫任務從Canal基于gtids遷移到CDC后，無法切換到initial模式動態加表的問題：整庫任務只能基于initial模式做動態加表,且加表時會阻塞其他增量表DDL同步的問題：1.需要上游數據源來約束schema變化2.下游用戶接受度不高，更期望能

8、用工單手動控制數倉schema現狀:社區暫未支持目前作業幫正在自研解決現狀:社區在master解決,預計2.4發布目前作業幫正在試用驗證現狀:在作業幫內部不算剛需沿用入倉工單維護schema變更遷移實踐/性能摸底:Canal VS CDC 增量消費CanalFlink-CDC峰值QPS:13000峰值QPS:19000(+32%+32%)Canal版本:1.1.3啟動方式：binlog-ealriest虛擬機規格：96C/384G工作線程：64Kafka分區數：6Flink-CDC版本:2.3.0啟動方式：binlog-ealriestTM內存：6144 MB并發/Slot：6Kafka分區數

9、：6由于Canal在后續版本中做了性能優化，因此該測試只能供參考：僅說明在作業幫場景下,Flink-CDC(2.3.0)性能優于Canal(1.1.3)遷移實踐/作業幫CDC遷移收益總結成本成本性能性能功能功能CanalZ-CDC資源核數消耗減少67%CanalZ-CDC消費性能增加32%三.作業幫數據采集體系的遷移實踐日志采集：從虛擬機到容器化遷移實踐/作業幫日志采集規模1000+接入接入日志源日志源百億條百億條每天每天日志日志量級量級百萬百萬+每秒每秒峰值峰值CPSCPS數百數百+GbpsGbps峰值峰值帶寬帶寬遷移實踐/基于虛擬機的日志采集：架構概覽遷移實踐/基于虛擬機的日志采集：痛點分

10、析1.流量網關使用虛擬機部署，運維成本繁重2.后端服務陸續容器化上云，現有Flume采集接入體系難以滿足done標記需求3.建設多個外圍服務來進行flume管理、done標記管理，維護成本大，穩定性差虛擬機架構下的痛點：流量網關如何上云？在k8s下,done標記需求如何支持?技術挑戰：Tips:以采集時間為準,當某個區間(如13-14點)的數據都處理完畢后，再讓數據向下游可見遷移實踐/流量網關上云思路遷移實踐/基于k8s日志采集的done標記實現思路遷移實踐/流量網關上云遷移方案遷移實踐/作業幫日志采集遷移收益虛擬機容器化成本成本根據流量潮汐按時間段動態擴縮POD資源核數消耗減少54%運維運維3人力0.5人力K8S化,不再專人維護VM集群和Agent公司OP團隊提供統一運維虛擬機容器化四.未來規劃未來規劃123CDC輕量化、整庫同步等特性的優雅落地接入能力進一步抽象，低成本接入更多新數據源可觀測性進一步增強，入倉全鏈路感知管控