数仓分层HW版实践总结

type

status

date

slug

summary

1 范围

略

2 规范性引用文件

《XXXX集团数据建模规范》

3 术语和定义

3.1 数据湖

数据湖是逻辑上各种原始数据的集合，具有“原始”、“海量”和“多样”（包含结构化、非结构化数据）等特征。数据湖保留数据的原格式，原则上不对数据进行清洗和加工，但针对多源异构的数据资产场景，需进行整合处理并完成数据资产注册。数据湖涵盖内部数据、外部数据，以及结构化和非结构化数据等。

3.2 数据仓库

数据仓库是面向主题、集成、稳定、可追溯的存储与管理体系，能够统一接入异构数据源，并通过数据抽取（ETL）、转换、整合等过程，将数据转换为规范化的主题数据模型。数据仓库支持高效存储、历史数据管理、分析查询优化，为业务分析和管理决策提供数据支撑。

3.3 E-R模型

E-R模型即实体关系模型，用于描述现实世界的对象（实体）、特征（属性）和相互关系（关系），是数据库结构设计的基础。

3.4 范式建模

范式建模是一种数据库建模方法，其主要目标是通过分解数据结构，遵循范式化规则来消除冗余和依赖异常，从而保证数据的一致性和完整性。

3.5 维度建模

维度建模是一种专门用于数据仓库和商业智能环境的数据建模方法，其核心目标是优化查询性能和简化数据分析过程。维度模型由事实表和维度表组成，事实表存储业务事实、度量值和维度外键信息，维度表存储描述性属性与场景信息。

3.6 星型模型

星型模型是维度建模中一种典型的、具有特定结构特征的模型形式。星型模型中维度表围绕事实表呈放射状排列，维度表之间无关联关系。星型模型通过增加冗余减少关联次数，性能更优，当多个事实表共享同一个维度表时，这种扩展的星型模型被称为星座模型。星座模型适用于复杂的业务场景，能够支持多主题的数据分析需求，为业务决策提供更全面的数据支持。

3.7 雪花模型

雪花模型是维度建模中基于星型模型衍生出的一种变体模型。它通过对维度表进行进一步规范化处理，将其分解为多个相互关联的子表，从而形成一种层次化的结构。这种规范化设计方式有效地避免了数据的重复存储，在节省存储空间的同时，显著降低了因数据更新操作而引发的异常风险。

3.8 汇聚表

汇聚表是基于原始数据进行聚合计算后的数据表，通常通过分组、汇总、统计等方式减少数据粒度，以提升查询性能和降低计算开销。

3.9 宽表

宽表是通过多表关联（如事实表与多个维度表的关联）预先合并数据形成的表，通常包含大量字段，减少查询时的表连接操作，提高查询效率。

4 管理职责与分工

集团数字信息中心负责本规范的制定、技术标准审定及执行监督，各业务部门应严格按照本规范要求，确保数据按规范准确入湖入仓。

5 湖仓分层原则

5.1 分层总体原则

为确保分层架构的科学性、合理性及高效性，湖仓分层设计应遵循以下原则：

5.1.1 标准化原则

湖仓分层设计应遵从统一的设计原则、设计方法、命名规范等要求，确保模型的标准化和规范化，达到提升模型设计质量，增加模型可读性，降低维护成本的目的。

5.1.2 扩展性原则

湖仓分层应具备良好的可扩展性，以适应业务的增长与变化，可扩展性越好，表示湖仓分层适应“变化”的能力越强。湖仓分层设计应充分考虑解耦、通用等诉求，以最小的模型修改满足业务需求变化，实现湖仓分层迭代演进。

5.1.3 一致性原则

湖仓分层设计应充分考虑数据流、业务场景等因素，确保数据的一致性，实现全局调用信息的可信与一致。

5.1.4 继承性原则

在基线版本演进过程中，非设计缺陷不得删除或修改上一个版本的实体或字段名。字段的新增应遵循不改变原实体含义的原则。

5.2 分层意义及目标

合理的数据分层结构对数据湖仓的稳定运行至关重要。通过有效的数据分层，可实现以下目标:

5.2.1 清晰数据结构

每个数据分层均有其明确的作用域，便于在数据表使用过程中快速定位和理解。

5.2.2 减少重复开发

通过规范数据分层，开发通用的中间层数据，能够大幅减少重复计算，提高数据开发效率。

5.2.3 复杂问题简单化

将复杂的任务分解成多个简单步骤来完成，每一层仅处理单一步骤，使任务更简单且易于理解和执行。

5.2.4 数据维护简易化

当数据出现问题时，无需修复所有数据，只需从有问题的步骤开始修复，简化维护流程。

