被社区关注的Blink开源到底向上游贡献了什么？(2)

此外，Blink 提供了全新的 JM FailOver 机制，JM 发生错误之后，新的 JM 会重新接管整个任务而不是重启任务，从而大大减少了 JM FailOver 对任务的影响。最后，Blink 也开发了对 Kubernetes 的支持。不同于 Standalone 模式在 Kubernetes 上的拉起方式，在基于 Flink FLIP6 的架构上基础之上，Blink 根据任务的资源需求动态的申请/释放 Pod 来运行 TaskExecutor，实现了资源弹性，提升了资源的利用率。

SQL/TableAPI

SQL/TableAPI 架构上的重构和性能的优化是 Blink 本次开源版本的一个重大贡献。首先，我们对 SQL 引擎的架构做了较大的调整。提出了全新的 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 能够极大的减少 I/O，从而成数量级的提升性能。除了上面提到的这些重要的重构和功能点，Blink 还实现了完整的 SQL DDL，带 emit 策略的流计算 DML，若干重要的 SQL 功能，以及大量的性能优化策略。

有了上面提到的诸多架构和实现上的重构。Blink 的 SQL/TableAPI 在功能和性能方面都取得了脱胎换骨的变化。在批计算方面，首先 Blink batch SQL 能够完整的跑通 TPC-H 和 TPC-DS，且性能上有着极大的提升。如上图所示，是这次开源的 Blink 版本和 Spark 2.3.1 的 TPC-DS 的基准性能对比。柱状图的高度代表了运行的总时间，高度越低说明性能越好。可以看出， Blink 在 TPC-DS 上和 Spark 相比有着非常明显的性能优势。而且这种性能优势随着数据量的增加而变得越来越大。在实际的场景这种优势已经超过 Spark 的三倍。在流计算性能上我们也取得了类似的提升。我们线上的很多典型作业，它的性能是原来的 3 到 5 倍。在有数据倾斜的场景，以及若干比较有挑战的 TPC-H Query，流计算性能甚至得到了数十倍的提升。

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

Hive 的兼容性

我们这次开源的版本实现了在元数据和数据层将 Flink 和 Hive 对接和打通。国内外很多公司都还在用 Hive 在做自己的批处理。对于这些用户，现在使用这次 Blink 开源的版本，就可以直接用 Flink SQL 去查询 Hive 的数据，真正能够做到在 Hive 引擎和 Flink 引擎之间的自由切换。

为了打通元数据，我们重构了 Flink catalog 的实现，并且增加了两种 catalog，一个是基于内存存储的 FlinkInMemoryCatalog，另外一个是能够桥接 Hive metaStore 的 HiveCatalog。有了这个 HiveCatalog，Flink 作业就能读取 Hive 的 metaData。为了打通数据，我们实现了 HiveTableSource，使得 Flink 任务可以直接读取 Hive 中普通表和分区表的数据。因此，通过这个版本，用户可以使用 Flink SQL 读取已有的 Hive 元数据和数据，做数据处理。未来我们将在 Flink 上继续加大对 Hive 兼容性的支持，包括支持 Hive 特有的请求、数据类型和 Hive UDF 等等。

Zeppelin for Flink

为了提供更好的可视化和交互式体验，我们做了大量的工作让 Zeppelin 能够更好的支持 Flink。这些改动有些是在 Flink 上的，有些是在 Zeppelin 上的。在这些改动全部推回 Flink 和 Zeppelin 社区之前，大家可以使用这个 Zeppelin 镜像（具体细节请参考 Blink 代码里的 docs/quickstart/zeppelin_quickstart.md）来测试和使用这些功能。这个用于测试的 Zeppelin版本，首先很好的融合和集成了 Flink 的多种运行模式以及运维界面。使用文本 SQL 和 TableAPI 可以自如的查询 Flink 的静态表和动态表。

（编辑：ASP站长网）