数据工程中的10个常见设计方式

除了 ETL（抽取、转换、加载）、ELT（抽取、加载、转换） 和 CDC（变更数据捕获）等常见数据集成设计模式之外，行业中还广泛采用了许多其他类型的设计方式，以应对日益复杂的数据处理需求。这些设计方式涵盖了从数据存储、流动到消费的各个环节，旨在提升系统的可扩展性、灵活性和实时处理能力。接下来将介绍一些在现代数据架构中更为常见且实用的设计方式，它们在不同场景下为数据工程实践提供了有力的支持。

数据传输

数据工程中的数据传输是通过工具或协议实现数据在系统间高效、安全移动与同步的过程，支撑数据集成与分析。

1. 零拷贝数据传输

在系统级编程中，“零拷贝”（Zero-copy）是一种旨在减少数据传输过程中不必要的内存复制操作的技术。其核心思想是通过绕过 CPU 的参与，将数据直接从磁盘文件传输到网络接口设备，而无需应用程序介入数据复制过程。这种方式不仅降低了 CPU 的负载，还提高了数据传输的效率和吞吐量。

例如，在现代操作系统中，Java 提供了 transferTo 方法，它利用 Linux 内核中的 sendfile() 系统调用来实现高效的文件传输。这种方法避免了传统方式中多次在用户空间与内核空间之间切换上下文所带来的性能损耗。目前，NGINX 和 KAFKA 等高性能系统已广泛采用这种技术作为其底层数据传输机制的重要组成部分。

然而，零拷贝并非适用于所有场景。由于它跳过了用户空间，因此在需要对传输数据进行处理的情况下（如加密、压缩或内容转换），该技术就显得力不从心。因此，零拷贝更适合于那些仅需高效传输原始数据而不涉及中间处理的场景。

此外，零拷贝有多种实现方式，具体取决于系统架构和应用场景。例如，可以通过内存映射（memory map）配合 write 系统调用实现，也可以结合 sendfile 与文件描述符（File Descriptors）来完成高效的数据传输。另一种常见的方法是使用 sendfile 搭配 DMA（直接内存访问）的“聚集-收集”（Gather Collector）机制，以进一步减少内存操作。

如果对操作系统级别的性能感兴趣的话， 推荐阅读毛文安等老师的《深入理解eBPF与可观测性》一书——

值得一提的是，Splice（拼接） 是一种基于元数据操作的零拷贝技术。它并不真正复制数据本身，而是操作数据的元信息（metadata）。这种设计建立在存储与计算分离的基础之上，使得计算层只需处理元数据，而非实际数据内容。当发生更新时，系统也只需要修改受影响的部分元数据，从而实现更高效的数据管理与差异保留。这为构建高性能、低延迟的数据传输系统提供了坚实的技术支撑。

2. n 路队列数据传输

在多个应用程序需要使用相同数据的场景下，传统的做法是由数据源直接向每个系统分别发送数据。然而，这种方法不仅增加了数据源的复杂性和负担，还可能导致数据一致性和同步问题。为了解决这些问题，可以采用队列或主题（topic）的方式进行数据传输。具体来说，数据源只需将数据发送到一个中心化的队列或主题中，而各个消费者应用则根据自身需求从这个共享的数据管道中异步获取所需信息。

这样一来，不但简化了数据源的设计和实现，同时也提高了系统的可扩展性和灵活性，使得添加或移除消费者变得更加容易而不影响整个系统的稳定性和性能。此外，这种模式有助于确保所有消费者接收到的数据是统一且一致的，进一步提升了数据处理的准确性和可靠性。通过利用队列或多路广播机制，数据能够在不同的应用之间高效流转，满足现代分布式系统对于实时性和高并发的要求。

数据处理

3. Lambda 架构

Lambda 架构是一种统一的数据处理体系，旨在同时支持实时数据和历史数据的采集、处理与查询。该架构的设计理念在于通过一套系统来应对两种主要的数据处理需求：对海量历史数据的批处理和对新产生数据的实时处理。其核心思想是为这两类数据流复制相同的处理逻辑，从而保证最终输出的一致性与准确性。

整个架构由三个层次组成：批处理层负责对全量数据进行长期存储和周期性计算；速度层则专注于低延迟的实时数据处理，以快速响应最新数据变化；而服务层用于将批处理和流处理的结果合并，并对外提供统一的查询接口，使用户能够高效地获取最新的分析结果。

4. Kappa 架构

