《新兴数据湖仓设计与实践手册·从分层架构到数据湖仓架构设计（2025 年）》 系列文章将聚焦从数据仓库分层到数据湖仓架构的设计与实践。手册将阐述数据仓库分层的核心价值、常见分层类型，详解分层下的 ETL 架构及数据转换环节，介绍数据仓库分层对应的技术架构，并以贴源层（ODS）、数据仓库层（DW）、数据服务层（DWS）为例，深入剖析数湖仓分层设计，最后探讨数据仓库技术趋势并进行小结。
本文为系列文章首篇，详细剖析了数据仓库分层的概念与设计，希望能够为相关从业者提供数据湖仓设计与实践的系统指引。
💓 温馨提醒：纯干货分享，字数较多，建议收藏学习~
数据仓库分层的核心价值
数据仓库通过分层结构，使得每层数据都有特定的应用范围和职能，从而保证数据结构层次更清晰，结构更明确。使用时，数据表的层级划分能帮助用户快速理解和定位相关数据，减少查询复杂性。
- 优化数据关系，实现层次内模型内聚，层次外模型分离
数据分层设计使每层模型高度集中和统一，专注于特定的数据处理任务，便于维护和优化。数据清洗、整合、转换等操作集中在同一层，提高了数据质量，便于快速定位和解决问题。
不同层次间的模型相对独立，降低了层间耦合度，使一层的变更不会影响其他层，提升了系统的灵活性和可扩展性。这种设计还能更好地应对业务需求变化和系统升级，保障系统的稳定性和高效性。 - 隐藏底层系统复杂性，上游变化避免下游收到多层次影响
当业务系统更新时，数据仓库的分层机制可以有效屏蔽底层变化带来的影响。通过数据仓库层，屏蔽源系统复杂的命名和结构，保证数据仓库的规范性和一致性。即使源系统发生变化，数据仓库层会处理相关调整，避免下游用户的代码和逻辑频繁改动，从而保持数据的连续性和稳定性。 - 增强数据复用，减少重复工作。
通过分层结构，数据在每个阶段被逐步加工和整理，形成可供后续层次直接使用的高质量数据。这种分层方式减少了开发人员在不同任务或项目中对数据进行重复抽取和处理的需求。数据在底层经过一次标准化、清洗和转换后，可以在上层反复使用，避免了重复开发和冗余计算。
例如，不同的业务团队或分析应用可以基于同一数据源进行分析，而不需要每次重新从原始系统抽取和处理数据。这大大提高了开发效率，并减少了因为重复开发带来的潜在错误。 - 实现数据来源分阶段可追溯，避免形成蜘蛛网
分层设计将数据处理划分为多个阶段，每个阶段专注于特定的加工任务，确保在每一层的数据都有清晰的来源和去向记录。这种设计使得数据在流经不同层次时，其处理步骤、转换规则和变更历史能够被完整地追踪和记录。数据血缘追踪在数据仓库分层中尤为显著。
每一层次都保留了数据从原始采集到最终应用的路径信息，这样，当某一层的数据发生异常或问题时，开发人员和数据工程师可以通过数据血缘信息快速定位数据的来源，识别具体的处理步骤并查明问题根源。
数据仓库中的这种分层与分步追踪机制确保了任何数据变更都能被溯源，有助于维护数据质量和可信度 - 简化复杂问题，分步解决复杂业务口径问题
数据仓库分层设计，将复杂的任务拆解为若干易于理解的步骤，每一层只需关注单一任务，方便管理和维护。当数据出现问题时，可以直接从出现问题的步骤开始修复，而无需重新调整整个数据链条，保证数据准确性和系统可维护性。 - 简化维护，保障系统稳定
分层设计让数据仓库的维护更为简便------每层的问题仅需在该层解决，不会影响其他层的代码和逻辑。这种设计能够在性能、成本、效率和质量之间实现更好的平衡，为大数据系统的稳定和高效运行提供了保障。
通过数据仓库的分层和模型方法，大数据系统可以实现结构化、高效的存储与管理，从而在性能与成本的平衡中最大化数据利用价值。
常见数据分层
在上述原则情况下，数据仓库的分层设计并非盲目分层，而是为了解决人员开发、ETL任务组织、数据存储、权限控制等问题。
常见的分层包括ODS（操作型数据）、STG/SDATA（数据贴源层/数据镜像层）、DWD/SOR/PDATA（明细数据层/数据原子层）、DWS/SMA/MID（汇总层/中间层）、ADS/IDX（应用数据层/指标层）、DM（数据集市层）等。
在实际应用中，尽管数据仓库设计通常包含 ODS、DWD、DWS、DWM、DM 和 ADS 等多个层次，但这些分层的界限往往难以严格区分。复杂的业务需求和实际场景可能导致分层策略难以完全落实。例如，为了满足实时分析或跨部门需求，某些层次的数据可能会混合或被简化，从而使得数据架构的实现变得更加灵活和复杂。
这几个层次定义初步如下：
- ODS（Operational Data Store）：操作型数据存储层。 用于存储从多个源系统获取的、经过初步处理的实时或接近实时数据，命名规则贴近于源系统。
- STG/SDATA（Staging Area）：数据贴源层/数据镜像层，有些是从ODS，有些是从源系统导出的数据进入到本层中，进行数据镜像留存，一般表的设计格式是按照天粒度进行切分，例如STG_Table1_20241108，这种类型。
- DWD/SOR/PDATA（Data Warehouse Detail/Source of Record）：明细数据层/数据原子层 。用于存储经过清洗、整合和转换的高粒度明细数据，是数据仓库的核心，一般采用分主题方式设计，目标是通过严格的逻辑模型设计，让数据仓库明细数据屏蔽源系统的影响。
曾经在传统数据仓库时代Teradata和IBM都在这个领域有深厚的积累，例如10大领域模型，11大领域模型等，不过随着业务随着市场快速变化，标准数据仓库模型只能在稳定的业务领域里进行实施和开展，其它模型的规整也变为企业每年/隔年的数据治理项目共同展开了。 - DWS/SMA/MID（Data Warehouse Summary）：服务层或汇总层。用于存储经过聚合和计算的汇总数据，支持常见的业务查询和分析，主要统一业务口径，加强数据复用，减少数据仓库压力，里面会涉及到大量原子指标的计算，一般数据治理主要治理的核心都在这个层次。
- DWM（Data Warehouse Modeling）：过去传统的OLAP模型层。 用于对数据进行建模，形成维度建模、星型模型或雪花模型结构，不过随着新一代OLAP引擎的性能加强和Ad-hoc需求的增多，本层和ADS/IDX层已经逐步合并到一起，成为应用分析层中的一部分。而系统界面的查询更多的会直接到DWS层进行。
- DM（Data Mart）：数据集市层。 为特定的业务线或部门定制的子集数据仓库，提供更灵活和专用的分析能力，主要会分给各业务部门和分支机构，让他们开展自己的分析处理业务。
- ADS/IDX（Application Data Store）： 应用数据层。面向具体应用的最终数据层，提供高效的查询和分析能力，一般会对接BI工具或者内部管理驾驶舱，现在也开始让大模型直接在这个层级取数据实现自然语言查询指标结果。
一般来说，数据仓库的三层结构（ODS、DWD、DWS）是基本框架，各公司可以根据自身业务需求对DW层进一步划分，以便适应不同场景和业务需求。
数据仓库分层下的ETL架构
在不同数据层次、以及源系统到数据仓库之间的ETL（Extraction、Transformation、Loading） 是数据仓库建设的核心，负责将分散在不同源系统的异构数据抽取到临时中间层，经过清洗、转换、集成后加载至数据仓库或数据集市。
通常，ETL规则的设计和执行在数据仓库实施中占据了60%到80%的工作量。而随着数据量的增加和非结构化数据和实时处理需求的增加，ETL架构也逐步被淘汰演变为EtLT架构（参见ELT已死，EtLT才是现代数据处理架构的终点!），以更好地适应多样化的数据源和实时场景。
- 数据抽取（Extraction）
数据抽取负责将原始数据从各源系统中获取。传统的抽取方式包括初始化加载与定期刷新。初始化加载用于建立维表和事实表，将初始数据导入到数据仓库中；数据刷新则负责在源数据变动时追加或更新数据仓库内容。常见的刷新方式有定时任务和触发器。
在处理非结构化数据（如API接口数据、XML文件）和Binlog数据时，抽取步骤会更加复杂。比如，需要通过交互接口（如HTTP API、SaaS API）获取非结构化数据，并对数据库的变更日志（Binlog）进行解析（如Oracle CDC、AWS RDS CDC、MongoDB CDC）。
这些数据在抽取后，通常需转换为仓库兼容的内存格式，以便后续的处理和集成，例如，将多种源数据统一转为WhaleTunnel/SeaTunnel格式供处理引擎使用。 - 轻量级转化/数据清洗（transform/Cleaning）
数据清洗和轻量级转化是为消除原始数据中的二义性、重复性、不完整性或不符合业务规则的数据。清洗过程可以去除无效数据，确保数据的一致性和准确性。轻量级清洗会数据格式化为数据仓库所需的标准格式。不同源系统的数据字段命名或数据格式往往不一致（如A表的字段名为id，而B表为ids），转换过程将统一这些命名和格式，构建一致的数据字典。
一般来说，这一步不会进行复杂的业务逻辑处理，以避免对后续升级和扩展带来依赖。对于复杂的业务逻辑，通常建议在数据仓库内通过SQL或存储过程处理，而不是依赖于外部清洗工具。
这样可以提高系统的灵活性，避免过多依赖特定工具带来的维护成本。
例如，在白鲸开源的WhaleTunnel/SeaTunnel当中利用界面/脚本进行轻量级别数据清洗，增加字段、修改数据类型、修改字段名称、过滤不需要的数据等。 - 数据加载（Loading）
在加载阶段，经过清洗和转换的数据会以批量加载（bulkload）或直接写入的方式存入目标存储系统（如HDFS、Doris、Hive、Hudi、Iceberg、Greenplum等），为数据集市提供基础。
大多数公司会将加载任务整合到内部数据平台和调度平台中（如Apache DolphinScheduler或WhaleScheduler），并封装大数据集群（如Hadoop、Spark、SeaTunnel、Hive等）以提供统一的操作接口。数据平台可以基于权限控制，为不同用户群体提供不同的操作权限，便于管理与维护。
在Load时候，也尽量不使用JDBC模式，因为大量数据加载时候insert/update会行程系统瓶颈，例如，WhaleTunnel/SeaTunnel是全部内存转化和高速加载的，不会把中间数据存储磁盘或数据库当中，同时在Load时候采用高速数据API Bulk Load方式，数倍于JDBC模式。
通常，为了优化任务调度，大公司会将数据仓库划分为不同层级，设立分层，建立不同的工作量/项目进行管理，而不会全面用一个DAG 管理所有的任务。
这样，日常的数千甚至上万条定时任务可以按不同数据仓库层次/业务部门和小组进行维护，通过权限、优先级或依赖关系分层执行，提升调度的管理效率和稳定性。
数据转换（Transformation）
前面讲大量数据通过实时和批量的方式进入数据仓库/数据湖当中，随着数据仓库性能的加强和SQL功能的扩展，目前已经不再流行使用ETL工具（例如Informatica、DataStage、Talend等）在数据仓库当再进行处理，而是直接利用SQL处理复杂的业务。
这样对于系统的移植、人员的管理、以及后续升级到DataOps流程支持敏捷开发都更加的方便。
因此，EtLT架构已经成为现在技术的主流架构。 目前的架构基本都在数数据仓库的某些字段内容可能需要基于多个源字段的逻辑关系计算得出，可以书写相应的SQL完成整体开发。当前，SQL、Python或Shell脚本是常用的转换工具，搭配调度工具（如Apache DolphinScheduler或WhaleScheduler）可以高效管理数据转换任务流。
💓 下篇预告：（二）数据仓库分层下的技术架构