数据仓库采用单一还是多数据模型？ELT模式下的设计疑问

核心结论：优先基于统一业务域构建单一逻辑数据模型，再通过视图/派生表实现特定场景的按需轻量化建模，不要为每个数据管道单独创建独立模型。

为什么不建议为每个管道单独建模？ #

• 数据冗余与一致性风险：每个管道单独建模会重复存储客户、商品这类核心实体数据，既浪费存储资源，还可能出现同一实体信息在不同模型中版本不一致的问题（比如客户手机号在采购模型和供应商模型中更新不同步）。
• 跨域分析成本飙升：电商场景中经常需要做跨域分析，比如“供应商履约质量对客户复购率的影响”，如果采购和供应商数据分属独立模型，需要跨多个数据集做复杂关联，完全违背ELT“快速获取数据、灵活分析”的初衷。

单一模型如何适配ELT的按需特性？ #

ELT的核心是先把全量原始数据加载到数据仓库的原始层（比如从S3同步的原始表存放在raw层），再在中间逻辑层（curated层）构建统一的核心模型，按需建模体现在基于统一模型构建面向特定场景的派生对象：

1. 统一逻辑层：整合核心业务域的实体与关系，比如电商场景下的dim_customers（客户维度表）、dim_suppliers（供应商维度表）、dim_products（商品维度表）、fact_orders（订单事实表，关联客户、商品、供应商）。这一层只保留核心数据，保证数据的唯一性和一致性。
2. 按需派生层：针对特定业务需求，基于统一逻辑层创建视图或物化视图：
   • 客户采购场景：创建vw_customer_purchase_behavior视图，关联dim_customers和fact_orders，聚合计算客户的下单频次、客单价、复购率等指标。
   • 供应商场景：创建mv_supplier_delivery_stats物化视图，关联dim_suppliers、fact_orders和dim_products，统计供应商的按时交货率、退货率、供货占比等数据。

这些派生对象不需要重复存储基础数据，只是基于统一模型做针对性计算，既满足了按需分析的需求，又保证了数据的一致性。

电商场景的落地示例 #

1. 原始层：存储从S3同步的全量原始数据，比如s3_raw_customers、s3_raw_orders、s3_raw_suppliers、s3_raw_products。
2. 逻辑层：构建统一核心模型，比如：
   • dim_customers：整合所有渠道的客户信息，包含客户ID、姓名、手机号、注册时间等核心字段。
   • dim_suppliers：整合供应商基本信息、资质、合作期限等字段。
   • fact_orders：存储订单明细，关联客户ID、商品ID、供应商ID，包含订单金额、下单时间、交货时间等事实字段。
3. 分析层：
   • 针对运营部门的客户采购分析需求，创建视图vw_customer_segmentation，按客户的采购金额、频次做分层。
   • 针对供应链部门的供应商管理需求，创建物化视图mv_supplier_rating，结合供货时效、退货率计算供应商综合评分。

实操建议 #

• 先梳理核心业务域：明确电商的核心域（客户、商品、交易、供应商等），优先把这些域的实体和关系在逻辑层统一建模，确保核心数据唯一可信。
• 避免过度建模：逻辑层只保留核心实体和必要关联，不需要一开始就把所有字段都纳入，ELT原始层已经存储了全量数据，需要时再从原始层补充字段到逻辑层。
• 优先用视图/物化视图：针对特定场景需求，优先使用视图（满足实时分析）或物化视图（满足高性能查询），减少数据冗余，同时保证数据与核心模型同步更新。

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