企业官网建设流程全解析

简介：本资源是阿里集团内部数据研发团队制定的《数据模型设计规范》官方文档，面向数据工程师、数仓开发人员及企业级数据平台建设者，系统解决多业务线数据建模标准不一、复用性低、维护成本高等核心问题。文档完整覆盖维度建模全流程——从业务需求分析、维度与事实表设计、粒度与类型定义，到模型优化、标准化治理、文档编写及版本控制机制，特别强化了可落地的实施约束与协同规范。资源为单文件Word文档（.docx），共1个文件，大小6.14MB，内容结构清晰，含前言、目录及14页核心章节，其中维度建模部分占比较大，便于快速定位关键设计原则与实操要点。目前已有287人学习下载，读者可直接获取阿里系成熟的数据建模方法论、标准化模板框架及配套管理要求，适用于中大型组织数据中台建设、模型评审体系建设与新人培养体系搭建。

1. 为什么一份数据模型设计规范，比写一百个 SQL 还重要？

在阿里集团内部，一个新业务上线前，DBA 不会先建库，数据平台工程师不会急着搭任务调度，ETL 开发者也不会立刻写清洗脚本——所有人第一件事，是打开《数据模型设计规范.docx》，逐条核对「主题域划分是否符合三层架构」「维度表主键是否采用代理键+业务键双标识」「事实表粒度声明是否精确到「单次用户点击行为」还是「日汇总订单金额」」。这不是流程形式主义，而是因为过去十年里，阿里每一起跨部门数据口径争议、每一次报表指标跳变、每一例数仓分层混乱导致的链路不可追溯，最终根因都指向模型设计阶段的模糊地带：比如「GMV」在营销域定义为「支付成功订单金额」，在财务域却按「开票金额」统计；又比如一张「用户行为快照表」未声明快照周期，下游误用为全量宽表，导致月报数据重复计算。这份文档不是教科书，而是一套可执行、可校验、可审计的工程契约——它把抽象的数据语义，翻译成字段命名规则、主外键约束、血缘标注方式、甚至 Excel 模板里的下拉选项。适合所有参与数据资产建设的角色：数据产品经理要据此定义指标口径，开发工程师靠它生成 DDL 脚本，质量工程师用它编写元数据校验规则，而数据治理团队则直接将其中 37 条检查项嵌入 CI/CD 流水线。它解决的从来不是「怎么建表」，而是「建出来的表，能否被整个组织一致理解、稳定消费、长期演进」。

2. 主题域与分层体系：从「业务语言」到「技术结构」的强制映射

阿里数据模型设计规范的核心骨架，是主题域（Subject Area）与分层（Layer）的二维强约束。这不是简单的文件夹分类，而是通过明确的边界定义，切断业务需求与物理实现之间的随意映射。主题域代表业务视角的聚合单元，如「用户」、「商品」、「交易」、「内容」、「营销」；分层则代表数据加工深度，严格限定为四层：ODS（操作数据存储）、DWD（明细数据层）、DWS（汇总数据层）、ADS（应用数据层）。关键在于，任何一张表必须且只能归属一个主题域和一个分层，禁止出现「user_trade_dwd」这种跨域混搭命名，也禁止「dwd_user_behavior」与「dws_user_summary」共存于同一物理库中。

2.1 主题域划分的三个不可逾越原则

主题域不是按系统拆分，而是按业务实体生命周期归集。规范明确要求：

• 单一责任原则：一个主题域内只描述一类核心业务实体及其直接关联行为。例如「用户」域包含用户注册、登录、实名认证、会员等级变更等事件，但绝不包含「用户购买商品」这一行为——该行为属于「交易」域，即使其主键是 user_id。
• 无交叉引用原则：主题域间通过标准主键（如 user_sk、item_sk）关联，禁止跨域冗余存储字段。常见错误是「商品域」表中冗余存储「所属类目名称」，正确做法是仅保留 category_id，并通过维度表关联获取名称。
• 演进隔离原则：当业务发生重大调整（如「直播电商」独立为新业务线），必须新建主题域「直播」，而非在「交易」域下新增直播相关表。历史表保持只读，新模型走全新路径。

