构建 Medallion 架构——打地基在建房子之前，必须先打好坚实的地基。Medallion 架构亦然。本章作为预备性

在建房子之前，必须先打好坚实的地基。Medallion 架构亦然。本章作为预备性的桥段，引入我们在讨论 Medallion 架构时会反复出现的关键组件与模式，也为第 3 章的深入讲解（Medallion 架构及其各层）做好铺垫。

本章将覆盖以下核心领域：

额外的着陆区（Extra landing zones）
在数据进入 Medallion 架构之前，用于摄取原始数据的前置区域。

原始数据（Raw data）
来自各类来源、尚未处理的数据，是后续转换与分析的基础。

批处理（Batch processing）
按计划的时间间隔以批的方式收集、处理并输出数据的处理模式。

实时数据处理（Real-time data processing）
与批处理相对，数据一旦可用即刻处理，支持即时分析与决策。

ETL 与编排工具（ETL and orchestration tools）
负责抽取、转换、装载数据，并在数据生态中承担工作流编排与自动化的关键角色。

上述组件是否纳入 Medallion 架构图，因团队而异：有的从一开始就画在主体框架内，有的则放在图外或边缘，以强调其支撑性。

我们还将探讨 Delta 表的管理。跨越不同的 Medallion 层，如何有效管理这些表，对保持数据处理的完整性与效率至关重要。

在读完本章后，你应当对这些关键要素有扎实的基础认知，为后续更深入理解 Medallion 架构及其运行层面做好准备。

前置条件（Foundational Preconditions）

在设计与实现任何架构之前，你需要数据。因此，启动新架构的第一步，是识别目标源系统并确定最佳取数方式。由此引出一个关键挑战：是否需要使用中间着陆区来进行数据摄取，以便在数据进入 Medallion 架构之前获得更好的组织与转换。随后，你需要决定摄取方式——批处理还是实时处理？这将直接影响你在数据集成、编排与表管理上的工具与技术选型。

接下来的小节将按上述顺序展开，为你在第 3 章理解 Bronze、Silver、Gold 各层打下基础。我们先从“是否需要额外着陆区”谈起。

额外着陆区（Extra Landing Zones）

着陆区（landing zone）常被用作数据进入 Medallion 架构之前的前置摄取区域。是否采用，受到数据源特性的影响。

例如，面对外部服务或 SaaS 厂商时，你可能需要一个安全的着陆区，先临时存放数据，再迁入 Bronze 层。又如，某些对数据摄取有严格要求的应用团队会需要专属着陆区：他们自行管理抽取过程，确保没有异常或数据不一致；并可能要求特定的 ETL 工具或集成运行时。在这类场景下，源系统与湖仓架构之间往往存在多个着陆区。

相反，是否可以直接将数据摄入 Bronze 层？取决于源系统的条件。如果源系统具备完备的安全措施与稳定的直连摄取手段，绕过中间着陆区、直达 Bronze 可能更高效。这时无需先把数据停放在前置区域。可见，摄取方式会因数据源特性与数据团队诉求而显著不同。

着陆区要点（LANDING ZONES TAKEAWAY）
虽然 Bronze 主要承担数据汇集角色，但在更大或更复杂的环境中，你可能需要一个前置着陆区。是否把这层命名为 Bronze由你决定。有的组织称之为 “锡层（tin layer）” 、 “pre-Bronze” 、 “预清洗（pre-refinement）” 、 “暂存（staging）”或“落地区（landing area）” ，并将其画在典型 Medallion 架构之外；也有人把它并入 Bronze 的设计。关键在于：以满足组织功能与非功能需求的方式摄取与存放数据。

下面我们继续探讨更细致的差异：先谈原始数据的处理，再讨论不同的摄取方式。

原始数据（Raw Data）

当我们谈到以 “raw / as-is” 的方式将数据落到 Bronze 层时，需要保持谨慎。设想复杂的事务系统（如带有成千上万张表的商业套件）：在这类场景中，工程师往往需要在抽取阶段介入做调解（mediation） 。