5.2.5 屏蔽业务变动的影响

通过实施数据分层架构，有效隔离业务逻辑变更与数据结构的直接关联，避免因业务需求变动引发数据结构频繁修改。

5.2.6 数据质量提升

通过数据治理手段和工具，屏蔽原始数据的异常，提升数据服务质量，为后续的数据分析与应用提供可靠保障。

6 湖仓分层设计

集团数据湖仓分层采用四层架构，包括贴源层、整合层、报告层、集市层。

6.1 贴源层（SDI，Source Data Integration）

贴源层是数据仓库的起点，负责从各类业务系统中抽取数据，并将其完整、准确、及时地同步至数据底座。该层的主要目标是确保数据的原始性和一致性，为后续的数据处理提供可靠的基础。贴源层的数据结构与源系统保持一致，避免在初始阶段引入复杂的转换逻辑，保证数据的真实性和可追溯性。

6.2 整合层（DWI，Data Warehouse Integration）

整合层是数据仓库的核心环节，负责将贴源层的数据按照预定的业务规则和关系模型进行整合与重构。该层采用规范化的建模方法，结合集团数据架构的设计原则，最大限度地减少数据冗余，提升数据的灵活性和集成度。整合层通过统一的规则和逻辑，将分散的源系统数据转化为结构化的、可复用的数据资产，为上层应用提供一致的数据视图。

6.3 报告层（DWR，Data Warehouse Report）

报告层是数据仓库中为业务分析和报表展示提供支持的重要层级，根据业务需求对数据进行加工处理，如属性补充和数据优化等，以提升数据的可用性。为了提高数据查询和报表生成的效率，报告层采用高效的模型设计，通过适当增加数据冗余度，显著提升数据访问性能。报告层的设计为业务部门提供直观、高效的数据支持，满足多样化的分析和展示需求。

6.4 集市层（DM，Data Mart）

集市层是数据仓库的应用层，面向具体的业务场景，按需组合所需的数据内容。在构建集市层时，重点考虑数据的可复用性，避免重复建设。在报表分析中，如果需要按年、季度、月等不同时间维度展示数据，应优先使用一张包含年、月、日粒度的汇总表，以支持多场景复用，减少资源浪费。集市层的设计为业务部门提供灵活、高效的数据服务，助力业务决策和运营优化。

7 分层技术规范

建设湖仓分层时，应参考《XXXX集团数据建模规范》，确保整体数据模型的规范性和一致性。通过明确各层级的职责和数据流动关系，提高数据的可维护性和可扩展性，避免重复开发和资源浪费。

7.1 贴源层（SDI）规范

7.1.1 数据模型

SDI层无需单独设计逻辑模型，直接采用源系统的关系建模，在源模型结构基础上增加记录来源、记录创建时间、创建更新时间、逻辑删除标记等扩展字段。SDI记录来源需初始化为源系统和源端数据库信息，记录创建时间和更新时间初始化为具体作业执行时间，逻辑删除标记初始化为false。

7.1.2 加工逻辑

（一）数据抽取与调度

使用数据集成工具，按照《XXXX集团数据集成规范》制定的集成方式（全量、增量）和频率（日调度、准实时等）抽取源系统数据。

（二）数据字段转换

在数据集成过程中，除因源系统与目标数据库字段类型不一致或不兼容可能导致作业失败的情况需进行必要的加工转换外，原则上不对原始数据进行其他形式的加工处理，以保持数据的完整性和准确性。

（三）数据核验与追溯

对主数据或核心业务表的贴源层表，需配置核验作业，识别源端记录的物理删除和关键字段的变更操作，更新逻辑删除标记、记录更新时间等扩展字段，保留数据副本，以满足合规追溯需求。

7.2 整合层（DWI）规范

7.2.1 数据模型

（一）DWI层采用E-R关系建模，在SDI层模型无法满足业务需求、存在设计缺陷或性能瓶颈时，需进行重新建模，以确保数据结构的合理性和关联性。若SDI层模型设计合理，能够支撑业务需求且具备良好性能，则DWI层以优化或扩展为主，避免不必要的模型重构，提高数据架构的稳定性和可维护性。

（二）DWI模型需要增加扩展记录来源、记录创建时间、记录更新时间、逻辑删除标记等扩展字段。DWI记录来源初始化为上游的SDI库表信息，记录创建时间和更新时间初始化为具体作业执行时间，逻辑删除标记初始化为false。

7.2.2 加工逻辑

（一）多源优先级整合

针对多源数据冲突或重叠情形，应依据预设优先级规则执行数据优选及融合策略，确保数据应用准确性。

（二）多源属性行整合

