【数据管理架构】Medallion架构：管理铜区、银区和金区的最佳实践

我的许多客户使用Medallion结构在Lakehouse中对数据进行逻辑排列。它们通过不同的阶段或层来处理传入的数据。如下图所示，最受认可的布局包含青铜、白银和黄金层，因此使用了“奖章架构”一词。

尽管三层设计是常见和众所周知的，但我目睹了许多关于每一层的范围、目的和最佳实践的讨论。我还观察到，理论和实践之间存在着巨大的差异。因此，让我分享一下我个人对如何实现数据架构分层的思考。

数据平台战略

分层架构的第一个也是最重要的考虑因素是确定如何使用数据平台。集中式和共享数据平台的结构预计与许多域使用的联邦多平台结构截然不同。分层也会根据您是将平台与体系结构的源系统端还是消费端对齐而有所不同。考虑到消费端更多样的数据使用特征，与源系统相关的平台在分层和结构方面通常比与消费者相关的平台更容易标准化。

考虑到这些因素，让我们在每一层之后探索每一层。对于每一层，我首先提供一些抽象和高级的目标。之后，我将通过实地观察使分层更加具体。

着陆区

着陆区或着陆区是一个可选级别，通常由建立数据平台的组织实施。它是从各种来源收集的数据在传输到青铜层之前的临时存储位置。当从目标源系统提取数据具有挑战性时，例如在处理外部客户端或SaaS供应商时，这一层变得尤为必要。在这些情况下，可能存在依赖性，或者数据可能以不合适的文件格式或结构接收。

着陆区的设计可能因组织而异。它通常是一个简单的Blob存储帐户，但在某些情况下，它被集成到数据湖服务中，例如发生数据摄取的容器、存储桶或特定文件夹。着陆区中的数据通常非常多样化，文件格式包括CSV、JSON、XML、Parquet、Delta等。

青铜层

青铜层通常是一个以自然和原始状态存储数据的储层。它包含未经验证的数据（无需首先定义模式）。在该层中，您可以使用全负载或增量负载来获取数据。存储在青铜中的数据通常具有以下特征：

• 按原样维护结构中数据源的原始状态。
• 数据是不可变的（只读）。
• 使用间隔分区表进行管理，例如，使用YYYYMMDD或datetime文件夹结构。
• 以有效的存储格式（例如Parquet或Delta）保留每个数据集的完整（未处理）历史记录。
• 对于事务性数据：可以增量附加并随时间增长。
• 提供重新创建给定数据系统的任何状态的能力。
• 可以是流式处理和批处理事务的任意组合。
• 可能包括额外的元数据，如架构信息、源文件名或记录数据处理的时间。

我遇到的一个常见问题是，“哪种文件格式更高级？我应该选择Delta还是Parquet？”虽然Delta提供了更快的速度，但如果您的数据已经使用文件夹结构进行了版本控制或历史记录，那么它的好处就不那么明显了。因此，维护事务日志或应用版本控制并不重要。青铜数据通常是新的或附加的数据。因此，选择Parquet是完全可以接受的。但是，您也可以选择“增量”以与其他图层保持一致。

一些人认为，Bronze数据对进行查询或特别分析的业务用户是有益的。然而，根据我与客户的经验，很少有原始数据被用作这些任务的输入。原始数据很难处理，因为它需要深入了解源系统的设计。您还需要破解数据中嵌入的复杂业务逻辑。由于经常出现许多小桌子，几乎不可能确保安全。总之，Bronze充当了一个暂存层和其他层的来源，主要由技术帐户访问。

银层

银层在已经摄入的数据上提供了一个精细的结构。它代表了我们数据的一个经过验证、丰富的版本，可用于下游工作负载，包括操作和分析。除此之外，银可能具有以下特性：

• 使用数据质量规则验证和处理数据。
• 通常只包含功能数据。因此，Bronze的技术数据或无关数据会被过滤掉。
• 历史化通常通过合并所有数据来应用。使用缓慢变化的维度（SCD）（类型2或类型4）处理数据。这意味着将添加其他列，如开始列、结束列和当前列。
• 数据以高效的存储格式存储；优选德尔塔或Parquet。
• 使用版本控制来回滚处理错误。
• 处理丢失的数据，标准化干净或空字段。
• 数据通常用参考数据和/或主数据来丰富。
• 某些主题领域的数据往往杂乱无章。
• 数据通常仍然是源系统对齐和组织的。因此，它还没有与其他领域数据集成。

对于Silver，有几个注意事项：

某些人提出，Silver可以作为临时存储层，删除过时的数据或自发创建存储帐户。客户经常询问我是否认同这种观点。好吧，这取决于情况。如果您不打算在原始环境中使用数据进行运营报告或运营分析，那么Silver可以是一个临时层。然而，如果您的目标是保存历史数据并使用Silver进行运营报告和分析，那么我建议将Silver作为一个永久层。

如果您正在处理需要查询的Silver数据，建议使用非规范化的数据模型。这种方法消除了广泛联接的必要性，并更好地与分布式基于列的存储体系结构保持一致。这是否意味着您应该放弃第三种正常形式或Data Vault样式的数据模型？这样做似乎没有充分的理由。关于历史化，delta文件格式已经为Parquet文件提供了隔离和安全版本。此外，您的青铜层中有一个历史记录，您可以从中重新加载数据。为了实现自动化和适应性，建议使用元数据驱动的策略来管理表和笔记本电脑。至于数据冗余（多次存储相同的数据），与计算处理和数据连接相比，存储在湖中的成本更低。总之，除非您每天都在处理重大的模式更改，否则似乎没有充分的理由增加数据保管库的复杂性。为了进一步探讨这个主题，Simon Whiteley的视频提供了许多考虑因素，强烈推荐。