提示：主题域清单在规范附录中以 Excel 表格固化，包含中英文名称、业务负责人、数据Owner、首次上线时间。每次新增主题域需经数据治理委员会评审，评审材料必须包含该域与其他域的边界说明图（Mermaid 语法绘制，非手绘）。

2.2 四层模型的物理隔离与加工规则

分层不是逻辑概念，而是物理库、Schema、甚至计算引擎的硬隔离。规范强制规定各层的建表语法、分区策略与权限模型：

2.2.1 DWD 层建表示例与参数解析

CREATE TABLE IF NOT EXISTS dwd_user_profile_di ( user_sk BIGINT COMMENT '用户代理键，全局唯一', user_id STRING COMMENT '业务主键，来自源系统', gender STRING COMMENT '性别，枚举值：M/F/UNKNOWN', age_group STRING COMMENT '年龄分组，枚举值：UNDER18/18_24/25_34/35_44/45_54/55PLUS', city_tier STRING COMMENT '城市等级，枚举值：FIRST_TIER/SECOND_TIER/THIRD_TIER/OTHER', dt STRING COMMENT '分区字段：业务日期' ) COMMENT '用户基础档案日快照表，粒度：每个用户每日一条记录' PARTITIONED BY (dt STRING) STORED AS PARQUET TBLPROPERTIES ( 'auto.purge' = 'true', 'creator' = 'data_engineer_team', 'owner' = 'user_domain_owner@alibaba-inc.com' );

• auto.purge='true'：启用自动分区清理，避免历史测试分区堆积；
• COMMENT字段必须完整描述业务含义，且枚举值需与规范附录中的标准字典完全一致（如FIRST_TIER不可写作Tier1）；
• user_sk与user_id必须同时存在，前者用于模型关联，后者用于业务溯源；
• 表名后缀_di明确标识为「日粒度」（Daily Incremental），若为全量快照则用_df（Daily Full）。

3. 维度建模落地：从「字段列表」到「可执行的维度表模板」

维度建模不是画星型图，而是将业务概念转化为具备强约束的物理表结构。阿里规范将维度表分为「缓慢变化维度（SCD）」与「快速变化维度（FCD）」两类，并为每类提供标准化建模模板。关键不在于理论分类，而在于每种类型对应的 DDL 语法、ETL 加工逻辑、以及下游消费时的 SQL 写法。

3.1 缓慢变化维度（SCD）的 Type2 实现规范

Type2 是阿里最常用的 SCD 类型，要求保留历史版本。规范强制要求：

• 必有字段：sk（代理键）、bk（业务键）、start_dt（生效日期）、end_dt（失效日期）、is_current（当前有效标识）；
• 分区策略：按dt分区，但start_dt/end_dt必须为普通字段，禁止作为分区字段；
• 状态管理：end_dt默认值为'99991231'，is_current为'Y'或'N'，禁止使用布尔类型。

3.1.1 商品维度表（dwd_item_dim）DDL 示例

CREATE TABLE IF NOT EXISTS dwd_item_dim ( item_sk BIGINT COMMENT '商品代理键', item_id STRING COMMENT '商品业务ID', item_name STRING COMMENT '商品名称', brand_name STRING COMMENT '品牌名称', category_l1 STRING COMMENT '一级类目', category_l2 STRING COMMENT '二级类目', price DECIMAL(18,2) COMMENT '当前售价', start_dt STRING COMMENT '生效日期，格式 yyyyMMdd', end_dt STRING COMMENT '失效日期，格式 yyyyMMdd', is_current STRING COMMENT '是否当前有效：Y/N', dt STRING COMMENT '分区字段：快照生成日期' ) COMMENT '商品维度表，SCD Type2 实现' PARTITIONED BY (dt STRING) STORED AS PARQUET;

注意：start_dt和end_dt的值必须由上游 ETL 任务精确计算，例如当商品价格变更时，原记录end_dt更新为变更前一日，新记录start_dt设为变更当日，is_current='Y'。规范要求所有 SCD 表的 ETL 任务必须输出change_type字段（INSERT/UPDATE/DELETE），用于下游血缘追踪。

