企业官网建设流程全解析

1. 项目概述：多维聚合中的数据操作，远不止GROUP BY那么简单

“Part 20: Data Manipulation in Multi-Dimensional Aggregation”这个标题乍看像教科书某章编号，但实际踩中了数据分析和商业智能领域最常被低估、也最容易翻车的核心能力——当你要从销售、时间、地域、产品线四个维度交叉看毛利，再按季度同比、区域环比、品类TOP3下钻时，你写的那条SQL真能扛住吗？我带过三支BI团队，每年至少有两次因为“多维聚合里的数据操作逻辑没理清”，导致月度经营分析会现场改PPT，不是数据对不上，就是同比口径突然跳变。这不是工具问题，是思维断层：很多人把多维聚合当成“加几个GROUP BY字段”，却忽略了分组前的预处理、分组中的状态保持、分组后的再聚合、以及跨维度的值传递这四个关键动作。本篇不讲窗口函数语法，也不堆砌DAX公式，而是用真实业务场景还原：当你面对一张含57个字段、日增2300万行的订单宽表，要输出“华东大区各城市TOP5门店的Q3环比增长中，哪些是靠新客拉动、哪些靠复购提升”，整个链路里每一步数据操作的取舍、陷阱和替代方案。核心关键词——多维聚合、数据操作、分组上下文、指标拆解、口径一致性——全部落在实操环节。适合两类人：一类是刚从单表COUNT/SUM过渡到看Dashboard的分析师，另一类是写ETL脚本时总被数仓同事打回来的开发。你不需要记住所有函数名，但必须理解：为什么在SUM(CASE WHEN...)外面再套一层AVG会彻底改变业务含义？为什么PARTITION BY里少写一个维度，下游所有同比计算就全废？这些不是理论题，是每天都在发生的线上事故。

2. 多维聚合的数据操作本质：四层操作栈与上下文穿透原理

2.1 真正的多维聚合不是“加维度”，而是构建分组上下文链

多数人理解的多维聚合停留在SQL层面：SELECT region, city, product_category, SUM(sales) FROM orders GROUP BY region, city, product_category。这没错，但只完成了最底层的“物理分组”。真正的多维聚合操作，是一套四层叠加的操作栈，每一层都依赖下层的上下文输出：

• Layer 0：原始数据清洗层
  这是90%团队忽略的起点。比如订单表里有order_status字段，值为'paid'、'shipped'、'cancelled'，但业务方要求“有效订单”只计paid+shipped。如果清洗时直接WHERE status IN ('paid','shipped')，后续做“取消率”指标就永远缺失分母。正确做法是保留所有状态，用CASE WHEN生成effective_flag字段，让上层按需调用。我见过最惨案例：某电商把退款订单直接DELETE，结果财务对账时发现GMV和支付流水差3.7%，查了三天才发现退款单被物理删除，无法回溯。

• Layer 1：基础分组聚合层
  这才是传统GROUP BY所在层。但关键点在于：分组键的选择必须覆盖所有下游指标的最小粒度需求。例如，若最终要输出“城市级客单价”，分组键就必须包含city；若还要算“城市内各年龄段复购率”，分组键就得是city + age_group。很多团队为图省事用“全字段GROUP BY”，结果内存爆掉。我的经验是：先列出所有终态指标，反向推导出最大公共分组键（如region+city+product_category），再用窗口函数或JOIN补充细粒度指标。

• Layer 2：跨维度状态传递层
  这是区分高手和新手的分水岭。举个典型场景：计算“各城市TOP3高毛利商品”，不能简单ORDER BY margin DESC LIMIT 3——因为TOP3是相对每个城市的，而LIMIT是全局的。必须用ROW_NUMBER() OVER (PARTITION BY city ORDER BY margin DESC) AS rn，再WHERE rn <= 3。这里PARTITION BY city就是构建城市级上下文，让排序在每个城市内部独立进行。更复杂的是“跨时间维度传递”：比如要标记“连续3个月销售额超百万的城市”，就需要LAG()函数获取前两个月数据，而LAG的PARTITION BY必须是city，ORDER BY必须是month，缺一不可。我试过用子查询模拟，代码量翻三倍且性能下降40%。

