flink1.11 Flink SQL 新功能解读

在了解 Flink 整体发展趋势后，我们来看下最近发布的 Flink 1.11 版本在 connectivity 和 simplicity 方面都带来了哪些令人耳目一新的功能。

#### FLIP-122：简化 connector 参数

整个 Flink SQL 1.11 在围绕易用性方面做了很多优化，比如 FLIP-122，优化了 connector 的 property 参数名称冗长的问题。以 Kafka 为例，在 1.11 版本之前用户的 DDL 需要声明成如下方式

 CREATE TABLE user_behavior (
  ...
) WITH (
  'connector.type'='kafka',
  'connector.version'='universal',
  'connector.topic'='user_behavior',
  'connector.startup-mode'='earliest-offset',
  'connector.properties.zookeeper.connect'='localhost:2181',
  'connector.properties.bootstrap.servers'='localhost:9092',
  'format.type'='json'
);

而在 Flink SQL 1.11 中则简化为

CREATE TABLE user_behavior (
  ...
) WITH (
  'connector'='kafka',
  'topic'='user_behavior',
  'scan.startup.mode'='earliest-offset',
  'properties.zookeeper.connect'='localhost:2181',
  'properties.bootstrap.servers'='localhost:9092',
  'format'='json'
);

DDL 表达的信息量丝毫未少，但是看起来清爽许多 :) Flink 的开发者们为这个优化做了很多讨论，有兴趣可以围观 FLIP-122 Discussion Thread。

#### FLINK-16743：内置 connectors

Flink SQL 1.11 新加入了三种内置的 connectors，如下表所示

connector	描述	使用场景
'connector'='datagen'	用于生成随机数据的source	常用于测试
'connector'='blackhole'	不做任何处理的 sink	常用于性能测试
'connector'='print'	打印到标准输出流(.out文件)的 sink	常用于调试

在外部 connector 环境还没有 ready 时，用户可以选择 datagen source 和 print sink 快速构建 pipeline 熟悉 Flink SQL；对于想要测试 Flink SQL 性能的用户，可以使用 blackhole 作为 sink；对于调试排错场景，print sink 会将计算结果打到标准输出（比如集群环境下就会打到 taskmanager.out 文件），使得定位问题的成本大大降低。

#### FLIP-110：LIKE 语法

Flink SQL 1.11 支持用户从已定义好的 table DDL 中快速 “fork” 自己的版本并进一步修改 watermark 或者 connector 等属性。比如下面这张 base_table 上想加一个 watermark，在 Flink 1.11 版本之前，用户只能重新将表声明一遍，并加入自己的修改，可谓 “牵一发而动全身”。

-- before Flink SQL 1.11
CREATE TABLE base_table (
 id BIGINT,
 name STRING,
 ts TIMESTAMP
) WITH (
 'connector.type'='kafka',
 ...
);

CREATE TABLE derived_table (
 id BIGINT,
 name STRING,
 ts TIMESTAMP,
 WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) WITH (
 'connector.type'='kafka',
 ...
);

从 Flink 1.11 开始，用户只需要使用 CREATE TABLE LIKE 语法就可以完成之前的操作

-- Flink SQL 1.11
CREATE TABLE base_table (
 id BIGINT,
 name STRING,
 ts TIMESTAMP
) WITH (
 'connector'='kafka',
 ...
);

CREATE TABLE derived_table (
 WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
) LIKE base_table;

而内置 connector 与 CREATE TABLE LIKE 语法搭配使用则会如下图一般产生“天雷勾地火”的效果，极大提升开发效率。

#### FLIP-113：动态 Table 参数

对于像 Kafka 这种消息队列，在声明 DDL 时通常会有一个启动点位去指定开始消费数据的时间，如果需要更改启动点位，在老版本上就需要重新声明一遍新点位的 DDL，非常不方便。

CREATE TABLE user_behavior (
  user_id BIGINT,
  behavior STRING,
  ts TIMESTAMP(3)
) WITH (
  'connector'='kafka',
  'topic'='user_behavior',
  'scan.startup.mode'='timestamp',
  'scan.startup.timestamp-millis'='123456',
  'properties.bootstrap.servers'='localhost:9092',
  'format'='json'
);

从 Flink 1.11 开始，用户可以在 SQL client 中按如下方式设置开启 SQL 动态参数（默认是关闭的），如此即可在 DML 里指定具体的启动点位。

SET 'table.dynamic-table-options.enabled' = 'true';

SELECT user_id, COUNT(DISTINCT behaviro)
FROM user_behavior /*+ OPTIONS('scan.startup.timestamp-millis'='1596282223') */
GROUP BY user_id;

