【Flink SQL】Flink SQL 语法篇(四):Group 聚合、Over 聚合

FlinkSQL语法深度解析:Group聚合与Over聚合详解
本文详细介绍了ApacheFlinkSQL中的Group聚合和Over聚合功能,包括它们的基础概念、区别、SQL语义以及在批处理和实时流处理中的应用。特别强调了窗口聚合的时间语义和Groupingsets、Rollup、Cube等高级特性。

Flink SQL 语法篇》系列,共包含以下 10 篇文章:

😊 如果您觉得这篇文章有用 ✔️ 的话,请给博主一个一键三连 🚀🚀🚀 吧 (点赞 🧡、关注 💛、收藏 💚)!!!您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容!!!

1.Group 聚合

1.1 基础概念

Group 聚合定义(支持 Batch / Streaming 任务):Flink 也支持 Group 聚合。Group 聚合和上面介绍到的窗口聚合的不同之处,就在于 Group 聚合是按照数据的类别进行分组,比如年龄、性别,是横向的;而窗口聚合是在时间粒度上对数据进行分组,是纵向的。如下图所示,就展示出了其区别。其中 按颜色分 key(横向)就是 Group 聚合按窗口划分(纵向)就是 窗口聚合

在这里插入图片描述

1.2 窗口聚合和 Group 聚合

应用场景:一般用于对数据进行分组,然后后续使用聚合函数进行 countsum 等聚合操作。

那么这时候,小伙伴萌就会问到,我其实可以把窗口聚合的写法也转换为 Group 聚合,只需要把 Group 聚合的 Group By key 换成时间就行,那这两个聚合的区别到底在哪?

首先来举一个例子看看怎么将 窗口聚合 转换为 Group 聚合。假如一个窗口聚合是按照 1 1 1 分钟的粒度进行聚合,如下 滚动窗口 SQL:

-- 数据源表
CREATE TABLE source_table (
    -- 维度数据
    dim STRING,
    -- 用户 id
    user_id BIGINT,
    -- 用户
    price BIGINT,
    -- 事件时间戳
    row_time AS cast(CURRENT_TIMESTAMP as timestamp(3)),
    -- watermark 设置
    WATERMARK FOR row_time AS row_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '10',
  'fields.dim.length' = '1',
  'fields.user_id.min' = '1',
  'fields.user_id.max' = '100000',
  'fields.price.min' = '1',
  'fields.price.max' = '100000'
)

-- 数据汇表
CREATE TABLE sink_table (
    dim STRING,
    pv BIGINT,
    sum_price BIGINT,
    max_price BIGINT,
    min_price BIGINT,
    uv BIGINT,
    window_start bigint
) WITH (
  'connector' = 'print'
)

-- 数据处理逻辑
insert into sink_table
select dim,
    count(*) as pv,
    sum(price) as sum_price,
    max(price) as max_price,
    min(price) as min_price,
    -- 计算 uv 数
    count(distinct user_id) as uv,
    UNIX_TIMESTAMP(CAST(tumble_start(row_time, interval '1' minute) AS STRING)) * 1000  as window_start
from source_table
group by
    dim,
    -- 按照 Flink SQL tumble 窗口写法划分窗口
    tumble(row_time, interval '1' minute)

转换为 Group 聚合 的写法如下:

-- 数据源表
CREATE TABLE source_table (
    -- 维度数据
    dim STRING,
    -- 用户 id
    user_id BIGINT,
    -- 用户
    price BIGINT,
    -- 事件时间戳
    row_time AS cast(CURRENT_TIMESTAMP as timestamp(3)),
    -- watermark 设置
    WATERMARK FOR row_time AS row_time - INTERVAL '5' SECOND
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '10',
  'fields.dim.length' = '1',
  'fields.user_id.min' = '1',
  'fields.user_id.max' = '100000',
  'fields.price.min' = '1',
  'fields.price.max' = '100000'
);

-- 数据汇表
CREATE TABLE sink_table (
    dim STRING,
    pv BIGINT,
    sum_price BIGINT,
    max_price BIGINT,
    min_price BIGINT,
    uv BIGINT,
    window_start bigint
) WITH (
  'connector' = 'print'
);