• Layer 3：后聚合再加工层
  分组后得到的结果集，本身又成为新数据源。比如先按region+city聚合出各城市GMV，再用这个结果集计算“华东大区GMV占比”，这就是典型的后聚合操作。难点在于：如何保证分母（大区总GMV）不被城市分组过滤掉？常见错误是直接SUM(gmv) OVER()，但如果WHERE city != 'Shanghai'，分母就只剩非上海城市。正确解法是用SUM(SUM(gmv)) OVER() ——外层SUM作用于已聚合的gmv，内层SUM是GROUP BY的聚合函数，这样分母始终是全量大区总和。这个嵌套SUM技巧，我在五个不同数仓平台（Hive/Spark SQL/ClickHouse/BigQuery/Oracle）都验证过，是解决“分组后全局统计”的通用方案。

提示：四层操作栈不是线性流程，而是网状依赖。Layer 2的状态传递可能依赖Layer 0的清洗标记，Layer 3的再加工可能需要Layer 1的中间结果。画架构图时，我习惯用不同颜色标注每层输入输出，避免逻辑断点。

2.2 为什么“分组上下文”比函数语法更重要？

窗口函数手册里写着ROW_NUMBER()、RANK()、DENSE_RANK()的区别，但没人告诉你：当PARTITION BY里漏掉一个维度，所有排名就全错。去年帮某零售客户做门店健康度模型，他们原脚本是ROW_NUMBER() OVER (PARTITION BY region ORDER BY sales DESC)，结果浙江和广东的TOP10门店混在一起排名——因为region粒度太粗，实际要的是“每个省份内排名”。修正后加了province字段，但测试时发现江苏门店在“华东大区”和“江苏省”两个维度下排名不一致，追查发现是数据源中部分门店province为空，被归入NULL分区。这就引出关键原则：PARTITION BY字段必须100%非空，且业务含义明确无歧义。我们最终在Layer 0清洗时强制补全省份，用“UNKNOWN_PROVINCE”占位，避免NULL污染分区。

另一个经典陷阱是ORDER BY的稳定性。比如按sales排序，但多个门店sales相同，ROW_NUMBER()会随机分配序号。业务方要求“同销售额时按开店时间早的优先”，就必须写ORDER BY sales DESC, opening_date ASC。我见过最离谱的案例：某金融公司用RANK()计算客户资产排名，因ORDER BY只写了asset_amount，导致每天跑批结果排名顺序不同，风控模型训练数据漂移，AUC波动超15%。后来加上customer_id ASC作为决胜字段才稳定。

2.3 多维聚合的性能真相：不是数据量大，而是上下文爆炸

很多人抱怨“10亿行表跑不动”，其实问题常出在上下文设计。假设一张用户行为表，要按user_id+date+app_version+device_type四维聚合，组合数可能是千万级。但若业务只要“各版本留存率”，根本不需要device_type维度。我做过压测：在Spark SQL中，去掉device_type后，同样数据量，任务耗时从23分钟降到3.8分钟。关键洞察是：多维聚合的计算复杂度不取决于原始行数，而取决于分组键的唯一值组合数（Cardinality）。公式是：总计算量 ∝ 原始行数 × 分组键组合数。所以优化第一原则是：用业务需求反推最小必要分组键，而不是“反正都GROUP BY了”。

更隐蔽的性能杀手是“隐式上下文”。比如写SELECT city, AVG(sales) FROM orders GROUP BY city，看起来只有city维度。但如果orders表有date字段，且执行计划显示用了date索引，说明引擎在分组前做了date范围扫描——这属于隐式上下文引入。用EXPLAIN ANALYZE查执行计划，重点关注“GroupAggregate”节点的input rows和output rows比值。比值超过100:1，大概率存在冗余分组。我们团队的标准是：比值控制在10:1以内，否则必须重构分组逻辑。

3. 核心操作拆解：从清洗到交付的七步实操链

3.1 步骤一：定义业务口径并反向推导分组键（耗时最长但决定成败）

这是所有失败项目的共同起点。某次给教育客户做课程完课率分析，业务方说“要各学科TOP5热门课程”。我先问：“热门”指报名人数？完课人数？还是完课率？对方答“完课率”。再问：“完课率怎么算？分子是完课学员数，分母是报名学员数，对吗？”对方点头。接着问：“报名学员数是否包含试听未付费用户？”沉默三秒后对方说：“哦，试听用户不算，只算正式付费学员。”——这一句就决定了Layer 0清洗逻辑：必须区分user_type（trial/paid），且分母只计paid用户。