除启动点位外，动态参数还支持像 sink.partition 、 scan.startup.mode 等更多运行时参数，感兴趣可移步 FLIP-113 获得更多信息。

#### FLIP-84：重构优化 TableEnvironment 接口

Flink SQL 1.11 以前的 TableEnvironment 接口定义和行为有一些不够清晰，比如

• TableEnvironment#sqlUpdate() 方法对于 DDL 会立即执行，但对于 INSERT INTO DML 语句却是 buffer 住的，直到调用 TableEnvironment#execute() 才会被执行，所以在用户看起来顺序执行的语句，实际产生的效果可能会不一样。
• 触发作业提交有两个入口，一个是 TableEnvironment#execute(), 另一个是 StreamExecutionEnvironment#execute()，于用户而言很难理解应该使用哪个方法触发作业提交。
• 单次执行不接受多个 INSERT INTO 语句。

针对这些问题，Flink SQL 1.11 提供了新 API，即 TableEnvironment#executeSql()，它统一了执行 sql 的行为， 无论接收 DDL、查询 query 还是 INSERT INTO 都会立即执行。针对多 sink 场景提供了 StatementSet 和 TableEnvironment#createStatementSet() 方法，允许用户添加多条 INSERT 语句一起执行。

除此之外，新的 execute 方法都有返回值，用户可以在返回值上执行 print, collect 等方法。

新旧 API 对比如下表所示

Current Interface	New Interface
tEnv.sqlUpdate("CREATE TABLE...”);	TableResult result = tEnv.executeSql("CREATE TABLE...”);
tEnv.sqlUpdate("INSERT INTO...SELECT...”);<br/>tEnv.execute();	TableResult result = <br/> tEnv.executeSql("INSERT INTO ... SELECT...”);
tEnv.sqlUpdate("insert into xx ...”); <br/>tEnv.sqlUpdate("insert into yy ...”); <br/>tEnv.execute();	StatementSet ss =tEnv.createStatementSet(); <br/>ss.addInsertSql("insert into xx ...”); <br/>ss.addInsertSql("insert into yy ...”); <br/>TableResult result = ss.execute();

对于在 Flink 1.11 上使用新接口遇到的一些常见问题，云邪做了统一解答，可在 Appendix 部分查看。

#### FLIP-95：TableSource & TableSink 重构

开发者们在 Flink SQL 1.11 版本花了大量经历对 TableSource 和 TableSink API 进行了重构，核心优化点如下

• 移除类型相关接口，简化开发，解决迷惑的类型问题，支持全类型
• 寻找 Factory 时，更清晰的报错信息
• 解决找不到 primary key 的问题
• 统一了流批 source，统一了流批 sink
• 支持读取 CDC 和输出 CDC
• 直接高效地生成 Flink SQL 内部数据结构 RowData

老 TableSink API 如下所示，其中有 6 个方法是类型相关并且还充斥着 deprecated 方法，导致 connector 经常出 bug。新 DynamicTableSink API 去掉了所有类型相关接口，因为所有的类型都是从 DDL 来的，不需要 TableSink 告诉框架是什么类型。而对于用户来说，最直观的体验就是在老版本上遇到各种奇奇怪怪报错的概率降低了很多，比如不支持的精度类型和找不到 primary key / table factory 的诡异报错在新版本上都不复存在了。关于 Flink 1.11 是如何解决这些问题的详细可以在 Appendix 部分阅读。

#### FLIP-123：Hive Dialect

Flink 1.10 版本对 Hive connector 的支持达到了生产可用，但是老版本的 Flink SQL 不支持 Hive DDL 及使用 Hive syntax，这无疑限制了 Flink connectivity。在新版本中，开发者们为支持 HiveQL 引入了新 parser，用户可以在 SQL client 的 yaml 文件中指定是否使用 Hive 语法，也可以在 SQL client 中通过 set table.sql-dialect=hive/default 动态切换。更多信息可以参考 FLIP-123。

以上简要介绍了 Flink 1.11 在 减少用户不必要的输入和操作方面对 connectivity 和 simplicity 方面做出的优化。下面会重点介绍在外部系统和数据生态方面对 connectivity 和 simplicity 的两个核心优化，并附上最佳实践介绍。

3 Hive 数仓实时化 & Flink SQL + CDC 最佳实践

FLINK-17433：Hive 数仓实时化

下图是一张非常经典的 Lambda 数仓架构，在整个大数据行业从批处理逐步拥抱流计算的许多年里代表“最先进的生产力”。然而随着业务发展和规模扩大，两套单独的架构所带来的开发、运维、计算成本问题已经日益凸显。

