春节前一周，经过社区内部讨论，阿里巴巴大数据引擎Blink作为Flink的一个分支正式开源。今天，ApacheFlink官网发文进一步说明了Blink对Flink项目贡献的意义，并公布了Blink与Flink的合并计划。社区的合并计划最初将侧重于bounded/batch功能，社区将重构SQL/TableAPI模块，将Blink查询计划器（优化器）和运行时（操作器）合并到当前SQL运行时使用的附加查询处理器中。过渡期过后，将开发新的查询处理器，而当前的处理器可能会被弃用。为了融入Blink的调度增强和有界数据的作业恢复能力，Flink社区也在致力于重构当前的调度功能。不久前，经过社区的讨论，阿里巴巴决定将Blink贡献回Flink项目。为什么这对Flink来说很重要？这对Flink的用户和社区意味着什么？这与Flink的整体愿景有何关系？让我们退后一步，找出答案。对于Blink的贡献形式，Flink社区讨论邮件如下：https://lists.apache.org/thread.html/2f7330e85d702a53b4a2b361149930b50f2e89d8e8a572f8ee2a0e6d@unifiedbatchandstreamprocessingmethodsFlink从早期开始就有意采用统一的批流处理方式处理方法流式处理。它的核心构建块是“无界数据流的连续处理”：如果可以做到这一点，也可以离线处理有界数据集（批处理），因为有界数据集是在某个点结束的数据流。许多项目（如Flink、Beam等）支持“流式优先，将批处理作为流式处理的特例”的概念，这通常被认为是构建跨越实时和离线数据的应用程序的有力方式，这可以大大降低数据基础设施的复杂性。为什么批处理器仍然存在？“批处理只是流处理的一个特例”并不意味着所有的流处理器都可以用于批处理——流处理器的出现并没有让批处理器过时：纯流式系统对于批处理工作负载来说实际上很慢。没有人会认为使用流处理器来分析海量数据是个好主意。像ApacheBeam这样的统一API通常根据数据是持久的（无界的）还是固定的（有界的）将工作负载委托给不同的运行时。Flink提供了一个流式API，可以处理有界和无界场景，同时仍然提供单独的DataSetAPI和运行时用于批处理，因为它会更快。那么“批处理只是流处理的一个特例”的想法有什么问题呢？这种范式没有任何问题。统一批处理和流处理API只是一方面，我们还需要利用“有界数据”特例的一些特性来处理批处理用例。毕竟，批处理器就是为这种特殊情况设计的。建立在流式运行时之上的批处理我们一直相信，可以有一个既可用于流式处理又可用于批处理的运行时。流优先运行时还可以利用有界数据流的特殊属性来进行快速批处理，如批处理器。这就是Flink采用的方法。Flink包含一个网络堆栈，支持低延迟/高吞吐量的流式数据交换和高吞吐量的批处理洗牌。它还提供了许多流式运行时运算符以及用于有界输入的专用运算符，如果您选择DataSetAPI或TableAPI，则可以使用这些运算符。所以Flink实际上在早期就展示了一些令人印象深刻的批处理性能。下面的基准测试有点旧，但为我们的架构方法提供了一个很好的早期验证。对3.2TB（80GB/节点）数据进行排序所花费的时间（以秒为单位）有多糟糕？为了总结这种方法并将Flink带入一个新的水平（批处理），我们需要做更多的增强。我们相信以下功能是实现我们愿景的关键：真正统一的运行时运算符堆栈：目前，有界和无界运算符具有不同的网络和线程模型，不能混合或匹配。最初是因为批处理操作符遵循“拉模型”（以促进批处理算法），而流操作符遵循“推模型”（以获得更好的延迟/吞吐量）。在统一算子栈中，连续流算子是基础。在对有界数据进行操作时，如果没有延迟约束，API或查询优化器可以从更大的运算符集中选择合适的运算符。例如，优化器可以选择一个特殊的连接运算符，在读取第二个输入流之前完全读取一个输入流。利用有界数据流来降低容错能力：如果输入数据是有界的，则可以在随机播放（内存或磁盘）期间缓冲数据并在失败后重放。这允许更细粒度的故障恢复并且更有效。使用有界数据流运算符的属性进行调度：连续无界流式应用程序需要同时运行所有运算符。基于有界数据的应用程序可以根据另一个运算符使用数据的方式来调度其中一个运算符（例如，首先构建哈希表，然后探测哈希表）。这样做可以提高资源效率。为DataStreamAPI启用这些特殊优化：目前只有TableAPI在处理有界数据时激活了这些优化。SQL性能和覆盖范围：SQL是事实上的标准数据语言，虽然它用于连续流处理，但不适合有界/批处理。为了与优秀的批处理引擎竞争，Flink需要提高SQL查询执行覆盖率和性能。虽然Flink的核心数据平面是高性能的，但SQL的执行速度很大程度上取决于优化器规则、丰富的算子和代码生成等。现在我们来谈谈BlinkBlink是Fl??ink的一个分支，最初是在阿里巴巴内部创建的，用于改进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)。TableAPIandSQLqueryprocessor：SQLqueryprocessor是相对于新的Flink主分支进化最多的组件：Flink目前将查询转换为DataSet或DataStream程序（取决于输入的特性），而Blink则将查询转换为上述流媒体运营商的数据流。Blink为常见的SQL操作增加了更多的运行时操作符，例如半连接、反连接等。查询计划器（优化器）仍然基于ApacheCalcite，但提供了更多的优化规则（包括连接重排序），并使用合适的成本模型。更积极的流媒体运营商链接。扩展通用数据结构（分类器、哈希表）和序列化器，进一步处理二进制数据并减少序列化开销。代码生成用于行序列化程序。改进的调度和故障恢复：最后，Blink对任务调度和容错进行了多项改进。调度策略通过利用操作员处理输入数据的方式来更好地利用资源。故障转移策略允许沿持久洗牌边界进行更细粒度的恢复。可以在不重新启动正在运行的应用程序的情况下替换失败的JobManager。Blink的变化带来了巨大的性能提升。以下数据由Blink开发人员提供，并给出了性能改进的粗略图。Blink与Flink1.6.0在TPC-H基准测试中的相对性能。Blink性能平均提高了10倍在TPC-DS基准测试中，Blink与Spark的性能相加，总结了所有查询的总时间。Blink与Flink的合并计划Blink的代码目前作为Flink代码库的一个分支（https://github.com/apache/flink/tree/blink）对外开放。合并如此多的更改是一项艰巨的挑战，同时尽可能保持合并过程不中断，并尽可能保持公共API稳定。社区的合并计划最初侧重于上述有界/批处理功能，并遵循以下方法以确保顺利集成：为了合并Blink的SQL/TableAPI查询处理器增强功能，我们利用Flink和Blink具有相同API的事实：SQL和表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目录和集成的支持目前在单独的设计讨论中。总结我们认为未来的数据处理技术栈将以流处理为基础：流处理的优雅、离线处理（批处理）建模的能力、实时数据处理和事件驱动应用的相同方式，同时它还提供了高性能和一致性，这真的很有吸引力。成都甲米谷大数据培训，大数据开发，数据分析与挖掘，小班教学，免费试听。利用有界数据的某些属性是流处理器实现与专用批处理器相同性能的关键。Flink支持批处理，但它的下一步是构建一个统一的运行时，成为一个可以与批处理系统竞争的流式处理器。阿里巴巴贡献的Blink帮助Flink社区加速实现这一目标。英文原文：https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html
