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

实时湖仓在视频号场景的应用实践 # 演讲人：梁溪—微信视频号—高级数据工程师 梁溪 实时湖仓Oteam成员 目前负责视频号湖仓架构设计和开发迭代 目录 CONTENT 背景介绍项目总结 应用实践未来展望 # 背景介绍 s 业务概况 数据规模 作者数量、视频数量、视频曝光次数，均呈爆发式增长 单log峰值TPS可达240W/s 单日记录数达千亿级，存储量超4PB s 数据流转概况 s 架构概况 Lambda系统特性 离线与实时链路相互独立 离线使用批计算，稳定性高 实时采用流计算，延迟低 Lambda架构问题 离线/实时数据不一致 两套链路，运维成本高 离线产出时延高，实时出错率高 s 方案调研 方案一：Kappa架构–基于MQ方案二：Kappa变体–基于OLAP引擎 优点：实时性高、一套逻辑 缺点：较难支持大规模数据集及对应的回溯 优点：实时性高、一套逻辑，支持查询大数据集 缺点：成本非常高，较难支持大规模数据集及对应的回溯 关键问题：既要求实时性，又要求控制成本，还要求稳定、可靠 s 方案调研 数据湖技术对比 特性 Hive/THive Iceberg Hudi DeltaLake 运维 运维投入 力度大 力度大 无 无 公司内使用 大规模 大规模 无 无 业内使用 大规模 大规模 国内 小规模 THive互通性 支持 支持 不支持 不支持 能力 写入延迟 1H+ 1min 1min 1min 文件合并 手动 自动 自动 手动 生命周期管理 自动 自动 自动 自动 Schema演化 不支持 支持 支持 支持 Update/Delete 分区级删除 支持 支持 支持 ACID事务/时间旅行 不支持 支持 支持 支持 经对比，最终选择了Iceberg # 应用实践 湖上建仓 s 数据入库 tube/kafka/pulsar下csv/json/pb格式入库 iceberg实时表分钟级落地 数据计算 iceberg流转批模式生产，调度时延大幅降低 简化链路/统一代码，节省人力/资源成本 数据存储 统一存储为iceberg，省去kafka类MQ介质 湖表可用于异常恢复，补录时延大幅降低 查询加速 基于StarRocks的RoutineLoad实时导入ice数据 借助SR的物化视图等加速数据查询 入库及下游读取优化 数据入库问题 小文件问题–下游读取慢 实时数据落地依赖flinkCP机制 query触发扫描的split过多导致查询慢 解决思路 加大flinkCP间隔 调整分布、配置filter s 解决方案 合理配置targetSizeInbytes、利用索引重分布 引入自动优化(AO)服务 小文件稳定在数值范围内，且文件分布更合理 优化前平均耗时422s，优化后平均耗时64s 优化开发链路 开发链路痛点 实时join场景复杂多变，开发门槛高，导致开发效率低 s 解决思路 降低开发门槛 SQL化作业 Icebergwatermarkchecker将流转批 同源关联 异步io/广播等重度依赖外部存储，存在不稳定隐患 高阶API封装的泛化能力较弱，时间成本高 s 优化开发链路 解决方案 协同oteam共建流转批checker，平台组件化 iceberg指标表+维表作SparkSQL开发，节省人力成本 端到端时延15min（2min依赖+10min调度+3min计算） 脱离外部存储依赖，如redis/kafka/pulsar等Pass服务 优化基础BI表 数据计算痛点 离线链路层级多，计算冗长 指标繁多，资源消耗大 产出时延大，下游使用无法保障 s 浏览侧核心天级基础宽表问题 上游依赖个数近20个 数百个字段，维度庞大，指标繁多 原始数据量级数千亿，结果集数百亿行 shuffle数据量级达到数TB 下游依赖总数超过1000+ 次日04:30-05:00才可产出指标 优化基础BI表 原有thive方案 s 解决思路 聚合shuffle网络传输转为本地化操作 全量计算演变为增量计算 解决方案 Spark3.3AQE/SPJ加速计算 网络传输 icemerge-on-read+mergeinto实现多流累积拼接 全量计算 旁路异步compaction合并 优化基础BI表 thive/iceberg方案对比 s iceberg方案收益 单表调度时延大幅减少：02:10–>00:25 单表产出时效显著变快：04:50–>01:10 计算并发(core) 1500 1000 500 ice方案tdw方案 单表计算资源减少：核数减少近16%，内存减少近12% 整体链路产出时间可减少约3.5h+，即10:30->07:00 整体链路计算资源预计可减少近15% # 项目总结 s 项目总结 数据接入 视频号侧已接入超400张iceberg表，涵盖短视频、直播、电商等主要子业务 单日接入的增量数据超4PB，存量数据超25PB 数据计算 基于流转批、merge-on-read、mergeinto，实现调度时延降低4倍以上，指标产出时延减少3h以上 简化链路及统一代码的工作，实现人力成本约节省30%以上，计算成本节省约15% 省下关联依赖的Redis存储，节约近400万元/年 待全链路切换iceberg后，预计可节省计算资源超3k单元，约人民币1700万元/年 数据存储 统一存储为iceberg，省下Kafka等MQ介质，节约近700万元/年 湖表可用于故障后的异常恢复，补录时延降低3倍 # 未来展望 s 未来展望 底座全面切换iceberg superSQL、pysql无缝切换thive至iceberg 共建完善iceberg周边能力 优化icebergwatermarkchecker 谢谢观看 s 附录 Icebergwatermarkchecker工作原理