-- 数据处理逻辑
insert into sink_table
select dim,
    count(*) as pv,
    sum(price) as sum_price,
    max(price) as max_price,
    min(price) as min_price,
    -- 计算 uv 数
    count(distinct user_id) as uv,
    cast((UNIX_TIMESTAMP(CAST(row_time AS STRING))) / 60 as bigint) as window_start
from source_table
group by
    dim,
    -- 将秒级别时间戳 / 60 转化为 1min
    cast((UNIX_TIMESTAMP(CAST(row_time AS STRING))) / 60 as bigint)

确实没错,上面这个转换是一点问题都没有的。

但是窗口聚合和 Group by 聚合的差异在于:

  • 本质区别窗口聚合是具有时间语义的,其本质是想实现窗口结束输出结果之后,后续有迟到的数据也不会对原有的结果发生更改了,即输出结果值是定值(不考虑 allowLateness)。而 Group by 聚合是没有时间语义的,不管数据迟到多长时间,只要数据来了,就把上一次的输出的结果数据撤回,然后把计算好的新的结果数据发出。
  • 运行层面:窗口聚合是和 时间 绑定的,窗口聚合其中窗口的计算结果触发都是由 时间(Watermark)推动的。Group by 聚合完全由 数据 推动触发计算,新来一条数据去根据这条数据进行计算出结果发出;由此可见两者的实现方式也大为不同。

1.3 SQL 语义

SQL 语义这里也拿离线和实时做对比,Order 为 Kafka,target_table 为 Kafka,这个 SQL 生成的实时任务,在执行时,会生成三个算子。

  • 数据源算子From Order):数据源算子一直运行,实时的从 Order Kafka 中一条一条的读取数据,然后一条一条发送给下游的 Group 聚合算子,向下游发送数据的 shuffle 策略是根据 group by 中的 key 进行发送,相同的 key 发到同一个 SubTask(并发) 中。
  • Group 聚合算子group by key + sum / count / max / min):接收到上游算子发的一条一条的数据,去状态 state 中找这个 key 之前的 sum / count / max / min 结果。如果有结果 oldResult,拿出来和当前的数据进行 sum / count / max / min 计算出这个 key 的新结果 newResult,并将新结果 [key, newResult] 更新到 state 中,在向下游发送新计算的结果之前,先发一条撤回上次结果的消息 -[key, oldResult],然后再将新结果发往下游 +[key, newResult];如果 state 中没有当前 key 的结果,则直接使用当前这条数据计算 sum / max / min 结果 newResult,并将新结果 [key, newResult] 更新到 state 中,当前是第一次往下游发,则不需要先发回撤消息,直接发送 +[key, newResult]
  • 数据汇算子INSERT INTO target_table):接收到上游发的一条一条的数据,写入到 target_table Kafka 中这个实时任务也是 24 24 24 小时一直在运行的,所有的算子在同一时刻都是处于 running 状态的。

1.4 Group 聚合支持 Grouping sets、Rollup、Cube

Group 聚合也支持 Grouping setsRollupCube。举一个 Grouping sets 的案例:

SELECT 
    supplier_id
    , rating
    , product_id
    , COUNT(*)
FROM (VALUES
    ('supplier1', 'product1', 4),
    ('supplier1', 'product2', 3),
    ('supplier2', 'product3', 3),
    ('supplier2', 'product4', 4))
AS Products(supplier_id, product_id, rating)
GROUP BY GROUPING SET (
    ( supplier_id, product_id, rating ),
    ( supplier_id, product_id         ),
    ( supplier_id,             rating ),
    ( supplier_id                     ),
    (              product_id, rating ),
    (              product_id         ),
    (                          rating ),
    (                                 )
)

2.Over 聚合

Over 聚合定义(支持 Batch / Streaming):可以理解为是一种特殊的滑动窗口聚合函数。

那这里我们拿 Over 聚合窗口聚合 做一个对比,其之间的最大不同之处在于:

  • 窗口聚合:不在 group by 中的字段,不能直接在 select 中拿到。
  • Over 聚合:能够保留原始字段。

注意:其实在生产环境中,Over 聚合的使用场景还是比较少的。在 Hive 中也有相同的聚合,但是小伙伴萌可以想想你在离线数仓经常使用嘛?

  • 应用场景:计算最近一段滑动窗口的聚合结果数据。
  • 实际案例:查询每个产品最近一小时订单的金额总和。
