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

此外，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 功能，以及大量的性能优化策略。

（编辑：西安站长网）

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