企业官网建设流程全解析

简介：本资源是一份面向互联网行业数据工程师与数仓架构师的《数据仓库模型建设规范1.0》实操型技术文档，聚焦解决中大型企业级数据仓库物理建模混乱、分层职责不清、命名不统一等落地难题。文档系统定义了数聚模型的三层架构（L0准备层、L1原子层、L2应用层），详述各层表类型（临时表L0_TMP、接口表L0_DCI、维度表DW_DIM、原子事实表L1_DW_FACT、宽表L2_FACT等）的加载逻辑、历史处理策略、命名规范及开发要点，并对比Inmon与Kimball建模方法的适用场景，强调维度建模在稳定性、自适应性与可扩展性上的工程实践价值。资源为单个249KB的Word文档（.docx），内容完整覆盖从数据抽取清洗到OLAP支撑的全链路设计约束，结构清晰、术语规范、示例具体，便于团队快速对齐建模标准并落地实施。目前已有137人学习下载，适合正开展数仓体系建设或需统一建模口径的中高级数据研发人员参考使用。

1. 这份《数据仓库模型建设规范1.0》不是文档模板，而是数仓团队的“施工红线图”

你刚接手一个互联网公司新立项的数据中台项目，ODS层刚接完12个业务系统的日志和数据库Binlog，但开发组在建L1层时卡住了：维表要不要加代理键？事实表的粒度定到“用户单次点击”还是“用户日汇总”？临时表命名该用TMP_POS_ORDER还是L0_TMP_POS_ORDER？没人敢拍板——因为没人知道哪个选择会把后续3个月的ETL任务拖进性能泥潭。这份《数据仓库模型建设规范1.0》要解决的，正是这种“技术决策真空”：它不教你怎么写SQL，而是用可执行的命名规则、强制的字段清单、分层的数据流向图，把模糊的“应该怎么做”变成明确的“必须怎么建”。它面向的是正在落地真实互联网业务（如电商订单履约、用户行为分析、广告效果归因）的数仓工程师，尤其适合那些已跑通数据接入但正面临模型混乱、口径不一、查询变慢的中型团队。规范里没有空泛的“高可用”“高性能”口号，所有条款都指向一个结果：当BI同事问“上月华东区新客复购率是多少”，你能5分钟内从L1原子事实表+组织维+时间维精准定位到那张表、那个字段、那个分区。

2. 数聚三层架构：L0/L1/L2不是概念分层，而是数据生命周期的硬性阶段切分

数聚模型将数据仓库划分为准备层（L0）、原子层（L1）和应用层（L2），这三层不是逻辑抽象，而是物理隔离的数据处理阶段，每一层都有不可绕过的数据结构、强制的命名规则和明确的加工边界。跳过某一层或混淆层间职责，是导致后续模型崩坏的最常见原因。

2.1 L0准备层：临时表与接口表的“双轨制”数据落地机制

L0层的核心矛盾是源系统数据原始性与下游加工可用性之间的张力。规范强制采用“临时表→接口表→转换表”的三段式落地流程，杜绝直接从源库抽取后直连L1的做法。

• 临时表（L0_TMP_）：仅保存本次抽取的快照数据，无历史保留。全量抽取时存源表全量；增量抽取时只存自上次抽取以来变更的记录（依赖源系统流水号或时间戳）。其存在意义是为清洗提供“无污染”的原始沙盒。

• 接口表（L0_DCI_）：必须保存完整历史。即使源系统做全量抽取，接口表也需通过MERGE或UPSERT逻辑保证历史数据不丢失。这是L0层最关键的契约：下游任何模块（包括L1维度建模）都只能读取接口表，不得跨层访问临时表。

• 转换表（L0_MAP_）：纯中间产物，用于复杂清洗逻辑（如多源地址标准化、敏感字段脱敏、空值填充策略）。规范要求其命名必须体现映射关系，例如L0_MAP_USER_CONTACT表示用户联系方式清洗逻辑。

提示：互联网场景下高频出现的“用户设备ID跨天漂移”问题，必须在L0_MAP层解决。不能等到L1再处理——因为L1事实表粒度若定为“日”，则漂移ID会导致同一天产生两条冲突记录。正确做法是在L0_MAP_USER_DEVICE中增加device_id_fingerprint字段，用UA+IP+设备特征生成稳定指纹，此逻辑必须固化在转换表脚本中。

