多维聚合实战：用PostgreSQL+Python构建高性能数据立方体

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

你有没有遇到过这样的场景：销售部门要按季度、按产品线、按区域，同时看销售额、毛利、退货率三个指标；运营团队需要对比上周、上月、去年同期的用户活跃度、留存率、付费转化率，还要区分新老用户和不同渠道来源；甚至一个简单的库存报表，也得交叉呈现“仓库A的SKU#123在Q3的在库量 vs 调拨出库量 vs 预售锁定量”。这时候，Excel里的SUMIFS函数开始卡顿，SQL的GROUP BY嵌套三层后连自己都看不懂，而原始数据表里那几百万行记录，仿佛在嘲笑你“维度太多，无力聚合”。这正是Multi-Dimensional Aggregation（多维聚合）的真实战场——它不是简单的“求和”或“计数”，而是把数据当成一块可任意切片、旋转、钻取的立方体，而Data Manipulation（数据操作）就是那把精准的手术刀。本篇聚焦的“Part 20”，绝非教科书里抽象的理论章节，而是我在为一家连锁零售企业搭建BI看板时，被逼到墙角后亲手打磨出的一套实操方法论。它解决的核心问题非常具体：如何在不拖垮查询性能、不牺牲分析灵活性的前提下，让业务人员能像转动魔方一样，自由组合时间、地理、商品、客户四大主维度，实时查看任意交叉组合下的核心KPI。适合谁？如果你正被Pandas的pivot_table搞晕、被SQL的CUBE/ROLLUP绕晕、或者刚接触DAX却对CALCULATE函数的上下文流转一头雾水，这篇就是为你写的。它不讲“是什么”，只讲“怎么拧开这个螺丝”，以及“为什么必须这样拧”。

2. 多维聚合的本质与设计思路：从“平面报表”到“数据立方体”的思维跃迁

2.1 为什么传统单维聚合在这里会彻底失效？

先说个血泪教训。项目初期，我们用最朴素的SQL写法：SELECT region, product_line, quarter, SUM(sales), AVG(margin) FROM sales GROUP BY region, product_line, quarter。逻辑清晰，结果正确。但当业务方第一次提出需求：“给我看华东区所有产品线在Q3的销售额，再叠加显示华东区整体、所有产品线整体、Q3整体，最后还要有个总计”——也就是一个标准的“全维度汇总”时，我们的SQL瞬间膨胀成12个UNION ALL子句，执行时间从0.8秒飙到14秒。更致命的是，当他们第二天追加一句“再加个客户等级维度”时，组合爆炸直接让查询超时。问题根源在于，单维GROUP BY是线性思维，而业务分析是网状思维。你无法预判用户下一次想拉哪几个维度组合，硬编码所有可能组合等于给数据库埋雷。

提示：多维聚合的底层数学模型是“超立方体（Hypercube）”。一个包含N个维度、每个维度有M个成员的数据集，其潜在的聚合单元数量是M^N。当N=5（时间、区域、产品、渠道、客户），M平均为10时，理论单元数已达10万。传统SQL逐条计算，本质是在暴力穷举这个空间。

2.2 核心设计原则：预计算 + 懒加载 + 上下文感知

我们最终放弃“每次查询都现场算”的幻想，转向一套分层设计：

• 第一层：原子事实表（Atomic Fact Table）
  这是所有聚合的基石。我们重构了原始销售流水表，确保每一行代表一个不可再分的业务事件（如：2023-07-15，华东-上海-徐汇店，SKU#A001，客户等级VIP，销售额299.00元）。关键点在于：所有维度字段必须是离散的、低基数的ID（如region_id=5，而非region_name='华东'），且严格遵循星型模型规范。这步看似繁琐，却为后续所有操作扫清障碍——ID比字符串JOIN快3倍以上，且天然支持位图索引。

• 第二层：预聚合立方体（Pre-aggregated Cube）
  我们没有用商业OLAP工具，而是用Python+PostgreSQL构建了一个轻量级立方体。核心策略是：只预计算高频、稳定、计算代价高的聚合，而非全部组合。例如，我们预计算了“时间+区域+产品线”三级组合的销售额总和与订单数，因为这是日报/周报的绝对刚需；但“时间+客户等级+渠道”的组合则保留为实时计算，因其使用频率低且计算快。这里的关键决策依据是：聚合粒度越粗，存储成本越低，但灵活性越差；粒度越细，存储爆炸，但响应极快。我们通过分析过去3个月的BI查询日志，锁定了TOP 15的维度组合，仅对它们做物化视图（Materialized View）固化。

