Flink 的新方向在哪里？这场顶级盛会给出了答案

九月的柏林，比杭州多了一丝清冽，与之相对应的，是如火如荼的2018 Flink Forward Berlin（以下简称FFB）会场。在这个初秋，Apache Flink 核心贡献者、行业先锋、实践专家在这里齐聚一堂，围绕Flink发展示状，生态与将来，共话计算之浪潮。值得一提的是，阿里巴巴做为ApacheFlink主要贡献方，受邀参与这次盛会，并发表演讲。

本文主要来自阿里巴巴研究员量仔和阿里巴巴资深技术专家莫问在2018 Flink Forward Berlin会后的分享。

众所周知，Apache Flink是一款分布式、高性能、高可用、高精确的为数据流应用而生的开源流式处理框架。Flink的核心是在数据流上提供数据分发、通讯、具有容错的分布式计算。同时，Flink在流处理引擎上提供了批流融合计算能力，以及SQL表达能力。

Flink Forward旨在聚集大数据领域一流人才共同探讨流计算、实时分析等领先技术。经过参会不只能够了解到Flink社区的最新动态和发展计划，还能够了解到国内外一线大厂围绕Flink生态的生产实践经验，是Flink开发者和使用者不可错过的盛会。

Leager 横空出世， ACID有新解

这次柏林Flink Forward上对于Flink的将来，展示出了几个新的方向：第一，Flink在解决传统的分布式事务（ACID）上作了更多改进。这次柏林Flink Forward上针对ACID提出了一种新的解法，这种方式比传统的分布式事务在性能上有更强的优点，走出了Streaming原有的领域和相关方面的扩张。Flink建立初期主要解决的是流计算方向的问题，随着生态的发展，同时也为解决多方面的需求，Flink 不断提高其解决更多场景的能力。正因如此，当下Flink正在作的场景就是从流计算向一个通用的场景转变。

第二，阿里巴巴在FFB上宣布对于批和流两种计算模型作了更深度的融合，批计算能力对比当前Flink社区版本有了数量级的提高；与此同时，在大数据生态方面，Flink从流处理到如今的批流融合，获得了质的飞跃。从长远角度看，不管是机器学习仍是到其余各个方面的场景，会逐渐将整个Flink生态完善起来。

同时，在大会第一天上午的主论坛中，dataArtisans重磅发布了基于云计算的分布式事务（ACID）的产品Leager，目前Leager发布了2个版本，一个是可试用的单机Streaming版本，另一个是River版本，在DA Platform上有售卖。

Leager API在github上能够查看：

https://github.com/dataArtisans/da-streamingledger

大会现场，经过一个简单的Demo，dataArtisans CTO Stephan Ewen 向听众介绍了在金融行业如何经过Leager解决银行的转帐问题。这是 Flink 生态上，一个新的分布式事务的解决方案。

批流统一，大势所趋

Flink在建立之初，就凭借其能够优雅支持多种计算模式的架构，被业界认为具有先天优点，这也是几年前阿里巴巴选择Flink引擎的一个重要缘由。现在阿里凭借其领先的技术水平，持续优化Flink在批计算处理方面的性能，使批与流之间的界限日渐消弭，真正实现批流统一。

对比Flink，其劲敌Spark也有流批统一的概念，但作法与之大有不一样。Spark是基于批处理作流处理，而且Spark在架构上先天不足，致使其在性能上的提高举步维艰，同时，自然批处理为主的架构为Spark进一步提升吞吐量带来巨大障碍。而Flink的批流统一，从另一个方向去看，是将流做为一切计算的基础。这个方案与Spark相比，最本质的区别在于：第一， Flink是自然的流处理引擎，容许其在流上作到极致；第二，在流上作批，架构上容许把批处理也作到极致。

尽管在当初选择大数据计算引擎时，Spark不管是从热度仍是生态角度也许都比Flink更胜一筹。但从长远考虑，阿里看到其在架构上存在几乎难以逾越的鸿沟，虽然Flink如今没有Spark生态那么火热，可是Flink的先天架构优点，加之诸如阿里这些大厂的支持，相信Flink会开辟出一片新的天空，且走的更远。

三年前，在内部启动Flink时，因其开源产品的特性，很难知足阿里大致量的特定场景需求，为了将Flink在阿里巴巴真正运行起来，阿里巴巴实时计算团队作了大量的优化，并命名Flink在阿里巴巴内部的版本为Blink。Blink在迭代优化的过程当中，也在不断向社区捐赠代码，真正作到“取之开源，用之开源”。

