介绍

一开始，规划数据湖似乎是一项艰巨的任务——决定如何最好地构建数据湖、选择哪种文件格式、是拥有多个数据湖还是只有一个数据湖、如何保护和管理数据湖。并非所有这些都需要在第一天回答，有些可能通过反复试验来确定。构建数据湖没有明确的指南，每个场景在摄取、处理、消费和治理方面都是独一无二的。
在之前的博客中，我介绍了数据湖和 Azure 数据湖存储 (ADLS) gen2 的重要性，但本博客旨在为即将踏上数据湖之旅的人提供指导，涵盖构建数据湖的基本概念和注意事项ADLS gen2 上的数据湖。

数据湖规划

结构、治理和安全性是关键方面，需要根据数据湖的潜在规模和复杂性进行适当的规划。考虑哪些数据将存储在湖中，它将如何到达那里，它的转换，谁将访问它，以及典型的访问模式。这将影响湖泊的结构及其组织方式。然后考虑谁需要访问哪些数据，以及如何对这些数据的消费者和生产者进行分组。从长远来看，规划如何实施和管理跨湖访问控制将是非常值得的投资。
如果您的数据湖可能从少量数据资产开始，并且只有自动化流程（例如 ETL 卸载），那么这个规划阶段可能是一项相对简单的任务。如果您的湖包含数百个数据资产并且具有自动和手动交互，那么规划肯定会花费更长的时间，并且需要来自各个数据所有者的更多协作。
到目前为止，大多数人可能都非常熟悉可怕的“数据沼泽”类比。根据蓝色花岗岩； “努力工作、治理和组织”是避免这种情况的关键。当然，可能不可能在一开始就计划好每一种可能性，但打下坚实的基础将增加数据湖持续成功的机会和长期的商业价值。
随着数据湖的规模（数据资产数量）和复杂性（用户或部门数量）的增加，强大的数据目录系统也变得越来越重要。该目录将确保可以为处理、消费和管理湖泊的人员找到、标记和分类数据。这个重要的概念将在另一个博客中更详细地介绍。

数据湖结构——区域

这一定是数据湖社区中最常争论的话题，简单的答案是每个数据湖都没有单一的蓝图——每个组织都有自己独特的一组需求。一种简单的方法可能是从几个通用区域（或层）开始，然后随着更复杂的用例的出现而有机地构建。下面概述的区域通常被称为不同的事物，但从概念上讲，它们具有相同的目的——在数据流经湖时区分数据的不同状态或特征，通常在业务价值和访问该数据的消费者方面。

生区（Raw zone）

使用基于水的类比，将这一层视为一个水库，它以自然原始状态存储数据——未经过滤和未经净化。您可以选择以原始格式（例如 json 或 csv）存储它，但在某些情况下，将其存储为压缩格式的列更有意义，例如 avro、parquet 或 Databricks Delta Lake。这些数据始终是不可变的——它应该被锁定并允许对任何消费者（自动或人工）只读。可以使用每个源系统的文件夹来组织区域，每个摄取进程仅对其关联的文件夹具有写访问权。
由于这一层通常存储的数据量最大，因此可以考虑使用生命周期管理来降低长期存储成本。在撰写本文时，ADLS gen2 支持以编程方式或通过生命周期管理策略将数据移动到酷访问层。该策略定义了一组每天运行一次的规则，可以分配给帐户、文件系统或文件夹级别。尽管操作会产生费用，但该功能是免费的。

净化区（Cleansed zone）

下一层可以被认为是一个过滤区，它可以去除杂质，但也可能涉及富集。
在这一层中发现的典型活动是模式和数据类型定义，删除不必要的列，以及清洁规则的应用，无论是验证、标准化还是协调。丰富过程还可以组合数据集以进一步提高洞察力的价值。
这个区域的组织通常更多是业务驱动而不是源系统——通常这可能是每个部门或项目的文件夹。有些人可能还认为这是一个暂存区，通常由针对它运行的自动化作业许可。如果数据分析师或科学家需要访问这种形式的数据，他们可以被授予只读访问权限。

策展区(Curated zone)

这是消费层，它针对分析而不是数据摄取或数据处理进行了优化。如本博客所述，它可以将数据存储在非规范化数据集市或星型模式中。维度建模最好使用 Spark 或数据工厂等工具完成，而不是在数据库引擎内部完成。如果您希望使湖泊成为唯一的事实来源，那么这将成为一个关键点。如果维度建模是在湖之外（即在数据仓库中）完成的，那么您可能希望将模型发布回湖中以保持一致性。不管怎样，请注意；不要指望这一层会取代数据仓库。通常，性能不足以用于响应式仪表板或最终用户/消费者交互式分析。它最适合希望运行大规模即席查询、分析或高级分析但没有严格的时间敏感报告需求的内部分析师或数据科学家。由于与数据仓库相比，湖中的存储成本通常较低，因此将细粒度的低级别数据保留在湖中并仅在仓库中存储聚合数据可能更具成本效益。这些聚合可以由 Spark 或数据工厂生成，并在加载数据仓库之前持久化到湖中。
该区域中的数据资产通常受到高度管理且有据可查。权限通常由部门或职能分配，并由消费者组或数据集市组织。

