新兴数据仓库设计与实践手册：从分层架构到实际应用（二）

本手册将分为三部分发布，以帮助读者逐步深入理解数据仓库的设计与实践。

第一部分介绍数据仓库的整体架构概述；
第二部分深入讨论ETL在数仓中的应用理论，ODS层的具体实现与应用；
第三部分将围绕DW数据仓库层、ADS层和数据仓库的整体趋势展开；

通过这样的结构，您可以系统地学习每一层次的内容和设计原则。

前情提要：《新兴数据仓库设计与实践手册：从分层架构到实际应用（一）》https://mp.weixin.qq.com/s/_iYSM0sT_NOysducbxEJhg

数仓分层下的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脚本是常用的转换工具，搭配调度工具（如DolphinScheduler或WhaleScheduler）可以高效管理数据转换任务流。

数仓分层的技术架构

数据中台的构建涉及多个方面，涵盖了大数据处理和管理的核心要素，在实际工作中通常包括以下内容：

01 系统架构

以Hadoop和Spark等大数据组件为核心，构建高效的分布式架构，以支持数据的存储、计算和处理能力。

02 数据架构

通过顶层设计进行主题域划分，并采用分层体系（如ODS-DW-ADS）来组织数据流向和结构层次，确保数据管理的灵活性和适应性。

03 数据建模

采用维度建模方法，通过确定业务过程的粒度，构建合理的维度表和事实表，以便更高效地支持业务分析和查询需求。

04 数据管理

包括对数据资产、元数据、数据质量、主数据和数据标准的全面管理，同时建立数据安全管理机制，确保数据的准确性、完整性和安全性。

05 辅助系统

包含任务调度、ETL处理以及监控等支撑系统，保障数据的高效处理和系统运行的稳定性。

06 数据服务

提供数据门户、数据查询、分析报表、可视化、机器学习和数据挖掘等服务，支持数据的多场景应用，以及数据交换、共享和下载功能。

数仓分层

在前面给大家粗略介绍了数据仓库的分成概念，接下来给大家详细介绍：数据仓库通常可以分为四个层次，但这一划分并不是固定的，不同公司可能会根据自身需求进行调整或重新命名。

ODS 贴源层

数据引入层（ODS，Operational Data Store），也称为数据基础层。这一层主要存放从源系统引入的原始数据，几乎不做任何加工处理，目的是将基础数据直接同步到数据仓库中，便于后续的数据处理工作。

在结构上，ODS层的数据与源系统保持高度一致，是数据仓库的数据准备区。

在现代数据架构中，ODS层的数据获取方式逐步向CDC（Change Data Capture，变更数据捕获）模式转变，尤其在数据湖和实时数据仓库的场景中。

新型的ETL工具已经可以支持源系统的DDL（数据定义语言）变更，这意味着当源系统的字段发生变化时，ODS层可以自动更新表结构，无需手动调整。

例如，WhaleTunnel这样的工具支持多种系统的DDL变更捕获，保证了ODS层数据在数据仓库、数据湖或实时数据仓库中的一致性，不会因为源系统的改变而中断ETL流程。

ODS层的数据通常分为当前数据和历史数据两部分：

当前数据表：用于存储最近需要处理的数据，保持最新的数据状态。
历史数据表：保存已处理完的数据以备后续使用，一般保留3-6个月后清理，具体时间视项目需求而定。如果源系统的数据量较小，也可以选择更长时间的保存，甚至全量保存。

数据清洗和规范化

尽管ODS层主要作用在于数据引入，但并非完全不做处理。

此层通常会进行基本的数据清洗，例如：

处理异常字段、规范化字段命名、统一时间格式
确保数据一致性，为后续数据处理和特征工程奠定基础

一些公司会选择在ODS层就进行初步的清洗和过滤，而另一些则将更多的数据加工留在DWD层。

选择在哪里进行清洗取决于企业的技术规范和需求。在实际开发中，大多数企业会在将数据存入ODS时进行基本处理，以减少后续工作量。

数据来源及存储策略设计

数据来源可按时间进行分区存储，通常以日为粒度，也有公司采用年、月、日三级分区以优化存储效率。

数据在进入数据仓库前进行基础清洗，如格式错误数据的剔除、关键信息缺失的过滤等，以保证数据质量。数据可分为实时和离线两种处理模式。

离线数据处理

离线数据通常通过定时任务（如每日批量任务）从业务系统或数据库中抽取。典型的日计算任务会在凌晨执行，通过SeaTunnel、DataX 或 WhaleTunnel从业务数据库提取数据，计算前一天的业务指标，并生成报表。

Hive、Spark常用于批量计算，计算结果存储于Hive、HBase、MySQL、Elasticsearch 或 Redis等系统中，供后续分析使用。

实时数据处理

实时数据源主要来自日志埋点数据或业务数据库，常用于实时推荐、用户画像等业务需求。

Spark Streaming 和 Flink负责实时计算，结果通常写入Elasticsearch、HBase 或 Redis。

实时数据源可利用WhaleTunnel监控MySQL的Binlog变化，将数据实时写入Kafka 或 HDFS。

数据来源

业务数据库：公司各业务系统生成的结构化数据。
日志数据：包括用户行为日志和系统后台日志。埋点数据首先经由Nginx上报，再由Flume收集并存储在Kafka等消息队列中，随后由SeaTunnel或WhaleTunnel拉取至离线数据仓库（如HDFS）。
外部数据：包括合作伙伴提供的数据或爬虫采集的数据，整合后用于补充业务分析。

数据存储策略（增量、全量、拉链）

在实际应用中，可根据需求选择增量、全量或拉链存储方式。

增量存储增量存储通常按天分区，以业务日期为分区字段，每日存储新增的业务数据。

例如，用户A在1月1日访问了店铺B，生成记录t1，并于1月2日访问店铺C，生成记录t2。增量存储会将t1存入1月1日的分区，将t2存入1月2日的分区。

如果用户A在1月1日购买商品B（生成t1记录）并在1月2日退货（更新t1记录），增量存储会将初始购买记录存于1月1日分区，退货更新后的记录则存于1月2日分区。

对于交易日志和行为日志等高频变更的数据表，增量存储能减少存储成本和数据冗余。下游分析需求一般只需聚合后的汇总数据，因此不需要长期保存全量的历史数据。

全量存储全量存储以日为分区，每个分区记录当天的完整业务数据快照。

例如，1月1日，卖家A发布了商品B和C，生成记录t1和t2。1月2日，卖家A下架商品B并上架商品D，此时商品B记录t1会更新，商品D生成新记录t3。

全量存储会在1月1日分区保存t1和t2，在1月2日分区保存更新后的t1、t2和t3。

对于数据量较小、变化缓慢的维度数据（如商品分类），全量存储能够保证数据完整性和易用性。
拉链存储拉链存储通过在表中增加开始时间（start_dt）和结束时间（end_dt）两个时间戳字段，记录每次数据变更，并以时间为分区字段。这种方式适用于记录所有变更数据的历史快照，为分析数据演变过程提供支持。