《Apache Flink 案例集（2022版）》——3.机器学习——Bilibili-Flink 在 B 站的多元化探索与实践（2） https://developer.aliyun.com/article/1228229
3. AI on Flink
传统的机器学习链路里数据的传输、特征的计算以及模型的训练，都是离线处理的，存在两个大的问题：第一个是时效性低，模型和特征的更新周期基本是 t+1 天或者 t+1 小时，在追求时效性的场景下体验并不好。第二个是计算训练的效率很低，必须等天或小时的分区数据全部准备好之后才能开始特征计算和训练。全量分区数据导致计算和训练的压力大。
在实时技术成熟后，大部分模型训练流程都切换到实时架构上，数据传输、特征计算和训练都可以做到几乎实时，从全量变成了短时的小批量增量进行，训练的压力也大大减轻。同时由于实时对离线的兼容性，在很多场景比如特征回补上，也可以尝试使用 Flink 的流批一体进行落地。
上图是B站典型的机器学习链路图。从图上可以看出，样本数据生产特征的计算、模型的训练和效果的评估都大量实时化，中间也夹杂着少量离线过程，比如一些超长周期的特征计算。
同时也可以看出，完整的业务的模型训练链路长，需要管理和维护大量的实时任务和离线任务。出现故障的时候，具体问题的定位也异常艰难。如何在整个机器学习的链路中同时管理号这么多实时和离线任务，并且让任务之间的协同和调度有序进行、高效运维，是B站一直在思考的问题。
因此B站引入了 Flink 生态下的 AIFlow 系统。AIFlow本身的定位就是做机器学习链路的管理，核心的机器计算引擎是 Flink，这和B站的诉求不谋而合。这套系统有三个主要的特性符合B站的业务需求。
第一，流批的混合调度。在B站实际的业务生产上，一套完整的实时链路都会夹杂着实时和离线两种类型的任务。AIFlow 支持流批的混合调度，支持数据依赖与控制依赖，能够很好地支持B站现有的业务形态，并且未来在 Flink 流批一体方面也会有更多的发挥空间；
第二，元数据的管理，AIFlow 对所有数据和模型都支持版本管理。有了版本管理，各种实验效果和实验参数就都可追溯；
第三，开放的通知机制。整个链路中存在很多的外部系统节点，难以归纳到平台内部，但是通过通知机制，可以打通 AIFlow 内部节点与外部节点的依赖。整套系统的部署分为三部分，notification service、 meta service 以及 scheduler，扩展性也很好，B站在内部化的过程中实现了很多自己的扩展。
AIFlow 的构建使用 Python 进行描述，运行时会有可视化的节点展示，可以很方便地追踪各个节点的状态，运维也可以做到节点级的管理，不需要做整个链路级别的运维。
未来规划
在平台建设方面，B站希望融合 Yarn session 模式与 application 模式做 session 的复用，解决任务上线的资源申请效率问题。同时希望大 state 任务也能够在 session 的基础上复用本地的 state，启动时无需重新下载 state。
同时希望能统一目前的 SQL 和 JAR 包两种模式，统一任务构建方式，让用户以更低的成本更多复杂的操作，平台也更方便管理。
在增量生产方面，B站希望构建一套标准的数据组织布局优化，并且基于历史查询自动对数据做重布局优化，使用Data Skipping等技术实现计算加速。同时希望对批流存储进行融合，并赋能AI数据的标准化。
在机器学习方面，B站希望整个系统借助Flink的批流一体能力支持实时离线两套运行模式，方便回补历史数据。同时希望可以实现特征多版本管理，并支持Alink原生训练，打通外部训练系统，实现全链路拉起。