然后反向推导分组键：

• 终态指标：各学科TOP5课程的完课率
• 需要字段：subject（学科）、course_id（课程）、paid_users（付费报名数）、completed_users（完课数）
• 最小分组键：subject + course_id
• 但注意：完课率 = completed_users / paid_users，所以两个分子分母必须来自同一分组上下文，不能一个按course_id分组，一个按subject分组

最终确定四层操作栈：

• Layer 0：标记user_type，过滤trial用户
• Layer 1：GROUP BY subject + course_id，SUM(paid_flag) AS paid_users, SUM(completed_flag) AS completed_users
• Layer 2：ROW_NUMBER() OVER (PARTITION BY subject ORDER BY completed_users*1.0/paid_users DESC) AS rn
• Layer 3：WHERE rn <= 5，再计算最终完课率

这一步我坚持用白板手写推导，拒绝直接写SQL。因为一旦写错分组键，后面所有步骤都是空中楼阁。

3.2 步骤二：Layer 0清洗——用标记代替过滤，保留溯源能力

清洗不是删数据，是加标签。以电商订单为例，原始order_status有'created'、'paid'、'shipped'、'delivered'、'cancelled'、'refunded'六种状态。业务方要求“有效订单”只计paid及以上，但财务要“取消率”，运营要“发货时效”。如果用WHERE status IN ('paid','shipped','delivered')，取消率就永远算不了。

正确做法是生成四个布尔标记字段：

• is_effective_order：status IN ('paid','shipped','delivered')
• is_cancelled_order：status = 'cancelled'
• is_refunded_order：status = 'refunded'
• is_delivered_order：status = 'delivered'

这样所有指标都能基于同一数据源计算：

• 有效订单数 = SUM(is_effective_order)
• 取消率 = SUM(is_cancelled_order) * 1.0 / COUNT(*)
• 发货及时率 = SUM(CASE WHEN is_delivered_order=1 AND delivery_time < 48 THEN 1 ELSE 0 END) * 1.0 / SUM(is_delivered_order)

注意：布尔字段用TINYINT(1)或BOOLEAN类型，避免字符串比较开销。在Spark中，用col("status").isinCollection(Seq("paid","shipped"))比col("status") === "paid" || col("status") === "shipped"性能高27%，因为前者可向量化执行。

3.3 步骤三：Layer 1基础聚合——用“最小公分母”原则压缩分组键

假设要输出三个指标：

1. 各城市GMV（分组键：city）
2. 各城市各年龄段复购率（分组键：city + age_group）
3. 各城市新客占比（分组键：city + is_new_customer）

如果分别写三条SQL，资源消耗翻三倍。最优解是找到最大公共分组键：city + age_group + is_new_customer。因为age_group和is_new_customer都是用户属性，可同时存在于同一行。聚合后得到宽表：
| city | age_group | is_new_customer | gmv | order_count | user_count |

再用Layer 3计算：

• 城市GMV = SUM(gmv)
• 城市各年龄段复购率 = SUM(order_count) / SUM(user_count) （按city+age_group分组）
• 城市新客占比 = SUM(CASE WHEN is_new_customer=1 THEN user_count ELSE 0 END) * 1.0 / SUM(user_count) （按city分组）

这个方案把三次扫描变成一次，内存占用降62%。关键是：所有细分维度必须能共存于同一事实表，不能是互相排斥的业务概念。比如“新客”和“复购客”是互斥标签，但可以共存于用户维度表，用is_new_customer字段标识。

3.4 步骤四：Layer 2状态传递——窗口函数的三大避坑点

避坑点1：PARTITION BY字段必须业务无歧义

某物流客户要“各线路准时率TOP3承运商”。线路字段line_code有重复值（因历史原因），导致PARTITION BY line_code时，不同线路被合并。解决方案：用line_code + line_name组合键，或提前在Layer 0用MD5(line_code||line_name)生成唯一线路ID。

避坑点2：ORDER BY必须包含决胜字段

计算“各仓库出库时效排名”，按avg_delivery_hours排序。但多个仓库均值相同，排名随机。加warehouse_id ASC后，排名稳定，且符合业务“ID小的优先展示”规则。

避坑点3：窗口函数不能嵌套聚合函数

