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工作原理工作原理