2.1.1 L0层命名规范与实操校验表

规范对L0层命名有强约束，违反即视为模型缺陷。以下为关键命名规则及验证命令（以Oracle为例）：

执行上述SQL后，若返回空集，说明存在命名违规表，必须立即整改。互联网业务中，订单、支付、用户行为等核心主题的接口表命名一致性，直接影响后续L1层维度关联的准确性。

2.2 L1原子层：维度表与事实表的“宪法级”字段清单

L1层是模型稳定性的基石。规范对维度表和事实表提出不可协商的字段要求，这些字段不是“建议添加”，而是“缺失即不可上线”。

2.2.1 维度表强制字段与互联网典型实现

维度表必须包含以下6个字段，缺一不可：

-- 创建电商用户维度表的标准DDL（Oracle） CREATE TABLE DW_DIM_USER ( DIM_KEY INTEGER PRIMARY KEY, KEY_STARTDATE DATE NOT NULL, KEY_ENDDATE DATE NOT NULL, CURRENT_FLAG CHAR(1) NOT NULL CHECK (CURRENT_FLAG IN ('Y','N')), BUSINESS_KEY VARCHAR2(50) NOT NULL, DIM_NAME VARCHAR2(100) NOT NULL, GENDER VARCHAR2(10), CITY VARCHAR2(50), REGISTER_TIME DATE, -- 其他属性... CONSTRAINT PK_DIM_USER PRIMARY KEY (DIM_KEY) ); -- 强制索引：位图索引适用于低基数字段（如GENDER、CURRENT_FLAG） CREATE BITMAP INDEX IDX_DIM_USER_GENDER ON DW_DIM_USER(GENDER); CREATE BITMAP INDEX IDX_DIM_USER_CURRFLAG ON DW_DIM_USER(CURRENT_FLAG);

注意：互联网用户维常含“设备类型”“渠道来源”等动态属性，规范要求这些必须作为维度属性（非代理键）存在，而非拆分成独立小维表。例如DEVICE_TYPE字段值为'IOS'/'ANDROID'/'WEB'，直接放在DW_DIM_USER中，避免为每个属性建维表导致关联爆炸。

2.2.2 事实表类型选择：事务事实表 vs 快照事实表的决策树

事实表类型决定数据粒度和存储成本。规范给出明确判断路径：

• 选事务事实表：当业务过程是离散事件，且需分析事件链路时。
  ✅ 适用场景：用户点击流（click_id,page_url,event_time）、订单创建（order_id,product_id,create_time）、支付成功（pay_id,amount,pay_time）。
  ❌ 禁止场景：计算“账户余额”——因为余额是状态，非事件。

• 选快照事实表：当需分析某个时间点的状态快照，且状态变化频率可控时。
  ✅ 适用场景：每日用户留存快照（stat_date,user_key,is_retained_7d）、每月商品库存快照（stat_month,product_key,stock_qty）。
  ❌ 禁止场景：实时风控评分——因快照周期无法满足毫秒级响应。

-- 电商用户日点击事务事实表（L1_DW_FACT_USER_CLICK） CREATE TABLE L1_DW_FACT_USER_CLICK ( FACT_KEY INTEGER PRIMARY KEY, USER_KEY INTEGER NOT NULL, -- 关联DW_DIM_USER.DIM_KEY PAGE_KEY INTEGER NOT NULL, -- 关联DW_DIM_PAGE.DIM_KEY CLICK_TIME DATE NOT NULL, SESSION_ID VARCHAR2(100), DURATION_SEC NUMBER(10), -- 事实指标（完全可加性） CLICK_COUNT NUMBER(5) DEFAULT 1, -- 外键索引（位图索引提升OLAP查询） CONSTRAINT FK_FACT_USER_CLICK_USER FOREIGN KEY (USER_KEY) REFERENCES DW_DIM_USER(DIM_KEY), CONSTRAINT FK_FACT_USER_CLICK_PAGE FOREIGN KEY (PAGE_KEY) REFERENCES DW_DIM_PAGE(DIM_KEY) ); -- 创建位图索引（针对高并发聚合查询） CREATE BITMAP INDEX IDX_FACT_CLICK_USERKEY ON L1_DW_FACT_USER_CLICK(USER_KEY); CREATE BITMAP INDEX IDX_FACT_CLICK_PAGEKEY ON L1_DW_FACT_USER_CLICK(PAGE_KEY); CREATE INDEX IDX_FACT_CLICK_TIME ON L1_DW_FACT_USER_CLICK(CLICK_TIME) LOCAL;