以我作为架构师的亲历为例：我曾处理 Temenos T24（核心银行系统）的数据抽取。此系统把全部数据都以 XML 存储，每张表只有两列：主键 RECID 与数据 XMLRECORD。若直接抽取，得到的数据集会极其复杂且难以管理。为此，我们使用 T24 Data Extractor，先从 T24 数据库拉取并落成更可管理的结构。随后我们又迁移到 Apache Flink，对流动中的数据进行解码与处理，使得在数据从 T24 流向其他环境的过程中就能转换与丰富 XML 记录。

类似地，复杂的 ERP 系统拥有成千上万张专门且互相关联的表，直接抽取也很难。组织通常会使用抽取服务或利用这类商业套件提供的语义模型来完成抽取调解。

从这些例子能学到什么？调解很可能存在。技术系统表到摄取层的第一步，常常需要一个中间件或自研组件：它的职责是将复杂的系统表或专有数据结构映射为更简单、可管理的数据模型。

原始数据要点（RAW DATA TAKEAWAY）
针对复杂数据进行预处理或调解发生在数据抵达 第一层之前，这不被视作 Medallion 架构内部的“转换”。因此，尽管第一层的数据通常标记为“原始”，但在复杂系统场景下，适度的预处理对于可管理性与清晰度至关重要。

至此，我们已覆盖了起步阶段的关键点。接下来转向数据管理的另一个核心问题——选择批量还是实时摄取。理解二者差异，将进一步提升我们高效处理数据的能力。我们先从批处理开始，随后因实时与流式摄取更复杂，会进行更长的讨论。

批处理（Batch Processing）

批处理是一种在一段时间内收集数据，随后一次性处理的方式。它至今依然流行，主要有以下原因：其一，成本效益高——可以在单次操作中处理大批量数据，减少持续运行与常开组件的需求；其二，许多既有系统与基础设施对批处理有广泛支持；其三，批处理利于构建历史视角，因其会在一次运行中处理所有累积的数据。

在为 Bronze 层设置批量数据摄取时，需要注意以下要点：

数据完整性至关重要。 在传输过程中使用行数校验、校验和（checksum）或哈希合计（hash totals）等方法，确保数据准确与完整。同时记录审计信息，如文件数量、数据量、拷贝时长、任务运行 ID、执行结果，便于监控与排障。
批处理非连续，而是按固定间隔运行。选择间隔时，要权衡源数据可用性、处理顺序与分析时效性。
即使尽力设计，批处理仍可能失败。为提升 Bronze 层韧性，需要健壮的错误处置机制。可考虑建设一个“错误层”或“数据孤儿院（data orphanage） ”，专门监控与承接异常，充当安全网，确保整体数据管理平稳可靠。
工具选型对抽取与摄取至关重要。评估多种工具与方法，以确保无缝集成与处理。例如 Azure Data Factory 常用于数据抽取、工作流编排与管道管理，提供 200+ 连接器。合适的工具能显著提升数据收集的效率与可靠性。关于工具与选型，后文“ETL 与编排工具”会再呼应。

在进入现代摄取方式之前，需要承认：数据收集对许多组织仍是难题——源系统特性、格式与网络设计的多样性、技术与平台的差异，都会让一致、标准化的抽取变得不易。

批处理要点（BATCH PROCESSING TAKEAWAY）
数据收集的挑战并不新鲜：历史上，组织就为数据仓库收集数据。因此，许多团队会复用既有接口（如定制抽取脚本或传统批量投递）将数据导入湖仓。批处理看似直接，实则在企业级落地常很复杂，因为每个数据源往往都需要差异化对待。
随着组织演进，可能会考虑采用更当代的接口，例如实时数据摄取。这正是现代湖仓架构的强项：批与实时皆可高效管理。

实时数据处理（Real-Time Data Processing）

正如第 1 章所强调，现代湖仓架构对流式/实时数据支持良好。通过在数据生成即处理，可以立刻获得洞察并做出及时决策，典型应用包括欺诈检测、个性化交互与系统动态调优。这显著提升了应用的响应性与有效性，在快节奏业务中尤为关键。

要为系统建立实时摄取，通常需要新增组件或调整现有架构。原因在于多数应用并不会天然产生事件流；作为开发/工程人员，可能需要修改应用架构以支持事件分发。例如在 Node.js + Express 应用中，可能会引入库并编写代码，将事件发送到 Azure Event Hubs 等服务。

