Apache Flink 1.11版本着重提升了SQL模块的易用性和功能，引入了对CDC的支持，使得用户能通过SQL对接Debezium和Canal数据源。此外，Flink SQL还支持将流式数据实时写入Hive等离线数仓。源和sink接口重构，支持Changelog，解决了类型匹配问题，提升了SQL的易用性。Flink SQL还增加了对Hive的流批一体支持，实现了Hive的实时读写。
7 月 6 日，Apache Flink 1.11 正式发布。从 3 月初进行功能规划到 7 月初正式发版，1.11 用将近 4 个月的时间重点优化了 Flink 的易用性问题，提升用户的生产使用体验。
SQL 作为 Flink 中公认的核心模块之一，对推动 Flink 流批一体功能的完善至关重要。在 1.11 中，Flink SQL 也进行了大量的增强与完善，开发大功能 10 余项，不仅扩大了应用场景，还简化了流程，上手操作更简单。
其中，值得注意的改动包括：
-
默认 Planner 已经切到 Blink planner 上。
-
引入了对 CDC（Change Data Capture，变动数据捕获）的支持，用户仅用几句简单的 SQL 即可对接 Debezium 和 Canal 的数据源。
-
离线数仓实时化，用户可方便地使用 SQL 将流式数据从 Kafka 写入 Hive 等。
Flink SQL 演变
随着流计算的发展，挑战不再仅限于数据量和计算量，业务变得越来越复杂，开发者可能是资深的大数据从业者、初学 Java 的爱好者，或是不懂代码的数据分析者。如何提高开发者的效率，降低流计算的门槛，对推广实时计算非常重要。
SQL 是数据处理中使用最广泛的语言，它允许用户简明扼要地展示其业务逻辑。Flink 作为流批一体的计算引擎，致力于提供一套 SQL 支持全部应用场景，Flink SQL 的实现也完全遵循 ANSI SQL 标准。之前，用户可能需要编写上百行业务代码，使用 SQL 后，可能只需要几行 SQL 就可以轻松搞定。
Flink SQL 的发展大概经历了以下阶段：
-
Flink 1.1.0：第一次引入 SQL 模块，并且提供 TableAPI，当然，这时候的功能还非常有限。
-
Flink 1.3.0：在 Streaming SQL 上支持了 Retractions，显著提高了 Streaming SQL 的易用性，使得 Flink SQL 支持了复杂的 Unbounded 聚合连接。
-
Flink 1.5.0：SQL Client 的引入，标志着 Flink SQL 开始提供纯 SQL 文本。
-
Flink 1.9.0：抽象了 Table 的 Planner 接口，引入了单独的 Blink Table 模块。Blink Table 模块是阿里巴巴内部的 SQL 层版本，不仅在结构上有重大变更，在功能特性上也更加强大和完善。
-
Flink 1.10.0：作为第一个 Blink 基本完成 merge 的版本，修复了大量遗留的问题，并给 DDL 带来了 Watermark 的语法，也给 Batch SQL 带来了完整的 TPC-DS 支持和高效的性能。
经过了多个版本的迭代支持，SQL 模块在 Flink 中变得越来越重要，Flink 的 SQL 用户也逐渐扩大。基于 SQL 模块的 Python 接口和机器学习接口也在快速发展。毫无疑问， SQL 模块作为最常用的 API 之一和生态的集成变得越来越重要。
SQL 1.11 重要变更
Flink SQL 在原有的基础上扩展了新场景的支持：
-
Flink SQL 引入了对 CDC（Change Data Capture，变动数据捕获）的支持，它使 Flink 可以方便地通过像 Debezium 这类工具来翻译和消费数据库的变动日志。
-
Flink SQL 扩展了类 Filesystem connector 对实时化用户场景和格式的支持，从而可以支持将流式数据从 Kafka 写入 Hive 等场景。
除此之外，Flink SQL 也从多个方面提高 SQL 的易用性，系统性的解决了之前的 Bug、完善了用户 API。
CDC 支持
CDC 格式是数据库中一种常用的模式，业务上典型的应用是通过工具（比如 Debezium 或 Canal）将 CDC 数据通过特定的格式从数据库中导出到 Kafka 中。在以前，业务上需要定义特殊的逻辑来解析 CDC 数据，并把它转换成一般的 Insert-only 数据，后续的处理逻辑需要考虑到这种特殊性，这种 work-around 的方式无疑给业务上带来了不必要的复杂性。
如果 Flink SQL 引擎能原生支持 CDC 数据的输入，将 CDC 对接到 Flink SQL 的 Changelog Stream 概念上，将会大大降低用户业务的复杂度。
流计算的本质是就是不断更新、不断改变结果的计算。考虑一个简单的聚合 SQL，流计算中，每次计算产生的聚合值其实都是一个局部值，所以会产生 Changelog Stream。在以前想要把聚合的数据输出到 Kafka 中，如上图所示，几乎是不可能的，因为 Kafka 只能接收 Insert-only 的数据。
Flink 之前主要是因为 Source&Sink 接口的限制，导致不能支持 CDC 数据的输入。Flink SQL 1.11 经过了大量的接口重构，在新的 Source&Sink 接口上，支持了 CDC 数据的输入和输出，并且支持了 Debezium 与 Canal 格式（FLIP-105）。这一改动使动态 Table Source 不再只支持 append-only 的操作，而且可以导入外部的修改日志（插入事件）将它们翻译为对应的修改操作（插入、修改和删除）并将这些操作与操作的类型发送到后续的流中。
如上图所示，理论上，CDC 同步到 Kafka 的数据就是 Append 的一个流，只是在格式中含有 Changelog 的标识：
-
一种方式是把 Changlog 标识看做一个普通字段，这也是目前普遍的使用方式。
-
在 Flink 1.11 后，可以将它声明成 Changelog 的格式，Flink 内部机制支持 Interpret Changelog，可以原生识别出这个特殊的流，将其转换为 Flink 的 Changlog Stream，并按照 SQL 的语义处理；同理，Flink SQL 也具有输出 Change Stream 的能力 （Flink 1.11 暂无内置实现），这就意味着，你可以将任意类型的 SQL 写入到 Kafka 中，只要有 Changelog 支持的 Format
最低0.47元/天 解锁文章
扫一扫
1320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
