数据仓库模型设计与建设应用规范1.0版

数据仓库模型设计与建设应用规范1.0版一、引言1.1目的与意义本规范旨在为企业级数据仓库的模型设计、建设与应用提供一套统一、标准、可落地的指导框架。通过明确数据仓库模型的设计原则、方法、流程及应用规范，确保数据仓库能够高效支撑业务分析决策，提升数据资产价值，保障数据的一致性、准确性、完整性和易用性，降低系统建设与维护成本，促进跨部门数据协作与共享。1.2适用范围本规范适用于企业内部所有数据仓库项目的模型设计、开发、测试、部署、运维及应用支持等相关活动。所有参与数据仓库建设的业务人员、数据架构师、模型设计师、ETL开发工程师、数据分析人员及运维人员均需遵守本规范。1.3术语定义*数据仓库（DW）:一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。*主题域:对企业业务过程中某一宏观领域的抽象，是数据归类的最高层次。*实体:业务领域中客观存在并可相互区分的事物。*属性:实体所具有的某一特性。*事实表:存储业务过程中度量值（事实）及关联维度键的数据表。*维度表:存储描述事实表中度量值环境信息（维度属性）的数据表。*ODS层（操作数据存储）:用于集成和暂存来自各业务系统的原始数据，保持数据的原始性和即时性。*DW层（数据仓库层）:核心层，按照主题域进行数据组织，完成数据的清洗、转换、集成和整合，提供一致性的基础数据。细分为DWD（明细数据层）、DWS（汇总数据层）。*DM层（数据集市层）:面向特定业务部门或分析需求，提供高度汇总和预计算的数据，支持快速查询分析。*ETL（抽取、转换、加载）:将数据从源系统抽取出来，经过清洗、转换、集成等处理后加载到数据仓库的过程。*SCD（缓慢变化维度）:维度属性的值随时间发生缓慢变化，需要对这种变化进行跟踪和管理的策略。二、数据仓库模型设计基本原则2.1业务驱动原则模型设计必须紧密结合企业业务需求和战略目标，以业务理解为基础，确保模型能够准确反映业务实体、业务过程和业务规则，支持业务问题的分析与解答。避免为了技术而技术，脱离实际业务场景。2.2面向主题原则数据仓库应按照主题域组织数据，每个主题域对应企业中一个相对独立的业务领域。主题的划分应具有稳定性和包容性，能够覆盖该领域的主要分析需求，并便于用户理解和使用。2.3集成性与一致性原则模型设计应确保来自不同源系统的数据在命名规范、数据类型、编码标准、业务规则等方面达成一致，消除数据冗余和冲突，提供统一、准确的数据视图。集成过程中需处理数据不一致、重复、缺失等问题。2.4可扩展性与灵活性原则模型设计应具备良好的可扩展性，能够适应业务的发展变化和新需求的提出。在架构上预留扩展空间，允许新增实体、属性、关系或主题域，而无需对现有模型进行大规模重构。2.5数据质量优先原则模型设计应充分考虑数据质量因素，包括数据的准确性、完整性、一致性、及时性、有效性和唯一性。通过合理的模型结构（如约束、校验规则）和ETL处理，提升数据质量。2.6性能优化原则在模型设计阶段就要考虑查询性能。合理设计表结构（如事实表与维度表的划分）、索引策略、分区策略、适度的预计算和汇总，以提高数据仓库的查询响应速度和处理效率，满足用户分析需求。2.7规范化与标准化原则在数据仓库的不同层次（如ODS、DWD）可适当采用不同程度的规范化设计以减少冗余和异常；而在DWS、DM层可根据查询性能需求采用适度的反规范化。同时，命名规范、编码规范、设计文档规范等应贯穿始终。三、数据仓库模型设计规范3.1模型分层设计规范3.1.1ODS层设计规范*定位：对接源系统，尽可能保留源数据原貌，进行简单清洗和格式转换。*设计要点：*数据结构应尽量与源系统保持一致，便于数据溯源和问题定位。*记录数据的抽取时间、来源系统等元数据信息。*对敏感数据进行脱敏处理。*可采用增量或全量方式同步数据，视源系统特性和业务需求而定。3.1.2DW层设计规范*DWD层（明细数据层）：*定位：对ODS层数据进行清洗、转换、补充，形成面向主题的、粒度最细的标准化明细数据。*设计要点：*消除数据噪声（如空值、异常值、重复值）。*统一数据编码和命名。*补充必要的维度关联键。*保留历史痕迹，支持数据回溯。*DWS层（汇总数据层）：*定位：基于DWD层数据，按照一定的业务规则和分析维度进行轻度汇总和聚合，提供公共指标数据。*设计要点：*面向分析常用的维度组合进行汇总。*汇总粒度应具有通用性，避免过度细分。*确保汇总指标的计算逻辑一致。3.1.3DM层设计规范*定位：针对特定业务场景或用户群体，提供高度定制化、预计算的分析数据，优化查询性能。*设计要点：*紧密结合具体分析需求，提供即席查询或报表所需的数据。*可以是宽表形式，包含多维度和多指标。*允许适度的数据冗余以换取查询效率。3.2模型设计方法数据仓库模型设计推荐采用维度建模方法，辅以适当的ER建模思想。维度建模更侧重于用户的查询分析需求，易于理解和使用，能够提供较好的查询性能。3.2.1维度建模核心要素*事实表：*粒度：明确事实表中一条记录代表的业务事件的详细程度，粒度是维度建模的基础。*事实：分为可加性事实（如销售额、数量）、半可加性事实（如账户余额）和不可加性事实（如单价、比率）。优先存储可加性事实。*类型：事务事实表、周期快照事实表、累积快照事实表。根据业务过程特点选择合适的事实表类型。*维度表：*属性：包含描述性信息，用于查询约束、分组和报表标签。应尽可能丰富维度属性。*层级：支持钻取分析的维度属性层级关系（如地区维度：国家-省-市-区）。*SCD处理：根据业务需求选择合适的SCD策略（如SCD1：直接覆盖；SCD2：增加新行；SCD3：增加新列等）。3.2.2ER建模应用在数据仓库的ODS层或某些核心业务主题的DWD层，可适当采用ER建模方法，以清晰表达实体间的复杂关系，保证数据的规范性和一致性。ER模型强调实体、属性及实体间的关系。3.3模型设计过程3.3.1需求分析与主题域划分深入理解业务需求，包括分析需求、报表需求、数据指标需求等。基于业务需求和企业业务架构，划分合理的主题域。3.3.2概念模型设计在主题域内，识别主要的业务实体（主题），定义实体的核心属性，以及实体间的主要关系。形成高层次的概念模型，通常用ER图表示。3.3.3逻辑模型设计对概念模型进行细化，确定每个实体（表）的具体属性、数据类型、主键、外键，定义表与表之间的关系。对于维度模型，明确事实表和维度表，以及它们之间的关联。此阶段不涉及具体的物理存储细节。3.3.4物理模型设计根据逻辑模型，结合目标数据库的特性（如Oracle,MySQL,Hive等）和性能要求，进行物理模型设计。包括表名确定、字段名确定、数据类型映射与优化、索引设计、分区策略、存储参数设置等。3.4命名规范命名规范应确保简洁、明确、一致，能够反映对象的业务含义和用途，便于理解和维护。*表命名：*采用“层名_主题域_子主题_表类型_描述”的结构，如：dwd_sales_order_fact（销售订单明细事实表），dim_customer_info（客户信息维度表）。*层名：ods,dwd,dws,dm。*表类型：fact（事实表）,dim（维度表）,agg（汇总表）,tmp（临时表）,view（视图）。*使用小写字母，单词之间用下划线分隔。*字段命名：*采用有意义的英文单词或缩写，反映字段的业务含义，如：order_id,customer_name,sales_amount。*主键字段通常为“表名_id”或直接用“id”。*日期字段明确时间粒度，如：create_date（创建日期，精确到日）,create_time（创建时间，精确到秒）。*使用小写字母，单词之间用下划线分隔。避免使用数据库关键字。*视图命名：*以“v_”为前缀，后续规则参考表命名，如：v_dm_sales_monthly_report。*索引命名：*主键索引：pk_表名。*唯一索引：uk_表名_字段名。*普通索引：idx_表名_字段名。3.5数据类型选择*选择合适的数据类型，既能准确表示数据，又能节省存储空间，提高处理效率。*日期时间类型优先使用数据库原生的DATE,DATETIME,TIMESTAMP类型。*数值类型根据数据精度和范围选择，避免盲目使用大类型。*字符串类型根据实际长度选择VARCHAR（可变长）或CHAR（定长），VARCHAR更节省空间。*对于Hive等大数据平台，注意区分STRING与其他数值类型、日期类型的使用场景。3.6约束与完整性*主键约束：确保表中每条记录的唯一性，事实表通常为组合主键（业务主键或代理键）。*外键约束：在逻辑模型中明确表间关系，物理实现时根据数据库性能和ETL效率权衡是否创建物理外键。*非空约束：对必填字段设置非空约束。*业务规则约束：通过ETL过程或触发器（谨慎使用）确保数据符合业务规则（如取值范围、格式校验）。3.7模型评审模型设计过程中应建立多级评审机制，包括设计师自审、团队内部评审、业务部门评审、架构师评审等。评审内容包括：*是否符合业务需求。*主题划分是否合理。*粒度设计是否恰当。*表结构、字段设计是否合理，命名是否规范。*关系定义是否清晰准确。*是否考虑性能优化。*是否满足扩展性要求。评审通过后方可进入下一阶段。四、数据仓库模型建设规范4.1ETL开发规范*抽取：*明确抽取源、抽取频率（全量/增量）、抽取方式（CDC、日志、定时快照等）。*对源数据进行必要的探查和理解，处理源数据异常。*转换：*严格按照模型设计的规则进行数据清洗、格式转换、编码转换、计算派生、数据拆分与合并等。*转换逻辑应清晰、可追溯，优先在SQL或ETL工具中实现，避免复杂的硬编码。*处理SCD时，确保历史数据的准确性和一致性。*加载：*根据目标表的特性和数据量选择合适的加载方式（INSERT、INSERTOVERWRITE、UPSERT、MERGE等）。*考虑加载性能，大数据量时可采用批量加载、分区加载等策略。*加载过程应有详细日志记录，便于问题排查。*ETL调度：*合理设置作业依赖和执行顺序。*确保ETL作业的稳定性、可靠性和可恢复性。*对ETL作业进行监控和告警。4.2物理存储与性能优化*分区策略：*对大表进行分区，常用分区键包括日期（如按天、按月）、地区、业务类型等。*选择合适的分区类型（如范围分区、列表分区、哈希分区）。*索引设计：*为常用查询条件的字段、连接字段创建索引。*平衡索引带来的查询加速和DML操作的开销。*避免在频繁更新的字段上创建过多索引。*表存储格式：*在Hadoop生态中，选择合适的文件存储格式（如ORC,Parquet）以提高压缩率和查询性能。*预计算与物化视图：*对复杂、高频的汇总查询，可采用预计算结果或物化视图的方式提升性能。4.3数据集成与一致性*确保不同源系统数据集成到数据仓库后的一致性，包括编码一致、命名一致、计算逻辑一致。*建立统一的维度表，供不同事实表关联，确保分析维度的一致性。*对于关键指标，定义统一的计算口径和业务规则，并文档化。五、数据仓库模型应用与运维规范5.1数据服务与接口规范*数据仓库的数据服务应通过统一的接口对外提供，如视图、API等。*对外提供的数据集应具有清晰的元数据描述，包括数据来源、含义、更新频率、数据质量等。*控制数据访问权限，确保数据安全。5.2元数据管理*建立完善的元数据管理体系，记录模型结构、字段含义、数据血缘、SCD策略、ETL规则、数据质量规则等。*确保元数据的准确性和及时性，元数据应与实际数据和模型保持同步更新。*提供元数据查询和检索功能，方便用户理解和使用数据。5.3数据质量管理*建立数据质量监控指标体系，包括准确性、完整性、一致性、及时性、唯一性、有效性等。*对关键数据进行常态化监控和校验，发现数据质量问题及时告警并处理。*持续改进数据质量，从源头上治理数据问题。5.4模型变更管理*模型变更（如新增字段、修改字段类型、新增表、表结构调整等）必须遵循变更流程。*变更前需进行影响评估，包括对ETL作业、下游应用、报表的影响。*变更需经过评审和测试，并有回滚方案。*变更后需更新相关文档（模型设计文档、元数据等），并通知相关使用方。5.5性能监控与优化*定期监控数据仓库的查询性能、ETL作业性能、