• 第三层：运行时动态操纵（Runtime Manipulation）
  这才是“Part 20”的灵魂。当用户在前端选择“区域=华东”、“时间=Q3”、“产品线=大家电”时，系统并不去查预聚合表，而是：

  1. 识别过滤上下文：将用户选择转化为WHERE条件（WHERE region_id IN (1,2,3) AND quarter='2023-Q3' AND product_line_id=7）；
  2. 智能路由查询：若该组合恰好命中某个预聚合物化视图，则直接读取；否则，自动降级到原子事实表，但利用PostgreSQL的BRIN索引（针对时间字段）和位图索引（针对region_id/product_line_id）加速扫描；
  3. 注入计算逻辑：所有KPI（如毛利率=SUM(gross_profit)/SUM(sales)）均以SQL表达式形式注入，而非预先存为字段，确保计算逻辑始终与业务规则同步。

这套设计的精妙之处在于：它把“计算”这个重活，拆解成“预计算”（离线、省资源）、“索引加速”（在线、省时间）、“表达式注入”（灵活、保一致）三步，彻底规避了维度爆炸的陷阱。

2.3 工具链选型：为什么不用Power BI或Tableau的内置聚合？

坦白说，我们试过。Power BI的DirectQuery模式在千万级事实表上，一个简单切片就卡顿；Tableau的Extract虽然快，但数据更新延迟高达2小时，无法满足运营团队“分钟级监控库存周转”的需求。最终我们选择PostgreSQL 15 + Python（Pandas/Dask） + 自研API层，原因很务实：

• PostgreSQL的物化视图支持REFRESH CONCURRENTLY，更新时不影响查询；
• 其窗口函数（如SUM() OVER (PARTITION BY ...)）和FILTER子句（COUNT(*) FILTER (WHERE status='paid')）能优雅实现复杂KPI；
• Python作为胶水层，能无缝衔接ETL、模型训练（后续要加预测功能）和API服务。
  这不是技术炫技，而是业务SLA倒逼出的选择：要求99.5%的查询响应<1.5秒，且数据从产生到可查延迟<30秒。

3. 核心数据操作技术详解：从“切片”到“钻取”的七种武器

3.1 切片（Slicing）：最基础却最易被忽视的精准过滤

切片是固定一个维度的值，观察其他维度的变化。例如，“固定时间=Q3，看各区域销售额”。很多人以为这只是加个WHERE条件，但实操中陷阱重重。我们曾因一个疏忽导致全公司看板数据错误三天：

• 问题：业务方要求“Q3”包含7月1日至9月30日，但数据库里订单日期是order_date（下单日），而财务确认收入是revenue_date（确认日）。两个日期在促销季可能跨月。
• 解决方案：在原子事实表中，强制增加reporting_period字段，并在ETL时根据业务规则精确赋值。例如，所有7月1日-9月30日下单、且在9月30日前确认收入的订单，reporting_period='2023-Q3'。这样，切片永远基于单一、权威的reporting_period字段，杜绝歧义。
• 代码实操（PostgreSQL物化视图）：

  CREATE MATERIALIZED VIEW mv_sales_q3_region AS SELECT region_id, SUM(sales_amount) AS total_sales, COUNT(DISTINCT order_id) AS order_count, AVG(margin_rate) AS avg_margin FROM fact_sales WHERE reporting_period = '2023-Q3' -- 关键：唯一可信源 GROUP BY region_id; REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales_q3_region;

3.2 切块（Dicing）：多维度的联合过滤，性能杀手的克星

切块是同时固定多个维度的值，如“华东区+大家电+Q3”。这正是传统SQL最脆弱的环节。我们的优化核心是复合索引 + 位图索引协同：

• 在fact_sales表上创建复合索引：CREATE INDEX idx_region_product_q ON fact_sales (region_id, product_line_id, reporting_period);
• 对高基数但低选择率的字段（如customer_id）创建位图索引：CREATE INDEX idx_customer_bitmap ON fact_sales USING bitmap (customer_id);
• 原理：复合索引快速定位“华东+大家电+Q3”的数据块起始位置；位图索引则用内存中的位向量（0/1）高效标记哪些行满足额外条件（如customer_level='VIP'），再与主索引结果做位运算（AND），速度远超传统B-tree索引的逐行扫描。实测在1200万行数据上，切块查询从8.2秒降至0.37秒。

