如何解决点击流分析系统星型模式中事实表与失败详情的1对多关系？

方案1：嵌套JSON字段直接存储（适合快速迭代/非结构化查询） #

• 直接在fact_events中新增failure_details字段，类型设为JSON（或对应数据仓库支持的半结构化类型，如BigQuery JSON、Snowflake VARIANT）
• 优点：无需额外建模，保留原始数据结构，ETL流程简单，可直接处理不可预测的attribute_key/attribute_value
• 缺点：若需对失败属性做频繁聚合分析（如按特定attribute_value统计失败次数），查询性能可能弱于结构化存储，部分数据仓库对JSON字段的索引支持有限

方案2：主事实表+失败详情子事实表（多事实表关联） #

• 保留fact_events作为主事实表，新增fact_failure_details子事实表：
  • fact_failure_details字段：event_key（关联fact_events主键）、failure_type、attribute_key、attribute_value、其他固定失败字段（如有）
  • 每个失败诊断对象对应fact_failure_details中的一行记录
• 优点：完全结构化，支持对任意attribute_key/attribute_value做聚合分析，符合Kimball事实表设计原则
• 缺点：ETL需将嵌套数组拆分为多行，数据量会增加，查询时需关联两个事实表

方案3：桥接表+柔性维度（处理半结构化属性） #

• 针对不可预测的属性键值对，新增dim_flex_attributes柔性维度表：
  • 字段：attribute_key、attribute_value、attribute_sk（代理键）
• 新增桥接表bridge_event_failures：
  • 字段：event_key、failure_type、attribute_sk
• 主事实表fact_events保留is_success及核心事件字段
• 优点：复用属性值，减少数据冗余，支持灵活的属性分析
• 缺点：ETL复杂度高，需动态识别新的attribute_key并插入维度表，首次加载和新增属性时需处理维度同步

方案选择建议 #

• 若分析需求以事件级统计为主，仅偶尔查看失败详情：选方案1
• 若需频繁对失败属性做细分聚合：选方案2
• 若失败属性重复度高，且希望减少数据冗余：选方案3

内容的提问来源于stack exchange，提问作者Oleksii