导读：随着人工智能时期的降临，数据量的爆发，阿里巴巴的商品数据处理就常常须要面对增量和全量两套不同的业务流程问题，以是阿里巴巴就在想：能不能有一套统一的大数据引擎技能，用户只须要根据自己的业务逻辑开拓一套代码。
这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持，这便是阿里巴巴选择 Flink 的背景和初衷。

彼时的 Flink 不管是规模还是稳定性尚未经历实践，成熟度有待商榷。
阿里巴巴实时打算团队决定在阿里内部建立一个 Flink 分支 Blink，并对 Flink 进行大量的修正和完善，让其适应阿里巴巴这种超大规模的业务场景。
那么，阿里巴巴对 Flink 究竟做了哪些优化呢？

Apache Flink 概述

Apache Flink（以下简称 Flink）是出身于欧洲的一个大数据研究项目，原名 StratoSphere。
该项目是柏林工业大学的一个研究性项目，早期专注于批打算。
2014 年，StratoSphere 项目中的核心成员孵化出 Flink，并在同年将 Flink 捐赠 Apache，后来 Flink 顺利成为 Apache 的顶级大数据项目。
同时 Flink 打算的主流方向被定位为流打算，即用流式打算来做所有大数据的打算事情，这便是 Flink 技能出身的背景。

2014 年 Flink 作为主攻流打算的大数据引擎开始在开源大数据行业内崭露锋芒。
差异于 Storm、Spark Streaming 以及其他流式打算引擎的是：它不仅是一个高吞吐、低延迟的打算引擎，同时还供应很多高等功能。
比如它供应有状态的打算，支持状态管理，支持强同等性的数据语义以及支持 Event Time,WaterMark 对乱序的处理等。

Flink 的受欢迎还离不开它身上的浩瀚标签，个中包括性能精良（尤其在流打算领域）、高可扩展性、支持容错，是一种纯内存式的一个打算引擎，做了内存管理方面的大量优化，其余也支持 eventime 的处理、支持超大状态的 Job（在阿里巴巴中作业的 state 大小超过 TB 的是非常常见的）、支持 exactly-once 的处理。

阿里巴巴与 Flink

随着人工智能时期的降临，数据量的爆发，在范例的大数据的业务场景下数据业务最通用的做法是：选用批处理的技能处理全量数据，采取流式打算处理实时增量数据。
在绝大多数的业务场景之下，用户的业务逻辑在批处理和流处理之中每每是相同的。
但是，用户用于批处理和流处理的两套打算引擎是不同的。

因此，用户常日须要写两套代码。
毫无疑问，这带来了一些额外的包袱和本钱。
阿里巴巴的商品数据处理就常常须要面对增量和全量两套不同的业务流程问题，以是阿里巴巴就在想：能不能有一套统一的大数据引擎技能，用户只须要根据自己的业务逻辑开拓一套代码。
这样在各种不同的场景下，不管是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持，这便是阿里巴巴选择 Flink 的背景和初衷。

基于 Flink 在阿里巴巴搭建的平台于 2016 年正式上线，并从阿里巴巴的搜索和推举这两大场景开始实现。
目前阿里巴巴所有的业务，包括阿里巴巴所有子公司都采取了基于 Flink 搭建的实时打算平台。
同时 Flink 打算平台运行在开源的 Hadoop 集群之上。
采取 Hadoop 的 YARN 做为资源管理调度，以 HDFS 作为数据存储。
因此，Flink 可以和开源大数据软件 Hadoop 无缝对接。

目前，这套基于 Flink 搭建的实时打算平台不仅做事于阿里巴巴集团内部，而且通过阿里云的云产品 API 向全体开拓者生态供应基于 Flink 的云产品支持。

