附录 E · H&M 数据集¶
本附录正式介绍 TTD 端到端验证所用的 H&M 数据集：来源、表结构、选择理由、加载流程与语义平面映射。全书凡提及"在 H&M 数据集上验证"之处（如 第 1 章、第 5 章、第 10 章、第 15 章），均以本附录为权威参照。
E.1 数据集来源与领域¶
TTD 使用 Kaggle 竞赛 H&M Personalized Fashion Recommendations 作为端到端验证基线。
| 属性 | 说明 |
|---|---|
| 领域 | 零售 / 时尚电商 |
| 来源方 | H&M Group（53 个在线市场、约 4,850 家门店） |
| 原始任务 | 基于客户历史购买记录，预测其未来 7 天将购买的商品 |
| 数据形态 | 交易流水 + 客户画像 + 商品属性 + 商品图片（多模态） |
| 在 TTD 中的角色 | 不做商品推荐，而是作为 Agentic BI 的业务数据——用户用自然语言查询"GMV 趋势""销量 Top N""客户分群"等分析问题，TTD 生成并执行 SQL |
TTD 任务与原始竞赛任务不同
原始竞赛是推荐系统任务（预测 article_id）；TTD 把同一份数据当作 Agentic BI 的查询对象——关注的是"用户提问 → NL2SQL → 执行 → 可视化"的端到端链路，而非推荐准确率。数据集的选择是出于其表结构清晰、语义丰富、公开可复现，适合演示语义治理与四引擎 RAG。
E.2 表结构与规模¶
H&M 在 TTD 数据面中以 gold_hm schema 的三张表承载，对应一个经典的星型拓扑（1 事实表 + 2 维度表）。DDL 见 data-plane/sql/100_hm_create_schema.sql。
E.2.1 gold_hm.dim_article（维度表 · 26 列）¶
商品主数据，描述每一件可售卖商品的颜色、类别、部门、外观等属性。
| 列 | 类型 | 说明 |
|---|---|---|
article_id |
VARCHAR(16) | 商品唯一标识（主键，关联事实表） |
product_code / prod_name |
VARCHAR(16) / TEXT | 商品编码与名称 |
product_type_no / product_type_name |
INTEGER / VARCHAR(256) | 商品类型 |
product_group_name |
VARCHAR(256) | 商品分组 |
graphical_appearance_no / _name |
INTEGER / VARCHAR(256) | 图案外观 |
colour_group_code / _name |
VARCHAR(8) / VARCHAR(128) | 颜色组 |
perceived_colour_value_id / _name |
INTEGER / VARCHAR(128) | 感知色值 |
perceived_colour_master_id / _name |
INTEGER / VARCHAR(128) | 感知主色 |
department_no / department_name |
INTEGER / VARCHAR(256) | 部门 |
index_code / index_name |
VARCHAR(8) / VARCHAR(256) | 索引 |
index_group_no / index_group_name |
INTEGER / VARCHAR(256) | 索引分组 |
section_no / section_name |
INTEGER / VARCHAR(256) | 系列 |
garment_group_no / garment_group_name |
INTEGER / VARCHAR(256) | 服装分组 |
detail_desc |
TEXT | 商品文本描述（多模态：可用于 NLP） |
image_url |
TEXT | 商品图片地址（多模态：非全量商品有图） |
E.2.2 gold_hm.dim_customer（维度表 · 7 列）¶
客户主数据，描述客户的人口统计与会员状态。
| 列 | 类型 | 说明 |
|---|---|---|
customer_id |
VARCHAR(64) | 客户唯一标识（主键，关联事实表） |
fn |
REAL | 是否接收时尚新闻邮件（1=是） |
active |
REAL | 是否活跃（1=是） |
club_member_status |
VARCHAR(32) | 会员状态（ACTIVE / PRE-CREATE / LEFT CLUB） |
fashion_news_frequency |
VARCHAR(32) | 时尚新闻频率（Regularly/Monthly/None） |
age |
SMALLINT | 年龄（已匿名化分桶） |
postal_code |
VARCHAR(128) | 邮编（已脱敏哈希） |
E.2.3 gold_hm.fact_transaction（事实表 · 5 列）¶
交易流水，每一行代表一次购买行为（同一客户同一天购买同一商品计为多行）。
| 列 | 类型 | 说明 |
|---|---|---|
t_dat |
DATE | 交易日期（主时间列） |
customer_id |
VARCHAR(64) | 客户（外键 → dim_customer） |
article_id |
VARCHAR(16) | 商品（外键 → dim_article） |
price |
DECIMAL(18,8) | 价格（退货为负值） |
sales_channel_id |
SMALLINT | 销售渠道（1=线下门店，2=线上） |
E.2.4 数据规模¶
下表数字为 Kaggle 官方公布量级，标注为"约"。实际加载规模取决于本地是否全量导入；TTD 不依赖固定行数运行。
| 数据集 | 约略规模 | 说明 |
|---|---|---|
transactions_train.csv → fact_transaction |
~31.8M 行 | 2018-09-20 至 2020-09-22 的交易 |
customers.csv → dim_customer |
~1.37M 行 | 客户画像 |
articles.csv → dim_article |
~105K 行 | 商品主数据 |
images/ |
~105K 张 | 商品图片（非全量商品有图，按 article_id 前三位分子目录） |
数据规模为设计目标语境
上述行数为 Kaggle 原始数据集量级，用于让读者建立规模直觉。TTD 尚未进行系统化的大规模数据性能实测；本地开发常以子集加载以降低资源占用。性能基准（不同数据量下的延迟与吞吐）见 第 16 章 路线图。
E.3 为何选择 H&M¶
| 选择理由 | 说明 |
|---|---|
| 单域、易理解 | 零售/时尚是大众熟悉的领域，读者无需领域知识即可理解"销量""GMV""退货率"等指标 |
| 经典星型拓扑 | 1 事实表 + 2 维度表，足以演示 join 路径规划（Steiner 树）与多表关联，又不至于过于复杂 |
| 含 Chasm Trap 风险 | fact_transaction 通过 customer_id 与 article_id 同时关联两维度表，适合演示 第 6 章 的 aggregate-before-join 重写 |
| 多模态元数据 | detail_desc（文本）与 image_url（图像）天然适合演示多模态 RAG 的扩展空间 |
| 公开可复现 | Kaggle 公开数据集，任何读者都可下载并复现 TTD 的端到端流程 |
诚实声明：H&M 的局限
H&M 是一个小规模、单领域数据集（仅 3 表）。它能验证 TTD 的端到端链路完整性，但无法证明系统在跨行业、大规模 schema（几十上百张表）下的泛化能力。这是 TTD 当前最大的验证缺口之一，已在多处标记为改进项：
- 第 1 章 1.3.3 列为首要局限
- 第 10 章 列为数据面改进项
- 第 15 章 列为评估改进项
- 第 16 章 "公开基准回归"列为改进方向（引入 Spider/BIRD 等多 schema 基准做离线回归）
E.4 数据加载与列存镜像¶
H&M 数据通过两步进入数据面（详见 第 10 章）：
%%{init: {'theme':'base','themeVariables':{'primaryColor':'#e8f0fe','primaryTextColor':'#202124','primaryBorderColor':'#1a73e8','lineColor':'#5f6368','secondaryColor':'#e0f2f1','tertiaryColor':'#f8f9fa'}}}%%
flowchart LR
CSV["Kaggle CSV<br/>transactions · customers<br/>articles"] -->|"COPY FROM STDIN<br/>load_hm_data.py"| SRC["gold_hm.*_src<br/>堆表（行存）"]
SRC -->|"mooncake.create_table<br/>mirror · source"| MIRROR["gold_hm.*<br/>列存镜像<br/>pg_mooncake columnstore"]
MIRROR -->|"OLAP 聚合查询<br/>SUM · COUNT · GROUP BY"| QUERY["用户 SQL 执行<br/>语义资产引用规范名<br/>与生产 Redshift 同表契约"]
classDef bpProcess fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#202124
classDef bpData fill:#e0f2f1,stroke:#0d7377,stroke-width:2px,color:#202124
classDef bpSuccess fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px,color:#202124
class CSV bpProcess
class SRC bpData
class MIRROR bpData
class QUERY bpSuccess- 源表
_src（行存堆表）：load_hm_data.py用COPY FROM STDIN将 CSV 导入dim_article_src/dim_customer_src/fact_transaction_src。 - 列存镜像（canonical 名）：
CALL mooncake.create_table('gold_hm.dim_article', 'gold_hm.dim_article_src')创建列存镜像，镜像使用规范名（无_src后缀）。 - 语义资产与生产共用规范名：
semantic-plane/的 YAML 资产和生产 Redshift 都引用gold_hm.dim_article等规范名——本地 pg_mooncake 镜像与生产 Redshift 共享同一表契约，仅方言不同。
列存镜像为何存在
OLAP 聚合查询（SUM/COUNT/GROUP BY）在列存上远快于行存——列存按列压缩、只读所需列、向量化执行。这正是 Redshift/Snowflake 等 OLAP 引擎的核心。pg_mooncake 在本地以 PG 扩展形式提供列存能力，使开发态无需 Redshift 即可获得接近的查询特征。详见 第 10 章 pg_mooncake 内部。
E.5 与语义平面的映射¶
H&M 的三张 gold 表在语义平面（第 9 章）中被映射为完整的治理资产，位于 semantic-plane/domains/hm_fashion/。这是"三层治理模型"的具体实例：
| 语义资产类型 | H&M 示例 | 数量（约） | 说明 |
|---|---|---|---|
table_asset |
fact_transaction、dim_article、dim_customer |
3 | 三张 gold 表各一份资产 |
column_asset |
price、t_dat、age、sales_channel_id… |
38 | 26+7+5 列逐列定义业务名、语义类型、暴露策略 |
metric_asset |
transaction_count、avg_transaction_price、unique_customer_count… |
5 | 预定义指标（含 SQL 定义、反例、相似指标） |
business_term |
"GMV""销量""退货率""客单价"… | — | 业务术语到列/指标的强路由映射（ADR-16） |
join_rule |
fact_transaction ⟕ dim_article ON article_id 等 |
3 | 事实表到两维度表的 join 规则（含基数、扇出风险） |
business_rule |
"退货金额为负""客户年龄匿名化"等 | 7 | H&M 数据集的业务约束 |
few_shot_example |
"上月销量 Top 10 商品" → SQL | — | 供 Engine D / Prompt 参考的问答对 |
business_context |
"H&M 零售分析"领域上下文 | — | 限定分析范围的上下文边界 |
示例 metric 资产（semantic-plane/domains/hm_fashion/metrics/transaction_count.yaml）：
# file: domains/hm_fashion/metrics/transaction_count.yaml
metric_asset:
metric_id: "met_hm_transaction_count"
metric_name: "Transaction Count"
business_definition_zh: >
交易次数，统计购买交易事实表中的总行数。每一行代表一次购买行为，
同一客户同一天购买同一商品会被计为多次。
business_definition_en: >
Total number of purchase transactions. Each row in fact_transaction
represents one purchase event.
sql_definition: >
SELECT COUNT(*)
FROM gold_hm.fact_transaction
default_grain: "daily"
allowed_dimensions: ["t_dat", "sales_channel_id"]
owner: "data-team@hm.com"
certification_status: "certified"
version: "1.0.0"
counter_examples:
- "交易次数 ≠ 订单数，这里没有订单概念，一行就是一次购买行为"
这 8 类资产经语义层发布管道（Git YAML → pre-commit/CI 校验 → PR 审查 → S3 发布 → Backend 自动导入）进入数据面，供 第 5 章 的 R/V/G/D 四引擎检索。资产类型与校验 schema 详见 第 9 章。
相关文档¶
- 第 1 章 引言——H&M 作为验证基线的定位与局限
- 第 5 章 RAG 检索——四引擎如何检索 H&M 语义资产
- 第 9 章 语义平面——8 类资产类型与发布管道
- 第 10 章 数据平面——H&M 数据的加载与列存镜像
- 第 15 章 质量评估——基于 H&M 的评估数据集示例