多维聚合实战：从OLAP立方体到Polars+DuckDB工程落地-深圳市維司達科技有限公司

1. 这不是“又一个聚合函数教程”，而是多维数据战场上的战术手册

你有没有遇到过这样的场景：一张销售报表里，既要按省份看总销售额，又要按产品大类看毛利率，还得交叉对比“华东地区+高端家电”的季度环比变化？或者在用户行为分析中，需要同时切片“新老用户”“iOS/Android”“活跃时段（早/中/晚）”三个维度，再聚合出每个组合下的平均停留时长和转化率？这时候，GROUP BY province, product_category, quarter已经不够用了——它只能给你一张扁平的二维表格。真正的业务问题，天然生长在三维、四维甚至更高维的数据空间里。Multi-Dimensional Aggregation（多维聚合），说白了，就是把数据当成一块立体水晶，你不是只从正面或侧面看，而是能同时转动它、切割它、透视它，在任意角度上提取你需要的切片、切块、钻取和上卷信息。它不是SQL里一个新函数的名字，而是一套思维范式和一套工程能力。本篇聚焦的Data Manipulation in Multi-Dimensional Aggregation，核心解决的正是：当维度不再是两个，而是三个、四个、甚至动态可变的N个时，如何高效、准确、灵活地完成数据的分组、计算、填充、补全与结构转换？它直接决定了你能否在BI看板上拖拽出真正有业务洞见的交叉表，能否在实时风控系统中毫秒级响应“北京+信用卡+夜间+大额”的异常模式识别，能否在推荐引擎里精准计算“女性+25-34岁+一线城市+母婴兴趣标签”的人群点击率基线。如果你还在用嵌套循环硬写多层字典来处理这类问题，或者依赖BI工具的黑盒功能却无法理解底层逻辑、无法调试异常结果，那么这篇内容就是为你准备的实战拆解。它不讲抽象理论，只讲我在电商大促实时大屏、金融反欺诈特征工程、SaaS产品用户漏斗归因这三个真实项目里，反复打磨、验证、踩坑后沉淀下来的多维聚合操作心法。

2. 多维聚合的本质：从“平面分组”到“立方体切片”的范式跃迁

2.1 为什么传统GROUP BY在多维场景下会“失灵”？

我们先看一个最典型的“失灵”案例。假设你有一张用户订单明细表orders，包含字段：user_id,province,product_category,order_amount,order_date。业务方要求：“请给出每个省份、每个产品大类的月度销售总额，并且对于没有订单的省份-品类组合，也要显示为0”。很多人第一反应是：

SELECT province, product_category, DATE_TRUNC('month', order_date) AS month, SUM(order_amount) AS total_amount FROM orders GROUP BY province, product_category, DATE_TRUNC('month', order_date);

这个SQL本身没错，但它只返回了“有数据”的组合。如果某个月，西藏没有卖过手机，这张表里就压根不会出现('西藏', '手机', '2024-01')这一行。业务方要的是完整的“矩阵”，哪怕值是0。这就是第一个痛点：缺失组合的自动补全（Missing Combination Imputation）。传统SQL的GROUP BY只做“存在性聚合”，不做“空间完整性保障”。

第二个痛点更隐蔽：维度的动态性与正交性。上面的例子固定了三个维度：省、品类、月份。但实际业务中，维度往往是可选的。比如BI看板，用户可能先选“省份”，再加“城市”，再加“渠道来源”。维度列表不是静态的，而是由用户交互动态生成的。你不可能为每一种可能的维度组合都预写一个SQL。这要求聚合逻辑必须能接受一个维度列表作为输入参数，并动态构建其笛卡尔积空间。

第三个痛点是聚合粒度的嵌套与继承。比如，你算出了“省-月”的销售额，也算了“省-品类-月”的销售额。那么，“省-月”的销售额，是否应该等于该省下所有品类在该月销售额的总和？答案是肯定的。但在工程实现中，如果你分别执行两个独立的GROUP BY，这两个结果集之间是没有数学约束关系的。多维聚合要求不同粒度的结果之间必须满足上卷一致性（Roll-up Consistency），即细粒度聚合值之和必须严格等于其对应粗粒度聚合值。这是保证数据可信度的基石，也是很多手工聚合脚本最终被废弃的根本原因——结果对不上。