在某些场景，还需要增加能够读取事务数据库日志或调用 API 的组件。一旦建立了稳定的事件流，数据平台便可使用 Spark 等服务/框架捕获并处理这些数据。

WARNING
在数据流转中，务必区分携带状态的事件（state-carrying events）与简单通知（notifications） 。前者在某一时刻提供应用状态的快照，可用于处理、分析或触发后续事件，适合监控数据的变化与更新；后者则是提示“发生了什么”的轻量告警，通常不包含详细状态（如新邮件提醒或系统告警）。

技术供应商为实时/流式数据提供了多种路径——这既反映了问题的复杂性，也适应了丰富的集成选择。下面介绍撰稿时最常见的几种方式。我们先从 Spark Structured Streaming 讲起，它允许在数据流动中进行读取与转换；随后讨论 Change Data Feed 与 Change Data Capture（CDC） ，并给出若干注意事项与学习资源。

Spark Structured Streaming

在 Apache Spark 引擎中对 Structured Streaming 的强力支持，大幅提升了实时处理能力。作为 Spark 的组成部分，它可持续处理数据流，支持从事件日志文件、物联网设备、Apache Kafka 等实时消息系统摄取数据；同时也擅长处理原始/非结构化数据，这在实时场景中很常见。

在此阶段，转换至关重要：需要把原始数据转为更可用的格式。对非结构化数据，这些步骤可能包括展开嵌套 JSON、从 XML 提取字段，或应用复杂函数派生新列。这些操作为下游分析与存储清洗与准备数据，确保其可被高效处理与分析。

完成转换后，Structured Streaming 支持多种输出：将处理好的数据写入持久化存储以便进一步分析或后续使用。目的地取决于应用需求，既可以是 Delta Lake（提供 ACID 与版本管理）、也可以是传统关系库、NoSQL 数据库，甚至直接回写到消息总线/事件队列支持进一步处理或实时分析。

NOTE
使用 Spark 进行实时摄取通常需要一个“常开（always on） ”的计算集群，成本可能更高。若对时延要求不苛，可考虑定期触发（如每 5 分钟）执行这些工作负载以降低费用。

Structured Streaming 与 Spark 生态其他组件（如 MLlib）的整合，还能构建复杂的实时分析管道，帮助组织从数据中即时提炼洞察，支持被动响应与主动决策。总之，对 Structured Streaming 的支持，是希望利用实时处理能力的组织的一项强大武器。

Change Data Feed（变更数据馈送）

在流处理语境下，另一值得讨论的模式是 Change Data Feed。它允许捕获 Delta 表的变更，使你能够**（近）实时**处理这些变化。

启用方式：在 Delta 表上设置属性 delta.enableChangeDataFeed=true，例如：

ALTER TABLE myDeltaTable
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

CDF 可作为 Spark Structured Streaming 的输入源。二者结合能强力支持实时处理：例如在一次初始 MERGE 对比之后，仅处理后续增量变化，加速并简化 ETL/ELT。同样的模式也能把增量变化下游推送到 Kafka 或 RDBMS，供后续环节继续利用。

关于 Delta 与 Structured Streaming 的集成实践，可参考 Delta Lake 文档“Table Streaming Reads and Writes”。

Change Data Capture（CDC，变更数据捕获）

CDC 是用于识别并捕获数据实时变化的技术。CDC 工具会主动监控数据库修改并记录这些变更，从而实现将数据复制到其他系统。该方法特别适合对源系统进行实时捕获，以便将变化无缝引入数据平台。第 5 章将更详细讨论 CDC。这里先以注意事项与学习资源作为实时处理部分的收尾。

注意事项与学习资源（Considerations and Learning Resources）

Spark Structured Streaming、Change Data Feed 与 CDC 是构建强大实时集成与分析管道的核心组件。下表给出三者的概览对比：

表 2-1　实时数据处理选项概览

选项	描述
Spark Structured Streaming	支持复杂操作并集成多种来源与落地；面向连续数据处理。
Change Data Feed	实时捕获 Delta 表变更；仅流转增量/差异，提高处理效率。
CDC	有效追踪数据库事务日志中的变化，实现实时复制与集成。

