1. 电商交易场景的维度建模实战电商交易是数仓建模中最典型的业务场景之一。我去年帮一家跨境电商企业搭建数仓时发现他们每天有200多万笔订单数据但分散在10多个业务系统中。通过维度建模我们最终把查询效率提升了17倍。1.1 星型模型设计要点在设计电商交易星型模型时核心事实表就是订单事实表。这里有个坑要注意订单的粒度到底是按订单头还是订单行项我们当时选择了订单行项粒度因为一个订单可能包含多个商品优惠券抵扣、运费等金额需要分摊到每个商品便于后续分析单品销售情况订单事实表的关键字段包括CREATE TABLE fact_order ( order_sk BIGINT, -- 代理键 product_sk BIGINT, -- 商品维度外键 customer_sk BIGINT, -- 客户维度外键 date_sk INT, -- 日期维度外键 order_id VARCHAR(50), -- 原始订单ID quantity INT, -- 购买数量 price DECIMAL(18,2), -- 单价 amount DECIMAL(18,2), -- 总金额 coupon_amount DECIMAL(18,2) -- 优惠金额 );1.2 缓慢变化维处理用户维度是最典型的缓慢变化维。我们遇到过用户修改收货地址的情况这时候有3种处理方案类型1直接覆盖旧值适合不关心历史的情况类型2新增记录并标记生效时间最常用类型3保留有限历史版本如当前值和前一个值我们最终采用类型2方案用户维度表设计如下CREATE TABLE dim_user ( user_sk BIGINT PRIMARY KEY, user_id VARCHAR(50), user_name VARCHAR(100), address VARCHAR(200), is_current BOOLEAN, start_date DATE, end_date DATE );2. 用户行为分析的Data Vault实践用户行为数据的特点是数据量大、变化频繁。某社交平台日活用户3000万每天产生20亿条行为日志传统星型模型难以应对。2.1 Data Vault核心组件我们采用Data Vault模型后架构变得非常灵活中心表Hub示例CREATE TABLE hub_user ( user_hash_key VARCHAR(32) PRIMARY KEY, user_id VARCHAR(50), load_date TIMESTAMP, record_source VARCHAR(20) );链接表Link示例CREATE TABLE link_user_click ( user_click_hash_key VARCHAR(32) PRIMARY KEY, user_hash_key VARCHAR(32), page_hash_key VARCHAR(32), load_date TIMESTAMP );附属表Satellite示例CREATE TABLE sat_user_click_detail ( user_click_hash_key VARCHAR(32), click_time TIMESTAMP, stay_duration INT, device_type VARCHAR(50), load_date TIMESTAMP );2.2 实时数据处理方案对于用户行为数据我们采用Lambda架构实时层用KafkaFlink处理实时数据批处理层每天凌晨跑T1的完整数据服务层将实时和离线数据合并展示实测下来用户行为分析报表的延迟从原来的24小时降低到5分钟运营团队可以更快调整推广策略。3. 供应链管理的混合建模方案某零售企业的供应链系统包含2000多家供应商、500多个仓库数据关系极其复杂。我们采用了维度建模Data Vault的混合方案。3.1 库存管理模型设计库存是个典型的状态型指标我们采用周期快照事实表CREATE TABLE fact_inventory_daily ( product_sk BIGINT, warehouse_sk BIGINT, date_sk INT, quantity INT, cost_amount DECIMAL(18,2) ) PARTITIONED BY (dt STRING);3.2 供应商关系处理供应商之间存在复杂的股权关系我们用Data Vault模型来记录-- 供应商中心表 CREATE TABLE hub_supplier ( supplier_hash_key VARCHAR(32), supplier_code VARCHAR(50), load_date TIMESTAMP ); -- 供应商关系链接表 CREATE TABLE link_supplier_relation ( relation_hash_key VARCHAR(32), parent_supplier_hash_key VARCHAR(32), child_supplier_hash_key VARCHAR(32), relation_type VARCHAR(20), load_date TIMESTAMP );这种混合架构既满足了日常报表的查询性能需求又能灵活应对供应商关系的变更。4. 金融风控场景的特殊建模金融风控对数据时效性和历史追溯要求极高。我们为某银行设计的反欺诈系统需要处理以下特殊场景4.1 交易流水模型采用事务事实表记录每笔交易CREATE TABLE fact_transaction ( transaction_sk BIGINT, account_sk BIGINT, channel_sk INT, time_sk INT, transaction_id VARCHAR(50), amount DECIMAL(18,2), balance DECIMAL(18,2), status TINYINT );4.2 客户画像模型客户风险等级会随时间变化我们采用全量快照方式CREATE TABLE dim_customer_risk ( customer_sk BIGINT, risk_level TINYINT, credit_score INT, update_time TIMESTAMP ) PARTITIONED BY (dt STRING);每天凌晨跑批生成全量快照虽然存储成本高但查询效率提升明显复杂风控模型的运行时间从45分钟缩短到8分钟。
数仓建模实战：从理论到落地的四大核心场景
1. 电商交易场景的维度建模实战电商交易是数仓建模中最典型的业务场景之一。我去年帮一家跨境电商企业搭建数仓时发现他们每天有200多万笔订单数据但分散在10多个业务系统中。通过维度建模我们最终把查询效率提升了17倍。1.1 星型模型设计要点在设计电商交易星型模型时核心事实表就是订单事实表。这里有个坑要注意订单的粒度到底是按订单头还是订单行项我们当时选择了订单行项粒度因为一个订单可能包含多个商品优惠券抵扣、运费等金额需要分摊到每个商品便于后续分析单品销售情况订单事实表的关键字段包括CREATE TABLE fact_order ( order_sk BIGINT, -- 代理键 product_sk BIGINT, -- 商品维度外键 customer_sk BIGINT, -- 客户维度外键 date_sk INT, -- 日期维度外键 order_id VARCHAR(50), -- 原始订单ID quantity INT, -- 购买数量 price DECIMAL(18,2), -- 单价 amount DECIMAL(18,2), -- 总金额 coupon_amount DECIMAL(18,2) -- 优惠金额 );1.2 缓慢变化维处理用户维度是最典型的缓慢变化维。我们遇到过用户修改收货地址的情况这时候有3种处理方案类型1直接覆盖旧值适合不关心历史的情况类型2新增记录并标记生效时间最常用类型3保留有限历史版本如当前值和前一个值我们最终采用类型2方案用户维度表设计如下CREATE TABLE dim_user ( user_sk BIGINT PRIMARY KEY, user_id VARCHAR(50), user_name VARCHAR(100), address VARCHAR(200), is_current BOOLEAN, start_date DATE, end_date DATE );2. 用户行为分析的Data Vault实践用户行为数据的特点是数据量大、变化频繁。某社交平台日活用户3000万每天产生20亿条行为日志传统星型模型难以应对。2.1 Data Vault核心组件我们采用Data Vault模型后架构变得非常灵活中心表Hub示例CREATE TABLE hub_user ( user_hash_key VARCHAR(32) PRIMARY KEY, user_id VARCHAR(50), load_date TIMESTAMP, record_source VARCHAR(20) );链接表Link示例CREATE TABLE link_user_click ( user_click_hash_key VARCHAR(32) PRIMARY KEY, user_hash_key VARCHAR(32), page_hash_key VARCHAR(32), load_date TIMESTAMP );附属表Satellite示例CREATE TABLE sat_user_click_detail ( user_click_hash_key VARCHAR(32), click_time TIMESTAMP, stay_duration INT, device_type VARCHAR(50), load_date TIMESTAMP );2.2 实时数据处理方案对于用户行为数据我们采用Lambda架构实时层用KafkaFlink处理实时数据批处理层每天凌晨跑T1的完整数据服务层将实时和离线数据合并展示实测下来用户行为分析报表的延迟从原来的24小时降低到5分钟运营团队可以更快调整推广策略。3. 供应链管理的混合建模方案某零售企业的供应链系统包含2000多家供应商、500多个仓库数据关系极其复杂。我们采用了维度建模Data Vault的混合方案。3.1 库存管理模型设计库存是个典型的状态型指标我们采用周期快照事实表CREATE TABLE fact_inventory_daily ( product_sk BIGINT, warehouse_sk BIGINT, date_sk INT, quantity INT, cost_amount DECIMAL(18,2) ) PARTITIONED BY (dt STRING);3.2 供应商关系处理供应商之间存在复杂的股权关系我们用Data Vault模型来记录-- 供应商中心表 CREATE TABLE hub_supplier ( supplier_hash_key VARCHAR(32), supplier_code VARCHAR(50), load_date TIMESTAMP ); -- 供应商关系链接表 CREATE TABLE link_supplier_relation ( relation_hash_key VARCHAR(32), parent_supplier_hash_key VARCHAR(32), child_supplier_hash_key VARCHAR(32), relation_type VARCHAR(20), load_date TIMESTAMP );这种混合架构既满足了日常报表的查询性能需求又能灵活应对供应商关系的变更。4. 金融风控场景的特殊建模金融风控对数据时效性和历史追溯要求极高。我们为某银行设计的反欺诈系统需要处理以下特殊场景4.1 交易流水模型采用事务事实表记录每笔交易CREATE TABLE fact_transaction ( transaction_sk BIGINT, account_sk BIGINT, channel_sk INT, time_sk INT, transaction_id VARCHAR(50), amount DECIMAL(18,2), balance DECIMAL(18,2), status TINYINT );4.2 客户画像模型客户风险等级会随时间变化我们采用全量快照方式CREATE TABLE dim_customer_risk ( customer_sk BIGINT, risk_level TINYINT, credit_score INT, update_time TIMESTAMP ) PARTITIONED BY (dt STRING);每天凌晨跑批生成全量快照虽然存储成本高但查询效率提升明显复杂风控模型的运行时间从45分钟缩短到8分钟。
