多维聚合实战：SQL与Polars高维数据安全变形指南

1. 项目概述：当数据不再是一张“平铺直叙”的表格

你有没有遇到过这样的场景：销售部门要按“城市+季度+产品线”三个维度看毛利，财务部门却需要“事业部+成本中心+会计期间”交叉分析费用率，而管理层打开BI看板时，只看到一个模糊的“同比下滑2.3%”——没人知道这数字是哪个区域、哪类产品、哪个月份拖了后腿。这就是典型的多维聚合困境：原始数据像一筐混装的水果，而业务需求却要求你同时按颜色、大小、成熟度、产地四个筛子去分拣，还不能漏掉任何一颗果子。本项目标题中的“Part 20: Data Manipulation in Multi-Dimensional Aggregation”，表面看是教程序列的第20节，实则直指数据分析链条中最容易被轻视、却最常导致结论翻车的核心环节——如何在保持数据语义完整性的前提下，对高维结构进行安全、可逆、可解释的变形操作。它不是教你怎么写GROUP BY，而是解决当你面对一张含12个维度字段、87个度量指标、日增千万行的宽表时，如何让SUM()不吞掉关键细节、让PIVOT不扭曲业务逻辑、让ROLLUP不制造虚假相关性。我带过的23个企业级数据项目里，有17个在上线后三个月内因多维聚合逻辑缺陷引发过报表争议，根源全出在“数据操纵”这个看似基础的环节——比如把“客户等级”和“签约渠道”两个非正交维度强行做笛卡尔积，结果算出“VIP客户通过地推渠道签约”的荒谬组合；又比如用COUNT(DISTINCT)统计跨月活跃用户时，没考虑用户ID在不同系统间的映射漂移，导致复购率虚高40%。这篇文章不讲抽象理论，只拆解真实战场上的操作手册：从维度建模的底层约束开始，到SQL引擎对多维聚合的实际执行路径，再到Pandas/Polars中那些“看起来一样、结果却天差地别”的函数调用陷阱。无论你是刚学完GROUP BY的新手，还是每天和OLAP Cube打交道的资深分析师，这里的内容都能让你下次写聚合查询前，多问一句“这个操作真的尊重了我的业务事实吗”。

2. 多维聚合的本质与设计逻辑：为什么“堆维度”是最危险的捷径

2.1 维度不是标签，而是业务事实的坐标系

很多人把维度理解成“筛选条件”或“分组字段”，这是根本性误区。真正的维度（Dimension）是业务世界中不可再分的稳定参照系，它定义了度量（Measure）存在的空间位置。举个具体例子：某电商平台的订单事实表中，“下单时间”维度绝不是简单的一个DATETIME字段，而是一个由年、季度、月、周、日、小时、是否工作日、是否节假日、是否大促期等12个层级构成的时间维度表（Time Dimension Table）。当你执行GROUP BY year, quarter, product_category时，实际是在三维坐标系中定位立方体单元——X轴是年份（离散点），Y轴是季度（周期性循环），Z轴是品类（树状分类）。如果直接用EXTRACT(YEAR FROM order_time)硬编码年份，就等于把连续的时间轴粗暴切成孤立切片，丢失了“2023年Q4包含双十二大促”这个关键业务上下文。我曾帮一家零售企业重构销售看板，他们原报表用DATE_TRUNC('month', sale_date)分月统计，结果发现所有门店的“月度环比”在12月都异常飙升。排查三天才发现：系统里12月25日的圣诞订单，因物流延迟到次年1月才确认收入，但分月逻辑把订单日期当唯一依据，导致12月虚增、1月虚减。真正的解法是建立独立的时间维度表，将“会计期间”（财务认领时间）和“业务发生时间”（订单创建时间）作为两个平行维度，允许用户按需切换坐标系。这印证了一个核心原则：维度设计必须前置，且需承载业务规则，而非技术便利。

