你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

数据湖区域和容器

在将数据放入数据湖之前,请务必规划数据结构。 有了计划,就能有效地使用安全、分区和处理功能。

有关数据湖的概述,请参阅面向云规模分析的 Azure Data Lake Storage 概述

概述

三个数据湖帐户应与典型的数据湖层保持一致。

湖编号 图层 容器数量 容器名称
1 原始 1 登陆
1 原始 2 一致性
2 扩充 1 经过标准化
2 策划 2 数据产品
3 开发 1 分析沙盒
3 开发 # Synapse 主存储编号

上表显示了我们建议的每个数据登陆区域的标准容器数量。 此建议的例外情况是容器中的数据是否需要不同的软删除策略。 这些要求确定了对更多容器的需求。

注意

每个数据登陆区域中展示了三个数据湖。 数据湖跨越三个数据湖帐户、多个容器和文件夹,但它代表了数据登陆区域的一个逻辑数据湖。

根据你的要求,你可能希望将原始层、扩充层和特选层合并到一个存储帐户中。 保留另一个名为“开发”的存储帐户,供数据使用者带来其他有用的数据产品。

有关分离数据湖帐户的更多信息,请参阅逻辑数据湖中的存储帐户

启用 Azure Storage 的分层命名空间功能可以有效地管理文件。 分层名称空间功能会将帐户内的对象和文件组织成一个由目录和嵌套子目录组成的层次结构。 此层次结构的组织方式与计算机上的文件系统相同。

当数据无关的引入引擎或加入应用程序注册新的记录系统时,它会在原始、扩充和标准化数据层上的容器中创建所需的文件夹。 如果源对齐的数据应用程序要引入数据,则数据应用程序团队需要由数据登陆区域团队来创建文件夹和安全组。 将服务主体名称或托管标识放入正确的组中,然后分配权限级别。 为数据登陆区域和数据应用程序团队记录此流程。

有关团队的详细信息,请参阅了解 Azure 中云规模分析的角色和团队

每个数据产品都应在由数据产品团队管理的数据产品容器中拥有两个文件夹。

在标准化容器的扩充层中,每个源系统有两个按分类划分的文件夹。 通过这种结构,你的团队可以单独存储具有不同安全性和数据分类的数据,并为它们分配不同的安全访问权限。

标准化容器需要一个用于保存机密或更低级别的数据的常规文件夹,以及一个用于保存个人数据的敏感文件夹。 通过使用访问控制列表 (ACL) 来控制对这些文件夹的访问。 可以创建一个删除了所有个人数据的数据集,并将其存储在普通文件夹中。 你可以拥有另一个数据集,其中包含了敏感个人数据文件夹中的所有个人数据。

ACL 和 Microsoft Entra 组的组合可限制数据访问。 这些列表和组控制其他组可以和不可以访问的内容。 数据所有者和数据应用程序团队可以批准或拒绝对其数据资产的访问。

有关详细信息,请参阅数据隐私

警告

某些软件产品不支持挂在数据湖容器的根。 由于存在这种限制,原始层、特选层、扩充层和开发层中的每个数据湖容器都应包含一个可分支到多个文件夹的文件夹。 仔细设置文件夹权限。 从根目录创建新文件夹时,父目录中的默认 ACL 会决定子目录的默认 ACL 和访问 ACL。 子文件的 ACL 没有默认 ACL。

有关详细信息,请参阅 Azure Data Lake Storage Gen2 中的访问控制列表 (ACL)

原始层(青铜)或数据湖 1

注意

奖牌体系结构是一种数据设计模式,用于描述一系列逐步完善的数据层,这些数据层提供了湖屋的基本结构。 青铜层、白银层和黄金层表示每个级别的数据质量不断提高,其中黄金层代表最高质量。

将原始层视为以自然和原始状态存储数据的容器。 它未经筛选和净化。 数据可以按 JSON 或 CSV 等原始格式进行存储。 或者,将文件内容作为压缩文件格式(如 Avro、Parquet 或 Databricks Delta Lake)中的一列进行存储,这样做可能更为经济。

这些原始数据是不可改变的。 让原始数据保持锁定状态,如果你向任何使用者(自动或人工)授予权限,请确保将它们设为只读。 可以为每个源系统建立一个文件夹来组织该层。 为每个引入进程仅授予对其关联文件夹的写入访问权限。

将数据从源系统加载到原始区域时,可以选择执行以下操作:

  • 满负荷,以便提取整个数据集。
  • 增量负荷,以便仅加载更改的数据。

在文件夹结构中注明所选的加载模式,以简化数据使用者的使用。

每个源对齐数据应用程序或自动引入引擎源的源系统原始数据都放在完整文件夹或增量文件夹中。 每个引入进程应仅对其关联文件夹具有写入访问权限。

满负荷和增量负荷的区别在于:

  • 满负荷 - 在以下情况时,可将数据源的完整数据载入:

    • 源的数据量较小。
    • 源系统没有一个时间戳字段来识别数据是否被添加、更新或删除。
    • 源系统每次都会覆盖完整数据。
  • 增量负荷 - 如果出现以下情况,可以载入源的增量数据:

    • 源的数据量较大。
    • 源系统有一个时间戳字段来识别数据是否被添加、更新或删除。
    • 数据更改后,源系统会创建和更新文件。

原始数据湖由登陆容器和一致性容器组成。 每个容器都根据其用途使用 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 Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}

提示

在其他读取数据存储(如 Azure SQL 数据库)中读取数据时,请确保特选数据中包含了该数据的副本。 数据产品用户会被引导到主读取数据存储或 Azure SQL 数据库实例,但如果在数据湖中提供数据,他们也可以使用额外的工具来浏览数据。

开发层或数据湖 3

数据使用者可以连同引入到标准化容器的数据一起引入其他有用数据产品。

在这种情况下,数据平台可以为这些使用者分配一个分析沙盒区域。 在沙盒中,他们可以利用自己带来的特选数据和数据产品,以便生成有价值的见解。 例如,如果数据科学团队希望确定新地区的最佳产品投放策略,则他们可以从该地区的同类产品中获取其他数据产品,如客户人口统计和使用数据。 团队可以利用这些数据中的高价值销售见解来分析产品的市场契合度和销售策略。

注意

分析沙盒区域是个人或小组合作者的工作区。 沙盒区域的文件夹具有一组特殊策略,可防止将此区域用作生产解决方案的一部分的企图。 这些策略限制了可用存储总量和数据存储时间。

这些数据产品的质量和准确性通常是未知的。 它们仍被归类为数据产品,但都是临时的,只与使用数据的用户组相关。

当这些数据产品成熟后,企业就可以将这些数据产品推广到特选数据层。 为了让数据产品团队负责处理新的数据产品,请在特选数据区域中为团队提供专用文件夹。 他们可以在文件夹中存储新结果,并与组织内的其他团队共享。

注意

对于创建的每个 Azure Synapse workspace,可使用数据湖 3 创建一个容器作为主存储。 该容器可阻止 Azure Synapse workspace 干扰特选和扩充区域的吞吐量限制。

后续步骤