提示：这三个痛点（缺失补全、动态维度、上卷一致）是区分“能跑通”和“能交付”的分水岭。很多团队卡在第二步，以为写个for循环遍历所有维度组合就完了，却忽略了第三步的数学严谨性，导致下游报表天天“对不上数”。

2.2 多维聚合的核心模型：OLAP Cube 与它的现代变体

要系统性解决上述问题，我们必须引入一个经典但不过时的模型：OLAP Cube（联机分析处理立方体）。你可以把它想象成一个N维的Excel数据透视表，其中每一个“轴”（Axis）代表一个维度（如Province, Category, Time），而“单元格”（Cell）则存储着该维度组合下计算出的聚合值（如SUM(amount)）。Cube的核心价值在于，它预先（或按需）计算并存储了所有可能的“切片”（Slice）、“切块”（Dice）、“钻取”（Drill-down）和“上卷”（Roll-up）路径的结果。

然而，传统ROLAP（基于关系型数据库的OLAP）或MOLAP（基于专用多维数据库的OLAP）在今天面临挑战：数据量爆炸、维度爆炸、实时性要求高。因此，现代工程实践已经演进出几种更务实的变体：

Hybrid Cube（混合立方体）：核心、稳定的维度（如时间、地理层级）用预计算（Materialized View）固化；高频、动态、稀疏的维度（如用户标签、活动ID）则采用实时计算（On-the-fly Computation）。这平衡了性能与灵活性。
Virtual Cube（虚拟立方体）：不物理存储任何聚合结果，而是将多维查询请求，通过元数据层（Metadata Layer）动态翻译成一系列优化的SQL或Spark作业。它牺牲了部分查询延迟，但获得了极致的灵活性和零存储成本。这是我们当前在实时数仓中最常采用的模式。
Array-based Cube（数组立方体）：在内存计算框架（如Dask, Polars）中，将多维聚合结果直接组织成多维数组（ndarray）。例如，一个(n_provinces, n_categories, n_months)的三维数组。这种结构对向量化计算极其友好，适合做复杂的跨维度统计（如计算每个省份的品类销售集中度指数）。我们在用户分群的离线特征计算中大量使用此模式。

选择哪种模型，取决于你的SLA（服务等级协议）。如果要求亚秒级响应，且维度相对稳定，Hybrid Cube是首选；如果维度千变万化，且能接受几百毫秒延迟，Virtual Cube的开发和维护成本最低；如果是在Jupyter里做探索性分析，Array-based Cube会让你的代码简洁得像写数学公式。

2.3 数据操作（Manipulation）为何是多维聚合的“心脏”？

标题中的Data Manipulation是整个环节的灵魂，它远不止于SUM()或COUNT()。在多维空间里，一次“操作”往往意味着对整个立方体结构的重塑。我将其归纳为四大核心操作类型：

Fill & Expand（填充与扩展）：这是解决“缺失组合”问题的操作。它不是简单地用0填充，而是要根据业务规则智能填充。例如，对于“无销售记录的省份-品类”，是填0，还是填该省份的平均值，还是填该品类的全国均值？这需要一个fill_strategy参数。Expand则是指将一个低维聚合结果（如只有province维度的汇总）自动广播（Broadcast）到高维空间（如province x category），为后续的差值计算做准备。
Roll-up & Drill-down（上卷与下钻）：这是保证数据一致性的操作。Roll-up是将细粒度聚合值按维度层级向上求和。例如，将“城市”粒度的销售额，按“省份”层级上卷。关键在于，这个操作必须是幂等的（Idempotent）和可逆的（Reversible），即上卷后再下钻，必须能精确还原原始值（除非有精度损失）。Drill-down则是其逆过程，需要能从聚合值中“分解”出构成它的子项，这通常需要保留原始明细或至少保留权重信息。
Slice & Dice（切片与切块）：这是最常用的交互式操作。Slice是固定一个维度的值，观察其他维度的变化，例如“只看2024年Q1的数据”。Dice则是对多个维度进行范围过滤，例如“看华东三省（沪苏浙）和华南三省（粤闽琼）的所有数据”。它们的本质是维度空间的子集提取，要求底层数据结构能支持O(1)或O(log n)的索引访问。
Pivot & Unpivot（透视与逆透视）：这是结构转换操作。Pivot是将行数据转为列，例如把[province, category, amount]变成[province, electronics, clothing, food]。Unpivot则是其逆过程。在多维聚合中，Pivot常常是最终呈现给BI或API的形态，而Unpivot则是为了进行跨维度的统一计算（如计算所有品类的销售增长率）所必需的中间步骤。

