Flink大数据计算的机遇与挑战

做者: 王绍翾（大沙）

本文来自于王绍翾在2018年08月11日Flink China Meetup。
王绍翾，花名“大沙”，加州大学圣迭戈分校计算机工程的博士，Apache Flink Commiter。目前在阿里负责Flink平台以及生态的一些工做。

本文内容以下：

流计算核心技术

Flink是德国data Artisans创造的，早期Flink主要是作偏批计算的，可是Spark在批处理上已经有必定优点，正面竞争没什么意义，因而改变方向，基于chandy-lamport算法开始作流计算，完成后完美的解决了低延迟问题和状态管理。

低延迟，快速容错

低延迟是Flink源生的，固然保证了快速容错。大数据计算中job老是会失败，因此须要可以快速的恢复。若是平时延迟很低，可是job一失败，恢复几分钟，确定是没法接受的。

通用的API，易用性

Flink有了基础的能力后，开始考虑通用的API，最开始的时候有了一些Java和Scala的一些API。可是发展到必定程度以后，由于API不仅是开放于开发，而是全部用户。怎么样更容易的知足用户的需求和支持用户，这是流计算的很核心的一点。

弹性，高性能

弹性，高性能是大数据不变的主题。怎么样确保引擎在上千台机器不出问题的运行，scalability很重要，包括Spark早期到必定规模遇到不少问题，固然Blink已经完美的解决了全部问题。在性能上，Flink不只是在流计算仍是批处理上已经有了绝对的优点。

流和批的统一

Flink的早期interface是很是弱的，包括Spark早期也是，因而流计算的社区开始讨论流计算的SQL究竟是什么样子的，因而造成了两派风格，一派是认为Streaming SQL是一种different SQL跟Batch Sql，另外一派推的SQL跟Batch SQL是彻底一致的。

为何会说彻底一致？流计算跟批计算一个基本的区别是，都是计算，可是流计算须要提早看到结果，这须要将结果提早发出，可是后面过来的数据会对前面的结果进行修正，因此流计算跟批计算比较大的区别就是数据提早发出和数据修正，最终保证数据正确。

怎么来处理这个问题:

• 首先要告诉用户API，怎么样去计算彻底是用户的语义
• 另外两点就是何时发出去，何时修正，这些跟SQL自己描述是没什么关系的
• 因此传统的ANSI SQL是彻底能够描述流计算的，Flink SQL的语义就是ANSI SQL

用户要什么?

• 高性能
• 高级分析
• 容易开发
• 开箱即用
• 低延迟

咱们说的是大数据，而不只仅是流计算。对于功能型的用户，更关心的是易用性，如何作好分析，如何更好的开发，如何更容易上手。我没学过计算机，可是学的是其余任何的一个行业多是统计，生物，建筑，金融……，怎么样才能更快的开发出来。

假如老板说，今天要部署Flink了，因而给了你50台机器，到了次日，你部署完毕了，做业跑起来了，老板吓呆了，以为你KPI很是的棒。因此开箱即用，更容易的去开发对用户来讲很是须要的。

传统的批计算要追求performance，目前流计算对performance需求愈来愈大。

一.Flink的现状和将来

知道了用户想要的，咱们看Flink现状。

Flink目前被普遍的用于超低延迟流计算场景中，可是Flink在批处理上其实已经有很是高的处理性能，而且在API上流和批是统一的，在性能上和易用性上都有不错的表现。

带着已知的事情和一点点未知的事情，来看看Flink能作的一些事情:流计算已经很是成熟，批计算，AI的计算，包括TF ON Flink，training也好，prediction也好，任何计算。另外还有很大的一块IOT，Hadoop Summit 中强调各类数据中，流的也好，批的也好，最终IOT的数据最大。虽然不是每一个公司都会接触IOT，但它绝对是一个很大的future。

1.阿里巴巴的Blink

Blink1.0其实是enterprise版的Flink，主要专一与流计算上。

Blink2.0是一个统一的引擎，支持流处理和批处理，在其余方面，例如AI方面作了很大的改进，在batch性能上已经远超Spark。回馈社区也是这个版本。

2.Flink SQL Engine的架构

咱们先看一眼Flink SQL Engine，从上面开始有Query的API，有Query Optimization，下来会翻译到DataSteam或者DataSet算子，而后Runtime，在各个集群上运行。这个架构在里面展开DataSteam和DataSet，能够看到几个比较大的问题：

1. 在设计上，历来没想过统一块儿来。最终Query Optimization翻译完以后到DataStream或者DataSet是彻底两条独立的pipline，并且往下的代码是全完不复用的
2. 再一个能够看批计算，DataSet下面还有一个Optimized Plan，这两层优化给统一带来很大的困难

