内容简介:作者: 王绍翾(大沙)本文来自于王绍翾在2018年08月11日Flink China Meetup。王绍翾,花名“大沙”,加州大学圣迭戈分校计算机工程的博士,Apache Flink Commiter。目前在阿里负责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,可以看到几个比较大的问题:
- 在设计上,从来没想过统一起来。最终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:
JIRA: https://issues.apache.org/jir...
是社区的工作方式。Bug,feature,improvements提出的地方,每一个code的贡献都会关联到一个JIRA issue。
Wiki: https://cwiki.apache.org/conf...
有许多文档,包括大量FLIP,当然也等着大家contribution。
那如何要参与开发呢?
- 你要在社区提出自己的想法,收集一些建议。
- 你还要了PMC,commiter对分别对哪部分code负责,你可以联系他,让他帮你review。
- 可以依靠JIRA处理一些小的问题,但是比较重大的改进还是需要依靠FLIP。
- 完成之后,就需要去贡献代码,当然要保证代码的质量,加入很多test case,当你pull request时,会有很多人review你的代码,没有问题后就会merge上去。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 新医药 普华资本李杨:新药投资的机遇与挑战
- 基于FPGA的深度学习加速器综述:挑战与机遇
- 区块链的五大挑战以及AI带来的四大机遇
- 人工智能在过程工业绿色制造中的机遇与挑战
- 李飞飞:云原生分布式数据库面临哪些机遇与挑战?
- FIT 2019 议题前瞻:AI+安全,是机遇亦是挑战 | 前沿安全神盾局
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
HTTP Developer's Handbook
Chris Shiflett / Sams Publishing / 2003-3-29 / USD 39.99
The largest group with an unsatisfied demand for a good book on HTTP is the worldwide group of Web developers. A good book on HTTP can help new and old Web developers alike, as a thorough understandin......一起来看看 《HTTP Developer's Handbook》 这本书的介绍吧!