阿里重磅开源全球首个批流一体机器学习平台Alink，Blink功能已全部贡献至Flink

自 2019 年 1 月起，阿里巴巴逐步将内部维护的 Blink 回馈给 Flink 开源社区，目前贡献代码数量已超过 100 万行。国内包括腾讯、百度、字节跳动等公司，国外包括 Uber、Lyft、Netflix 等公司都是 Flink 的使用者。


今年 8 月发布的 Flink 1.9.0 是阿里内部版本 Blink 合并入 Flink 后的首次发版，在今天的 Flink Forward 2019 大会上，阿里发布了 Flink 1.10 版本功能前瞻，正式版本预计于 2020 年 1 月发布。

Flink 1.10 版本功能前瞻：Blink 全部功能进入 Flink
------------------------------------

据介绍，Flink 1.10 版本可以看作一个比较重要的里程碑式版本，至此，Blink 全部功能都已经进入 Flink，包括 Blink 中比较关键的设计和通用的优化。以下是该版本将包含的主要功能和技术亮点前瞻：

1.**完成Blink/Flink merge**

（1）**更加强大的Blink Query Processor**

*   DDL 增强，支持在建表语句中定义计算列和 watermark
*   生产级别的Batch支持，完整支持 TPC-H 和TPC-DS 测试集，其中 TPC-DS 10T的性能是Hive3.0的7倍 
    （2）完成scheduler的重构，支持更灵活batch调度策略

（3）更完善，更细粒度，更灵活的资源管理

*   对 TaskExecutor 的内存模型进行了梳理，解决了 RockDB 内存难以配置和管控、TM 启动前后内存计算不一致等长期存在的问题
*   简化了内存计算逻辑，降低了配置难度
*   对算子级别的资源用量进行更精细的管理，解决算子资源超用带来的性能及稳定性问题，提高资源利用效率

**2.Hive兼容性生产可用**

（1）Meta 兼容，支持直接读取 Hive catalog，版本覆盖1.x，2.x到3.x 
（2）数据格式兼容，支持直接读取 Hive 表，同时也支持写成 Hive 表的格式 
（3）UDF 兼容，支持在 Flink SQL 内直接调用 Hive 的UDF，UDTF，UDAF

**3.更加强大的Python支持**

*   增加了对 NativePython UDF 的支持，用户可以用Python开发自己的业务逻辑
*   很好的支持了 Python 类库的依赖管理，Python用户不仅可以自定义Python UDF 而且可以与其他现有的Python library进行集成
*   在架构上引入了BeamPortability Framework，Flink与Beam社区共同打造功能便捷，性能优越的Python UDF支持框架
*   与Flink资源管理框架进行集成，实现了对Python UDF资源的管控

**4.支持原生K8S集成**

（1）原生的资源管理，可以根据作业的资源需求动态去申请TaskManager，不需要依赖外部系统或组件 
（2）更加方便的任务提交，不需要安装kubectl等工具，可以达到和Yarn相似的体验

**5.新增多个主流机器学习算法库**

（1）包括逻辑回归，随机森林，KMeans等

提问：在 1.10 版本中，Blink 全部功能都已经进入 Flink，而这距离上一次 1.9 发布刚过去三个月，那也是 Blink 首次并入 Flink 的版本发布，距离去年阿里宣布要开源 Blink 也不过一年时间。为什么 Blink 的 Merge 进度能做到这么快？过程中遇到了哪些问题？你们是如何解决的？

莫问： 我们投入了很多资源，包括有数十位技术人员来做这个事情，并行度比较大，所以才能在比较短的时间内贡献多达 150 万行代码。

提问：整个过程中有没有遇到什么比较棘手的问题？ 
莫问： 社区是一个相对开放透明的场景，不像自己的项目可以比较随意地改动，而是要走一个民主的过程，包括要经过社区的讨论、大家的认可，要保证代码的质量等。我们既要做到快速推进，还要保证质量和社区的公平性，这个挑战还是很大的。

提问：所以你们怎么平衡这两件事情？

莫问： 整个 Flink 社区的合作模式是比较高效的，社区不同模块的负责人每周都会有视频会议，可能是不同国家的社区讨论，这些都做得非常高效，项目管理做得非常好。在这种机制的保证下，我们可以让代码快速进入同时保证迭代的速度。其实这对工程效率的开发也是非常大的挑战。说白了，我们投入了很多技术人员做这件事，但也不是只看数量。我们投入的很多人手本身就是 Apache 项目的 PMC 和 Committer，而不完全是普通的工程师，这些人本身对于 Apache 项目的工作机制和流程都比较熟悉，他们的效率和作战能力不能按一个人这么算。社区就是这样，不是人多的问题，还需要合适的人。