3.3 旋转（Pivoting）：把行变列，让对比一目了然

业务最爱问：“今年Q3 vs 去年Q3，销售额涨了多少？” 这需要将时间维度“旋转”为列。Pandas的pivot_table虽方便，但在大数据量下内存溢出。我们改用SQL的crosstab扩展（需安装tablefunc）：

-- 需先启用扩展 CREATE EXTENSION IF NOT EXISTS tablefunc; -- 生成对比表：行=区域，列=年份，值=Q3销售额 SELECT * FROM crosstab( 'SELECT region_id, EXTRACT(YEAR FROM revenue_date) AS year, SUM(sales_amount) FROM fact_sales WHERE EXTRACT(QUARTER FROM revenue_date) = 3 GROUP BY region_id, year ORDER BY 1,2', 'SELECT DISTINCT EXTRACT(YEAR FROM revenue_date) FROM fact_sales WHERE EXTRACT(QUARTER FROM revenue_date) = 3 ORDER BY 1' ) AS ct(region_id int, "2022" numeric, "2023" numeric);

关键技巧：crosstab要求输入SQL必须严格按rowid, category, value三列排序。我们用EXTRACT(YEAR...)确保年份是数字，避免字符串排序错误（如"2022"排在"2023"后）。

3.4 钻取（Drill-down）与上卷（Roll-up）：维度层级的自由穿梭

这是多维分析的灵魂。例如，从“全国销售额”钻取到“华东销售额”，再钻取到“上海销售额”。这依赖维度表的层级结构。我们为dim_region表设计了严格父-子关系：

• 上卷（Roll-up）：用递归CTE向上聚合。查询“华东”时，自动包含其下所有子区域（上海、南京等）：

  WITH RECURSIVE region_tree AS ( SELECT region_id, parent_id, level FROM dim_region WHERE region_id = 2 -- 华东 UNION ALL SELECT d.region_id, d.parent_id, d.level FROM dim_region d INNER JOIN region_tree r ON d.parent_id = r.region_id ) SELECT SUM(f.sales_amount) FROM fact_sales f INNER JOIN region_tree r ON f.region_id = r.region_id;

• 钻取（Drill-down）：只需在WHERE中指定更细粒度的region_id，如WHERE region_id = 3（上海），无需修改逻辑。

3.5 计算成员（Calculated Members）：KPI的动态生命线

毛利率、复购率、库存周转天数……这些都不是原始字段，而是计算得出。硬编码在SQL里会导致维护地狱。我们的方案是：在API层用Python动态解析计算表达式。

• 前端配置一个JSON：

  { "kpi_code": "gross_margin", "expression": "SUM(gross_profit) / NULLIF(SUM(sales_amount), 0)", "format": "percent" }

• API收到请求后，将expression安全注入SQL模板：

  # 安全校验：只允许白名单函数和字段 allowed_functions = ['SUM', 'AVG', 'COUNT', 'NULLIF'] allowed_fields = ['sales_amount', 'gross_profit', 'order_count'] # ... 校验通过后拼接 sql = f"SELECT {expression} AS value FROM fact_sales WHERE ..."

为什么不用数据库存储过程？因为业务KPI规则变更频繁（如毛利率计算口径从“含税”改为“不含税”），Python配置热更新比改数据库函数快10倍。

3.6 时间智能（Time Intelligence）：让“同比”“环比”不再烧脑

“Q3销售额 vs Q2”、“2023年Q3 vs 2022年Q3”——这类计算最易出错。我们弃用复杂的日期函数，转而在ETL阶段预生成时间代理键（Surrogate Key）：

• 创建dim_date表，每行代表一天，包含：date_key(20230715),year,quarter,month,week_of_year,is_holiday,same_quarter_last_year_key(20220715),same_month_last_year_key(20220715)等。
• 在事实表中，date_key作为外键关联。
• 查询“同比”时，只需JOIN一次：

  SELECT t1.quarter, t1.total_sales AS current_sales, t2.total_sales AS last_year_sales, (t1.total_sales - t2.total_sales) / NULLIF(t2.total_sales, 0) AS yoy_growth FROM mv_sales_by_quarter t1 LEFT JOIN mv_sales_by_quarter t2 ON t1.quarter_key = t2.same_quarter_last_year_key;

