什么是勋章架构？详解铜、银、金三层

勋章架构 vs. 传统 ETL 流水线

在采用传统抽取-转换-加载（ETL）流水线的数据仓库中，您必须预先定义数据的模式。如果数据格式或模式发生变化，除非您手动调整，否则系统将失败。

在基于勋章的抽取-加载-转换（ELT）架构中，您会先将数据以原始形式保存，而不是在飞行中转换并只存储最终数据。这个差异使基于勋章的架构既稳健又灵活：您可以按原样保存原始数据，并在之后决定如何使用它。

若需两者的完整对比，建议阅读我们的ETL 与 ELT 指南。

勋章架构的另一个优势是其与平台无关的特性。铜、银、金是逻辑阶段，而非绑定于某个厂商的技术。您可以根据数据平台和工作负载需求，使用不同的存储系统、处理引擎和表格式来实现这一模式。

勋章架构中的铜、银、金三层如何工作？

这三层按逻辑顺序衔接，每一层都构建在前一层之上。

铜层：原始数据的恢复点

这是原始数据按其本来面貌落地的位置，无论它来自关系型数据库、诸如 Salesforce 的 SaaS 应用、承载实时事件的 Kafka 主题、REST API、CSV 导出，还是物联网设备流。摄取通常由工具处理，例如用于变更数据捕获的 Fivetran，或用于对象存储落文件的 Databricks Auto Loader。

铜层数据通常包含相当多的错误、不一致和重复，因此绝不应直接用于业务场景。尽管如此，该分层作为一个恢复点具有很高价值，您可以据此再生银层或金层数据。

该分层的重要性在于其留痕：它记录并日志化每一次摄取事件或事务。它往往包含有价值的元数据，如摄取时间戳、数据来源及各类标识符。目标是在尽可能原始且完整的前提下存储数据，以便重放下游流水线，使用相同的源数据来调试任何问题。

银层：契约分层

银层将原始数据转换为干净、结构化的数据。以下是铜层与银层之间进行的一些重要清洗转换示例：

• 筛除不必要的列
• 记录去重
• 修复不一致问题
• 处理缺失值
• 数据标准化
• 连接与合并各类数据集

此分层还包含模式强制，确保数据符合预定义结构并支持模式演进。

您也会在这里执行数据质量检查。例如，添加规则以标记或拒绝失败的业务交易或异常值。随着数据通过各阶段，这里是提升数据质量的第一步。

由于此阶段涉及数据修改，使用数据血缘工具（如dbt）来追踪数据如何从铜层转化到银层就显得尤为重要。质量检查通常通过 dbt tests、Great Expectations 或 Soda 实施，而治理则通过数据目录（如Databricks Unity Catalog或 Collibra）来强制执行。

如果您想学习如何将凌乱数据转化为合格的银层数据集，建议从我们的Cleaning Data in Python课程开始。

金层：面向业务的产出

该架构的最终分层存储质量最高的数据。这些高度精炼的数据用于在Power BI、Tableau 或 Looker 中进行业务报告，被下游分析应用消费，或通过如 Feast 或 Databricks Feature Store 等特征库提供给机器学习模型。

由于数据已完成清洗，此阶段的重点在于将其转化为有价值的业务资产。根据具体使用场景（如财务报表、营销仪表板、告警系统、机器学习模型训练等），银层之后的转换确保金层准确包含手头任务所需的信息。

在这里，您会创建KPI，应用自定义业务公式，或将数据聚合为每周、每月或每季度粒度以满足定期报告。铜层与银层的操作往往较为通用，而金层操作更灵活，并根据您的具体使用方式而定制。

如何从铜层数据重建银层和金层？

只有当您确实能使用铜层中保留的原始数据时，保留它才有意义，这通常发生在上游或下游发生变化时。变更的代价取决于它在链路中的位置。

• 源模式发生变化意味着需要将铜层重放处理至银层和金层。
• 业务定义的变化（例如新增收入规则或调整聚合窗口）只需从已验证的银层重建金层。

无论哪种情况，您都不必回到源系统。这正是历史更正之所以可行的原因，因为源系统可能不再以您最初摄取的形式保存这些数据。

