阿里巴巴为何选择Apache Flink？

本文主要整理自阿里巴巴计算平台事业部资深技术专家莫问在云栖大会的演讲。

合抱之木，生于毫末

随着人工智能时代的降临，数据量的爆发，在典型的大数据的业务场景下数据业务最通用的作法是：选用批处理的技术处理全量数据，采用流式计算处理实时增量数据。在绝大多数的业务场景之下，用户的业务逻辑在批处理和流处理之中每每是相同的。可是，用户用于批处理和流处理的两套计算引擎是不一样的。

所以，用户一般须要写两套代码。毫无疑问，这带来了一些额外的负担和成本。阿里巴巴的商品数据处理就常常须要面对增量和全量两套不一样的业务流程问题，因此阿里就在想，咱们能不能有一套统一的大数据引擎技术，用户只须要根据本身的业务逻辑开发一套代码。这样在各类不一样的场景下，不论是全量数据仍是增量数据，亦或者实时处理，一套方案便可所有支持，这就是阿里选择Flink的背景和初衷。

目前开源大数据计算引擎有不少选择，流计算如Storm,Samza,Flink,Kafka Stream等，批处理如Spark,Hive,Pig,Flink等。而同时支持流处理和批处理的计算引擎，只有两种选择：一个是Apache Spark，一个是Apache Flink。

从技术，生态等各方面的综合考虑。首先，Spark的技术理念是基于批来模拟流的计算。而Flink则彻底相反，它采用的是基于流计算来模拟批计算。

从技术发展方向看，用批来模拟流有必定的技术局限性，而且这个局限性可能很难突破。而Flink基于流来模拟批，在技术上有更好的扩展性。从长远来看，阿里决定用Flink作一个统一的、通用的大数据引擎做为将来的选型。

Flink是一个低延迟、高吞吐、统一的大数据计算引擎。在阿里巴巴的生产环境中，Flink的计算平台能够实现毫秒级的延迟状况下，每秒钟处理上亿次的消息或者事件。同时Flink提供了一个Exactly-once的一致性语义。保证了数据的正确性。这样就使得Flink大数据引擎能够提供金融级的数据处理能力。

Flink在阿里的现状

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

目前，这套基于Flink搭建的实时计算平台不只服务于阿里巴巴集团内部，并且经过阿里云的云产品API向整个开发者生态提供基于Flink的云产品支持。

Flink在阿里巴巴的大规模应用，表现如何？

规模：一个系统是否成熟，规模是重要指标，Flink最初上线阿里巴巴只有数百台服务器，目前规模已达上万台，此等规模在全球范围内也是屈指可数；

状态数据：基于Flink，内部积累起来的状态数据已是PB级别规模；

Events：现在天天在Flink的计算平台上，处理的数据已经超过万亿条；

PS：在峰值期间能够承担每秒超过4.72亿次的访问，最典型的应用场景是阿里巴巴双11大屏；

Flink的发展之路

接下来从开源技术的角度，来谈一谈Apache Flink是如何诞生的，它是如何成长的？以及在成长的这个关键的时间点阿里是如何进入的？并对它作出了那些贡献和支持？

Flink诞生于欧洲的一个大数据研究项目StratoSphere。该项目是柏林工业大学的一个研究性项目。早期，Flink是作Batch计算的，可是在2014年，StratoSphere里面的核心成员孵化出Flink，同年将Flink捐赠Apache，并在后来成为Apache的顶级大数据项目，同时Flink计算的主流方向被定位为Streaming，即用流式计算来作全部大数据的计算，这就是Flink技术诞生的背景。

2014年Flink做为主攻流计算的大数据引擎开始在开源大数据行业内崭露头角。区别于Storm,Spark Streaming以及其余流式计算引擎的是：它不只是一个高吞吐、低延迟的计算引擎，同时还提供不少高级的功能。好比它提供了有状态的计算，支持状态管理，支持强一致性的数据语义以及支持Event Time,WaterMark对消息乱序的处理。

Flink核心概念以及基本理念

Flink最区别于其余流计算引擎的，其实就是状态管理。

