多维聚合实战：用Python构建可钻取数据立方体

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

你有没有遇到过这样的场景：销售部门要按季度、按区域、按产品大类看毛利，同时还要对比去年同期；财务团队需要把成本拆解到“部门-项目-费用类型-发生月份”四个维度，再筛选出超预算的组合；甚至一个简单的用户行为分析，都要交叉统计“新老用户 × 设备类型 × 页面路径 × 时间段”的点击热力图。这时候，Excel 的透视表点到第三层就开始卡顿，SQL 里写个 GROUP BY 带上四个字段，结果一跑就是五分钟，还经常漏掉某个维度的空值组合——这根本不是数据量的问题，而是你还在用“二维思维”处理多维现实。

Multi-Dimensional Aggregation（多维聚合），说白了，就是把数据当成一个有长、宽、高、甚至时间轴的立方体来切片、切块、钻取和旋转。它不是简单地“分组求和”，而是构建一套可动态导航的数据骨架。而Data Manipulation in Multi-Dimensional Aggregation，正是这个骨架上最核心的“关节活动”——它决定了你能不能在不重建模型的前提下，自由地增删维度、调整层级、计算衍生指标、合并异构来源，甚至让不同业务线的聚合口径在同一个底座上对齐。这不是数据库工程师的专利，而是今天每个要从数据中拿结论的产品经理、运营分析师、BI 开发者都绕不开的基本功。本文不讲 OLAP 理论，只聊我在三个真实项目里，如何用 Python + Pandas + PyArrow 手动“拧紧”这些关节，把一张扁平的订单表，变成能支撑 27 种业务视图的活体数据立方体。

2. 多维聚合的本质设计：为什么不能直接 GROUP BY 四个字段？

2.1 从“表格思维”到“立方体思维”的认知跃迁

很多人第一次接触多维聚合，下意识就去写 SQL：

SELECT region, product_category, quarter, SUM(revenue) AS total_revenue, AVG(profit_margin) AS avg_margin FROM sales GROUP BY region, product_category, quarter;

这看起来很完美，但问题藏在“完美”背后。我们来拆解一下这个查询实际构建的是什么：

• 它生成了一个3 维空间中的点集：region 是 X 轴，product_category 是 Y 轴，quarter 是 Z 轴。每个 (X,Y,Z) 坐标上，挂载着两个度量值（total_revenue 和 avg_margin）。
• 但它丢失了所有更高维或更低维的视角。比如，你想知道“华东地区所有产品的全年总营收”，就得重新写一个GROUP BY region的查询；想知道“Q1 所有区域的平均毛利率”，又得写GROUP BY quarter。每一次切换，都是一次全表扫描，计算逻辑无法复用。
• 更致命的是，它无法表达“空组合”。如果某区域在某季度没有销售记录，这个 (region, quarter) 组合在结果里就彻底消失。但在管理报表中，“华东 Q1 销售额为 0”和“华东 Q1 数据缺失”是完全不同的业务含义——前者是经营结果，后者是数据采集故障。

真正的多维聚合，目标是构建一个“预计算+按需计算”混合的立方体（Cube）。它的核心设计原则不是“一次算完所有组合”，而是“定义好所有可能的组合结构，并让计算路径清晰、可追溯、可复用”。

2.2 我的三维设计骨架：维度表、事实表与层次映射

在落地之前，我强制自己画一张草图，明确三个不可妥协的组件：

1. 维度表（Dimension Tables）：它们是立方体的“坐标轴”。每个维度必须是有明确层级结构（Hierarchy）和唯一自然键（Natural Key）的。例如：

   • dim_time表：包含date_id（主键）、year、quarter、month、week_of_year、is_holiday。关键点：quarter不是独立字段，而是year的子级，month是quarter的子级。这种父子关系，决定了钻取（Drill-down）和上卷（Roll-up）的路径。
   • dim_geo表：包含region_id（主键）、country、province、city、is_metropolitan。这里province是country的子级，city是province的子级。一个城市必然属于一个省，一个省必然属于一个国家——这种确定性，是聚合计算可预测的基础。
   • dim_product表：包含sku_id（主键）、category、sub_category、brand、is_premium。注意，category和sub_category是树状结构，而不是扁平标签。