提示：互联网埋点数据量极大，事务事实表必须按时间分区（如PARTITION BY RANGE (CLICK_TIME)）。规范要求分区粒度与业务分析需求对齐——若90%查询按“日”过滤，则用日分区；若需高频查“小时趋势”，则必须细化到小时分区，否则全表扫描将拖垮集群。

3. 维度建模实战：从电商订单业务过程到星形模式的四步推演

维度建模不是画ER图，而是将业务语言翻译成可执行的数据结构。规范强调的“四步法”必须严格遵循，跳步即埋坑。我们以互联网电商“订单履约”业务过程为例，演示如何落地。

3.1 第一步：锁定业务过程——拒绝模糊需求，定义原子事件

业务方说：“我们要看订单数据”。这不够。规范要求必须拆解为不可再分的业务过程。电商订单履约链条包含：

• ORDER_CREATED（订单创建）
• PAYMENT_RECEIVED（支付成功）
• WAREHOUSE_PICKED（仓库拣货）
• LOGISTICS_DISPATCHED（物流发货）
• CUSTOMER_RECEIVED（客户签收）

关键决策：本模型聚焦ORDER_CREATED过程。理由：它是所有后续状态的源头，且互联网订单创建事件具有强时效性（秒级）、高价值（GMV核心）、低歧义（支付前状态最稳定）。

注意：若同时建PAYMENT_RECEIVED事实表，必须确保其ORDER_KEY与ORDER_CREATED表中的ORDER_KEY完全一致（同一代理键），否则多事实表关联将产生笛卡尔积。规范强制要求所有订单相关事实表共享同一订单维度代理键体系。

3.2 第二步：声明粒度——用一句话定义事实表每一行的含义

粒度声明是建模成败的分水岭。错误示例：“订单数据”——太模糊。
正确声明（规范要求书面写入设计文档）：
“L1_DW_FACT_ORDER_CREATED事实表的每一行，代表一个用户在某一时刻创建的一个订单，粒度为‘单订单单商品’（即一个订单含多个商品时，拆分为多行）。”

此声明直接决定：

• 维度选择：必须包含USER_KEY（用户）、TIME_KEY（创建时间）、PRODUCT_KEY（商品）、ORDER_KEY（订单主键）；
• 事实选择：ORDER_AMOUNT（订单金额）、QUANTITY（商品数量）必须是单行可加的；
• 排除项：ORDER_TOTAL_AMOUNT（订单总金额）不能作为事实，因为它在“单商品行”上无意义。

3.3 第三步：选定维度——从粒度反推最小维度集合

根据“单订单单商品”粒度，强制存在的维度有：

• DW_DIM_USER（用户维度）：提供用户画像（新老客、地域、设备）
• DW_DIM_TIME（时间维度）：提供DAY_KEY、HOUR_KEY、WEEK_KEY
• DW_DIM_PRODUCT（商品维度）：提供类目、品牌、价格带
• DW_DIM_ORDER（订单维度）：提供订单类型（普通/团购/预售）、渠道（APP/小程序/H5）

提示：互联网场景中，“订单维度”常被忽略。但规范强调：订单类型、优惠类型（满减/折扣券/红包）、配送方式（快递/同城急送）等强分析属性，必须沉淀为独立维度表，而非塞进事实表。原因：维度表可建立层次结构（如ORDER_TYPE → SUB_TYPE），支持钻取分析；而事实表字段无法分层。

3.4 第四步：确定事实——区分可加性、半可加性与非可加性

事实必须严格匹配粒度。对ORDER_CREATED事实表：

