按账户分组,间隔超 1 小时则重置序列号--极简法

简介: 本例演示如何用SQLazy实现“按账户分组、超1小时重置序列号”的会话划分:先按account_number和dt排序;再用segment condition判断前一行+3600秒是否≤当前时间,生成组号grp;最后在(account_number, grp)内用seq生成连续序号。逻辑清晰,免写复杂SQL。

问题描述:按账户分组,序列号在每次活动间隔超过 1 小时后重置
一张表包含 account_number 和 dt 两个字段。每个账户的记录按时间排序,需要生成一个序列号 Seq。规则如下:

按账户分组,按日期时间升序处理

如果当前行的活动时间与上一行的时间间隔超过 1 小时,则序列号重置为 1

否则(间隔 ≤ 1 小时),序列号递增 1

源数据:

account_number dt

19 2024-04-03 07:02:02

19 2024-04-03 07:02:41

19 2024-04-03 14:58:49

19 2024-04-03 19:58:49

19 2024-04-05 14:58:49

19 2024-04-05 14:59:31

19 2024-04-17 23:56:13

20 2024-04-17 23:59:13

19 2024-04-18 00:15:13

19 2024-04-18 14:56:13

20 2024-04-18 07:41:55

20 2024-04-18 19:41:55

20 2024-04-18 19:56:55

19 2024-04-19 07:41:55

19 2024-04-19 07:42:20

19 2024-04-19 08:41:20

期望结果:

19 2024-04-03 07:02:02 1

19 2024-04-03 07:02:41 2

19 2024-04-03 14:58:49 1

19 2024-04-03 19:58:49 1

19 2024-04-05 14:58:49 1

19 2024-04-05 14:59:31 2

19 2024-04-17 23:56:13 1

19 2024-04-18 00:15:13 2

19 2024-04-18 14:56:13 1

19 2024-04-19 07:41:55 1

19 2024-04-19 07:42:20 2

19 2024-04-19 08:41:20 3

20 2024-04-17 23:59:13 1

20 2024-04-18 07:41:55 1

20 2024-04-18 19:41:55 1

20 2024-04-18 19:56:55 2

SQLazy 分步实现
image.png
下面分别解释这些步骤。

第 1 步:按账户和日期时间升序排序

sort account_number asc, dt asc

将原始数据按 account_number 和 dt 升序排列。这一步确保每个账户内的记录按时间先后顺序处理。
1ef6fdc6624d3d7aeea8395363e43621_1781575384545100.png
第 2 步:分段 - 判断是否超过 1 小时,生成组号

segment condition ((dt[-1] elapse 3600 second)<= dt) partition account_number as grp

在每个账户分区内,依次检查当前行的 dt 与上一行的 dt 是否间隔超过 1 小时(3600 秒)。条件 (dt[-1] elapse 3600 second) <= dt 的含义是:“上一行的时间加上 3600 秒后,是否小于等于当前行的时间”。如果成立,说明间隔 ≥ 1 小时,则新开一个组;否则与上一行同组。最终为每个记录生成一个组号 grp。
6c555f6fa94761cbd9aafdeede121b8c_1781575384706100.png
第 3 步:在每个 (account_number, grp) 内生成组内序号

compute # as seq partition account_number, grp

表示按分区内的当前顺序自动生成的序号(从 1 开始)。这里按账户和组号分区,在每个分区内按原顺序(已排序)生成序号 seq。这正是我们需要的序列号。

执行后,最终输出如下:
4d61e10f0bb1e5173e609d1297082220_1781575384807100.png
最后删除辅助列 grp(或直接输出所需列)即可得到期望结果。

编译生成 SQL

完成上述步骤后,通过 SQLazy 的编译器可以生成等价的原生 SQL,无需手动编写。
de56fd5dab3f5b9495ff9f7192184fca_1781575384027100.png
以下是生成的目标数据库语句(以 MySQL 为例):

WITH t2 AS (
  SELECT
    account_number,
    dt
  FROM
    numEvents
),
t3 AS (
  SELECT
    account_number,
    dt,
    SUM(
      CASE
        WHEN (col__5 + INTERVAL 3600 SECOND <= dt) THEN 1
        ELSE 0
      END
    ) OVER (
      PARTITION BY account_number
      ORDER BY
        CASE
          WHEN account_number IS NULL THEN 1
          ELSE 0
        END,
        account_number ASC,
        CASE
          WHEN dt IS NULL THEN 1
          ELSE 0
        END,
        dt ASC
    ) + 1 AS grp
  FROM
    (
      SELECT
        t2.*,
        LAG(dt) OVER (
          PARTITION BY account_number
          ORDER BY
            CASE
              WHEN account_number IS NULL THEN 1
              ELSE 0
            END,
            account_number ASC,
            CASE
              WHEN dt IS NULL THEN 1
              ELSE 0
            END,
            dt ASC
        ) AS col__5
      FROM
        t2
    ) sub__6
)
SELECT
  account_number,
  dt,
  grp,
  ROW_NUMBER() OVER (
    PARTITION BY account_number,
    grp
    ORDER BY
      account_number,
      CASE
        WHEN account_number IS NULL THEN 1
        ELSE 0
      END,
      account_number ASC,
      CASE
        WHEN dt IS NULL THEN 1
        ELSE 0
      END,
      dt ASC
  ) AS seq
FROM
  t3
ORDER BY
  account_number,
  CASE
    WHEN account_number IS NULL THEN 1
    ELSE 0
  END,
  account_number ASC,
  CASE
    WHEN dt IS NULL THEN 1
    ELSE 0
  END,
  dt ASC