实验室区(Laboratory zone)

这是发生探索和实验的层。在这里，数据科学家、工程师和分析师可以自由地进行原型设计和创新，将他们自己的数据集与生产数据集混合在一起。这类似于在初始价值评估期间有用的自助服务分析 (BI) 的概念。此区域不能替代开发或测试数据湖，在典型的软件开发生命周期之后，更严格的开发活动仍然需要它。
每个湖用户、团队或项目都将通过文件夹拥有自己的实验室区域，他们可以在其中对新的见解或分析进行原型设计，然后通过自动化工作将它们正式化和生产化。此区域中的权限通常是每个用户、团队或项目的读写权限。
为了在一张图中可视化端到端的数据流、所涉及的角色、工具和概念，以下内容可能会有所帮助……

数据湖中的概念、工具和角色

Concepts, tools, & personas in the Data Lake

之前没有提到敏感区域，因为它可能不适用于每个组织，因此它是灰色的，但值得注意的是，这可能是一个访问受限的单独区域（或文件夹）。
科学家在原始区域中显示为灰色的原因是，并非所有数据科学家都希望使用原始数据，因为它需要大量数据准备才能用于机器学习模型。同样，分析师通常不需要访问已清理的层，但每种情况都是独特的，并且可能会发生。

文件夹结构/层次结构

适当的文件夹层次结构将尽可能简单，但不会更简单。文件夹结构应具有：

一种人类可读、可理解、一致、自记录的命名约定
足够细化的权限，但不会产生额外开销和管理的深度。
分区策略可以优化访问模式和适当的文件大小。特别是在精选区域中，根据最佳检索计划结构，但要谨慎选择具有高基数的分区键，这会导致过度分区，进而导致文件大小不理想。
每个文件夹都有相同schema 和相同格式/类型的文件

虽然许多使用基于时间的分区有许多选项可以提供更有效的访问路径。您可能希望考虑的其他一些选项是主题领域、部门/业务单位、下游应用程序/用途、保留政策或新鲜度或敏感性。

原始区域可以由源系统组织，然后是实体。这是一个示例文件夹结构，最适合文件夹安全性：


\Raw\DataSource\Entity\YYYY\MM\DD\File.extension

通常，每个源系统都将在 DataSource 文件夹级别被授予写入权限，并指定默认 ACL（请参阅下面有关 ACL 的部分）。这将确保在创建新的每日文件夹和文件时继承权限。相反，以下结构对于文件夹安全性可能会变得乏味，因为需要为每个新的每日文件夹授予写入权限：


\Raw\YYYY\MM\DD\DataSource\Entity\File.extension

原始层中的敏感子区域可以由顶级文件夹分隔。这将允许使用基于前缀匹配的规则定义单独的生命周期管理策略。例如：


\Raw\General\DataSource\Entity\YYYY\MM\DD\File.extension
\Raw\Sensitive\DataSource\Entity\YYYY\MM\DD\File.extension

在这个规划阶段，一定要保持开放的心态。文件夹或区域不需要总是驻留在同一个物理数据湖中——它们也可以表现为单独的文件系统或不同的存储帐户，即使在不同的订阅中也是如此。特别是如果您可能在单个区域中有巨大的吞吐量要求，可能超过每秒 20,000 的请求率，那么不同订阅中的多个物理湖（存储帐户）将是一个明智的想法。请参阅标题为“有多少数据湖/存储帐户/文件系统？”的部分更多细节。

我需要多少数据湖、存储帐户和文件系统？

一个常见的设计考虑是是否拥有单个或多个数据湖、存储帐户和文件系统。数据湖本身可以被认为是一个单一的逻辑实体，但它可能由不同区域的不同订阅中的多个存储帐户组成，具有集中式或分散式管理和治理。无论物理实施如何，使用单一存储技术的好处是能够通过多种访问数据的方式在整个组织内实现标准化。虽然 ADLS gen2 仍然是一项完全托管的 PaaS 服务，并且在您开始存储和访问数据之前，拥有多个存储帐户或文件系统不会产生任何金钱成本。 Azure 中的每个资源都存在与管理和运营相关的开销，以确保适当地维护预配、安全性和治理（包括备份和 DR）。是否创建一个或多个帐户的问题没有明确的答案，它需要根据您的独特情况进行思考和计划。一些最重要的考虑因素可能是：