什么是状态？例如开发一套流计算的系统或者任务作数据处理，可能常常要对数据进行统计，如Sum,Count,Min,Max,这些值是须要存储的。由于要不断更新，这些值或者变量就能够理解为一种状态。若是数据源是在读取Kafka,RocketMQ，可能要记录读取到什么位置，并记录Offset，这些Offset变量都是要计算的状态。

Flink提供了内置的状态管理，能够把这些状态存储在Flink内部，而不须要把它存储在外部系统。这样作的好处是第一下降了计算引擎对外部系统的依赖以及部署，使运维更加简单；第二，对性能带来了极大的提高：若是经过外部去访问，如Redis,HBase它必定是经过网络及RPC。若是经过Flink内部去访问，它只经过自身的进程去访问这些变量。同时Flink会按期将这些状态作Checkpoint持久化，把Checkpoint存储到一个分布式的持久化系统中，好比HDFS。这样的话，当Flink的任务出现任何故障时，它都会从最近的一次Checkpoint将整个流的状态进行恢复，而后继续运行它的流处理。对用户没有任何数据上的影响。

Flink是如何作到在Checkpoint恢复过程当中没有任何数据的丢失和数据的冗余？来保证精准计算的？

这其中缘由是Flink利用了一套很是经典的Chandy-Lamport算法，它的核心思想是把这个流计算当作一个流式的拓扑，按期从这个拓扑的头部Source点开始插入特殊的Barries，从上游开始不断的向下游广播这个Barries。每个节点收到全部的Barries,会将State作一次Snapshot，当每一个节点都作完Snapshot以后，整个拓扑就算完整的作完了一次Checkpoint。接下来无论出现任何故障，都会从最近的Checkpoint进行恢复。

Flink利用这套经典的算法，保证了强一致性的语义。这也是Flink与其余无状态流计算引擎的核心区别。

下面介绍Flink是如何解决乱序问题的。好比星球大战的播放顺序，若是按照上映的时间观看，可能会发现故事在跳跃。

在流计算中，与这个例子是很是相似的。全部消息到来的时间，和它真正发生在源头，在线系统Log当中的时间是不一致的。在流处理当中，但愿是按消息真正发生在源头的顺序进行处理，不但愿是真正到达程序里的时间来处理。Flink提供了Event Time和WaterMark的一些先进技术来解决乱序的问题。使得用户能够有序的处理这个消息。这是Flink一个很重要的特色。

接下来要介绍的是Flink启动时的核心理念和核心概念，这是Flink发展的第一个阶段；第二个阶段时间是2015年和2017年，这个阶段也是Flink发展以及阿里巴巴介入的时间。故事源于2015年年中，咱们在搜索事业部的一次调研。当时阿里有本身的批处理技术和流计算技术，有自研的，也有开源的。可是，为了思考下一代大数据引擎的方向以及将来趋势，咱们作了不少新技术的调研。

结合大量调研结果，咱们最后得出的结论是：解决通用大数据计算需求，批流融合的计算引擎，才是大数据技术的发展方向，而且最终咱们选择了Flink。

但2015年的Flink还不够成熟，不论是规模仍是稳定性还没有经历实践。最后咱们决定在阿里内部创建一个Flink分支，对Flink作大量的修改和完善，让其适应阿里巴巴这种超大规模的业务场景。在这个过程中，咱们团队不只对Flink在性能和稳定性上作出了不少改进和优化，同时在核心架构和功能上也进行了大量创新和改进，并将其贡献给社区，例如：Flink新的分布式架构，增量Checkpoint机制,基于Credit-based的网络流控机制和Streaming SQL等。

阿里巴巴对Flink社区的贡献

咱们举两个设计案例，第一个是阿里巴巴重构了Flink的分布式架构，将Flink的Job调度和资源管理作了一个清晰的分层和解耦。这样作的首要好处是Flink能够原生的跑在各类不一样的开源资源管理器上。通过这套分布式架构的改进，Flink能够原生地跑在Hadoop Yarn和Kubernetes这两个最多见的资源管理系统之上。同时将Flink的任务调度从集中式调度改成了分布式调度，这样Flink就能够支持更大规模的集群，以及获得更好的资源隔离。