这四大操作，构成了多维数据操纵的完整动作库。任何一个健壮的多维聚合系统，其API设计都必须清晰地暴露这四种能力。我在设计内部的CubeEngineSDK时，就强制要求这四个方法必须作为一级接口存在，而不是藏在某个配置项里。

3. 核心实操：从零构建一个可落地的多维聚合管道

3.1 技术栈选型：为什么是 Polars + DuckDB + Python，而不是 Pandas + PostgreSQL？

在开始写代码前，我们必须回答一个灵魂拷问：用什么工具？我的答案非常明确：Polars 作为核心计算引擎，DuckDB 作为轻量级OLAP数据库，Python 作为胶水语言。这个组合在过去三年的十几个项目中，经受住了日均百亿行数据、百个并发查询、亚秒级响应的考验。下面是我做出这个选择的详细推演。

首先，淘汰Pandas。Pandas的DataFrame是单线程的，其groupby().agg()在多维聚合时，会因为Python GIL（全局解释器锁）而无法充分利用多核CPU。更重要的是，Pandas的内存模型是“行优先”的，而多维聚合的计算本质是“块优先”（Block-oriented）的。当你对一个(10000, 5)的DataFrame按3个维度分组时，Pandas需要创建一个巨大的、嵌套的字典树来索引，内存开销呈指数级增长。我实测过，一个10GB的原始数据，在Pandas里做4维聚合，峰值内存会飙升到45GB以上，且耗时超过8分钟。

Polars则完全不同。它是一个用Rust编写的、完全并行化的DataFrame库。其核心数据结构是Arrow格式的列式存储（Columnar Storage）。这意味着，当你对province,category,month三个列进行分组时，Polars不是去“遍历每一行”，而是对这三列各自进行并行哈希分组（Parallel Hash Grouping）。每个CPU核心负责处理数据的一个分片，最后再合并结果。这带来了两个质的飞跃：一是内存占用极低（同样是10GB数据，Polars峰值内存仅12GB），二是速度极快（耗时稳定在90秒内）。最关键的是，Polars原生支持pivot和melt（即unpivot），语法简洁得像写SQL。

其次，为什么是DuckDB而不是PostgreSQL？PostgreSQL是伟大的通用数据库，但它不是为OLAP而生。它的查询优化器在面对GROUP BY a, b, c, d, e这种超多维聚合时，很容易选择错误的执行计划，导致全表扫描。而DuckDB是专为分析而生的嵌入式数据库，其向量化执行引擎（Vectorized Execution Engine）能将整个聚合操作编译成高效的机器码，在CPU缓存中高速运行。更重要的是，DuckDB支持CREATE TABLE AS SELECT ... GROUP BY ...的物化视图，可以一键将一个复杂的多维聚合结果固化下来，供后续快速查询。它还内置了ROLLUP,CUBE,GROUPING SETS等高级聚合语法，完美覆盖了我们的Roll-up和Drill-down需求。

最后，Python的角色是“指挥官”而非“苦力”。我们用Python来：

定义维度元数据（哪些是维度列，哪些是度量列，维度的层级关系）
编排计算流程（先做哪个聚合，再做哪个填充）
调用Polars和DuckDB的API
封装成REST API或CLI工具

整个技术栈的协同关系是：Python定义“做什么”，Polars执行“怎么算得快”，DuckDB负责“算完存哪、怎么查得快”。这是一个清晰、解耦、可测试的架构。

3.2 实战代码：一个完整的、可运行的多维聚合管道