2.2 多维聚合的三大反模式：踩坑现场实录

在上百次数据交付中，我总结出最常触发线上事故的三种错误操作，它们都源于对多维聚合本质的误读：

1. 维度爆炸式堆叠（Dimension Explosion）
   典型表现：为满足“所有可能组合”的需求，在GROUP BY中塞入15个字段。问题在于：当某个维度存在大量NULL值（如“推荐人ID”仅对30%订单有效），笛卡尔积会生成海量空值组合，导致SUM()结果被稀释。更致命的是，当维度间存在隐含依赖（如“省份”决定“城市”，“城市”决定“商圈”），强行三者并列分组会产生逻辑矛盾——杭州西湖区不可能出现在广东省数据中，但SQL不会报错，只会返回0值，掩盖真实分布。我们曾用GROUP BY province, city, district, store_type, member_level分析门店业绩，结果发现TOP10门店中7家是“未知省份+未知城市+旗舰店”的组合，根源是门店主数据中地理信息缺失率达62%，聚合操作把脏数据合法化了。

2. 度量计算顺序错乱（Measure Order Fallacy）
   这是最隐蔽的陷阱。比如计算“客单价=总销售额/订单数”，新手常写SELECT SUM(amount)/COUNT(*)。看似正确，但在多维聚合中，如果先按“用户等级”分组，再计算该等级的客单价，SUM(amount)/COUNT(*)是对每个用户的平均订单额，而非该等级所有订单的平均交易额。正确做法必须是SUM(amount)/SUM(COUNT(*))，即先汇总各维度下的订单总数，再用总销售额除以总订单数。我在金融风控项目中见过更极端案例：计算“逾期率=逾期账户数/总授信账户数”，开发人员用COUNT(CASE WHEN overdue_days>0 THEN 1 END)/COUNT(*)，结果在按“放款渠道”分组时，某互联网渠道逾期率高达98%。后来发现该渠道大量测试账号未设置逾期标识，COUNT(*)把测试账号全算进分母，而分子只计真实逾期户——本质上是在错误的粒度上执行了除法运算。

3. 聚合函数的语义漂移（Semantic Drift of Aggregates）
   同一个函数在不同维度组合下含义剧变。MAX(created_at)在“用户ID”维度下是该用户的最后登录时间，在“订单ID”维度下却是该订单的创建时间（单值无意义），而在“产品类目”维度下则变成该类目下最新上架商品时间。某SaaS公司报表显示“客户成功团队响应时长中位数为0.3秒”，震惊全员。排查发现：他们用PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY response_time)按“客户行业”分组，但部分行业只有1个客户（如“航天工业”仅服务2家单位），中位数计算退化为单值，而该客户恰好是内部测试账号，响应时间设为0。聚合函数的稳定性必须与维度粒度严格匹配——高基数维度（如用户ID）适合分布统计，低基数维度（如产品状态）只适合计数或布尔判断。

2.3 设计决策树：选对聚合策略比写对SQL更重要

面对具体需求，如何选择技术方案？我用一张决策树收束混乱：

• 第一步：确认业务问题的原子粒度
  问自己：“这个问题的答案，最小不可分割的单位是什么？” 如果是“每个用户的月度消费总额”，粒度就是（用户ID，年月）；如果是“华东区Q3各品类GMV占比”，粒度就是（大区，季度，品类）。所有维度必须能无损还原到该粒度。曾有团队坚持在“订单明细表”上直接聚合，结果发现同一订单的多个SKU被重复计算，被迫回溯到“订单头表”重建粒度。

• 第二步：识别维度间的层级关系
  画出维度关系图：时间维度必有年→季→月→日层级；地理维度必有国家→省→市→区层级；产品维度必有类目→子类目→品牌→SKU层级。禁止跨层级并列分组（如同时用“年份”和“星期几”），必须通过层级钻取（Drill-down）实现。我们用Snowflake构建的销售Cube中，强制规定所有查询必须从最高层级（如“财年”）开始，下钻时只能沿预设路径（财年→季度→月份），杜绝“年份+星期几”这类反模式。

