为何说 Flink + AI 值得期待？

去年 11 月的 Flink Forward Asia 2019（如下简称 FFA） 上 Flink 社区提出了将来发展的几个主要方向，其中之一就是拥抱 AI [1]。实际上，近年来 AI 持续火热，各类计算框架、模型和算法层出不穷，从某种角度上来讲，这个赛道已经有些拥挤了。在这种状况下， Flink 将怎样拥抱 AI，又会为用户带来什么新的价值？Flink AI 的优劣势分别在哪里？本文将经过对这些问题的讨论来分析 Flink AI 的发展方向。

Lambda 架构，流批统一和 AI 实时化

Flink 在 AI 中的价值其实和大数据中 Lambda 架构[2]和流批统一这两个概念有关系，Flink 为大数据实时化带来的价值也将一样使 AI 受益。

不妨让咱们简单回顾一下大数据的发展过程。从 Google 奠定性的“三架马车” 3[5] 论文发表后的很长一段时间内，大数据的发展主线上都只有批计算的身影。后来随着你们认识到数据时效性的重要做用，Twitter 开源的流计算引擎 Storm [6] 红极一时，各类流计算引擎也纷纷登场，其中也包括了 Flink。因为成本、计算准确性和容错性等方面的考虑，各家企业纷纷使用起了被称为 Lambda 架构的解决方案，在同一个架构下融合批计算和流计算，以便在成本，容错和数据时效性之间达到一个平衡。

Lambda 架构在解决数据时效性的同时也存在一些问题，其中最受诟病的就是其系统复杂度和可维护性。用户须要为 Batch Layer 和 Speed Layer 各维护一套引擎和代码，还须要保证两者之间的计算逻辑彻底一致（图1）。

图1

为了解决这个问题，各个计算引擎不约而同的开始了流批统一的尝试，试图使用同一套引擎来执行流和批的任务（图2）。通过若干年的大浪淘沙，Spark [7] 和 Flink 成为了目前处于第一梯队的两款主流计算引擎。Flink 是从流计算逐渐进入到批计算，一个很是典型的成功案例就是使用同一套标准的 SQL 语句对流和批进行查询，并保证最终结果一致性[8]。而 Spark 则是采用微批 (Micro Batch) 的方式从批计算进入到流计算提出了 Spark Streaming，可是在时延的表现上始终逊色一些。

图2

能够看到，在大数据的发展过程当中，Lambda 架构和流批一体背后的原始驱动力是数据实时化。一样是向数据要价值，AI 对数据时效性的要求同大数据是一致的。所以AI实时化也将会是一个重要的发展方向。在观察目前主流的 AI 场景和技术架构时，咱们也会发现它们与大数据平台有不少联系和类似之处。

目前的 AI 大体能够分为数据预处理（也称数据准备/特征工程等），模型训练和推理预测三个主要阶段。下面咱们逐一来看一看在每一个阶段中 AI 实时化需求有哪些，又有什么样的问题待解决。为了便于与大数据的架构作类比，咱们姑且认为流计算和批计算做为一种计算类型的划分维度已经将全部基于数据的计算一分为二，没有遗漏了。AI 的各个阶段根据场景不一样，也能够归为两者之一。

数据预处理（数据准备/特征工程）

数据预处理阶段是模型训练和推理预测的前置环节，不少时候它更多的是一个大数据问题。根据数据预处理后的下游不一样，数据预处理多是批计算也多是流计算，计算类型和下游一致。在一个典型的离线训练（批计算）和在线预测（流计算）场景下，训练和预测时要求产生输入数据的预处理逻辑是一致的（好比相同的样本拼接逻辑），这里的需求和 Lambda 架构中的需求同样，所以一个流批统一的引擎会格外有优点。这样能够避免批做业和流做业使用两个不一样的引擎，省去了维护逻辑一致的两套代码的麻烦。

模型训练

