引言（Introduction）
本章将对常见的数据工程模式做一个高层概览，说明其重要性以及如何有效运用这些模式来解决领域中的常见挑战。文中还包含这些模式的示例，展示它们如何解决数据工程中经常遇到的典型问题。同时，本章会引入数据工程中的关键术语，并解释这些术语在模式语境下的意义。理解这些术语至关重要，因为全书会反复引用它们来解释模式、应用场景与示例。
本书会按数据生命周期中的角色——摄取、转换、存储、服务——对各种数据工程模式进行分类。在每个类别下，又会依据特定用例（如实时 vs. 批处理、热存储 vs. 冷存储）进一步细分，帮助你全面理解这些模式如何在不同场景中落地。书中还将探讨支撑数据工程模式的多样化技术：从数据摄取工具到面向不同用例的数据库存储系统；并讨论各项技术的收益与权衡（成本、管理开销、复杂度等），帮助你在为数据工程需求选型时做出明智决策。
结构（Structure）
本章涵盖以下主题：
- 认识数据工程模式
- 数据工程模式的重要性
- 数据工程模式示例
- 模式的有效使用
- 数据处理与摄取模式
- 数据存储与处理模式
目标（Objectives）
读完本章后，你将理解什么是数据工程模式，并能讨论若干实例；理解如何用模式构建数据管道的可复用组件；同时了解各类数据摄取、处理、存储与服务模式以及对应的实现技术。
认识数据工程模式（Understanding data engineering patterns）
数据工程中存在一套可复用的解决方案与模板，可应用于多种问题场景，这些可复用方案即称为数据工程模式。类似于软件工程中的模式，它们通过多年创新积累的标准化与架构韧性，帮助我们构建稳健的数据系统。
数据工程模式的重要性（Importance of data engineering patterns）
数据工程模式之所以关键，在于它们标准化了经多年实践打磨的成熟架构。同一个数据工程问题往往有多种做法，但应优先采用对该问题最高效的架构与技术。数据工程模式正是帮助工程师识别这些经过验证且稳健、具成本效益的解法。
模式还能帮助工程师避开性能陷阱，减少为了“定制”而踩坑的概率，从而用更少的硬件投入降低系统的 TCO。同时，模式把安全最佳实践“内嵌”其中，帮助打造更安全的数据系统。对于经验尚浅的工程师，按照“问题 → 模式”的映射来实施，也能构建出高质量系统。
数据工程模式示例（Examples of data engineering patterns）
本节通过两个示例，帮助理解数据工程模式是什么，以及如何在企业中用它们解决业务用例。两个示例分别是：基于实时数据工程模式的推荐系统，以及使用缓存模式来解决消费级应用的用户画像查找问题。它们都说明：以方法化、经验证的方式应用数据工程模式，对解决业务问题至关重要。
实时数据摄取（Real-time data ingestion）
许多企业用例需要实时数据摄取，如：金融交易欺诈检测、电商商品推荐、机票/网约车动态定价、物流运输跟踪等。实时系统的时延需求可能从亚毫秒到数秒不等，传统批处理技术难以满足。要实现亚毫秒级时延，通常需要专门技术，而实时数据工程模式正演示了这类技术路径。
以电商推荐系统为例：系统利用应用的点击流来理解用户偏好。此用例时间敏感——用户浏览商品目录时，个性化推荐应当实时呈现。为此，推荐系统需要掌握该用户的实时点击流。
然而，推荐系统通常运行在分析与 AI 平台上，而非电商应用所在的事务系统。因此，需要将点击流实时送往分析平台：在事务系统中采集点击流，写入消息系统（如 Apache Kafka），再通过 Kafka Connectors 将数据推送到分析系统。Kafka 提供必要的流控与消息投递保证，即便源/汇系统因维护（计划内或计划外）离线也能缓冲与重试。
图 2.1：基于 Apache Kafka 的实时推荐系统架构（Figure 2.1: Real-time system for recommendations）
缓存（Caching）
缓存是最常见的数据工程模式之一。其思想是在高速的临时层存储数据，以加速读取。当从持久化存储读取的速度无法满足应用的时延要求时，通常会在持久层之上构建缓存。数据库的持久化依赖磁盘（机械盘或 SSD），但即便是 SSD，要达到亚毫秒级读延迟也并不容易；缓存系统则通过**主存（如 DRAM）**来承载从持久层“热点”提取的数据。
以社交平台的用户画像缓存为例：用户注册后，画像数据通常存于关系型或 NoSQL 持久库中。但当用户再次登录需要回显画像时，这些数据库很难稳定提供亚毫秒的响应。
为达成亚毫秒响应，社交应用会使用如 Redis 或 Couchbase 的缓存，把用户画像从持久库缓存起来。应用读取画像时，优先命中缓存，避免直接访问持久库。
图 2.2：写通缓存（write-through）与同步流程示意（Figure 2.2: Cache write through with sync）
翻译
有效使用模式（Effective use of patterns）
数据工程模式通过提供稳健、可复用的解决方案，显著简化数据工程师的工作。然而，为特定用例/问题选择正确的模式至关重要。模式的价值取决于其与问题的匹配度。选错模式不仅会使方案无效，还可能导致次优实现、成本失控乃至失败。
来看一个例子，说明正确选型的重要性。在社交媒体场景中，分析工具会对单条或一组帖子进行情绪分析（sentiment analysis） ，以理解品牌参与度、正/负面影响等。评论会持续产生，因此需持续分析。乍看之下，这似乎适合实时摄取与分析，但事实并非如此，主要有两点原因：
- 分析粒度：不需要对每条单独评论实时分析并立刻行动，更适合在短时间窗口内做聚合级别的分析。
- 计算成本：对每条评论做强实时分析计算代价极高，整体方案成本不可承受。
因此，更合适的模式是微批处理（Micro-batching） ：按分钟或小时聚合评论后再分析。之所以称为“微批”，是因为把一批评论打包处理，但批次很小、运行间隔很短，从而保持分析的新鲜度。与实时模式相比，微批的运行成本要低得多（例如无需为超低时延场景配置庞大的 Kafka 等基础设施）。可见，从用例到模式的映射需要谨慎推敲，才能有效地使用模式。
数据处理与摄取模式（Data processing and ingestion patterns）
数据处理与摄取模式用于构建从上游事务系统取数、转换，并将数据迁移到下游分析/ML 系统的管道。此类模式会根据处理方式与时延要求的不同而区分。
批量摄取与处理（Batch ingestion and processing）
批处理是应用最广的模式，因其实现简单、成本低（工程投入与技术栈要求都较低）。许多业务用例按固定周期运行分析产出定时报表，这与批处理范式天然契合。
批处理指在预先设定的时间间隔内，收集并一次性处理大量数据。典型如银行向监管机构的日终报送（流动性、资产负债表、反洗钱、衍生品/外汇等）。为此，银行需将多源数据汇聚到分析系统，并在日终出报。既然报表按计划在日终运行，那么白天按批次采集并写入分析库即可。实现上，可用如 Apache Spark 定义作业（每小时抽取上一小时数据→转换→加载至目标分析库），再用 cron 调度，或用 Apache Airflow 等高级编排工具。
如上所示，采用批处理无需 CDC、消息队列等复杂技术，简单即力量。为任意用例设计方案时，数据工程师都应先自问：能否用批处理解决？ 若能，就不必上更复杂的栈。
常用技术栈（详见后续章节与代码示例）：
- 数据处理：MapReduce、Hive、Apache Spark、AWS EMR
- 编排：Apache Airflow、Control-M
- 存储：Amazon S3、HDFS
实时摄取与处理（Real-time ingestion and processing）
实时处理随着对“即时洞察”的需求增长而迅速普及，常见于电商、支付、出行、文娱等存在实时交互的行业。实时的定义依用例而异，可从亚毫秒到数秒不等。
实时系统需要数据一产生就取到。常用做法是 CDC：
- 源为数据库时，可读取事务日志以捕获变更；
- 源为 Kafka 等消息系统时，直接消费新增消息。
实时变更取到后进入转换阶段。为避免引入时延，实时链路通常只做最小化转换。例如在 Kafka 生态中，可用 Single Message Transforms (SMT) 注入简单转换。
随后是可用性/服务化：常将实时处理与缓存模式结合，以低时延提供查询。流水线可将数据加载到 Redis/Couchbase 支持点查，同时把数据写入分析型数据库以支持复杂分析。可见，多种模式可组合以满足用例需求：CDC/消息系统支撑“取/转”，缓存系统支撑“存/服”。
常用技术栈（详见后续章节与代码示例）：
- 消息/流：Apache Kafka、Apache Flink、AWS MSK、GCP Pub/Sub
- 缓存/低时延服务：Redis、Couchbase
- CDC：Oracle GoldenGate、Debezium、IBM InfoSphere Data Replication
- 实时处理：Spark Structured Streaming
微批处理（Micro-batching）
微批在批处理与实时之间折中：成本接近批处理，数据接近实时可用。其架构与批处理相似，但批次更小、间隔更短，因此数据的可用性更“实时”。
常用技术栈（详见后续章节与代码示例）：
- Apache Hadoop、MapReduce、Hive
- Apache Spark、Apache Airflow
- AWS EMR、Amazon S3
注：与批处理技术栈基本一致，因微批是对传统批处理的演进。
Lambda 架构（Lambda architecture）
Lambda 架构融合批处理与实时两者优势：在提供实时可用性的同时，保证高质量处理。其包含三层：批处理层（Batch） 、速度层（Speed） 、服务层（Serving） 。
- 批处理层：在历史全量数据上进行复杂转换与聚合，产出高质量的整备数据。由于数据量大、处理复杂，运行较慢，但能提供只有历史视角才能完成的深度分析价值。
- 速度层：确保事件发生即可用，便于立刻采取行动。为保证时效，不做复杂转换。
- 服务层：将批层与速度层的数据视图合并，向用户提供统一视图。
Lambda 架构复杂且成本高（内部同时实现批与实时，并需多元技术栈），应按需谨慎采用。
批处理层技术栈：
- 数据处理：MapReduce、Hive、Apache Spark、AWS EMR
- 编排：Apache Airflow、Control-M
- 存储：Amazon S3、HDFS
速度层技术栈：
- 消息/流：Apache Kafka、Apache Flink、AWS MSK、GCP Pub/Sub
- 缓存/低时延服务：Redis、Couchbase
- CDC：Oracle GoldenGate、Debezium、IBM InfoSphere Data Replication
- 实时处理：Spark Streaming
ETL 与 ELT
提取-转换-加载（ETL） ，顾名思义，是在提取数据与将其加载到目标系统之间加入数据转换阶段的模式。转换步骤会执行数据清洗、标准化、格式转换、富化等多种数据处理任务。历史上，这些转换常由 IBM DataStage、AbInitio 等专有工具完成，但在现代架构中更偏好使用 Apache Spark 来运行转换。
当我们希望只将已处理且干净的数据写入目标系统时，ETL 是首选模式。之所以只将清洗后的数据写入目标系统，原因多样：例如合规要求，或目标系统无力存储与处理原始数据。ETL 也非常契合传统的数据仓库架构——在该架构中，通常建议数据仓库仅对经过转换的高质量数据运行 BI 查询。
提取-加载-转换（ELT）是另一种模式：先提取并加载数据到目标系统的暂存表，再从暂存表将数据转换并加载到主表。这种做法无需在中间系统完成转换，但会把转换的计算负载转移到目标系统本身。该方式并不适合以运行 BI 工作负载为主的数据仓库：如果在数据仓库上直接执行转换作业，而又未对资源使用进行隔离，就可能干扰 BI 工作负载。ELT 更适合运行在 Hive + HDFS 等大数据架构上：先将原始数据落到 HDFS，再用 Hive 将其转换、整形为所需的目标格式，然后对外提供分析使用。
ETL 与 ELT 的技术栈通常与批处理模式类似，因为复杂转换往往只能在批处理过程中完成——它们较慢且消耗大量计算资源。
ETL/ELT 常用技术栈：
- 数据转换作业：MapReduce、Hive、Apache Spark、AWS EMR
- 编排：Apache Airflow、Control-M
- 暂存存储：Amazon S3、HDFS
- 数据仓库：Oracle Exadata、Vertica、DB2 BLU、ClickHouse
数据存储与处理模式
数据存储与处理模式关注在不同场景下如何存与取的数据方法论。每个业务用例在存储成本、检索时延、吞吐量、可扩展性、可靠性、压缩等维度都有不同诉求。这些模式为这些诉求的不同组合提供了经过验证的模板化解决方案，帮助在为存取构建复杂数据工程方案时避免架构性失误。
数据库与事务型数据
数据库类型众多，数据库模式的作用是为给定用例选择合适的数据库类型。关系型数据库以行列结构化表格存储数据，已存在数十年并支撑了全球大部分关键软件基础设施。然而，关系型数据库灵活性不足、扩展成本高，也不太适配 Web 与移动等现代编程范式。
为克服这些问题，NoSQL 数据库应运而生。它以半结构化/非结构化方式存储数据，相比固定模式的关系型数据库更灵活。NoSQL 有多种类型，如键值存储、文档存储、宽列存储等；其易于扩展与运维，并提供现代应用所需的更灵活数据模型。许多 NoSQL 还是多模型（multi-model） ：单一数据库支持多种数据存储与访问模式。例如 Couchbase 既支持以键值对形式存储并通过 store/get 访问，也支持存储 JSON 文档并用 SQL 查询。
关系型数据库常见技术栈：
- 开源：MySQL、Postgres
- 企业与托管：Oracle、DB2、SQL Server、AWS RDS
NoSQL 数据库常见技术：
- MongoDB、Couchbase：多模型，支持键值与文档
- Cassandra：宽列存储
- DynamoDB：键值存储
面向数据分析的数据仓库
数据仓库是事务型关系数据库在分析领域的“表亲”，专为在大数据集上运行复杂分析查询而生。它从多个事务系统汇聚数据，为企业提供统一的分析视图。为确保进入仓库的数据干净且可信，通常在到达数据仓库前使用 ETL 进行转换。诸如 Power BI、Tableau 等 BI 工具通常从数据仓库取数生成报表。
数据仓库常采用列式存储并具备大规模并行处理（MPP）能力，这是在大数据集上高效快速查询的关键。尽管 Lakehouse（将数据仓库性能与数据湖的规模和灵活性结合）正兴起，但由于其简单与专用，数据仓库仍非常流行。
数据仓库常见技术：
- 本地/企业：Oracle Exadata、DB2 BLU、Vertica
- 开源：ClickHouse
- 云端：Amazon Redshift、Snowflake
数据湖与 Medallion 架构
数据湖是企业集中采集、存储与处理全部数据的系统，为收集海量原始、未处理数据提供低成本存储与计算，确保组织内各数据工程团队都能访问公司产生的原始数据以构建数据资产。
Medallion 架构是现代数据模式，将处理系统分为 青铜（Bronze）/白银（Silver）/黄金（Gold） 三层：
- Bronze（青铜） ：在数据湖等系统中存放原始数据，作为企业原始未处理数据的“集散地”。
- Silver（白银） ：消费 Bronze 数据，进行清洗、转换与富化，形成可用数据，用于探索性分析。
- Gold（黄金） ：在 Silver 基础上进一步面向用例精炼，为数据仓库与机器学习做准备。例如构建聚合结果装载进数据仓库以支持 BI。
构建数据湖的常见技术：
- 存储：HDFS、S3
- 处理：MapReduce、Hive、Apache Spark
- 集成：Apache Kafka
构建 Medallion 的常见技术：
- Bronze：HDFS、S3、Hadoop 等低成本原始数据存储
- Silver：在 Delta Lake、Apache Iceberg、Apache Hudi 等 lakehouse 格式之上，配合 Apache Spark
- Gold：Vertica、Oracle Exadata、ClickHouse、Snowflake 等数据仓库，以及诸如 Databricks 等云数据管理平台
数据复制与分区
在大规模系统中，数据复制与分区模式对可靠性与性能至关重要。存储与服务应用天然易受硬件/软件故障影响（“故障”）。为保证可靠性并将影响最小化，常通过复制实现容错。复制策略因目标不同而异：是为防单机故障、数据中心故障，还是为负载均衡等。
在单一系统内，为防机器故障，可将同一数据的多个副本存放在不同机器（即副本）。若目标是防整体系统或数据中心故障，则需借助变更数据捕获（CDC）等技术复制到另一套系统。
数据分区能显著提升性能与可扩展性。常见的**scatter-gather（分散-聚合）**模式通过分区将数据分布到多节点处理，再聚合结果以高效地处理与服务数据。
数据分区是大多数分布式数据库的内建能力，无需特定外部技术；数据复制通常也由数据库提供，但若某些数据库不原生支持，则可采用 Oracle GoldenGate 等 CDC 技术实现。
热存储 vs. 冷存储
在海量数据场景下，存储成本会迅速攀升，而并非所有数据都需要即时、低时延访问。低频访问（冷）数据可转移到更低成本的存储，代价是访问更慢。
例如：为 BI 应用提供服务的数据仓库中，较旧且不再被频繁访问的数据可迁移至数据湖等更廉价层级。又如在 S3 中，不需频繁快速访问的数据可迁至 S3 Glacier，以更低成本换取更慢访问。
常见冷存储技术：
- S3 Glacier
- HDFS
数据缓存与低时延服务
数据缓存/低时延服务是在工业界极为常见的模式，用于实现亚毫秒级查询响应。此模式通过作为内存数据库的系统叠加在其他持久存储之上，或采用运行在Flash/NVMe 等超高速介质上的数据库来实现。
与其他模式不同，优秀的缓存方案与基础设施选型同样密切相关。一个关键挑战是DGM（Data Greater than Memory） ：企业级用例往往无法把全部数据装入内存，否则成本高昂，因此需要设计能在内存不足时仍稳定高效的方案。
常见技术：
- Redis、Couchbase：内存数据库
- Aerospoke（基于闪存）
- Amazon ElastiCache
数据搜索模式
数据搜索可分为文本搜索与语义搜索。文本搜索基于词组/单词/通配/模式匹配；语义搜索则尝试查找概念等价但文本上不易直接匹配的内容。
文本搜索依赖倒排索引（将检索词映射到出现该词的记录集合）；语义搜索依赖向量索引（对数据嵌入后的向量建立索引）。随着 LLM 的兴起，语义搜索因在 **RAG（检索增强生成）**中的应用而大受欢迎。
常见搜索技术：
- 文本搜索：Elasticsearch、OpenSearch、Lucene
- 语义搜索：Pinecone、Couchbase、Weaviate、FAIS
领域特定模式
数据工程中存在大量领域特定模式，如时序数据、边缘侧数据处理、**机器学习特征库（Feature Store）**等。它们各自有独特挑战：
- 边缘侧需应对不稳定网络（偏远地区），以及设备内存极其有限，常需 SQLite 等专用数据库。
- 特征库常需 ASOF join（按某时点获取特征），并非所有数据库原生支持，这对数据工程师提出更高的实现要求。
由于这类模式的技术栈高度依赖领域场景且较为小众，本章不做通用技术推荐；后续章节在具体讲解这些模式时会深入其技术选型。
杂项模式（Miscellaneous patterns）
“杂项”数据工程模式无法被严格归入某一单一类别（如数据摄取或数据存储）。与数据摄取、数据存储模式相比，它们更偏横切面，适用于大多数数据工程系统，涵盖让系统具备生产可用性的安全、可观测性与编排等模式。
数据安全模式
数据安全模式提供在数据全生命周期中进行防护的策略，确保机密性、完整性与可用性，涵盖加密、访问控制与安全传输。常见的是认证与授权模式。
-
认证（Authentication） ：可采用多种方式；传统的口令认证仍在使用，但为增强安全性，现代系统更常采用多因素认证（MFA） ——除用户名/口令外，再叠加一次性验证码（OTP）或生物特征等要素。
-
授权（Authorization） ：在识别用户身份后，控制其可在系统上执行的操作。最常见的是基于角色的访问控制（RBAC） ，根据用户被分配的角色及其权限来界定允许的活动。
-
数据加密：确保数据在传输中与静态存储时都受到保护。
- 传输中：最常用模式是 TLS，通过对称与非对称密码学的组合实现安全传输。
- 静态存储：常用AES（对称）与RSA（非对称）等算法。即使数据被意外访问，攻击者也难以利用。现代对象存储、数据库与数据湖等系统普遍支持静态加密。
数据可观测性与监控模式
要在生产环境中可靠运行数据系统并满足治理、安全与可靠性要求，可观测性与监控至关重要。这些模式为数据流水线提供端到端监控、异常检测与数据质量检查等能力，帮助前瞻性地发现与解决问题、跟踪数据血缘并保障数据完整性，从而提升运行效率、减少停机并支撑决策。
- 数据可观测性更关注数据质量、治理、血缘、访问。
- 数据监控更关注可靠性、性能、效率与成本。
常用技术：
- 可观测性/治理：Collibra、Alation、Apache Atlas（数据目录）；IBM DataStage、Oracle EDQ、Talend（数据质量）
- 监控：Datadog、Splunk、Prometheus（指标收集与监控）；Grafana（监控与看板）；PagerDuty、Slack（告警与通知）
幂等与去重模式
分布式数据操作天然易受网络中断、硬件故障、软件缺陷等影响，可能导致数据损坏或丢失。为确保数据完整与高质量，需引入幂等性。
- 恰好一次（Exactly Once Semantics, EOS） ：使用 Kafka 等消息系统可实现数据移动的幂等性。
- Checkpoint（检查点） ：通过在独立日志中记录操作完成状态以实现幂等重试。
- 按区间分片的加载作业：大规模数据装载通过**分区（如日期范围）**实现幂等，失败重跑仅需重处理相关分区。
随着组织从多源摄取海量数据，重复数据的概率显著上升，既会扭曲分析与决策，也浪费存储并推高成本。需采用去重模式识别与清除重复：
- 校验和（Checksum） ：为每条数据生成唯一校验值（如 SHA-256、MD5），在处理时与已有校验值比对以识别潜在重复。去重可节省存储/计算并避免重复处理提升性能。
常用技术：
- 幂等性：Kafka、AWS SQS 支持 EOS；Apache Kafka 支持检查点；MongoDB、Couchbase、Postgres 的 Upsert/Merge/主键可阻止重复插入。
- 去重：Apache Spark 的 SHA-256/SHA-512；Postgres、Oracle 等数据库的 MD5/SHA-256 函数。
数据编排模式
数据编排用于自动化、调度与管理复杂数据工作流，确保数据在各系统与处理阶段间顺畅流动。编排模式与本书中其他模式协同工作，构建端到端的数据管道——既是粘合剂，也是在生产中运行方案的框架。
常用技术：
- Apache Airflow：作业调度与编排
- Apache NiFi：可视化构建数据管道
- Terraform、Ansible：基础设施层的编排与管理
结论
本章概述了常见数据工程模式及其实现技术，并说明了通用术语的使用；同时展示了如何组合多种模式来设计一致的解决方案。我们简要覆盖了多类摄取与处理、存储与服务模式，为后续章节的深入铺垫。
在下一章，我们将详细讨论批处理的摄取与处理以及对应的行业用例，并给出若干代码示例来展示批处理模式的实现。
