感谢您的关注 点赞 再看,对博主的肯定,会督促博主持续的输出更多的优质实战内容!!!
1.序篇-本文结构
本文从以下五个小节介绍 flink sql sourcesinkformat 的概念、原理。
- 背景篇-关于 sql
- 定义篇-sql source、sink
- 实战篇-sql source、sink 的用法
- 原理剖析篇-sql source、sink 是怎么跑起来的
- 总结与展望篇
2.背景篇-关于 sql
关于 flink sql 的定位。
先聊聊使用 sql 的原因,总结来说就是一切从简。
- SQL 属于 DSL
- SQL 易于理解
- SQL 内置多种查询优化器
- SQL 稳定的语言
- SQL 易于管理
- SQL 利于流批一体
目前 1.13 版本的 SQL 已经集成了大量高效、易用的 feature。本系列教程也是基于 1.13.1。
3.定义篇-sql source、sink
本文会简单介绍一些 flink sql 的 source、sink 的定义、使用方法,会着重切介绍其对应框架设计和实现。详细解析一下从一条 create table sql 到具体的算子层面的整个流程。
Notes:在 flink sql 中,source 有两种表,一种是数据源表,一种是数据维表。数据源表就是有源源不断的数据的表。比如 mq。数据维表就是用来给某些数据扩充维度使用的。比如 redis,mysql,一般都是做扩容维度的维表 join 使用。 本节主要介绍数据源表,数据维表的整个流程和数据源表几乎一样。下文中的 source 默认都为数据源表。
首先在介绍 sql 之前,我们先来看看 datastream 中定义一个 source 需要的最基本的内容。
- source、sink 的 connector 连接配置信息。比如 datastream api kafka connector 的 properties,topic 名称。
- source、sink 的序列化方式信息。比如 datastream api kafka connector 的 DeserializationSchema,SerializationSchema。
- source、sink 的字段信息。比如 datastream api kafka connector 的序列化或者反序列化出来的 Model 所包含的字段信息。
- source、sink 对象。比如 datastream api kafka connector source 对应的具体 java 对象。
sql 中的 source、sink 所包含的基本点其实和 datastream 都是相同的,可以将 sql 中的一些语法给映射到 datastream 中来帮助快速理解 sql:
- sql source、sink connectorproperties。可以对应到 datastream api kafka connector 的 properties,topic 名称。
- sql source、sink format。可以对应到 datastream api kafka connector 的 DeserializationSchema,SerializationSchema。
- sql source、sink field。可以对应到 datastream api kafka connector 的序列化或者反序列化出来的 Model 所包含的字段信息。
- sql source、sink catalog_name、db_name、table_name。可以对应到 datastream api kafka connector source 对应的具体 java 对象。
- sql 本身的特性。比如某些场景下需要将 sql schema 持久化,会用到 hive catalog 等,这个可以说是 sql 目前比 datastream api 多的一个特性。但是仔细想想,其实 datastream 也能够拓展这样的能力,其实就是将某个 datastream 注册到外部存储中(可以,但对 datastream 来说没必要)。
来看看官网的文档 create table schema 的描述,可以发现就是围绕着上面这五点展开的。https://ci.apache.org/projects/flink/flink-docs-release-1.13/zh/docs/dev/table/sql/create/#create-table。
代码语言:javascript复制CREATE TABLE [IF NOT EXISTS] [catalog_name.][db_name.]table_name
(
{ <physical_column_definition> | <metadata_column_definition> | <computed_column_definition> }[ , ...n]
[ <watermark_definition> ]
[ <table_constraint> ][ , ...n]
)
[COMMENT table_comment]
[PARTITIONED BY (partition_column_name1, partition_column_name2, ...)]
WITH (key1=val1, key2=val2, ...)
[ LIKE source_table [( <like_options> )] ]
<physical_column_definition>:
column_name column_type [ <column_constraint> ] [COMMENT column_comment]
<column_constraint>:
[CONSTRAINT constraint_name] PRIMARY KEY NOT ENFORCED
<table_constraint>:
[CONSTRAINT constraint_name] PRIMARY KEY (column_name, ...) NOT ENFORCED
<metadata_column_definition>:
column_name column_type METADATA [ FROM metadata_key ] [ VIRTUAL ]
<computed_column_definition>:
column_name AS computed_column_expression [COMMENT column_comment]
<watermark_definition>:
WATERMARK FOR rowtime_column_name AS watermark_strategy_expression
<source_table>:
[catalog_name.][db_name.]table_name
<like_options>:
{
{ INCLUDING | EXCLUDING } { ALL | CONSTRAINTS | PARTITIONS }
| { INCLUDING | EXCLUDING | OVERWRITING } { GENERATED | OPTIONS | WATERMARKS }
}[, ...]
结合我们刚刚说的 sql source、sink 中主要包含 5 点解释一下:
代码语言:javascript复制CREATE TABLE [IF NOT EXISTS] -- sql source、sink catalog_name、db_name、table_name
(
-- sql source、sink field 字段信息
) WITH
(
-- sql source、sink connectorproperties 连接配置
-- sql source、sink format
)
来个 kafka source 的例子:
代码语言:javascript复制CREATE TABLE KafkaTable ( -- sql source、sink catalog_name、db_name、table_name
`f0` STRING, -- sql source、sink 的字段信息
`f1` STRING
) WITH (
'connector' = 'kafka', -- sql source、sink 的 connector 连接配置
'topic' = 'topic', -- sql source、sink 的 connector 连接配置
'properties.bootstrap.servers' = 'localhost:9092', -- sql source、sink 的 connector 连接配置
'properties.group.id' = 'testGroup', -- sql source、sink 的 connector 连接配置
'format' = 'json' -- sql source、sink 的序列化方式信息
)
其对应的 datastream 写法如下:
代码语言:javascript复制Properties properties = new Properties();
properties.setProperty("bootstrap.servers", "localhost:9092");
properties.setProperty("group.id", "testGroup");
DeserializationSchema<Tuple2<String, String>> d = new AbstractDeserializationSchema<Tuple2<String, String>>() {
@Override
public Tuple2<String, String> deserialize(byte[] message) throws IOException {
return json 解析为 tuple2 此处省略;
}
};
DataStream<Tuple2<String, String>> stream = env
.addSource(new FlinkKafkaConsumer<>("topic", d, properties));
将 sql source 和 datastream source 的组成部分互相映射起来可以得到下图,其中 datastream、sql 中颜色相同的属性互相对应:
2
可以看到,将所有的 sql 关系代数都映射到 datastream api 上,会有助于我们快速理解。
4.实战篇-sql source、sink 的用法
直接见官网 Table API Connectors。已经描述的非常详细了,本文侧重原理,所以此处不多赘述。
https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/connectors/table/overview/
https://www.alibabacloud.com/help/zh/faq-list/62516.htm?spm=a2c63.p38356.b99.212.3c1a1442x9AY7m
5.原理剖析篇-sql source、sink 是怎么跑起来的
关于 sql 具体工作原理可以参考 https://zhuanlan.zhihu.com/p/157265381。
3
但是很多刚接触 flink sql 的读者看完这篇文章,会感觉到还没准备好就来了这么大一堆密集的信息。那么
- 我到底应该从哪里看起呢?
- 能理解 sql 会映射到具体的算子执行。但是它具体是怎么对应到具体的算子上的呢?
博主会从以下两个角度去帮大家理清楚整个流程。
- 先抛开 flink sql、datastream 提供的能力来说,如果你在自己的一个程序中去接入一个数据源,你最关心的是哪些组件?
答:消费一个数据源最重要的就是 connector(负责链接外部组件,消费数据) serde(负责序列化成 flink 认识的变量形式)。
- 结合第一个问题 一段简单的 flink sql 代码来看看 flink 是怎么去做这件事情的。
代码(基于 1.13.1):
代码语言:javascript复制public class KafkaSourceTest {
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env = StreamExecutionEnvironment.createLocalEnvironmentWithWebUI(new Configuration());
env.setParallelism(1);
EnvironmentSettings settings = EnvironmentSettings
.newInstance()
.useBlinkPlanner()
.inStreamingMode().build();
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env, settings);
tEnv.executeSql(
"CREATE TABLE KafkaSourceTable (n"
" `f0` STRING,n"
" `f1` STRINGn"
") 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");
tEnv.toAppendStream(t, Row.class).print();
env.execute();
}
}
可以看到这段代码很简单,就是创建一个数据源表之后 select 数据 print。
通过上面这段 sql 映射出的 transformations 中发现,其实 flink 中最关键变量的也就是我们刚刚提出的第一个问题中的那两点:
- sql source connector 是
FlinkKafkaConsumer
- sql source format 是
JsonRowDataDeserializationSchema
19
所以我们就可以从下面这三个方向(多出来的一个是配置信息)的问题去了解具体是怎么对应到具体的算子上的。
- sql source connector:用户指定了
connector = kafka
,flink 是怎么自动映射到FlinkKafkaConsumer
的? - sql source format:用户指定了
format = json
,字段信息,flink 是怎么自动映射到JsonRowDataDeserializationSchema
,以及字段解析的? - sql source properties:flink 是怎么自动将配置加载到
FlinkKafkaConsumer
中的?
5.1.connector 怎样映射到具体算子?
引用官网图:
22
Notes:其中
LookupTableSource
为数据维表。
先说下结论,再跟一遍源码。
结论:
- MetaData:将 sql create source table 转化为实际的
CatalogTable
、翻译为 RelNode - Planning:创建 RelNode 的过程中使用 SPI 将所有的 source(
DynamicTableSourceFactory
)sink(DynamicTableSinkFactory
) 工厂动态加载,获取到 connector = kafka,然后从所有 source 工厂中过滤出名称为 kafka 继承自DynamicTableSourceFactory.class
的工厂类KafkaDynamicTableFactory
,使用KafkaDynamicTableFactory
创建出KafkaDynamicSource
- Runtime:
KafkaDynamicSource
创建出FlinkKafkaConsumer
,负责 flink 程序实际运行。
源码:
debug 代码,既然创建的是 FlinkKafkaConsumer
,那我们就将断点打在 FlinkKafkaConsumer
的构造函数中。
5
如图可以发现当 debug 到当前断点时,已经进入 FlinkKafkaConsumer
source 的创建阶段了,执行到这里的时候已经是完成了 sql connector 和具体实际 connector 的映射了。那么 connector 怎样映射到具体算子的过程呢?
我们往前回溯一下,定位到 CatalogSourceTable
中的 82 行(源码基于 1.13.1),发现 tableSource 已经是 KafkaDynamicSource
,因此可以确定就是这一行代码将 connector = kafka 映射到 FlinkKafkaConsumer
的。
6
可以发现这段代码将包含了所有 sql create source table 中信息的 catalogTable 变量传入了。
7
进入这个方法后,可以看到是使用了 FactoryUtil
创建了 DynamicTableSource
。
8
进入 FactoryUtil.createTableSource
后可以看到,就是最重要的两步操作。
- 先获取 kafka 工厂对象。
- 使用 kafka 工厂对象创建出 kafka source。
9
进入 FactoryUtil.getDynamicTableFactory
后:
- flink 是使用了 SPI 机制动态(SPI 机制天然插件化)的加载到了所有继承了
Factory
的工厂实例。通过截图可以看到有好多 sourcesinkformat Factory。关于 SPI 可以参考 https://www.jianshu.com/p/3a3edbcd8f24 - 通过 connector = kafka
DynamicTableSourceFactory.class
的标识去过滤出KafkaDynamicTableFactory
。
然后 KafkaDynamicTableFactory.createDynamicTableSource
去创建对应的 source。
13
可以看到 KafkaDynamicTableFactory.createDynamicTableSource
中调用 KafkaDynamicTableFactory.createKafkaTableSource
来创建 KafkaDynamicSource
。
基本上整个创建 Source 的流程就结束了。
5.2.format 怎样映射到具体 serde?
结论:
- MetaData:和 connector 都一样
- Planning:format 是在创建 RelNode 的过程中,使用
KafkaDynamicTableFactory
创建出KafkaDynamicSource
时,通过 SPI 去动态过滤出 format = json 并且继承自DeserializationFormatFactory.class
的 format 工厂类JsonFormatFactory
。 - Runtime:
KafkaDynamicSource
创建出FlinkKafkaConsumer
时,实例化 serde 即JsonRowDataDeserializationSchema
,负责 flink 程序实际运行时的反序列化。
源码:
15
KafkaDynamicTableFactory.createDynamicTableSource
中获取反序列化 schema 定义。
18
- flink 是使用了 SPI 机制动态(SPI 机制天然插件化)的加载到了所有继承了
Factory
的 format 工厂实例。 - 通过 format = json 的标识并且继承自
DeserializationFormatFactory.class
去过滤出JsonFormatFactory
。
20
5.3.其他配置属性怎么加载?
结论:
在 KafkaDynamicTableFactory
创建 KafkaDynamicTable
的过程中初始化。
源码:
14
21
6.总结与展望篇
本文作为 flink sql 知其然系列的第一节,基于 1.13.1 版本 flink 介绍了 flink sql 的 sourcesinkformat 从 sql 变为可执行代码的原理。带大家过了一下源码。希望可以喜欢。
下节预告:flink sql 自定义 sourcesink。