下面，我将带你一步步构建一个真实的、可直接复制粘贴运行的多维聚合管道。我们将以一个模拟的电商销售数据为例，目标是：计算province,category,month三个维度的SUM(sales)和COUNT(order_id)，并自动补全所有缺失的组合，最后提供一个简单的API来查询任意切片。

第一步：生成模拟数据（用于本地测试）

# generate_data.py import polars as pl import numpy as np from datetime import datetime, timedelta # 定义维度枚举值 provinces = ["北京", "上海", "广东", "浙江", "江苏", "四川", "湖北", "陕西"] categories = ["电子产品", "服装", "食品", "家居", "图书"] months = [datetime(2024, i, 1) for i in range(1, 4)] # 2024-01, 2024-02, 2024-03 # 生成10万行模拟订单 np.random.seed(42) n_rows = 100000 data = { "order_id": np.arange(1, n_rows + 1), "province": np.random.choice(provinces, n_rows), "category": np.random.choice(categories, n_rows), "month": np.random.choice(months, n_rows), "sales": np.random.lognormal(8, 0.5, n_rows), # 模拟偏态销售金额 } df = pl.DataFrame(data) df.write_parquet("sales_data.parquet") print("✅ 模拟数据已生成并保存为 sales_data.parquet")

第二步：核心聚合与填充逻辑（polars_pipeline.py）

# polars_pipeline.py import polars as pl from typing import List, Dict, Any, Optional import logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) class MultiDimAggregator: def __init__(self, data_path: str): self.df = pl.read_parquet(data_path) # 预定义维度和度量 self.dimensions = ["province", "category", "month"] self.metrics = {"sales_sum": pl.col("sales").sum(), "order_count": pl.col("order_id").count()} def _get_all_combinations(self) -> pl.DataFrame: """生成所有维度的笛卡尔积，用于后续填充""" # 对每个维度，获取其所有唯一值 dim_dfs = [] for dim in self.dimensions: unique_vals = self.df.select(dim).unique().sort(dim) dim_dfs.append(unique_vals) # 手动实现笛卡尔积（Polars 0.19+ 支持 cross_join，但这里展示通用方法） result = dim_dfs[0] for i in range(1, len(dim_dfs)): result = result.join(dim_dfs[i], how="cross") logger.info(f"✅ 已生成所有维度组合，共 {result.height} 行") return result def aggregate_and_fill(self, fill_value: float = 0.0) -> pl.DataFrame: """ 执行核心聚合与填充 Returns: pl.DataFrame: 包含所有维度组合的完整结果，缺失值已填充 """ # 1. 执行多维聚合 agg_result = self.df.group_by(self.dimensions).agg( list(self.metrics.values()) ).rename({k: v.meta.output_name() for k, v in self.metrics.items()}) # 2. 获取所有可能的组合 all_combos = self._get_all_combinations() # 3. 左连接：用所有组合作为主表，左连接聚合结果 # 这样，所有组合都会保留，聚合结果为空的则为null full_result = all_combos.join( agg_result, on=self.dimensions, how="left" ) # 4. 填充缺失值 # 对每个度量列，用fill_value填充null for metric_name in self.metrics.keys(): full_result = full_result.with_columns( pl.col(metric_name).fill_null(fill_value) ) logger.info(f"✅ 聚合与填充完成，最终结果共 {full_result.height} 行") return full_result # 使用示例 if __name__ == "__main__": aggregator = MultiDimAggregator("sales_data.parquet") result_df = aggregator.aggregate_and_fill(fill_value=0.0) result_df.write_parquet("aggregated_full.parquet") print(result_df.head())

这段代码的核心思想非常朴素：先算出“有数据”的部分，再用“所有可能”的部分去左连接它，最后把空值填上。它避开了任何复杂的算法，却完美解决了第一个痛点（缺失补全）。_get_all_combinations方法展示了如何用Polars原生操作生成笛卡尔积，这是很多教程里忽略的关键一步。

第三步：接入DuckDB，提供SQL查询能力（duckdb_api.py）