而 Flink 作为一个流批一体的计算引擎，在最初的设计上就认为“万物本质皆是流”，批处理是流计算的特例，如果能够在自身提供高效批处理能力的同时与现有的大数据生态结合，则能以最小侵入的方式改造现有的数仓架构使其支持流批一体。在新版本中，Flink SQL 提供了开箱即用的 “Hive 数仓同步”功能，即所有的数据加工逻辑由 Flink SQL 以流计算模式执行，在数据写入端，自动将 ODS，DWD 和 DWS 层的已经加工好的数据实时回流到 Hive table。One size (sql) fits for all suites (tables) 的设计，使得在 batch 层不再需要维护任何计算 pipeline。

对比传统架构，它带来的好处和解决的问题有哪些呢？

• 计算口径与处理逻辑统一，降低开发和运维成本

  传统架构维护两套数据 pipeline 最大的问题在于需要保持它们处理逻辑的等价性，但由于使用了不同的计算引擎（比如离线使用 Hive，实时使用 Flink 或 Spark Streaming），SQL 往往不能直接套用，存在代码上的差异性，经年累月下来，离线和实时处理逻辑很可能会完全 diverge，有些大的公司甚至会存在两个团队分别去维护实时和离线数仓，人力物力成本非常高。Flink 支持 Hive Streaming Sink 后，实时处理结果可以实时回流到 Hive 表，离线的计算层可以完全去掉，处理逻辑由 Flink SQL 统一维护，离线层只需要使用回流好的 ODS、DWD、DWS 表做进一步 ad-hoc 查询即可。

• 离线对于“数据漂移”的处理更自然，离线数仓“实时化”

  离线数仓 pipeline 非 data-driven 的调度执行方式，在跨分区的数据边界处理上往往需要很多 trick 来保证分区数据的完整性，而在两套数仓架构并行的情况下，有时会存在对 late event 处理差异导致数据对比不一致的问题。而实时 data-driven 的处理方式和 Flink 对于 event time 的友好支持本身就意味着以业务时间为分区（window），通过 event time + watermark 可以统一定义实时和离线数据的完整性和时效性，Hive Streaming Sink 更是解决了离线数仓同步的“最后一公里问题”。

  FLIP-105：支持 Change Data Capture (CDC)

除了对 Hive Streaming Sink 的支持，Flink SQL 1.11 的另一大亮点就是引入了 CDC 机制。CDC 的全称是 Change Data Capture，用于 tracking 数据库表的增删改查操作，是目前非常成熟的同步数据库变更的一种方案。在国内常见的 CDC 工具就是阿里开源的 Canal，在国外比较流行的有 Debezium。Flink SQL 在设计之初就提出了 Dynamic Table 和“流表二象性”的概念，并且在 Flink SQL 内部完整支持了 Changelog 功能，相对于其他开源流计算系统是一个重要优势。本质上 Changelog 就等价于一张一直在变化的数据库的表。Dynamic Table 这个概念是 Flink SQL 的基石， Flink SQL 的各个算子之间传递的就是 Changelog，完整地支持了 Insert、Delete、Update 这几种消息类型。

得益于 Flink SQL 运行时的强大，Flink 与 CDC 对接只需要将外部的数据流转为 Flink 系统内部的 Insert、Delete、Update 消息即可。进入到 Flink 内部后，就可以灵活地应用 Flink 各种 query 语法了。

在实际应用中，把 Debezium Kafka Connect Service 注册到 Kafka 集群并带上想同步的数据库表信息，Kafka 则会自动创建 topic 并监听 Binlog，把变更同步到 topic 中。在 Flink 端想要消费带 CDC 的数据也很简单，只需要在 DDL 中声明 format = debezium-json 即可。

在 Flink 1.11 上开发者们还做了一些有趣的探索，既然 Flink SQL 运行时能够完整支持 Changelog，那是否有可能不需要 Debezium 或者 Canal 的服务，直接通过 Flink 获取 MySQL 的变更呢？答案当然是可以，Debezium 类库的良好设计使得它的 API 可以被封装为 Flink 的 Source Function，不需要再起额外的 Service，目前这个项目已经开源，支持了 MySQL 和 Postgres 的 CDC 读取，后续也会支持更多类型的数据库，可移步`https://github.com/ververica/...
` 解锁更多使用姿势。

下面的 Demo 会介绍如何使用 flink-cdc-connectors 捕获 mysql 和 postgres 的数据变更，并利用 Flink SQL 做多流 join 后实时同步到 elasticsearch 中。

假设你在一个电商公司，订单和物流是你最核心的数据，你想要实时分析订单的发货情况。因为公司已经很大了，所以商品的信息、订单的信息、物流的信息，都分散在不同的数据库和表中。我们需要创建一个流式 ETL，去实时消费所有数据库全量和增量的数据，并将他们关联在一起，打成一个大宽表。从而方便数据分析师后续的分析。