官宣！阿里Blink和Flink合并计划出炉

最新推荐文章于 2024-02-18 00:49:10 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2024-02-18 00:49:10 发布

阅读量327

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89147165

版权

春节前一周，经过社区内部讨论，阿里巴巴大数据引擎Blink作为Flink的分支正式开源。今天，Apache Flink官方网站发文对Blink贡献回Flink项目的意义作进一步说明，并公布了Blink和Flink的合并计划。社区的合并计划最初会将重点放在有界/批处理功能上，社区将对SQL/Table API模块进行重组，将Blink查询规划器（优化器）和运行时（操作符）合并为当前SQL运行时的附加查询处理器。经过一段过渡期之后，将开发新的查询处理器，而当前的处理器很可能会被弃用。为了合并Blink的调度增强功能和有界数据的作业恢复功能，Flink社区也在努力重构当前的调度功能。

前不久，经社区讨论，阿里巴巴决定将Blink贡献回Flink项目。为什么说这对Flink来说是一件大事？这对Flink的用户和社区来说意味着什么？这与Flink的整体愿景有着怎样的关系？让我们退后一步，一探究竟。

针对Blink的贡献形式，Flink社区讨论邮件如下：

https://lists.apache.org/thread.html/2f7330e85d702a53b4a2b361149930b50f2e89d8e8a572f8ee2a0e6d@\u0026lt;dev.flink.apache.org\u0026gt;

统一的批处理和流式处理方法

从早期开始，Flink就有意采用统一的批处理和流式处理方法。其核心构建块是“持续处理无界的数据流”：如果可以做到这一点，还可以离线处理有界数据集（批处理），因为有界数据集就是在某个时刻结束的数据流。

$\"image\"$

很多项目（例如Flink、Beam等）都支持“流式处理优先，将批处理视为流式处理的特殊情况”的理念，这个理念也经常被认为是构建跨实时和离线数据应用程序的强大方式，可以大大降低数据基础设施的复杂性。

为什么批处理器仍然存在？

“批处理只是流式处理的一个特例”并不意味着所有的流式处理器都能用于批处理——流式处理器的出现并没有让批处理器变得过时：

纯流式处理系统在批处理工作负载时其实是很慢的。没有人会认为使用流式处理器来分析海量数据是个好主意。
像Apache Beam这样的统一API通常会根据数据是持续的（无界）还是固定的（有界）将工作负载委托给不同的运行时。
Flink提供了一个流式API，可以处理有界和无界的场景，同时仍然提供了单独的DataSet API和运行时用于批处理，因为速度会更快。

那么“批处理只是流式处理的一个特例”这种想法出了什么问题？

其实这种范式并没有错。统一批处理和流式处理API只是一个方面，我们还需要利用“有界数据”这个特殊情况的某些特征来应对批处理用例。毕竟，批处理器就是专门为这种特殊情况而准备的。

建立在流式运行时之上的批处理

我们始终认为，同时拥有一个可用于流式处理和批处理的运行时是可能的。一个流式处理优先的运行时也可以利用有界数据流的特殊属性进行快速的批处理，就像批处理器那样。而这就是Flink所采用的方法。

Flink包含了一个网络栈，支持低延迟/高吞吐的流式数据交换和高吞吐的批次shuffle。它还提供了很多流式运行时操作符，也为有界输入提供了专门的操作符，如果你选择了DataSet API或Table API，就可以使用这些操作符。

$\"image\"$

因此，Flink实际上在早期就已经展示出了一些令人印象深刻的批处理性能。下面的基准测试有点旧了，但在早期很好地验证了我们的架构方法。

$\"image\"$

排序3.2TB（80GB/节点）数据所使用的时间（以秒为单位）

还差些什么？

为了总结这个方法，并让Flink在有界数据（批处理）方面达到最新的水平，我们需要做出更多的增强。我们认为下面这些特性是实现我们愿景的关键:

