在此阶段，你将为数据湖仓设计 Delta Lake 存储架构和数据组织方式。
设计奖牌体系结构
奖牌架构将数据组织成多个层次，以随着数据在管道中的推进提高数据质量。 这种模式是构建结构良好的湖屋的基础。
在最简单的形式中，奖牌体系结构由三层组成：青铜层（原始数据）、银层（精简数据）和黄金层（业务就绪数据）。
青铜层 （原始数据）
将源数据导入湖屋的一层并在此保存。 从青铜层创建所有下游数据时，如果需要，可以从此层重新生成后续层。
青铜层特征
事实来源：原始数据完全按照从源系统接收时的状态。
最小转换：以原始格式存储的数据（或转换为 Delta 以便可审核）。
不可变：数据仅追加，从不更新或删除。
读取架构：针对各种源系统的灵活架构处理。
审核线索：对于某些应用程序（如 GDPR 或管控数据），可以将此层转换为 Delta 格式。
青铜层的最佳做法
保留所有源数据字段，以便完全可审核。
使用 Unity 目录卷登陆原始文件。
实现增量引入以避免完全重新处理。
通过引入日期进行分区，实现高效的数据管理。
记录数据源和引入计划。
银层（精炼数据）
第二层的目的是保存清理、优化、筛选和聚合的数据。
银层特征
数据质量：删除重复项、处理缺失值、强制实施架构。
扩充：联接来自多个源的数据以创建集成数据集。
标准化：应用一致的数据类型、格式和命名约定。
业务规则：实现验证规则和业务逻辑。
服务于分析：用于报告、仪表板和机器学习的基础。
银层最佳做法
实施数据质量检查和监视。
将 Unity Catalog 托管表用于银层数据。
按业务维度（例如日期、区域、产品）进行分区。
文档转换逻辑和业务规则。
为数据新鲜度建立 SLA。
黄金层 （业务就绪数据）
第三层是围绕业务或项目需求创建的。 它作为数据产品提供给其他业务部门或项目，从而满足不同的安全需求（例如，匿名化的数据）或者优化性能（例如，预先聚合的视图）。
黄金层特征
业务特定：专为特定用例和使用者定制。
性能优化：针对快速查询预先聚合、非规范化。
访问控制：实现行级安全性和列掩码。
面向用户：结构化用于 BI 工具、应用程序和机器学习模型。
数据产品：作为整个组织中的可重用数据集发布。
黄金层的最佳做法
为不同的业务部门或用例创建单独的黄金表。
使用动态视图实现行级别和列级安全性。
为经常查询的表实现预测优化。
记录从青铜到黄金的数据世系。
通过具有明确所有权的 Unity 目录发布数据产品。
登陆区域注意事项
大型组织中的管道通常在云中具有额外的登陆区域。 登陆区域在引入青铜层之前从外部系统接收原始文件。
登陆区域模式
云对象存储：用于文件删除的 S3、ADLS Gen2 或 GCS 存储桶。
Unity 目录卷：使用 Unity 目录治理保护 POSIX 样式的文件访问。
第三方访问：外部系统可以直接写入登陆区域。
通知触发器：使用事件通知触发引入管道。
有关全面的奖章体系结构指南，请参阅什么是奖章湖屋建筑？
设计数据引入策略
将数据引入铜层是奖牌体系结构的第一步。 根据数据源、数据量和延迟要求设计引入策略。
引入方法
Lakeflow Connect
Lakeflow Connect 是Azure Databricks提供的托管数据引入服务，可以定期将数据从外部源同步到Azure Databricks，而无需编写一行代码。
合作伙伴引入工具
Fivetran 等工具还可以从 Lakeflow Connect 不支持的源引入数据。 任何此类原始和非结构化数据都应存储在 Unity 目录卷（而不是外部位置）中。
自定义引入管道
对于复杂的转换需求或不受支持的数据源，请使用 Lakeflow 管道或笔记本构建自定义数据引入管道。
引入模式
批量摄取
计划定期数据加载（例如每小时、每日、每周）。
最适合处理大量历史数据。
与流式处理相比，成本更低。
分析工作负荷的可接受延迟。
流数据引入
持续数据引入，延迟较低。
将 Lakeflow 管道与自动加载程序配合使用，以便进行文件引入。
最适合实时分析和操作用例。
更高的计算成本，但新数据。
更改数据捕捉（CDC）
从源系统捕获和应用增量更改。
对于需要频繁更新的大型表，该方法效率很高。
保留数据世系和审核线索。
由 Lakeflow Connect 和 Lakeflow 管道提供支持。
数据引入的最佳做法
使用 Unity 目录卷在青铜引入之前登陆原始数据。
实现幂等引入以安全地处理重试。
使用自动加载程序从云存储高效引入文件。
为登陆区域数据配置保留策略。
监视引入管道，以查找故障和数据质量问题。
设计表管理策略
表和卷可以创建为管理的或外部的。 了解取舍有助于您设计正确的表策略。
托管表 vs 外部表
托管表和存储卷
Unity 目录管理对来自Azure Databricks的外部表和卷的访问，但不控制基础文件或完全管理这些文件的存储位置。 另一方面，库存表和数据卷完全由 Unity Catalog 管理，并存储在与所含模式关联的托管存储地点。
Azure Databricks建议对大多数工作负荷使用托管卷和托管表，因为它们简化了配置、优化和管理。 新功能（如预测优化和托管灾难恢复）仅适用于托管表。
外部表和卷
与外部表相比，托管表最大的不同在于没有提供简单文件夹结构 schema_name/table_name，而是使用内部类似于 GUID 的文件夹。 只能通过 Unity 目录访问这些文件夹。
何时使用外部表
出于法规或合规性原因，数据必须保留在特定的云存储路径中。
外部系统需要对数据进行直接文件访问。
与无法使用 OpenSharing 的系统共享数据。
无法迁移到托管存储的现有数据。
表管理的最佳做法
对所有新的 Lakehouse 数据（青铜、白银、黄金）使用托管表。
采用托管卷以处理登陆区域和原始非结构化数据。
仅为必须保留在特定路径中的数据保留外部表。
制定所有数据表的所有权和生命周期策略。
为经常查询的托管表启用预测优化。
中心辐射徽章设计
中心辐射型设计模式可与企业部署的Medallion架构相结合。 此模式集中共享数据资产，同时允许特定于域的数据处理。
星型拓扑奖牌特征
数据中心：引入、策展和管理组织范围内的资产（例如 SAP 数据或常规资产，如天气或财务）。 这些产品可以被视为源链接的数据产品。
数据域：每个域读取一些中心策展的数据产品，并引入和策展其特定领域的原始数据。 然后，域生成特定于域的数据产品。
发布模型
集中发布：域将数据产品发布回中心供组织使用。
分布式发布：域在其自己的目录中发布数据产品以供域特定的使用。
示例星形拓扑结构
Data Hub (Central)
├── Bronze: Organization-wide raw data (SAP, financials, weather)
├── Silver: Curated shared datasets
└── Gold: Enterprise-wide data products
Sales Domain
├── Bronze: Sales-specific raw data + shared hub data
├── Silver: Sales analytics datasets
└── Gold: Sales data products (published to hub or domain)
Engineering Domain
├── Bronze: Engineering telemetry + shared hub data
├── Silver: Engineering metrics
└── Gold: Engineering dashboards (published within domain)
枢纽-辐射模型的最佳实践
将中心用于多个域使用的组织范围的共享数据。
允许域采集和管理其特定于域的数据。
建立明确的数据产品发布策略（集中式与分布式）。
使用 Unity Catalog 的目录来划分中心和域数据。
使用Azure Databricks托管的 OpenSharing 在中心和域之间共享数据产品。
设计数据管理策略
数据管理可确保跨 Databricks 的数据质量、可发现性和合规性。 设计适合组织成熟度和要求的治理策略。
数据质量策略
无论勋章架构的变体如何，随着数据在各层之间流动，数据质量必须提高。 因此，对数据的信任随后会从业务角度增加。
数据质量工具
约束：确保自动验证添加到表的数据的质量和完整性。
主键和外键：对表中的字段之间的关系进行编码（信息性，未强制执行）。
预期：防止数据质量问题蔓延到下游（当前适用于 Lakeflow 管道，不久后将适用于所有 Unity Catalog 表）。
Lakehouse 监控：监控账户中所有表中数据的统计属性和质量。
数据质量最佳做法
在青铜引入时实施数据质量检查（例如架构验证、null 检查）。
当数据移动到银牌和黄金时，强制实施更严格的质量规则。
监视一段时间内的数据质量指标和趋势。
为关键数据集定义数据质量 SLA。
针对数据质量冲突自动发出警报。
避免数据孤岛
数据移动、复制和重复需要一段时间，并可能会降低 Lakehouse 中的数据质量，尤其是在导致数据孤岛时。 为了明确数据复制与数据孤岛之间的区别，数据独立副本或一次性副本本身并不有害。 有时有必要提高敏捷性、试验性和创新性。 当这些副本与依赖它们的下游业务数据产品一起正常运行时，它们将成为数据孤岛。 这些孤岛很快出现不同步，最终导致数据湖的可信度降低。
避免数据孤岛最佳做法
使用 Unity 目录视图和 OpenSharing，而不是复制数据。
为每个数据集建立单一事实来源。
阻止部门级数据复制和重复。
使用 Unity Catalog 血统追踪数据依赖。
定期停用冗余数据集。
数据目录与发现
Unity 目录为可用性和数据治理提供数据发现和世系。
数据发现
所有业务领域的用户（特别是在自助服务模型中）都需要能够发现相关数据。 因此，Lakehouse 需要一个涵盖所有业务相关数据的数据目录。 数据目录的主要目标是：
允许用户搜索和发现数据集。
提供数据集的元数据、说明和文档。
显示从源到消耗的数据世系。
显示数据质量指标和新鲜度信息。
数据世系
精确跟踪数据世系，以便用户可以解释数据如何到达其当前形状和形式。 Unity 目录会自动捕获以下项的世系：
表间依赖关系。
执行进行读取或写入数据的笔记本和作业任务。
上游源系统。
下游消费者和数据产品。
数据目录的最佳做法
向所有目录、架构和表添加说明和标记。
记录数据所有者和主题专家。
使用 Unity Catalog 搜索以启用数据探索。
定期查看和更新元数据。
在进行更改之前，使用世系了解数据依赖关系。
Delta Lake 体系结构建议
推荐
使用奖牌体系结构来构建数据湖（铜牌、银牌、金牌）。
使用 Unity Catalog 托管表来管理所有湖仓数据（青铜到黄金）。
将 Unity 目录卷用于登陆区域和原始非结构化数据。
在每个层（青铜、银、金）上实施数据质量检查。
使用 Unity 目录启用数据发现和世系跟踪。
为经常查询的托管表启用预测优化。
为枢纽-辐射型体系结构建立明确的数据产品发布策略。
避免
不要通过跨域复制操作数据来创建数据孤岛。
除非数据必须保留在特定的存储路径中，否则不要使用外部表。
不要跳过青铜层（始终将原始数据保留为事实来源）。
不要绕过数据质量检查来满足交付截止时间。
不允许在没有 Unity Catalog 治理的情况下发生非托管数据蔓延。
阶段 6 结果
完成阶段 6 后，应具备：
奖章架构设计包括青铜层、银层和金层，每层都有其明确用途。
根据要求定义的数据引入策略（批处理、流式处理或 CDC）。
表管理策略设计（管理表与外部表）。
评估“轮辐式”勋章架构（针对多领域组织）。
通过在每一层进行适当的检查来定义数据质量策略。
已建立数据管理策略（例如目录、世系、发现）。
设计着陆区架构（如果需要满足外部系统的要求）。
定义的数据产品发布模型（集中式、分布式或混合）。
实施指南：有关实施 Delta Lake 设计的分步说明，请参阅 什么是 Azure Databricks 中的 Delta Lake？。