实操心得：预生成same_quarter_last_year_key比用DATE_SUB()函数计算快5倍，且结果绝对确定，无时区/闰年等陷阱。

3.7 高级筛选（Advanced Filtering）：超越WHERE的业务逻辑封装

有时需求是“销售额前10的区域”或“毛利率低于15%的产品线”。这已超出简单过滤。我们用窗口函数 + CTE实现：

-- 找出Q3销售额Top 5的区域 WITH ranked_regions AS ( SELECT region_id, SUM(sales_amount) AS total_sales, ROW_NUMBER() OVER (ORDER BY SUM(sales_amount) DESC) AS rn FROM fact_sales WHERE reporting_period = '2023-Q3' GROUP BY region_id ) SELECT region_id, total_sales FROM ranked_regions WHERE rn <= 5;

注意：ROW_NUMBER()保证严格排名（并列时序号不同），RANK()则会并列（如两个第1名，下一个为第3名）。业务需求决定函数选型。

4. 实操全流程：从原始日志到实时看板的12步落地

4.1 步骤1-3：数据建模与ETL准备（耗时：2人日）

1. 梳理业务维度：与业务方闭门3小时，确认四大主维度及其层级。例如，“产品线”下必须有“一级类目”（大家电）、“二级类目”（空调）、“SKU”三级，且明确“空调”属于“大家电”，不可跨级。
2. 设计星型模型：用draw.io画出fact_sales（中心）与dim_time、dim_region、dim_product、dim_customer（四颗星）的关系图，标注所有外键和索引。
3. 编写ETL脚本（Python + Pandas）：
   • 读取原始CSV（含order_date,region_name,product_name等模糊字段）；
   • 用dim_region表的region_name映射region_id（处理“华东”、“华东区”、“East China”等别名）；
   • 计算reporting_period：if order_date between '2023-07-01' and '2023-09-30' and revenue_date <= '2023-09-30': '2023-Q3'；
   • 写入PostgreSQL，开启INSERT ... ON CONFLICT DO NOTHING防重复。

4.2 步骤4-6：预聚合与索引优化（耗时：1人日）

4. 创建物化视图：按查询日志TOP15组合，编写15个CREATE MATERIALIZED VIEW语句。例如：

   CREATE MATERIALIZED VIEW mv_sales_time_region AS SELECT reporting_period, region_id, SUM(sales_amount) AS sales_sum FROM fact_sales GROUP BY reporting_period, region_id;

5. 建立索引矩阵：为每个物化视图创建复合索引。mv_sales_time_region上建(reporting_period, region_id)；mv_sales_product_region上建(product_line_id, region_id)。
6. 设置自动刷新：用PostgreSQL的pg_cron扩展，每15分钟执行REFRESH MATERIALIZED VIEW CONCURRENTLY mv_*。并发刷新确保看板查询不被阻塞。

4.3 步骤7-9：API层开发（耗时：3人日）

7. 定义RESTful接口：GET /api/v1/aggregation?dimensions=region,product&metrics=sales_sum,order_count&filters={"reporting_period":"2023-Q3"}。
8. SQL生成引擎：Python函数接收参数，动态拼接SQL：
   • dimensions→GROUP BY子句；
   • metrics→ 从预定义字典映射SQL表达式（"sales_sum": "SUM(sales_amount)"）；
   • filters→WHERE条件，自动处理IN（多选）和=（单选）。
9. 缓存策略：对完全相同的参数组合，用Redis缓存结果（TTL=60秒），避免重复计算。缓存Key为md5(json.dumps(params))。

4.4 步骤10-12：前端集成与验证（耗时：2人日）

10. 前端组件化：用React开发可复用的DimensionSelector（多选下拉）、MetricCard（KPI卡片）、CrossTabTable（交叉表）。
11. 连接API：在useEffect中调用/api/v1/aggregation，将返回的JSON直接渲染。
12. 全链路压测：用Locust模拟100并发用户，随机切换维度组合。目标：95%请求<1.2秒。实测结果：峰值QPS 87，平均响应980ms，达标。

5. 常见问题与独家排查技巧：那些文档里不会写的坑

5.1 问题1：物化视图刷新时，查询偶尔返回空结果