提问：您上午在演讲中提到 Flink 正在成为一个真正的 Unified Engine。有趣的是，我们近期已经不止一次听到不同的计算引擎提出类似的说法，比如 Spark 的核心理念也是成为“统一数据分析平台”，能否请您谈谈 Flink 的设计理念？二者的统一有什么相同点和不同点？

莫问：Flink 的核心理念我们强调过很多次，它的本质计算思想是流处理核心。流处理核心就是所有的都是基于 Stream 来处理，批可以看作是一个有限的流。像今天提到的在线的 Stateful Function 也是 Event Driven，所有的 Event 不停地进入做函数计算，做在线有状态的计算，然后把结果给用户，再不停地迭代。其实在线服务也是无限的，也是不会停止的处理，不停地有人访问，有人处理。Flink 的核心是基于流计算的 Core，去覆盖 Offline 和 Online，这样它跟 Spark 还是不太一样的。Spark 认为所有东西都是基于 Batch 的，而流是无数个 Batch 凑在一起，这一点不太一样。

但大家在宏观上的愿景都是类似的，用一套计算引擎技术或大数据处理的技术，来解决尽量多的场景，这样从用户的角度来说学习成本更低、开发效率更高、运维成本也更低。所以大家的目标和理念是一致的，只不过在实现这个目标的方法上的选择是不一样的。

\*\*提问：下面这个问题我们之前问过 Databricks 的工程师，今天也想问问您，如果我要做统一的平台，你也要做统一平台，那会不会存在最后到底谁能真正统一谁的问题？

\*\*莫问： 我觉得大家并不是说做什么，什么就一定会赢，一定会好。从我个人态度来说，技术还是需要有一定良性的竞争，这样才能相互学习，同时条条大路通罗马，不一定哪一个绝对正确，可能不同场景有不同的偏好或不同的特定区域的需求，或适应的场景不一样。解决类似问题有两三家公司共存，这种状态是比较健康的，就像数据库领域有 MySQL、PostgreSQL 等，在线服务也类似，起码得有两家大公司在一起竞争，是比较合适的。但最终哪个做得更好，还是取决于是否能把自己的理论做到极致。因为理论是理论，你的理论和我的理论听起来各有千秋，但是谁最后能赢看的是细节，包括用户体验。你是否按照正确的方法在做，细节做得够不够好，而不是大家听起来思路一样就没有区别了。细节和社区生态的发展、推进过程都很重要。

开源 Alink：Flink 机器学习进度几何？
------------------------

Flink 在机器学习领域的进展一直是众多开发者关注的焦点，今年 Flink 迎来了一个小里程碑：机器学习算法平台 Alink 开源，这也宣告了 Flink 正式切入 AI 领域。