这也意味着您可以在不重跑摄取的情况下更改指标定义，这正是拥有众多金层消费者的团队保持分层独立的现实原因。

勋章架构在数据湖仓中的定位

一个数据湖仓既提供数据湖的廉价对象存储，又具备数据仓库的事务性保障。它并不规定内部表应如何组织。这正是勋章所填补的空白：湖仓是存储基底，而铜、银、金则是您将其划分为具有不同质量保证的目录、模式和表的方式。

在实践中，这种划分通常是物理的。在Databricks上，您可能会在一个 Unity Catalog 的目录中设置三个模式；在Microsoft Fabric中，可能是一个湖仓包含铜、银表，再为金层提供数据仓库。相同的模式，不同的管道与连接。

开放表格式是支撑分层在并发读写下成立的关键。Delta Lake、Apache Iceberg 和 Apache Hudi 各自提供了如下某些能力：

• ACID 事务
• 模式演进
• 版本化的表状态
• 并发控制
• 分区演进
• 时光回溯

版本化对于我们刚才讨论的重放行为尤为重要。原始 Parquet 文件当然能很好地保留您的源数据，但它们不提供可回滚的事务历史，因此一次不良的银层运行会覆盖掉好的结果，且您无从对比。Delta Lake 通过事务日志来跟踪变更，而 Apache Iceberg则将表状态表示为快照。

这些都非强制。勋章是一种逻辑模式，许多团队在 Postgres 模式或纯 S3 前缀上配合 dbt 来运行它。只是您会失去廉价回滚的能力。

勋章架构 vs 数据网格

两者经常被比较，通常是因为人们以为它们存在竞争关系。它们回答的是不同的问题：数据网格决定谁拥有哪些数据，而勋章架构决定该所有者如何对其进行精炼。

数据网格将数据责任交给销售、财务或供应链等域团队，他们将数据作为产品发布，并对其质量、可发现性、血缘和治理负责。支撑这一切的两大要素是：为每个域提供相同工具的自助式基础设施，以及在不剥夺域所有权的前提下设定全组织标准的联合治理。

勋章架构则是域团队在自己地盘内运行的方式。比如，负责运输数据的供应链团队会在铜层保留原始运输事件，在银层存放已验证记录，并在金层发布可用于分析的运输数据集，供其他域消费。网格在金层边界定义契约；其上游的一切由该团队自行决定。

在将两者结合之前有一点需要注意：按域划分的铜层意味着每个域都要承担自己的摄取与存储成本，而且像客户或产品这样的共享维度往往会在三个地方被重复构建。网格的拥护者会说这是所有权的代价。这依然是真实成本，值得在承诺之前核算清楚。

勋章架构的优点与局限

勋章带来复用与可恢复性，代价是存储、时延与流水线数量。是否值得，几乎完全取决于您有多少数据消费者。

时延这一点最容易被低估。每一层通常都是单独的定时作业，因此一个按小时运行的三层批处理流水线，可能会让金层比源系统滞后两小时。对于每周收入报告这没问题，但对运营告警就不行，这也是团队常让告警直接读取银层而非等待金层的原因。

人们最先提的成本是存储，但这通常并非最大问题。铜层位于廉价的对象存储中，虽有重复但范围可控。真正棘手的是流水线数量：20 个源表乘以 3 个分层，就有 60 个可能在凌晨 3 点出故障的点。

与此相对，糟糕的数据质量也自有其代价。IBM 在 2026 年报告称，43% 的首席运营官将数据质量列为其最重要的数据优先事项，这一结论基于其 2025 年度商业价值研究院的研究。该研究中超过四分之一的组织报告称，因数据质量不佳导致的年度损失超过 500 万美元。

因此问题不在于实施勋章架构是否比单条流水线更贵——答案是肯定的。而在于您是否已经在对账会议和无人信任的仪表板上为另一种做法付出了代价。

何时应使用勋章架构？

当同一份清洗过的数据服务于多个消费者时，勋章才能发挥其价值。这比数据量、团队规模或数据源数量更能预测其收益。

在以下情况下使用勋章架构：