• 完全可加性事实（可任意维度聚合）：
  QUANTITY（商品数量）、DISCOUNT_AMOUNT（单品优惠额）——按用户、时间、商品类目求和均有业务意义。
• 半可加性事实（仅部分维度可加）：
  ORDER_AMOUNT（订单金额）——按用户、商品类目可加；但按时间维度加总“日订单金额”有意义，加总“小时订单金额”可能失真（因跨小时订单被重复计算）。
• 非可加性事实（禁止放入事实表）：
  ORDER_STATUS（订单状态码）、PROMOTION_NAME（促销名称）——这些是描述性属性，必须移入DW_DIM_ORDER维度表。

-- L1_DW_FACT_ORDER_CREATED标准结构（关键事实字段） CREATE TABLE L1_DW_FACT_ORDER_CREATED ( FACT_KEY INTEGER PRIMARY KEY, ORDER_KEY INTEGER NOT NULL, -- 订单维度代理键 USER_KEY INTEGER NOT NULL, -- 用户维度代理键 PRODUCT_KEY INTEGER NOT NULL, -- 商品维度代理键 TIME_KEY INTEGER NOT NULL, -- 时间维度代理键（如20231001） QUANTITY NUMBER(10) NOT NULL, -- 完全可加 DISCOUNT_AMOUNT NUMBER(12,2), -- 完全可加 ORDER_AMOUNT NUMBER(12,2), -- 半可加（按订单维度聚合时需去重） -- 外键约束 CONSTRAINT FK_FACT_ORD_USER FOREIGN KEY (USER_KEY) REFERENCES DW_DIM_USER(DIM_KEY), CONSTRAINT FK_FACT_ORD_PROD FOREIGN KEY (PRODUCT_KEY) REFERENCES DW_DIM_PRODUCT(DIM_KEY), CONSTRAINT FK_FACT_ORD_TIME FOREIGN KEY (TIME_KEY) REFERENCES DW_DIM_DATE(DATE_KEY) );

4. 缓慢变化维（SCD）的五种实现模式：互联网高频变更场景的选型指南

互联网业务中，用户属性（手机号、地址）、商品属性（价格、类目）、组织属性（部门归属、汇报线）频繁变更。若不处理，历史分析将失真。规范定义了5种SCD模式，每种对应特定变更场景，选错即导致数据口径灾难。

4.1 SCD Type 1：覆盖更新——仅适用于“不关心历史”的元数据

适用场景：维度表中纯粹的元数据修正，如用户维中DIM_NAME拼写错误（"张三丰"→"张三丰"）、商品维中BRAND_NAME笔误（"苹国"→"苹果"）。
操作：直接UPDATE原记录，不新增行，不修改KEY_STARTDATE。
风险：若误用于业务属性（如用户城市变更），将导致历史订单全部归属到新城市。

-- 修正用户昵称（Type 1） UPDATE DW_DIM_USER SET DIM_NAME = '张三丰', KEY_MODIFYDATE = SYSDATE WHERE BUSINESS_KEY = 'U123456' AND CURRENT_FLAG = 'Y';

4.2 SCD Type 2：新增版本——互联网最常用模式，支撑“时间旅行”分析

适用场景：用户城市变更、商品类目调整、员工部门调动等需保留历史轨迹的变更。
核心机制：新记录插入，原记录KEY_ENDDATE置为变更时间，CURRENT_FLAG='N'；新记录KEY_STARTDATE为变更时间，CURRENT_FLAG='Y'。
互联网特化：规范要求KEY_STARTDATE/KEY_ENDDATE必须精确到秒，并建立组合索引。

-- 用户U123456从北京调至上海（Type 2） -- 步骤1：失效原记录 UPDATE DW_DIM_USER SET KEY_ENDDATE = TO_DATE('2023-10-01 09:15:22', 'YYYY-MM-DD HH24:MI:SS'), CURRENT_FLAG = 'N', KEY_MODIFYDATE = SYSDATE WHERE BUSINESS_KEY = 'U123456' AND CURRENT_FLAG = 'Y'; -- 步骤2：插入新记录 INSERT INTO DW_DIM_USER ( DIM_KEY, KEY_STARTDATE, KEY_ENDDATE, CURRENT_FLAG, BUSINESS_KEY, DIM_NAME, CITY ) VALUES ( SEQ_DIM_USER.NEXTVAL, TO_DATE('2023-10-01 09:15:22', 'YYYY-MM-DD HH24:MI:SS'), TO_DATE('9999-12-31', 'YYYY-MM-DD'), 'Y', 'U123456', '张三丰', '上海' );

