实时湖仓在视频号场景的应用实践

背景介绍

• 业务概况：视频号数据规模巨大，单log峰值TPS达240W/s，单日记录数达千亿级，存储量超4PB，作者数量、视频数量、视频曝光次数均呈爆发式增长。
• 数据流转概况：原采用Lambda架构，实时采用流计算，离线使用批计算，但存在运维成本高、离线产出时延高、实时出错率高、离线/实时数据不一致等问题。
• 方案调研：对比Kappa架构和Flink架构，最终选择湖上建仓方案，以平衡实时性、成本和稳定性。

应用实践

• 湖上建仓：
  • 数据入库：采用Iceberg实时表分钟级落地，支持tube/kafka/pulsar下csv/json/pb格式入库。
  • 数据计算：简化链路/统一代码，节省人力/资源成本，Iceberg流转批模式生产，调度时延大幅降低。
  • 数据存储：统一存储为Iceberg，省去Kafka类MQ介质，湖表可用于异常恢复，补录时延大幅降低。
  • 查询加速：基于StarRocks的RoutineLoad实时导入Ice数据，借助SR的物化视图等加速数据查询。
• 入库及下游读取优化：
  • 解决方案：合理配置targetSizeInbytes、利用索引重分布，引入自动优化(AO)服务，加大flinkCP间隔，调整分布、配置filter。
• 优化开发链路：
  • 开发链路痛点：降低开发门槛，SQL化作业，Icebergwatermark checker将流转批，同源关联。
  • 解决方案：协同oteam共建流转批checker，平台组件化，Iceberg指标表+维表作SparkSQL开发，脱离外部存储依赖。
• 优化基础BI表：
  • 浏览侧核心天级基础宽表问题：上游依赖个数近20个，数百个字段，维度庞大，指标繁多，原始数据量级数千亿，结果集数百亿行，shuffle数据量级达到数TB，下游依赖总数超过1000+，次日04:30-05:00才可产出指标。
  • 解决思路：聚合shuffle网络传输转为本地化操作，全量计算演变为增量计算。
  • 解决方案：Spark3.3 AQE/SPJ加速计算，Iceberg merge-on-read+merge into实现多流累积拼接，旁路异步compaction合并。
  • thive/iceberg方案对比：Iceberg方案单表调度时延大幅减少（02:10–> 00:25），单表计算资源减少（核数减少近16%，内存减少近12%），整体链路产出时间可减少约3.5h+（10:30->07:00），整体链路计算资源预计可减少近15%。

项目总结

• 数据接入：单日接入的增量数据超4PB，存量数据超25PB，视频号侧已接入超400张Iceberg表，涵盖短视频、直播、电商等主要子业务。
• 数据计算：省下关联依赖的Redis存储，节约近400万元/年，基于流转批、merge-on-read、merge into，实现调度时延降低4倍以上，指标产出时延减少3h以上，简化链路及统一代码的工作，实现人力成本约节省30%以上，计算成本节省约15%，待全链路切换Iceberg后，预计可节省计算资源超3k单元，约人民币1700万元/年。
• 数据存储：统一存储为Iceberg，省下Kafka等MQ介质，节约近700万元/年，湖表可用于故障后的异常恢复，补录时延降低3倍。

未来展望

• 底座全面切换Iceberg：superSQL、pysql无缝切换thive至Iceberg。
• 共建完善Iceberg周边能力：优化Icebergwatermark checker。