另外一个是实现了增量的Checkpoint机制，由于Flink提供了有状态的计算和按期的Checkpoint机制，若是内部的数据愈来愈多，不停地作Checkpoint,Checkpoint会愈来愈大，最后可能致使作不出来。提供了增量的Checkpoint后，Flink会自动地发现哪些数据是增量变化，哪些数据是被修改了。同时只将这些修改的数据进行持久化。这样Checkpoint不会随着时间的运行而愈来愈难作，整个系统的性能会很是地平稳，这也是咱们贡献给社区的一个很重大的特性。

通过2015年到2017年对Flink Streaming的能力完善，Flink社区也逐渐成熟起来。Flink也成为在Streaming领域最主流的计算引擎。由于Flink最先期想作一个流批统一的大数据引擎，2018年已经启动这项工做，为了实现这个目标，阿里巴巴提出了新的统一API架构，统一SQL解决方案，同时流计算的各类功能获得完善后，咱们认为批计算也须要各类各样的完善。不管在任务调度层，仍是在数据Shuffle层，在容错性，易用性上，都须要完善不少工做。

篇幅缘由，下面主要和你们分享两点：

 ●  统一 API Stack
 ●  统一 SQL方案

先来看下目前Flink API Stack的一个现状，调研过Flink或者使用过Flink的开发者应该知道。Flink有2套基础的API，一套是DataStream，一套是DataSet。DataStream API是针对流式处理的用户提供，DataSet API是针对批处理用户提供，可是这两套API的执行路径是彻底不同的，甚至须要生成不一样的Task去执行。因此这跟获得统一的API是有冲突的，并且这个也是不完善的，不是最终的解法。在Runtime之上首先是要有一个批流统一融合的基础API层，咱们但愿能够统一API层。

所以，咱们在新架构中将采用一个DAG（有限无环图）API，做为一个批流统一的API层。对于这个有限无环图，批计算和流计算不须要泾渭分明的表达出来。只须要让开发者在不一样的节点，不一样的边上定义不一样的属性，来规划数据是流属性仍是批属性。整个拓扑是能够融合批流统一的语义表达，整个计算无需区分是流计算仍是批计算，只须要表达本身的需求。有了这套API后，Flink的API Stack将获得统一。

除了统一的基础API层和统一的API Stack外，一样在上层统一SQL的解决方案。流和批的SQL，能够认为流计算有数据源，批计算也有数据源，咱们能够将这两种源都模拟成数据表。能够认为流数据的数据源是一张不断更新的数据表，对于批处理的数据源能够认为是一张相对静止的表，没有更新的数据表。整个数据处理能够当作SQL的一个Query，最终产生的结果也能够模拟成一个结果表。

对于流计算而言，它的结果表是一张不断更新的结果表。对于批处理而言，它的结果表是至关于一次更新完成的结果表。从整个SOL语义上表达，流和批是能够统一的。此外，不论是流式SQL，仍是批处理SQL，均可以用同一个Query来表达复用。这样以来流批均可以用同一个Query优化或者解析。甚至不少流和批的算子都是能够复用的。

Flink的将来方向

首先，阿里巴巴仍是要立足于Flink的本质，去作一个全能的统一大数据计算引擎。将它在生态和场景上进行落地。目前Flink已是一个主流的流计算引擎，不少互联网公司已经达成了共识：Flink是大数据的将来，是最好的流计算引擎。下一步很重要的工做是让Flink在批计算上有所突破。在更多的场景下落地，成为一种主流的批计算引擎。而后进一步在流和批之间进行无缝的切换，流和批的界限愈来愈模糊。用Flink,在一个计算中，既能够有流计算，又能够有批计算。

第二个方向就是Flink的生态上有更多语言的支持，不只仅是Java，Scala语言，甚至是机器学习下用的Python，Go语言。将来咱们但愿能用更多丰富的语言来开发Flink计算的任务，来描述计算逻辑，并和更多的生态进行对接。

最后不得不说AI，由于如今不少大数据计算的需求和数据量都是在支持很火爆的AI场景，因此在Flink流批生态完善的基础上，将继续往上走，完善上层Flink的Machine Learning算法库，同时Flink往上层也会向成熟的机器学习，深度学习去集成。好比能够作Tensorflow On Flink, 让大数据的ETL数据处理和机器学习的Feature计算和特征计算，训练的计算等进行集成，让开发者可以同时享受到多种生态给你们带来的好处。

本文做者：莫问

阅读原文
)

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。