提示：Type 2模式下，事实表关联维度必须带上时间条件。例如查“2023年9月北京用户订单”，SQL必须为：
FROM L1_DW_FACT_ORDER_CREATED f JOIN DW_DIM_USER u ON f.USER_KEY = u.DIM_KEY AND f.TIME_KEY BETWEEN u.KEY_STARTDATE AND u.KEY_ENDDATE
若漏掉时间条件，将关联到所有版本，导致订单重复计数。

4.3 SCD Type 3：新旧字段并存——适用于“最多两次变更”的轻量场景

适用场景：用户手机号变更（通常一生换1-2次）、商品主图URL更新。
结构：在维度表中增加OLD_PHONE、NEW_PHONE、PHONE_CHANGE_DATE字段。
优势：无需关联历史表，查询简单；存储开销小。
限制：规范明文禁止用于超过2次变更的属性（如用户地址变更超2次，必须用Type 2）。

-- 用户维扩展（Type 3） ALTER TABLE DW_DIM_USER ADD ( OLD_MOBILE VARCHAR2(20), NEW_MOBILE VARCHAR2(20), MOBILE_CHANGE_DATE DATE );

4.4 SCD Type 4：历史拉链表——专治“层级结构深度变更”的互联网顽疾

适用场景：组织架构调整（如事业部拆分）、区域行政划分变更（如“江苏南京”→“江苏南京市玄武区”）、产品类目树重构。
机制：单独建DW_DIM_ORG_HIST历史表，记录每次组织变更的快照；主维表DW_DIM_ORG只存当前结构。
互联网价值：解决“某订单归属哪个组织”的历史性难题。例如2023年Q1订单应归属原“华东大区”，Q2后归属新“华东销售部”，历史表可精准回溯。

-- 组织历史表（Type 4） CREATE TABLE DW_DIM_ORG_HIST ( HIST_KEY INTEGER PRIMARY KEY, ORG_KEY INTEGER NOT NULL, -- 关联主维表ORG_KEY ORG_CODE VARCHAR2(20), ORG_NAME VARCHAR2(100), PARENT_ORG_CODE VARCHAR2(20), EFFECTIVE_DATE DATE NOT NULL, EXPIRE_DATE DATE NOT NULL, IS_CURRENT CHAR(1) CHECK (IS_CURRENT IN ('Y','N')) );

4.5 SCD Type 6：混合模式——互联网复杂场景的终极方案

适用场景：需同时满足“快速查当前值”+“精准查历史值”+“支持多版本对比”的高阶需求，如风控模型中的用户信用等级变更、推荐算法中的用户兴趣标签演化。
结构：融合Type 1（当前值）、Type 2（历史版本）、Type 3（最近两次变更）于一体。规范要求必须包含CURRENT_VALUE、HIST_VERSION、PREV_VALUE三字段。

-- 用户信用等级维（Type 6） CREATE TABLE DW_DIM_CREDIT_LEVEL ( DIM_KEY INTEGER PRIMARY KEY, BUSINESS_KEY VARCHAR2(50) NOT NULL, CURRENT_LEVEL VARCHAR2(20), -- Type 1：当前等级 PREV_LEVEL VARCHAR2(20), -- Type 3：上一次等级 LEVEL_CHANGE_DT DATE, -- Type 3：上次变更时间 HIST_VERSION INTEGER, -- Type 2：历史版本号 START_DT DATE, -- Type 2：生效时间 END_DT DATE, -- Type 2：失效时间 CURRENT_FLAG CHAR(1) -- Type 2：当前标识 );

提示：Type 6虽强大，但规范强制要求“仅在业务方书面确认需多版本对比时启用”。因其维护成本最高，互联网团队常因滥用导致维度表膨胀。实际项目中，80%场景用Type 2即可覆盖。

