吳江-Flink在蔚來汽車的應用-修訂.pdf

1、吳江/蔚來大數據開發&Olap平臺 Tech LeadFlink在蔚來的應用實時計算在蔚來的發展歷程#1#1實時計算平臺#2#2實時看板#3#3CDP#4#4實時數倉#5#5其他應用場景#6#6#1實時計算在蔚來的發展歷程實時計算在蔚來的發展歷程正在進行實時計算平臺2.02021-01實時計算平臺1.02019-09引入Flink命令行方式提交和管理2018-05Spark streaming#2實時計算平臺實時計算平臺1.0YARN作業管理配置管理Metrics監控Flink版本管理集群資源管理告警提交運行停止恢復監控日志實時計算平臺1.0實時計算平臺2.0YARN作業管理配置管理Metri

2、cs監控Flink引擎版本管理集群資源管理告警開發測試提交運行停止恢復監控Flink SQL權限管理UDF管理日志空間管理資源管理調試#3實時看板實時看板的幾個難點數據延遲上報怎么處理數據延遲上報歷史和實時怎么統一流批一體多個維度值實時選擇維度實時選擇實時指標怎么驗證指標的驗證架構系統信息Mysql DorisDWS可加型指標推送離線數倉DWD實時指標展示推送指標(用于當天 聚合指標)Flink任務websocket拉取指標(用于歷史任意時間段聚合指標)前端報表后臺用戶ID管理(用于前端計算UV)歷史指標獲取歷史指標獲取UV指標實時計算實時數倉歷史指標展示實時UV統計維度值多選統計實時去重人數

3、UV一個用戶可能對應多個城市維度值可以多選維度值在看板前端可以隨時更改北京上海深圳實時UV統計維度值多選方案1在Flink狀態中存儲所有的user id和出現過的維度,并直接計算所有可能的維度組合的UV，并推送更新過的UV給前端缺點-維度爆炸-大部分計算都是無用的，浪費存儲和計算資源因為用戶選擇的維度組合只會是很少的一部分實時UV統計維度值多選方案2-在Flink中計算user id和對應的維度-后臺存儲每個維度值下的user id list-前端選擇維度后，只訂閱該維度下的user id增量更新-前端通過set存儲所有用戶id，實時計算變化的UV數架構user id計算訂閱用戶張三的前端報表

4、后臺北京Flinkuser id 1user id 2.上海user id 2user id 3.user id和對應城市訂閱訂閱北京+上海user id 1user id 2user id 3.上海user id 2user id 3.用戶李四的前端報表訂閱實時UV統計維度值多選Q:如果用戶量很大，前端是否會占用很多內存?A:前端可以考慮bitmap方案Q:如果同時打開前端看板的用戶很多，會怎么樣？A:Flink和后臺側幾乎沒有影響，UV去重的存儲和計算，都被分攤到了前端Q:前端會有很大的計算負載嗎?A:不會，只有增量的user id會推送給前端，整個過程都是流式的#4CDPCustomer

5、 Data Platform架構Flink Jobs系統信息元信息Mysql DorisElastic SearchTidbOffline Jobs基礎標簽管理行為標簽管理分群管理效果分析營銷管理畫像管理流量控制運營渠道 1運營渠道 N運營渠道 2.#5實時數倉實時數倉的考量點包括catalog管理元信息管理怎么合理的分層分層和離線數倉的建模方式有什么區別建模時延需要盡可能小鏈路盡可能短時效性架構元信息管理DWS權限管理DWDRAWDIMAPPLICATION血緣關系數據質量TiDBPGHiveKafka Topic規劃中AIOTemporal JoinAIOBroadcast or Temp

6、oral JoinDorisTiDBCatalog管理Catalog功能目前還未開發，未來會考慮所有的數據源對應一個表，屏蔽底層的存儲細節和差異結合即將上線的實時計算平臺Flink sql功能，效果更好合理的分層分層越多，時延越大實時數據的質量監控，比離線更加復雜，分層越多，出現問題越難定位合理的業務領域垂直劃分建模離線數倉，面對的更多是分析師離線數倉，大寬表有利于使用，可能用到的維度盡可能加上實時數倉，大寬表可能意味著更多的維度，更多的打寬操作，時延增加，維度按需添加實時數倉，面對的更多是開發，更偏重于實用時效性是否有專門的raw層，用于公共的CDC如果對接線上業務，傾向于單獨的鏈路，減少時延如果用于內部的業務分析，數據展示，傾向于實時數倉#6其他應用場景#1CQRS類應用，比如統一實時搜索服務，統一用戶視圖指標監控，異常檢測#2