简介《数据仓库建设规范模板.pdf》是一份系统化的数据仓库建设规范文档面向数据仓库建设与管理的技术人员尤其适合具有数据库管理和开发经验的专业人士。资源为单个PDF文件大小526KB内容覆盖数据库对象命名规范表、视图、存储过程、函数、分区、主键、索引、序列等、主机目录与文件命名规范、数据保存周期规范以及数据库编程、Java编程和Shell编程规范旨在解决命名不统一、代码可读性差、维护成本高等问题。文档特别要求注释量不低于30%并推荐标准SQL写法、避免隐式类型转换同时给出程序结构模板和日志记录规范保证程序健壮性。现有95人浏览学习适合作为团队内部标准或新员工培训参考帮助提升整体开发效率与协作一致性。1. 一份数据仓库命名模板为什么值得逐条看完数仓团队最怕的不是模型设计不出来而是三个月后没人说得清tmp_table_202312_v2_final到底是哪张表。命名不统一带来的维护成本是隐性的但每天都在发生需求方报了一个数据口径问题开发要翻半天找目标表新同事接手先花一周记部门和前任的命名习惯。这份《数据仓库建设规范模板》解决的就是这个问题它把数据库对象的命名、目录文件、分区保留、SQL 和 Java 编程约束统一成一套可执行的规范覆盖从 ODS 原样接入到 APP 报表输出的完整链路。文档适合三类人正在搭数仓基座的架构师、每天写抽取和汇总脚本的开发、以及需要给团队定规矩的运维负责人。它不是单纯罗列规范条文而是把命名、分区、日志、编码检查串成了工程标准。这篇博文我按实际落地顺序拆这几个关键部分并给出能直接用的示例和检查方法。2. 分层模型先行ODS、DW、DM、DIM、APP 的职责与命名模板2.1 五层模型的分工边界文档把数仓分为五个层次每层职责写得很清楚直接决定了后续所有表名的前缀选择。层次用途说明ODS存放来自各个系统的原始数据保持源系统原貌不做业务清洗通常按抽取日期分区DW根据业务分析需求对主题域内数据进行轻度汇总数据按主题域重组织不做跨域加工DM建立跨域业务主题模型如中高端用户、拍照用户等跨客户和产品的主题DIM统一服务于数据中心的参数表码表、字典、公共维度APP应用层用于生成报表直接供 BI 报表和数据服务调用我见过很多团队把 ODS 和 DW 混在一起源表直接做汇总后面口径一变全表重刷。这个模板把每层边界先定住就是防止这种问题。另有一条「DM 层不能进行同层引用」值得单独记跨层引用会让依赖关系变得不可控。2.2 对象命名模板拆解核心命名规则是对象类型_模型层次_主题域_对象描述[_汇总类型][_存储类型]尖括号为必填方括号为可选。例如一张在 DW 层客户域的日汇总目标表命名为tb_dw_cust_consume_day拆开看分别是tb : table 表对象 dw : 所属模型层 cust : 主题域 customer 的简称 consume : 对象描述中的业务功能 day : 汇总类型日汇总对象类型映射表列举了tb表、vw视图等文档中对存储过程、函数也做了约定建议按团队最常用的对象都列一张完整映射避免临时造缩写。模型层次直接复用 2.1 的五层。2.3 主题域、汇总类型与存储类型怎么设计主题域是对数据的大类划分文档要求新增主题必须到规范里备案登记这个动作很关键。很多团队只定了命名规则没有回执机制最后每个人按自己理解造新前缀。对象描述要求简洁准确通常由“业务功能”组成如果是通用规则下的多业务合成体对象描述里不加业务名。汇总类型取值日day、月mon、年year。存储类型更细目标程序生成的表不带后缀程序运行中的临时中间表加tmp配置表加cfg。比如程序跑批时产生的客户消费临时表命名成tb_dw_cust_consume_day_tmp一眼就能看出它不是可发布的正式数据对象。2.4 命名里的两条硬约束文档里反复强调两条命名采用有意义的英文词汇不允许用汉语拼音表名、列名必须加注释否则不予上线。这两条建议直接写进团队代码评审清单。命名用拼音的问题在于表名缩写会随方言变化——同一张“消费流水”表有人写xiaofei有人写xf有人写consume_flow最终索引、权限、血缘全都对不上。英文命名搭配注释是把可读性做扎实的最低成本手段。3. 从数据库对象到主机目录文件、字段、单位如何统一3.1 主机用户与目录规划文档对主机目录的约定是三层结构根目录/二级目录/[三级目录/]业务域[/自定义]根目录取决于物理存储挂载情况如果没有独立挂载点二级目录就是用户家目录业务域按抽取文件类型分类存储比如客户数据、账单数据分开目录。这种结构解决了两个问题第一数据文件从抽取到落地路径可预期脚本里写死路径也不会乱第二按业务域隔离后权限控制和各业务的数据量统计都方便。3.2 接口文件命名规则文件命名规则是文件类型_主题域_数据周期_接口文件序号.dat主题域取值为各项目名称数据周期日数据是 8 位YYYYMMDD月数据是 6 位YYYYMM接口文件序号长度 3默认从000开始。假设客户主题的日全量抽取文件当天是第 3 个接口文件命名就是cust_full_20250611_002.dat。这个规范的好处在于排序即时间序shell 脚本里用通配符拼接当天文件名非常稳定。3.3 字段命名与文件格式规范文件字段尽量不采用定长方式用|等特殊字符做分隔符同时要确认字段内容中不会出现该分隔符否则抽取后列会错位。文件编码统一 UTF-8避免跨平台传输后中文乱码。字段命名要求见名知意字段说明尽量参考现有业务数据库的数据字典。单位规范常被忽视文档专门拎出来说比如车速默认KM/h、金额单位是元还是分必须固定。这个细节我建议同时落到数仓的表字段注释里例如consume_amt注释写成“消费金额单位元”而不是只写“消费金额”。单位不写在元数据里后面取数口径很容易出现数量级不一致的问题。3.4 建表 DDL 落地示例把上述规范映射到一张 DW 层日汇总表DDL 大致是这样CREATE TABLE tb_dw_cust_consume_day ( cust_id VARCHAR(32) COMMENT 客户号来自DIM客户维表, consume_amt DECIMAL(18, 2) COMMENT 消费金额单位元, consume_cnt INT COMMENT 消费笔数, data_dt VARCHAR(8) COMMENT 统计日期YYYYMMDD ) COMMENT 客户日消费汇总表 PARTITIONED BY (dt VARCHAR(8));代码说明表名tb_dw_cust_consume_day中tb是对象类型dw是模型层cust是主题域consume是对象描述day是汇总类型。注意分区字段dt是标准 8 位字符串禁止用int类型存日期否则 SQL 里写where dt 20250611会触发隐式类型转换影响执行计划。字段注释里除了含义还带上了单位这就是 2.5 节单位规范的具体应用。提示这份模板拿到的场景多半是 HIVE 或者类 Hive 的数仓底座字段注释和分区字段用字符串能最大程度兼容不同版本组件。4. 分区管理、保留周期与程序日志可执行的落地路径4.1 汇总类型与数据保留周期文档对日表、月表、周表的处理做了非常具体的约束。日表以统计周期字段做日分区月底最后一天的数据不保存如有需要沉淀到月表月表以统计周期字段做月分区除分区字段外其余字段与日表必须相同。所有月报表、月 KPI 必须从月表出禁止从日表出。这条规则解决了一个典型问题月底数据从日表临时聚合每月最后一天任务跑批时间特别长且口径和月表容易不一致。数据保留周期需要按模型层分别设定比如日周期 ODS 保留 365 天DW 层按业务需要保留更短或更长。分区数量过多既占元数据空间又让扫描路径变长保留周期表应该写进数据资产管理文档和任务调度配置对应起来。4.2 分区操作统一收口文档里有一句容易被跳过的规定分区表的分区增加、删除操作统一由分区控制程序完成应用数据处理程序中不允许包含增加、删除分区的操作清空分区在应用数据处理程序里做避免程序多次运行导致的数据重复。这条规范把 DDL 操作从业务脚本里剥离出来换来的好处是分区生命周期完全可控不会出现业务脚本里drop partition误删数据的情况。4.3 分区管理脚本实现以 Hive 数仓为例一个集中式的分区控制脚本核心逻辑如下#!/bin/bash # 功能统一为日分区表添加/删除分区 # 用法partition_manager.sh tb_dw_cust_consume_day 20250611 TABLE_NAME$1 DATA_DT$2 KEEP_DAYS365 DROP_DT$(date -d ${DATA_DT} -${KEEP_DAYS} days %Y%m%d) # 添加当日分区if not exists 避免重复执行报错 hive -e ALTER TABLE ${TABLE_NAME} ADD IF NOT EXISTS PARTITION (dt${DATA_DT}); echo [INFO] add partition ${TABLE_NAME} dt${DATA_DT} # 清理超过保留周期的过期分区 hive -e ALTER TABLE ${TABLE_NAME} DROP IF EXISTS PARTITION (dt${DROP_DT}); echo [INFO] drop partition ${TABLE_NAME} dt${DROP_DT}参数说明DATA_DT是业务日期统一在调度平台传入KEEP_DAYS对应数据保留周期规范DROP_IF EXISTS保证删除幂等。业务脚本里只写数据写入逻辑不掺任何 DDL 语句。4.4 SQL 程序日志规范的落实文档对程序日志分成两类一类记录程序运行状态一个程序运行一次只记一条包括程序名称、目标表名、统计时间、开始和结束时间、运行状态、出错位置另一类记录运行过程一次运行记多条用于追踪中间阶段。这个设计和任务调度系统的告警天然配套状态日志进监控表过程日志进详细跟踪表。一个实用做法是在公共存储过程里封装日志写入函数业务程序只在开始、结束、异常三处调用-- 程序开始 CALL proc_log_status(tb_dw_cust_consume_day, 20250611, START, ); -- 程序主体 INSERT INTO tb_dw_cust_consume_day PARTITION (dt 20250611) SELECT cust_id, SUM(amt), COUNT(*) FROM tb_ods_cust_pay_day WHERE dt 20250611 GROUP BY cust_id; -- 程序结束 CALL proc_log_status(tb_dw_cust_consume_day, 20250611, SUCCESS, );5. 编码规范自动化检查把人工评审变成脚本兜底人工 review 规范文档里的每一条是不现实的尤其是注释比例不低于 30%、禁止select *、禁止 TAB 缩进这类机械规则。我建议把这些规则整理成一个 shell 脚本挂在调度或 CI 流程入口新脚本提交时先跑一遍再合并。#!/bin/bash # 功能SQL 规范自动检查脚本 # 用法check_sql_style.sh your_script.sql FILE$1 TOTAL_LINES$(wc -l $FILE) COMMENT_LINES$(grep -cE ^\s*(--|#|/\*) $FILE) RATIO$((COMMENT_LINES * 100 / TOTAL_LINES)) echo 总行数: ${TOTAL_LINES}, 注释行: ${COMMENT_LINES}, 注释率: ${RATIO}% # 检查 select *排除注释行后的实际语句 if grep -nE ^\s*select\s\* $FILE | grep -v ^\s*--; then echo [FAIL] 存在 select *请列出具体字段 fi # 检查 TAB 缩进排除 makefile 等非 SQL 文件 if grep -nP \t $FILE; then echo [FAIL] 文件包含 TAB 字符统一使用 4 空格缩进 fi # 检查分号后紧跟语句一行多语句 if grep -nE ;\s*\S $FILE; then echo [FAIL] 存在一行多条语句请拆行书写 fi脚本的原理不复杂注释率统计用正则匹配行首注释标记select *检查用grep -v排除注释行TAB 检查用grep -P匹配制表符。实际接入时可以把这些检查函数封装成独立文件失败时返回非零退出码调度平台收到非零码就阻断下游任务。我在团队里的做法是只阻断新提交的脚本存量脚本先放行再逐个整改避免一次引入大量改造工作量。把规范文档里最可复制的两项——分区收口和注释约束先固化成脚本和公共函数再逐步覆盖到所有存量任务。这份模板最大的价值不是条文本身而是让团队对“什么才叫规范代码”有了共同语言。本文还有配套的精品资源点击获取 数据仓库建设规范：命名模板、分层模型与自动化检查实践
简介《数据仓库建设规范模板.pdf》是一份系统化的数据仓库建设规范文档面向数据仓库建设与管理的技术人员尤其适合具有数据库管理和开发经验的专业人士。资源为单个PDF文件大小526KB内容覆盖数据库对象命名规范表、视图、存储过程、函数、分区、主键、索引、序列等、主机目录与文件命名规范、数据保存周期规范以及数据库编程、Java编程和Shell编程规范旨在解决命名不统一、代码可读性差、维护成本高等问题。文档特别要求注释量不低于30%并推荐标准SQL写法、避免隐式类型转换同时给出程序结构模板和日志记录规范保证程序健壮性。现有95人浏览学习适合作为团队内部标准或新员工培训参考帮助提升整体开发效率与协作一致性。1. 一份数据仓库命名模板为什么值得逐条看完数仓团队最怕的不是模型设计不出来而是三个月后没人说得清tmp_table_202312_v2_final到底是哪张表。命名不统一带来的维护成本是隐性的但每天都在发生需求方报了一个数据口径问题开发要翻半天找目标表新同事接手先花一周记部门和前任的命名习惯。这份《数据仓库建设规范模板》解决的就是这个问题它把数据库对象的命名、目录文件、分区保留、SQL 和 Java 编程约束统一成一套可执行的规范覆盖从 ODS 原样接入到 APP 报表输出的完整链路。文档适合三类人正在搭数仓基座的架构师、每天写抽取和汇总脚本的开发、以及需要给团队定规矩的运维负责人。它不是单纯罗列规范条文而是把命名、分区、日志、编码检查串成了工程标准。这篇博文我按实际落地顺序拆这几个关键部分并给出能直接用的示例和检查方法。2. 分层模型先行ODS、DW、DM、DIM、APP 的职责与命名模板2.1 五层模型的分工边界文档把数仓分为五个层次每层职责写得很清楚直接决定了后续所有表名的前缀选择。层次用途说明ODS存放来自各个系统的原始数据保持源系统原貌不做业务清洗通常按抽取日期分区DW根据业务分析需求对主题域内数据进行轻度汇总数据按主题域重组织不做跨域加工DM建立跨域业务主题模型如中高端用户、拍照用户等跨客户和产品的主题DIM统一服务于数据中心的参数表码表、字典、公共维度APP应用层用于生成报表直接供 BI 报表和数据服务调用我见过很多团队把 ODS 和 DW 混在一起源表直接做汇总后面口径一变全表重刷。这个模板把每层边界先定住就是防止这种问题。另有一条「DM 层不能进行同层引用」值得单独记跨层引用会让依赖关系变得不可控。2.2 对象命名模板拆解核心命名规则是对象类型_模型层次_主题域_对象描述[_汇总类型][_存储类型]尖括号为必填方括号为可选。例如一张在 DW 层客户域的日汇总目标表命名为tb_dw_cust_consume_day拆开看分别是tb : table 表对象 dw : 所属模型层 cust : 主题域 customer 的简称 consume : 对象描述中的业务功能 day : 汇总类型日汇总对象类型映射表列举了tb表、vw视图等文档中对存储过程、函数也做了约定建议按团队最常用的对象都列一张完整映射避免临时造缩写。模型层次直接复用 2.1 的五层。2.3 主题域、汇总类型与存储类型怎么设计主题域是对数据的大类划分文档要求新增主题必须到规范里备案登记这个动作很关键。很多团队只定了命名规则没有回执机制最后每个人按自己理解造新前缀。对象描述要求简洁准确通常由“业务功能”组成如果是通用规则下的多业务合成体对象描述里不加业务名。汇总类型取值日day、月mon、年year。存储类型更细目标程序生成的表不带后缀程序运行中的临时中间表加tmp配置表加cfg。比如程序跑批时产生的客户消费临时表命名成tb_dw_cust_consume_day_tmp一眼就能看出它不是可发布的正式数据对象。2.4 命名里的两条硬约束文档里反复强调两条命名采用有意义的英文词汇不允许用汉语拼音表名、列名必须加注释否则不予上线。这两条建议直接写进团队代码评审清单。命名用拼音的问题在于表名缩写会随方言变化——同一张“消费流水”表有人写xiaofei有人写xf有人写consume_flow最终索引、权限、血缘全都对不上。英文命名搭配注释是把可读性做扎实的最低成本手段。3. 从数据库对象到主机目录文件、字段、单位如何统一3.1 主机用户与目录规划文档对主机目录的约定是三层结构根目录/二级目录/[三级目录/]业务域[/自定义]根目录取决于物理存储挂载情况如果没有独立挂载点二级目录就是用户家目录业务域按抽取文件类型分类存储比如客户数据、账单数据分开目录。这种结构解决了两个问题第一数据文件从抽取到落地路径可预期脚本里写死路径也不会乱第二按业务域隔离后权限控制和各业务的数据量统计都方便。3.2 接口文件命名规则文件命名规则是文件类型_主题域_数据周期_接口文件序号.dat主题域取值为各项目名称数据周期日数据是 8 位YYYYMMDD月数据是 6 位YYYYMM接口文件序号长度 3默认从000开始。假设客户主题的日全量抽取文件当天是第 3 个接口文件命名就是cust_full_20250611_002.dat。这个规范的好处在于排序即时间序shell 脚本里用通配符拼接当天文件名非常稳定。3.3 字段命名与文件格式规范文件字段尽量不采用定长方式用|等特殊字符做分隔符同时要确认字段内容中不会出现该分隔符否则抽取后列会错位。文件编码统一 UTF-8避免跨平台传输后中文乱码。字段命名要求见名知意字段说明尽量参考现有业务数据库的数据字典。单位规范常被忽视文档专门拎出来说比如车速默认KM/h、金额单位是元还是分必须固定。这个细节我建议同时落到数仓的表字段注释里例如consume_amt注释写成“消费金额单位元”而不是只写“消费金额”。单位不写在元数据里后面取数口径很容易出现数量级不一致的问题。3.4 建表 DDL 落地示例把上述规范映射到一张 DW 层日汇总表DDL 大致是这样CREATE TABLE tb_dw_cust_consume_day ( cust_id VARCHAR(32) COMMENT 客户号来自DIM客户维表, consume_amt DECIMAL(18, 2) COMMENT 消费金额单位元, consume_cnt INT COMMENT 消费笔数, data_dt VARCHAR(8) COMMENT 统计日期YYYYMMDD ) COMMENT 客户日消费汇总表 PARTITIONED BY (dt VARCHAR(8));代码说明表名tb_dw_cust_consume_day中tb是对象类型dw是模型层cust是主题域consume是对象描述day是汇总类型。注意分区字段dt是标准 8 位字符串禁止用int类型存日期否则 SQL 里写where dt 20250611会触发隐式类型转换影响执行计划。字段注释里除了含义还带上了单位这就是 2.5 节单位规范的具体应用。提示这份模板拿到的场景多半是 HIVE 或者类 Hive 的数仓底座字段注释和分区字段用字符串能最大程度兼容不同版本组件。4. 分区管理、保留周期与程序日志可执行的落地路径4.1 汇总类型与数据保留周期文档对日表、月表、周表的处理做了非常具体的约束。日表以统计周期字段做日分区月底最后一天的数据不保存如有需要沉淀到月表月表以统计周期字段做月分区除分区字段外其余字段与日表必须相同。所有月报表、月 KPI 必须从月表出禁止从日表出。这条规则解决了一个典型问题月底数据从日表临时聚合每月最后一天任务跑批时间特别长且口径和月表容易不一致。数据保留周期需要按模型层分别设定比如日周期 ODS 保留 365 天DW 层按业务需要保留更短或更长。分区数量过多既占元数据空间又让扫描路径变长保留周期表应该写进数据资产管理文档和任务调度配置对应起来。4.2 分区操作统一收口文档里有一句容易被跳过的规定分区表的分区增加、删除操作统一由分区控制程序完成应用数据处理程序中不允许包含增加、删除分区的操作清空分区在应用数据处理程序里做避免程序多次运行导致的数据重复。这条规范把 DDL 操作从业务脚本里剥离出来换来的好处是分区生命周期完全可控不会出现业务脚本里drop partition误删数据的情况。4.3 分区管理脚本实现以 Hive 数仓为例一个集中式的分区控制脚本核心逻辑如下#!/bin/bash # 功能统一为日分区表添加/删除分区 # 用法partition_manager.sh tb_dw_cust_consume_day 20250611 TABLE_NAME$1 DATA_DT$2 KEEP_DAYS365 DROP_DT$(date -d ${DATA_DT} -${KEEP_DAYS} days %Y%m%d) # 添加当日分区if not exists 避免重复执行报错 hive -e ALTER TABLE ${TABLE_NAME} ADD IF NOT EXISTS PARTITION (dt${DATA_DT}); echo [INFO] add partition ${TABLE_NAME} dt${DATA_DT} # 清理超过保留周期的过期分区 hive -e ALTER TABLE ${TABLE_NAME} DROP IF EXISTS PARTITION (dt${DROP_DT}); echo [INFO] drop partition ${TABLE_NAME} dt${DROP_DT}参数说明DATA_DT是业务日期统一在调度平台传入KEEP_DAYS对应数据保留周期规范DROP_IF EXISTS保证删除幂等。业务脚本里只写数据写入逻辑不掺任何 DDL 语句。4.4 SQL 程序日志规范的落实文档对程序日志分成两类一类记录程序运行状态一个程序运行一次只记一条包括程序名称、目标表名、统计时间、开始和结束时间、运行状态、出错位置另一类记录运行过程一次运行记多条用于追踪中间阶段。这个设计和任务调度系统的告警天然配套状态日志进监控表过程日志进详细跟踪表。一个实用做法是在公共存储过程里封装日志写入函数业务程序只在开始、结束、异常三处调用-- 程序开始 CALL proc_log_status(tb_dw_cust_consume_day, 20250611, START, ); -- 程序主体 INSERT INTO tb_dw_cust_consume_day PARTITION (dt 20250611) SELECT cust_id, SUM(amt), COUNT(*) FROM tb_ods_cust_pay_day WHERE dt 20250611 GROUP BY cust_id; -- 程序结束 CALL proc_log_status(tb_dw_cust_consume_day, 20250611, SUCCESS, );5. 编码规范自动化检查把人工评审变成脚本兜底人工 review 规范文档里的每一条是不现实的尤其是注释比例不低于 30%、禁止select *、禁止 TAB 缩进这类机械规则。我建议把这些规则整理成一个 shell 脚本挂在调度或 CI 流程入口新脚本提交时先跑一遍再合并。#!/bin/bash # 功能SQL 规范自动检查脚本 # 用法check_sql_style.sh your_script.sql FILE$1 TOTAL_LINES$(wc -l $FILE) COMMENT_LINES$(grep -cE ^\s*(--|#|/\*) $FILE) RATIO$((COMMENT_LINES * 100 / TOTAL_LINES)) echo 总行数: ${TOTAL_LINES}, 注释行: ${COMMENT_LINES}, 注释率: ${RATIO}% # 检查 select *排除注释行后的实际语句 if grep -nE ^\s*select\s\* $FILE | grep -v ^\s*--; then echo [FAIL] 存在 select *请列出具体字段 fi # 检查 TAB 缩进排除 makefile 等非 SQL 文件 if grep -nP \t $FILE; then echo [FAIL] 文件包含 TAB 字符统一使用 4 空格缩进 fi # 检查分号后紧跟语句一行多语句 if grep -nE ;\s*\S $FILE; then echo [FAIL] 存在一行多条语句请拆行书写 fi脚本的原理不复杂注释率统计用正则匹配行首注释标记select *检查用grep -v排除注释行TAB 检查用grep -P匹配制表符。实际接入时可以把这些检查函数封装成独立文件失败时返回非零退出码调度平台收到非零码就阻断下游任务。我在团队里的做法是只阻断新提交的脚本存量脚本先放行再逐个整改避免一次引入大量改造工作量。把规范文档里最可复制的两项——分区收口和注释约束先固化成脚本和公共函数再逐步覆盖到所有存量任务。这份模板最大的价值不是条文本身而是让团队对“什么才叫规范代码”有了共同语言。本文还有配套的精品资源点击获取