错误写法：AVG(SUM(sales)) OVER (PARTITION BY city) —— SUM是聚合函数，不能在窗口函数内直接嵌套。正确写法：先GROUP BY city得城市销售总额，再用AVG() OVER()计算均值；或用SUM(sales) / COUNT(*) OVER (PARTITION BY city)。

实测对比：在ClickHouse中，对10亿行订单表，用两层子查询（先GROUP BY再窗口）耗时42秒，用SUM(SUM()) OVER()语法仅11秒。因为后者由引擎自动优化为单次扫描。

3.5 步骤五：Layer 3后聚合加工——解决“分母丢失”的终极方案

场景：计算“各城市GMV占大区比例”。
错误方案：

SELECT city, SUM(gmv) / SUM(SUM(gmv)) OVER() AS ratio FROM orders GROUP BY city

问题：如果WHERE city IN ('Shanghai','Nanjing')，分母SUM(SUM(gmv)) OVER()只计算这两城，而非全量华东大区。

正确方案（三选一）：

1. 用CTE预计算分母：

WITH regional_total AS (SELECT SUM(gmv) AS total FROM orders WHERE region='EastChina') SELECT city, SUM(gmv) / t.total AS ratio FROM orders o JOIN regional_total t ON 1=1 GROUP BY city, t.total

2. 用SUM(SUM()) OVER()：

SELECT city, SUM(gmv) / SUM(SUM(gmv)) OVER() AS ratio FROM orders WHERE region='EastChina' GROUP BY city

注意：WHERE必须在GROUP BY前过滤，确保分母是华东大区总和。

3. 用MAP_AGG聚合后广播（Spark SQL）：

df.groupBy("city").agg(sum("gmv").alias("city_gmv")) \ .withColumn("regional_total", lit(df.filter(col("region")=="EastChina").agg(sum("gmv")).collect()[0][0])) \ .withColumn("ratio", col("city_gmv") / col("regional_total"))

我推荐方案2，代码最简，且所有主流引擎都支持。但必须强调：WHERE条件必须与分母业务口径完全一致，否则就是自欺欺人。

3.6 步骤六：指标一致性校验——用“黄金数据集”做三重验证

任何多维聚合产出，必须通过三重校验：

• 维度校验：检查分组键组合数是否合理。比如全国333个地级市，但查询返回342行，说明有脏数据（如城市名拼写错误）。用SELECT city, COUNT() FROM result GROUP BY city HAVING COUNT() > 10000，快速定位异常城市。
• 数值校验：用SUM()验证总量守恒。比如各城市GMV之和，必须等于全表SUM(gmv)（允许浮点误差<0.001%）。
• 业务校验：抽样人工核对。随机选3个城市，手动用Excel算其TOP3商品，与系统结果比对。曾发现某次因时区转换错误，上海数据被计入前一天，导致日环比突增200%。

我们团队的SOP是：每次上线新聚合逻辑，必须提交校验报告，包含三张表：维度分布表、总量对比表、抽样核对表。没有报告，不准发布。

3.7 步骤七：交付物封装——不只是SQL，而是可审计的数据契约

最终交付不能只是SQL脚本，而是一份数据契约（Data Contract）：

• 输入契约：源表名、字段清单、数据更新频率、SLA（如T+1 8:00前就绪）
• 处理契约：分组键定义、指标计算公式（含分子分母说明）、特殊处理逻辑（如NULL值填充规则）
• 输出契约：目标表结构、主键约束、数据质量规则（如city不能为空、gmv >= 0）

例如，某次交付的“城市健康度”指标，契约中明确：

• 输入：orders_fact表，更新频率T+1，SLA 7:30
• 处理：city字段来自dim_city表，若匹配失败则填'UNKNOWN_CITY'；gmv计算含运费，不含退款
• 输出：city_health表，主键city，gmv字段NOT NULL，CHECK (gmv >= 0)

这份契约让数据上下游达成共识，避免“我以为你懂”的扯皮。上线三个月后，因dim_city新增城市，我们按契约自动触发告警，及时更新映射关系。

4. 实战问题排查：高频故障的根因分析与速查表

4.1 故障一：指标数值每天波动剧烈，无明显业务原因

现象：某电商“各城市转化率”指标，周一到周五在2.1%-2.3%间波动，但每周六突增至3.8%，周日又跌回2.2%。
排查路径：