彼时的 Flink 不管是规模还是稳定性尚未经历实践，成熟度有待商榷。
阿里巴巴实时打算团队决定在阿里内部建立一个 Flink 分支 Blink，并对 Flink 进行大量的修正和完善，让其适应阿里巴巴这种超大规模的业务场景。
在这个过程当中，该团队不仅对 Flink 在性能和稳定性上做出了很多改进和优化，同时在核心架构和功能上也进行了大量创新和改进，并将逐渐推回给社区，例如：Flink 新的分布式架构，增量 Checkpoint 机制, 基于 Credit-based 的网络流控机制和 Streaming SQL 等。
接下来，我们紧张从两个层面深度阐发阿里巴巴对 Flink 究竟做了哪些优化？

取之开源，用之开源一、 SQL 层

为了能够真正做到用户根据自己的业务逻辑开拓一套代码，能够同时运行在多种不同的场景，Flink 首先须要给用户供应一个统一的 API。
在经由一番调研之后，阿里巴巴实时打算认为 SQL 是一个非常适宜的选择。
在批处理领域，SQL 已经经历了几十年的磨练，是公认的经典。
在流打算领域，近年来也不断有流表二象性、流是表的 ChangeLog 等理论涌现。
在这些理论根本之上，阿里巴巴提出了动态表的观点，使得流打算也可以像批处理一样利用 SQL 来描述，并且逻辑等价。
这样一来，用户就可以利用 SQL 来描述自己的业务逻辑，相同的查询语句在实行时可以是一个批处理任务，也可以是一个高吞吐低延迟的流打算任务，乃至是先利用批处理技能进行历史数据的打算，然后自动的转成流打算任务处理最新的实时数据。
在这种声明式的 API 之下，引擎有了更多的选择和优化空间。
接下来，我们将先容个中几个比较主要的优化。

首先是对 SQL 层的技能架构进行升级和更换。
调研过 Flink 或者利用过 Flink 的开拓者该当知道，Flink 有两套根本的 API，一套是 DataStream，另一套是 DataSet。
DataStream API 是针对流式处理的用户供应，DataSet API 是针对批处理用户供应，但是这两套 API 的实行路径是完备不一样的，乃至须要天生不同的 Task 去实行。
Flink 原生的 SQL 层在经由一系列优化之后，会根据用户希望是批处理还是流处理的不同选择，去调用 DataSet 或者是 DataStream API。
这就会造成用户在日常开拓和优化中，常常要面临两套险些完备独立的技能栈，很多事情可能须要重复的去做两遍。
这样也会导致在一边的技能栈上做的优化，其余一边就享受不到。
因此阿里巴巴在 SQL 层提出了全新的 Quyer Processor，它紧张包括一个流和批可以只管即便做到复用的优化层（Query Optimizer）以及基于相同接口的算子层（Query Executor）。
这样一来， 80% 以上的事情可以做到两边复用，比如一些公共的优化规则，根本数据构造等等。
同时，流和批也会各自保留自己一些独特的优化和算子，以知足不同的作业行为。

在 SQL 层的技能架构统一之后，阿里巴巴开始寻求一种更高效的根本数据构造，以便让 Blink 在 SQL 层的实行更加高效。
在原生 Flink SQL 中，都统一利用了一种叫 Row 的数据构造，它完备由 JAVA 的一些工具构成关系数据库中的一行。
如果现在的一行数据由一个整型，一个浮点型以及一个字符串组成，那么 Row 当中就会包含一个 JAVA 的 Integer、Double 和 String。
众所周知，这些 JAVA 的工具在堆内有不少的额外开销，同时在访问这些数据的过程中也会引入不必要的装箱拆箱操作。
基于这些问题，阿里巴巴提出了一种全新的数据构造 BinaryRow，它和原来的 Row 一样也是表示一个关系数据中的一行，但与之不同的是，它完备利用二进制数据来存储这些数据。
在上述例子中，三个不同类型的字段统一由 JAVA 的 byte[] 来表示。
这会带来诸多好处：