Kappa 架构可以看作是对 Lambda 架构的一种简化和优化，它将原本的三层结构缩减为两层：处理层和服务层。在 Kappa 中，所有的数据处理任务都统一交由流处理引擎完成，无论是实时数据还是历史数据，都通过重放日志的方式来实现批处理功能。这种设计去除了单独的批处理层，使得整体架构更加简洁、易于维护，同时也降低了系统中因重复处理逻辑而引发不一致的风险。

通过统一使用流式处理模型，Kappa 架构不仅减少了组件复杂度，还提升了系统的实时能力与一致性保障，成为当前越来越多流处理平台所采用的架构模式。

数据建模

随着数据来源的多样化以及消费方式的不断演进，一个清晰、高效的数据建模策略已成为确保系统成功的关键因素。良好的数据模型不仅有助于提升查询性能和数据一致性，还能更好地支持复杂的分析需求。

5. 规范化与非规范化：两种核心建模方法

在数据建模中，规范化（Normalized）和非规范化（Denormalized）代表了两种不同的设计思路。规范化模型通常用于模拟真实业务系统的结构，强调去除数据冗余并以存储效率为导向。它通过将数据拆分为多个高度结构化的表来减少重复，并依靠多表连接（Join）实现数据完整性。这种模式常见于操作型数据库和面向特定主题的数据集市（Data Marts），适用于需要频繁更新和强一致性的场景。

与此相对，非规范化模型则更侧重于满足消费端或业务用户的查询需求，通常被称为“维度建模”。该方法通过构建星型模式（Star Schema）或雪花模式（Snowflake Schema）来优化查询性能。其中，维度表用于描述业务实体的属性和可能性，例如时间、地点或产品；而事实表则记录具体的业务事件，表示这些可能性的实际发生情况，如销售记录或用户行为日志。

此外，在维度建模中，处理缓慢变化维度（Slowly Changing Dimensions, SCD）是一个关键问题。由于某些维度信息（如客户地址或产品分类）会随时间发生变化，如何有效地追踪历史变更并保持当前状态，对保证分析结果的准确性至关重要。根据不同的业务要求，SCD 通常有多种处理策略，如直接覆盖旧值、添加新记录保留历史，或采用时间区间等方式进行管理。

如果面对多模态的结构/半结构/非结构化数据，推荐阅读巴川老师的《多模态数据分析》——

选择合适的建模方式应基于具体的应用场景和性能需求。规范化模型适合写入密集、数据一致性要求高的系统，而非规范化模型则更适合读取频繁、需快速响应复杂查询的分析平台。两者各有优势，在实际应用中也可结合使用，以实现灵活性与性能的平衡。

6. Data Vault 建模

Data Vault 是一种专为可扩展性和历史追踪而设计的数据建模方法，特别适用于需要整合来自多个源系统的复杂环境。它通过一组结构化的建模元素来表示核心业务实体、它们之间的关系以及相关的描述性信息。

在 Data Vault 中，集线器（Hub）用于表示企业中最核心的业务概念及其唯一标识符和元数据，是整个模型的主干部分。链接（Link）则用来表达这些核心实体之间的关联，支持灵活且可扩展的关系建模。而卫星（Satellite）则负责存储与集线器或链接相关的信息，并能够捕捉随时间变化的历史状态，其变更管理方式类似于 Type II 缓慢变化维度（SCD），从而保留完整的变更轨迹。

此外，Data Vault 的架构通常分为三个逻辑层：原始层（Raw Layer）、业务层（Business Layer）和表示层（Presentation Layer）。原始层主要用于存储未经清洗的原始数据，业务层则进行一致性处理和整合，表示层面向最终用户，提供易于理解和使用的数据视图。

由于其高度模块化、可扩展性强的特点，Data Vault 非常适合应用于现代 Lakehouse 架构中，能够有效支持从数据湖到数据仓库的多层次分析需求，同时兼顾灵活性与治理能力。

7. 宽表模型

宽表是一种典型的非规范化数据结构，常被形象地称为“一张大表”（One Big Table, OBT）。它通过将事实表与多个维度表的关联结果预先计算并存储，形成一个包含丰富上下文信息的单一表结构，从而大幅提升查询效率，尤其适用于需要频繁进行多维分析和快速响应的场景。

这种模型的核心优势在于其简化了查询逻辑，避免了复杂且耗时的多表连接操作，使用户能够更直接、高效地访问所需数据。例如，在像 BigQuery 这样的现代云数据仓库中，宽表被广泛使用，以支持大规模数据分析和实时报表生成。