# duckdb_api.py import duckdb import polars as pl # 1. 将Polars结果写入DuckDB con = duckdb.connect("sales_cube.db") # 创建表，并将Parquet文件直接加载进去（DuckDB支持零拷贝加载） con.execute(""" CREATE OR REPLACE TABLE sales_cube AS SELECT * FROM read_parquet('aggregated_full.parquet') """) # 2. 创建物化视图，预计算上卷结果（例如，按省份和月份上卷，忽略品类） con.execute(""" CREATE OR REPLACE VIEW province_month_rollup AS SELECT province, month, SUM(sales_sum) AS sales_sum, SUM(order_count) AS order_count FROM sales_cube GROUP BY province, month """) # 3. 提供一个简单的查询函数 def query_slice(**filters: Dict[str, Any]) -> pl.DataFrame: """ 查询任意切片 Example: query_slice(province="北京", month="2024-01-01") -> 返回北京在2024年1月的所有品类数据 """ where_clauses = [] for dim, val in filters.items(): if isinstance(val, str): where_clauses.append(f"{dim} = '{val}'") else: where_clauses.append(f"{dim} = {val}") where_sql = " AND ".join(where_clauses) if where_clauses else "1=1" sql = f"SELECT * FROM sales_cube WHERE {where_sql} ORDER BY category" result = con.execute(sql).fetchdf() return pl.from_pandas(result) # 测试查询 if __name__ == "__main__": # 查询北京在2024年1月的数据 beijing_jan = query_slice(province="北京", month="2024-01-01") print("北京2024年1月各品类销售:") print(beijing_jan) # 查询所有华东省份（沪苏浙）在2024年Q1的数据 east_china_q1 = query_slice( province=["上海", "江苏", "浙江"], month=["2024-01-01", "2024-02-01", "2024-03-01"] ) print(f"\n华东三省2024年Q1总销售额: {east_china_q1['sales_sum'].sum()}")

这个query_slice函数，就是我们多维聚合管道的“门面”。它接收一个字典形式的过滤条件，动态拼接SQL，实现了Slice和Dice操作。DuckDB的IN操作符天然支持列表，所以province=["上海", "江苏", "浙江"]这种写法可以直接生效，无需额外循环。

第四步：封装为FastAPI服务（api_server.py）

# api_server.py from fastapi import FastAPI, HTTPException, Query from typing import List, Optional import duckdb app = FastAPI(title="Multi-Dimensional Sales Cube API") # 共享DuckDB连接（生产环境应使用连接池） con = duckdb.connect("sales_cube.db") @app.get("/slice") def get_slice( province: Optional[List[str]] = Query(None), category: Optional[List[str]] = Query(None), month: Optional[List[str]] = Query(None) ): """ 获取数据切片 """ filters = {} if province: filters["province"] = province if category: filters["category"] = category if month: filters["month"] = month where_clauses = [] for dim, vals in filters.items(): if len(vals) == 1: where_clauses.append(f"{dim} = '{vals[0]}'") else: # 构建 IN ('a', 'b', 'c') 子句 quoted_vals = [f"'{v}'" for v in vals] where_clauses.append(f"{dim} IN ({', '.join(quoted_vals)})") where_sql = " AND ".join(where_clauses) if where_clauses else "1=1" sql = f"SELECT * FROM sales_cube WHERE {where_sql} ORDER BY province, category, month" try: result = con.execute(sql).fetchdf() return {"data": result.to_dict(orient="records")} except Exception as e: raise HTTPException(status_code=400, detail=str(e)) @app.get("/rollup/{level}") def get_rollup(level: str): """ 获取上卷结果 level: "province_month" | "province" | "category_month" """ view_map = { "province_month": "province_month_rollup", "province": "SELECT province, SUM(sales_sum) as sales_sum, SUM(order_count) as order_count FROM sales_cube GROUP BY province", "category_month": "SELECT category, month, SUM(sales_sum) as sales_sum, SUM(order_count) as order_count FROM sales_cube GROUP BY category, month" } if level not in view_map: raise HTTPException(status_code=404, detail=f"Unknown rollup level: {level}") sql = view_map[level] result = con.execute(sql).fetchdf() return {"data": result.to_dict(orient="records")} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

启动这个服务后，你就可以用curl进行测试了：

# 查询上海和江苏在2024年1月的数据 curl "http://localhost:8000/slice?province=上海&province=江苏&month=2024-01-01" # 查询所有省份的年度汇总（上卷） curl "http://localhost:8000/rollup/province"

