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

2019-04-26 来源：raincent

流计算核心技术

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，可以看到几个比较大的问题：

在设计上，从来没想过统一起来。最终Query Optimization翻译完之后到DataStream或者DataSet是完全两条独立的pipline，而且往下的代码是全完不复用的

再一个可以看批计算，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都会自动帮你做。