首先在存储空间上，去掉了很多无谓的额外花费，使得工具的存储更为紧凑；其次在和网络或者状态存储打交道的时候，也可以省略掉很多不必要的序列化反序列化开销；末了在去掉各种不必要的装箱拆箱操作之后，全体实行代码对 GC 也更加友好。

通过引入这样一个高效的根本数据构造，全体 SQL 层的实行效率得到了一倍以上的提升。

在算子的实现层面，阿里巴巴引入了更广范围的代码天生技能。
得益于技能架构和根本数据构造的统一，很多代码天生技能得以达到更广范围的复用。
同时由于 SQL 的强类型担保，用户可以预先知道算子须要处理的数据的类型，从而可以天生更有针对性更高效的实行代码。
在原生 Flink SQL 中，只有类似 a > 2 或者 c + d 这样的大略表达式才会运用代码天生技能，在阿里巴巴优化之后，有一些算子会进行整体的代码天生，比如排序、聚合等。
这使得用户可以更加灵巧的去掌握算子的逻辑，也可以直接将终极运行代码嵌入到类当中，去掉了昂贵的函数调用开销。
一些运用代码天生技能的根本数据构造和算法，比如排序算法，基于二进制数据的 HashMap 等，也可以在流和批的算子之间进行共享和复用，让用户真正享受到了技能和架构的统一带来的好处。
在针对批处理的某些场景进行数据构造或者算法的优化之后，流打算的性能也能够得到提升。
接下来，我们聊聊阿里巴巴在 Runtime 层对 Flink 又大刀阔斧地进行了哪些改进。

二、Runtime 层

为了让 Flink 在 Alibaba 的大规模生产环境中生根萌芽，实时打算团队准期碰着了各种寻衅，首当其冲的便是如何让 Flink 与其他集群管理系统进行整合。
Flink 原生集群管理模式尚未完善，也无法原生地利用其他其他相对成熟的集群管理系统。
基于此，一系列棘手的问题接连浮现：多租户之间资源如何折衷？如何动态的申请和开释资源？如何指定不同资源类型？

为理解决这个问题，实时打算团队经历大量的调研与剖析，终极选择的方案是改造 Flink 资源调度系统，让 Flink 可以原生地跑在 Yarn 集群之上；并且重构 Master 架构，让一个 Job 对应一个 Master，从此 Master 不再是集群瓶颈。
以此为契机，阿里巴巴和社区联手推出了全新的 Flip-6 架构，让 Flink 资源管理变成可插拔的架构，为 Flink 的可持续发展打下了坚实的根本。
如今 Flink 可以无缝运行在 YARN、Mesos 和 K8s 之上，正是这个架构主要性的有力解释。

办理了 Flink 集群大规模支配问题后，接下来的便是可靠和稳定性，为了担保 Flink 在生产环境中的高可用，阿里巴巴着重改进了 Flink 的 FailOver 机制。
首先是 Master 的 FailOver，Flink 原生的 Master FailOver 会重启所有的 Job，改进后 Master 任何 FailOver 都不会影响 Job 的正常运行；其次引入了 Region-based 的 Task FailOver，只管即便减少任何 Task 的 FailOver 对用户造成的影响。
有了这些改进的保驾护航，阿里巴巴的大量业务方开始把实时打算迁移到 Flink 上运行。

Stateful Streaming 是 Flink 的最大亮点，基于 Chandy-Lamport 算法的 Checkpoint 机制让 Flink 具备 Exactly Once 同等性的打算能力，但在早期 Flink 版本中 Checkpoint 的性能在大规模数据量下存在一定瓶颈，阿里巴巴也在 Checkpoint 上进行了大量改进，比如：