基于业务领域统一性原则，对跨区域、跨系统数据进行行级集合运算，应通过交集、并集和差集等标准化语法操作实现多源数据表级整合。

（三）多源属性列整合

遵循数据仓库设计要求，开展数据范式重构及模型重建工作，重点推进主数据标准化建设，确保数据结构规范性与系统兼容性。

（四）固定规则标识添加

基于业务规则实施数据字段标准化加工，涵盖数据清洗、衍生字段生成等处理规则，系统记录数据源信息（包括源数据库表、更新时间等元数据），实现全链路数据资产可追溯管理。

7.3 报告层（DWR）规范

7.3.1 数据模型

（一）DWR层主要采用星型模型设计事实表与维表，事实表直接关联对应维度。维度表需明确定义主键、业务属性及描述字段，并基于业务需求扩展属性，以减少跨表关联查询。在层级关系复杂或存储空间受限的场景下，可采用雪花模型对维度表进行规范化处理，以减少冗余数据并提高维护性。

（二）DWR层模型维度表和事实表需要增加记录来源、记录创建时间、记录更新时间、逻辑删除标记等扩展字段，汇聚表仅增加记录创建时间和记录更新时间扩展字段。DWR记录来源需要初始化为上游的DWI库表信息，记录创建时间和更新时间初始化为具体作业执行时间，逻辑删除标记初始化为false。

7.3.2 加工逻辑

（一）标准化业务维度

统一用户、产品、时间、地区等核心业务维度，确保不同数据域间可以共享、复用，避免数据割裂。

（二）轻度汇总

DWR层以事实数据为核心，通过按日、周、月等时间粒度进行适度聚合，该层聚焦于对原始业务数据明细数据进行轻量级汇总处理，例如订单量、交易金额、访问次数等指标的时间分组统计，以提升数据查询效率、减少重复计算压力。

（三）预计算核心指标

对关键度量（如GMV、订单量等）进行预计算，减少DM层计算压力，优化查询性能。

（四）历史数据保留

根据业务分析及历史追溯需求，对维度属性启用缓慢变化处理：

1．直接覆盖历史值：适用于无需追溯历史，只记录最新状态的的场景，如客户联系电话更新，实现方式通常是直接更新维度表中的值，或者是覆盖原有数据；

2．保留历史版本：适用于需长期追踪历史变更，进行时间线分析的场景，如客户风险等级变更，实现方式是新增字段版本号、生效日期、失效日期、是否当前版本，插入新记录时，将旧记录的失效日期设置为当前时间，并标记为过期数据，将新纪录的生效日期配置为当前时间。

7.4 集市层（DM）规范

7.4.1 数据模型

（一）DM层面向主题和业务分析进行建模，主要采用星型模型设计事实表与维度表，事实表直接关联对应维度。维度表需明确定义主键、业务属性及描述字段，并基于业务需求扩展属性，减少跨表关联查询，针对复杂层级维度或存储空间优先的场景下，使用雪花模型进行报告层设计。

（二）DM层模型需要增加记录创建时间和更新时间扩展字段，时间字段初始化为具体作业执行时间。

7.4.2 加工逻辑

（一）宽表设计

DM层应采用宽表设计，通过减少表关联、预计算指标优化查询性能，降低计算成本，提升数据访问效率。宽表字段范围须严格匹配业务需求，避免冗余过载影响存储与更新效率。应结合物化视图、增量刷新等策略，确保数据一致性、可维护性，满足BI报表和即席查询的高效支撑。

（二）指标冗余

DM层应通过存储预计算指标（如总成交额、累计用户数）减少实时计算，提升查询性能。指标冗余应权衡存储与计算成本，避免数据膨胀和冗余失控，确保计算逻辑统一、可复用，防止数据不一致。需结合预计算、物化视图、分区优化等技术，保障高并发、低延迟的数据分析需求。

（三）支持多维分析

DM层应基于维度建模构建数据结构，确保数据可在时间、地区、用户等多个维度下进行切片、钻取、聚合分析，满足业务的多维查询需求。在SQL设计中，应优先采用GROUPING ID + CUBE/ROLLUP/GROUPING SETS提供高效的分组汇总能力，避免通过多个独立查询或UNION ALL实现多层级聚合，降低计算开销，提升查询效率。CUBE适用于所有组合维度的全量聚合，ROLLUP适用于分层汇总分析，GROUPING SETS应用于指定维度组合的灵活聚合，GROUPING ID用于区分不同粒度的聚合结果。使用时须严格控制计算范围，避免不必要的全量聚合导致资源消耗过高，并结合索引、分区等优化策略，提升OLAP查询性能。