3.Blink SQL Engine的架构

咱们把整个的SQL Engine换成上图所示。从上层开始的API，到下面的Query Processor包括了Query Optimizer和Query Executor，当作完这些发现，代码大量的减小并被复用，一个job用一样的SQL只须要标识是Batch Mode仍是Stream Mode，就会获得同样的结果。

从API开始，翻译成Logical Plan通过Optimizer，再到相似写DataStream的这种Physical Plan，咱们能够看到在Optimizer以前的批跟流彻底同样，SQL同样，Logical Plan也同样。即用户脑子里想的东西，在批和流中如出一辙。

二.优化流计算的挑战和机遇

在Optimizer以后，流和批有些不同。

批和流在同样的地方就是一些简单的filter，predicate，projection还有joining reorder。

区别就是在流计算咱们不去支持sort，由于每条数据一来，就要对以前的数据更新，就比如我让在座的各位称个体重，排个序，忽然在座的哪位去上个厕所，体重变了，会影响不少人的排序，就须要改变大量的结果。因此在流上不去考虑相似sort的东西。可是流上由于有state的使用，怎么样把它的性能变得很高，减小Retraction，怎么样让用户的SLA用MicroBatch去优化。

流计算上一旦变成SQL，就得跑标准的SQL测试，TPC-H，TPC-DS。咱们看这个TPCH13，这个是测试的是用一张Customer表和一张Order表，须要作一次join和count。

这个计算在批计算上处理很方便，由于两个表就在那儿，它明显的知道用户表很小，它会把用户表hash到各个地方先cache下来，而后让订单表流过去，这个性能很是高，由于Order这张最大的表只是不停的流而不落地。

在流计算上怎么处理呢？由于根本不知道数据长什么样子，每边一来就得存下来，左边的Customer表来了以后存下来，由于一行只需存一个，因此用的是ValueState，可是每一个用户有不少的Order，右边的Order表则须要使用MapState，这个计算量很是大，性能很是差。怎么优化呢，咱们使用的SQL就有一个自然的好处Optimizer。SQL Engine有个rule就是转移了上面的countAgg和下面的join，SQL里面有个代数优化，先不考虑数据是什么样子，我从代数上认为中间这幅图和最右边这幅图的计算结果是一致的，因此我能够先对两边进行agg，我能够在Order那一边先把每一个用户count完变成一行只有一个数据，预先处理好数据，这样把Order表压缩成和customer同样大小的表，join上的开销省了不少，state从庞大的MapState变成了轻量的ValueState，性能提高了25倍，这也是为何SQL是有意义的。

对于一些流计算的特有优化，好比知道用户的SLA，有段时间就能够去配置mini-batch 。

作全网的count，那么用以上左图的红色和紫色，分别发送到一个地方去统计，不作预处理的话，红色节点负载太高，很快就致使反压。最好的办法就是红色和紫色的节点如今上游chain起来作预处理，至关于把一个聚合分红两部分，先作count，再作sum。

固然上面的方案不老是有效，好比count distinct，它也须要按颜色group by还要按某一列去distinct，致使不一样的数据没法被预聚合。因此在local-global上除了chain的方式还有shuffle的方式，至关于shuffle两次，也就是你们在流计算中所说的打散。第一次按distinct key去shuffle，第二次用group by的key去作shuffle。固然这些都是SQL Engine都会自动帮你作。

三.融入开源社区，参与开源开发

开源社区除了coding的贡献外，还有文档，生态，社区，产品，只要对这个开源的产品有帮助。更重要的是你在社区里面的活跃度，为社区解决什么问题。

做为一个用户你能够提出一些问题，去mailing list回答问题，去作testing和report等等

做为一个开发你能够去review code，包括本身的idea，大的重构。还能够帮助其余用户回答问题。

Mailing lists：

dev@flink.apache.org 开发者提问交流。

user@flink.apache.org 用户提问交流。

JIRA: https://issues.apache.org/jir...

是社区的工做方式。Bug，feature，improvements提出的地方，每个code的贡献都会关联到一个JIRA issue。

Wiki: https://cwiki.apache.org/conf...

有许多文档，包括大量FLIP，固然也等着你们contribution。

那如何要参与开发呢？

1. 你要在社区提出本身的想法，收集一些建议。
2. 你还要了PMC，commiter对分别对哪部分code负责，你能够联系他，让他帮你review。
3. 能够依靠JIRA处理一些小的问题，可是比较重大的改进仍是须要依靠FLIP。
4. 完成以后，就须要去贡献代码，固然要保证代码的质量，加入不少test case，当你pull request时，会有不少人review你的代码，没有问题后就会merge上去。

更多资讯请访问 Apache Flink 中文社区网站