3.2 快速变化维度（FCD）的轻量级建模

针对日志类、行为类高频更新维度（如「用户实时地理位置」），规范禁止使用 SCD，而要求采用 FCD 模式：仅保留最新状态，通过时间戳字段记录最后更新时间，且不保留历史版本。核心约束是：

• 必有字段：sk、bk、last_update_time（毫秒级时间戳）；
• 分区策略：按dt分区，last_update_time仅为字段，不参与分区；
• 消费约束：下游查询必须加WHERE last_update_time >= unix_timestamp() - 3600 * 24 * 7 * 1000（近7天），禁止全表扫描。

3.2.1 用户实时位置维度（dwd_user_location_fcd）建模要点

-- 建表时无需 start_dt/end_dt，但必须有 last_update_time CREATE TABLE IF NOT EXISTS dwd_user_location_fcd ( user_sk BIGINT, user_id STRING, province STRING, city STRING, district STRING, gps_longitude DECIMAL(10,7), gps_latitude DECIMAL(10,7), last_update_time BIGINT COMMENT '最后更新时间，毫秒时间戳', dt STRING ) PARTITIONED BY (dt STRING) STORED AS PARQUET; -- 下游消费必须带时间过滤，规范已将其固化为 BI 工具的默认 SQL 模板 SELECT user_id, province, city FROM dwd_user_location_fcd WHERE dt = '20240520' AND last_update_time >= unix_timestamp() - 3600 * 24 * 7 * 1000;

• last_update_time类型必须为BIGINT，单位毫秒，禁止使用STRING或TIMESTAMP；
• 规范要求所有 FCD 表的last_update_time字段，在写入时必须调用unix_timestamp(current_timestamp()) * 1000计算，确保精度统一；
• 若业务需要历史轨迹，必须新建独立的事实表（如dwd_user_gps_trace_f），而非在维度表中堆砌历史记录。

4. 事实表设计：粒度声明、代理键约束与可验证的度量定义

事实表是数据模型的「心脏」，其设计质量直接决定指标计算的准确性与扩展性。阿里规范将事实表分为「事务事实表」、「周期快照事实表」、「累计快照事实表」三类，并为每类定义了不可妥协的建模规则。核心思想是：粒度（Granularity）必须可验证、可追溯、不可歧义。

4.1 粒度声明的强制语法与校验机制

规范要求所有事实表的COMMENT字段必须以「粒度：」开头，且描述必须精确到最小业务事件。例如：

• ✅ 正确：COMMENT '粒度：每个用户在每个商品详情页的单次曝光行为'
• ❌ 错误：COMMENT '用户商品曝光数据'（未声明粒度）
• ❌ 错误：COMMENT '粒度：用户曝光'（未绑定商品、未说明是单次还是汇总）

更关键的是，规范配套提供了自动化校验脚本，通过解析 Hive Metastore 获取表注释，正则匹配粒度：(.+)，并比对预设的粒度词典。若发现未声明或声明模糊，CI 流水线直接失败。

4.1.1 事务事实表（dwd_user_item_exposure_f）建模实例

CREATE TABLE IF NOT EXISTS dwd_user_item_exposure_f ( exposure_sk BIGINT COMMENT '曝光代理键', user_sk BIGINT COMMENT '用户代理键，关联 dwd_user_dim', item_sk BIGINT COMMENT '商品代理键，关联 dwd_item_dim', exposure_time BIGINT COMMENT '曝光时间戳，毫秒', position INT COMMENT '曝光位置，从1开始编号', is_first_view STRING COMMENT '是否首屏曝光：Y/N', dt STRING COMMENT '分区字段：曝光发生日期' ) COMMENT '粒度：每个用户在每个商品详情页的单次曝光行为' PARTITIONED BY (dt STRING) STORED AS PARQUET TBLPROPERTIES ('creator' = 'recommendation_team');