• 第三步：为度量匹配聚合函数

  度量类型	安全聚合函数	危险操作	原因说明
  可加性度量（销售额）	SUM(), AVG()	MAX(), MIN()	极值破坏总量守恒
  半可加性度量（库存）	SUM()（跨时间）	SUM()（跨地点）	库存不能跨仓库相加
  不可加性度量（比率）	重构为分子/分母	直接AVG(转化率)	平均比率≠总转化率
  分布型度量（响应时长）	PERCENTILE_*	AVG(), MEDIAN()（无权重）	需按样本量加权计算

这个决策树不是教条，而是血泪教训的结晶。当你在凌晨三点修复因AVG(conversion_rate)导致的CEO汇报数据偏差时，会真正理解：多维聚合不是技术操作，而是业务逻辑的翻译过程。

3. 核心操作详解：从SQL到Python的实战拆解

3.1 SQL层：超越GROUP BY的七种武器

标准SQL的GROUP BY只是起点，真正的多维聚合需要组合使用高级语法。以下是我生产环境验证过的七种关键技术，每种都附真实场景和避坑指南：

1. ROLLUP：自动生成小计行，但小心NULL陷阱
场景：电商大促复盘需同时看“全站→类目→品牌→单品”四级汇总。

SELECT COALESCE(category, 'ALL') as category, COALESCE(brand, 'ALL') as brand, COALESCE(sku_id, 'ALL') as sku_id, SUM(gmv) as total_gmv FROM sales_fact GROUP BY category, brand, sku_id WITH ROLLUP;

关键点：WITH ROLLUP会在每个维度层级生成NULL值行（如category='手机'，brand=NULL表示该类目下所有品牌合计）。但NULL不等于'ALL'！必须用COALESCE显式转换，否则前端渲染时NULL会被过滤。更严重的是，ROLLUP生成的(ALL, ALL, ALL)行是全表总计，但若原始数据有WHERE条件（如WHERE status='paid'），这个总计可能与SELECT SUM(gmv) FROM sales_fact WHERE status='paid'不一致——因为ROLLUP在分组后计算，而WHERE在分组前过滤。解决方案：始终用CTE先过滤再ROLLUP。

2. CUBE：穷举所有组合，但性能杀手需节制
场景：分析营销活动效果需交叉验证“渠道×人群×时段”。

-- 危险写法（3维度CUBE生成2^3=8种组合） SELECT channel, audience, hour_slot, SUM(clicks) FROM campaign_log GROUP BY channel, audience, hour_slot WITH CUBE;

问题：当channel有50种、audience有200种、hour_slot有24种时，CUBE会尝试50×200×24=24万种组合，其中99%是0值（如“抖音×Z世代×凌晨3点”）。实测在10亿行表上耗时47分钟。优化方案：改用GROUPING SETS精准指定必要组合：

GROUP BY GROUPING SETS ( (channel, audience), -- 渠道×人群 (channel, hour_slot), -- 渠道×时段 (audience, hour_slot), -- 人群×时段 (channel), -- 渠道总计 (audience), -- 人群总计 (hour_slot), -- 时段总计 () -- 全局总计 );

这样只生成7种组合，耗时降至23秒，且结果更聚焦业务需求。

3. GROUPING()函数：识别ROLLUP/CUBE生成的NULL
继续上面的例子，COALESCE(channel, 'ALL')无法区分“真实channel为NULL”和“ROLLUP生成的占位NULL”。正确做法：

SELECT CASE WHEN GROUPING(channel)=1 THEN 'ALL_CHANNEL' ELSE channel END as channel, CASE WHEN GROUPING(audience)=1 THEN 'ALL_AUDIENCE' ELSE audience END as audience, SUM(clicks) FROM campaign_log GROUP BY channel, audience WITH ROLLUP;

