1、张杨/资深开发工程师FlinkFlink 在在B B站的多元化探索与实践站的多元化探索与实践平台建设平台建设增量化增量化AIAI On FlinkOn Flink#1#2#3#1#1平台建设平台建设平台建设基础功能完善基础功能完善lkafkakafka动态动态sinksinkl提交器优化提交器优化新任务构建模式新任务构建模式l算子化算子化智能诊断智能诊断l错误分析错误分析l自动调优自动调优topic1topic2topic3sink1sink2sink3mapkeybykeybykeybyKafkaKafka动态动态sinksinkn 数据倾斜u不同sink的数据差别很大,容易发生数据倾斜问题

2、n 不支持动态增加topicu增加topic需要改代增加sinku增加topic无法兼容checkpointn 持续维护成本高uTopic过多,sql太长难以维护基础功能完善topic1topic2topic3sinkmapudfKafka动态sinkn 动态topic生成usink属性里面支持udf生成topicu无需在sql里面编写多sinkuudf直接对接业务系统数据源n 单Sink数据均匀u每个sink处理数据量一致u没有倾斜问题u单sink维护成本低n 业务效果u多个千亿级分流任务稳定运行基础功能完善提交器优化flink1.8-submitterflink1.11-submitter

3、udf(on hdfs)RouterYarn-jmflink1.12-submittersubmit job graphYarn-tmYarn-tmYarn-tmnetwork classloadercompilen 本地编译u编译消耗资源多u提交器成为大规模故障恢复瓶颈n Flink版本耦合u提交器代码直接依赖flinku需要维护多个版本提交器n udf加载uurlclassloader远程加载不稳定u启动期间hdfs查询压力极大n 上传下载多,提交慢uflinklib多次上传下载uuserlib多次上传下载基础功能完善提交器优化submitteruserlib(on hdfs)Yarn-j

4、mYarn-tmYarn-tmYarn-tmsubmit contextdownload by versionflinklib(on hdfs)downloadcompilen 远程编译u采用application模式提交u修改源码支持udf本地加载上传u修改类加载器部分,严格child/parentn Flink版本解耦u提交器完全拆开flink依赖,纯shell执行u根据任务配置下载对应的flink版本n 资源远程自动下载uFlinklib走hdfs直接分发,client无需下载uUserlib走hdfs直接分发,client无需下载基础功能完善平台建设基础功能完善基础功能完善lkafka

5、kafka动态动态sinksinkl提交器优化提交器优化新任务构建模式新任务构建模式l算子化算子化智能诊断智能诊断l错误分析错误分析l自动调优自动调优SQLSQL优点-简单易上手-好维护缺点-难以定制化-核心功能缺失JARJAR优点-灵活可定制-功能全缺点-入门困难-难以维护算子化算子化优点-简单易上手-可定制-可维护缺点-有一定的理解成本新任务构建模式算子化SQLSQLSQLSQL算子jar1算子jar1n 混合构建u支持sql与jar混合构建任务u兼容纯sql,纯jar开发n 扩展性u在sql除了udf提供了更多扩展性u接口抽象,开发简单,跟udf类似n 支持通用算子u可提供通用算子,拖拽

6、构建任务新任务构建模式平台建设基础功能完善基础功能完善lkafkakafka动态动态sinksinkl提交器优化提交器优化新任务构建模式新任务构建模式l算子化算子化智能诊断智能诊断l错误分析错误分析l自动调优自动调优智能诊断300+users300+users7w+cores7w+cores1300+1300+online jobsonline jobs当前痛点资源配置资源配置初始资源确认困难碎片化严重使用资源周期性变化性能调优性能调优数据倾斜网络资源优化state性能调优错误诊断错误诊断任务失败原因分析修复建议gc性能调优智能诊断n 性能诊断u根据运行时节点metrics自动分析判断任务倾斜

7、,state内存,cpu配置是否合理n 失败诊断u根据日志快速分析出任务失败原因n 资源自动配置u根据最近7日实际使用资源,自动优化任务资源分配,目前只支持自动缩容n 业务收益u缩容目前节省了线上约10%资源未来展望n 任务启动加速u 融合per job与session模式,任务上下线无需销毁cluster,复用cluster与stateu Cluster根据新的资源配置重新调整申请,无需重建整个集群n 智能诊断u 参数自动优化,快速自动重启任务,任务免资源配置u 真正做到按需分配,动态扩缩容n 算子化u基于算子化标准化掉实时数仓建模,在实时数仓模型层标准场景尝试流批一体落地#2 2增量化增量

8、化早期数据架构业务痛点#1时效性n 日志数据无法实时追加即时查询n Mysql数据无法近实时更新,快速查询n 离线sla低,凌晨产出数据晚n etl查询效率低,暴力扫描分区或bucke全部文件n 无法优化数据布局,针对olap,adhoc场景优化#2数据使用效率低增量化架构n Engineu计算层Flinku存储层HUDI/HIVEn 增量管道u流式Flow，定义ETL Pipelineu加速数据产出时效性,避免集中计算n Organizeru数据重布局，含增量化和定期重组u如归档和Compaction增量化ODS-DWD增量化ODS-DWDn 数据落地HUDI/HIVEu可支持分钟级数据可见

