简介本资源是阿里集团内部数据研发团队制定的《数据模型设计规范》官方文档面向数据工程师、数仓开发人员及企业级数据平台建设者系统解决多业务线数据建模标准不一、复用性低、维护成本高等核心问题。文档完整覆盖维度建模全流程——从业务需求分析、维度与事实表设计、粒度与类型定义到模型优化、标准化治理、文档编写及版本控制机制特别强化了可落地的实施约束与协同规范。资源为单文件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、甚至计算引擎的硬隔离。规范强制规定各层的建表语法、分区策略与权限模型分层物理库名前缀典型建表语法约束分区字段强制要求消费方限制ODSods_CREATE EXTERNAL TABLE仅支持 TEXTFILE/Parquet禁止任何计算dt STRING COMMENT 业务日期格式 yyyyMMdd仅限 DWD 层任务读取禁止应用直连DWDdwd_CREATE TABLE必须指定TBLPROPERTIES(auto.purgetrue)至少包含dt和hh小时级粒度时禁止 ADS 层直接读取必须经 DWS 汇总DWSdws_必须使用INSERT OVERWRITEDISTRIBUTE BY显式控制数据倾斜dt必须为分区字段禁止hh可被 BI 工具、API 服务直接查询ADSads_必须添加COMMENT字段说明业务场景如COMMENT 供大促实时大屏使用的用户地域分布TOP10dtbiz_date业务发生日期双分区仅开放给前端应用禁止反向写入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_owneralibaba-inc.com );auto.purgetrue启用自动分区清理避免历史测试分区堆积COMMENT字段必须完整描述业务含义且枚举值需与规范附录中的标准字典完全一致如FIRST_TIER不可写作Tier1user_sk与user_id必须同时存在前者用于模型关联后者用于业务溯源表名后缀_di明确标识为「日粒度」Daily Incremental若为全量快照则用_dfDaily 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默认值为99991231is_current为Y或N禁止使用布尔类型。3.1.1 商品维度表dwd_item_dimDDL 示例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_currentY。规范要求所有 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_iditem_idexposure_time拼接确保唯一性所有外键user_sk,item_sk必须显式声明COMMENT关联目标表这是血缘自动解析的基础position字段必须为INT且业务含义明确如信息流第3位、搜索结果第1位禁止存储「位置ID」等模糊字符串。4.2 度量Measure字段的命名与类型规范度量字段不是随便起个名字就行。规范定义了严格的命名前缀与类型映射度量语义命名前缀推荐类型示例字段名校验要求计数类cnt_BIGINTcnt_click,cnt_order禁止为INT防止超限金额类amt_DECIMAL(18,2)amt_gmv,amt_discount必须为 2 位小数禁止FLOAT时长类dur_BIGINT毫秒dur_stay_sec,dur_play_ms单位必须在COMMENT中注明比率类pct_DECIMAL(10,4)pct_ctr,pct_conversion小数位数固定为 4值域 0~1004.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 模型交付的四大强制文件每套新模型上线必须提交以下四个文件缺一不可Excel 模型设计表使用规范提供的.xlsx模板包含「表名、中文名、主题域、分层、粒度声明、字段列表含类型、长度、枚举值、是否主键、外键关系图」Hive DDL 脚本与 Excel 完全一致的建表语句文件名格式dwd_xxx_f_ddl.sql元数据注册 JSON符合 OpenMetadata Schema 的 JSON 文件包含name、description、tags、columns、lineage字段血缘影响分析报告Markdown 格式说明本次建表对现有 DWS/ADS 层哪些报表、哪些 API 产生影响影响范围需人工确认并签字。提示Excel 模板中「字段枚举值」列必须从规范附录的标准字典中复制粘贴禁止手动输入。系统会校验枚举值哈希值不匹配则拒绝导入。5.2 自动化校验流水线的五个关卡模型交付包提交后进入 CI/CD 流水线依次执行五道硬性校验关卡校验内容失败后果技术实现1. 命名合规表名、字段名是否符合^[a-z][a-z0-9_]{2,63}$正则是否含禁用词如tmp、test、backup流水线中断Shell 脚本 grep -E2. 粒度声明DDLCOMMENT是否包含粒度且非空阻断建表Python 解析 HiveQL AST3. 外键一致性所有_sk字段的COMMENT是否指向真实存在的维度表阻断建表查询 Hive Metastore API4. 枚举值校验字段COMMENT中的枚举值是否在标准字典中存在阻断建表对接内部字典服务 REST API5. 血缘完整性JSON 元数据中lineage.upstream是否包含所有外键关联表允许告警但不阻断Neo4j 图数据库查询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你不是在填表而是在为整个组织的数据信任投票。本文还有配套的精品资源点击获取 阿里数据模型设计规范：主题域分层与维度建模实战
简介本资源是阿里集团内部数据研发团队制定的《数据模型设计规范》官方文档面向数据工程师、数仓开发人员及企业级数据平台建设者系统解决多业务线数据建模标准不一、复用性低、维护成本高等核心问题。文档完整覆盖维度建模全流程——从业务需求分析、维度与事实表设计、粒度与类型定义到模型优化、标准化治理、文档编写及版本控制机制特别强化了可落地的实施约束与协同规范。资源为单文件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、甚至计算引擎的硬隔离。规范强制规定各层的建表语法、分区策略与权限模型分层物理库名前缀典型建表语法约束分区字段强制要求消费方限制ODSods_CREATE EXTERNAL TABLE仅支持 TEXTFILE/Parquet禁止任何计算dt STRING COMMENT 业务日期格式 yyyyMMdd仅限 DWD 层任务读取禁止应用直连DWDdwd_CREATE TABLE必须指定TBLPROPERTIES(auto.purgetrue)至少包含dt和hh小时级粒度时禁止 ADS 层直接读取必须经 DWS 汇总DWSdws_必须使用INSERT OVERWRITEDISTRIBUTE BY显式控制数据倾斜dt必须为分区字段禁止hh可被 BI 工具、API 服务直接查询ADSads_必须添加COMMENT字段说明业务场景如COMMENT 供大促实时大屏使用的用户地域分布TOP10dtbiz_date业务发生日期双分区仅开放给前端应用禁止反向写入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_owneralibaba-inc.com );auto.purgetrue启用自动分区清理避免历史测试分区堆积COMMENT字段必须完整描述业务含义且枚举值需与规范附录中的标准字典完全一致如FIRST_TIER不可写作Tier1user_sk与user_id必须同时存在前者用于模型关联后者用于业务溯源表名后缀_di明确标识为「日粒度」Daily Incremental若为全量快照则用_dfDaily 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默认值为99991231is_current为Y或N禁止使用布尔类型。3.1.1 商品维度表dwd_item_dimDDL 示例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_currentY。规范要求所有 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_iditem_idexposure_time拼接确保唯一性所有外键user_sk,item_sk必须显式声明COMMENT关联目标表这是血缘自动解析的基础position字段必须为INT且业务含义明确如信息流第3位、搜索结果第1位禁止存储「位置ID」等模糊字符串。4.2 度量Measure字段的命名与类型规范度量字段不是随便起个名字就行。规范定义了严格的命名前缀与类型映射度量语义命名前缀推荐类型示例字段名校验要求计数类cnt_BIGINTcnt_click,cnt_order禁止为INT防止超限金额类amt_DECIMAL(18,2)amt_gmv,amt_discount必须为 2 位小数禁止FLOAT时长类dur_BIGINT毫秒dur_stay_sec,dur_play_ms单位必须在COMMENT中注明比率类pct_DECIMAL(10,4)pct_ctr,pct_conversion小数位数固定为 4值域 0~1004.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 模型交付的四大强制文件每套新模型上线必须提交以下四个文件缺一不可Excel 模型设计表使用规范提供的.xlsx模板包含「表名、中文名、主题域、分层、粒度声明、字段列表含类型、长度、枚举值、是否主键、外键关系图」Hive DDL 脚本与 Excel 完全一致的建表语句文件名格式dwd_xxx_f_ddl.sql元数据注册 JSON符合 OpenMetadata Schema 的 JSON 文件包含name、description、tags、columns、lineage字段血缘影响分析报告Markdown 格式说明本次建表对现有 DWS/ADS 层哪些报表、哪些 API 产生影响影响范围需人工确认并签字。提示Excel 模板中「字段枚举值」列必须从规范附录的标准字典中复制粘贴禁止手动输入。系统会校验枚举值哈希值不匹配则拒绝导入。5.2 自动化校验流水线的五个关卡模型交付包提交后进入 CI/CD 流水线依次执行五道硬性校验关卡校验内容失败后果技术实现1. 命名合规表名、字段名是否符合^[a-z][a-z0-9_]{2,63}$正则是否含禁用词如tmp、test、backup流水线中断Shell 脚本 grep -E2. 粒度声明DDLCOMMENT是否包含粒度且非空阻断建表Python 解析 HiveQL AST3. 外键一致性所有_sk字段的COMMENT是否指向真实存在的维度表阻断建表查询 Hive Metastore API4. 枚举值校验字段COMMENT中的枚举值是否在标准字典中存在阻断建表对接内部字典服务 REST API5. 血缘完整性JSON 元数据中lineage.upstream是否包含所有外键关联表允许告警但不阻断Neo4j 图数据库查询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你不是在填表而是在为整个组织的数据信任投票。本文还有配套的精品资源点击获取