增量 Checkpoint 机制：阿里巴巴生产环境中碰着大 JOB 有几十 TB State 是常事，做一次全量 CP 地动山摇，本钱很高，因此阿里巴巴研发了增量 Checkpoint 机制，从此之后 CP 从狂风骤雨变成了细水长流；Checkpoint 小文件合并：都是规模惹的祸，随着全体集群 Flink JOB 越来越多，CP 文件数也水涨船高，末了压的 HDFS NameNode 不堪重负，阿里巴巴通过把多少 CP 小文件合并成一个大文件的组织办法，终极把 NameNode 的压力减少了几十倍。

虽然说所有的数据可以放在 State 中，但由于一些历史的缘故原由，用户依然有一些数据须要存放在像 HBase 等一些外部 KV 存储中，用户在 Flink Job 须要访问这些外部的数据，但是由于 Flink 一贯都是单线程处理模型，导致访问外部数据的延迟成为全体系统的瓶颈，显然异步访问是办理这个问题的直接手段，但是让用户在 UDF 中写多线程同时还要担保 ExactlyOnce 语义，却并非易事。
阿里巴巴在 Flink 中提出了 AsyncOperator，让用户在 Flink JOB 中写异步调用和写“Hello Word”一样大略 ，这个让 Flink Job 的吞吐有了很大的飞跃。

Flink 在设计上是一套批流统一的打算引擎，在利用过快如闪电的流打算之后，批用户也开始有兴趣入住 Flink 小区。
但批打算也带来了新的寻衅，首先在任务调度方面，阿里巴巴引入了更加灵巧的调度机制，能够根据任务之间的依赖关系进行更加高效的调度；其次便是数据 Shuffle，Flink 原生的 Shuffle Service 和 TM 绑定，任务实行完之后要依旧保持 TM 无法开释资源；还有便是原有的 Batch shuffle 没有对文件进行合并，以是基本无法在生产中利用。
阿里巴巴开拓了 Yarn Shuffle Service 功能的同时办理了以上两个问题。
在开拓 Yarn Shuffle Service 的时候，阿里巴巴创造开拓一套新的 Shuffle Service 非常不便，须要侵入 Flink 代码的很多地方，为了让其他开拓者方便的扩展不同 Shuffle，阿里巴巴同时改造了 Flink Shuffle 架构，让 Flink 的 Shuffle 变成可插拔的架构。
目前阿里巴巴的搜索业务已经在利用 Flink Batch Job，并且已经开始做事于生产。

经由 3 年多打磨，Blink 已经在阿里巴巴开始茁壮成长，但是对 Runtime 的优化和改进是永无止境的，一大波改进和优化正在路上。

Flink 的未来方向

目前 Flink 已经成为一个主流的流打算引擎，社区下一步很主要的事情是让 Flink 在批打算上有所打破，在更多的场景着落地，成为一种主流的批打算引擎。
然后进一步在流和批之间进行无缝切换，使流和批的界线越来越模糊。
用 Flink，在一个打算中，既可以有流打算，又可以有批打算。

接下来阿里巴巴还将致力于推动 Flink 在生态上得到更多措辞的支持，不仅仅是 Java、Scala 措辞，乃至是机器学习下用的 Python、Go 措辞。

另一点不得不说 AI，由于现在很多大数据打算的需求和数据量都是在支持很火爆的 AI 场景，以是 Flink 在流批生态完善的根本上，将连续完善上层的 Machine Learning 算法库，同时 Flink 也会向更成熟的机器学习、深度学习去集成。
比如可以做 Tensorflow On Flink, 让大数据的 ETL 数据处理和机器学习的 Feature 打算和特色打算，演习的打算等进行集成，让开发者能够同时享受到多种生态给大家带来的好处。

末了，从生态、社区的生动来说，阿里巴巴目前在推进的一件事情是预备 2018 年 12 月 20 日 -21 日在国家会议中央举办的首届 Flink Forward China 峰会（千人规模），参与者将有机会理解阿里巴巴、腾讯、华为、滴滴、美团、字节跳动等公司为何将 Flink 作为首选的流处理引擎。

作者 | 阿里巴巴