• exposure_sk为自增代理键，禁止使用user_id+item_id+exposure_time拼接，确保唯一性；
• 所有外键（user_sk,item_sk）必须显式声明COMMENT关联目标表，这是血缘自动解析的基础；
• position字段必须为INT，且业务含义明确（如信息流第3位、搜索结果第1位），禁止存储「位置ID」等模糊字符串。

4.2 度量（Measure）字段的命名与类型规范

度量字段不是随便起个名字就行。规范定义了严格的命名前缀与类型映射：

4.2.1 交易事实表（dwd_trade_f）中金额字段的合规写法

CREATE TABLE IF NOT EXISTS dwd_trade_f ( trade_sk BIGINT, user_sk BIGINT, item_sk BIGINT, trade_time BIGINT, amt_gmv DECIMAL(18,2) COMMENT 'GMV金额，单位：元，精确到分', amt_payment DECIMAL(18,2) COMMENT '实付金额，单位：元，精确到分', amt_discount DECIMAL(18,2) COMMENT '优惠金额，单位：元，精确到分', cnt_item BIGINT COMMENT '商品件数', dt STRING ) COMMENT '粒度：每笔支付成功的订单' PARTITIONED BY (dt STRING) STORED AS PARQUET;

• amt_gmv等字段的COMMENT必须包含「单位」和「精度」，这是财务对账的法律依据；
• 规范禁止在事实表中存储「计算字段」，如pct_discount = amt_discount / amt_gmv，此类比率必须在 DWS 层通过 SQL 计算；
• 所有DECIMAL字段的精度必须严格匹配，DECIMAL(18,2)表示最多 16 位整数 + 2 位小数，超出则写入失败。

5. 模型交付与验证：从 Excel 模板到自动化流水线的闭环

模型设计不是写完文档就结束，而是必须完成「设计-建表-填充-验证-发布」的端到端闭环。阿里规范将这一过程固化为可执行的交付物清单与自动化校验点，确保模型从纸面走向生产环境时，零歧义、零遗漏、零手工。

5.1 模型交付的四大强制文件

每套新模型上线，必须提交以下四个文件，缺一不可：

1. Excel 模型设计表：使用规范提供的.xlsx模板，包含「表名、中文名、主题域、分层、粒度声明、字段列表（含类型、长度、枚举值、是否主键）、外键关系图」；
2. Hive DDL 脚本：与 Excel 完全一致的建表语句，文件名格式dwd_xxx_f_ddl.sql；
3. 元数据注册 JSON：符合 OpenMetadata Schema 的 JSON 文件，包含name、description、tags、columns、lineage字段；
4. 血缘影响分析报告：Markdown 格式，说明本次建表对现有 DWS/ADS 层哪些报表、哪些 API 产生影响，影响范围需人工确认并签字。

提示：Excel 模板中「字段枚举值」列必须从规范附录的标准字典中复制粘贴，禁止手动输入。系统会校验枚举值哈希值，不匹配则拒绝导入。

5.2 自动化校验流水线的五个关卡

模型交付包提交后，进入 CI/CD 流水线，依次执行五道硬性校验：

5.2.1 血缘影响分析的实操技巧：用SHOW DEPENDENCY定位下游

当修改一张 DWD 表（如新增字段is_vip），需评估对 DWS 层的影响。规范推荐使用 Hive 内置命令快速定位：

# 在 Hive CLI 中执行，获取所有依赖此表的视图/表 hive -e "SHOW DEPENDENCY IN dwd_user_profile_di;" > dependency_report.txt

输出结果会列出所有SELECT了dwd_user_profile_di的 DWS 表名，如dws_user_vip_summary_di。此时需人工检查这些 DWS 表的建表语句，确认是否引用了新增字段。规范要求：若 DWS 表未引用新字段，则无需修改；若引用，则必须同步更新其 DDL 并重新跑全量任务。该命令比手动查血缘平台更快，是日常迭代的必备技能。

模型设计规范的价值，不在文档厚度，而在每个标点符号背后可落地的工程动作。当你在建表时多敲一个COMMENT '粒度：...'，在写字段时多选一次标准字典，或在提交前多跑一次SHOW DEPENDENCY，你不是在填表，而是在为整个组织的数据信任投票。

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