• 现象：REFRESH MATERIALIZED VIEW执行中，前端看板突然空白1-2秒。
• 根因：PostgreSQL物化视图刷新是“先删后插”，中间存在短暂真空期。
• 解决方案：永远使用REFRESH CONCURRENTLY（需有唯一索引）。它通过创建新版本、原子切换指针实现零停机。我们最初漏建唯一索引，导致此命令报错，被迫用普通REFRESH，酿成事故。
• 避坑技巧：在物化视图上强制添加UNIQUE (dimension1, dimension2)索引。即使业务上不唯一，也可加INCLUDE (id)凑成唯一组合。

5.2 问题2：Pandas pivot_table内存爆满，Jupyter直接崩溃

• 现象：尝试对100万行数据做pivot_table(index='region', columns='quarter', values='sales')，内存飙升至16GB。
• 根因：Pandas默认创建稠密矩阵，即使90%单元格为空，也分配全量内存。
• 解决方案：改用pd.crosstab+sparse=True，或直接放弃Pandas，用SQLcrosstab（如3.3节）。
• 实操心得：pd.crosstab本质是优化过的频次统计，对数值聚合（求和）需配合aggfunc：

  # 安全替代pivot_table result = pd.crosstab( index=df['region'], columns=df['quarter'], values=df['sales'], aggfunc='sum', # 指定聚合函数 dropna=False )

5.3 问题3：时间智能计算结果与Excel手工核对不上