在讨论实时复制、流处理与 Bronze 层设计时，还需把握一些细节。例如可利用 Microsoft Fabric 的镜像（mirroring）功能，把云原生 Azure SQL 应用中的数据近实时复制到湖仓。此技术利用数据库的 CDC，将其转换为合适的 Delta 表并落地到湖仓（OneLake）。这些数据是否应归入 Bronze 层，取决于你的具体需求：

若你的目标是叠加全量导出，则近实时复制的数据更适合作为中间（或着陆）区域的一部分。这样可直接查询（近似源系统效果）且不影响源应用，但不利于将 Bronze 层组织为历史原始副本的积累区。此时，首层更像复制/预 Bronze 层。
若你的目标是维护一个可查询、且**“原样（as-is）”镜像源数据的 Bronze，那么实时复制的数据可视为 Bronze 的一部分。最终分类取决于你的用途与策略**。

实时与流式摄取要点（REAL-TIME DATA AND STREAMING INGESTION TAKEAWAY）
是否实施实时摄取/复制，以及这些数据应归入 Bronze 还是中间区域，本质上由使用需求与战略目标决定。
还需理解：在实时摄取中，多个层往往会同时更新。例如，你可用 Structured Streaming 直接处理来自 Azure Event Hubs 的流，并在处理时即时进行去列、聚合、初步情感分析等转换——把原始数据落到 Bronze，同时将清洗后的结果立即写入 Silver，甚至 Gold。此时 Bronze 更像归档区，而非主要读取层。这种并行处理方式对实时分析与洞察尤其有用，使你能更快访问并分析新到数据。

关于流式处理的系统性论述，可参见 Delta Lake: The Definitive Guide；另可参考“Structured Spark Streaming with Delta Lake: A Comprehensive Guide”。这些资源提供了在 Delta Lake 框架下实现流处理的详解与示例，有助于强化你在实时数据管理上的能力。

无论处理批量还是流式数据，摄取管理本身都是一门复杂学问，亟需清晰指引。选择合适的方法对高效数据处理至关重要；而要让这些方法成功落地，正确的工具必不可少，因为它们直接影响摄取流程的效率与效果。

ETL 与编排工具（ETL and Orchestration Tools）

讨论**抽取（Extract）—转换（Transform）—装载（Load）及编排（orchestration）**相关工具至关重要，因为它们会显著影响数据流水线的设计。第 5 章会给出示例；在此先了解一些常用工具及其在数据架构中的差异化特性：

Apache Airflow
开源平台，可以编程方式编写、调度与监控工作流；特别适合编排复杂数据管道与管理任务依赖。第 6 章将进一步讨论 Airflow。

Azure Data Factory（ADF）
在采用 Synapse Analytics、Azure Databricks 与 Microsoft Fabric 的组织中广泛使用。擅长创建、调度与编排数据工作流。在 Microsoft Fabric 中，ADF 简称 Data Factory，功能大体一致。其一大优势是大量连接器，便于从多种来源抽取数据。

Databricks Auto Loader
面向 Databricks 生态设计，长于增量处理到达云对象存储的新文件；其亮点之一是对**模式演进（schema evolution）**的处理。第 5 章会进一步介绍。

Databricks LakeFlow Connect
Databricks 的专用服务，内置连接器（如 Salesforce、SQL Server），用于便捷的数据摄取。

Databricks Workflows
Databricks 提供的托管编排服务，可定义、管理与监控多任务工作流，覆盖 ETL、分析与机器学习管道。

为追求更广泛兼容性与功能集，第三方工具（如 Fivetran、Qlik、StreamSets、Syncsort、Informatica、Stitch）也很流行。它们提供丰富连接器与编排能力，常与其他工具配合使用以增强整体功能。

在设计 Medallion 架构时，必须评估所选 ETL 工具的能力与限制。某些工具支持的装载步骤更复杂，可能要求你在架构中增加更多预处理。因此，ETL 工具的选择不仅会影响首层设计，也可能左右整体架构。务必谨慎权衡，以确保数据架构满足组织的功能/非功能需求。

假设你已用摄取工具顺利获取数据，接下来应把焦点转向表的管理。

管理 Delta 表（Managing Delta Tables）