GROUPING(channel)返回1表示该列为ROLLUP生成的NULL，0表示真实数据。这是保证报表语义准确的生命线。

4. 窗口函数嵌套聚合：解决“先分组再排名”的刚需
场景：找出“各城市中销量TOP3的品类”。
错误写法：

-- 错！窗口函数在GROUP BY之后执行，无法对分组内排序 SELECT city, category, SUM(sales) FROM orders GROUP BY city, category QUALIFY ROW_NUMBER() OVER (PARTITION BY city ORDER BY SUM(sales) DESC) <= 3;

正确链路：

WITH city_category_sales AS ( SELECT city, category, SUM(sales) as total_sales FROM orders GROUP BY city, category ), ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY city ORDER BY total_sales DESC) as rn FROM city_category_sales ) SELECT city, category, total_sales FROM ranked WHERE rn <= 3;

关键洞察：窗口函数作用于已聚合的结果集，而非原始行。必须用CTE分两步：先GROUP BY聚合，再窗口排序。我在广告平台项目中因此少查37TB数据——原方案试图在100亿行原始日志上开窗，新方案只在百万行聚合结果上操作。

5. FILTER子句：替代CASE WHEN的优雅方案
场景：计算“支付成功率=支付成功订单数/总订单数”，但需排除测试订单。
传统写法：

SELECT COUNT(CASE WHEN status='paid' AND is_test=0 THEN 1 END) * 1.0 / COUNT(CASE WHEN is_test=0 THEN 1 END) as success_rate FROM orders;

FILTER写法（PostgreSQL/BigQuery支持）：

SELECT COUNT(*) FILTER (WHERE status='paid' AND is_test=0) * 1.0 / COUNT(*) FILTER (WHERE is_test=0) as success_rate FROM orders;

优势：逻辑更清晰，避免CASE WHEN的嵌套混乱；执行计划更优（单次扫描）；且COUNT(*) FILTER比COUNT(CASE...)在NULL处理上更鲁棒。

6. LATERAL JOIN：处理动态维度的终极方案
场景：用户画像表中“兴趣标签”是JSON数组（["科技","游戏","摄影"]），需展开为多行并与订单表关联。

SELECT u.user_id, t.tag, o.total_amount FROM users u CROSS JOIN LATERAL ( SELECT value::STRING as tag FROM UNNEST(JSON_EXTRACT_ARRAY(u.interests)) as value ) t LEFT JOIN orders o ON u.user_id = o.user_id;

LATERAL确保子查询能引用外部表字段（u.interests），这是UNNEST无法单独做到的。在实时推荐系统中，我们用此技术将百万用户×平均5个标签的爆炸式关联，控制在亚秒级响应。

7. MATERIALIZED VIEW：固化高频聚合，但警惕陈旧风险
场景：每日需查询“各省份近30天GMV趋势”，原始表日增2亿行。

CREATE MATERIALIZED VIEW province_gmv_30d AS SELECT province, DATE_TRUNC('day', order_date) as stat_date, SUM(gmv) as daily_gmv FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY province, DATE_TRUNC('day', order_date);

优势：查询速度提升200倍。但风险在于：若订单状态变更（如退款），物化视图不会自动更新。我们的解决方案是：

• 设置刷新策略：REFRESH MATERIALIZED VIEW province_gmv_30d每日凌晨2点执行
• 在ETL流程中，对状态变更的订单，触发增量更新：INSERT INTO province_gmv_30d ... ON CONFLICT UPDATE
• 前端报表强制添加“数据截止时间”水印，避免用户误读实时性。

3.2 Python层：Pandas与Polars的生死抉择

当SQL无法满足复杂逻辑（如留存率计算、漏斗归因），Python成为最终防线。但Pandas和Polars的选择，直接决定项目成败。

Pandas的“温柔陷阱”