Alink 开源项目链接：[https://github.com/alibaba/Alink](https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fgithub.com%2Falibaba%2FAlink)

Alink 是阿里巴巴机器学习算法团队从 2017 年开始基于实时计算引擎 Flink 研发的新一代机器学习算法平台，提供丰富的算法组件库和便捷的操作框架，开发者可以一键搭建覆盖数据处理、特征工程、模型训练、模型预测的算法模型开发全流程。作为业界首个同时支持批式算法、流式算法的机器学习平台，Alink 提供了 Python 接口，开发者无需 Flink 技术背景也可以轻松构建算法模型。Alink 这个名字取自相关名称（Alibaba, Algorithm, AI, Flink,Blink）的公共部分。

据悉，Alink 已被广泛运用在阿里巴巴搜索、推荐、广告等多个核心实时在线业务中。在刚刚落幕的天猫双 11 中，单日数据处理量达到 970PB，每秒处理峰值数据高达 25 亿条。Alink 成功经受住了超大规模实时数据训练的检验，并帮助提升 4% CTR（商品点击转化率）。

**提问：能否先介绍一下 FlinkML 和 Alink 的概况，以及二者的关系？**

莫问：FlinkML 是 Flink 社区现存的一套机器学习算法库，这一套算法库已经存在很久而且更新比较缓慢。Alink 是基于新一代的 Flink，完全重新写了一套，跟 FlinkML 没有代码上的关系。Alink 由阿里巴巴大数据团队开发，开发出来以后在阿里巴巴内部也用了，然后现在正式开源出来。

**未来我们希望 Alink 的算法逐渐替换掉 FlinkML 的算法，可能 Alink 就会成为新一代版本的 FlinkML，当然替换还需要一个比较漫长的过程。**Alink 包含了非常多的机器学习算法，往 Flink 贡献或发布的时候也需要比较大的带宽，我们担心整个过程耗时会比较长，所以先把 Alink 单独开源出来，大家如果有需要的可以先用起来。后面贡献进展比较顺利的情况下，Alink 应该能完全合并到 FlinkML，也就是直接进入 Flink 生态的主干，这对于 Alink 来说是最好的归宿，到这个时候 FlinkML 就可以跟 SparkML 完全对应起来了。

**提问：除了 Alink 以外，Flink 当前在机器学习领域的工作还有哪些进展？和其他计算引擎相比，您如何评价当前 Flink 在机器学习和 AI 领域的工作，它的竞争力足够强吗？**

莫问： 其实我们还有很多正在进行的工作。机器学习的核心是迭代计算，机器学习训练就是不停地对数据进行迭代训练，训练出来一个模型然后上线。在核心训练的基础上，Flink 正在设计新的迭代计算，因为 Flink 是基于流式计算，所以它的迭代计算可以转化为 mini-batch 的迭代计算，可以根据数据条目数也可以根据数据段的时长，在流上打出很多细粒度的数据段。

Flink 的好处是在流上打细粒度的数据段可行性上没有问题，因为它本来就是纯流式的，截成一段一段没有问题。而 Spark 的迭代是把一个数据集做一次迭代，再做一次迭代，这个数据集很难切得特别细，切出来一段就是一次任务的运行，细粒度的挑战比较大。Flink 的好处是本身可以把粒度截得很细，所以重构原有的迭代计算是可行的。

Flink 最早的迭代计算也跟 Spark 一样，要么是一批迭代要么是一条一条迭代，完全是两个极端，我们想把它做一个抽象，可以按照时间、大小来设定迭代的 batch 大小，就类似于 Flink 窗口的概念，这样可以支持嵌套迭代、增量迭代等。我们在引擎层面做好了基于流的迭代技术之后，整个机器学习的训练就会大幅度加速。虽然算法本身的效果可能是一样的，但是运行的性能和速度不一样。

同时它还可以解决在线训练的问题，比如说互联网的日志流、用户行为是不停产生的，Flink 流式迭代可以不间断地处理用户产生的实时数据，可以在线迭代更新，模型可以每隔 5 分钟更新一次，也可以每隔 1 分钟更新一次。这样它的模型上线是一个 7×24 小时环状的更新，这样一套在线学习的体系会给用户带来很大的变化，这个变化不是简单的 30% 的提升或者是工程上的优化，而是在使用机器学习的理念上会有优化。

这是我们当前正在做的工作，社区里也已经开始讨论了，可能会作为 Flink 明年 1-2 个版本的重点。你可以这么认为，Flink 去年还是 Unified Engine，今年开始拥抱 AI 了，2019 年我们做的很多工作是偏 SQL 的优化，明年我们会更多地切入到 AI，就是 FlinkML 和 AI 场景的方向上。

\*\*提问：阿里是什么时候决定开源 Alink 的？ 
\*\* 
莫问： 去年 Blink 开源的时候，我们就在考虑是否把 Alink 一起开源了。但是后来觉得，第一个开源还没做，不敢一下子步子迈得这么大，要一步步来，而且 Blink 开源也要准备很多东西。当时我们没有办法做到两个大的项目同时开源，所以就先把 Blink 开源做好。

Blink 开源以后，我们想是不是把 Alink 的算法推到 Flink 就好了。但是发现往社区贡献确实是比较复杂的过程，Blink 在推的时候已经占用了很大的带宽，而社区的带宽就那么多，没有办法同时做多件事情。社区也需要一段时间消耗，所以决定先把 Blink 消耗掉，贡献完了，社区吃得下，然后再把 Alink 逐步贡献回社区。这是没有办法跨越的一个过程。

开源是一个很慎重的过程，不能随意想开就开一个。孩子不能管生不管养，要发东西就要有一个长期的计划，要负责任的，得给大家一个很明确的信号，这是有长期计划的，不是放了开源就结束了，以后肯定会有用户问你们放上去以后管不管？如果我们不想好这些问题，对用户来说就适得其反，大家觉得你并没有给大家一个清晰的信号，大家也不敢用。

**提问：相比 SparkML，Alink 的亮点是什么？对于开发者来说在哪些方面会比较有吸引力？**

莫问：Alink 一是依赖于 Flink 计算引擎层；第二 Flink 框架中有 UDF 的算子，Alink 本身对算法做了很多优化，包括在算法实现上做了细节的优化，比如通信、数据访问、迭代数据处理的流程等多方面的优化。基于这些优化可以让算法运行的效率更高，同时我们还做了很多配套工具，让易用性更好。同时 Alink 还有一个核心技术，就是做了很多 FTRL 的算法，是天然针对在线学习的。在线学习需要高频快速更新的迭代算法，这种情况下 Alink 有天然的优势，像今日头条、微博的信息流都会经常遇到这样的在线场景。


在离线学习上 Alink 跟 SparkML 对比基本上差不多，只要大家工程化都做得足够好，离线学习无法打出代差，真正的代差一定是设计上的理念不一样。设计上、产品形态、技术形态不一样才会有代差明显的优势。

相比 SparkML，我们的基调是批式算法基本一致，包括功能和性能，Alink 可以支持算法工程师常用的所有算法，包括聚类、分类、回归、数据分析、特征工程等，这些类型的算法是算法工程师常用的。我们开源之前也对标了 SparkML 所有的算法，做到了 100% 对标。除此之外，Alink 最大的亮点是有流式算法和在线学习，在自己的特色上能做到独树一帜，这样对用户来说没有短板，同时优势又很明显。


Alink 支持的机器学习算法

后续规划和未来展望
---------

**提问：接下来 Flink 会按照什么样的频率更新版本？能否透露 Flink 接下来还会有哪些值得期待的新特性或功能？**

莫问：3-4 个月，基本上会是一个季度更新一个版本，比如 2020 年 1 月份会发 1.10，4 月份会发 1.11。现在还说不好什么时候切 2.0，2.0 应该会是一个非常有里程碑意义的版本。现在 Flink 社区可以看到非常多的点，不仅有 AI、机器学习，还有今天主题演讲 Stephan Ewen 提到的 Stateful Function，也是非常有前景的。其实在线场景还有很多有前景的东西可以挖掘，Serverless（Faas）也是 Flink 后面的方向。Flink 社区有一点非常好，它刚刚演进到 1.x 版本，还有很大的上升空间，社区的生命力和状态都很好，大家有很多想法想放进去。

**提问：未来大数据领域还有哪些新的技术方向或趋势是比较重要的？**

莫问： 大数据和 AI 的融合可能是一个很好的机会，大家现在纯玩大数据基本上五花八门什么都玩过了，各种项目层出不穷。AI 也是百花争鸣，但其实用户想要的不只是 AI，数据在哪？AI 没有数据怎么玩？得把特征算好、样本算好才能训练出好的模型。这个模型只有经过不断地迭代反馈才能越来越好。这个过程中数据处理和数据分析非常重要，如果没有一套完整的反馈体系，大数据 +AI 的链路玩不通。有再好的引擎，如果没有闭环的计算路径也无法真正发挥生产或业务上的效果。 
所以要把大数据 +AI 整套处理做成非常易用、好用的解决方案，这是大家最需要的。现在可能一个个零散的点大家已经做到了，很多东西都能找到对应的开源项目，但是需要有一个整体的平台把所有技术串起来。

**提问：Flink 在一定程度上也想做这样的？**

莫问： 明年我们会开源一个新的项目 AI Flow，目前还没有 Ready，我们希望 AI Flow 可以通过一个工作流程把数据处理、预处理，包括模型的训练、模型管理、模型上线、动态更新，更新完拿到反馈，反馈之后怎么反向优化流程，整个系统串起来。其中每个环节都可以使用不同的引擎来实现，用 Flink OK，用 Spark 也 OK，就看最后哪个好用。比如可以用 Flink 做大数据处理，TensorFlow 做深度学习训练，FlinkML 做流式训练，把这些都串联起来给用户提供一个端到端的解决方案，这是很有前景的一个项目。

**提问：这是不是跟 Databricks 的 MLflow 有点类似？**

莫问：AI Flow 大于 MLflow，因为 MLflow 只定义了数据格式，AI Flow 可能跟 Kubeflow 更像，AI Flow 偏工作流程，MLflow 偏重于数据格式，没有覆盖特别完整的工作流程，但我们也不排除 MLflow 将来越做越大。

为什么我们要做这个东西？因为我们在阿里巴巴内部非常熟悉整个搜索推荐广告最核心的系统怎么玩，如何一步步流程化才能形成一套大脑去调控整个流量，甚至是搜索流量、推荐流量、广告流量，在业务流量和现金流量去 battle 等，这是整个商业化最核心的系统，这个系统就是基于大数据 +AI 的方案，而这套方案离不开 workflow，离不开数据格式的定义，离不开不同计算引擎的协同，这是更大的一个概念。我们明年会在这方面投入更多资源，也会联合其他的公司一起来做。

 

 

[原文链接](https://link.zhihu.com/?target=https%3A//yq.aliyun.com/articles/727597%3Futm_content%3Dg_1000089494)

本文为云栖社区原创内容，未经允许不得转载。