在构建和维护宽表的过程中，通常会借助自动化数据管道来提升效率与一致性。开发人员可以使用如 Airflow 和 dbt 等工具，实现从数据抽取、转换到加载（ETL/ELT）全过程的代码化管理。这些工具不仅支持任务调度和依赖管理，还能确保数据处理流程具备良好的可维护性和可扩展性。

同时，在数据库对象的持续交付（CD）方面，Liquibase 或 Flyway 等工具也被广泛采用，用于版本化管理数据库结构变更，确保宽表及相关对象在不同环境中的部署一致且可控。

宽表模型通过牺牲一定的存储空间换取了查询性能的显著提升，是现代数据分析平台中一种非常实用的设计模式，尤其适合对响应速度和易用性有较高要求的业务场景。

如果您希望更好地掌握数据体系建设，推荐阅读王晓华老师的《一本书讲透数据体系建设：方法与实践》——

8. 数据仓库：星型模式下的并行加载优化

在传统的星型模式数据仓库架构中，数据加载通常遵循先维度表、后事实表的顺序。这种串行加载方式虽然能确保外键约束的完整性，但也带来了明显的性能瓶颈，尤其是在处理大规模数据时，维度表的加载延迟会直接影响到整个ETL流程的效率。

为了解决这一问题，一种常见的优化策略是引入代理键的哈希计算机制。具体来说，可以在数据准备区（staging area）中对维度表的关键字段生成 VARCHAR(32) 类型的代理键，并通过计算其 MD5 哈希值作为唯一标识。这样可以在不依赖实际维度表主键的前提下，提前准备好事实表所需的外键信息。

在此基础上，进一步的改进措施包括禁用外键约束，从而实现维度表与事实表的并行加载。通过这种方式，多个数据流可以同时进行加载操作，大幅缩短整体加载时间。待所有数据加载完成后，再重新启用外键约束，以保证数据的一致性和引用完整性。

这种优化方法不仅提升了加载性能，还增强了系统的可扩展性，特别适用于高并发、大数据量的现代数据仓库环境。同时，它也为构建高效、灵活的数据管道提供了坚实的基础。

9. 事实表子集化

在处理大规模数据环境中的大型事实表时，为了提升查询性能并优化数据处理效率，可以采用一种称为“事实表子集化”的策略。该方法的核心思想是根据实际的访问模式和使用场景，从原始的大型事实表中提取出一个精简的数据子集，构建一个结构更为紧凑、查询响应更快的小型事实表。

这个子集通常包含最常被访问或最关键的业务数据，例如最近一段时间内的交易记录、高频查询所涉及的特定维度组合等。通过这种方式，不仅可以减少每次查询扫描的数据量，还能降低ETL处理的开销，提高整体系统性能。

值得注意的是，这种小型事实表可以在与主事实表相同的批次流程中进行填充，也可以作为独立的数据流单独处理，视具体的数据架构和业务需求而定。无论采用哪种方式，事实表子集化都为实现更高效的数据分析提供了一种灵活且实用的解决方案，尤其适用于对响应速度和资源利用率有较高要求的场景。

数据组织

数据工程中的数据组织通过结构化存储、分类和目录管理，提升数据可访问性、管理效率，并确保数据质量。

10. Medallion Lakehouse

Medallion Lakehouse 是一种分层数据组织架构，旨在通过层级化的结构提升数据质量和可用性。该架构将数据按照处理阶段划分为多个层次，每一层都代表了不同成熟度的数据资产，并为下一层提供更高质量、更结构化的输入。

最底层是 Bronze 层，用于存储从源系统直接摄取的原始数据，通常以“原样”（raw）或增量形式保存。这一层的数据尚未经过清洗或转换，保留了最原始的状态，主要用于数据的初步存储和后续处理。

在 Bronze 层基础上，数据经过清洗、验证和初步整合后进入 Silver 层。这一层的数据已经去除了无效或错误记录，具备一致的格式和基本的业务规则，适合用于轻量级分析或作为上层数据处理的来源。

最终，Silver 层的数据进一步丰富、聚合并建模，形成面向具体业务场景的结构化数据，进入 Gold 层。该层数据质量最高，专为支持关键业务指标、报表展示或高级分析而设计，具有高度的可读性和即用性。

这种逐层演进的方式不仅提升了数据治理能力，还增强了整个 Lakehouse 架构的灵活性与可维护性，使其成为现代数据平台中广泛采用的一种组织模式。

如果您希望掌握从数据驱动业务决策到整体的数据空间的体系建设，推荐阅读林建兴老师的《数据空间知识体系指南》【关联阅读】