真正统一的运行时操作符栈：目前，有界和无界操作符具有不同的网络和线程模型，不会混在一起，也不匹配。最初是因为批处理操作符遵循的是“拉取模型”（为了方便批处理算法），而流式操作符遵循的是“推模型”（可以获得更好的延迟/吞吐量）。在统一的操作符栈中，持续流式操作符是基础。在操作有界数据时，如果没有延迟方面的约束，API或查询优化器可以从更大的操作符集中选择合适的操作符。例如，优化器可以选择一个特殊的连接操作符，先完全读取第一个输入流，然后再读取第二个输入流。
利用有界数据流来减小容错范围：如果输入数据是有界的，可以在shuffle（内存或磁盘）期间缓冲数据，并在发生故障后重放数据。这样可以实现更细粒度的故障恢复，也更有效。
利用有界数据流操作符的属性进行调度：持续无界的流式应用程序需要同时运行所有操作符。基于有界数据的应用程序可以根据其中一个操作符如何消费数据（例如，先构建哈希表，再探测哈希表）来调度另一个操作符。这样做可以提高资源效率。
为DataStream API启用这些特殊优化：目前只有Table API在处理有界数据时激活了这些优化。
SQL的性能和覆盖范围：SQL是事实上的标准数据语言，虽然它被用在持续流式处理种，但并不适用于有界/批处理的情况。为了与最佳批处理引擎展开竞争，Flink需要提升SQL查询执行覆盖率和性能。虽然Flink的核心数据平面具有很高的性能，但SQL执行的速度在很大程度上取决于优化器规则、丰富的操作符和代码生成，等等。

现在来说说Blink

Blink是Flink的一个分支，最初在阿里巴巴内部创建的，针对内部用例对Flink进行改进。Blink添加了一系列改进和集成（https://github.com/apache/flink/blob/blink/README.md ），其中有很多与有界数据/批处理和SQL有关。实际上，在上面的功能列表中，除了第4项外，Blink在其他方面都迈出了重要的一步：

统一的流式操作符：Blink扩展了Flink的流式运行时操作符模型，支持选择性读取不同的输入源，同时保持推送模型的低延迟特性。这种对输入源的选择性读取可以更好地支持一些算法（例如相同操作符的混合散列连接）和线程模型（通过RocksDB的连续对称连接）。这些操作符为“侧边输入”（https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API ）等新功能打下了基础。

Table API和SQL查询处理器：与最新的Flink主分支相比，SQL查询处理器是演变得最多的一个组件：

Flink目前将查询转换为DataSet或DataStream程序（取决于输入的特性），而Blink会将查询转换为上述流式操作符的数据流。
Blink为常见的SQL操作添加了更多的运行时操作符，如半连接（semi-join）、反连接（anti-join）等。
查询规划器（优化器）仍然是基于Apache Calcite，但提供了更多的优化规则（包括连接重排序），并且使用了适当的成本模型。
更加积极的流式操作符链接。
扩展通用数据结构（分类器、哈希表）和序列化器，在操作二进制数据上更进一步，并减小了序列化开销。代码生成被用于行序列化器。

改进的调度和故障恢复：最后，Blink实现了对任务调度和容错的若干改进。调度策略通过利用操作符处理输入数据的方式来更好地使用资源。故障转移策略沿着持久shuffle的边界进行更细粒度的恢复。不需重新启动正在运行的应用程序就可以替换发生故障的JobManager。

Blink的变化带来了大幅度的性能提升。以下数据由Blink开发者提供，给出了性能提升的粗略情况。

$\"image\"$

在TPC-H基准测试中，Blink与Flink 1.6.0的相对性能。Blink性能平均提升10倍

$\"image\"$

在TPC-DS基准测试中，Blink与Spark的性能，将所有查询的总时间汇总在一起。

Blink和Flink的合并计划

Blink的代码目前已经作为Flink代码库的一个分支（https://github.com/apache/flink/tree/blink ）对外开放。合并这么多变更是一项艰巨的挑战，同时还要尽可能保持合并过程不要造成任何中断，并使公共API尽可能保持稳定。

社区的合并计划最初将重点放在上述的有界/批处理功能上，并遵循以下方法以确保能够顺利集成：

为了合并Blink的SQL/Table API查询处理器增强功能，我们利用了Flink和Blink都具有相同API的事实：SQL和Table API。在对Table/SQL模块（ https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions ）进行一些重组之后，我们计划将Blink查询规划器（优化器）和运行时（操作符）合并为当前SQL运行时的附加查询处理器。可以将其视为同一API的两个不同的运行器。最开始，可以让用户选择要使用哪个查询处理器。经过一个过渡期之后，将开发新的查询处理器，而当前的处理器很可能会被弃用，并最终被丢弃。因为SQL是一个定义良好的接口，我们预计这种转换对用户来说几乎没有影响。
为了合并Blink的调度增强功能和有界数据的作业恢复功能，Flink社区已经在努力重构当前的调度功能，并添加对可插拔调度和故障转移策略的支持。在完成这项工作后，我们就可以将Blink的调度和恢复策略作为新查询处理器的调度策略。最后，我们计划将新的调度策略应用于有界DataStream程序。
扩展的目录支持、DDL支持以及对Hive目录和集成的支持目前正在进行单独的设计讨论。