2024數據湖峰會PPT-梁溪-終稿.pdf

《2024數據湖峰會PPT-梁溪-終稿.pdf》由會員分享，可在線閱讀，更多相關《2024數據湖峰會PPT-梁溪-終稿.pdf（23頁珍藏版）》請在三個皮匠報告上搜索。

1、DataFunSummitDataFunSummit#20242024實時湖倉在視頻號場景的應用實踐實時湖倉在視頻號場景的應用實踐演講人：梁溪微信視頻號高級數據工程師 梁溪實時湖倉Oteam成員目前負責視頻號湖倉架構設計和開發迭代應用實踐應用實踐未來展望未來展望目錄目錄 CONTENTCONTENT背景介紹背景介紹項目總結項目總結DataFunSummitDataFunSummit#20242024背景介紹背景介紹業務概況s 數據規模數據規模 單log峰值TPS可達240W/s 單日記錄數達千億級，存儲量超4PB 作者數量、視頻數量、視頻曝光次數，均呈爆發式增長數據流轉概況ss LambdaL

2、ambda系統特性系統特性實時采用流計算，延遲低離線使用批計算，穩定性高 LambdaLambda架構問題架構問題兩套鏈路，運維成本高離線產出時延高，實時出錯率高離線/實時數據不一致離線與實時鏈路相互獨立架構概況方案調研s優點：實時性高、一套邏輯缺點：較難支持大規模數據集及對應的回溯 方案一：方案一：KappaKappa架構架構 基于基于MQMQ 方案二：方案二：KappaKappa變體變體 基于基于OLAPOLAP引擎引擎優點：實時性高、一套邏輯，支持查詢大數據集缺點：成本非常高，較難支持大規模數據集及對應的回溯關鍵問題：關鍵問題：既要求實時性，實時性，又要求控制成本，控制成本，還要求穩定、

3、可靠穩定、可靠方案調研s 數據湖技術對比數據湖技術對比特性特性Hive/Hive/THiveTHiveIcebergIcebergHudiHudiDeltaLakeDeltaLake運維運維投入力度大力度大無無公司內使用大規模大規模無無業內使用大規模大規模國內小規模THive互通性支持支持不支持不支持能力寫入延遲1H+1min1min1min文件合并手動自動自動手動生命周期管理自動自動自動自動Schema演化不支持支持支持支持Update/Delete分區級刪除支持支持支持ACID事務/時間旅行不支持支持支持支持經對比，最終選擇了IcebergIcebergDataFunSummitDataF

4、unSummit#20242024應用實踐應用實踐湖上建倉s 數據入庫數據入庫iceberg實時表分鐘級落地 數據計算數據計算簡化鏈路/統一代碼，節省人力/資源成本iceberg流轉批模式生產，調度時延大幅降低tube/kafka/pulsar下csv/json/pb格式入庫 數據存儲數據存儲統一存儲為iceberg，省去kafka類MQ介質湖表可用于異?；謴?，補錄時延大幅降低 查詢加速查詢加速基于StarRocks的RoutineLoad實時導入ice數據借助SR的物化視圖等加速數據查詢入庫及下游讀取優化s 數據入庫問題數據入庫問題小文件問題 下游讀取慢query觸發掃描的split過多導致

5、查詢慢實時數據落地依賴flink CP機制 解決思路解決思路加大flink CP間隔優化前平均耗時422s，優化后平均耗時64s64s 解決方案解決方案引入自動優化(AO)服務合理配置targetSizeInbytes、利用索引重分布小文件穩定在數值范圍內，且文件分布更合理調整分布、配置filter優化開發鏈路s 開發鏈路痛點開發鏈路痛點 實時join場景復雜多變，開發門檻高，導致開發效率低異步io/廣播等重度依賴外部存儲，存在不穩定隱患高階API封裝的泛化能力較弱，時間成本高 解決思路解決思路降低開發門檻SQL化作業Iceberg watermark checker將流轉批同源關聯優化開發鏈

6、路s協同oteam共建流轉批checker，平臺組件化iceberg指標表+維表作SparkSQL開發，節省人力成本端到端時延15min（2min依賴+10min調度+3min計算）解決方案解決方案脫離外部存儲依賴，如redis/kafka/pulsar等Pass服務優化基礎BI表s 數據計算痛點數據計算痛點 離線鏈路層級多，計算冗長產出時延大，下游使用無法保障指標繁多，資源消耗大 瀏覽側核心天級基礎寬表問題瀏覽側核心天級基礎寬表問題上游依賴個數近近2020個個數百個字段，維度龐大，指標繁多維度龐大，指標繁多原始數據量級數千億數千億，結果集數百億行數百億行shuffle數據量級達到數數TBTB

7、下游依賴總數超過超過1000+1000+次日04:30-05:0004:30-05:00才可產出指標s 解決思路解決思路Spark3.3 AQE/SPJ加速計算ice merge-on-read+merge into實現多流累積拼接 聚合shuffle網絡傳輸轉為本地化操作 解決方案解決方案全量計算演變為增量計算旁路異步compaction合并 原有原有thivethive方案方案網絡傳輸全量計算優化基礎BI表s icebergiceberg方案收益方案收益單表計算資源減少：核數減少近減少近16%16%，內存減少近減少近12%12%50010001500計算并發(core)ice方案tdw方案

8、單表調度時延大幅減少：大幅減少：02:1002:10 00:25 00:25單表產出時效顯著變快：顯著變快：04:5004:50 01:10 01:10 thivethive/iceberg/iceberg方案對比方案對比整體鏈路產出時間可減少約減少約3.5h+3.5h+，即10:3010:30 -07:0007:00整體鏈路計算資源預計可減少近減少近15%15%優化基礎BI表DataFunSummitDataFunSummit#20242024項目總結項目總結項目總結s 數據計算數據計算省下關聯依賴的Redis存儲，節約近近400400萬元萬元/年年基于流轉批、merge-on-read、m

9、erge into，實現調度時延降低4 4倍以上，倍以上，指標產出時延減少減少3h3h以上以上 數據存儲數據存儲統一存儲為iceberg，省下Kafka等MQ介質，節約近近700700萬元萬元/年年湖表可用于故障后的異?；謴?，補錄時延降低3 3倍倍 數據接入數據接入單日接入的增量數據超超4PB4PB，存量數據超超25PB25PB視頻號側已接入超超400400張張iceberg表，涵蓋短視頻、直播、電商短視頻、直播、電商等主要子業務簡化鏈路及統一代碼的工作，實現人力成本約節省30%30%以上，以上，計算成本節省約15%15%待全鏈路切換iceberg后，預計可節省計算資源超3k3k單元單元，約人民幣17001700萬元萬元/年年DataFunSummitDataFunSummit#20242024未來展望未來展望未來展望s 底座全面切換底座全面切換icebergicebergsuperSQL、pysql無縫切換thive至iceberg 共建完善共建完善icebergiceberg周邊能周邊能力力優化iceberg watermark checker感謝觀看感謝觀看謝謝觀看附錄s Iceberg watermark checkerIceberg watermark checker工作原理工作原理