回复
史上最全干货！Flink SQL 成神之路（一）
crazeblue
发布于 2022-9-21 10:54
浏览
1收藏
作者 | antigeneral了呀
来源 | 大数据羊说（ID：young_say）
转载请联系授权（微信ID：___antigeneral）
1.前言
呕心沥血，Flink SQL 成神之路出品。小伙伴萌可以先体验一下下图大纲。由于微信公众号限制上传图片像素，所以博主分隔成了 5 张图片。。。
NB
2.基础概念篇
2.1.SQL & Table 简介及运行环境
2.1.1.简介
Apache Flink 提供了两种关系型 API 用于统一流和批处理，Table 和 SQL API。
⭐ Table API 是一种集成在 Java、Scala 和 Python 语言中的查询 API，简单理解就是用 Java、Scala、Python 按照 SQL 的查询接口封装了一层 lambda 表达式的查询 API，它允许以强类型接口的方式组合各种关系运算符（如选择、筛选和联接）的查询操作，然后生成一个 Flink 任务运行。如下案例所示：
import org.apache.flink.table.api.*;
import static org.apache.flink.table.api.Expressions.*;
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode()
.build();
TableEnvironment tEnv = TableEnvironment.create(settings);
// 下面就是 Table API 的案例，其语义等同于
// select a, count(b) as cnt
// from Orders
// group by a
DataSet<Row> result = tEnv
.from("Orders")
.groupBy($("a"))
.select($("a"), $("b").count().as("cnt"))
.toDataSet(counts, Row.class);
result.print();⭐ SQL API 是基于 SQL 标准的 Apache Calcite 框架实现的，我们可以使用纯 SQL 来开发和运行一个 Flink 任务。如下案例所示：
insert into target
select a, count(b) as cnt
from Orders
group by a注意：无论输入是连续（流处理）还是有界（批处理），在 Table 和 SQL 任一 API 中同一条查询语句是具有相同的语义并且会产出相同的结果的。这就是说为什么 Flink SQL 和 Table API 可以做到在用户接口层面的流批统一。xdm，用一套 SQL 既能跑流任务，也能跑批任务，它不香嘛？
Table API 和 SQL API 也与 DataStream API 做到了无缝集成。可以轻松地在三种 API 之间灵活切换。例如，可以使用 SQL 的 MATCH_RECOGNIZE 子句匹配出异常的数据，然后使用再转为 DataStream API 去灵活的构建针对于异常数据的自定义报警机制。
在 xdm 大体了解了这两个 API 是干啥的之后，我们就可以直接来看看，怎么使用这两个 API 了。
2.1.2.SQL 和 Table API 运行环境依赖
根据小伙伴们使用的编程语言的不同（Java 或 Scala），需要将对应的依赖包添加到项目中。
⭐ Java 依赖如下
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-api-java-bridge_2.11</artifactId>
<version>1.13.5</version>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-planner-blink_2.11</artifactId>
<version>1.13.5</version>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-streaming-java_2.11</artifactId>
<version>1.13.5</version>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-common</artifactId>
<version>1.13.5</version>
</dependency>⭐ Scala 依赖如下
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-api-scala-bridge_2.11</artifactId>
<version>1.13.5</version>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-planner-blink_2.11</artifactId>
<version>1.13.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-streaming-scala_2.11</artifactId>
<version>1.13.5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-table-common</artifactId>
<version>1.13.5</version>
</dependency>引入上述依赖之后，小伙伴萌就可以开始使用 Table\SQL API 了。具体案例如下文所示。
2.2.SQL & Table 的基本概念及常用 API
在小伙伴萌看下文之前，先看一下 2.2 节整体的思路，跟着博主思路走，会更清晰：
- ⭐ 先通过一个 SQL\Table API 任务看一下我们在实际开发时的代码结构应该长啥样，让大家能有直观的感受
- ⭐ 重点介绍 SQL\Table API 中核心 API - TableEnvironment。SQL\Table 所有能用的接口都在 TableEnvironment 中
- ⭐ 通过两个角度（外部表\视图、临时\非临时）认识 Flink SQL 体系中的表的概念
- ⭐ 举几个创建外部表、视图的实际应用案例
2.2.1.一个 SQL\Table API 任务的代码结构
// 创建一个 TableEnvironment，为后续使用 SQL 或者 Table API 提供上线
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode() // 声明为流任务
//.inBatchMode() // 声明为批任务
.build();
TableEnvironment tEnv = TableEnvironment.create(settings);
// 创建一个输入表
tableEnv.executeSql("CREATE TEMPORARY TABLE table1 ... WITH ( 'connector' = ... )");
// 创建一个输出表
tableEnv.executeSql("CREATE TEMPORARY TABLE outputTable ... WITH ( 'connector' = ... )");
// 1. 使用 Table API 做一个查询并返回 Table
Table table2 = tableEnv.from("table1").select(...);
// 2. 使用 SQl API 做一个查询并返回 Table
Table table3 = tableEnv.sqlQuery("SELECT ... FROM table1 ... ");
// 将 table2 的结果使用 Table API 写入 outputTable 中，并返回结果
TableResult tableResult = table2.executeInsert("outputTable");
tableResult...总结一下上面案例使用到的一些 API，让大家先对 Table\SQL API 的能力有一个大概了解：
- ⭐ TableEnvironment：Table API 和 SQL API 的都集成在一个统一上下文（即 TableEnvironment）中，其地位等同于 DataStream API 中的 StreamExecutionEnvironment 的地位
- ⭐ TableEnvironment::executeSql：用于 SQL API 中，可以执行一段完整 DDL，DML SQL。举例，方法入参可以是 CREATE TABLE xxx，INSERT INTO xxx SELECT xxx FROM xxx。
- ⭐ TableEnvironment::from(xxx)：用于 Table API 中，可以以强类型接口的方式运行。方法入参是一个表名称。
- ⭐ TableEnvironment::sqlQuery：用于 SQL API 中，可以执行一段查询 SQL，并把结果以 Table 的形式返回。举例，方法的入参是 SELECT xxx FROM xxx
- ⭐ Table::executeInsert：用于将 Table 的结果插入到结果表中。方法入参是写入的目标表。
无论是对于 SQL API 来说还是对于 Table API 来说，都是使用 TableEnvironment 接口承载我们的业务查询逻辑的。只是在用户的使用接口的方式上有区别，以上述的 Java 代码为例，Table API 其实就是模拟 SQL 的查询方式封装了 Java 语言的 lambda 强类型 API，SQL 就是纯 SQL 查询。Table 和 SQL 很多时候都是掺杂在一起的，大家理解的时候就可以直接将 Table 和 SQL API 直接按照 SQL 进行理解，不用强行做特殊的区分。
而且博主推荐的话，直接上 SQL API 就行，其实 Table API 在企业实战中用的不是特别多。你说 Table API 方便吧，它确实比 DataStream API 方便，但是又比 SQL 复杂。一般生产使用不多。
注意：由于 Table 和 SQL API 基本上属于一回事，后续如果没有特别介绍的话，博主就直接按照 SQL API 进行介绍了。
如果 xdm 想直接上手运行一段 Flink SQL 的代码。
可以直接在公众号后台回复1.13.2 最全 flink sql获取源代码。所有的源码都开源到 github 上面了。里面包含了非常多的案例。可以直接拿来在本地运行的！！！肥肠的方便。
2.2.2.SQL 上下文：TableEnvironment
TableEnvironment 是使用 SQL API 永远都离不开的一个接口。其是 SQL API 使用的入口（上下文），就像是你要使用 Java DataStream API 去写一个 Flink 任务需要使用到 StreamExecutionEnvironment 一样。
可以认为 TableEnvironment 在 SQL API 中的地位和 StreamExecutionEnvironment 在 DataStream 中的地位是一样的，都是包含了一个 Flink 任务运行时的所有上下文环境信息。大家这样对比学习会比较好理解。
TableEnvironment 包含的功能如下：
- ⭐ ️Catalog 管理：Catalog 可以理解为 Flink 的 MetaStore，类似 Hive MetaStore 对在 Hive 中的地位，关于 Flink Catalog 的详细内容后续进行介绍
- ⭐ ️表管理：在 Catalog 中注册表
- ⭐️ SQL 查询：（这 TMD 还用说，最基本的功能啊），就像 DataStream 中提供了 addSource、map、flatmap 等接口
- ⭐ UDF 管理：注册用户定义（标量函数：一进一出、表函数：一进多出、聚合函数：多进一出）函数
- ⭐️ UDF 扩展：加载可插拔 Module（Module 可以理解为 Flink 管理 UDF 的模块，是可插拔的，可以让小伙伴萌自定义 Module，去支持奇奇怪怪的 UDF 功能）
- ⭐ DataStream 和 Table（Table\SQL API 的查询结果）之间进行转换：目前 1.13 版本的只有流任务支持，批任务不支持。1.14 支持批任务。
接下来介绍如何创建一个 TableEnvironment。案例为 Java。easy game。
⭐ 方法 1：通过 EnvironmentSettings 创建 TableEnvironment
import org.apache.flink.table.api.EnvironmentSettings;
import org.apache.flink.table.api.TableEnvironment;
// 1. 就是设置一些环境信息
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode() // 声明为流任务
//.inBatchMode() // 声明为批任务
.build();
// 2. 创建 TableEnvironment
TableEnvironment tEnv = TableEnvironment.create(settings);在 1.13 版本中。
如果你是 inStreamingMode，则最终创建出来的 TableEnvironment 实例为 StreamTableEnvironmentImpl。
如果你是 inBatchMode，则最终创建出来的 TableEnvironment 实例为 TableEnvironmentImpl。
它两虽然都继承了 TableEnvironment 接口，但是 StreamTableEnvironmentImpl 支持的功能更多一些。大家可以直接去看看接口实验一下，这里就不进行详细介绍。
⭐ 方法 2：通过已有的 StreamExecutionEnvironment 创建 TableEnvironment
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.table.api.EnvironmentSettings;
import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env);2.2.3.SQL 中表的概念
一个表的全名（标识）会由三个部分组成：Catalog 名称.数据库名称.表名称。如果 Catalog 名称或者数据库名称没有指明，就会使用当前默认值 default。
举个例子，下面这个 SQL 创建的 Table 的全名为 default.default.table1。
tableEnv.executeSql("CREATE TEMPORARY TABLE table1 ... WITH ( 'connector' = ... )");下面这个 SQL 创建的 Table 的全名为 default.mydatabase.table1。
tableEnv.executeSql("CREATE TEMPORARY TABLE mydatabase.table1 ... WITH ( 'connector' = ... )");表可以是常规的（外部表 TABLE），也可以是虚拟的（视图 VIEW）。
- ⭐ 外部表 TABLE：描述的是外部数据，例如文件（HDFS）、消息队列（Kafka）等。依然拿离线 Hive SQL 举个例子，离线中一个表指的是 Hive 表，也就是所说的外部数据。
- ⭐ 视图 VIEW：从已经存在的表中创建，视图一般是一个 SQL 逻辑的查询结果。对比到离线的 Hive SQL 中，在离线的场景（Hive 表）中 VIEW 也都是从已有的表中去创建的。其实 Flink 也是一样的。
注意：
这里有不同的地方就是，离线 Hive MetaStore 中不会有 Catalog 这个概念，其标识都是 数据库.数据表。
2.2.4.SQL 临时表、永久表
表（视图、外部表）可以是临时的，并与单个 Flink session（可以理解为 Flink 任务运行一次就是一个 session）的生命周期绑定。
表（视图、外部表）也可以是永久的，并且对多个 Flink session 都生效。
⭐ 临时表：通常保存于内存中并且仅在创建它们的 Flink session（可以理解为一次 Flink 任务的运行）持续期间存在。这些表对于其它 session（即其他 Flink 任务或非此次运行的 Flink 任务）是不可见的。因为这个表的元数据没有被持久化。如下案例：
-- 临时外部表
CREATE TEMPORARY TABLE source_table (
user_id BIGINT,
`name` STRING
) WITH (
'connector' = 'user_defined',
'format' = 'json',
'class.name' = 'flink.examples.sql._03.source_sink.table.user_defined.UserDefinedSource'
);
-- 临时视图
CREATE TEMPORARY VIEW query_view as
SELECT
*
FROM source_table
;⭐ 永久表：需要外部 Catalog（例如 Hive Metastore）来持久化表的元数据。一旦永久表被创建，它将对任何连接到这个 Catalog 的 Flink session 可见且持续存在，直至从 Catalog 中被明确删除。如下案例：
-- 永久外部表。需要外部 Catalog 持久化！！！
CREATE TABLE source_table (
user_id BIGINT,
`name` STRING
) WITH (
'connector' = 'user_defined',
'format' = 'json',
'class.name' = 'flink.examples.sql._03.source_sink.table.user_defined.UserDefinedSource'
);
-- 永久视图。需要外部 Catalog 持久化！！！
CREATE VIEW query_view as
SELECT
*
FROM source_table
;⭐ 如果临时表和永久表使用了相同的名称（Catalog名.数据库名.表名）。那么在这个 Flink session 中，你的任务访问到这个表时，访问到的永远是临时表（即相同名称的表，临时表会屏蔽永久表）。
2.2.5.SQL 外部数据表
由于目前在实时数据的场景中多以消息队列作为数据表。此处就以 Kafka 为例创建一个外部数据表。
⭐ Table API 创建外部数据表
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env =
StreamExecutionEnvironment.createLocalEnvironmentWithWebUI(new Configuration());
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.useBlinkPlanner()
.inStreamingMode()
.build();
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env, settings);
// kafka 数据源
DataStream<Row> r = env.addSource(new FlinkKafkaConsumer<Row>(xxx));
// 将 DataStream 转为一个 Table API 中的 Table 对象进行使用
Table sourceTable = tEnv.fromDataStream(r
, Schema
.newBuilder()
.column("f0", "string")
.column("f1", "string")
.column("f2", "bigint")
.columnByExpression("proctime", "PROCTIME()")
.build());
tEnv.createTemporaryView("source_table", sourceTable);
String selectWhereSql = "select f0 from source_table where f1 = 'b'";
Table resultTable = tEnv.sqlQuery(selectWhereSql);
tEnv.toRetractStream(resultTable, Row.class).print();
env.execute();
}上述案例中，Table API 将一个 DataStream 的结果集通过 StreamTableEnvironment::fromDataStream 转为一个 Table 对象来使用。
⭐ SQL API 创建外部数据表
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.useBlinkPlanner()
.inStreamingMode()
.build();
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env, settings);
// SQL API 执行 create table 创建表
tEnv.executeSql(
"CREATE TABLE KafkaSourceTable (\n"
+ " `f0` STRING,\n"
+ " `f1` STRING\n"
+ ") WITH (\n"
+ " 'connector' = 'kafka',\n"
+ " 'topic' = 'topic',\n"
+ " 'properties.bootstrap.servers' = 'localhost:9092',\n"
+ " 'properties.group.id' = 'testGroup',\n"
+ " 'format' = 'json'\n"
+ ")"
);
Table t = tEnv.sqlQuery("SELECT * FROM KafkaSourceTable");具体的创建方式就是使用 Create Table xxx DDL 定义一个 Kafka 数据源（输入）表（也可以是 Kafka 数据汇（输出）表）。
xdm，是不是又和 Hive 一样？惊不惊喜意不意外。对比学习 +1。
2.2.6.SQL 视图 VIEW
上文已经说了，一个 VIEW 其实就是一段 SQL 逻辑的查询结果。
视图 VIEW 在 Table API 中的体现就是：一个 Table 的 Java 对象，其封装了一段查询逻辑。如下案例所示：
⭐ Table API 创建 VIEW
import org.apache.flink.table.api.EnvironmentSettings;
import org.apache.flink.table.api.TableEnvironment;
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode() // 声明为流任务
.build();
TableEnvironment tEnv = TableEnvironment.create(settings);
// Table API 中的一个 Table 对象
Table projTable = tEnv.from("X").select(...);
// 将 projTable 创建为一个叫做 projectedTable 的 VIEW
tEnv.createTemporaryView("projectedTable", projTable);Table API 是使用了 TableEnvironment::createTemporaryView 接口将一个 Table 对象创建为一个 VIEW。
⭐ SQL API 创建 VIEW
import org.apache.flink.table.api.EnvironmentSettings;
import org.apache.flink.table.api.TableEnvironment;
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode() // 声明为流任务
.build();
TableEnvironment tEnv = TableEnvironment.create(settings);
String sql = "CREATE TABLE source_table (\n"
+ " user_id BIGINT,\n"
+ " `name` STRING\n"
+ ") WITH (\n"
+ " 'connector' = 'user_defined',\n"
+ " 'format' = 'json',\n"
+ " 'class.name' = 'flink.examples.sql._03.source_sink.table.user_defined.UserDefinedSource'\n"
+ ");\n"
+ "\n"
+ "CREATE TABLE sink_table (\n"
+ " user_id BIGINT,\n"
+ " name STRING\n"
+ ") WITH (\n"
+ " 'connector' = 'print'\n"
+ ");\n"
+ "CREATE VIEW query_view as\n" // 创建 VIEW
+ "SELECT\n"
+ " *\n"
+ "FROM source_table\n"
+ ";\n"
+ "INSERT INTO sink_table\n"
+ "SELECT\n"
+ " *\n"
+ "FROM query_view;";
Arrays.stream(sql.split(";"))
.forEach(tEnv::executeSql);SQL API 是直接通过一段 CREATE VIEW query_view as select * from source_table 来创建的 VIEW，是纯 SQL 写法。
这种创建方式是不是贼熟悉，和离线 Hive 一样 +1~
注意：
在 Table API 中的一个 Table 对象被后续的多个查询使用的场景下：Table 对象不会真的产生一个中间表供下游多个查询去引用，即多个查询不共享这个 Table 的结果，小伙伴萌可以理解为是一种中间表的简化写法，不会先产出一个中间表结果，然后将这个结果在下游多个查询中复用，后续的多个查询会将这个 Table 的逻辑执行多次。类似于 with tmp as (DML) 的语法
2.2.7.一个 SQL 查询案例
首先，如果 xdm 想直接上手运行一段 Flink SQL 的代码。
可以直接在公众号后台回复1.13.2 最全 flink sql获取源代码。所有的源码都开源到 github 上面了。里面包含了非常多的案例。可以直接拿来在本地运行的！！！肥肠的方便。
来看看一个 SQL 查询案例。
- ⭐ 案例场景：计算每一种商品（sku_id 唯一标识）的售出个数、总销售额、平均销售额、最低价、最高价
- ⭐ 数据准备：数据源为商品的销售流水（sku_id：商品，price：销售价格），然后写入到 Kafka 的指定 topic（sku_id：商品，count_result：售出个数、sum_result：总销售额、avg_result：平均销售额、min_result：最低价、max_result：最高价）当中
- ⭐ 任务代码：
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.inStreamingMode() // 声明为流任务
//.inBatchMode() // 声明为批任务
.build();
TableEnvironment tEnv = TableEnvironment.create(settings);
// 1. 创建一个数据源（输入）表，这里的数据源是 flink 自带的一个随机 mock 数据的数据源。
String sourceSql = "CREATE TABLE source_table (\n"
+ " sku_id STRING,\n"
+ " price BIGINT\n"
+ ") WITH (\n"
+ " 'connector' = 'datagen',\n"
+ " 'rows-per-second' = '1',\n"
+ " 'fields.sku_id.length' = '1',\n"
+ " 'fields.price.min' = '1',\n"
+ " 'fields.price.max' = '1000000'\n"
+ ")";
// 2. 创建一个数据汇（输出）表，输出到 kafka 中
String sinkSql = "CREATE TABLE sink_table (\n"
+ " sku_id STRING,\n"
+ " count_result BIGINT,\n"
+ " sum_result BIGINT,\n"
+ " avg_result DOUBLE,\n"
+ " min_result BIGINT,\n"
+ " max_result BIGINT,\n"
+ " PRIMARY KEY (`sku_id`) NOT ENFORCED\n"
+ ") WITH (\n"
+ " 'connector' = 'upsert-kafka',\n"
+ " 'topic' = 'tuzisir',\n"
+ " 'properties.bootstrap.servers' = 'localhost:9092',\n"
+ " 'key.format' = 'json',\n"
+ " 'value.format' = 'json'\n"
+ ")";
// 3. 执行一段 group by 的聚合 SQL 查询
String selectWhereSql = "insert into sink_table\n"
+ "select sku_id,\n"
+ " count(*) as count_result,\n"
+ " sum(price) as sum_result,\n"
+ " avg(price) as avg_result,\n"
+ " min(price) as min_result,\n"
+ " max(price) as max_result\n"
+ "from source_table\n"
+ "group by sku_id";
tEnv.executeSql(sourceSql);
tEnv.executeSql(sinkSql);
tEnv.executeSql(selectWhereSql);2.2.8.SQL 与 DataStream API 的转换
大家会比较好奇，要写 SQL 就纯 SQL 呗，要写 DataStream 就纯 DataStream 呗，为啥还要把这两类接口做集成呢？
博主举一个案例：在 pdd 这种发补贴券的场景下，希望可以在发的补贴券总金额超过 1w 元时，及时报警出来，来帮助控制预算，防止发的太多。
对应的解决方案，我们可以想到使用 SQL 计算补贴券发放的结果，但是 SQL 的问题在于无法做到报警。所以我们可以将 SQL 的查询的结果（即 Table 对象）转为 DataStream，然后就可以在 DataStream 后自定义报警逻辑的算子。
我们直接上 SQL 和 DataStream API 互相转化的案例：
public static void main(String[] args) throws Exception {
FlinkEnv flinkEnv = FlinkEnvUtils.getStreamTableEnv(args);
// 1. pdd 发补贴券流水数据
String createTableSql = "CREATE TABLE source_table (\n"
+ " id BIGINT,\n" -- 补贴券的流水 id
+ " money BIGINT,\n" -- 补贴券的金额
+ " row_time AS cast(CURRENT_TIMESTAMP as timestamp_LTZ(3)),\n"
+ " WATERMARK FOR row_time AS row_time - INTERVAL '5' SECOND\n"
+ ") WITH (\n"
+ " 'connector' = 'datagen',\n"
+ " 'rows-per-second' = '1',\n"
+ " 'fields.id.min' = '1',\n"
+ " 'fields.id.max' = '100000',\n"
+ " 'fields.money.min' = '1',\n"
+ " 'fields.money.max' = '100000'\n"
+ ")\n";
// 2. 计算总计发放补贴券的金额
String querySql = "SELECT UNIX_TIMESTAMP(CAST(window_end AS STRING)) * 1000 as window_end, \n"
+ " window_start, \n"
+ " sum(money) as sum_money,\n" -- 补贴券的发放总金额
+ " count(distinct id) as count_distinct_id\n"
+ "FROM TABLE(CUMULATE(\n"
+ " TABLE source_table\n"
+ " , DESCRIPTOR(row_time)\n"
+ " , INTERVAL '5' SECOND\n"
+ " , INTERVAL '1' DAY))\n"
+ "GROUP BY window_start, \n"
+ " window_end";
flinkEnv.streamTEnv().executeSql(createTableSql);
Table resultTable = flinkEnv.streamTEnv().sqlQuery(querySql);
// 3. 将金额结果转为 DataStream，然后自定义超过 1w 的报警逻辑
flinkEnv.streamTEnv()
.toDataStream(resultTable, Row.class)
.flatMap(new FlatMapFunction<Row, Object>() {
@Override
public void flatMap(Row value, Collector<Object> out) throws Exception {
long l = Long.parseLong(String.valueOf(value.getField("sum_money")));
if (l > 10000L) {
log.info("报警，超过 1w");
}
}
});
flinkEnv.env().execute();
}注意：
目前在 1.13 版本中，Flink 对于 Table 和 DataStream 的转化是有一些限制的：上面的案例可以看到，Table 和 DataStream 之间的转换目前只有 StreamTableEnvironment::toDataStream、StreamTableEnvironment::fromDataStream 接口支持。
所以其实小伙伴萌可以理解为只有流任务才支持 Table 和 DataStream 之间的转换，批任务是不支持的（虽然可以使用流执行模式处理有界流 - 批数据，也就是模拟按照批执行，但效率较低，这种骚操作不建议大家搞）。
那什么时候才能支持批任务的 Table 和 DataStream 之间的转换呢？1.14 版本支持。1.14 版本中，流和批的都统一到了 StreamTableEnvironment 中，因此就可以做 Table 和 DataStream 的互相转换了。
2.3.SQL 数据类型
在介绍完一些基本概念之后，我们来认识一下，Flink SQL 中的数据类型。
Flink SQL 内置了很多常见的数据类型，并且也为用户提供了自定义数据类型的能力。
总共包含 3 部分：
- ⭐ 原子数据类型
- ⭐ 复合数据类型
- ⭐ 用户自定义数据类型
2.3.1.原子数据类型
⭐ 字符串类型：
⭐ CHAR、CHAR(n)：定长字符串，就和 Java 中的 Char 一样，n 代表字符的定长，取值范围 [1, 2,147,483,647]。如果不指定 n，则默认为 1。
⭐ VARCHAR、VARCHAR(n)、STRING：可变长字符串，就和 Java 中的 String 一样，n 代表字符的最大长度，取值范围 [1, 2,147,483,647]。如果不指定 n，则默认为 1。STRING 等同于 VARCHAR(2147483647)。
⭐ 二进制字符串类型：
⭐ BINARY、BINARY(n)：定长二进制字符串，n 代表定长，取值范围 [1, 2,147,483,647]。如果不指定 n，则默认为 1。
⭐ VARBINARY、VARBINARY(n)、BYTES：可变长二进制字符串，n 代表字符的最大长度，取值范围 [1, 2,147,483,647]。如果不指定 n，则默认为 1。BYTES 等同于 VARBINARY(2147483647)。
⭐ 精确数值类型：
⭐ DECIMAL、DECIMAL(p)、DECIMAL(p, s)、DEC、DEC(p)、DEC(p, s)、NUMERIC、NUMERIC(p)、NUMERIC(p, s)：固定长度和精度的数值类型，就和 Java 中的 BigDecimal 一样，p 代表数值位数（长度），取值范围 [1, 38]；s 代表小数点后的位数（精度），取值范围 [0, p]。如果不指定，p 默认为 10，s 默认为 0。
⭐ TINYINT：-128 到 127 的 1 字节大小的有符号整数，就和 Java 中的 byte 一样。
⭐ SMALLINT：-32,768 to 32,767 的 2 字节大小的有符号整数，就和 Java 中的 short 一样。
⭐ INT、INTEGER：-2,147,483,648 to 2,147,483,647 的 4 字节大小的有符号整数，就和 Java 中的 int 一样。
⭐ BIGINT：-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 的 8 字节大小的有符号整数，就和 Java 中的 long 一样。
⭐ 有损精度数值类型：
⭐ FLOAT：4 字节大小的单精度浮点数值，就和 Java 中的 float 一样。
⭐ DOUBLE、DOUBLE PRECISION：8 字节大小的双精度浮点数值，就和 Java 中的 double 一样。
⭐ 关于 FLOAT 和 DOUBLE 的区别可见 https://www.runoob.com/w3cnote/float-and-double-different.html
⭐ 布尔类型：BOOLEAN
⭐ NULL 类型：NULL
⭐ Raw 类型：RAW('class', 'snapshot') 。只会在数据发生网络传输时进行序列化，反序列化操作，可以保留其原始数据。以 Java 举例，class 参数代表具体对应的 Java 类型，snapshot 代表类型在发生网络传输时的序列化器
⭐ 日期、时间类型：
⭐ DATE：由 年-月-日 组成的 不带时区含义 的日期类型，取值范围 [0000-01-01, 9999-12-31]
⭐ TIME、TIME(p)：由 小时：分钟：秒[.小数秒] 组成的 不带时区含义 的的时间的数据类型，精度高达纳秒，取值范围 [00:00:00.000000000到23:59:59.9999999]。其中 p 代表小数秒的位数，取值范围 [0, 9]，如果不指定 p，默认为 0。
⭐ TIMESTAMP、TIMESTAMP(p)、TIMESTAMP WITHOUT TIME ZONE、TIMESTAMP(p) WITHOUT TIME ZONE：由 年-月-日 小时：分钟：秒[.小数秒] 组成的 不带时区含义 的时间类型，取值范围 [0000-01-01 00:00:00.000000000, 9999-12-31 23:59:59.999999999]。其中 p 代表小数秒的位数，取值范围 [0, 9]，如果不指定 p，默认为 6。
⭐ TIMESTAMP WITH TIME ZONE、TIMESTAMP(p) WITH TIME ZONE：由 年-月-日 小时：分钟：秒[.小数秒] 时区 组成的 带时区含义 的时间类型，取值范围 [0000-01-01 00:00:00.000000000 +14:59, 9999-12-31 23:59:59.999999999 -14:59]。其中 p 代表小数秒的位数，取值范围 [0, 9]，如果不指定 p，默认为 6。
⭐ TIMESTAMP_LTZ、TIMESTAMP_LTZ(p)：由 年-月-日 小时：分钟：秒[.小数秒] 时区 组成的 带时区含义 的时间类型，取值范围 [0000-01-01 00:00:00.000000000 +14:59, 9999-12-31 23:59:59.999999999 -14:59]。其中 p 代表小数秒的位数，取值范围 [0, 9]，如果不指定 p，默认为 6。
⭐ TIMESTAMP_LTZ 与 TIMESTAMP WITH TIME ZONE 的区别在于：TIMESTAMP WITH TIME ZONE 的时区信息是携带在数据中的，举例：其输入数据应该是 2022-01-01 00:00:00.000000000 +08:00；TIMESTAMP_LTZ 的时区信息不是携带在数据中的，而是由 Flink SQL 任务的全局配置决定的，我们可以由 table.local-time-zone 参数来设置时区。
⭐ INTERVAL YEAR TO MONTH、 INTERVAL DAY TO SECOND：interval 的涉及到的种类比较多。INTERVAL 主要是用于给 TIMESTAMP、TIMESTAMP_LTZ 添加偏移量的。举例，比如给 TIMESTAMP 加、减几天、几个月、几年。INTERVAL 子句总共涉及到的语法种类如下 Flink SQL 案例所示。
CREATE TABLE sink_table (
result_interval_year TIMESTAMP(3),
result_interval_year_p TIMESTAMP(3),
result_interval_year_p_to_month TIMESTAMP(3),
result_interval_month TIMESTAMP(3),
result_interval_day TIMESTAMP(3),
result_interval_day_p1 TIMESTAMP(3),
result_interval_day_p1_to_hour TIMESTAMP(3),
result_interval_day_p1_to_minute TIMESTAMP(3),
result_interval_day_p1_to_second_p2 TIMESTAMP(3),
result_interval_hour TIMESTAMP(3),
result_interval_hour_to_minute TIMESTAMP(3),
result_interval_hour_to_second TIMESTAMP(3),
result_interval_minute TIMESTAMP(3),
result_interval_minute_to_second_p2 TIMESTAMP(3),
result_interval_second TIMESTAMP(3),
result_interval_second_p2 TIMESTAMP(3)
) WITH (
'connector' = 'print'
);
INSERT INTO sink_table
SELECT
-- Flink SQL 支持的所有 INTERVAL 子句如下，总体可以分为 `年-月`、`日-小时-秒` 两种
-- 1. 年-月。取值范围为 [-9999-11, +9999-11]，其中 p 是指有效位数，取值范围 [1, 4]，默认值为 2。比如如果值为 1000，但是 p = 2，则会直接报错。
-- INTERVAL YEAR
f1 + INTERVAL '10' YEAR as result_interval_year
-- INTERVAL YEAR(p)
, f1 + INTERVAL '100' YEAR(3) as result_interval_year_p
-- INTERVAL YEAR(p) TO MONTH
, f1 + INTERVAL '10-03' YEAR(3) TO MONTH as result_interval_year_p_to_month
-- INTERVAL MONTH
, f1 + INTERVAL '13' MONTH as result_interval_month
-- 2. 日-小时-秒。取值范围为 [-999999 23:59:59.999999999, +999999 23:59:59.999999999]，其中 p1\p2 都是有效位数，p1 取值范围 [1, 6]，默认值为 2；p2 取值范围 [0, 9]，默认值为 6
-- INTERVAL DAY
, f1 + INTERVAL '10' DAY as result_interval_day
-- INTERVAL DAY(p1)
, f1 + INTERVAL '100' DAY(3) as result_interval_day_p1
-- INTERVAL DAY(p1) TO HOUR
, f1 + INTERVAL '10 03' DAY(3) TO HOUR as result_interval_day_p1_to_hour
-- INTERVAL DAY(p1) TO MINUTE
, f1 + INTERVAL '10 03:12' DAY(3) TO MINUTE as result_interval_day_p1_to_minute
-- INTERVAL DAY(p1) TO SECOND(p2)
, f1 + INTERVAL '10 00:00:00.004' DAY TO SECOND(3) as result_interval_day_p1_to_second_p2
-- INTERVAL HOUR
, f1 + INTERVAL '10' HOUR as result_interval_hour
-- INTERVAL HOUR TO MINUTE
, f1 + INTERVAL '10:03' HOUR TO MINUTE as result_interval_hour_to_minute
-- INTERVAL HOUR TO SECOND(p2)
, f1 + INTERVAL '00:00:00.004' HOUR TO SECOND(3) as result_interval_hour_to_second
-- INTERVAL MINUTE
, f1 + INTERVAL '10' MINUTE as result_interval_minute
-- INTERVAL MINUTE TO SECOND(p2)
, f1 + INTERVAL '05:05.006' MINUTE TO SECOND(3) as result_interval_minute_to_second_p2
-- INTERVAL SECOND
, f1 + INTERVAL '3' SECOND as result_interval_second
-- INTERVAL SECOND(p2)
, f1 + INTERVAL '300' SECOND(3) as result_interval_second_p2
FROM (SELECT TO_TIMESTAMP_LTZ(1640966476500, 3) as f1)2.3.2.复合数据类型
- ⭐ 数组类型：ARRAY、t ARRAY。数组最大长度为 2,147,483,647。t 代表数组内的数据类型。举例 ARRAY、ARRAY，其等同于 INT ARRAY、STRING ARRAY
- ⭐ Map 类型：MAP<kt, vt>。Map 类型就和 Java 中的 Map 类型一样，key 是没有重复的。举例 Map<STRING, INT>、Map<BIGINT, STRING>
- ⭐ 集合类型：MULTISET、t MULTISET。就和 Java 中的 List 类型，一样，运行重复的数据。举例 MULTISET，其等同于 INT MULTISET
- ⭐ 对象类型：ROW<n0 t0, n1 t1, ...>、ROW<n0 t0 'd0', n1 t1 'd1', ...>、ROW(n0 t0, n1 t1, ...>、ROW(n0 t0 'd0', n1 t1 'd1', ...)。就和 Java 中的自定义对象一样。举例：ROW(myField INT, myOtherField BOOLEAN)，其等同于 ROW<myField INT, myOtherField BOOLEAN>
2.3.3.用户自定义数据类型
用户自定义类型就是运行用户使用 Java 等语言自定义一个数据类型出来。但是目前数据类型不支持使用 CREATE TABLE 的 DDL 进行定义，只支持作为函数的输入输出参数。如下案例：
⭐ 第一步，自定义数据类型
public class User {
// 1. 基础类型，Flink 可以通过反射类型信息自动把数据类型获取到
// 关于 SQL 类型和 Java 类型之间的映射见：https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/dev/table/types/#data-type-extraction
public int age;
public String name;
// 2. 复杂类型，用户可以通过 @DataTypeHint("DECIMAL(10, 2)") 注解标注此字段的数据类型
public @DataTypeHint("DECIMAL(10, 2)") BigDecimal totalBalance;
}⭐ 第二步，在 UDF 中使用此数据类型
public class UserScalarFunction extends ScalarFunction {
// 1. 自定义数据类型作为输出参数
public User eval(long i) {
if (i > 0 && i <= 5) {
User u = new User();
u.age = (int) i;
u.name = "name1";
u.totalBalance = new BigDecimal(1.1d);
return u;
} else {
User u = new User();
u.age = (int) i;
u.name = "name2";
u.totalBalance = new BigDecimal(2.2d);
return u;
}
}
// 2. 自定义数据类型作为输入参数
public String eval(User i) {
if (i.age > 0 && i.age <= 5) {
User u = new User();
u.age = 1;
u.name = "name1";
u.totalBalance = new BigDecimal(1.1d);
return u.name;
} else {
User u = new User();
u.age = 2;
u.name = "name2";
u.totalBalance = new BigDecimal(2.2d);
return u.name;
}
}
}⭐ 第三步，在 Flink SQL 中使用
-- 1. 创建 UDF
CREATE FUNCTION user_scalar_func AS 'flink.examples.sql._12_data_type._02_user_defined.UserScalarFunction';
-- 2. 创建数据源表
CREATE TABLE source_table (
user_id BIGINT NOT NULL COMMENT '用户 id'
) WITH (
'connector' = 'datagen',
'rows-per-second' = '1',
'fields.user_id.min' = '1',
'fields.user_id.max' = '10'
);
-- 3. 创建数据汇表
CREATE TABLE sink_table (
result_row_1 ROW<age INT, name STRING, totalBalance DECIMAL(10, 2)>,
result_row_2 STRING
) WITH (
'connector' = 'print'
);
-- 4. SQL 查询语句
INSERT INTO sink_table
select
-- 4.a. 用户自定义类型作为输出
user_scalar_func(user_id) as result_row_1,
-- 4.b. 用户自定义类型作为输出及输入
user_scalar_func(user_scalar_func(user_id)) as result_row_2
from source_table;
-- 5. 查询结果
+I[+I[9, name2, 2.20], name2]
+I[+I[1, name1, 1.10], name1]
+I[+I[5, name1, 1.10], name1]2.4.SQL 动态表 & 连续查询
在小伙伴萌看下文之前，先看一下 2.4 节整体的思路，跟着博主思路走，会更清晰：
- ⭐ 先分析一下将 SQL 应用到流处理的思路
- ⭐ SQL 应用于批处理已经很成熟了，通过对比流批处理在输入、数据处理、输出的异同点来分析出将 SQL 应用于流处理的核心要解决的问题点
- ⭐ 分析如何使用 SQL 动态输入表 技术来将 输入数据流 映射到 SQL 中的输入表
- ⭐ 分析如何使用 SQL 连续查询 技术来将 计算逻辑 映射到 SQL 中的运算语义
- ⭐ 使用 SQL 动态表 & 连续查询技术 两种技术方案来将 流式 SQL 实际应用到两个常见案例中
- ⭐ 分析 SQL 连续查询 的两种类型：更新（Update）查询 & 追加（Append）查询
- ⭐ 分析如何使用 SQL 动态输出表 技术来将 输出数据流 映射到 SQL 中的输出表
博主认为读完本节你应该掌握：
- ⭐ SQL 动态输入表、SQL 动态输出表
- ⭐ SQL 连续查询 的两种类型分别对应的查询场景及 SQL 语义
2.4.1.SQL 应用于流处理的思路
在流式 SQL 诞生之前，所有的基于 SQL 的数据查询都是基于批数据的，没有将 SQL 应用到流数据处理这一说法。
那么如果我们想将 SQL 应用到流处理中，必然要站在巨人的肩膀（批数据处理的流程）上面进行，那么具体的分析思路如下：
- ⭐ 步骤一：先比较 批处理 与 流处理 的异同之处：如果有相同的部分，那么可以直接复用；不同之处才是我们需要重点克服和关注的。
- ⭐ 步骤二：摘出 1 中说到的不同之处，分析如果要满足这个不同之处，目前有哪些技术是类似的
- ⭐ 步骤三：再从这些类似的技术上进一步发展，以满足将 SQL 应用于流任务中
博主下文就会根据上述三个步骤来一步一步介绍 动态表 诞生的背景以及这个概念是如何诞生的。
2.4.2.流批处理的异同点及将 SQL 应用于流处理核心解决的问题
首先对比一下常见的 批处理 和 流处理 中 数据源（输入表）、处理逻辑、数据汇（结果表） 的异同点。
对比上述流批处理之后，我们得到了要将 SQL 应用于流式任务的三个要解决的核心点：
- ⭐ SQL 输入表：分析如何将一个实时的，源源不断的输入流数据表示为 SQL 中的输入表。
- ⭐ SQL 处理计算：分析将 SQL 查询逻辑翻译成什么样的底层处理技术才能够实时的处理流式输入数据，然后产出流式输出数据。
- ⭐ SQL 输出表：分析如何将 SQL 查询输出的源源不断的流数据表示为一个 SQL 中的输出表。
将上面 3 个点总结一下，也就引出了本节的 动态表 和 连续查询 两种技术方案：
- ⭐ 动态表：源源不断的输入、输出流数据映射到 动态表
- ⭐ 连续查询：实时处理输入数据，产出输出数据的实时处理技术
2.4.3.SQL 流处理的输入：输入流映射为 SQL 动态输入表
动态表。这里的动态其实是相比于批处理的静态（有界）来说的。 - ⭐ 静态表：应用于批处理数据中，静态表可以理解为是不随着时间实时进行变化的。一般都是一天、一小时的粒度新生成一个分区。
- ⭐ 动态表：动态表是随时间实时进行变化的。是将 SQL 体系中表的概念应用到 Flink 上面的的核心点。
来看一个具体的案例，下图显示了点击事件流（左侧）如何转换为动态表（右侧）。当数据源生成更多的点击事件记录时，映射出来的动态表也会不断增长，这就是动态表的概念：
Dynamic Table
2.4.4.SQL 流处理的计算：实时处理底层技术 - SQL 连续查询
连续查询。
部分高级关系数据库系统提供了一个称为物化视图（Materialized Views) 的特性。
物化视图其实就是一条 SQL 查询，就像常规的虚拟视图 VIEW 一样。但与虚拟视图不同的是，物化视图会缓存查询的结果，因此在请求访问视图时不需要对查询进行重新计算，可以直接获取物化视图的结果，小伙伴萌可以认为物化视图其实就是把结果缓存了下来。
举个例子：批处理中，如果以 Hive 天级别的物化视图来说，其实就是每天等数据源 ready 之后，调度物化视图的 SQL 执行然后产生新的结果提供服务。那么就可以认为一条表示了输入、处理、输出的 SQL 就是一个构建物化视图的过程。
映射到我们的流任务中，输入、处理逻辑、输出这一套流程也是一个物化视图的概念。相比批处理来说，流处理中，我们的数据源表的数据是源源不断的。那么从输入、处理、输出的整个物化视图的维护流程也必须是实时的。
因此我们就需要引入一种实时视图维护（Eager View Maintenance）的技术去做到：一旦更新了物化视图的数据源表就立即更新视图的结果，从而保证输出的结果也是最新的。
这种 实时视图维护（Eager View Maintenance）的技术就叫做 连续查询。
注意：
⭐ 连续查询（Continuous Query） 不断的消费动态输入表的的数据，不断的更新动态结果表的数据。
⭐ 连续查询（Continuous Query） 的产出的结果 = 批处理模式在输入表的上执行的相同查询的结果。相同的 SQL，对应于同一个输入数据，虽然执行方式不同，但是流处理和批处理的结果是永远都会相同的。
2.4.5.SQL 流处理实际应用：动态表 & 连续查询技术的两个实战案例
总结前两节，动态表 & 连续查询 两项技术在一条流 SQL 中的执行流程总共包含了三个步骤，如下图及总结所示：
Query
- ⭐ 第一步：将数据输入流转换为 SQL 中的动态输入表。这里的转化其实就是指将输入流映射（绑定）为一个动态输入表。上图虽然分开画了，但是可以理解为一个东西。
- ⭐ 第二步：在动态输入表上执行一个连续查询，然后生成一个新的动态结果表。
- ⭐ 第三步：生成的动态结果表被转换回数据输出流。
我们实际介绍一个案例来看看其运行方式，以上文介绍到的点击事件流为例，点击事件流数据的字段如下：
[
user: VARCHAR, // 用户名
cTime: TIMESTAMP, // 访问 URL 的时间
url: VARCHAR // 用户访问的 URL
]⭐ 第一步，将输入数据流映射为一个动态输入表。以下图为例，我们将点击事件流（图左）转换为动态表 (图右)。当点击数据源源不断的来到时，动态表的数据也会不断的增加。
Dynamic Table
⭐ 第二步，在点击事件流映射的动态输入表上执行一个连续查询（Continuous Query），并生成一个新的动态输出表。
下面介绍两个查询的案例：
第一个查询：一个简单的 GROUP-BY COUNT 聚合查询，写过 SQL 的都不会陌生吧，这种应该都是最基础，最常用的对数据按照类别分组的方法。
如下图所示 group by 聚合的常用案例。
time
那么本案例中呢，是基于 clicks 表中 user 字段对 clicks 表（点击事件流）进行分组，来统计每一个 user 的访问的 URL 的数量。下面的图展示了当 clicks 输入表来了新数据（即表更新时），连续查询（Continuous Query） 的计算逻辑。
group agg
当查询开始，clicks 表(左侧)是空的。
- ⭐ 当第一行数据被插入到 clicks 表时，连续查询（Continuous Query）开始计算结果数据。数据源表第一行数据 [Mary,./home] 输入后，会计算结果 [Mary, 1] 插入（insert）结果表。
- ⭐ 当第二行 [Bob, ./cart] 插入到 clicks 表时，连续查询（Continuous Query）会计算结果 [Bob, 1]，并插入（insert）到结果表。
- ⭐ 第三行 [Mary, ./prod?id=1] 输出时，会计算出[Mary, 2]（user 为 Mary 的数据总共来过两条，所以为 2），并更新（update）结果表，[Mary, 1] 更新成 [Mary, 2]。
- ⭐ 最后，当第四行数据加入 clicks 表时，查询将第三行 [Liz, 1] 插入（insert）结果表中。
注意上述特殊标记出来的字体，可以看到连续查询对于结果的数据输出方式有两种：
- ⭐ 插入（insert）结果表
- ⭐ 更新（update）结果表
大家对于 插入（insert）结果表 这件事都比较好理解，因为离线数据都只有插入这个概念。
但是 更新（update）结果表 就是离线处理中没有概念了。这就是连续查询中中比较重要一个概念。后文会介绍。
接下来介绍第二条查询语句。
第二条查询与第一条类似，但是 group by 中除了 user 字段之外，还 group by 了 tumble，其代表开了个滚动窗口（后面会详细说明滚动窗口的作用），然后计算 url 数量。
group by user，是按照类别（横向）给数据分组，group by tumble 滚动窗口是按时间粒度（纵向）给数据进行分组。如下图所示。
time
图形化一解释就很好理解了，两种都是对数据进行分组，一个是按照 类别 分组，另一种是按照 时间 分组。
与前面一样，左边显示了输入表 clicks。查询每小时持续计算结果并更新结果表。clicks 表有三列，user，cTime，url。其中 cTime 代表数据的时间戳，用于给数据按照时间粒度分组。
tumble window
我们的滚动窗口的步长为 1 小时，即时间粒度上面的分组为 1 小时。其中时间戳在 12:00:00 - 12:59:59 之间有四条数据。13:00:00 - 13:59:59 有三条数据。14:00:00 - 14:59:59 之间有四条数据。
- ⭐ 当 12:00:00 - 12:59:59 数据输入之后，1 小时的窗口，连续查询（Continuous Query）计算的结果如右图所示，将 [Mary, 3]，[Bob, 1] 插入（insert）结果表。
- ⭐ 当 13:00:00 - 13:59:59 数据输入之后，1 小时的窗口，连续查询（Continuous Query）计算的结果如右图所示，将 [Bob, 1]，[Liz, 2] 插入（insert）结果表。
- ⭐ 当 14:00:00 - 14:59:59 数据输入之后，1 小时的窗口，连续查询（Continuous Query）计算的结果如右图所示，将 [Mary, 1]，[Bob, 2]，[Liz, 1] 插入（insert）结果表。
而这个查询只有 插入（insert）结果表 这个行为。
2.4.6.SQL 连续查询的两种类型：更新（Update）查询 & 追加（Append）查询
虽然前一节的两个查询看起来非常相似（都计算分组进行计数聚合），但它们在一个重要方面不同：
- ⭐ 第一个查询（group by user），即（Update）查询：会更新先前输出的结果，即结果表流数据中包含 INSERT 和 UPDATE 数据。小伙伴萌可以理解为 group by user 这条语句当中，输入源的数据是一直有的，源源不断的，同一个 user 的数据之后可能还是会有的，因此可以认为此 SQL 的每次的输出结果都是一个中间结果， 当同一个 user 下一条数据到来的时候，就要用新结果把上一次的产出中间结果（旧结果）给 UPDATE 了。所以这就是 UPDATE 查询的由来（其中 INSERT 就是第一条数据到来的时候，没有之前的中间结果，所以是 INSERT）。
- ⭐ 第二个查询（group by user, tumble(xxx)），即（Append）查询：只追加到结果表，即结果表流数据中只包含 INSERT 的数据。小伙伴萌可以理解为虽然 group by user, tumble(xxx) 上游也是一个源源不断的数据，但是这个查询本质上是对时间上的划分，而时间都是越变越大的，当前这个滚动窗口结束之后，后面来的数据的时间都会比这个滚动窗口的结束时间大，都归属于之后的窗口了，当前这个滚动窗口的结果数据就不会再改变了，因此这条查询只有 INSERT 数据，即一个 Append 查询。
上面是 Flink SQL 连续查询处理机制上面的两类查询方式。我们可以发现连续查询的处理机制不一样，产出到结果表中的结果数据也是不一样的。针对上面两种结果表的更新方式，Flink SQL 提出了 changelog 表的概念来进行兼容。
changelog 表这个概念其实就和 MySQL binlog 是一样的。会包含 INSERT、UPDATE、DELETE 三种数据，通过这三种数据的处理来描述实时处理技术对于动态表的变更：
- ⭐ changelog 表：即第一个查询的输出表，输出结果数据不但会追加，还会发生更新
- ⭐ changelog insert-only 表：即第二个查询的输出表，输出结果数据只会追加，不会发生更新
2.4.7.SQL 流处理的输出：动态输出表转化为输出数据
可以看到我们的标题都是随着一个 SQL 的生命周期的。从 输入流映射为 SQL 动态输入表、实时处理底层技术 - SQL 连续查询 到本小节的 SQL 动态输出表转化为输出数据。都是有逻辑关系的。
我们上面介绍到了 连续查询（Continuous Query） 的输出结果表是一个 changelog。其可以像普通数据库表一样通过 INSERT、UPDATE 和 DELETE 来不断修改。
它可能是一个只有一行、不断更新 changelog 表，也可能是一个 insert-only 的 changelog 表，没有 UPDATE 和 DELETE 修改，或者介于两者之间的其他表。
在将动态表转换为流或将其写入外部系统时，需要对这些不同状态的数据进行编码。Flink 的 Table API 和 SQL API 支持三种方式来编码一个动态表的变化:
- ⭐ Append-only 流：输出的结果只有 INSERT 操作的数据。
- ⭐ Retract 流：
- ⭐ Retract 流包含两种类型的 message：add messages 和 retract messages 。其将 INSERT 操作编码为 add message、将 DELETE 操作编码为 retract message、将 UPDATE 操作编码为更新先前行的 retract message 和更新（新）行的 add message，从而将动态表转换为 retract 流。
- ⭐ Retract 流写入到输出结果表的数据如下图所示，有 -，+ 两种，分别 - 代表撤回旧数据，+ 代表输出最新的数据。这两种数据最终都会写入到输出的数据引擎中。
- ⭐ 如果下游还有任务去消费这条流的话，要注意需要正确处理 -，+ 两种数据，防止数据计算重复或者错误。
retract
3.⭐ Upsert 流：
- ⭐ Upsert 流包含两种类型的 message：upsert messages 和 delete messages。转换为 upsert 流的动态表需要唯一键（唯一键可以由多个字段组合而成）。其会将 INSERT 和 UPDATE 操作编码为 upsert message，将 DELETE 操作编码为 delete message。
- ⭐ Upsert 流写入到输出结果表的数据如下图所示，每次输出的结果都是当前每一个 user 的最新结果数据，不会有 Retract 中的 - 回撤数据。
- ⭐ 如果下游还有一个任务去消费这条流的话，消费流的算子需要知道唯一键（即 user），以便正确地根据唯一键（user）去拿到每一个 user 当前最新的状态。其与 retract 流的主要区别在于 UPDATE 操作是用单个 message 编码的，因此效率更高。下图显示了将动态表转换为 upsert 流的过程。
upsert
2.4.8.补充知识：SQL 与关系代数
小伙伴萌会问到，关系代数是啥东西？
其实关系代数就是对于数据集（即表）的一系列的 操作（即查询语句）。常见关系代数有：
Relational Algebra
⭐ 那么 SQL 和关系代数是啥关系呢？
SQL 就是能够表示关系代数一种面向用户的接口：即用户能使用 SQL 表达关系代数的处理逻辑，也就是我们可以用 SQL 去在表（数据集）上执行我们的业务逻辑操作（关系代数操作）。
分类
标签
已于2022-9-21 10:54:54修改
赞
1
收藏 1
回复
相关推荐