9、性n DWD层ETL增量化u原DWD层数据Ready于2点到5点，现时效提升到凌晨30min到1h内n 湖仓链路打通，下游透明u兼容Hive，小时/天分区，传统ETL调度透明u基于HUDI Schema Evolution，字段扩展前后兼容，满足业务发展及灵活性要求n 全量+增量一体化打通u全/增量格式标准化,分钟级摄取,一键增量化入仓uMysql基于Flink CDC,全量SnapshotReader,增量BinlogReaderuTIDB基于快照文件+Binlog,全量Slave节点Agent采集,增量BinlogReadern 兼容Hive分区,ETL透明u每小时/天分区，触发HUDI

10、Snapshot全量拷贝，并主动注册HMS分区信息，下游无缝增量化CDCn 进出条数统计u全链路端到端Metric采集条数,统计落地质量n 数据采样精确校验u源头JDBC采样Select比例数据,HUDI增量视图对比数据n 哨兵模拟Mysql到HUDI全量探测u模拟Mysql的写入和更新,每10分钟产生binlog数据进行HUDI全量校验n DB快照与HUDI快照全量精确审计u周期性(按天/周)Agent采集DBA快照,初始化为HUDI表进行数据全量的精确审计增量化CDC增量化hudi改进n ProcessElementuHoodieKey判断State初始化n Files Loopsu对应P

11、artition下state不存在，则目录下所有文件全扫描n Hash By Keyuloops所有文件，根据Hash提取对应key存放到IndexState中n 问题u每个Task处理全量数据，效率极差Bootstrap冷启动n Coordinatoru集中式分发BaseFile文件n IndexBootstrapuloops每一个BaseFilesuHash Key By HoodieRecordn 效果u处理能力提升N(并发度)倍Bootstrap冷启动n WriteFunctionuSnapshot阶段,Event可能存在丢失n CoordinatoruNotify本身不在CK生命周期

12、内,不保障成功n 问题u在CK成功,但Notify失败或Notify完成前重启,作业会存在Instant丢失,数据质量不完整Checkpoint一致性优化Checkpoint一致性优化n Append模式u小文件滚动合并关掉，A-A+B-A+B+C，巨大的IO读写放大u每次CK新写Parquet，在多文件达到合并大小后触发Compactionn 关闭生产消费模式的限速u原生HUDI限速,通过采样记录计算平均值,会存在一些误限uAppend模式下,每批次Queue等同于Bucket的Buffer,仅控QueueSize即可n 外挂式小文件Compactionu针对每一次CK产生小文件,定制横向和

13、纵向Compaction模式,进行小文件合并n 吞吐效果u在纯Insert场景下,数据的入湖性能提升5倍,每秒流式写入峰值在5k/rps,1coreAppend写入优化GetListing优化n TimelineServer单例u现有基于TM粒度,后续可进一步优化提供一个单例TimelineServerOperatorn GetListing元数据目录uHUDI Metadata每一次Commit Instance只能获取到mapping的增量BaseFiles,待开展优化GetListing优化n 计算加速u 构建一套标准的数据组织布局优化u OPTIMIZE Command/Z-Order

14、ing by Multiple Attributesu 基于历史查询，自动对数据重布局优化，Data Skipping加速计算n 流批存储融合u 屏蔽上层细节，Connectors打通Kafka和HUDI的数据衔接，Kappa架构u 热数据通过Kafka Cache+SSD访问，冷数据HUDI Time Traveln 赋能AI数据的标准化u提供基于湖上的特征库、画像库、索引库等，解决版本管理、简化接入和查询u算法大量工作集中在对数据及模型做调优，强诉求于多版本管理未来展望#3 3AI On AI On FlinkFlinkn 时效性低u基于t+1d/h的特征u基于t+1d/h的样本n 全量训

15、练效率低u必须等分区数据全部ready才能开始训练u分区数据过大训练效率低传统离线架构n 时效性高u几乎完全实时的特征u几乎完全实时的样本n 增量训练u根据实时数据增量训练u避免单次训练数据过大n 流批融合u部分长周期特征需要大量历史离线数据backfillu看到了实时离线特征流批融合的可能性实时架构B站推荐数据链路n 支持流批依赖u支持流任务和批任务的混合调度u支持数据依赖u支持控制依赖n 支持元数据管理u对于数据和模型有一套完善的管理机制n 信号驱动u支持notification通过消息驱动外部系统引入AIFlow平台架构V2V2版本版本V3V3版本版本展示效果未来展望n 流批一体u 整个流程支持实时离线两套运行模式,方便回补历史数据n 特征管理u 支持特征多版本管理u 支持特征无码化引入n 模型训练u支持Alink原生训练u支持打通外部训练系统,全链路拉起