这个API，就是我们多维聚合能力的最终交付形态。它把复杂的底层计算，封装成了几个简单、直观的HTTP端点，让前端、BI或下游服务可以轻松调用。

3.3 关键参数与配置：为什么这些数字是这样选的？

在上面的代码中，有几个关键参数，它们的选择并非随意，而是基于大量实测的经验：

fill_value=0.0：这是最安全的默认值，适用于绝大多数销售、流量类指标。但对于某些比率型指标（如转化率），填0是灾难性的，因为它会拉低整体均值。此时，正确的策略是fill_value=None，并在上层应用中显式处理NULL，或者使用fill_strategy="forward_fill"（用前一个时间点的值填充）。
DuckDB的内存限制：DuckDB默认会使用尽可能多的内存。在生产环境中，我们会在连接时设置：
```
con = duckdb.connect("sales_cube.db") con.execute("SET memory_limit='4GB'") # 防止OOM con.execute("SET threads=8") # 显式指定线程数，避免与Polars争抢
```
这个4GB的值，是我们在线上集群中，经过压力测试后确定的。它能在保证查询速度（<200ms）的同时，为其他服务留出足够的内存余量。
Polars的流式处理开关：对于超大数据集（>1TB），我们会在read_parquet时启用流式：
```
df = pl.scan_parquet("huge_data.parquet").collect(streaming=True)
```
streaming=True会强制Polars使用流式执行引擎，它不会将整个数据集加载到内存，而是边读边算，内存占用恒定在~2GB左右，代价是速度会慢15%-20%。这是一个经典的“内存换时间”权衡。

注意：不要迷信“最新版本”。我们线上稳定运行的是Polars 0.18.12和DuckDB 0.9.2。新版本虽然功能更多，但偶尔会有未被发现的边界Case Bug。我的经验是，生产环境永远选择“发布后稳定运行3个月以上”的版本，而不是“最新版”。

4. 真实世界踩坑录：那些文档里绝不会写的血泪教训

4.1 “时间维度”的陷阱：你以为的“2024-01”真的是同一个东西吗？

这是我在金融项目里栽的第一个大跟头。当时，我们有一个trade_date字段，类型是DATE。业务方要求按“年-月”聚合。我理所当然地写了：

SELECT EXTRACT(YEAR FROM trade_date) AS year, EXTRACT(MONTH FROM trade_date) AS month, SUM(amount) AS total FROM trades GROUP BY year, month;

结果上线后，风控同事立刻报警：1月份的交易额比平时高了3倍！排查了整整两天，最后发现，EXTRACT(MONTH FROM '2024-01-01')返回的是整数1，而EXTRACT(MONTH FROM '2024-01-31')返回的也是1。这看起来没问题。但问题出在year和month是两个独立的整数列。当year=2024, month=1时，它既匹配2024-01-01，也匹配2024-01-31，还匹配2023-01-15（如果数据有跨年的话）！因为2023-01-15的year=2023, month=1，它会被分到2023-01这个桶里，完全正确。但问题在于，year和month的组合，无法唯一标识一个时间区间。2024-01这个概念，在业务上指的是“2024年1月1日到2024年1月31日”这个闭区间，而不仅仅是两个数字。

正确的做法，是创建一个规范的时间键（Time Key）：

-- 推荐：使用字符串格式，语义清晰且可排序 SELECT TO_CHAR(trade_date, 'YYYY-MM') AS year_month, -- 返回 '2024-01' SUM(amount) AS total FROM trades GROUP BY year_month; -- 或者，使用日期类型，表示该月的第一天（更推荐，便于计算） SELECT DATE_TRUNC('month', trade_date) AS month_start, -- 返回 '2024-01-01' SUM(amount) AS total FROM trades GROUP BY month_start;

DATE_TRUNC('month', ...)返回的是一个DATE类型，其值是该月的第一天。这个值既是唯一的，又是可排序的（'2024-01-01' < '2024-02-01'），还能直接参与日期运算（如month_start + INTERVAL '1 month'）。这才是一个合格的时间维度。

