阿里巴巴Blink正式开源，重要优化点解读

首先，我们对 SQL engine 的架构做了较大的调整。提出了全新的 Query Processor（QP）， 它包括了一个优化层（Query Optimizer）和一个算子层（Query Executor）。这样一来，流计算和批计算的在这两层大部分的设计工作就能做到尽可能地复用。另外，SQL 和 TableAPI 的程序最终执行的时候将不会翻译到 DataStream 和 DataSet 这两个 API 上，而是直接构建到可运行的 DAG 上来，这样就使得物理执行算子的设计不完全依赖底层的 API，有了更大的灵活度，同时执行代码也能够被灵活的 codegen 出来。

唯一的一个影响就是这个版本的 SQL 和 TableAPI 不能和 DataSet 这个 API 进行互相转换，但仍然保留了和 DataStream API 互相转换的能力（将 DataStream 注册成表，或将 Table 转成 DataStream 后继续操作）。未来，我们计划把 dataset 的功能慢慢都在 DataStream 和 TableAPI 上面实现。到那时 DataStream 和 SQL 以及 tableAPI 一样，是一个可以同时描述 bounded 以及 unbounded processing 的 API。

除了架构上的重构，Blink 还在具体实现上做了较多比较大的重构。

首先，Blink 引入了二进制的数据结构 BinaryRow，极大的减少了数据存储上的开销以及数据在序列化和反序列化上计算的开销。

其次，在算子的实现层面，Blink 在更广范围内引入了 CodeGen 技术。由于预先知道算子需要处理的数据的类型，在 QP 层内部就可以直接生成更有针对性更高效的执行代码。Blink 的算子会动态的申请和使用资源，能够更好的利用资源，提升效率，更加重要的是这些算子对资源有着比较好的控制，不会发生 OutOfMemory 的问题。

此外，针对流计算场景，Blink 加入了 miniBatch 的执行模式，在 aggregate、join 等需要和 state 频繁交互且往往又能先做部分 reduce 的场景中，使用 miniBatch 能够极大的减少 IO，从而成数量级的提升性能。除了上面提到的这些重要的重构和功能点，Blink 还实现了完整的 SQL DDL，带 emit 策略的流计算 DML，若干重要的 SQL 功能，以及大量的性能优化策略。

有了上面提到的诸多架构和实现上的重构。Blink 的 SQL／tableAPI 在功能和性能方面都取得了脱胎换骨的变化。在批计算方面，首先 Blink batch SQL 能够完整地跑通 TPC-H 和 TPC-DS，且性能上有了极大的提升。

如上图所示，是这次开源的 Blink 版本和 spark 2.3.1 的 TPC-DS 的 benchmark 性能对比。柱状图的高度代表了运行的总时间，高度越低说明性能越好。可以看出，Blink 在 TPC-DS 上和 Spark 相比有着非常明显的性能优势，而且这种性能优势随着数据量的增加而变得越来越大。在实际的场景这种优势已经超过 Spark 三倍，在流计算性能上我们也取得了类似的提升。我们线上的很多典型作业，性能是原来的 3 到 5 倍。在有数据倾斜的场景，以及若干比较有挑战的 TPC-H query，流计算性能甚至得到了数十倍的提升。

除了标准的 Relational SQL API。TableAPI 在功能上是 SQL 的超集，因此在 SQL 上所有新加的功能，我们在 tableAPI 也添加了相对应的 API。除此之外，我们还在 TableAPI 上引入了一些新的功能。其中一个比较重要是 cache 功能。在批计算场景下，用户可以根据需要来 cache 计算的中间结果，从而避免不必要的重复计算，它极大地增强了 interactive programming 体验。我们后续会在 tableAPI 上添加更多有用的功能。其实很多新功能已经在社区展开讨论并被社区接受，例如我们在 tableAPI 增加了对一整行操作的算子 map/flatMap/aggregate/flatAggregate (Flink FLIP29) 等等。

Hive 的兼容性

（编辑：PHP编程网 - 湛江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!