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

2019-04-26    来源:raincent

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

流计算核心技术

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都会自动帮你做。

 

 

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

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

作为一个用户你可以提出一些问题,去mailing list回答问题,去做testing和report等等

作为一个开发你可以去review code,包括自己的idea,大的重构。还可以帮助其他用户回答问题。

Mailing lists:

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

JIRA: https://issues.apache.org/jira/browse/FLINK

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

Wiki: https://cwiki.apache.org/confluence/display/FLINK

有许多文档,包括大量FLIP,当然也等着大家contribution。

那如何要参与开发呢?

你要在社区提出自己的想法,收集一些建议。

你还要了PMC,commiter对分别对哪部分code负责,你可以联系他,让他帮你review。

可以依靠JIRA处理一些小的问题,但是比较重大的改进还是需要依靠FLIP。

完成之后,就需要去贡献代码,当然要保证代码的质量,加入很多test case,当你pull request时,会有很多人review你的代码,没有问题后就会merge上去。

本文来自于王绍翾在2018年08月11日Flink China Meetup。

王绍翾,花名“大沙”,加州大学圣迭戈分校计算机工程的博士,Apache Flink Commiter。目前在阿里负责Flink平台以及生态的一些工作。

标签: [db:TAGG]

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:解读:乌镇智库《全球人工智能发展报告(2018)》

下一篇:新手指南:大数据、区块链及其结合(附应用场景)