陶然-蚂蚁实时计算 Flink on OceanBase.pdf

1、陶然/阿里巴巴高级开发工程师、Apache Spark&Flink Contributor周跃跃/蚂蚁集团 OceanBase 架构师蚂蚁实时计算 Flink on OceanBase#1#1蚂蚁实时计算生产实践蚂蚁实时计算生产实践#2 2#3#3蚂蚁蚂蚁 FlinkFlink OnOn OceanBaseOceanBaseOceanBaseOceanBase 社区版技术架构及核心特性社区版技术架构及核心特性蚂蚁实时计算生产实践1.Flink 热启动2.引擎无关通用 IO 的探索3.Flink云原生生产和实践*Notice:第三部分由另一位同学在分论坛分享蚂蚁实时计算规模数据同步145632实

2、时大屏在线学习ETL实时核对实时特征核心业务场景Flink 热启动1.修改一个参数要重启整个作业2.修改下执行计划也要重启3.重启作业是很重的操作，需要各类前置校验4.重启的方式是资源重复销毁然后重新申请和创建进程5.整个启动流程可能耗时在3-5分钟以上或更大（根据作业规模），用户体感很差背景和痛点：常规重启有没有更快速的方式（甚至秒级启动体验）？Flink 热启动热启动定位1.热启动完全替代常规暴力重启2.复用作业已经存在的资源3.复用作业的JobGraph并对其更新4.加速作业启动速度在保证状态兼容的前提下执行计划兼容和状态恢复宽兼容宽兼容紧兼容紧兼容1.指执行计划算子个数和点边关系一致2

3、.是热启动最最基本的兼容要求1.指在宽兼容基础上保持chainedGroups的一致目的：保证热启动的状态恢复，区分出针对vertex逻辑变更的情形，简单来说如果vertex没有变更，我们可以对vertex进行缩放，反之，需要完整的更新一次JobGraphFlink 热启动过程热启动触发JobMaster回填Graph并调度新的Graph客户端执行计划兼容检测updating request宽兼容紧兼容不兼容Exceptionrequest引擎层Graph回填和重新调度步骤1.新的JobGraph对旧的JobGraph部分资源和对象的直接复用（如checkpoint设置、savepoint设置

4、、没有变更的jar或者资源文件等）2.停止 checkpoint coordinator3.使用新的JobGraph生成新的ExecutionGraph并恢复状态（ExecutionGraph内部对象复用，如TaskManagerLocation信息等）4.挂起当前 ExecutionGraph（支持task cancel快速失败）5.使用新的ExecutionGraph恢复jobRuntime 支持和改造1.jobmaster 针对JobGraph和ExcutionGraph进行替换和复用2.更多rescale的hander支持1.热启动过程中cp的暂停和恢复checkpoint1.细粒度的

5、热启动，更大地复用taskmanager和podrecale vertex&configuration1.完整的热启动，兼容更多场景2.slotpool和rm层的slot和tm复用支持replace jobgraphjobmaster&rest handlersFlink 热启动效果秒级重启适用(99%speed up)：-原地重启-仅修改参数-缩容（缩并发,task的规格不变）-扩容（扩容部分并发度，有空闲slot摆放）-上述修改的混合部分加速效果（50%-60%左右的speed up）：-扩容（按倍数扩并发或扩的并发taskmanger无法摆放，复用部分pod，扩容部分pod）-扩缩部分t

6、ask资源（扩缩部分vertex的资源规格，复用部分pod，扩容部分pod）-分裂部分结点（复用部分pod，扩容部分pod）-合并部分结点（复用部分pod，扩容部分pod）上述修改的混合最坏场景（10%-20%左右的speed up）：-扩缩全部task的资源，导致全部pod规格改变,无法复用-拓扑完全改变注：针对资源规格的限制实际上可以调整和设置，主要是集群资源的限制蚂蚁引擎无关通用 IO背景和痛点：1.输入输出各个引擎和应用独自开发，重复造轮子2.新的插件 bug 多，没有经历大规模生产作业的考验3.Jar 冲突问题多3.不够全面4.不够标准和规范Flink 插件体系*DataStream