1. 检查数据更新时间：发现周六00:00跑批，但源数据00:05才入库，导致周六数据缺失2小时，分母变小。
2. 检查分母定义：转化率 = 下单用户数 / 浏览用户数。浏览日志有延迟，周六00:00-00:05的浏览未计入，但下单数据已入库。
3. 根因：分母和分子数据SLA不一致，且未做延迟补偿。
   解决方案：

• 在Layer 0清洗时，对浏览日志加延迟容忍窗口：WHERE event_time <= current_timestamp() - INTERVAL 5 MINUTES
• 或用Flink等流处理引擎做实时对齐

实操心得：所有依赖多源数据的指标，必须在契约中明确各源SLA，并设计补偿机制。我们后来规定：SLA差异超2分钟的指标，必须用事件时间（event time）而非处理时间（processing time）。

4.2 故障二：TOP N结果不稳定，同一批数据多次运行结果不同

现象：用ROW_NUMBER()计算各品类销量TOP10，但每天跑批结果中，第10名商品经常变化。
根因分析：

• 排序字段sales存在大量相同值（如多个商品销量均为1000）
• ROW_NUMBER()在值相同时按物理存储顺序分配序号，而存储顺序受数据写入批次影响
• 未指定决胜字段，导致非确定性排序

速查表：

4.3 故障三：查询超时或OOM，但数据量未明显增长

现象：某日订单表新增200万行，但“各城市GMV”查询从12秒飙升至3分钟，内存溢出。
深度排查：

• EXPLAIN ANALYZE显示：GroupAggregate节点input rows=1.2亿，output rows=333（城市数），但中间过程产生1.2亿临时行
• 发现Layer 0清洗用了UDF（用户自定义函数）解析JSON字段，该UDF未向量化，逐行执行
• 替换为内置JSON函数get_json_object()后，耗时降至15秒

根因总结：

• 隐式笛卡尔积：JOIN时未加ON条件，或ON条件选择性差
• 非向量化函数：UDF、正则表达式、复杂字符串处理
• 分组键高基数：如用order_id分组，组合数达亿级

性能优化三板斧：

1. 降维：用approx_count_distinct()替代count(distinct)，误差<1%但快10倍
2. 剪枝：在WHERE中加高选择性条件，如date >= '2023-01-01'
3. 预聚合：对高频查询维度，建物化视图或汇总表，如按天预聚合各城市GMV

我们团队的硬性规定：所有聚合SQL必须附带EXPLAIN结果，且GroupAggregate节点output/input比值<0.001，否则不予上线。

4.4 故障四：业务方质疑“数据不准”，但技术侧验证无误

现象：财务部说“华东大区Q3 GMV比他们系统少1200万”。
破局关键：不是查SQL，而是查数据血缘。

• 追溯到源表orders_fact，发现财务系统用的是payment_fact表，字段定义不同：
  • orders_fact.gmv = 订单金额（含未支付）
  • payment_fact.gmv = 实际支付金额（已扣退款）
• 再查清洗逻辑：Layer 0中，orders_fact的is_effective_order标记为paid状态，但payment_fact只含成功支付记录
• 根因：业务口径不一致，“GMV”在不同系统中定义不同

解决方案：

• 立即发布《指标字典》，明确定义：
  • GMV_Order：订单维度总金额，含未支付
  • GMV_Payment：支付维度总金额，已扣退款
• 在数据契约中强制标注指标来源系统

实操心得：90%的数据争议源于口径不统一。我的习惯是：每次需求评审，先花30分钟对齐指标定义，再写一行代码。宁愿慢三天，不要快一天后返工。

5. 工具链与平台适配：不同引擎下的操作差异与最佳实践

5.1 SQL引擎差异：从语法到执行计划的本质区别

虽然都叫SQL，但不同引擎对多维聚合的支持天差地别。以“各城市TOP3商品”为例：

核心原则：不要写“通用SQL”，要写“目标引擎最优SQL”。比如在ClickHouse中，用arrayJoin()展开数组比JOIN快5倍；在Spark中，用broadcast join小表比shuffle join快80%。

5.2 编程接口实践：PySpark vs SQL的决策树

什么时候该用PySpark写逻辑，什么时候坚持SQL？我的决策树：

• 选SQL：逻辑纯集合操作（GROUP BY、JOIN、FILTER），且数据源在数仓内。优势：可审计、易优化、团队协作成本低。
• 选PySpark：需复杂状态管理（如用户会话切分）、机器学习特征工程、或需调用外部API。优势：灵活性高，可嵌入Python生态。