# 场景：计算各城市用户7日留存率（D1→D7） df = pd.read_sql("SELECT user_id, city, event_date FROM events", conn) # 错误示范：用groupby.apply暴力计算 def calc_retention(group): first_day = group['event_date'].min() cohort = group[group['event_date'] == first_day]['user_id'].unique() retention = {} for day in range(1, 8): target_date = first_day + pd.Timedelta(days=day) active_users = group[group['event_date'] == target_date]['user_id'].nunique() retention[f'D{day}'] = active_users / len(cohort) if cohort.size > 0 else 0 return pd.Series(retention) result = df.groupby('city').apply(calc_retention) # 内存爆破预警！

问题：groupby.apply对每个城市单独执行Python函数，无法利用向量化；当城市数超1000时，内存占用达32GB。更糟的是，pd.Timedelta在大型DataFrame上性能极差。

Polars的降维打击

import polars as pl # 一次加载，全程惰性求值 df = pl.scan_parquet("events.parquet") \ .with_columns([ pl.col("event_date").cast(pl.Date).alias("date"), pl.col("user_id").cast(pl.Utf8) ]) # 关键：用表达式API替代Python循环 cohort_df = df.group_by("user_id").agg([ pl.col("date").min().alias("first_date"), pl.col("city").first().alias("city") # 假设用户归属城市不变 ]) # 计算留存：用join代替循环 retention_df = cohort_df.join( df.select(["user_id", "date"]).with_columns( pl.col("date").alias("retention_date") ), on="user_id", how="left" ).with_columns([ (pl.col("retention_date") - pl.col("first_date")).dt.total_days().alias("days_since_first") ]).filter( pl.col("days_since_first").is_between(1, 7, closed="both") ).group_by(["city", "days_since_first"]).agg([ pl.col("user_id").n_unique().alias("retained_users") ]).join( cohort_df.group_by("city").agg( pl.col("user_id").n_unique().alias("cohort_size") ), on="city" ).with_columns([ (pl.col("retained_users") / pl.col("cohort_size")).alias("retention_rate") ])

优势：

• 内存效率：Polars用Arrow内存格式，相同数据比Pandas省内存60%
• 并行计算：.group_by().agg()自动多线程，10亿行数据聚合耗时从Pandas的42分钟降至Polars的3.7分钟
• 查询优化：.scan_parquet()惰性加载，只读取需要的列；filter提前下推，避免全表扫描

我的选型铁律：

• 数据量 < 100万行：Pandas足够，开发效率优先
• 数据量 100万~1亿行：Polars，用pl.read_csv()或pl.scan_parquet()
• 数据量 > 1亿行：必须上数据库，Python只做结果后处理
• 存在复杂时序逻辑（如漏斗、留存）：Polars的over()窗口和cumcount()比Pandas的rolling()更精准

曾有个客户坚持用Pandas处理20亿行日志，服务器OOM崩溃17次。切换Polars后，单机8核32GB内存稳定运行，且代码行数减少40%——因为Polars的表达式链式调用天然契合多维聚合思维。

3.3 可视化层：让聚合结果不说谎

再完美的聚合，若可视化失真，价值归零。以下是三个反直觉但至关重要的原则：

原则1：禁用默认的“自动缩放Y轴”
BI工具（如Tableau/Power BI）默认开启Y轴自动缩放，导致“华北区GMV 1.2亿”和“西北区GMV 800万”在柱状图中高度差被压缩，视觉上西北区只比华北区矮10%。正确做法：

• 手动设置Y轴最小值为0（强制比例守恒）
• 或用“对数刻度”（当量级差异超100倍时）
• 或改用“相对值”图表（如各区域GMV占全国比重的环形图）

原则2：聚合结果必须携带“置信度标识”
当某维度组合样本量过小时（如“西藏那曲市高端护肤品销量”），直接显示数字会误导决策。我们的解决方案：

