在 Microsoft Fabric 中实现奖牌式湖屋体系结构
本文介绍奖牌湖体系结构，并介绍如何在 Microsoft Fabric 中实现湖屋。 这篇文章面向以下受众：
- 数据工程师：设计、生成和维护基础结构和系统的技术人员，可支持组织收集、存储、处理和分析大量数据。
- 卓越中心、IT 和 BI 团队：负责在整个组织中监督分析的团队。
- Fabric 管理员：负责监督组织的 Fabric 的管理员。
奖牌湖屋体系结构通常称为奖牌体系结构，它是组织用来在湖屋中以合乎逻辑的方式组织数据的设计模式。 这是 Fabric 建议采用的设计方法。
奖牌体系结构包括三个不同的层或区域。 每个层指示存储在湖屋中的数据的质量，级别越高，则表示质量越高。 使用此多层方法有助于为企业数据产品构建单一事实来源。
重要的是，奖牌体系结构保证了数据在各层传输时的原子性、一致性、隔离和持续性 (ACID) 属性集。 从原始数据开始，一系列验证和转换操作将为高效分析准备经过优化的数据。 该体系结构包括三个奖牌阶段：铜牌（原始）、银牌（验证）和金牌（扩充）。
有关详细信息，请参阅《什么是奖牌湖屋体系结构？》。
Fabric 中的 OneLake 和湖屋
新式数据仓库的基础是一个数据湖。 Microsoft OneLake 是面向整个组织的单个统一逻辑数据湖。 它随每个 Fabric 租户自动预配，旨在成为所有分析数据的单个位置。
可以使用 OneLake 执行以下操作：
- 移除孤岛并降低管理工作量。 在一个数据湖资源中存储、管理和保护所有组织数据。 由于 OneLake 是随 Fabric 租户预配的，因此无需预配或管理更多资源。
- 减少数据移动和重复。 OneLake 的目标是仅存储一个数据副本。 数据副本越少，数据移动过程就会越少，从而提高效率并降低复杂性。 如有必要，可以创建快捷方式来引用存储在其他位置的数据，而不是将其复制到 OneLake。
- 与多个分析引擎一起使用。 OneLake 中的数据是以开放格式存储的。 通过此方式，各种分析引擎可以查询数据，包括 Analysis Services（由 Power BI 使用）、T-SQL 和 Apache Spark。 其他非 Fabric 应用程序也可以使用 API 和 SDK 访问 OneLake。
有关详细信息，请参阅《OneLake - 面向数据的 OneDrive》。
要在 OneLake 中存储数据，请在 Fabric 中创建湖屋。 湖屋是一个数据体系结构平台，用于在单个位置存储、管理和分析结构化数据与非结构化数据。 它可以轻松地扩展到所有文件类型和大小的大量数据，并且因为它存储在单个位置，因此可以轻松地在整个组织中共享和重用。
每个湖屋都有一个内置的 SQL 分析终结点，可用于解锁数据仓库功能，而无需移动数据。 这意味着可以使用 SQL 查询在湖屋中查询数据，而无需进行任何特殊设置。
有关详细信息，请参阅《什么是 Microsoft Fabric 中的湖屋？》。
表和文件
在 Fabric 中创建湖屋时，将会自动为表和文件预配两个物理存储位置。
- 表是托管 Apache Spark 中所有格式（CSV、Parquet 或 Delta）的表的托管区域。 所有表（无论是自动创建还是显式创建）都会识别为湖屋中的表。 此外，任何增量表（即具有基于文件的事务日志的 Parquet 数据文件）也将识别为表。
- 文件是一个非托管区域，用于以任何文件格式存储数据。 此区域中存储的任何 Delta 文件不会自动识别为表。 如果要通过非托管区域中的 Delta Lake 文件夹创建表，则需要显式创建一个快捷方式或外部表，其位置指向包含 Apache Spark 中 Delta Lake 文件的非托管文件夹。
托管区域（表）与非托管区域（文件）之间的主要区别是自动表发现和注册过程。 此过程仅在托管区域中创建的任何文件夹上运行，但不在非托管区域中运行。
在 Microsoft Fabric 中，湖屋资源管理器提供了整个湖屋的统一图形表示形式，以便用户导航、访问和更新其数据。
有关自动表发现的详细信息，请参阅《自动表发现和注册》。
Delta Lake 存储
Delta Lake 是一个优化的存储层，可提供存储数据和表的基础。 它支持大数据工作负载的 ACID 事务，因此它是 Fabric 湖屋中的默认存储格式。
重要的是，Delta Lake 在湖屋中为流式处理和批处理操作提供了可靠性、安全性和性能。 它在内部以 Parquet 文件格式存储数据，但它还会维护事务日志和统计信息，这些日志和统计信息提供标准 Parquet 格式的功能和性能改进。
与通用文件格式相比，Delta Lake 格式提供以下主要优势。
- 支持 ACID 属性，尤其是防止数据损坏的持续性。
- 更快的读取查询。
- 提高了数据新鲜度。
- 支持批处理和流式处理工作负载。
- 通过使用 Delta Lake 时间旅行支持数据回滚。
- 通过使用 Delta Lake 表历史记录增强了法规合规性和审核。
Fabric 使用 Delta Lake 对存储文件格式进行了标准化处理，默认情况下，当将数据写入新表时，Fabric 中的每个工作负载引擎都会创建增量表。 有关详细信息，请参阅《湖屋和 Delta Lake 表》。
Fabric 中的奖牌体系结构
奖牌体系结构的目标是在数据通过每个阶段传输时逐步改进和提高数据的结构和质量。
奖牌体系结构由三个不同的层（或区域）组成。
- 铜牌：也称为原始区域，是以原始格式存储源数据的第一层。 此层中的数据通常仅追加且不可变。
- 银牌：也称为扩充区域，此层存储从铜牌层获取的数据。 原始数据已经过清理和标准化处理，现在它的结构为表（行和列）。 它还可能与其他数据集成，以提供所有业务实体（如客户、产品等）的企业视图。
- 金牌：也称为特选区域，此最终层存储从银牌层获取的数据。 数据经过优化，以满足特定的下游业务和分析要求。 表通常符合星型架构设计，它支持开发针对性能和可用性而优化的数据模型。
重要
由于 Fabric 湖屋表示单个区域，因此需要为这三个区域中的每个区域创建一个湖屋。
在 Fabric 典型的奖牌体系结构实现中，铜牌区域将以与数据源相同的格式存储数据。 当数据源是关系数据库时，增量表是一个不错的选择。 银牌和金牌区域包含增量表。
提示
要了解如何创建湖屋，请完成《湖屋端到端方案》教程。
Fabric 湖屋指导
本部分提供与使用奖牌体系结构实现 Fabric 湖屋相关的指导。
部署模型
要在 Fabric 中实现奖牌体系结构，可以使用 湖屋（每个区域一个）、数据仓库或两者的组合。 你的决定应基于你的偏好和团队的专业知识。 请记住，Fabric 提供了灵活性：可以使用不同的分析引擎来处理 OneLake 中数据的一个副本。
下面是需要考虑的两种模式。
- 模式 1：将每个区域创建为湖屋。 在这种情况下，业务用户将通过使用 SQL 分析终结点访问数据。
- 模式 2：创建铜牌和银牌区域作为湖屋，并将金牌区域创建为数据仓库。 在这种情况下，业务用户可使用数据仓库终结点访问数据。
虽然可以在单个 Fabric 工作区中创建所有湖屋，但建议在其自己的单独 Fabric 工作区中创建每个湖屋。 此方法可在区域级别提供更多控制和更好的治理。
对于铜牌区域，建议以原始格式存储数据，或使用 Parquet 或 Delta Lake 来存储数据。 尽可能将数据保留为其原始格式。 如果源数据来自 OneLake、Azure Data Lake Store Gen2 (ADLS Gen2)、Amazon S3 或 Google，请在铜牌区域中创建快捷方式，而不是跨区域复制数据。
对于银牌和金牌区域，建议使用 Delta 表，因为它们可提供额外的功能和性能增强。 Fabric 会对 Delta Lake 格式进行标准化处理，默认情况下，Fabric 中的每个引擎都将以此格式写入数据。 此外，这些引擎会对 Parquet 文件格式使用 V-Order 写入时间优化。 通过这种优化，Fabric 计算引擎（如 Power BI、SQL、Apache Spark 等）能够实现极快的读取。 有关详细信息，请参阅 Delta Lake 表优化和 V-Order。
最后，今天的许多组织面临数据量的巨大增长，需要应对日益增长的以逻辑方式组织和管理这些数据的需求，同时需要促进更有针对性的高效使用和管理。 这可以引导你通过治理来建立和管理去中心化或联合式数据组织。
为了实现此目标，请考虑实现数据网格体系结构。 数据网格是一种体系结构模式，侧重于创建提供数据即产品的数据域。
通过创建数据域，可以为 Fabric 中的数据资产创建数据网格体系结构。 可以创建映射到业务领域的域，例如市场营销、销售、库存、人力资源和其他领域。 然后，可以通过在每个域中设置数据区域来实现奖牌体系结构。
有关域的详细信息，请参阅《域》。
了解增量表数据存储
本部分介绍与在 Fabric 中实现奖牌湖屋体系结构相关的其他指导主题。
文件大小
通常，当大数据平台具有少量大型文件而不是大量小文件时，其性能会更好。 这是因为，当计算引擎必须管理许多元数据和文件操作时，其性能会下降。 为了提高查询性能，建议将数据文件的大小设为约 1 GB。
Delta Lake 具有名为预测优化的功能。 预测优化不再需要手动管理 Delta 表的维护操作。 启用此功能后，Delta Lake 会自动标识将受益于维护操作的表，然后优化其存储。 它可以透明地将许多较小的文件合并到大型文件中，而不会对数据的其他读者和写入者产生任何影响。 虽然此功能应构成卓越运营和数据准备工作的一部分，但 Fabric 也能够在数据写入期间优化这些数据文件。 有关详细信息，请参阅《Delta Lake 的预测优化》。
历史数据保留
默认情况下，Delta Lake 会保留所做的所有更改的历史记录，这意味着历史元数据的大小会随着时间推移而增长。 根据业务需求，应只将历史数据保留一段时间，以降低存储成本。 请考虑仅保留上个月的历史数据或其他适当时间段的历史数据。
可以使用 VACUUM 命令从 Delta 表中移除较旧的历史数据。 但请注意，为了保持数据的一致性，默认情况下不能删除最近七天的历史数据。 默认天数由表属性 delta.deletedFileRetentionDuration = "interval <interval>" 控制。 它确定了在将文件视为清除操作的候选对象之前，必须将其删除的时间段。
表分区
在每个区域中存储数据时，建议在适用的情况下使用分区文件夹结构。 此方法有助于提高数据的可管理性和查询性能。 通常，由于分区修剪/消除，文件夹结构中的分区数据会导致更快地搜索特定数据条目。
通常，在新数据到达时，可将数据追加到目标表。 但在某些情况下，由于需要同时更新现有数据，因此可以合并数据。 在这种情况下，可以使用 MERGE 命令执行更新插入操作。 在对目标表进行分区时，请务必使用分区筛选器来加快操作速度。 这样，引擎可以消除不需要更新的分区。
数据访问
最后，应该规划和控制谁需要访问湖屋中的特定数据。 还应了解访问此数据时要使用的各种事务模式。 然后，可以定义正确的表分区方案，并使用 Delta Lake Z-order 索引并置数据。
相关内容
有关实现 Fabric 湖屋的详细信息，请参阅以下资源。