探偈程男《新兴数据湖仓设计与实践手册·从分层架构到数据湖仓架构设计2025 年》 系列文章将聚焦从数据仓库分层到数据湖仓架构的设计与实践。手册将阐述数据仓库分层的核心价值、常见分层类型详解分层下的 ETL 架构及数据转换环节介绍数据仓库分层对应的技术架构并以贴源层ODS、数据仓库层DW、数据服务层DWS为例深入剖析数湖仓分层设计最后探讨数据仓库技术趋势并进行小结。本文为系列文章首篇详细剖析了数据仓库分层的概念与设计希望能够为相关从业者提供数据湖仓设计与实践的系统指引。?? 温馨提醒纯干货分享字数较多建议收藏学习~数据仓库分层的核心价值数据仓库通过分层结构使得每层数据都有特定的应用范围和职能从而保证数据结构层次更清晰结构更明确。使用时数据表的层级划分能帮助用户快速理解和定位相关数据减少查询复杂性。优化数据关系实现层次内模型内聚层次外模型分离数据分层设计使每层模型高度集中和统一专注于特定的数据处理任务便于维护和优化。数据清洗、整合、转换等操作集中在同一层提高了数据质量便于快速定位和解决问题。不同层次间的模型相对独立降低了层间耦合度使一层的变更不会影响其他层提升了系统的灵活性和可扩展性。这种设计还能更好地应对业务需求变化和系统升级保障系统的稳定性和高效性。隐藏底层系统复杂性上游变化避免下游收到多层次影响当业务系统更新时数据仓库的分层机制可以有效屏蔽底层变化带来的影响。通过数据仓库层屏蔽源系统复杂的命名和结构保证数据仓库的规范性和一致性。即使源系统发生变化数据仓库层会处理相关调整避免下游用户的代码和逻辑频繁改动从而保持数据的连续性和稳定性。增强数据复用减少重复工作。通过分层结构数据在每个阶段被逐步加工和整理形成可供后续层次直接使用的高质量数据。这种分层方式减少了开发人员在不同任务或项目中对数据进行重复抽取和处理的需求。数据在底层经过一次标准化、清洗和转换后可以在上层反复使用避免了重复开发和冗余计算。例如不同的业务团队或分析应用可以基于同一数据源进行分析而不需要每次重新从原始系统抽取和处理数据。这大大提高了开发效率并减少了因为重复开发带来的潜在错误。实现数据来源分阶段可追溯避免形成蜘蛛网分层设计将数据处理划分为多个阶段每个阶段专注于特定的加工任务确保在每一层的数据都有清晰的来源和去向记录。这种设计使得数据在流经不同层次时其处理步骤、转换规则和变更历史能够被完整地追踪和记录。数据血缘追踪在数据仓库分层中尤为显著。每一层次都保留了数据从原始采集到最终应用的路径信息这样当某一层的数据发生异常或问题时开发人员和数据工程师可以通过数据血缘信息快速定位数据的来源识别具体的处理步骤并查明问题根源。数据仓库中的这种分层与分步追踪机制确保了任何数据变更都能被溯源有助于维护数据质量和可信度简化复杂问题分步解决复杂业务口径问题数据仓库分层设计将复杂的任务拆解为若干易于理解的步骤每一层只需关注单一任务方便管理和维护。当数据出现问题时可以直接从出现问题的步骤开始修复而无需重新调整整个数据链条保证数据准确性和系统可维护性。简化维护保障系统稳定分层设计让数据仓库的维护更为简便——每层的问题仅需在该层解决不会影响其他层的代码和逻辑。这种设计能够在性能、成本、效率和质量之间实现更好的平衡为大数据系统的稳定和高效运行提供了保障。通过数据仓库的分层和模型方法大数据系统可以实现结构化、高效的存储与管理从而在性能与成本的平衡中最大化数据利用价值。常见数据分层在上述原则情况下数据仓库的分层设计并非盲目分层而是为了解决人员开发、ETL任务组织、数据存储、权限控制等问题。常见的分层包括ODS操作型数据、STG/SDATA数据贴源层/数据镜像层、DWD/SOR/PDATA明细数据层/数据原子层、DWS/SMA/MID汇总层/中间层、ADS/IDX应用数据层/指标层、DM数据集市层等。在实际应用中尽管数据仓库设计通常包含 ODS、DWD、DWS、DWM、DM 和 ADS 等多个层次但这些分层的界限往往难以严格区分。复杂的业务需求和实际场景可能导致分层策略难以完全落实。例如为了满足实时分析或跨部门需求某些层次的数据可能会混合或被简化从而使得数据架构的实现变得更加灵活和复杂。这几个层次定义初步如下ODSOperational Data Store操作型数据存储层。 用于存储从多个源系统获取的、经过初步处理的实时或接近实时数据命名规则贴近于源系统。STG/SDATAStaging Area数据贴源层/数据镜像层有些是从ODS有些是从源系统导出的数据进入到本层中进行数据镜像留存一般表的设计格式是按照天粒度进行切分例如STG_Table1_20241108这种类型。DWD/SOR/PDATAData Warehouse Detail/Source of Record明细数据层/数据原子层。用于存储经过清洗、整合和转换的高粒度明细数据是数据仓库的核心一般采用分主题方式设计目标是通过严格的逻辑模型设计让数据仓库明细数据屏蔽源系统的影响。曾经在传统数据仓库时代Teradata和IBM都在这个领域有深厚的积累例如10大领域模型11大领域模型等不过随着业务随着市场快速变化标准数据仓库模型只能在稳定的业务领域里进行实施和开展其它模型的规整也变为企业每年/隔年的数据治理项目共同展开了。DWS/SMA/MIDData Warehouse Summary服务层或汇总层。用于存储经过聚合和计算的汇总数据支持常见的业务查询和分析主要统一业务口径加强数据复用减少数据仓库压力里面会涉及到大量原子指标的计算一般数据治理主要治理的核心都在这个层次。DWMData Warehouse Modeling过去传统的OLAP模型层。 用于对数据进行建模形成维度建模、星型模型或雪花模型结构不过随着新一代OLAP引擎的性能加强和Ad-hoc需求的增多本层和ADS/IDX层已经逐步合并到一起成为应用分析层中的一部分。而系统界面的查询更多的会直接到DWS层进行。DMData Mart数据集市层。 为特定的业务线或部门定制的子集数据仓库提供更灵活和专用的分析能力主要会分给各业务部门和分支机构让他们开展自己的分析处理业务。ADS/IDXApplication Data Store 应用数据层。面向具体应用的最终数据层提供高效的查询和分析能力一般会对接BI工具或者内部管理驾驶舱现在也开始让大模型直接在这个层级取数据实现自然语言查询指标结果。一般来说数据仓库的三层结构ODS、DWD、DWS是基本框架各公司可以根据自身业务需求对DW层进一步划分以便适应不同场景和业务需求。数据仓库分层下的ETL架构在不同数据层次、以及源系统到数据仓库之间的ETLExtraction、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可以高效管理数据转换任务流。