• 在报表中增加“数据可靠性”列：CASE WHEN COUNT(*) < 50 THEN 'LOW' WHEN COUNT(*) < 200 THEN 'MEDIUM' ELSE 'HIGH' END
• 对LOW可靠性的数据，前端自动灰显并添加tooltip：“基于47笔订单计算，建议谨慎参考”
• 在仪表盘顶部添加全局提示：“当前视图中，12.3%的数据点可靠性为LOW”

原则3：交互式下钻必须保持聚合一致性
用户点击“华东区”柱子下钻到“上海”，若下钻后显示的上海数据与华东区中上海的数值不一致，信任瞬间崩塌。根源常是：

• 上层用SUM(gmv)，下层用AVG(gmv)（错误）
• 上层过滤status='paid'，下层漏掉该条件（错误）
• 上层用DATE_TRUNC('month', date)，下层用date::DATE（精度不一致）
  我们的强制规范：所有下钻层级共享同一份SQL模板，仅替换WHERE条件中的维度值，确保“所见即所得”。

4. 实战排障手册：从报错信息到根因定位的完整路径

4.1 SQL层典型故障速查表

4.2 Python层调试黄金法则

当Polars/Pandas聚合结果异常，按此顺序排查：

Step 1：验证输入数据质量（占排障时间70%）

# Polars版数据体检 def data_health_check(df: pl.DataFrame): report = [] for col in df.columns: null_pct = df[col].is_null().mean().item() * 100 unique_pct = df[col].n_unique() / len(df) * 100 if null_pct > 5: report.append(f"⚠️ {col}: {null_pct:.1f}% NULL值") if unique_pct < 0.1 and df[col].dtype in [pl.Utf8, pl.Categorical]: report.append(f"⚠️ {col}: 低基数({unique_pct:.1f}%)，检查是否应为维度") return report print(data_health_check(raw_df)) # 输出：⚠️ user_id: 12.3% NULL值；⚠️ product_id: 低基数(0.03%)

真相：83%的“聚合结果不准”问题，根源是输入数据有NULL或脏值。某电商项目中，user_id字段12%为NULL，导致所有用户维度聚合失效。解决方案：在ETL首道工序强制df = df.filter(pl.col("user_id").is_not_null())。

Step 2：检查聚合函数的语义边界

# 错误：用sum()聚合布尔值（True=1, False=0），但业务需要计数 df.select([ pl.col("is_paid").sum().alias("paid_sum"), # 返回1的个数 pl.col("is_paid").sum().over("city").alias("city_paid_sum") # 每城支付订单数 ]) # 正确：明确意图 df.select([ pl.col("is_paid").sum().alias("paid_orders"), # 重命名表明语义 pl.col("is_paid").mean().alias("payment_rate") # 支付率=支付订单/总订单 ])

关键洞察：sum()对布尔值有效，但payment_rate必须是mean()，因为sum()/count()在分组中可能因NULL产生偏差。我在广告归因项目中，因混淆二者导致ROI计算偏差27%。

Step 3：用“分段快照”定位逻辑断点

# 不要一次性跑完，分阶段保存中间结果 step1 = raw_df.filter(pl.col("order_status") == "completed") step1.write_parquet("debug/step1_filtered.parquet") # 保存快照 step2 = step1.group_by(["city", "product_category"]).agg([ pl.sum("gmv").alias("city_cat_gmv"), pl.count().alias("order_count") ]) step2.write_parquet("debug/step2_aggregated.parquet") # 人工检查step2_aggregated.parquet，确认数据量、极值是否合理 # 若异常，回溯step1看过滤条件是否过严

血泪经验：永远保留中间快照！某次线上事故，因filter()条件写错，导致聚合在空数据集上运行，返回全0结果。有step1快照，10分钟定位；没有则需重跑2小时ETL。

4.3 跨系统一致性校验：让数据团队不再甩锅

当SQL结果与Python结果不一致，或BI报表与数据库查询不符，按此协议校验：