你不需要读懂或调试这段 SQL,只需确认前面三步的逻辑正确,编译器就会输出可运行的代码。

列个表格总结一下:
image.png
这个实例展示了 SQLazy 处理“基于时间间隔的会话划分”类问题的简洁性:通过 segment condition 直接描述“超过 1 小时就新开一组”,再配合分区内行号,完美映射了业务需求。

相关文章
|
4月前
|
SQL 人工智能 JSON
智能问数(Text2SQL)工业级落地,纯 AI 黑盒方案都没戏
本文剖析Text2SQL领域“高准确率宣传”与“无公开DEMO”之间的矛盾,指出黑盒方案因AI幻觉、不可解释、不可审计,难担企业级信任;润乾NLQ采用白盒路线——以人类可读可确认的“规范文本”为中间层,AI仅作翻译,后续规则编译100%确定,真正实现稳定、可解释、可落地的智能问数。
|
11月前
|
SQL 自然语言处理 BI
另辟蹊径的 Text2SQL,不用大模型也能搞 chatBI
润乾报表NLQ组件摒弃大模型路线,采用规则词典与领域知识库,将自然语言精准转化为MQL查询语言,实现稳定、低成本、可维护的ChatBI。其核心在于结构化语义解析,避免“幻觉”,支持复杂多表关联与计算,适用于企业级BI场景,是可靠高效的自然语言查询解决方案。
|
4月前
|
SQL 人工智能 自然语言处理
准确率 100% 的智能问数(Text2SQL)实践,还要关心什么指标?
润乾NLQ创新采用“规范文本+规则编译”架构,将口语转为可验证的中间语言,再确定性生成SQL,实现规范文本→SQL环节100%准确率。规避大模型幻觉,支持多表JOIN、子查询、聚合等复杂场景,实施门槛低、结果稳定可控。(239字)
|
11月前
|
SQL 自然语言处理 BI
万字长文解析 NLQ 破局 Text2SQL,兼得灵活复杂准确
润乾NLQ创新采用“规范文本”作中间层,兼顾问题灵活性与查询准确性。通过人类可读的规范文本确认意图,结合规则引擎生成精确SQL,并支持复杂查询,以低成本实现企业级Text2SQL的可靠落地,突破传统三难困境。
|
6月前
|
人工智能 JavaScript BI
用 AI 编程生成 ECharts 图表
报表内置图表有限,复杂图表(如K线图、地图等)需手写ECharts代码,学习成本高、调试耗时。本文以K线图为例,介绍“参数导出→AI生成→脚本回填”三步法:用Trae等AI工具根据报表导出的参数自动生成JS脚本,再替换嵌入报表模板,大幅提升开发效率。(239字)
|
11月前
|
SQL XML 自然语言处理
Text2SQL 破局技术解析之一:规范文本与灵活性
润乾NLQ创新采用“规范文本”作为中间层,将自然语言转SQL分为三阶段:LLM生成可读的规范文本,用户确认意图后,通过规则引擎转为MQL再生成准确SQL。该方案兼顾灵活性、准确性与复杂查询支持,大幅降低企业实施成本,为人机协同的Text2SQL提供了可行的工程化路径。
|
4天前
|
SQL 人工智能 自然语言处理
语义层的厚度是智能问数 Text2SQL 的制胜点
Text2SQL 真正难点不在语法,而在业务语义。润乾 NLQ 以厚重语义层破局——涵盖关联、维度、指标、词典四大支柱,支撑多表关联、复杂计算与口语化查询,确保结果准确、确定、可落地。
|
9月前
|
XML 人工智能 自然语言处理
ChatBI 不止 Text2SQL,加上多维分析才算全链 AI+ 商业智能
润乾BI突破传统ChatBI局限,以规则引擎实现从“问数据”到“操作数据”的全链路自然语言分析。支持分组汇总、排名、环比、图表生成等复杂操作,指令规范、结果确定,杜绝AI幻觉。通过智能提示降低使用门槛,更可与LLM协同,将口语问题转化为精准分析步骤,让数据决策高效、可信、可控。
|
2月前
|
SQL 人工智能 自然语言处理
智能问数的不可能三角:灵活、准确、复杂
智能问数存在“不可能三角”:灵活性、准确性、复杂性三者不可兼得。润乾NLQ创新破局——用LLM专司口语转规范文本(保灵活),用户确认后交由规则引擎编译SQL(保准确),再通过MQL/DQL/SPL分层支撑复杂查询(保复杂)。三角非攻克,而是拆解与协同。
|
2月前
|
运维 安全 数据建模
免费SSL证书比付费的阿里云SSL证书更不安全吗?一文讲透底层真相+HTTPS证书选型全指南
绝大多数网站运维人员、个人站长、后端开发者在部署HTTPS时,都会陷入固化认知误区:付费SSL证书安全等级更高,免费SSL证书存在底层安全漏洞,不适用于正式线上业务。尤其是Let’s Encrypt、ZeroSSL这类有效期仅90天的免费DV证书,长期被贴上“容易被钓鱼站点滥用”“稳定性差”的负面标签。但从密码学底层、行业通用加密标准、CA机构签发规范综合分析,该认知存在根本性偏差:**在公网数据传输加密这个核心功能层面,正规渠道签发的免费DV证书与商业付费证书安全强度完全持平;二者真正的差距不在于加密算法防护能力,而是身份核验严格程度、运维兜底机制、风险赔付能力、长期合规信任体系**。
214 1