目前而言 AI 训练阶段基本上是批计算（离线训练）产生静态模型（Static Model）的过程。这是由于目前绝大多数的模型是基于独立同分布（IID）的统计规律实现的，也就是从大量的训练样本中找到特征和标签之间的统计相关性（Correlation），这些统计相关性一般不会忽然变化，所以在一批样本上训练出的数据在另外一批具备相同的特征分布的样本上依然适用。然而这样的离线模型训练产生的静态模型依然可能存在一些问题。

首先样本数据可能随着时间推移会发生分布变化，这种状况下，在线预测的样本分布和训练样本的分布会产生偏移，从而使模型预测的效果变差。所以静态模型一般须要从新训练，这能够是一个按期过程或者经过对样本和模型的预测效果进行监控来实现（注意这里的监控自己实际上是一个典型的流计算需求）。

另外，在有些场景下，预测阶段的样本分布可能没法在训练阶段就知晓。举例来讲，在阿里双十一，微博热搜，高频交易等这类样本分布可能发生没法预测的分布改变的场景下，如何迅速更新模型来获得更好的预测结果是十分有价值的。

所以一个理想的 AI 计算架构中，应该把如何及时更新模型归入考虑。在这方面流计算也有着一些独特的优点。事实上，阿里巴巴在搜索推荐系统中已经在使用在线机器学习，而且在双十一这样的场景下取得了良好的效果。

推理预测

推理预测环节的环境和计算类型比较丰富，既有批处理（离线预测）又有流处理。流式预测又大体能够分为在线 (Online) 预测和近线 (Nearline) 预测。在线预测一般处于用户访问的关键链路(Critical Path 中)，所以对 latency 的要求极高，好比毫秒级。而近线预测要求略低一些，一般在亚秒级到秒级。目前大多数纯流式分布式计算（Native Stream Processing）引擎能够知足近线数据预处理和预测的需求，而在线数据预处理和预测则一般须要将预测代码写进应用程序内部来知足极致的低延迟要求。所以在线预测的场景也比较少看到大数据引擎的身影。在这方面 Flink 的 Stateful Function [9] 是一个独特的创新，Stateful Function 的设计初衷是在 Flink 上经过若干有状态的函数来构建一个在线应用，经过它能够作到超低延迟的在线预测服务，这样用户能够在离线，近线和在线三种场景下使用同一套代码同一个引擎来进行数据预处理和预测。

综上所述，能够看到在机器学习的每一个主要阶段中对 AI 实时化都有重要的需求，那什么样的系统架构可以有效知足这样的需求呢？

Flink 和 AI 实时化的架构

目前最典型的 AI 架构示例是离线训练配合在线推理预测（图3）。

图3

正如以前提到的，这个架构存在两个问题：

1. 模型更新的周期一般比较长。
2. 离线和在线的预处理可能须要维护两套代码。

为了解决第一个问题，咱们须要引入一个实时训练的链路（图4）。

图4

在这个链路中，线上的数据在用于推理预测以外还会实时生成样本并用于在线模型训练。在这个过程当中，模型是动态更新的，所以能够更好的契合样本发生的变化。

不管是纯在线仍是纯离线的链路，都并不是适合全部的 AI 场景。和 Lambda 的思想相似，咱们能够把二者结合（图5）。

图5

一样的，为了解决系统复杂度和可运维性的问题（也就是上面提到的第二个问题），咱们但愿在数据预处理的部分用一个流批统一的引擎来避免维护两套代码（图6）。不只如此，咱们还须要数据预处理和推理预测可以支持离线，近线和在线的各类 Latency 要求，因此使用 Flink 是一个很是合适的选择。尤为是对于数据预处理环节而言，Flink 在流和批上全面完整的 SQL 支持能够大大提升的开发效率。

图6

除此以外，为了进一步下降系统的复杂度，Flink 也在模型训练环节进行了一系列努力（图7）。