2. 事实表（Fact Table）：它是立方体的“内容体”，只存储度量值（Measures）和指向维度表的外键（Surrogate Keys）。我的fact_sales表长这样：

   sale_id	date_id	region_id	sku_id	quantity	revenue	cost	discount
   1001	20230101	101	5001	2	199.00	80.00	0.00

   关键设计点：

   • 绝不存储任何维度属性（如region_name,quarter_name）。这些信息全部通过region_id和date_id关联到维度表获取。好处是：维度属性变更（比如“华北”改名为“京津冀”）只需更新维度表，事实表零改动。
   • 所有外键必须是整数型代理键（Surrogate Key），而非字符串自然键（如"SH"或"Q1-2023"）。整数 JOIN 性能比字符串快 3-5 倍，且避免了自然键变更带来的级联更新灾难。

3. 层次映射（Hierarchy Mapping）：这是让立方体“活起来”的胶水。它不是一张物理表，而是一份明确定义的 JSON 配置：

{ "time": { "levels": ["year", "quarter", "month", "date"], "parents": {"quarter": "year", "month": "quarter", "date": "month"} }, "geo": { "levels": ["country", "province", "city"], "parents": {"province": "country", "city": "province"} }, "product": { "levels": ["category", "sub_category", "sku"], "parents": {"sub_category": "category", "sku": "sub_category"} } }

这份配置，直接决定了 BI 工具或自研前端能提供哪些钻取按钮。没有它，你的立方体就是一堆散装的 GROUP BY 结果。

提示：很多团队跳过这一步，直接在 BI 工具里拖拽字段建模。短期看省事，长期看是埋雷。一旦维度层级变更（比如新增“大区”作为province的父级），所有已发布的报表都得手动重配，运维成本指数级上升。

2.3 为什么放弃传统 OLAP 引擎？手写聚合的三大硬核优势

看到这里，你可能会问：“既然有 ClickHouse、Doris、StarRocks 这些专业的 MPP OLAP 引擎，为什么还要手写？” 这是我踩过坑后总结的三点血泪经验：

1. 调试可见性（Debuggability）：在 StarRocks 里，一个GROUP BY查询跑了 8 秒，你只能看到最终结果。但用 Pandas 写，你可以df.groupby(['region', 'quarter']).agg({...}).pipe(print)，中间每一步都能print(df.shape)、print(df.memory_usage(deep=True).sum())，清楚看到数据在哪个环节膨胀、哪个字段导致了分组倾斜。对于复杂业务逻辑（比如“剔除试用订单后再计算复购率”），这种透明度是救命稻草。

2. 逻辑嵌套自由度（Nesting Freedom）：OLAP 引擎的HAVING子句只能过滤聚合后的结果，无法实现“先按用户分组计算其首单时间，再按首单时间分组统计留存”。而 Pandas 的groupby().apply()可以嵌套任意 Python 函数，把复杂的、带状态的业务规则，像写业务代码一样实现。我曾用它在一个apply函数里，完成了“识别用户生命周期阶段 → 计算该阶段内平均停留时长 → 根据时长打分 → 汇总为区域健康度指数”的四步链式计算。

3. 与机器学习流水线的无缝集成（ML Pipeline Integration）：最终的聚合结果，往往不是为了做报表，而是喂给一个预测模型。用 SQL 导出 CSV 再读入 Python，会丢失数据类型、时区、空值语义。而用 PyArrow 读取 Parquet 后，在同一个 DataFrame 里，你可以直接调用scikit-learn的StandardScaler对revenue列做标准化，再用pandas.get_dummies()对category做独热编码，整个过程零数据拷贝、零格式转换。这种端到端的流畅感，是任何“导出-导入”模式都无法比拟的。

当然，手写不等于裸奔。我的方案是：用 PyArrow 做底层存储和 IO，用 Pandas 做核心计算，用 DuckDB 做轻量级 SQL 协同查询。三者组合，既保住了 OLAP 的性能，又拿到了编程的灵活性。

3. 核心数据操作实操：从原始数据到可钻取立方体的七步炼金术

3.1 第一步：数据清洗与键对齐——别让脏数据毁掉整个立方体

多维聚合的基石是“键的纯净”。我见过太多项目，因为一个维度表里的region_id是字符串"101"，而事实表里是整数101，导致 JOIN 全为空，最后报表全是 0。所以，清洗不是可选项，是第一道生死线。

我的标准清洗流程（Python + PyArrow）：