规划大型企业工作负载可能需要大量的吞吐量和资源。考虑到各种订阅和服务配额可能会影响您将湖物理拆分为多个订阅和/或存储帐户的决定。有关更多信息，请参阅附录。
区域与全球湖泊。湖上全球分布的消费者或进程可能对地理距离引起的延迟很敏感，因此需要数据驻留在本地。监管限制或数据主权通常会阻止数据离开特定区域。这些只是一个物理湖泊可能不适合全球运营的几个原因。
全球企业可能有多个区域性湖泊，但需要获得其运营的全球视野。一个集中的湖可能会收集和存储区域聚合数据，以便运行企业范围的分析和预测。
计费和组织原因。由于计费或分散管理的原因，某些部门或子公司可能需要自己的数据湖。
环境隔离和可预测性。尽管 ADLS gen2 提供了出色的吞吐量，但仍有一些限制需要考虑。例如，人们可能希望将实验室区域中运行的活动与对策展区域的潜在影响隔离开来，该区域通常保存用于关键决策的具有更大商业价值的数据。
存储帐户级别的特性和功能。如果您想使用生命周期管理或防火墙规则等选项，请考虑是否需要在区域或数据湖级别应用这些选项。

虽然拥有多个存储帐户可能有很多充分的理由，但应注意不要创建额外的孤岛，从而阻碍数据的可访问性和探索。注意避免由于整个组织缺乏可见性或知识共享而导致重复的数据项目。更有理由确保有一个集中的数据目录和项目跟踪工具。幸运的是，只要适当授予权限，ADF 和 Databricks (Spark) 等数据处理工具和技术就可以轻松地跨多个湖与数据交互。有关从 Databricks 用户和进程保护 ADLS 的不同方法的信息，请参阅以下指南。

HNS、RBAC 和 ACL

应该重申的是，ADLS gen2 不是一个单独的服务（就像 gen1 一样），而是一个启用了分层命名空间 (HNS) 的普通 v2 存储帐户。之后无法将标准 v2 存储帐户迁移到 ADLS gen2 — 必须在创建帐户时启用 HNS。如果没有 HNS，控制访问的唯一机制是容器级别的基于角色的访问 (RBAC)，对于某些人来说，这不能提供足够精细的访问控制。对于 HNS，RBAC 通常用于存储帐户管理员，而访问控制列表 (ACL) 指定谁可以访问数据，而不是存储帐户级别设置。 RBAC 权限的评估优先级高于 ACL，因此如果同一用户同时拥有这两种权限，则不会评估 ACL。如果这一切听起来有点令人困惑，我强烈建议您了解文档中涵盖的 ADLS 的 RBAC 和 ACL 模型。另一个不错的起点是 Blue Granite 的博客。

管理访问

如上所述，对数据的访问是使用 ACL 在适当的文件夹和文件级别使用执行、读取和写入访问权限的组合来实现的。 Execute 仅在文件夹的上下文中使用，并且可以被认为是对该文件夹的搜索或列表权限。
最简单的入门方法是使用 Azure 存储资源管理器。导航到文件夹并选择管理访问权限。但是，在生产场景中，始终建议通过版本控制的脚本来管理权限。有关一些示例，请参见此处。
重要的是要了解，为了在一定深度访问（读取或写入）文件夹或文件，必须将执行权限分配给每个父文件夹，一直到文档中所述的根级别。换句话说，用户（在 AAD 直通的情况下）或服务主体 (SP) 将需要对指向该文件的文件夹层次结构中的每个文件夹的执行权限。

拒绝将 ACL 分配给个人或服务主体

使用 ADLS 时，可以通过 ACL 在目录和文件级别管理权限，但根据最佳实践，这些权限应分配给组而不是单个用户或服务主体。这有两个主要原因; i.) 如果有 1000 个文件，更改 ACL 可能需要时间来传播，并且 ii.) 每个文件或文件夹限制为 32 个 ACL 条目。这是一个基于 Unix 的一般限制，如果超出此限制，您将收到内部服务器错误，而不是明显的错误消息。请注意，每个 ACL 已经以四个标准条目（拥有用户、拥有组、掩码和其他）开始，因此您只剩下 28 个剩余条目可供您访问，如果您使用组，这应该绰绰有余......

“具有大量 ACL 条目的 ACL 往往变得更加难以管理。多个 ACL 条目通常表明应用程序设计不佳。在大多数此类情况下，更好地利用组而不是臃肿的 ACL 更有意义。”

同样重要的是权限继承的工作方式：

“......一个项目的权限存储在项目本身。换句话说，如果在创建子项之后设置权限，则无法从父项继承该项的权限。只有在创建子项之前对父项设置了默认权限时，才会继承权限。”

