DML:Order By、Limit 子句
大家好,我是老羊,今天我们来学习 Flink SQL 中的 TopN、Order By、Limit 3个操作。
1.Order By 子句
支持 BatchStreaming,但在实时任务中一般用的非常少。
实时任务中,Order By 子句中必须要有时间属性字段,并且时间属性必须为升序时间属性,即 WATERMARK FOR rowtime_column AS rowtime_column - INTERVAL '0.001' SECOND
或者 WATERMARK FOR rowtime_column AS rowtime_column
。
举例:
代码语言:javascript复制CREATE TABLE source_table_1 (
user_id BIGINT NOT NULL,
row_time AS cast(CURRENT_TIMESTAMP as timestamp()),
WATERMARK FOR row_time AS row_time
) WITH (
'connector' = 'datagen',
'rows-per-second' = '10',
'fields.user_id.min' = '1',
'fields.user_id.max' = '10'
);
CREATE TABLE sink_table (
user_id BIGINT
) WITH (
'connector' = 'print'
);
INSERT INTO sink_table
SELECT user_id
FROM source_table_1
Order By row_time, user_id desc
2.Limit 子句
支持 BatchStreaming,但实时场景一般不使用,但是此处依然举一个例子:
代码语言:javascript复制CREATE TABLE source_table_1 (
user_id BIGINT NOT NULL,
row_time AS cast(CURRENT_TIMESTAMP as timestamp()),
WATERMARK FOR row_time AS row_time
) WITH (
'connector' = 'datagen',
'rows-per-second' = '10',
'fields.user_id.min' = '1',
'fields.user_id.max' = '10'
);
CREATE TABLE sink_table (
user_id BIGINT
) WITH (
'connector' = 'print'
);
INSERT INTO sink_table
SELECT user_id
FROM source_table_1
Limit
结果如下,只有 3 条输出:
代码语言:javascript复制 I[5]
I[9]
I[4]
DML:TopN 子句
- ⭐ TopN 定义(支持 BatchStreaming):TopN 其实就是对应到离线数仓中的 row_number(),可以使用 row_number() 对某一个分组的数据进行排序
- ⭐ 应用场景:根据
某个排序
条件,计算某个分组
下的排行榜数据 - ⭐ SQL 语法标准:
SELECT [column_list]
FROM (
SELECT [column_list],
ROW_NUMBER() OVER ([PARTITION BY col1[, col2...]]
ORDER BY col1 [asc|desc][, col2 [asc|desc]...]) AS rownum
FROM table_name)
WHERE rownum <= N [AND conditions]
- ⭐
ROW_NUMBER()
:标识 TopN 排序子句 - ⭐
PARTITION BY col1[, col2...]
:标识分区字段,代表按照这个 col 字段作为分区粒度对数据进行排序取 topN,比如下述案例中的partition by key
,就是根据需求中的搜索关键词(key)做为分区 - ⭐
ORDER BY col1 [asc|desc][, col2 [asc|desc]...]
:标识 TopN 的排序规则,是按照哪些字段、顺序或逆序进行排序 - ⭐
WHERE rownum <= N
:这个子句是一定需要的,只有加上了这个子句,Flink 才能将其识别为一个 TopN 的查询,其中 N 代表 TopN 的条目数 - ⭐
[AND conditions]
:其他的限制条件也可以加上
- ⭐ 实际案例:取某个搜索关键词下的搜索热度前 10 名的词条数据。
输入数据为搜索词条数据的搜索热度数据,当搜索热度发生变化时,会将变化后的数据写入到数据源的 Kafka 中:
数据源 schema:
代码语言:javascript复制-- 字段名 备注
-- key 搜索关键词
-- name 搜索热度名称
-- search_cnt 热搜消费热度(比如 3000)
-- timestamp 消费词条时间戳
CREATE TABLE source_table (
name BIGINT NOT NULL,
search_cnt BIGINT NOT NULL,
key BIGINT NOT NULL,
row_time AS cast(CURRENT_TIMESTAMP as timestamp()),
WATERMARK FOR row_time AS row_time
) WITH (
...
);
-- 数据汇 schema:
-- key 搜索关键词
-- name 搜索热度名称
-- search_cnt 热搜消费热度(比如 3000)
-- timestamp 消费词条时间戳
CREATE TABLE sink_table (
key BIGINT,
name BIGINT,
search_cnt BIGINT,
`timestamp` TIMESTAMP()
) WITH (
...
);
-- DML 逻辑
INSERT INTO sink_table
SELECT key, name, search_cnt, row_time as `timestamp`
FROM (
SELECT key, name, search_cnt, row_time,
-- 根据热搜关键词 key 作为 partition key,然后按照 search_cnt 倒排取前 100 名
ROW_NUMBER() OVER (PARTITION BY key
ORDER BY search_cnt desc) AS rownum
FROM source_table)
WHERE rownum <=
输出结果:
代码语言:javascript复制-D[关键词1, 词条1, 4944]
I[关键词1, 词条1, 8670]
I[关键词1, 词条2, 1735]
-D[关键词1, 词条3, 6641]
I[关键词1, 词条3, 6928]
-D[关键词1, 词条4, 6312]
I[关键词1, 词条4, 7287]
可以看到输出数据是有回撤数据的,为什么会出现回撤,我们来看看 SQL 语义。
- ⭐ SQL 语义
上面的 SQL 会翻译成以下三个算子:
- ⭐
数据源
:数据源即最新的词条下面的搜索词的搜索热度数据,消费到 Kafka 中数据后,按照 partition key 将数据进行 hash 分发到下游排序算子,相同的 key 数据将会发送到一个并发中 - ⭐
排序算子
:为每个 Key 维护了一个 TopN 的榜单数据,接受到上游的一条数据后,如果 TopN 榜单还没有到达 N 条,则将这条数据加入 TopN 榜单后,直接下发数据,如果到达 N 条之后,经过 TopN 计算,发现这条数据比原有的数据排序靠前,那么新的 TopN 排名就会有变化,就变化了的这部分数据之前下发的排名数据撤回(即回撤数据),然后下发新的排名数据 - ⭐
数据汇
:接收到上游的数据之后,然后输出到外部存储引擎中
上面三个算子也是会 24 小时一直运行的。
往期推荐
(上)史上最全干货!Flink SQL 成神之路(全文 18 万字、138 个案例、42 张图)
(中)史上最全干货!Flink SQL 成神之路(全文 18 万字、138 个案例、42 张图)
(下)史上最全干货!Flink SQL 成神之路(全文 18 万字、138 个案例、42 张图)
flink sql 知其所以然(十九):Table 与 DataStream 的转转转(附源码)
flink sql 知其所以然(十八):在 flink 中还能使用 hive udf?附源码
flink sql 知其所以然(十七):flink sql 开发利器之 Zeppelin
flink sql 知其所以然(十六):flink sql 开发企业级利器之 Dlink
flink sql 知其所以然(十五):改了改源码,实现了个 batch lookup join(附源码)
flink sql 知其所以然(十四):维表 join 的性能优化之路(上)附源码
flink sql 知其所以然(十三):流 join 很难嘛???(下)
flink sql 知其所以然(十二):流 join 很难嘛???(上)
flink sql 知其所以然(十一):去重不仅仅有 count distinct 还有强大的 deduplication
flink sql 知其所以然(十):大家都用 cumulate window 计算累计指标啦
flink sql 知其所以然(九):window tvf tumble window 的奇思妙解
flink sql 知其所以然(八):flink sql tumble window 的奇妙解析之路
flink sql 知其所以然(七):不会连最适合 flink sql 的 ETL 和 group agg 场景都没见过吧?
flink sql 知其所以然(六)| flink sql 约会 calcite(看这篇就够了)
flink sql 知其所以然(五)| 自定义 protobuf format
flink sql 知其所以然(四)| sql api 类型系统
flink sql 知其所以然(三)| 自定义 redis 数据汇表(附源码)
flink sql 知其所以然(二)| 自定义 redis 数据维表(附源码)
flink sql 知其所以然(一)| sourcesink 原理
揭秘字节跳动埋点数据实时动态处理引擎(附源码)