import pyarrow as pa import pyarrow.parquet as pq import pandas as pd # 1. 读取原始CSV（假设是sales_raw.csv） raw_df = pd.read_csv("sales_raw.csv", dtype={"region_code": str, "sku_code": str}) # 2. 清洗维度键：统一转为字符串并去除首尾空格和不可见字符 raw_df["region_code"] = raw_df["region_code"].astype(str).str.strip().str.replace(r"\s+", " ", regex=True) raw_df["sku_code"] = raw_df["sku_code"].astype(str).str.strip() # 3. 清洗日期：强制解析为 datetime，并提取标准 date_id (YYYYMMDD) raw_df["order_date"] = pd.to_datetime(raw_df["order_date"], errors="coerce") raw_df = raw_df.dropna(subset=["order_date"]) # 丢弃无法解析的日期 raw_df["date_id"] = raw_df["order_date"].dt.strftime("%Y%m%d").astype(int) # 4. 关键一步：检查键的覆盖度（Coverage Check） dim_region = pd.read_parquet("dim_region.parquet") # 维度表已预先构建 missing_regions = set(raw_df["region_code"]) - set(dim_region["region_code"]) if missing_regions: print(f"警告：发现 {len(missing_regions)} 个未在维度表中定义的 region_code: {list(missing_regions)[:5]}") # 实际项目中，这里会触发告警，并将缺失码写入待审核队列

实操心得：永远不要相信上游数据的“格式正确”。我曾在一家电商公司，发现sku_code字段里混入了"SKU-12345"和"12345"两种格式，而维度表只认"12345"。这个 bug 导致华东区的 GMV 在月报里被低估了 37%。从此，我的清洗脚本第一行永远是print(f"原始数据行数: {len(raw_df)}")，最后一行是print(f"清洗后行数: {len(clean_df)}")，两数之差就是脏数据的“尸体清单”。

3.2 第二步：构建事实表——用代理键替换自然键

清洗后的raw_df还带着region_code、sku_code这些自然键。现在，我们要用维度表的代理键（region_id,sku_id）来替换它们，完成事实表的“脱敏”。

# 加载维度表（使用PyArrow，内存更省） dim_region = pq.read_table("dim_region.parquet").to_pandas() dim_product = pq.read_table("dim_product.parquet").to_pandas() # 创建映射字典（内存友好，比merge快） region_map = dim_region.set_index("region_code")["region_id"].to_dict() product_map = dim_product.set_index("sku_code")["sku_id"].to_dict() # 替换键（向量化操作，非循环！） clean_df["region_id"] = clean_df["region_code"].map(region_map) clean_df["sku_id"] = clean_df["sku_code"].map(product_map) # 检查映射失败（即自然键在维度表中找不到） null_regions = clean_df["region_id"].isnull().sum() null_skus = clean_df["sku_id"].isnull().sum() if null_regions > 0 or null_skus > 0: raise ValueError(f"键映射失败：{null_regions} 条记录 region_id 为空，{null_skus} 条记录 sku_id 为空") # 选择最终的事实表字段 fact_sales = clean_df[["sale_id", "date_id", "region_id", "sku_id", "quantity", "revenue", "cost", "discount"]] # 写入Parquet，为后续高效聚合做准备 pq.write_table(pa.Table.from_pandas(fact_sales), "fact_sales.parquet")

注意：map()操作比merge()快得多，尤其在大数据集上。merge()会创建一个巨大的笛卡尔积中间表，而map()是 O(1) 的哈希查找。另外，fact_sales.parquet的文件名里我特意没加日期，因为事实表是增量追加的，我会用pyarrow.dataset来管理分区。

3.3 第三步：预计算基础聚合——生成“原子粒度”立方体

现在，我们有了干净的事实表和维度表。下一步，不是直接做业务报表，而是生成一个“最小可用”的原子聚合层。我的原则是：所有业务报表，都必须基于这个原子层进行二次聚合，而不是回刷原始事实表。

原子粒度，我定义为：事实表的所有外键字段 + 所有度量字段的原始聚合（SUM, COUNT, AVG）。也就是GROUP BY date_id, region_id, sku_id。

# 读取事实表（PyArrow Parquet，支持列存和谓词下推） fact_table = pq.read_table( "fact_sales.parquet", columns=["date_id", "region_id", "sku_id", "quantity", "revenue", "cost", "discount"] ) # 转为Pandas进行聚合（对于亿级数据，我会用Dask，但这里先用Pandas演示） df = fact_table.to_pandas() # 执行原子聚合 atomic_cube = ( df.groupby(["date_id", "region_id", "sku_id"], dropna=False) .agg( total_quantity=("quantity", "sum"), total_revenue=("revenue", "sum"), total_cost=("cost", "sum"), total_discount=("discount", "sum"), order_count=("sale_id", "count"), # 订单数，不是行数 avg_order_value=("revenue", "mean"), # 平均订单金额 ) .reset_index() ) # 写入原子立方体 pq.write_table(pa.Table.from_pandas(atomic_cube), "cube_atomic.parquet")

