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

实时湖仓在视频号场景的应用实践 演讲人：梁溪—微信视频号—高级数据工程师 梁溪 实时湖仓Oteam成员目前负责视频号湖仓架构设计和开发迭代 目录CONTENT 背景介绍项目总结 应用实践未来展望 背景介绍 业务概况 数据规模 单log峰值TPS可达240W/s单日记录数达千亿级，存储量超4PB作者数量、视频数量、视频曝光次数，均呈爆发式增长 数据流转概况 架构概况 Lambda系统特性 实时采用流计算，延迟低离线使用批计算，稳定性高离线与实时链路相互独立 Lambda架构问题 两套链路，运维成本高离线产出时延高，实时出错率高离线/实时数据不一致 方案调研 优点：实时性高、一套逻辑，支持查询大数据集 优点：实时性高、一套逻辑 缺点：成本非常高，较难支持大规模数据集及对应的回溯 缺点：较难支持大规模数据集及对应的回溯 关键问题：既要求实时性，又要求控制成本，还要求稳定、可靠 方案调研 应用实践 湖上建仓 数据入库 iceberg实时表分钟级落地tube/kafka/pulsar下csv/json/pb格式入库 数据计算 简化链路/统一代码，节省人力/资源成本iceberg流转批模式生产，调度时延大幅降低 数据存储 统一存储为iceberg，省去kafka类MQ介质湖表可用于异常恢复，补录时延大幅降低 查询加速 基于StarRocks的RoutineLoad实时导入ice数据借助SR的物化视图等加速数据查询 入库及下游读取优化 解决方案 数据入库问题 合理配置targetSizeInbytes、利用索引重分布 小文件问题–下游读取慢 引入自动优化(AO)服务 实时数据落地依赖flinkCP机制 query触发扫描的split过多导致查询慢 解决思路 加大flinkCP间隔调整分布、配置filter 优化开发链路 开发链路痛点 解决思路 降低开发门槛 SQL化作业 Icebergwatermark checker将流转批 同源关联 优化开发链路 解决方案 协同oteam共建流转批checker，平台组件化 iceberg指标表+维表作SparkSQL开发，节省人力成本 端到端时延15min（2min依赖+10min调度+3min计算） 脱离外部存储依赖，如redis/kafka/pulsar等Pass服务 优化基础BI表 浏览侧核心天级基础宽表问题 上游依赖个数近20个数百个字段，维度庞大，指标繁多原始数据量级数千亿，结果集数百亿行shuffle数据量级达到数TB下游依赖总数超过1000+次日04:30-05:00才可产出指标 离线链路层级多，计算冗长产出时延大，下游使用无法保障指标繁多，资源消耗大 优化基础BI表 原有thive方案 解决思路 聚合shuffle网络传输转为本地化操作 全量计算演变为增量计算 解决方案 Spark3.3 AQE/SPJ加速计算ice merge-on-read+merge into实现多流累积拼接旁路异步compaction合并 优化基础BI表 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 感谢观看谢谢观看 附录 Iceberg watermark checker工作原理