SELECT order_id, order_time, amount,
  SUM(amount) OVER (
    PARTITION BY product
    ORDER BY order_time
    RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW
  ) AS one_hour_prod_amount_sum
FROM Orders
  • Over 聚合的语法总结如下:
SELECT
  agg_func(agg_col) OVER (
    [PARTITION BY col1[, col2, ...]]
    ORDER BY time_col
    range_definition),
  ...
FROM ...
  • ORDER BY:必须是时间戳列(事件时间、处理时间)。
  • PARTITION BY:标识了聚合窗口的聚合粒度,如上述案例是按照 product 进行聚合。
  • range_definition:这个标识聚合窗口的聚合数据范围,在 Flink 中有两种指定数据范围的方式。第一种为 按照行数聚合,第二种为 按照时间区间聚合。如下案例所示。

2.1 时间区间聚合

按照时间区间聚合就是时间区间的一个滑动窗口,比如下面案例 1 1 1 小时的区间,最新输出的一条数据的 sum 聚合结果就是最近一小时数据的 amount 之和。

CREATE TABLE source_table (
    order_id BIGINT,
    product BIGINT,
    amount BIGINT,
    order_time as cast(CURRENT_TIMESTAMP as TIMESTAMP(3)),
    WATERMARK FOR order_time AS order_time - INTERVAL '0.001' SECOND
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '1',
  'fields.order_id.min' = '1',
  'fields.order_id.max' = '2',
  'fields.amount.min' = '1',
  'fields.amount.max' = '10',
  'fields.product.min' = '1',
  'fields.product.max' = '2'
);

CREATE TABLE sink_table (
    product BIGINT,
    order_time TIMESTAMP(3),
    amount BIGINT,
    one_hour_prod_amount_sum BIGINT
) WITH (
  'connector' = 'print'
);

INSERT INTO sink_table
SELECT product, order_time, amount,
  SUM(amount) OVER (
    PARTITION BY product
    ORDER BY order_time
    -- 标识统计范围是一个 product 的最近 1 小时的数据
    RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW
  ) AS one_hour_prod_amount_sum
FROM source_table

2.2 行数聚合

按照行数聚合就是数据行数的一个滑动窗口,比如下面案例,最新输出的一条数据的 sum 聚合结果就是最近 5 5 5 行数据的 amount 之和。

CREATE TABLE source_table (
    order_id BIGINT,
    product BIGINT,
    amount BIGINT,
    order_time as cast(CURRENT_TIMESTAMP as TIMESTAMP(3)),
    WATERMARK FOR order_time AS order_time - INTERVAL '0.001' SECOND
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '1',
  'fields.order_id.min' = '1',
  'fields.order_id.max' = '2',
  'fields.amount.min' = '1',
  'fields.amount.max' = '2',
  'fields.product.min' = '1',
  'fields.product.max' = '2'
);

CREATE TABLE sink_table (
    product BIGINT,
    order_time TIMESTAMP(3),
    amount BIGINT,
    one_hour_prod_amount_sum BIGINT
) WITH (
  'connector' = 'print'
);

INSERT INTO sink_table
SELECT product, order_time, amount,
  SUM(amount) OVER (
    PARTITION BY product
    ORDER BY order_time
    -- 标识统计范围是一个 product 的最近 5 行数据
    ROWS BETWEEN 5 PRECEDING AND CURRENT ROW
  ) AS one_hour_prod_amount_sum
FROM source_table

预跑结果如下:

+I[2, 2021-12-24T22:18:19.147, 1, 9]
+I[1, 2021-12-24T22:18:20.147, 2, 11]
+I[1, 2021-12-24T22:18:21.147, 2, 12]
+I[1, 2021-12-24T22:18:22.147, 2, 12]
+I[1, 2021-12-24T22:18:23.148, 2, 12]
+I[1, 2021-12-24T22:18:24.147, 1, 11]
+I[1, 2021-12-24T22:18:25.146, 1, 10]
+I[1, 2021-12-24T22:18:26.147, 1, 9]
+I[2, 2021-12-24T22:18:27.145, 2, 11]
+I[2, 2021-12-24T22:18:28.148, 1, 10]
+I[2, 2021-12-24T22:18:29.145, 2, 10]