• 多个团队或工作负载读取相同数据。在银层完成一次性清洗与标准化，然后在其之上构建所需数量的金层数据集，用于 BI、报告或模型训练。
• 不同业务问题需要相同数据的不同形态。财务想要月度确认收入，销售想要按销售代表的日度订购量。二者都可源自同一张银层表，而无需重复摄取逻辑。
• 您的各源系统彼此不一致。银层是您在 Salesforce 的账户 ID 与计费系统的客户 ID 之间进行对账的地方，下游使用者无需再猜哪个更权威。
• 您需要对某个数字负责。将原始、已验证与已策划的数据分离，意味着您可以沿每一步转换回溯有争议的数字，而不必从头重新推导。
• 转换逻辑经常变更。如上所述，保留的铜层数据使您无需回到源系统即可重建。

在以下情况下可略过：

• 您的数据团队较小且流水线复杂度有限。
• 数据来自单一来源，几乎无需清洗或转换。
• 仅有一个下游应用或团队消费数据。
• 报告需求简单明了，不值得维护多个处理分层。

当两层就足够

三层图是默认选项，而非硬性要求。对于单一业务用例，铜层加一个合并分层往往是正确选择：保留原始数据以便重放，然后在一步中完成清洗与业务逻辑。

请选择匹配您消费者需求的形态。您不应合并的是铜层，因为这是无法重建的分层。

因此，如果您正处于中间状态且确实拿不准，那么先构建两层，并在出现第二个消费者时再添加第三层，是一种不错的做法。后加金层远比在连续六个月覆盖原始数据后再补建铜层要便宜得多。

实施勋章架构的常见错误

大多数勋章问题并非架构性问题。而是在期限压力下做出的小妥协，悄悄地移除了您最初建立分层的理由。

在铜层进行数据转换

重放的论证完全建立在铜层保存了接近源系统实际发送内容的基础上。若在落地前应用业务逻辑，您就失去了原始状态，这意味着无法重处理，也没有审计轨迹。

这通常出于好理由。有人为省空间删除了“没人用”的列，或在摄取时强制转换了一个混乱的时间戳字段，因为它会导致下一个作业出错。六个月后，被认为“没人用”的列变得重要了，而原始值已不复存在。尽量让铜层尽可能贴近源头，把修复放在银层。

模糊银层与金层边界

银层负责清洗和标准化；金层回答业务问题。当度量逻辑渗入银层时，每个金层数据集都会继承一个并非自己所需的定义，您又回到了勋章本应解决的问题。

检验很简单：如果业务用户会对这个数字提出争议，那它就属于金层。去重是银层关切；“什么算活跃客户”不是。

将三层视为强制要求

勋章架构是一种逻辑设计模式，而不是要求每条流水线都必须包含严格三层的硬性规定。铜、银、金代表数据精炼的逻辑阶段，每一层都可以根据工作负载以不同方式实现。

例如，某一层可以使用物化表、视图或其他合适的抽象，而不必为数据创建单独的物理副本。关键在于当数据从原始状态走向业务可信与可用时，建立有意义的边界，而非机械复刻经典的三层图。

将金层当作“堆放场”

这是我最常见却最少被讨论的问题。金层数据集创建成本很低，且几乎没人会删除它们，于是一年后，您可能会有四十张表，其中十一张是月度收入的不同变体，而没人记得 CFO 实际看的是哪一张。

银层具备天然的纪律性，因为其职责明确。金层没有，因此每个数据集都需要明确的所有者，并且要有删除的决心。否则，您最终会得到同一指标的多个竞争版本，而这正是分层试图避免的问题之一。

结语

勋章真正带给您的，是当有人问某个数字从何而来时，您能指出的位置；以及当答案被证明有误时，您能回溯到的一份原始数据副本。当有多个团队读取相同数据时，这些额外的存储与作业就是值得的。若只有一个团队使用，两层或许更合适，也能为您节省维护成本。

如果您想了解该模式所处的更广泛背景，我们的Understanding Modern Data Architecture课程涵盖现代数据栈背后的平台与技术。我们的Data Engineer职业路径进一步深入生产流水线的构建与维护。