从两个讲座看Blink即将开源

昨天阿里巴巴宣布Blink2019年初开源，后台很多人让我聊聊Blink开源这个事情。我这里总结一下两个和Blink有关的讲座给大家。希望对大家理解Blink开源这个事情有所帮助。本文非常的偏技术。

个讲座是今年在里约热内卢的VLDB会场周靖人博士做的关于大数据分析未来的讲座，我之前发过文了：阿里巴巴在VLDB展示的新想法：融合数据分析 讲座里周靖人博士介绍了他领导的团队如何针对不同的数据分析引擎提供统一的查询语言，统一的优化，引入时间的维度等很多想法。具体内容如下。

----------------------------------------------------------------------------------------------

阿里巴巴今年在VLDB给了一个讲座，讲述了阿里巴巴的一些新想法：融合数据分，讲的比较精彩。主要的内容如下。

在现实里，我们一般都有多个不同的数据分析引擎。以阿里巴巴为例的话，有Blink这样的流计算引擎，有MaxCompute这样对应HIVE的batch引擎，有AnalyticDB这样的分析引擎，有PolarDB这样的HTAP等。如果我们去看亚马逊，也有类似的，Kenisis/Aurora/Athena/Redshift等若干分析引擎。

这些引擎的latency都不一样。一般来说，latency比较低的，消耗的资源就会比较多一些。

从这个讲座里，阿里巴巴对未来的这些引擎的看法是，用户用SQL或者类似SQL的方式告诉系统用户想干什么（而不是怎么干）。这个语言也可以提供latency和资源消耗的限制。

然后MaxCompute就可以通过查询优化的方式，选择出为合适的引擎完成计算。当然，从后续的讲座可以看到，这个选择为合适的计算引擎，并不是说只是用一个引擎，有的时候，整个计算的一部分可以在引擎A里面做，而另外一部分可以在引擎B里做。

这就对我们现存的query plan和query optimization（查询优化）提出了很大的挑战。在这里，核心的属性是在整个查询优化过程中，运行节点引入了时间戳的概念。

这样一来，对查询优化的挑战就很巨大了。查询优化本来的目标是减少中间结果的输出，但是在这个新的假设下，优化的目标就不是这样单纯了。

这个讲座里给了一个这种场景下的优化的例子：

按照我的理解，这个想法目前尚处于早期阶段，并未进入产品化。这是可以理解的。因为这个东西很难，确实是非常的难。

查询优化自诞生以来，虽然查询优化框架，推理的规则，stats的搜集等各方面都有很多的进步，诞生查询优化的目标从来都没有变过。简单而言是找到能够早完成该查询的执行方案。

但是在这个系统里，查询优化要解决的显然不是同一个问题，时间戳的引入，资源消耗的引入，不同优化目标的引入，这些东西放在一起，必然对目前流行的Volcano的查询优化框架和相关查询优化技术提出非常巨大的挑战。这种挑战，需要很多的时间和创新。如果现在已经实现可以商用化了，我倒是真要吃惊了。

如果我们站在更远一点的角度去看。这个系统假设用户告诉系统干什么，走的是经典的SQL的道路。这个做法是不是好的做法，一直有两派。Spark和Flink的编程模型里更多的是一个dataflow的编程模式，告诉系统用户想怎么做。但是系统可以在不改变运行结果的基础上进行等价的转换。这种告诉系统干什么但是不告诉系统怎么干的道路，是或者不是未来的主流道路我看不太清楚。

另外一个没有解答的问题是这个系统会用什么样的数据模型。Blink是流模型。Batch通过流给一个很大很大的窗口去模拟。而经典的MaxCompute是典型的batch模型。数据模型在不同的计算引擎之间可能是不统一的。由此类比，每个计算引擎之间的数据类型，计算精度等可能也是有差别的。这样一来，会不会导致系统的两个理论上等价的执行计划，事实上结果有差别。而应用是否可以容忍这种差别，也是不好说的。从这个角度来看，这个项目对MaxCompute的引擎的改造应该比较小，Blink的streaming系统，嵌入到新的框架里，需要的改动多一些。

----------------------------------------------------------------------------------------------

第二个讲座是蒋晓伟在今年柏林的Flink Forward的讲座：Unified Engine for Data Processing and AI。具体来说这个讲座是讨论周靖人博士下属的蒋晓伟Blink团队做的如何把Batch，Streaming以及AI融合在一起的相关工作。

Flink是一个以streaming作为主体，Batch作为特例的引擎。

其架构如下：

Flink架构的问题在于上层的DataStream API和DataSet API是完全独立的，下层的runtime也是独立的，只有中间共享了Job Graph。即便如此，Flink依然是开源产品里复杂的流计算引擎。

那么Flink能成为好的批计算引擎吗？

阿里巴巴的一个benchmark显示这是完全可能的，其根源在于Flink的pipeline执行模式比其他的批计算引擎都要快。

事实上阿里巴巴内部的Blink就可以做的很好。这个讲座接下来讲了下面三个主题：

Blink选择了SQL作为unified API，主要理由如下：

通过引入Dynamic Table的概念来达到流处理和批处理在运行时候的统一：

Blink相对Flink还增加了很多新的功能和支持：

Flink对TPC-H的支持没问题，但是TPC-DS的查询只有一半能编译。Blink把所有对TPC-H和TPC-DS的支持补全了，同时测试了很多的SQL语句：

Flink现存的流执行模式和批执行模式是不一样的：

要建立统一的执行引擎需要统一的operator abstraction

Blink使用了新的架构设计：

在新框架下查询执行是这样的：

从TPC-H的性能看，Blink要比Flink好很多：

Blink对调度器进行了强化：

Flink只能chain单一的输入但是Blink支持多输入，工作并行度大大提高了：

Blink的查询执行上也做了很多优化：

请输入图片描述

Blink相对于Flink的10X提速主要是如下分解的：

Blink的下一步主要是：

以上是这个讲座的所有内容。这个讲座是我目前学习的所有资料里对Blink和Flink比较详细的资料。我想只要看完了这个讲座，大家应该知道Blink和Flink的差别了。

如果大家同时读了之前VLDB周靖人博士的讲座和上述蒋晓伟在Flink Forward的讲座，大体上应该可以了解阿里巴巴集团MaxCompute这个组织对未来流处理，批处理以及AI如何发展有一个认识了。

这里面的技术难点在于一方面Blink自身正在发展成为一个越来越全能的计算引擎，另外一个方面在更高的层面上，MaxCompute要对不同引擎之间做基于时间的查询优化。这两件事本身都是技术上非常有挑战性的事情。而在两个不同层面的查询优化如何有机的协调好，更是巨大的挑战。这基本上已经代表了查询优化技术自问世以来大的挑战了。能不能做好，能做得多好，只能拭目以待了。

如上我给大家介绍了Flink/Blink以及MaxCompute对流引擎，批处理引擎以及AI等各方面的技术趋势，限于篇幅等因素更深入的讨论就不展开了，希望对大家理解Blink开源有帮助。