一致性校验四步法：

1. 锚定基准：选取一个确定性高的维度组合（如WHERE city='北京' AND product_category='手机' AND stat_date='2023-10-01'），获取该组合的原始行数、SUM(gmv)、COUNT(*)
2. 逐层剥离：
   • 检查ETL脚本中该WHERE条件是否被修改（如stat_date被转成DATE_TRUNC）
   • 检查BI连接器是否启用“自动类型转换”（把INT转成FLOAT导致精度丢失）
   • 检查缓存机制（BI是否读取了过期的物化视图）
3. 二分法隔离：
   • 若SQL与Python不一致：用SELECT * FROM table WHERE ... LIMIT 1000导出样本，分别在SQL和Python中运行，对比结果
   • 若SQL与BI不一致：在BI中导出“原始数据”（非聚合后数据），用SQLSELECT * FROM table WHERE ...对比
4. 终极验证：用MD5(CONCAT(city, '_', product_category, '_', SUM(gmv)))生成校验码，三方比对

我们为某车企搭建的数据质量平台，强制所有关键报表执行此协议，将跨系统数据不一致投诉从每月23起降至0。核心是：不争论“谁错了”，只验证“哪里断了”。

5. 高阶实践：构建可持续演进的多维聚合体系

5.1 维度建模的工业化落地

手工写SQL终将失控。我们为中大型企业设计的维度建模流水线：

阶段1：维度字典自动化
用Python脚本扫描所有业务表，自动生成维度字典：

# 扫描sales_fact表，识别维度候选 from sqlalchemy import create_engine engine = create_engine("...") # 获取表结构 meta = engine.execute("SELECT column_name, data_type FROM information_schema.columns WHERE table_name='sales_fact'") dims = [] for col in meta: if col.data_type in ['character varying', 'text', 'integer'] and col.column_name not in ['amount', 'quantity']: # 检查该列是否符合维度特征（高基数、低变化率） distinct_ratio = engine.execute(f"SELECT COUNT(DISTINCT {col.column_name}) * 1.0 / COUNT(*) FROM sales_fact").scalar() if distinct_ratio > 0.01: # 基数门槛 dims.append(col.column_name) # 输出维度字典Markdown with open("dim_dict.md", "w") as f: f.write("| 维度名 | 类型 | 基数 | 示例值 | 业务含义 |\n|---|---|---|---|---|\n") for d in dims: sample = engine.execute(f"SELECT {d} FROM sales_fact LIMIT 3").fetchall() f.write(f"| {d} | {col.data_type} | {distinct_ratio:.2%} | {sample} | 请填写 |\n")

产出物：dim_dict.md供业务方评审，确保“省份”“城市”等维度定义无歧义。

阶段2：SQL模板引擎
用Jinja2构建参数化SQL模板：

{%- set dimensions = ["city", "product_category", "channel"] -%} {%- set measures = ["SUM(gmv) as total_gmv", "COUNT(*) as order_count"] -%} SELECT {% for d in dimensions %}{{ d }},{% endfor %} {% for m in measures %}{{ m }}{% if not loop.last %},{% endif %}{% endfor %} FROM {{ source_table }} WHERE {{ filter_condition }} GROUP BY {% for d in dimensions %}{{ d }}{% if not loop.last %},{% endif %}{% endfor %} {% if with_rollup %}WITH ROLLUP{% endif %}

运维时只需配置JSON：

{ "source_table": "sales_fact", "filter_condition": "stat_date >= '2023-01-01'", "dimensions": ["province", "quarter"], "with_rollup": true }

自动生成SQL，杜绝手工拼接错误。

阶段3：聚合结果版本管理
用DVC（Data Version Control）管理聚合结果：

# 生成聚合结果 polars_script.py --config prod_config.yaml > aggregated_v1.parquet # 版本化 dvc add aggregated_v1.parquet git commit -m "v1: Sales aggregation for Q3 2023"

当业务