• 流批一体算法库 Alink

在去年的 FFA 2019 上，阿里巴巴宣布开源了基于 Flink 的机器学习算法库 Alink [10]，并计划将其逐步贡献回 Apache Flink，做为 Flink ML Lib 随 Apache Flink 发布。除了离线学习的算法外，Alink 的一大特点就是为用户提供了在线学习算法，助推 Flink 在 AI 实时化上发挥更大的做用。

• Deep Learning on Flink （flink-ai-extended [11]）

帮助用户把目前流行的深度学习框架（TensorFlow、PyTorch）整合到 Flink 中。使除了深度学习算法开发者以外的用户能够基于 Flink 实现整套 AI 架构。

• 流批统一的迭代语义和高性能实现

AI 训练中迭代收敛是一个最核心的计算过程。Flink 从一开始就使用了原生迭代的方式来保证迭代计算的效率。为了帮助用户更好的开发算法，简化代码，进一步提升运行效率。Flink 社区也正在统一流和批上迭代的语义，同时对迭代性能进行更进一步的优化，新的优化将尽量避免迭代轮次之间的同步开销，容许不一样批次的数据、不一样轮次的迭代同时进行。

图7

固然，在一个完整的 AI 架构中，除了以上提到的三个主要阶段，还有不少其余工做须要完成，包括对各类数据源的对接，已有 AI 生态的对接，在线的模型和样本监控和各种周边配套支持系统等。阿里巴巴实时计算负责人王峰（花名莫问）在 2019 年 FFA 的主题演讲中的一张图（图8）很好的总结了其中许多工做。

图8

Flink 社区也正在为此作出努力。大体上来讲，这些 AI 相关的工做能够分红补足，提升和创新三类。下面罗列了其中一部分进行中的工做，有些工做也许与 AI 不直接相关，可是却会对 Flink 更好的服务于 AI 实时化产生影响。

补足：人有我无

• Flink ML Pipeline [12]：帮助用户方便的存储和复用一个机器学习的完整计算逻辑。
• Flink Python API（PyFlink [13]）：Python 是 AI 的母语，PyFlink 为用户提供 AI 中最重要的编程接口。
• Notebook Integration [14]（Zeppelin）：为用户的 AI 实验提供友好的 API。
• 原生 Kubernetes 支持 [15]：和 Kubernetes 集成来支持基于云原生的的开发、部署和运维。

提升：人有我强

• Connector 的从新设计和优化 [16]：简化 Connector 实现，扩大 Connector 生态。

创新：人无我有

• AI Flow：兼顾流计算的大数据 + AI 顶层工做流抽象和配套服务（即将开源）。
• Stateful Function[9]：提供堪比在线应用的超低延迟数据预处理和推理预测。

其中有些是 Flink 做为流行的大数据引擎的自有功能，好比丰富 Connector 生态来对接各类外部数据源。另外一些则要依靠 Flink 以外的生态项目来完成，其中比较重要的是 AI Flow。它虽然起源于支持 AI 实时化架构，可是在引擎层并不绑定 Flink，而聚焦于顶层的流批统一工做流抽象，旨在为不一样平台，不一样引擎和不一样系统共同服务于 AI 实时化的架构提供环境支持。因为篇幅关系在此很少赘述，将另文向你们介绍。

写在最后

Apache Flink 从一个简单的流计算想法开始，直到今天成长为一个业界流行的实时计算开源项目，使全部人受益，这个过程当中离不开 Flink 社区中数以百计的代码贡献者和数以万计的用户。咱们相信 Flink 在 AI 上也可以有所做为，也欢迎更多的人可以加入到 Flink 社区，同咱们一块儿共创并共享 AI 实时化的价值。

查看更多：https://yqh.aliyun.com/detail..._content=g_1000105250

上云就看云栖号：更多云资讯，上云案例，最佳实践，产品入门，访问：https://yqh.aliyun.com/