当然,如果你在一个 SELECT 中有多个聚合窗口的聚合方式,Flink SQL 支持了一种简化写法,如下案例:

SELECT order_id, order_time, amount,
  SUM(amount) OVER w AS sum_amount,
  AVG(amount) OVER w AS avg_amount
FROM Orders
-- 使用下面子句,定义 Over Window
WINDOW w AS (
  PARTITION BY product
  ORDER BY order_time
  RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW)
<think>好的,我现在需要回答用户关于Flink SQL和标准SQL语法差异的问题。首先,用户之前已经问过Flink SQL与传统SQL的区别,现在更具体地询问语法上的不同。我需要确保这次回答集中在语法层面,而不是重复之前的整体对比。 首先,我需要回忆一下之前提供的回答,其中提到了数据模型、时间语义、执行模式等方面,但用户现在更关注语法差异。因此,我需要调整重点,专注于具体的语法元素,比如DDL、DML、函数、窗口操作等。 用户提供的引用[1]是关于Flink SQL语法系列文章,其中提到WITH、SELECT、WHERE、窗口聚合等内容。这些内容可以作为参考,但需要结合标准SQL的语法进行对比。例如,Flink SQL窗口函数如TUMBLE、HOP等,在标准SQL中并不存在,这是重要的差异点。 接下来,我需要组织回答的结构。可能分为以下几个部分:数据定义语言(DDL)、数据操作语言(DML)、时间处理和窗口函数、函数扩展、连接操作、动态表与持续查询、执行控制语句等。每个部分对比Flink SQL和标准SQL的具体语法差异,并给出示例。 例如,在DDL方面,Flink SQL需要定义水印和时间属性,这在标准SQL中是没有的。在DML中,Flink SQL的SELECT语句可能涉及窗口聚合和状态管理。时间处理部分需要详细说明事件时间和处理时间的语法,以及水印的定义方法。 另外,用户提到要生成相关问题,我需要确保在最后列出相关问题,帮助用户深入理解。同时,引用文献需要正确标注,比如引用[^1]来自用户提供的资料。 需要确保回答符合之前的格式要求:使用中文,行内公式用$...$,独立公式用$$...$$,代码块正确标注,结构清晰。同时,检查是否有遗漏的重要语法差异,比如Top N的实现、Deduplication语法、临时表等。 最后,验证示例代码的正确性,比如创建表时定义水印,使用TUMBLE窗口,以及MATCH_RECOGNIZE的示例是否符合Flink SQL的语法规范。同时,确保引用的部分正确标注来源,如引用[^1]和[^2]对应的内容是否存在,避免虚构引用。 总结思考步骤:确定用户需求集中在语法差异,参考之前的回答和用户提供的引用,组织结构,分点对比,加入示例代码,验证正确性,生成相关问题,确保格式和引用正确。</think>### Flink SQL 与标准 SQL 语法差异对比 Flink SQL 在兼容标准 SQL 的基础上,扩展了流处理特有的语法(如时间语义、窗口操作、动态表等),同时优化了部分语法结构以适应分布式计算场景。以下是核心语法差异的详细对比: --- #### **一、数据定义语言(DDL)差异** | **语法特性** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **表定义中的时间属性** | 无内置时间字段定义 | 必须显式定义事件时间(`TIMESTAMP(3)`)及水印(`WATERMARK`)[^1] | | **连接器声明** | 依赖数据库引擎(如 `CREATE TABLE` 不带存储类型) | 需指定连接器类型(如 `connector='kafka'`)[^1] | | **临时表生命周期** | 表持久化存储 | 任务级临时表(任务停止后自动销毁) | **示例:定义含水印的动态表** ```sql CREATE TABLE orders ( order_id STRING, amount DECIMAL, event_time TIMESTAMP(3), -- 定义水印(允许5秒延迟) WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND ) WITH ( 'connector' = 'kafka', 'topic' = 'orders_topic' ); ``` --- #### **二、数据操作语言(DML)差异** | **语法特性** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **窗口聚合语法** | 无原生支持(需手动分组) | 必须使用窗口函数(如 `TUMBLE`/`HOP`/`SESSION`) | | **持续查询** | 仅执行一次性查询 | 支持 `INSERT INTO` 持续输出结果到动态表 | | **状态保留设置** | 无状态管理语法 | 可通过 `WITH` 参数控制状态生命周期(如 `'state.ttl'='7d'`) | **示例:滚动窗口聚合** ```sql SELECT user_id, TUMBLE_START(event_time, INTERVAL '1' HOUR) AS window_start, COUNT(*) AS click_count FROM clicks GROUP BY user_id, TUMBLE(event_time, INTERVAL '1' HOUR); ``` --- #### **三、时间语义与窗口函数** | **语法元素** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **时间字段类型** | 普通时间戳字段(如 `TIMESTAMP`) | 需区分事件时间(`TIMESTAMP(3)`)和处理时间(`PROCTIME()`)[^1] | | **窗口定义方式** | 无 | 显式调用窗口函数(如 `TUMBLE`/`HOP`)或通过 `OVER` 子句定义 | | **延迟数据处理** | 无 | 通过 `WATERMARK` 和 `ALLOW_LATENESS` 处理乱序事件 | **示例:处理迟到数据** ```sql SELECT window_start, SUM(amount) FROM TABLE( TUMBLE( TABLE orders, DESCRIPTOR(event_time), INTERVAL '10' MINUTE, ALLOW_LATENESS(INTERVAL '2' MINUTE) -- 允许迟到2分钟 ) ) GROUP BY window_start; ``` --- #### **、函数与操作符扩展** | **功能** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **时间函数** | 基础函数(如 `NOW()`) | 流式时间函数(如 `CURRENT_WATERMARK`) | | **复杂事件处理** | 无 | `MATCH_RECOGNIZE` 语法(类正则模式匹配)[^1] | | **Top-N 查询** | 使用 `LIMIT` 或 `ROW_NUMBER()` | 专用 `TOP N` 语法(优化状态存储效率) | **示例:模式匹配检测连续失败登录** ```sql SELECT * FROM login_events MATCH_RECOGNIZE ( PARTITION BY user_id ORDER BY event_time MEASURES START_ROW.event_time AS start_time, LAST(FAIL.event_time) AS end_time PATTERN (START FAIL{3}) -- 连续3次失败 DEFINE FAIL AS FAIL.status = 'failure' ); ``` --- #### **五、连接(Join)操作差异** | **特性** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **流表连接类型** | 仅支持静态表 `INNER JOIN`/`LEFT JOIN` | 支持流式连接(如 `Interval Join`/`Temporal Join`)[^1] | | **时间区间连接** | 无 | `Interval Join`(基于时间范围关联事件) | | **维表关联** | 通过 `JOIN` 静态表 | `LOOKUP JOIN`(动态查询外部存储) | **示例:Interval Join 关联订单与物流信息** ```sql SELECT o.order_id, l.logistics_time FROM orders o JOIN logistics l ON o.order_id = l.order_id AND l.logistics_time BETWEEN o.event_time AND o.event_time + INTERVAL '2' HOUR; ``` --- #### **六、动态表与持续查询** | **语法特性** | **标准 SQL** | **Flink SQL** | |----------------------|-------------------------------------------|--------------------------------------------| | **查询结果输出** | 一次性返回结果集 | 持续更新结果(如物化视图) | | **更新操作** | 显式 `UPDATE`/`DELETE` | 通过 `CHANGELOG` 模式隐式处理(如 `RETRACT` 流) | | **结果表类型** | 仅支持静态结果表 | 支持 `APPEND`/`RETRACT`/`UPSERT` 流 | --- ### 总结 Flink SQL 语法在以下方向显著区别于标准 SQL: 1. **时间驱动**:强制定义时间语义与水印机制,支持事件时间处理。 2. **流式扩展**:窗口函数、`MATCH_RECOGNIZE`、流式 `JOIN` 等语法专为无界数据流设计。 3. **状态管理**:通过 `WITH` 参数控制状态生命周期,避免资源泄漏。 4. **执行模式**:支持持续查询与动态结果表,适应实时计算场景。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大数据与AI实验室

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值