• 现象：“2023-Q3 vs 2022-Q3”增长率为12.3%，但财务部Excel算出来是11.8%。
• 根因：数据库revenue_date是UTC时间，而业务方要求按本地时区（CST）计算。原始数据未转换时区。
• 解决方案：在ETL阶段统一转换。PostgreSQL中：

  -- 将UTC时间转为CST（UTC+8） ALTER TABLE fact_sales ADD COLUMN revenue_date_cst DATE; UPDATE fact_sales SET revenue_date_cst = (revenue_date AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai')::DATE;

  后续所有时间维度均基于revenue_date_cst计算。
• 经验：时区问题必须在数据入仓第一步解决，后期修正成本极高。

5.4 问题4：高级筛选（如Top N）在物化视图上失效

• 现象：mv_sales_time_region里只有reporting_period和region_id，无法直接做“Top 5区域”，因为缺少SUM(sales)的聚合值供排序。
• 根因：物化视图是预聚合结果，但Top N需要对聚合值再排序，属于二次计算。
• 解决方案：物化视图必须包含用于排序的度量值。修改视图：

  CREATE MATERIALIZED VIEW mv_sales_time_region AS SELECT reporting_period, region_id, SUM(sales_amount) AS sales_sum, -- 必须包含此字段！ COUNT(*) AS order_count FROM fact_sales GROUP BY reporting_period, region_id;

  然后查询时：SELECT * FROM mv_sales_time_region WHERE reporting_period='2023-Q3' ORDER BY sales_sum DESC LIMIT 5;
• 关键提醒：物化视图不是“懒人包”，设计时就要预判所有可能的二次操作（排序、过滤、分页）所需字段。

5.5 问题5：维度值中文乱码，前端显示“???”

• 现象：dim_region.region_name在数据库里是“华东”，但API返回JSON里变成“???”。
• 根因：PostgreSQL数据库编码为UTF8，但Python连接时未指定client_encoding='utf8'，导致驱动用默认latin1解码。
• 解决方案：在psycopg2.connect()中显式声明：

  conn = psycopg2.connect( host="localhost", database="dw", user="user", password="pass", client_encoding='utf8' # 关键！ )

• 终极检查清单：数据库编码（SHOW SERVER_ENCODING;）、客户端编码（SHOW CLIENT_ENCODING;）、连接字符串参数、前端HTML<meta charset="UTF-8">，四者必须全为UTF8。

6. 性能调优实战：从“能跑”到“飞一般”的5个关键参数

6.1 PostgreSQL配置：不只是shared_buffers

我们调优的5个核心参数，均来自生产环境实测（128GB内存服务器）：

注意：work_mem是每个操作（如一个ORDER BY）的内存上限，非全局。设太高会导致并发高时内存耗尽。我们按最大并发50计算：50 * 256MB = 12.8GB < 总内存128GB，安全。

6.2 索引策略：不止是“加索引”，而是“加对索引”

• BRIN索引：专为大表、有序字段（如revenue_date）设计。CREATE INDEX idx_date_brin ON fact_sales USING BRIN (revenue_date);占用空间仅B-tree的1/20，对范围查询（WHERE revenue_date BETWEEN '2023-07-01' AND '2023-09-30'）性能相当。
• 部分索引：只为高频查询子集建索引。例如，90%查询只看近2年的数据：CREATE INDEX idx_recent_sales ON fact_sales (region_id, product_line_id) WHERE revenue_date >= '2022-01-01';
• 覆盖索引：让索引包含查询所需所有字段，避免回表。CREATE INDEX idx_covering ON fact_sales (reporting_period, region_id) INCLUDE (sales_amount, order_id);

6.3 查询重写：一行SQL的威力

一个经典案例：业务要“各区域Q3销售额，排除退货订单”。原始SQL：

SELECT region_id, SUM(sales_amount) FROM fact_sales WHERE reporting_period = '2023-Q3' AND order_status != 'returned' GROUP BY region_id;

问题：order_status选择率低（仅1%退货），B-tree索引效果差，全表扫描慢。
重写为：

SELECT region_id, SUM(sales_amount) FROM fact_sales WHERE reporting_period = '2023-Q3' AND order_id NOT IN (SELECT order_id FROM fact_sales WHERE order_status = 'returned') GROUP BY region_id;

原理：利用order_id的主键索引（极快），先找出所有退货订单ID，再用NOT IN高效排除。实测从11.4秒降至0.89秒。
注意：NOT IN对NULL敏感，确保子查询order_id无NULL。

6.4 并发控制：让100个用户同时刷看板也不卡

• 连接池：用pgbouncer（Transaction Pooling模式），将应用连接数限制在20，数据库实际连接数恒为20，避免连接风暴。
• 查询超时：在API层设置statement_timeout=5000（5秒），超时自动中断，防止一个慢查询拖垮整个服务。
• 优先级队列：对/api/v1/aggregation接口，用Nginx限流limit_req zone=aggr burst=10 nodelay;，确保突发流量被平滑处理。

6.5 监控告警：让问题在用户投诉前暴露

• 关键指标监控（用Prometheus + Grafana）：
  • pg_stat_database.blks_read：每秒磁盘块读取数，突增说明索引失效；
  • pg_stat_activity.state：active连接数持续>50，触发告警；
  • 自定义指标：mv_refresh_duration_seconds{view="mv_sales_time_region"}，超过300秒告警。
• 日志分析：用ELK收集PostgreSQL日志，设置告警规则：log_level: "ERROR" AND message: "canceling statement due to statement timeout"，即刻通知DBA。

7. 经验总结：多维聚合不是技术，而是业务语言的翻译器

做完这个项目，我最大的体会是：技术方案的成败，80%取决于对业务逻辑的敬畏，而非代码的精巧。我们曾花整整一周，就为了确认“Q3”的起止日期——财务部按自然季度（7-9月），而运营部按财年季度（假设财年从4月开始，则Q3是10-12月）。一个日期定义的分歧，能让所有聚合结果归零。所以，我的第一条铁律是：所有维度、所有KPI、所有时间周期，必须有且仅有一个业务方签字确认的《数据字典V1.0》，它比任何代码都重要。

第二条心得：不要迷信“全自动化”。我们曾试图用AI自动发现维度关系，结果把“客户等级”和“会员积分”错误关联，导致复购率计算失真。后来回归笨办法：让业务方手动画出维度关系图，工程师照着实现。慢，但准。

第三条，也是最反直觉的：有时候，不优化才是最好的优化。当业务方第一次提出“按小时看销售额”时，我们本能想加hour_of_day维度。但深入聊后发现，他们真正需要的是“促销活动期间的分钟级监控”，而非全年每小时数据。于是我们单独建了一个轻量级fact_promotion_realtime表，只存活动期间数据，用TimescaleDB（时序数据库）存储，查询快如闪电。为1%的需求，不必拖累99%的架构。

最后分享一个小技巧：在API返回的JSON里，强制加入_debug字段，包含本次查询的真实SQL、执行时间、扫描行数。业务方看到"execution_time_ms": 1245, "rows_scanned": 842312，立刻明白为何这个组合慢——不是系统不行，是数据量太大。信任，往往始于透明。

这个“Part 20”，不是终点，而是起点。下一站，我们正把这套多维聚合能力，封装成SDK，让业务方自己的Python脚本也能调用aggregation.query(dimensions=['region'], metrics=['sales_sum'])。真正的数据民主化，不是给他们一个BI工具，而是给他们一把能自己锻造工具的锤子。