这个cube_atomic.parquet就是我们的“黄金层”。它有三个巨大价值：

• 体积小：原始事实表有 10 亿行，原子立方体只有 2000 万行（因为date_id * region_id * sku_id的组合远少于原始订单行）。
• 计算快：所有后续报表，都从这 2000 万行里GROUP BY，而不是 10 亿行。
• 口径稳：avg_order_value的计算逻辑（revenue的mean）在这里固化，下游所有报表都继承这个定义，杜绝了“财务算的 AOV 和运营算的 AOV 不一致”的经典冲突。

3.4 第四步：维度上卷（Roll-up）——从 SKU 到 Category 的自动推导

原子立方体太细了，没人想看“20230101, 华东, SKU-12345”的销售额。我们需要把它“上卷”到业务关心的层级，比如quarter,region,category。

关键在于：不能硬编码GROUP BY，而要根据前面定义的层次映射配置，动态生成聚合路径。

import json # 加载层次映射配置 with open("hierarchy.json") as f: hierarchy = json.load(f) # 加载维度表 dim_time = pq.read_table("dim_time.parquet").to_pandas() dim_geo = pq.read_table("dim_geo.parquet").to_pandas() dim_product = pq.read_table("dim_product.parquet").to_pandas() # 加载原子立方体 atomic_cube = pq.read_table("cube_atomic.parquet").to_pandas() # 动态上卷函数 def roll_up_cube(cube_df, dim_tables, hierarchy_config, target_levels): """ cube_df: 原子立方体DataFrame dim_tables: {table_name: DataFrame} 字典 hierarchy_config: 层次配置JSON target_levels: 目标层级列表，如 ["quarter", "region", "category"] """ result = cube_df.copy() # 1. 逐个维度进行JOIN，获取目标层级字段 for dim_name, levels in hierarchy_config.items(): if any(level in target_levels for level in levels["levels"]): # 找到该维度在cube_df中的外键名（约定：dim_name + "_id"） fk_col = f"{dim_name}_id" # JOIN维度表，只选取需要的目标层级字段 needed_cols = [col for col in levels["levels"] if col in target_levels] dim_subset = dim_tables[dim_name][[fk_col] + needed_cols].drop_duplicates() result = result.merge(dim_subset, on=fk_col, how="left") # 2. 执行GROUP BY，聚合度量 group_cols = [col for col in target_levels if col in result.columns] agg_funcs = { "total_quantity": "sum", "total_revenue": "sum", "total_cost": "sum", "total_discount": "sum", "order_count": "sum", "avg_order_value": "mean" # 注意：AOV的mean是跨所有订单的平均，不是各组平均的平均 } rolled_cube = result.groupby(group_cols, dropna=False).agg(agg_funcs).reset_index() return rolled_cube # 示例：生成“季度-区域-品类”立方体 qrc_cube = roll_up_cube( atomic_cube, {"time": dim_time, "geo": dim_geo, "product": dim_product}, hierarchy, ["quarter", "region", "category"] ) pq.write_table(pa.Table.from_pandas(qrc_cube), "cube_qrc.parquet")

这个函数的威力在于，你只需要改一行target_levels = ["year", "country", "brand"]，就能瞬间生成一个全新的“年度-国家-品牌”视图，而不用重写任何 SQL。这就是多维聚合的“元编程”魅力。

3.5 第五步：衍生指标计算——不只是SUM和AVG

业务需求从来不只是“求和”。常见的衍生指标有三类，我分别用不同策略处理：

1. 比率型（Ratio）：如毛利率= (revenue - cost) / revenue。绝不在原子层计算！因为SUM(revenue-cost)/SUM(revenue)≠SUM(revenue)/SUM(revenue) - SUM(cost)/SUM(revenue)。必须在上卷后的立方体里，用聚合后的total_revenue和total_cost重新计算。

