13518219792
作者: 王绍翾（大沙）
成都创新互联是一家专注于成都网站设计、做网站与策划设计,台州网站建设哪家好?成都创新互联做网站,专注于网站建设十载,网设计领域的专业建站公司;建站业务涵盖:台州等地区。台州做网站价格咨询:028-86922220
本文来自于王绍翾在2018年08月11日Flink China Meetup。
王绍翾，花名“大沙”，加州大学圣迭戈分校计算机工程的博士，Apache Flink Commiter。目前在阿里负责Flink平台以及生态的一些工作。
本文内容如下：
Flink是德国data Artisans创造的，早期Flink主要是做偏批计算的，但是Spark在批处理上已经有一定优势，正面竞争没什么意义，于是改变方向，基于chandy-lamport算法开始做流计算，完成后完美的解决了低延迟问题和状态管理。
低延迟是Flink源生的，当然保证了快速容错。大数据计算中job总是会失败，所以需要能够快速的恢复。如果平时延迟很低，但是job一失败，恢复几分钟，肯定是无法接受的。
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本身描述是没什么关系的
高性能
高级分析
容易开发
开箱即用
cdn.xitu.io/2019/4/25/16a539a2cf310379?w=1055&h=563&f=jpeg&s=123260">
我们说的是大数据，而不仅仅是流计算。对于功能型的用户，更关心的是易用性，如何做好分析，如何更好的开发，如何更容易上手。我没学过计算机，但是学的是其他任何的一个行业可能是统计，生物，建筑，金融……，怎么样才能更快的开发出来。
假如老板说，今天要部署Flink了，于是给了你50台机器，到了第二天，你部署完毕了，作业跑起来了，老板吓呆了，觉得你KPI非常的棒。所以开箱即用，更容易的去开发对用户来说非常需要的。
传统的批计算要追求performance，目前流计算对performance需求越来越大。
知道了用户想要的，我们看Flink现状。
Flink目前被广泛的用于超低延迟流计算场景中，但是Flink在批处理上其实已经有非常高的处理性能，并且在API上流和批是统一的，在性能上和易用性上都有不错的表现。
带着已知的事情和一点点未知的事情，来看看Flink能做的一些事情:流计算已经非常成熟，批计算，AI的计算，包括TF ON Flink，training也好，prediction也好，任何计算。另外还有很大的一块IOT，Hadoop Summit 中强调各种数据中，流的也好，批的也好，最终IOT的数据最大。虽然不是每个公司都会接触IOT，但它绝对是一个很大的future。
Blink1.0实际上是enterprise版的Flink，主要专注与流计算上。
Blink2.0是一个统一的引擎，支持流处理和批处理，在其他方面，例如AI方面做了很大的改进，在batch性能上已经远超Spark。回馈社区也是这个版本。
我们先看一眼Flink SQL Engine，从上面开始有Query的API，有Query Optimization，下来会翻译到DataSteam或者DataSet算子，然后Runtime，在各个集群上运行。这个架构在里面展开DataSteam和DataSet，可以看到几个比较大的问题：
在设计上，从来没想过统一起来。最终Query Optimization翻译完之后到DataStream或者DataSet是完全两条独立的pipline，而且往下的代码是全完不复用的
我们把整个的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/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。
更多资讯请访问 Apache Flink 中文社区网站