换句话说，默认权限应用于新的子文件夹和文件，因此如果需要将一组新权限递归地应用于现有文件，则需要编写脚本。有关 PowerShell 中的示例，请参见此处。
建议很明确 - 从长远来看，预先计划和分配 ACL 到组可以节省时间和痛苦。随着权限的发展，用户和服务主体可以在未来有效地从组中添加和删除。如果出于某种原因您决定不顾一切将服务主体直接添加到 ACL，那么请务必使用服务主体 ID 的对象 ID (OID)，而不是已注册 App ID 的 OID，如中所述常见问题解答。您可能希望考虑编写各种报告来监控和管理 ACL 分配，并将这些报告与存储分析日志交叉引用。

文件格式和文件大小

随着数据湖随着时间的推移而发展，Parquet 已成为湖中数据存储格式的最流行选择。根据场景或区域，它可能不是唯一选择的格式——事实上，Lake 的优点之一是能够以多种格式存储数据，尽管最好（不是必需的）坚持特定格式每个区域更多地从该区域的消费者的一致性的角度来看。
选择最合适的格式通常需要在存储成本、性能以及用于处理和使用湖中数据的工具之间进行权衡。工作负载的类型也可能影响决策，例如实时/流式传输、仅附加或 DML 繁重。
如前所述，由于读取/列表操作的增加，大量小文件 (kbs) 通常会导致性能欠佳，并可能导致更高的成本。

Azure Data Lake Storage Gen2 经过优化，可以更好地处理较大的文件。分析作业将以更低的成本运行得更快。

由于更短的计算（Spark 或数据工厂）时间以及优化的读取操作，成本得以降低。例如，大小大于 4 MB 的文件会导致每读取超过前 4 MB 的 4 MB 数据块的价格较低。例如，读取 16 MB 的单个文件比读取 4 个每个 4 MB 的文件便宜。在此处阅读有关 Data Lake gen2 存储成本的更多信息，特别是请参阅页面底部的常见问题解答部分。
使用 Spark 处理数据时，典型的指导是大约 64MB — 每个文件 1GB。在 Spark 社区中众所周知，数千个小文件（大小为 kb）是性能的噩梦。在原始区域中，这可能是一个挑战，特别是对于通常具有较小文件/消息的高速流数据。文件需要定期压缩/合并，或者对于那些使用 Databricks Delta Lake 格式的文件，使用 OPTIMIZE 甚至 AUTO OPTIMIZE 可以提供帮助。如果流通过事件中心路由，则捕获功能可用于根据时间或大小触发器将数据保留在 Avro 文件中。其他技术可能是将原始数据存储为压缩格式的列，例如 Parquet 或 Avro。
在非原始区域中，读取优化的柱状格式（例如 Parquet 和 Databricks Delta Lake 格式）是不错的选择。特别是在策划区域分析性能变得至关重要，谓词下推/文件跳过和列修剪的优势可以节省时间和成本。由于湖技术中缺乏类似 RDBMS 的索引，大数据优化是通过知道“不看哪里”来实现的。但是，如上所述，请注意过度分区，不要选择具有高基数的分区键。可以在此处和此处的博客中找到各种格式的比较。

总之，随着更大的数据量和更高的数据速度，文件格式将在摄取和分析性能中发挥关键作用。在更容易堆积较小文件的原始区域中，尤其是在物联网规模场景中，压缩将是另一个重要的考虑因素。将文件保留为 json 或 csv 等原始格式可能会导致性能或成本开销。以下是在原始层中面临这些挑战时需要考虑的一些选项：

考虑批量写入文件并使用具有良好压缩比的格式，如 Parquet，或使用写入优化的格式，如 Avro。
在 raw 和 cleaned 之间引入一个中间数据湖区域/层，它定期从 raw 中获取未压缩和/或小文件，并将它们压缩成这个新层中更大的压缩文件。如果需要提取或分析原始数据，这些过程可以针对此中间层而不是原始层更有效地运行。
使用生命周期管理归档原始数据以降低长期存储成本，而无需删除数据。

结论

没有一种万能的方法来设计和构建数据湖。有些人可能会通过利用更具成本效益的存储和数据处理技术（例如 ETL 卸载）来快速启动他们的数据湖。其他人可能希望花时间考虑他们自己的需求，包括当前和未来的摄取和消费模式、所涉及的角色、他们的安全和治理要求。为避免随着数据湖足迹的扩大而出现无法控制的混乱，后者需要在某个时候发生，但不应通过“分析瘫痪”无限期地阻碍进展。数据湖可以通过数据的民主化促进更加以数据为中心、数据驱动的文化，但这应该是一个组织范围的承诺，而不仅仅是一个 IT 驱动的项目，以实现长期成功。
祝您在数据湖之旅中一切顺利，并希望在下面的评论部分听到您的反馈和想法。虽然我已尽一切努力确保所提供的信息在撰写本文时是真实和准确的，但我的经验和研究是有限的，而且不断发展的技术和云服务会随着时间而改变。