你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
数据湖区域和容器
在将数据放入数据湖之前，请务必规划数据结构。 如果有计划，则可以有效地使用安全性、分区和处理。
有关数据湖的概述，请参阅 Azure Data Lake 存储的概述，了解云规模分析。
概述
三个数据湖帐户应与典型的数据湖层保持一致。
| 湖编号 | 图层 | 容器编号 | 容器名称 |
|---|---|---|---|
| 1 | 原始 | 1 | 登陆 |
| 1 | 原始 | 2 | 一致性 |
| 2 | 扩充 | 1 | 经过标准化 |
| 2 | 策划 | 2 | 数据产品 |
| 3 | 开发 | 1 | 分析沙盒 |
| 3 | 开发 | # | Synapse 主存储编号 |
上表显示了建议每个数据登陆区域的标准容器数。 此建议的例外情况是容器中的数据是否需要不同的软删除策略。 这些要求确定了对更多容器的需求。
注意
每个数据登陆区域中展示了三个数据湖。 Data Lake 位于三个 Data Lake 帐户、多个容器和文件夹中，但它代表数据登陆区域的一个逻辑数据湖。
根据需求，可能需要将原始层、扩充层和特选层合并到一个存储帐户中。 保留另一个名为“开发”的存储帐户，供数据使用者带来其他有用的数据产品。
有关分隔 Data Lake 帐户的详细信息，请参阅逻辑数据湖中的存储帐户。
使用分层名称空间功能启用Azure 存储，这样就可以有效地管理文件。 分层名称空间功能将帐户中的对象和文件组织到目录和嵌套子目录的层次结构中。 此层次结构的组织方式与计算机上的文件系统相同。
当数据无关的引入引擎或加入应用程序注册新的记录系统时，它会在原始、扩充和标准化数据层上的容器中创建所需的文件夹。 如果源对齐的数据应用程序引入数据，数据应用程序团队需要数据登陆区域团队来创建文件夹和安全组。 将服务主体名称或托管标识放入正确的组，并分配权限级别。 为数据登陆区域和数据应用程序团队记录此流程。
有关团队的详细信息，请参阅了解 Azure 中云规模分析的角色和团队。
每个数据产品都应在数据产品容器中包含两个文件夹，数据产品团队拥有这些文件夹。
在标准化容器的扩充层中，每个源系统有两个按分类划分的文件夹。 使用此结构，你的团队可以单独存储具有不同安全性和数据分类的数据，并为其分配不同的安全访问权限。
标准化容器需要一个用于保存机密或更低级别的数据的常规文件夹，以及一个用于保存个人数据的敏感文件夹。 使用访问控制列表（ACL）控制对这些文件夹的访问。 可以创建删除所有个人数据的数据集，并将其存储在常规文件夹中。 可以有另一个数据集，其中包含敏感个人数据文件夹中的所有个人数据。
ACL 和 Microsoft Entra 组的组合限制数据访问。 这些列表和组控制其他组可以和不可以访问的内容。 数据所有者和数据应用程序团队可以批准或拒绝对其数据资产的访问。
警告
某些软件产品不支持装载 Data Lake 容器的根目录。 由于此限制，原始、特选、扩充和开发层中的每个 Data Lake 容器应包含一个分支到多个文件夹的文件夹。 仔细设置文件夹权限。 从根目录创建新文件夹时，父目录中的默认 ACL 将确定子目录的默认 ACL 并访问 ACL。 子文件的 ACL 没有默认 ACL。
有关详细信息，请参阅 Azure Data Lake Storage Gen2 中的访问控制列表 (ACL)。
原始层或数据湖 1
将原始层视为以自然和原始状态存储数据的容器。 它未经过滤和净化。 可以采用原始格式（如 JSON 或 CSV）存储数据。 或者，将文件内容存储为压缩文件格式（如 Avro、Parquet 或 Databricks Delta Lake）的列可能具有成本效益。
此原始数据是不可变的。 使原始数据保持锁定状态，如果向任何使用者（自动化或人工）授予权限，请确保它们是只读的。 可以使用每个源系统一个文件夹来组织此层。 为每个引入进程仅授予对其关联文件夹的写入访问权限。
将数据从源系统加载到原始区域时，可以选择执行以下操作：
- 用于提取完整数据集的完全加载 。
- 增量加载 以仅加载已更改的数据。
指示所选加载模式在文件夹结构中，以简化数据使用者的使用。
源系统中每个源对齐的数据应用程序或自动引入引擎源位于完整文件夹或 delta 文件夹中的原始数据。 每个引入进程应仅对其关联文件夹具有写入访问权限。
完整负载和增量负载之间的差异如下：
完全加载 - 如果：
- 源中的数据量较小。
- 源系统不维护时间戳字段，用于标识是否已添加、更新或删除数据。
- 源系统每次都会覆盖完整数据。
增量加载 - 可从源载入增量数据（如果：
- 源中的数据量很大。
- 源系统维护一个时间戳字段，用于标识是否已添加、更新或删除数据。
- 数据更改后，源系统会创建和更新文件。
原始数据湖由登陆容器和一致性容器组成。 每个容器使用特定于其用途的 100% 强制文件夹结构。
登陆容器布局
登陆容器是为来自已识别源系统的原始数据保留的。 与数据无关的引入引擎或源对齐的数据应用程序加载数据，该数据不受更改且采用其原始支持的格式。
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
原始层一致性容器
原始层包含符合数据质量的数据。 将数据复制到登陆容器时，将触发数据处理和计算，将数据从登陆容器复制到一致性容器。 在此第一阶段，数据将转换为 Delta Lake 格式并进入输入文件夹。 当数据质量运行时，传递的记录将复制到输出文件夹中。 在错误文件夹中失败的记录。
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
提示
考虑可能需要从头开始重新生成分析平台的方案。 请考虑重新生成下游读取数据存储所需的最精细数据。 确保为关键组件制定业务连续性和灾难恢复计划。
扩充层或数据湖 2
将扩充层视为筛选层。 它去除杂质，也可能涉及扩充。
标准化容器保存记录和主控系统。 文件夹首先按主题领域划分，然后按实体划分。 数据在已合并的已分区表中提供，这些表已针对分析消耗进行了优化。
标准化容器
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
注意
此数据层被视为银级层或读取数据源。 除数据质量、增量湖转换和数据类型对齐外，此层中的数据没有应用任何转换。
下图显示了数据湖和容器从源数据到标准化容器的流程。
特选层或数据湖 2
特选层是使用层。 它针对分析而不是数据引入或处理进行优化。 特选层可以将数据存储在非规范化数据市场或星型架构中。
标准化容器中的数据将转换为提供给数据使用者的高价值数据产品。 此数据具有结构。 它可以按原样提供给使用者，如数据科学笔记本，或通过另一个读取数据存储（如Azure SQL 数据库）。
使用 Spark 或数据工厂等工具执行维度建模，而不是在数据库引擎中执行此操作。 如果你想让湖成为单一事实来源，那么这种工具的使用就成为一个关键点。
如果在湖外部进行维度建模，你可能希望将模型发布回到湖以保持一致性。 此层不是数据仓库的替代项。 其性能通常不足以响应仪表板或最终用户和使用者交互式分析。 此层最适合运行大规模、即兴查询或分析的内部分析师和数据科学家，或者适用于没有时间敏感报告需求的高级分析师。 由于数据湖中的存储成本比数据仓库低，因此在湖中保持精细的低级别数据可能具有成本效益。 在仓库中存储聚合数据。 使用 Spark 或Azure 数据工厂生成这些聚合。 在将数据加载到数据仓库之前，请将其保存到 Data Lake。
此区域中的数据资产通常高度治理，并且记录良好。 按部门或职能分配权限，并按使用者组或数据市场组织权限。
数据产品容器
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
提示
将数据置于另一个读取数据存储（如Azure SQL 数据库）时，请确保该数据的副本位于特选数据中。 数据产品用户将引导到主读取数据存储或Azure SQL 数据库实例，但如果数据在 Data Lake 中可用，还可以使用额外的工具浏览数据。
开发层或数据湖 3
数据使用者可以连同引入到标准化容器的数据一起引入其他有用数据产品。
在此方案中，数据平台可以为这些使用者分配分析沙盒区域。 在沙盒中，他们可以使用他们带来的特选数据和数据产品来生成有价值的见解。 例如，如果数据科学团队希望确定新区域的最佳产品放置策略，则可以从该区域的类似产品引入其他数据产品，如客户人口统计数据和使用情况数据。 该团队可以使用此数据中的高价值销售见解来分析产品市场拟合和产品策略。
注意
分析沙盒区域是单个或少量协作者的工作区域。 沙盒区域的文件夹具有一组特殊策略，可防止将此区域用作生产解决方案的一部分的企图。 这些策略限制可用存储总量以及可以存储的数据时长。
这些数据产品的质量和准确性通常是未知的。 它们仍被归类为数据产品，但临时且仅与使用该数据的用户组相关。
当这些数据产品成熟时，企业可以将这些数据产品提升到特选的数据层。 为了让数据产品团队负责处理新的数据产品，请在特选数据区域中为团队提供专用文件夹。 他们可以将新结果存储在文件夹中，并与组织中的其他团队共享。
注意
对于创建的每个 Azure Synapse 工作区，请使用 Data Lake 3 创建容器以用作主存储。 此容器阻止 Azure Synapse 工作区干扰特选和扩充区域的吞吐量限制。
数据流入产品和分析沙盒的示例
下图编译了本文中的信息，并演示了数据如何流向数据产品和服务和分析沙盒。