表管理在各层都至关重要，因为它影响性能、可用性与成本。诸如 *-ordering 与 liquid clustering 等技术可优化数据布局，使检索更高效。下面依次介绍 Z-ordering 与 V-ordering，随后讨论分区，最后讨论liquid clustering、表压缩（compaction）与优化写入以及 DeltaLog。

Z-Ordering

Z-ordering 通过把相关数据聚集到同一批文件中来提升检索效率：改善数据局部性、减少 I/O、支持多维度数据管理；在许多场景下可比常规检索快 2–4 倍，对需要高效过滤与 JOIN 的查询尤为有利。尽管在一些场景中已由融合 Z-order 与分区优势的 liquid clustering 取代，但是否仍适用取决于你的部署。

实践中，Delta Lake 会通过**数据跳读（data skipping）**算法自动受益。你也可显式用 ZORDER BY 指定列，使数据按需组织以加快访问。例如：

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType);

该方法显著减少扫描数据量，提升整体性能。需要注意，Z-ordering 对超大表（数百 GB、TB 或更大）最有价值。

V-Ordering

V-ordering 也是优化检索的技术，不同于 Z-order，它是Parquet 写入时的优化。本质上，V-order 按 Power BI 的 VertiPaq 引擎所用的存储算法逻辑组织数据，从而在 Microsoft Fabric 的计算引擎（如 Power BI、Warehouse）下拥有更快读取。V-order 100% 兼容开源 Parquet 格式，所有 Spark 引擎都可作为普通 Parquet 读取。

根据 Microsoft 关于 Delta Lake 表优化与 V-order 的文档，V-order 的性能收益取决于引擎与场景：平均可提升约 10% 的读性能，部分场景可达 50% 。可通过 Delta 表属性启用，例如：

CREATE TABLE person (id INT, name STRING, age INT)
USING parquet
TBLPROPERTIES ("delta.parquet.vorder.enabled" = "true");

需要承认：V-order 的优化是有成本的。排序会使平均写入时长增加约 15% 。¹ 如有需要可关闭此特性。写入变慢的原因是写过程增加了排序步骤；当写入量大而读取较少时，这会成为顾虑。

为获得最佳收益，应将 V-order 与架构层次或特定用例对齐（如 SQL 端点使用非常频繁的场景），以判断其收益是否胜过潜在的写入开销。

接下来，我们转向另一种提升性能的模式——表分区。

表分区（Table Partitioning）

表分区对管理超大数据集（数百 GB 至多 TB）很有效：将大表划分为更小的片段，在查询时减少必要读取的数据量，从而显著提升查询性能。在 Delta Lake 中，可按某列进行分区。常见选择是日期，但也可按查询中高频过滤的列（如国家）分区。创建分区示例：

CREATE TABLE events
USING DELTA
PARTITIONED BY (date);

分区与 Z-ordering 在大表上最有效；两者可以组合，但需注意：Z-order 的聚簇仅在分区内发生，且同一字段不能同时用于分区与 Z-order。

Liquid Clustering

在实践中，要把 Z-order 与分区调到最优并不容易：它们要求固定的数据布局，需要充分的前期规划。为缓解这些挑战，Delta Lake 在 2024 年中引入了 liquid clustering，意在取代传统的 Z-order 与分区。

Liquid clustering 通过聚簇键动态调整数据布局，区别于 Hive 风格分区的静态布局。这种“液态”布局会随着查询模式演变而变化，解决分区不佳与列基数等问题。你可以对列进行增量优化与重聚簇，而无需重写全部数据。更多细节可参考 Delta Lake 官方文档中的 liquid clustering。

压缩与优化写入（Compaction and Optimized Writes）

Delta Lake 提供 OPTIMIZE 操作，针对我们在“HDFS”部分讨论过的小文件问题。当你更新/删除/新增数据时，Delta 会产出大量小文件；积累过多会拖慢查询。可运行 optimize 任务将小文件压缩为更大、更易管理的文件，提高性能。语句如下：

OPTIMIZE delta_table_name;

另一种提速方式是优化写入（optimized writes） 。该特性默认关闭，但在 Delta Lake 3.1+ 可开启：将表属性 delta.autoOptimize.optimizeWrite 设为 true。启用后，Delta 会在写入时自动优化数据文件布局，提升查询性能。² 详见 Delta Lake 文档。