5. 数据库物理设计：位图索引、分区与统计信息的互联网级调优实践

规范第6章的数据库设计条款，不是纸上谈兵。在互联网海量数据场景下，一个索引类型选错、一个分区键设偏、一次统计信息未更新，都可能让TB级查询从秒级退化到小时级。

5.1 维度表索引：位图索引（Bitmap Index）是OLAP查询的加速器

互联网分析常需多维交叉过滤（如“上海女性用户在iOS端点击首页Banner”），此时B-tree索引效率低下。规范强制要求：

• 所有低基数维度属性（GENDER、DEVICE_TYPE、CURRENT_FLAG）必须建位图索引；
• 高基数字段（USER_NAME、EMAIL）禁用位图索引（易引发锁争用）；
• 维度表主键DIM_KEY必须建B-tree唯一索引。

-- 电商用户维索引策略（Oracle） -- 位图索引：低基数字段，支持AND/OR高效合并 CREATE BITMAP INDEX IDX_DIM_USER_GENDER ON DW_DIM_USER(GENDER); CREATE BITMAP INDEX IDX_DIM_USER_DEVICE ON DW_DIM_USER(DEVICE_TYPE); CREATE BITMAP INDEX IDX_DIM_USER_CURRFLAG ON DW_DIM_USER(CURRENT_FLAG); -- B-tree索引：主键和高基数字段 CREATE UNIQUE INDEX PK_DIM_USER ON DW_DIM_USER(DIM_KEY); CREATE INDEX IDX_DIM_USER_EMAIL ON DW_DIM_USER(EMAIL); -- 仅当需按邮箱查询时

注意：位图索引在高并发DML场景下有锁粒度问题。规范要求互联网业务中，维度表加载必须在业务低峰期（如凌晨2-4点）批量执行，并在加载后立即重建位图索引，避免在线更新导致索引失效。

5.2 事实表分区：按时间分区是互联网数据的生命线

TB级事实表若不分区，单次全表扫描将耗尽集群资源。规范规定：

• 事务事实表必须按TIME_KEY（如CLICK_TIME）范围分区，粒度与业务分析周期一致；
• 快照事实表按STAT_DATE（如20231001）列表分区；
• 分区键必须是事实表中真实存在的字段，禁止用函数（如TRUNC(CLICK_TIME)）。

-- 用户点击事实表（日分区） CREATE TABLE L1_DW_FACT_USER_CLICK ( FACT_KEY INTEGER, USER_KEY INTEGER, CLICK_TIME DATE, ... ) PARTITION BY RANGE (CLICK_TIME) ( PARTITION P_20230901 VALUES LESS THAN (TO_DATE('2023-09-02', 'YYYY-MM-DD')), PARTITION P_20230902 VALUES LESS THAN (TO_DATE('2023-09-03', 'YYYY-MM-DD')), PARTITION P_20230903 VALUES LESS THAN (TO_DATE('2023-09-04', 'YYYY-MM-DD')), PARTITION P_MAX VALUES LESS THAN (MAXVALUE) );

5.3 装载后统计信息：ANALYZE TABLE不是可选项，是上线必检项

数据库优化器依赖统计信息生成执行计划。互联网场景中，ETL任务常批量插入百万级数据，若未更新统计信息，优化器仍按旧数据量估算，导致选择全表扫描而非索引扫描。

-- 规范强制要求：每次L1层表装载完成后执行 ANALYZE TABLE L1_DW_FACT_USER_CLICK COMPUTE STATISTICS FOR ALL COLUMNS SIZE AUTO; ANALYZE TABLE DW_DIM_USER COMPUTE STATISTICS FOR ALL COLUMNS SIZE AUTO; -- 验证统计信息是否更新（Oracle） SELECT table_name, num_rows, last_analyzed FROM user_tables WHERE table_name IN ('L1_DW_FACT_USER_CLICK', 'DW_DIM_USER');

提示：互联网团队常因疏忽遗漏此步。规范要求将ANALYZE语句嵌入ETL作业末尾，并设置告警——若last_analyzed时间早于当前ETL任务开始时间，则触发企业微信告警。这是保障查询性能的最后一道防线。

本文还有配套的精品资源，点击获取