我经常讨论是否应该已经在应用程序和源系统之间集成数据。这个问题稍微复杂一些。我的建议是，如果可能的话，将事情分开，以便于管理和隔离问题。这表明，对于使用Silver进行运营报告或分析的情况，建议不要过早地合并和集成来自源系统的数据。这样做可能会导致应用程序之间出现不必要的连接点。例如，只对来自单一来源的数据感兴趣的用户也将链接到其他系统，因为数据在提供之前首先在统一的层中进行组合。因此，这些数据用户更有可能受到其他系统的潜在影响。如果您正在努力实现这样一个独立的设计，那么来自不同来源的数据的集成或组合应该转移到黄金层。

上述推理同样适用于将湖屋与建筑的源系统侧对齐。如果您有意构建数据产品，并坚持保持数据所有权一致，那么我建议您的工程师不要过早地交叉连接其他领域应用程序的数据。

在考虑富集度时，例如计算，需要考虑某些因素。如果您的目标是启用运营报告，并且这需要丰富，我建议您开始在银层中丰富您的数据。这可能会在稍后的黄金阶段合并数据时导致一些额外的校准。虽然这可能需要额外的努力，但它提供的灵活性使其成为一项值得的努力。

金层

在Lakehouse架构中，黄金层存储在“特定项目”数据库中结构化的数据，使其易于使用。来自各种来源的数据的这种集成可能会导致数据所有权的转变。至于黄金层，我建议根据您的具体用例，使用较少联接的非规范化和读取优化的数据模型，例如Kimball风格的星形模式。除此之外，预计金层具有以下特性：

• 黄金表表示已经为消费或用例转换的数据。
• 数据以有效的存储格式存储，最好是德尔塔格式。
• Gold使用版本控制来回滚处理错误。
• 历史化仅适用于一组用例或消费者。因此，黄金可以是白银中数据的选择或聚合。
• 在Gold中，您可以应用复杂的业务规则。因此，它使用了许多后处理活动、计算、富集、特定于用例的优化等。
• 数据具有高度的管理性和良好的文档记录。

黄金往往是最复杂的一层，因为它的设计取决于您的架构的广度。在最基本的设置中，Lakehouses仅与源系统侧保持一致。在这种情况下，黄金层中的数据代表“数据产品”数据，使其通用且用户友好，适合广泛分发到许多其他领域。在这次分发之后，预计数据将被存放在另一个平台上，可能是另一个Lakehouse。

如果发生这种情况，预计这些平台中的黄金层将符合分析消费者的确切需求。因此，数据被建模，具有专门针对正在进行的用例而定制的形状和结构。这种方法可以促进一些原则，即只允许域在不直接分配给其他域的内部数据上运行。因此，一些表可能是灵活的，可以在任何给定的时间进行调整，而其他具有正式状态的表则由其他实体使用。在上图中可以看到这种设计的反映。

如果您的Lakehouse的范围很广，同时包括提供商和消费者，请考虑其他层。这些额外的层通常被称为工作空间层或表示层。在这种配置中，Gold中的数据更加通用，可以集成并为各种用例做好准备。然后，这些工作空间或表示层包含数据的子集。该模型与数据仓库中的典型数据建模非常相似。本质上，Gold是一个通用集成层，可以从中填充数据集市或子集。

某些组织利用这些工作空间或表示层向其他平台或团队传播数据。他们通过选择和/或预过滤特定场景的数据来实现这一点。其他一些组织实现标记化，包括用随机字符串替换敏感数据。其他人则使用额外的服务进行数据匿名化。这些数据可以被视为表现类似于“数据产品”数据。

由于其对企业范围标准的遵守，黄金层可能会在其他层中脱颖而出。虽然企业数据建模可能被视为复杂而耗时，但许多组织仍然使用它来确保数据的可重用性和标准化。在Lakehouse方法中，企业数据模型提供了一个抽象框架，用于在团队的lakehouses中组织数据。企业模型通常只概述某些数据，并要求团队在与其他团队共享数据集时遵循特定的参考值或包括主标识符。设置企业范围标准的另一种方法是在另一个Lakehouse架构中收集数据、协调和分发数据。从那里，数据可以在下游被其他域消耗。这种方法类似于主数据管理。或者，您可以授权团队负责特定的统一实体。那么，其他团队必须始终使用这些实体来遵守。在上述大多数情况下，标准化和协调都发生在黄金层。

当涉及到技术体系结构时，尤其是对于Gold来说，理解选择数据库或服务是一个复杂的过程是至关重要的。这一过程需要考虑各种因素，并需要作出许多妥协。除了数据结构之外，您还需要评估一致性、可用性、缓存、及时性和索引方面的需求，以增强性能。有多种存储和检索数据的方法，如小数据块或大数据块、排序数据块等。与一些爱好者可能建议的相反，没有一种单一的服务能够同时完美地满足所有方面的需求。因此，典型的Lakehouse架构通常包括多种技术服务的混合，例如用于特定查询的无服务器SQL服务、用于快速报告的柱状存储、用于更复杂查询的关系数据库、用于物联网和流分析的时间序列存储等。

我希望你觉得这是一篇有用的文章。感谢你们所有构建下一代数据平台的人：祝你们旅途愉快！