qrc_cube["gross_margin"] = (qrc_cube["total_revenue"] - qrc_cube["total_cost"]) / qrc_cube["total_revenue"] # 注意：要处理分母为0的情况 qrc_cube["gross_margin"] = qrc_cube["gross_margin"].replace([np.inf, -np.inf], np.nan)

2. 占比型（Share）：如“某品类在华东的销售额占华东总销售额的比例”。这需要先计算华东总销售额（上卷到region），再和region-category的结果 JOIN。

# 计算区域总销售额 region_total = qrc_cube.groupby("region", dropna=False)[["total_revenue"]].sum().rename(columns={"total_revenue": "region_total_revenue"}) # JOIN回来计算占比 qrc_cube = qrc_cube.merge(region_total, on="region", how="left") qrc_cube["category_share_in_region"] = qrc_cube["total_revenue"] / qrc_cube["region_total_revenue"]

3. 窗口型（Window）：如“环比增长率”。这需要按时间排序，用shift()函数。

# 确保按时间排序 qrc_cube = qrc_cube.sort_values(["region", "category", "quarter"]) # 计算上一季度的销售额（按region和category分组） qrc_cube["prev_quarter_revenue"] = qrc_cube.groupby(["region", "category"])["total_revenue"].shift(1) qrc_cube["qoq_growth_rate"] = (qrc_cube["total_revenue"] - qrc_cube["prev_quarter_revenue"]) / qrc_cube["prev_quarter_revenue"]

实操心得：所有衍生指标的计算，我都会在代码里加上注释，说明其数学定义和业务含义。比如# gross_margin: (总营收 - 总成本) / 总营收，分子分母均为上卷后聚合值，非原子层计算。这不仅是给自己看，更是给接手的同事留下的“契约”。

3.6 第六步：空值组合填充（Sparsity Handling）——让“0”和“NULL”各司其职

前面提到，GROUP BY会丢失空组合。在管理报表中，我们必须显式地“补全”这些组合，让“0”代表“无业务发生”，而NULL代表“数据缺失”。

我的填充策略是：对每个目标立方体，生成其所有可能的组合笛卡尔积，再 LEFT JOIN 原始聚合结果。

from itertools import product def fill_sparse_cube(cube_df, dim_tables, target_levels): """ cube_df: 已上卷的立方体（如qrc_cube） dim_tables: 维度表字典 target_levels: 目标层级列表，如 ["quarter", "region", "category"] """ # 1. 为每个目标层级，提取其所有唯一值 level_values = {} for level in target_levels: # 根据level名，反向查找它属于哪个维度表 for dim_name, config in hierarchy.items(): if level in config["levels"]: # 从对应的维度表中提取该level的所有值 dim_df = dim_tables[dim_name] # 过滤掉NULL值，因为我们只关心“有效”的组合 level_values[level] = dim_df[level].dropna().unique().tolist() break # 2. 生成所有可能的组合（笛卡尔积） all_combinations = list(product(*[level_values[level] for level in target_levels])) combinations_df = pd.DataFrame(all_combinations, columns=target_levels) # 3. LEFT JOIN，用0填充缺失的度量 filled_cube = combinations_df.merge(cube_df, on=target_levels, how="left") # 4. 对所有度量列，将NaN填充为0（业务上，“无记录”即“0”） measure_cols = ["total_quantity", "total_revenue", "total_cost", "total_discount", "order_count"] for col in measure_cols: if col in filled_cube.columns: filled_cube[col] = filled_cube[col].fillna(0) return filled_cube # 应用填充 filled_qrc_cube = fill_sparse_cube(qrc_cube, {"time": dim_time, "geo": dim_geo, "product": dim_product}, ["quarter", "region", "category"]) pq.write_table(pa.Table.from_pandas(filled_qrc_cube), "cube_qrc_filled.parquet")

这个步骤让报表变得“诚实”。当你看到“华北 Q3 智能手机销售额为 0”，你知道这是真实的经营结果；而如果这个组合在filled_qrc_cube里都不存在，那才是真正的数据管道故障，需要立刻告警。

3.7 第七步：物化与发布——从脚本到服务的最后一步

一个再完美的立方体，如果不能被业务方方便地使用，就是废品。我的发布流程是三层：

1. Parquet 文件层：所有cube_*.parquet文件，按业务域组织在 S3/HDFS 上。这是最原始、最灵活的访问方式，供数据科学家和高级分析师直接读取。

2. DuckDB 视图层：启动一个轻量级 DuckDB 实例，将所有 Parquet 文件注册为虚拟表，并创建业务友好的视图。