现在我们已介绍了多种表优化技术，接下来将转向事务日志（transaction log） ，它在保障数据完整性与实现数据恢复方面扮演关键角色。

DeltaLog

Delta 事务日志（Delta transaction log） ，亦称 DeltaLog，是 Delta Lake 的关键特性，在 Medallion 架构的所有层中都会频繁用到。如第 1 章所述，DeltaLog 会精确记录对某张 Delta 表所做的每一次变更，包括新增、ALTER 语句、OPTIMIZE 作业、修改与删除等。该日志以完整的表历史为核心，存放在该 Delta 表目录下的 _delta_log 子目录里，由一系列 JSON 文件构成。

每次事务都会生成一个新的日志文件，详细记录已执行的动作、新增文件、移除文件以及与事务有关的其他信息。默认情况下，这些日志文件的保留阈值为 7 天。你可以通过 ALTER TABLE ... SET TBLPROPERTIES 修改该设置，从而更灵活地控制日志的保留时长。此能力强化了数据管理的稳健性，并在需要时提升审计与回滚的可达性。

NOTE
VACUUM 语句会清理表目录：删除 非 Delta 管理的文件，以及不属于该表最新事务状态且早于保留阈值的数据文件。这样既能维持高效、精简的存储环境，也有助于节省成本并满足合规要求。

在 Medallion 架构中，DeltaLog 是一项重要的安全保障。一旦出现错误或数据完整性受损，尤其在 Silver/Gold 层，你可以快速回退到该 Delta 表的先前版本。借助 RESTORE 命令，你可以按时间或版本号访问表的早期版本。这一特性支持诸如数据审计、回滚、以及实验/报表复现等关键场景。

需要注意的是，DeltaLog 的主要用途在于数据恢复与审计，而非充当传统意义上的历史数据库。例如，如果你想找出“过去一个月发生变更的记录”，仅靠事务日志往往需要大量处理（需要读取并比较所有文件）。更高效的做法是在表内直接管理历史，例如使用**缓慢变化维（SCD）**等方法。这样不仅性能更优，也有助于长期维护数据完整性。我们将在“缓慢变化维”部分再回到这一话题。

TABLE MANAGEMENT TAKEAWAY（表管理要点）
为获得最佳的数据管理性能，应将 V-ordering、liquid clustering 等 *-ordering 技术与架构各层对齐，关注每层的查询与访问模式，以确保高效的查询与检索。同时，应为 Delta 表设置合理的保留阈值：在运行需要与数据恢复之间取得平衡，既保证数据新鲜度，也控制存储成本。

通过对多种摄取与表管理模式的角色与注意事项的系统理解，我们已经具备为 Medallion 架构做出结构与方法选择的基础。下面让我们总结关键洞见，并思考它们如何影响我们在架构旅程中的下一步。

结语（Conclusion）

为 Medallion 架构打好基础是一个细致的过程，始于对前置条件的全面理解：识别源系统、明确导出与摄取的最优路径。每个源系统可能都需要定制化的抽取与装载方式，这提醒我们切勿低估这一基础阶段。在此阶段，应与源系统的所有者深入协作与规划，以便就是否进行调解（mediation） 、是否引入额外着陆区、是否采用集成运行时组件、以及在批处理与实时之间如何取舍等问题做出明智决定。这些选择各有细节与权衡，并会显著影响数据收集的工作量。

此外，ETL 与编排工具的选型至关重要：它不仅可能决定首层的设计，也会影响整体架构。需要谨慎评估与标准化，确保所选工具既满足当前需求，又与组织的更广泛要求一致。在工具与服务层面，标准化是高效开展治理、元数据管理、血缘采集、一致的数据质量报告等工作的关键；这一决策也将影响架构的灵活性与可扩展性。

同时，表管理与数据建模紧密相关、且对性能优化至关重要。要在设计早期就考虑有效的表管理策略，确保架构能高效承载预期的数据负载。

至此，我们已为构建 Medallion 架构奠定了基石。在第 3 章，我们将更深入到各层的细节：讨论其设计要点、实践考量与成熟的最佳实践。