目前，阿里巴巴的实时业务场景，从搜索到广告、数据平台、安全等等。全部大的场景都是基于阿里巴巴内部版本Blink展开，同时经过Stream Compute产品在阿里提供公共云服务。在Flink Forward上，阿里为Flink提出的批流融合新突破，这也是架构上的一个新方向，并已经获得了初步的成果和验证。

蒋晓伟认为Flink新的发展方向有两个，第一个是在传统数据处理领域：包括批流统1、机器学习、以及如何把AI workload融合进来；第二个是Flink和微服务的技术融合创新，从而为在线服务领域带来新的变革。这使得Flink在生态上，也会拥有大的想象空间。

Flink Forward过去只在德国柏林、美国旧金山举办。今年将由阿里巴巴做为独家承办方将这一盛会引入中国，于今年12月在北京落地，共建生态。更多会议信息将于近期发布，敬请关注。

关于Flink，也许你还想了解这些事情

Q：架构上，Flink和Spark相比最大的特色是什么，为何Flink更适合作批流融合统一引擎？

Flink底层是基于Streaming，而Spark底层是基于Batch;这是两个大相径庭的作法，Spark是在RDD的Batch上构建一切，所以Spark构建Streaming须要把RDD作的很是小。 在粗粒度上面构建一个细粒度，在计算上会有不少瓶颈，架构上的问题很难去解决，这也是Spark在Streaming上作的一些事。而Flink自然就是Streaming, Batch就是在Bounded Streaming上的延伸，在架构上是没有多少损失的。所以Flink在走Batch这条路上走下去是没有太多障碍的，而且阿里在Flink上面作了不少针对Batch场景的优化和改进，例如：JOB的调度以及容错，数据Shuffe，任务执行优化上都作了不少工做。

Q： 机器学习在Flink平台应用案例多吗？Flink在AI时代怎么同Spark竞争？

Flink平台应用案例仍是较多的，在阿里内部，几乎一半的计算都是在机器学习上，近年来至关重要的一个趋势就是朝着实时机器学习发展。Flink的批流融合架构，使得其不管在离线仍是实时机器学习领域均可以发挥。首先，在深度学习方面，如今不少算法在业务场景中都获得了很好的应用，做为一个好的计算引擎，都须要和深度学习很好的集成，Flink在这方面也正在作大量的工做；其次，对于传统的机器学习，阿里在Flink上也作了不少工做，并实现以及改进了不少机器学习算法。

Q：将来Flink和Blink发展差别性，或是有多少Feature没办法反馈给社区，对社区是否是一种损失？

阿里特殊的业务体量是不少公司暂时达不到的，这使得阿里在发展的过程当中会更早遇到一些技术瓶颈，天然也会更早的解决这些问题。在解决问题的过程当中，阿里会将对Flink的改进方案通过必定时间的验证确保稳定可行后再贡献给Flink开源社区。固然，Flink社区也是由不少其余公司在支持和使用，因此向社区贡献的过程和节奏是须要必定耐心和时间的，但这个过程确定会愈来愈快，愈来愈顺畅。

Q：持续不按期的批处理算批仍是算流？

批和流的分类不是非黑即白的问题，两者的界限会在批流统一趋势下逐渐模糊。咱们真正要关心的问题是，选择执行计划是什么样的方式。好比一方面从Kafka流式获取数据，同时按期还要从HBase批量获取数据，这个时候已经分不清楚是批仍是流任务了，这就是真正的批流融合了。

Q： Flink DataSet和DataStream API是否能统一？

目前TableAPI/SQL是统一的，但DataSet和DataStream是针对流和批不一样的2个API，阿里如今提出了一个更加底层的DAGAPI，即一个有限无环图来表达计算拓扑的概念，这个拓扑能够表达各类流或者批的语义，图上的点表示算子（能够是流也能够是批算子），中间数据是流式传输仍是批处理传输，整个图也能够是流批混合的，例如：一个Source从Kafka读一个DataStream，另外一个Source按期从HDFS或者HBase读一个DataSet。其余API均可以基于DAGAPI来定义语义，之后DataSet API也许能够和DataStream整合掉，在DataStream中增长有限流的算子，就能够实现批处理了。

Q： Flink SQL 跟 GreenPlum 这样MPP架构的OLAP计算引擎 比起来优点在哪？

从处理场景来讲，Flink SQL更广一些，例如：Flink SQL不只支持短Query，还能够有长query。Flink在Failover上面作的比较全面，但OLAP都是短Query，不怎么须要Failover，所以OLAP引擎能够认为是一种特殊的批处理场景，有着本身特殊的需求和特性。

 

本文做者：期待直播的

本文来自云栖社区合做伙伴“阿里技术”，了解相关信息能够关注“阿里技术”。