-- 在DuckDB中执行 CREATE VIEW v_sales_qrc AS SELECT quarter, region, category, total_revenue, ROUND(gross_margin * 100, 2) AS gross_margin_pct, category_share_in_region * 100 AS share_pct FROM 'cube_qrc_filled.parquet';

这样，业务方就可以用标准 SQL 连接 DuckDB，写SELECT * FROM v_sales_qrc WHERE quarter = '2023Q3'，体验和连 MySQL 一模一样。

3. API 服务层（可选）：对于需要嵌入到内部系统的场景，我用 FastAPI 包一层：

from fastapi import FastAPI import duckdb app = FastAPI() con = duckdb.connect() @app.get("/sales/qrc") def get_qrc_data(region: str = None, category: str = None): sql = "SELECT * FROM v_sales_qrc WHERE 1=1" params = [] if region: sql += " AND region = ?" params.append(region) if category: sql += " AND category = ?" params.append(category) result = con.execute(sql, params).fetchdf() return result.to_dict(orient="records")

至此，一个从原始 CSV 到可被全公司调用的多维聚合服务，就完整落地了。整个过程，没有黑盒，没有神秘的“引擎配置”，只有清晰的 Python 代码、可验证的 Parquet 文件和标准的 SQL 接口。

4. 常见问题与排查技巧实录：那些让我熬夜到凌晨三点的 Bug

4.1 问题速查表：高频故障与根因定位

4.2 “分组倾斜”（Skew）的实战诊断与化解

当你的GROUP BY在 Pandas 里跑得奇慢，或者内存爆掉，大概率是遇到了分组倾斜：某个分组（如region_id = 1）的数据量是其他分组的 1000 倍。

诊断：不要猜，用代码看。

# 查看分组大小分布 group_sizes = df.groupby("region_id").size() print("分组大小统计：") print(group_sizes.describe()) print("\n最大的10个region_id:") print(group_sizes.nlargest(10))

如果max是mean的 500 倍以上，就是严重倾斜。

化解三板斧：

1. Salting（加盐）：给倾斜键加随机后缀，打散它。

import numpy as np # 识别出倾斜的region_id（假设是1） skewed_id = 1 salted_df = df.copy() # 对倾斜键，添加0-9的随机盐值 salted_df.loc[salted_df["region_id"] == skewed_id, "region_id_salt"] = np.random.randint(0, 10, size=salted_df[salted_df["region_id"] == skewed_id].shape[0]) # 对非倾斜键，盐值设为-1，保持原样 salted_df.loc[salted_df["region_id"] != skewed_id, "region_id_salt"] = -1 salted_df["region_id_salted"] = salted_df["region_id"].astype(str) + "_" + salted_df["region_id_salt"].astype(str) # 现在按'salted_id'分组 result = salted_df.groupby("region_id_salted").agg({...}) # 最后，把盐去掉，合并结果 result.index = result.index.str.split("_").str[0].astype(int) final_result = result.groupby(level=0).sum() # 如果是sum聚合

2. 两阶段聚合：先局部聚合，再全局聚合。

# 第一阶段：按region_id + 一个辅助字段（如date_id的年份）分组，降低单组数据量 stage1 = df.groupby(["region_id", df["date_id"] // 10000]).agg({...}) # 20230101 // 10000 = 2023 # 第二阶段：再按region_id汇总 final_result = stage1.groupby("region_id").agg({...})

3. 业务过滤：很多时候，倾斜是因为包含了测试数据、机器人流量等。在清洗阶段就df = df[~df["is_test_order"]]，比在聚合时处理高效十倍。

4.3 时间维度的“陷阱”：为什么你的同比计算总是错？

时间维度是最容易出错的。我总结了三个必踩的坑：

• 坑一：quarter字符串比较。"Q4">"Q1"是True，但"2023Q4"<"2024Q1"是False。永远用date_id或标准日期类型做排序和比较。

• 坑二：闰年与月末。pd.date_range("2023-01-01", "2023-12-31", freq="Q")生成的季度末是2023-03-31,2023-06-30,2023-09-30,2023-12-31，完美。但如果你用strftime("%YQ%q")，2023-02-28会被算作Q1，而2023-03-01也是Q1，没问题。但2024-02-29（闰年）呢？确保你的dim_time表覆盖了所有可能的日期，包括闰年2月29日。

• 坑三：同比的“基准日”。计算2023Q3同比，应该和2022Q3比，而不是