实操心得：在数据建模阶段，就强制规定所有时间维度必须使用DATE_TRUNC生成的date类型，或者TO_CHAR(..., 'YYYY-MM-DD')生成的string类型。永远不要用EXTRACT(YEAR...)和EXTRACT(MONTH...)的组合。这个教训，让我在后续所有项目中，都增加了一条数据质量检查规则：SELECT COUNT(*) FROM (SELECT DISTINCT EXTRACT(YEAR FROM date_col), EXTRACT(MONTH FROM date_col) FROM table) t，如果这个数不等于SELECT COUNT(DISTINCT TO_CHAR(date_col, 'YYYY-MM')) FROM table，就说明数据有问题。

4.2 “维度层级”的幻觉：为什么“华东”不是一个原子维度？

另一个常见误区，是把业务上常说的聚合词，当成一个独立的维度。比如，“华东地区”、“华北地区”、“华南地区”。很多新人会想：“那我直接在数据里加一列region，值是‘华东’、‘华北’，不就完事了？”

错。这犯了维度建模中的“退化维度”（Degenerate Dimension）错误。“华东”不是一个基础维度，而是province维度的一个派生属性（Derived Attribute）。它的值完全由province决定：['上海','江苏','浙江','安徽','江西','福建','山东']->'华东'。

为什么不能把它当作一个独立维度？因为这会破坏维度的正交性（Orthogonality）。正交性要求，任何一个维度的取值，都不应该由其他维度的取值推导出来。一旦你有了province和region两列，你就引入了冗余和不一致的风险。例如，一条记录的province='上海'，但region='华北'，这显然是脏数据。更严重的是，当你做GROUP BY region, category时，你丢失了province层面的细节，无法再下钻到“上海的电子产品卖了多少”。

正确的做法是：只保留原子维度（province），并通过一个维度表（Dimension Table）来管理其层级关系。

-- 维度表：dim_province CREATE TABLE dim_province ( province_id INT PRIMARY KEY, province_name VARCHAR(20), region VARCHAR(20), -- 这是属性，不是维度 economic_zone VARCHAR(20) -- 如'一线', '新一线', '二线' ); -- 事实表：fact_sales CREATE TABLE fact_sales ( sale_id BIGINT, province_id INT, -- 外键，指向dim_province category_id INT, month_id INT, sales_amount DECIMAL(18,2) );

在聚合时，你始终GROUP BY p.province_name，如果需要按大区看，就JOIN dim_province，然后GROUP BY p.region。这样，province是单一事实源，region只是它的视图。数据的一致性和可追溯性得到了根本保障。

4.3 “聚合函数”的选择性失明：COUNT(*) vs COUNT(column)

这是SQL里最古老、也最容易被忽视的陷阱。假设你有一张用户行为日志表，其中user_id是主键，但device_id字段可能为NULL（比如Web端用户未登录）。

SELECT COUNT(*) AS total_events, COUNT(user_id) AS users_with_id, COUNT(device_id) AS devices_with_id FROM user_log;

COUNT(*)统计的是行数，COUNT(user_id)统计的是user_id非NULL的行数。如果user_id是主键，那这两者应该相等。但如果device_id有NULL，COUNT(device_id)就会小于COUNT(*)。

在多维聚合中，这个差异会被放大。假设你按province分组：

SELECT province, COUNT(*) AS total_events, COUNT(device_id) AS events_with_device FROM user_log GROUP BY province;

你可能会惊讶地发现，total_events和events_with_device的比值，在不同省份间差异巨大。比如，广东的比值是0.95，而西藏的比值只有0.3。这背后的真实业务含义是：西藏的用户，有很大比例是通过Web端匿名访问的，而广东的用户，绝大多数都登录并绑定了设备。这是一个极其宝贵的用户行为洞察。

但如果你在写聚合逻辑时，不加区分地全部用COUNT(*)，这个洞察就永远消失了。所以，我的铁律是：在定义度量（Metrics）时，必须明确写出COUNT(column)，并注明该列的业务含义和NULL语义。在MultiDimAggregator类中，metrics字典的key，从来不是"count"，而是"event_count"、"user_count"、"device_count"，每一个都对应一个具体的、非NULL的业务实体。