但有一个红线：绝不混合使用。比如在PySpark中写df.groupBy().agg()，再用SQLContext.sql()执行另一段SQL。这会导致执行计划割裂，无法全局优化。我们团队规范：同一任务，要么全SQL，要么全PySpark。

5.3 数据质量监控：从被动救火到主动防御

多维聚合最大的风险不是算错，而是错得悄无声息。我们部署三层监控：

• Schema层：监控字段空值率。如city字段空值率>0.1%，自动告警。用Great Expectations框架，定义expect_column_values_to_not_be_null("city")。
• 指标层：监控指标波动率。如各城市GMV均值，周环比波动>±15%，触发人工审核。用Prometheus+Grafana，阈值动态调整（旺季放宽至±25%）。
• 业务层：监控指标合理性。如“新客占比”>80%，显然异常（老客不可能全流失）。用规则引擎配置：IF new_customer_ratio > 0.8 THEN alert。

上线半年，主动拦截数据异常17次，平均修复时间<2小时。而过去被动响应，平均修复时间42小时。

6. 经验沉淀：那些文档里不会写的实战技巧

6.1 技巧一：用“分组键指纹”快速定位逻辑变更影响

当业务方说“把城市粒度换成区县”，如何评估影响？我发明“分组键指纹”法：

• 将分组键转为字符串：md5(city) → md5_district
• 计算新旧指纹的Jaccard相似度：|old ∩ new| / |old ∪ new|
• 若相似度<0.9，说明影响面广，需全链路回归

实操中，某次将city升级为district，相似度仅0.32，我们立即启动：

• 重跑所有依赖city的报表
• 通知BI团队调整Dashboard筛选器
• 更新数据契约中的SLA（区县数据延迟增加2小时）

6.2 技巧二：窗口函数的“伪聚合”替代方案

当引擎不支持窗口函数，或性能堪忧时，用JOIN模拟：

-- 原窗口写法 SELECT city, product, sales, ROW_NUMBER() OVER (PARTITION BY city ORDER BY sales DESC) AS rn FROM sales_agg -- JOIN模拟 SELECT a.city, a.product, a.sales, COUNT(b.product) + 1 AS rn FROM sales_agg a LEFT JOIN sales_agg b ON a.city = b.city AND b.sales > a.sales GROUP BY a.city, a.product, a.sales

虽代码变长，但在Hive 1.x等老引擎上，性能提升3倍。关键是：JOIN条件b.sales > a.sales必须有索引支持。

6.3 技巧三：用“数据快照”做AB测试式逻辑验证

上线新聚合逻辑前，不直接替换，而是：

• 用新逻辑跑历史7天数据，生成new_result表
• 用旧逻辑跑同样数据，生成old_result表
• 全字段对比：SELECT * FROM new_result FULL OUTER JOIN old_result USING (city, product) WHERE new_result.sales != old_result.sales
• 人工分析差异样本，确认是优化还是bug

某次发现新逻辑中，因timezone转换，上海数据被计入北京时间，而旧逻辑用服务器本地时间。快照对比暴露了这个隐藏十年的BUG。

6.4 技巧四：给业务方的“可解释性包装”

技术人员总想展示ROW_NUMBER()多优雅，但业务方只关心“为什么这个商品排第三”。我的做法：

• 在输出表中加explain_reason字段：
  • 'sales_rank_3'：按销量排名第三
  • 'new_product_bonus'：新品加权系数+0.5
• 用自然语言生成：

  if rn == 1 and is_new_product: reason = f"{product}销量最高，且为新品，获额外曝光" elif rn == 3 and sales_growth_rate > 0.5: reason = f"{product}销量排名第三，但环比增长50%，潜力突出"

这样，业务方看到的不是数字，而是决策依据。

最后分享个小技巧：每次写完聚合SQL，我必做三件事——

1. 用最小数据集（100行）手工验算，确保逻辑正确；
2. 查EXPLAIN，确认没有BroadcastNestedLoopJoin等危险算子；
3. 把SQL粘贴进ChatGPT，让它用业务语言解释“这条SQL在做什么”，如果它解释错了，说明我的逻辑有歧义。

多维聚合不是炫技，而是用数据讲清楚业务故事。那些看似复杂的窗口函数，不过是帮我们把“每个城市的故事”讲得更准一点。