B站基于Iceberg的流批一体的探索和实践

张陈毅/哔哩哔哩DataFunSummit#2024实时数据传输概览新鲜度存储成本保留数据的Batch易用性高高短低弱低低长中好优势1.数据新鲜度可达分钟级，可供下游流式消费2.数据异常可直接使用FlinkBatch回刷，单链路无需多引擎适配3.FlinkBatch引擎可直接query数据，无需dump4.视图的支持，减少重复存储数据的浪费5.Iceberg异步优化数据(小文件、Magnus数据优化1.小文件合并2.文件内部排序3.Distribution分布4.创建索引5.创建预计算文件•计算&存储成本共计355w/年•CPU使用降低20%，内存消耗降低22%l性能提升：新技术方案，经过多个实际已迁移任务前后的分析，平均性能提升约48.9%。00商业和AI的在线训练(背景)1.训练数据的存储不统一2.实时训练和离线训练两套计算开发3.Dump任务解析PBCPU消耗较大4.Kafka读网络和磁盘IO较大(protobuf)商业和AI的在线训练(迭代)特点1.实时训练和离线训练统一存储(API)2.存储成本降低(压缩、ErasureCode[EC]优化)3.计算成本的降低20%(dump任务)商业和AI的在线训练(规划)改进:Base数据由Iceberg替换Kafka期望:缓解kafka网络和磁盘读压力手段:使用GIC，降低Checkpoint时间•优化Base数据的新鲜度•缓解RocksDBCheckpoint的CPU共振实时+离线同步1.Hive表每个分区为全量的的快照数据2.Hive可作为大流量实时计算场景下维表Join的替代方案，缓解DBquery压力实时链路补强，提供能力1.将Iceberg作为MySQL的镜像表来做实时查询(分钟级延迟)2.Iceberg表具备增量流读changelog能力1.MOR写EqualityDeleteFile附带整个Row2.Flink流读changelog，保障数据处理的有序性(同Snapshot下:Equal、Data、Pos)3.WriteOperator引入keyedstate记录Primarykey，避免上游数据重放4.Magnus异步compactionmor表，防止EqualDelete过多影响Batch读合并单链路1.[即时查询]Iceberg作为MySQL的镜像表来做实时查询(分钟级延迟)2.[实时消费]Iceberg表具备增量流读changelog能力3.[离线场景]Iceberg每个Tag为全量的的历史快照数据优化项a.FlinkCheckpoint的触发增加和watermark关联机制b.WriterOperator前增加Operator缓存数据，解决T2的数据落到T1中c.Tag独立于dataFile，防止非分区表data目录下触达文件数上限问题Flink大流量任务使用维表Join(Lookup)时，对远端DB的压力较大，并且在使用中存在一些痛点1.维表连接器多，每个连接器私有参数也多，用户使用成本大2.维表点查远端DB耗时高，读DB压力大3.即使做了LocalCache优化，但是任务重启缓存会失效QPS/ConnectionQPS/ConnectionNoState1.借助于Calcite使用SQLHint的方式支持新join语法，降低SQL撰写难度和区分存量Join2.对Calcite和FlinkProjectRule改造，支持保留PrimaryKey信息3.ChangeLog保留UpdateBefore语义，使得State数据更新准确4.新JoinOperator:Left流在Right流Initsplittask完成前会被block1.F