在本文中，我们将探索 Azure 数据湖分析并使用 U-SQL 查询数据。

Azure 数据湖分析 (ADLA) 简介

Microsoft Azure 平台支持 Hadoop、HDInsight、数据湖等大数据。通常，传统数据仓库存储来自各种数据源的数据，将数据转换为单一格式并进行分析以做出决策。开发人员使用可能需要更长时间进行数据检索的复杂查询。组织正在增加他们在云基础架构中的足迹。它利用了云基础设施仓库解决方案，例如 Amazon RedShift、Azure Synapse Analytics（Azure SQL 数据仓库）或 AWS 雪花。云解决方案具有高度可扩展性和可靠性，可支持您的数据、查询处理和存储需求。

数据仓库遵循Extract-Transform-Load机制进行数据传输。

• 提取：从不同的数据源中提取数据
• 转换：将数据转换为特定格式
• 加载：将数据加载到预定义的数据仓库模式、表中

数据湖不需要严格的模式，并在分析之前将数据转换为单一格式。 它以原始格式存储数据，例如二进制、视频、图像、文本、文档、PDF、JSON。 它仅在需要时转换数据。 数据可以是结构化、半结构化和非结构化格式。

数据湖的一些有用功能是：

• 它存储原始数据（原始数据格式）
• 它没有任何预定义的schema
• 您可以在其中存储非结构化、半结构化和结构化
• 它可以处理 PB 甚至数百 PB 的数据量
• 数据湖在读取方法上遵循模式(schema )，根据需求对数据进行转换

概括地说，Azure 数据平台体系结构如下所示。 图片参考：微软文档

• 摄取：从各种数据源收集数据并以其原始格式存储到 Azure 数据湖中
• 存储：将数据存储到 Azure Data Lake Storage、AWS S3 或 Google 云存储
• 处理：将原始存储中的数据处理成兼容的格式
• 分析：使用存储和处理的数据执行数据分析。 您可以使用 Azure 数据湖分析 (ADLA)、HDInsight 或 Azure Databricks

原文：https://www.sqlshack.com/an-overview-of-azure-data-lake-analytics-and-u…

本文:https://jiagoushi.pro/node/1768

介绍

一开始，规划数据湖似乎是一项艰巨的任务——决定如何最好地构建数据湖、选择哪种文件格式、是拥有多个数据湖还是只有一个数据湖、如何保护和管理数据湖。并非所有这些都需要在第一天回答，有些可能通过反复试验来确定。构建数据湖没有明确的指南，每个场景在摄取、处理、消费和治理方面都是独一无二的。

在之前的博客中，我介绍了数据湖和 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 驱动的项目，以实现长期成功。

祝您在数据湖之旅中一切顺利，并希望在下面的评论部分听到您的反馈和想法。虽然我已尽一切努力确保所提供的信息在撰写本文时是真实和准确的，但我的经验和研究是有限的，而且不断发展的技术和云服务会随着时间而改变。

附录 — ADLS gen2 注意事项

虽然配额和限制将是一个重要的考虑因素，但其中一些不是固定的，Azure 存储产品团队将始终尽可能满足您对规模和吞吐量的要求。在撰写本文时，这里是已发布的配额和需要考虑的项目：

• 所有区域为 5 PiB。这些是默认限制，通常可以通过支持票提高。
• 每个存储帐户每秒的最大请求速率为 20,000。
• 入口速率 25 Gbps。
• 每个订阅 250 个存储帐户。
• 每个文件或文件夹的最大访问权限和默认 ACL 32。这是一个硬限制，因此 ACL 应该分配给组而不是单个用户。
• 在此处查看其他限制。请注意，一些默认（最大）限制或配额可能会通过支持请求增加。
• 支持 ADLS gen2 的 Azure 服务。
• 支持的 Blob 存储功能。
• 其他重要考虑因素。

请注意，限制、配额和功能在不断发展，因此建议您继续检查文档以获取更新。

原文：https://medium.com/microsoftazure/building-your-data-lake-on-adls-gen2-…

本文：https://jiagoushi.pro/node/1769

Azure Data Lake 刚刚全面上市，尤其是 Azure Data Lake Store 的管理似乎令人生畏，尤其是在处理大数据时。在这篇博客中，我将带您了解使用数据湖和大数据的风险和挑战。然后，我将带您了解我们为帮助最好地管理这些风险和挑战而创建的框架。

如果您需要了解什么是数据湖以及如何创建您的第一个 Azure Data Lake Store 和您的第一个 Azure Data Lake Analytics 作业，请随时关注这些链接。

大数据和数据湖的风险和挑战

大数据带来的挑战如下：

• 容量——庞大的数据量是否变得难以管理？
• 多样性——结构化表格？半结构化 JSON？完全非结构化的文本转储？我们通常可以使用仅包含其中一个的系统进行管理，但如果我们要处理一个巨大的混合体，它就会变得非常棘手
• 速度——数据输入的速度有多快？我们需要多快才能将它送到需要它的人手中？
• 准确性——当数据量不同、来源和结构不同以及它们到达湖的速度不同时，我们如何保持准确性和准确性？
• 同时管理所有四个是挑战的开始。

很容易将数据湖视为任何事物的倾倒场。微软的销售宣传正是如此——“存储便宜，存储一切！！”。我们倾向于同意——但如果数据完全不正确、不准确、过时或完全无法理解，那么它根本没有用，并且会让任何试图理解数据的人感到困惑。这实际上将创建一个没有人愿意进入的数据沼泽。糟糕的数据和管理不善的文件削弱了人们对湖泊作为信息来源的信任。倾倒是不好的。

还有数据淹没——因为数据量趋向于海量，而且速度只会随着时间的推移而增加，我们将看到越来越多的信息可以通过湖获得。到了那个时候，如果湖泊管理不善，那么用户将很难找到他们想要的东西。这些数据可能都是完全相关和准确的，但如果用户找不到他们需要的东西，那么湖本身就没有价值。从本质上讲，数据淹没是指数据量如此之大，以至于您无法找到其中的内容。

如果您忽略这些挑战，将湖泊视为垃圾场，您将污染您的湖泊，它将不再适合使用。

如果没有人使用数据湖，那将是一项毫无意义的努力，不值得维护。

每个人都需要共同努力，以确保湖泊保持清洁、管理和有利于数据潜水！

这些是我们在使用 Azure Data Lake 时面临的风险和挑战。但是我们如何管理它呢？

框架

我们把湖分成不同的部分。关键是湖中包含各种不同的数据——一些已经过清理并可供业务用户使用，一些是无法辨认的原始数据，需要在使用之前进行仔细分析。通过确保数据得到仔细管理，您可以立即了解数据的准备程度。

数据从左到右流动——更左边的区域表示直接从源系统输入数据的位置。水平部分描述了准备的级别——手动、流和批处理。

• 手工——又名实验室。这里的数据是使用临时脚本手动准备的。
• 流——这里的数据是半实时的，来自事件中心，并在通过流分析等特定于流的工具进行处理后登陆。一旦登陆，就没有进一步的数据处理——湖本质上是一个批处理工具。
• 批处理——这是更传统的数据处理，许多 BI 开发人员看到的那种“ETL”。我们有一个原始数据的登陆区域，一个过渡区域，在此区域中，数据被清理、验证、丰富和增强，并添加了额外的来源和计算，然后最终被放置在一个可供业务使用的精选区域中。

我们正在使用 Data Lake Store 的空白画布，并在顶部应用文件夹结构、文件管理流程和管理流程。

文件夹结构本身可以任意详细，我们自己遵循一个特定的结构：

原始数据区域是进入湖的任何文件的着陆点，每个数据源都有子文件夹。这允许轻松浏览 Lake 中的数据源，并确保我们不会两次收到相同的数据，即使我们在不同的系统中使用它也是如此。

然而，Enriched 和 Curated 层有特定的用途。我们不会在没有业务驱动的情况下获取数据并对其进行丰富/清理/处理，这不是我们为了好玩而做的事情。因此，我们可以为它分配一个项目或系统名称，此时它被组织到这些终端系统中。这意味着我们可以在 Enriched 中查看与 Curated 中相同的结构。

本质上，原始数据按来源分类，而丰富和策划的数据按目的地分类。

我们创建的框架或我们赋予它的过程没有什么复杂的，但是让每个人都了解它的意图和数据湖的一般用途是非常重要的。如果一个用户在添加数据时没有遵循流程，或者 ETL 开发人员没有清理测试文件，系统就会开始崩溃，我们就会屈服于我们一开始讨论的挑战。

总而言之，Azure Data Lake Store 中的结构是维持秩序的关键：

• 您需要强制执行和维护文件夹结构。
• 请记住，无论是使用非结构化数据还是表和 SQL，结构都是必要的
• 请记住，读取模式应用了临时结构——但如果你不知道你在看什么，这将很难做到！

原文：https://adatis.co.uk/Shaping-The-Lake-Data-Lake-Framework/

本文：https://jiagoushi.pro/shaping-lake-data-lake-framework

在这篇文章中，我们将介绍基于数据仓库和基于数据湖的云大数据解决方案之间的区别。 我们通过比较多种云环境中可用的两种流行技术来做到这一点：Databricks 和 Snowflake。

正如我们在上一篇文章中了解到的，数据分析平台可以分为多个阶段。上面，我们可以看到一张图片，大致了解了管道中 Snowflake 和 Databricks 的角色。在这里，我们可以将工具分类为处理（绿色）或存储（蓝色）。 Databricks 是一种处理工具，而 Snowflake 涵盖了处理和存储。另一方面，Delta Lake 是与 Databricks 相关的存储解决方案。我们稍后会介绍。

根据上一篇给出的定义，我们可以粗略的说Databricks是一个基于数据湖的工具，而Snowflake是一个基于数据仓库的工具。现在让我们更深入地研究这些工具。

Databricks 是具有数据仓库功能的数据湖工具

Databricks 是一个基于 Apache Spark 的处理工具，它为编程环境提供高度可自动扩展的计算能力。 Apache Spark 是基于编码的大数据处理的事实上的标准编程框架。

Databricks 计费本质上是基于使用情况的。您为使用的计算资源付费，仅此而已。原则上，Databricks 特别适合在管道的早期阶段处理数据，尤其是在青铜层和银层之间。它也可用于准备黄金层数据，但在为报告工具等提供数据方面并不是最好的。

最近，Databricks 已将其能力大幅扩展至传统数据仓库的方向。 Databricks 提供了现成的 SQL 查询接口和轻量级的可视化层。此外，Databricks 提供了一种数据库类型的表结构。数据库类型功能是专门使用 Delta 文件格式开发的。

Delta 文件格式是一种将数据库优势带入数据湖世界的方法。除其他外，该格式提供数据模式版本控制和数据库类型 ACID 事务。根据数据湖范式，文件格式本身是开放的，任何人都可以免费使用。

基于 Delta 格式和 Databricks 工具，该公司正在尝试为数据湖和数据仓库混合方法传播一种新颖的“Data Lakehouse”范式概念。

Snowflake 是一个借鉴数据湖范式的可扩展数据仓库

Snowflake 是专为云环境开发的可扩展数据仓库解决方案。 Snowflake 以专有文件格式将数据存储在云存储中。因此，根据数据仓库范式，数据只能通过 Snowflake 获得。除了计算资源外，您还需要为雪花文件格式的数据存储付费。但是，您还可以使用典型的数据仓库功能，例如可用的精细权限管理。

几年前，Snowflake 通过提供高度分布式和可扩展的计算能力扰乱了数据仓库市场。这是通过在数据仓库架构中完全分离存储和处理层来完成的。传统上，这一直是大数据世界中数据仓库解决方案的主要障碍。这是 Snowflake 向数据湖范式方向扩展其解决方案的方式之一。如今，它提供了用于实时数据摄取的高效工具等。

说 Snowflake 的成功给 Amazon Redshift 和 Azure Data Warehouse 开发带来了危机，这可能并不为过。后两种数据仓库解决方案的可扩展性明显受到更多限制：如果您想避免高额费用，则需要在小存储容量或慢处理之间进行选择。很多时候，很难找到合适的组合。因此，您通常会为您没有实际使用的储备资源支付大量资金。尽管如此，这两款产品都已采取措施解决这个问题。

结论：Databricks 和 Snowflake

在这篇文章中，我们讨论了两个非常流行的多云数据分析产品：Databricks 和 Snowflake。正如上一篇博文中所讨论的，我们从它们的背景范式的角度专门研究了它们。

我们注意到 Snowflake 在数据仓库领域有基础，而 Databricks 更面向数据湖。然而，两者都将其范围扩展到了其范式的典型限制之外。

这两种工具绝对可以单独使用来满足数据分析平台的需求。 Databricks 可以直接从存储中提供数据或将数据导出到数据集市。不需要单独的数据仓库。另一方面，可以将数据直接摄取到 Snowflake 进行处理、建模和提供。以我的经验，纯Snowflake解决方案更常见，可能是因为 Databricks 已经出现很久了。

然而，正如在上一篇文章中提到的，在一个平台上同时使用这两种产品可能是个好主意。图中描述了这种解决方案的故障，Databricks 读取和处理原始数据，Snowflake 负责管道的发布端。同样重要的是要注意 Databricks 和 Snowflake 正在合作以更好地集成产品。

总而言之，混合解决方案的未来似乎更加光明。

原文：https://www.tietoevry.com/en/blog/2021/09/data-lakes-and-warehouses-dat…

本文：https://jiagoushi.pro/data-lakes-and-warehouses-databricks-and-snowflake

• 数据湖漫游指南
  • ADLS Gen2 何时是您数据湖的正确选择？
  • 设计数据湖的关键考虑因素
  • 术语
  • 组织和管理数据湖中的数据
  • 我想要集中式还是联合式数据湖实施？
  • 如何组织我的数据？
    • 我如何管理对我的数据的访问？
    • 我选择什么数据格式？
    • 如何管理我的数据湖成本？
    • 如何监控我的数据湖？
  • 优化数据湖以获得更好的规模和性能
    • 文件大小和文件数
    • 文件格式
    • 分区方案
    • 使用查询加速
  • 推荐阅读
  • 问题、意见或反馈？

Azure Data Lake Storage Gen2 (ADLS Gen2) 是用于大数据分析的高度可扩展且经济高效的数据湖解决方案。随着我们继续与客户合作，利用 ADLS Gen2 从他们的数据中发掘关键洞察，我们已经确定了一些关键模式和注意事项，可帮助他们在大规模大数据平台架构中有效利用 ADLS Gen2。

本文档记录了我们在与客户合作的基础上学到的这些注意事项和最佳实践。就本文档而言，我们将重点介绍我们的大型企业客户在 Azure 上大量使用的现代数据仓库模式，包括我们的解决方案，例如 Azure Synapse Analytics。

我们将改进此文档以在未来的迭代中包含更多分析模式。

重要提示：请将此文档的内容视为指导和最佳实践，以帮助您做出架构和实施决策。这不是官方的 HOW-TO 文档。

ADLS Gen2 何时是您数据湖的正确选择？ #

企业数据湖旨在成为大数据平台中使用的非结构化、半结构化和结构化数据的中央存储库。企业数据湖的目标是消除数据孤岛（数据只能由组织的一部分访问）并促进单一存储层，以适应组织的各种数据需求有关选择正确的更多信息存储解决方案，请访问在 Azure 中选择大数据存储技术一文。

出现的一个常见问题是何时使用数据仓库与数据湖。我们敦促您将数据湖和数据仓库视为互补的解决方案，它们可以协同工作，帮助您从数据中获得关键见解。数据湖是存储来自各种来源的所有类型数据的存储库。自然形式的数据存储为原始数据，并在此原始数据上应用模式和转换，以根据业务试图回答的关键问题获得有价值的业务洞察力。数据仓库是高度结构化的模式化数据的存储，这些数据通常被组织和处理以获得非常具体的见解。例如。零售客户可以将过去 5 年的销售数据存储在数据湖中，此外，他们可以处理来自社交媒体的数据，从零售分析解决方案中提取消费和情报的新趋势，并利用所有这些作为输入一起生成一个数据集，可用于预测明年的销售目标。然后，他们可以将高度结构化的数据存储在数据仓库中，BI 分析师可以在其中构建目标销售预测。此外，他们可以使用数据湖中相同的销售数据和社交媒体趋势来构建智能机器学习模型，以在其网站上进行个性化推荐。

ADLS Gen2 是适用于大数据分析工作负载的企业级超大规模数据存储库。 ADLS Gen2 通过分层命名空间提供更快的性能和 Hadoop 兼容访问，通过细粒度访问控制和本机 AAD 集成降低成本和安全性。这适合作为专注于大数据分析场景的企业数据湖的选择——使用转换从非结构化数据中提取高价值的结构化数据、使用机器学习的高级分析或实时数据摄取和分析以获得快速洞察力。值得注意的是，我们已经看到客户对超大规模的定义有不同的定义——这取决于存储的数据、交易数量和交易吞吐量。当我们说超大规模时，我们通常指的是数 PB 的数据和数百 Gbps 的吞吐量——这种分析所涉及的挑战与吞吐量中的数百 GB 数据和几 Gbps 的事务非常不同。

设计数据湖的关键考虑因素#

当您在 ADLS Gen2 上构建企业数据湖时，了解您对关键用例的需求很重要，包括

1. 我在数据湖中存储了什么？
2. 我在数据湖中存储了多少数据？
3. 您在数据的哪一部分上运行分析工作负载？
4. 谁需要访问我的数据湖的哪些部分？
5. 我将在我的数据湖上运行哪些各种分析工作负载？
6. 分析工作负载有哪些不同的事务模式？
7. 我的工作预算是多少？

对于我们一直从客户那里听到的一些关键设计/架构问题，我们希望将本文档的其余部分固定在以下结构中。

• 有优缺点的可用选项
• 选择适合您的选项时要考虑的因素
• 适用时推荐的模式
• 您想要避免的反模式

为了最好地利用本文档，请确定您的关键场景和要求，并根据您的要求权衡我们的选项以决定您的方法。如果您无法选择完全适合您的场景的选项，我们建议您使用一些选项进行概念验证 (PoC)，让数据指导您的决策。

术语#

在我们讨论构建数据湖的最佳实践之前，熟悉我们将在使用 ADLS Gen2 构建数据湖的上下文中使用的各种术语非常重要。本文档假设您在 Azure 中有一个帐户。

• 资源：可通过 Azure 获得的可管理项目。虚拟机、存储帐户、VNET 是资源的示例。
• 订阅：Azure 订阅是一个逻辑实体，用于分离 Azure 资源的管理和财务（计费）逻辑。订阅与 Azure 资源的限制和配额相关联，您可以在此处阅读有关它们的信息。
• 资源组：用于容纳 Azure 解决方案所需资源的逻辑容器可以作为一个组一起管理。您可以在此处阅读有关资源组的更多信息。
• 存储帐户：包含所有 Azure 存储数据对象的 Azure 资源：blob、文件、队列、表和磁盘。您可以在此处阅读有关存储帐户的更多信息。就本文档而言，我们将重点介绍 ADLS Gen2 存储帐户——它本质上是一个启用了分层命名空间的 Azure Blob 存储帐户，您可以在此处阅读更多相关信息。
• 容器（也称为非 HNS 启用帐户的容器）：一个容器组织一组对象（或文件）。一个存储帐户对容器的数量没有限制，容器可以存储无限数量的文件夹和文件。有些属性可以应用于容器级别，例如 RBAC 和 SAS 键。
• 文件夹/目录：文件夹（也称为目录）组织一组对象（其他文件夹或文件）。一个文件夹下可以创建多少个文件夹或文件没有限制。文件夹还具有与之关联的访问控制列表 (ACL)，有两种类型的 ACL 与文件夹关联——访问 ACL 和默认 ACL，您可以在此处阅读有关它们的更多信息。
• 对象/文件：文件是保存可以读/写的数据的实体。一个文件有一个与之关联的访问控制列表。文件只有访问 ACL，没有默认 ACL。

组织和管理数据湖中的数据#

随着我们的企业客户制定他们的数据湖战略，ADLS Gen2 的关键价值主张之一是作为其所有分析场景的单一数据存储。请记住，这个单一数据存储是一个逻辑实体，根据设计考虑，它可以表现为单个 ADLS Gen2 帐户或多个帐户。一些客户拥有分析管道组件的端到端所有权，而其他客户则拥有一个中央团队/组织来管理数据湖的基础架构、运营和治理，同时为多个客户提供服务——无论是他们企业中的其他组织还是外部的其他客户到他们的企业。

在本节中，我们针对客户在设计企业数据湖时听到的一系列常见问题提出了我们的想法和建议。作为说明，我们将以大型零售客户 Contoso.com 为例，构建他们的数据湖策略以帮助处理各种预测分析场景。

我想要集中式还是联合式数据湖实施？ #

作为企业数据湖，您有两种可用的选择——要么将所有数据管理集中在一个组织内以满足您的分析需求，要么拥有一个联合模型，您的客户管理他们自己的数据湖，而集中式数据团队提供指导并管理数据湖的几个关键方面，例如安全性和数据治理。重要的是要记住，集中式和联合数据湖策略都可以使用一个存储帐户或多个存储帐户来实施。

客户问我们的一个常见问题是，他们是否可以在单个存储帐户中构建数据湖，或者他们是否需要多个存储帐户。虽然从技术上讲，单个 ADLS Gen2 可以解决您的业务需求，但客户选择多个存储帐户的原因有多种，包括但不限于本节其余部分中的以下场景。

关键考虑#

在决定要创建的存储帐户数时，以下注意事项有助于决定要预配的存储帐户数。

• 单个存储帐户使您能够管理一组控制平面管理操作，例如存储帐户中所有数据的 RBAC、防火墙设置、数据生命周期管理策略，同时允许您使用容器、文件和存储帐户上的文件夹。如果您想优化以简化管理，特别是如果您采用集中式数据湖策略，这将是一个值得考虑的好模型。
• 多个存储帐户使您能够在不同帐户之间隔离数据，以便可以对它们应用不同的管理策略或单独管理它们的计费/成本逻辑。如果您正在考虑采用联合数据湖策略，每个组织或业务部门都有自己的一组可管理性要求，那么此模型可能最适合您。

让我们将这些方面放在一些场景的上下文中。

覆盖全球的企业数据湖#

在全球市场和/或地理分布的组织的推动下，有些情况下，企业的分析场景将多个地理区域考虑在内。数据本身可以分为两大类。

• 可以在所有地区全球共享的数据——例如Contoso 正在尝试规划下一个财政年度的销售目标，并希望从各个地区获取销售数据。
• 需要隔离到一个区域的数据——例如Contoso 希望根据买家的个人资料和购买模式提供个性化的买家体验。鉴于这是客户数据，需要满足主权要求，因此数据不能离开该区域。

在这种情况下，客户将提供特定于区域的存储帐户来存储特定区域的数据并允许与其他区域共享特定数据。这里仍然有一个集中的逻辑数据湖，其中包含一组由多个存储帐户组成的中央基础设施管理、数据治理和其他操作。

客户或数据特定隔离#

存在企业数据湖服务于多个客户（内部/外部）场景的场景，这些场景可能会受到不同的要求——不同的查询模式和不同的访问要求。让我们以我们的 Contoso.com 为例，他们有分析方案来管理公司运营。在这种情况下，他们拥有各种数据源——员工数据、客户/活动数据和财务数据，这些数据受不同治理和访问规则的约束，也可能由公司内的不同组织管理。在这种情况下，他们可以选择为各种数据源创建不同的数据湖。

在另一种情况下，作为为多个客户提供服务的多租户分析平台的企业最终可能会为不同订阅中的客户提供单独的数据湖，以帮助确保客户数据及其相关的分析工作负载与其他客户隔离，以帮助管理他们的成本和计费模式。

建议#

 

• 为您的开发和生产环境创建不同的存储帐户（最好在不同的订阅中）。除了确保需要不同 SLA 的开发和生产环境之间有足够的隔离之外，这还有助于您有效地跟踪和优化管理和计费策略。
• 确定数据的不同逻辑集，并考虑以统一或隔离的方式管理它们的需求——这将有助于确定您的帐户边界。
• 从一个存储帐户开始您的设计方法，并考虑为什么需要多个存储帐户（隔离、基于区域的要求等）而不是相反的原因。
• 其他资源（例如 VM 核心、ADF 实例）也有订阅限制和配额——在设计数据湖时要考虑这些因素。

反模式#

谨防多重数据湖管理#

当您决定 ADLS Gen2 存储帐户的数量时，请确保针对您的消费模式进行优化。如果您不需要隔离并且您没有充分利用您的存储帐户的功能，您将承担管理多个帐户的开销，而没有有意义的投资回报。

来回复制数据#

当您拥有多个数据湖时，您需要谨慎对待的一件事是您是否以及如何跨多个帐户复制数据。这会产生一个管理问题，即真相的来源是什么以及它需要有多新鲜，并且还会消耗涉及来回复制数据的事务。如果您有一个合法的方案来复制您的数据，我们的路线图中有一些功能可以使此工作流程更容易。

可扩展性注释#

我们的客户问的一个常见问题是，单个存储帐户是否可以无限地继续扩展以满足他们的数据、事务和吞吐量需求。我们在 ADLS Gen2 中的目标是满足客户所需的极限。当您遇到需要真正存储大量数据（数 PB）并需要帐户支持真正大的事务和吞吐量模式（数万 TPS 和数百 Gbps 吞吐量）的场景时，我们确实要求)，通常通过 Databricks 或 HDInsight 进行分析处理需要 1000 个计算能力核心，请联系我们的产品组，以便我们可以计划适当地支持您的要求。

如何组织我的数据？ #

ADLS Gen2 帐户中的数据组织可以在容器、文件夹和文件的层次结构中按顺序完成，如我们上面所见。当我们与客户合作制定他们的数据湖策略时，一个非常常见的讨论点是他们如何最好地组织他们的数据。有多种方法可以在数据湖中组织数据，本节记录了许多构建数据平台的客户采用的通用方法。

该组织跟踪数据的生命周期，因为它通过源系统一直流向最终消费者——BI 分析师或数据科学家。例如，让我们跟随销售数据通过 Contoso.com 的数据分析平台的旅程。

例如，将原始数据视为自然状态下有水的湖泊/池塘，数据按原样摄取和存储，未经转换，丰富的数据是水库中的水，经过清洗并以可预测的状态存储（以我们的数据为例），策划的数据就像准备消费的瓶装水。工作区数据就像一个实验室，科学家可以在其中携带自己的数据进行测试。值得注意的是，虽然所有这些数据层都存在于单个逻辑数据湖中，但它们可能分布在不同的物理存储帐户中。在这些情况下，拥有 Metastore 有助于发现。

• 原始数据：这是来自源系统的数据。此数据按原样存储在数据湖中，并由分析引擎（例如 Spark）使用以执行清理和充实操作以生成精选数据。原始区域中的数据有时也存储为聚合数据集，例如在流场景的情况下，数据通过消息总线（如事件中心）摄取，然后通过实时处理引擎（如 Azure Stream 分析或 Spark Streaming）聚合，然后存储在数据湖中。根据您的业务需求，您可以选择保持数据原样（例如来自服务器的日志消息）或聚合它（例如实时流数据）。这一层数据由中央数据工程团队高度控制，很少被其他消费者访问。根据您企业的保留策略，此数据要么在保留策略要求的期限内按原样存储，要么在您认为数据不再使用时将其删除。例如。这将是从在其本地系统中运行的 Contoso 的销售管理工具中提取的原始销售数据。
• 丰富的数据：这一层数据是原始数据（按原样或聚合）具有定义模式的版本，并且数据经过清理、丰富（与其他来源），可供分析引擎使用以提取高价值数据。数据工程师生成这些数据集，并继续从这些数据集中提取高价值/精选数据。例如。这将是丰富的销售数据 - 确保销售数据被模式化，丰富了其他产品或库存信息，并为 Contoso 内部的不同业务部门分成多个数据集。
• 精选数据：这一层数据包含提供给数据消费者（BI 分析师和数据科学家）的高价值信息。该数据具有结构，可以按原样（例如数据科学笔记本）或通过数据仓库提供给消费者。该层中的数据资产通常受到高度管理和良好记录。例如。业务部门的高质量销售数据（即与其他需求预测信号（如社交媒体趋势模式）相关的丰富数据区域中的数据），用于预测分析以确定下一财政年度的销售预测。
• 工作区数据：除了数据工程团队从源头摄取的数据之外，数据的消费者还可以选择带来其他可能有价值的数据集。在这种情况下，数据平台可以为这些消费者分配工作空间，以便他们可以使用精选数据以及他们带来的其他数据集来生成有价值的见解。例如。数据科学团队正在尝试确定新地区的产品放置策略，他们可以带来其他数据集，例如客户人口统计数据和该地区其他类似产品的使用数据，并使用高价值的销售洞察数据来分析产品市场契合度和发行策略。
• 存档数据：这是您组织的数据“保险库” - 存储的数据主要符合保留策略，并且具有非常严格的用途，例如支持审计。您可以使用 ADLS Gen2 中的 Cool 和 Archive 层来存储此数据。您可以阅读有关我们的数据生命周期管理政策的更多信息，以确定适合您的计划。

关键考虑#

在决定数据结构时，请考虑数据本身的语义以及访问数据的消费者，以确定适合您的数据组织策略。

建议#

 

• 为不同的数据区域创建不同的文件夹或容器（更多关于文件夹与容器之间的注意事项） - 原始数据集、丰富数据集、策划数据集和工作区数据集。
• 在一个区域内，选择根据逻辑分隔在文件夹中组织数据，例如日期时间或业务单位或两者兼而有之。您可以在我们的最佳实践文档中找到有关目录布局的更多示例和场景。
  • 在设计文件夹结构时考虑分析使用模式。例如。如果您有一个 Spark 作业读取过去 3 个月内来自特定地区的产品的所有销售数据，那么理想的文件夹结构是 /enriched/product/region/timestamp。
  • 在决定文件夹结构时，请考虑您希望遵循的访问控制模型。
  • 下表提供了一个框架，供您考虑数据的不同区域以及具有常见模式的区域的相关管理。

考虑	原始数据	丰富的数据	策划的数据	工作空间数据
消费者	数据工程团队	数据工程团队，由数据科学家/BI分析师提供临时访问模式	数据工程师、BI分析师、数据科学家	数据科学家/BI分析师
访问控制	数据工程团队已锁定访问权限	完全控制数据工程团队，并对BI分析师/数据科学家具有读取权限	完全控制数据工程团队，对BI分析师/数据科学家具有读写权限	完全控制数据工程师、数据科学家/BI 分析师
数据生命周期管理	一旦生成了丰富的数据，就可以将其移动到较冷的存储层以管理成本。	较旧的数据可以移动到较冷的层。	较旧的数据可以移动到较冷的层。	虽然最终消费者可以控制这个工作区，但要确保有清理不必要数据的流程和策略——例如，使用基于策略的 DLM，数据可以很容易地建立起来。
文件夹结构和层次结构	文件夹结构以反映摄入模式。	文件夹结构反映组织，例如业务部门。	文件夹结构反映组织，例如业务部门。	文件夹结构反映了工作区所使用的团队。
实例	/raw/sensordata /raw/lobappdata /raw/userclickdata	/enriched/sales /enriched/ manufacturing	/curated/sales /curated/ manufacturing	/workspace/salesBI /workspace/ manufacturin datascience

• 我们的客户询问何时使用容器以及何时使用文件夹来组织数据的另一个常见问题。 虽然在更高级别，它们都用于数据的逻辑组织，但它们有一些关键区别。

考虑	容器	文件夹
等级	容器可以包含文件夹或文件。	文件夹可以包含其他文件夹或文件。
使用AAD的访问控制	在容器级别，可以使用RBAC设置粗粒度的访问控制。这些RBAC适用于容器内的所有数据。	在文件夹级别，可以使用ACL设置细粒度的访问控制。ACL仅适用于该文件夹（除非使用默认ACL，在这种情况下，在该文件夹下创建新文件/文件夹时会对其进行快照）。
非AAD访问控制	在容器级别，可以启用匿名访问（通过共享密钥）或设置特定于容器的SAS密钥。	文件夹不支持非AAD访问控制。

反模式#

不相关数据无限增长#

虽然 ADLS Gen2 存储不是很昂贵，并且允许您在存储帐户中存储大量数据，但即使您不需要整个数据语料库，生命周期管理策略的缺失也可能最终导致存储中数据的增长非常快为您的方案。我们看到这种数据增长的两种常见模式是：-

• 使用较新版本的数据刷新数据——客户通常会保留一些较旧版本的数据以供分析，当同一数据有一段时间刷新时，例如当上个月的客户参与数据在 30 天的滚动窗口中每天刷新时，您每天都会获得 30 天的参与数据，如果您没有适当的清理流程，您的数据可能会呈指数级增长。
• 工作区数据积累——在工作区数据区，您的数据平台的客户，即 BI 分析师或数据科学家可以带来他们自己的数据集 通常，我们已经看到，当未使用的数据是留在存储空间周围。

我如何管理对我的数据的访问？ #

ADLS Gen2 支持结合 RBAC 和 ACL 来管理数据访问的访问控制模型。您可以在此处找到有关访问控制的更多信息。除了使用 RBAC 和 ACL 使用 AAD 身份管理访问之外，ADLS Gen2 还支持使用 SAS 令牌和共享密钥来管理对 Gen2 帐户中数据的访问。

我们从客户那里听到的一个常见问题是何时使用 RBAC 以及何时使用 ACL 来管理对数据的访问。 RBAC 允许您将角色分配给安全主体（AAD 中的用户、组、服务主体或托管标识），并且这些角色与容器中数据的权限集相关联。 RBAC 可以帮助管理与控制平面操作（例如添加其他用户和分配角色、管理加密设置、防火墙规则等）或数据平面操作（例如创建容器、读写数据等）相关的角色。有关 RBAC 的更多信息，您可以阅读这篇文章。

RBAC 本质上仅限于顶级资源——ADLS Gen2 中的存储帐户或容器。您还可以在资源组或订阅级别跨资源应用 RBAC。 ACL 允许您将安全主体的一组特定权限管理到更窄的范围 - ADLS Gen2 中的文件或目录。有 2 种类型的 ACL——访问 ADL 控制对文件或目录的访问，默认 ACL 是为与目录关联的目录设置的 ACL 模板，这些 ACL 的快照由在下创建的任何子项继承那个目录。

关键考虑#

下表提供了如何使用 ACL 和 RBAC 来管理 ADLS Gen2 帐户中数据权限的快速概览——在较高级别，使用 RBAC 来管理粗粒度权限（适用于存储帐户或容器）并使用用于管理细粒度权限的 ACL（适用于文件和目录）。

Consideration	RBACs	ACLs
Scope	Storage accounts, containers. Cross resource RBACs at subscription or resource group level.	Files, directories
Limits	2000 RBACs in a subscription	32 ACLs (effectively 28 ACLs) per file, 32 ACLs (effectively 28 ACLs) per folder, default and access ACLs each
Supported levels of permission	Built-in RBACs or custom RBACs	ACL permissions

在容器级别使用 RBAC 作为数据访问控制的唯一机制时，请注意 2000 的限制，尤其是在您可能拥有大量容器的情况下。您可以在门户的任何访问控制 (IAM) 刀片中查看每个订阅的角色分配数量。

建议#

 

• 为对象（通常是我们在客户那里看到的目录中的目录）创建所需权限级别的安全组，并将它们添加到 ACL。对于要提供权限的特定安全主体，请将它们添加到安全组，而不是为它们创建特定的 ACL。遵循这种做法将帮助您最大限度地减少管理新身份访问的过程——如果您想将新身份递归添加到容器中的每个文件和文件夹，这将需要很长时间。让我们举一个例子，您的数据湖中有一个目录 /logs，其中包含来自服务器的日志数据。您可以通过 ADF 将数据摄取到此文件夹中，还可以让服务工程团队的特定用户上传日志并管理其他用户到此文件夹。此外，您还有各种 Databricks 集群分析日志。您将创建 /logs 目录并创建两个具有以下权限的 AAD 组 LogsWriter 和 LogsReader。
  • LogsWriter 添加到具有 rwx 权限的 /logs 文件夹的 ACL。
  • LogsReader 添加到具有 r-x 权限的 /logs 文件夹的 ACL。
  • ADF 的 SPN/MSI 以及用户和服务工程团队可以添加到 LogsWriter 组。
  • Databricks 的 SPN/MSI 将添加到 LogsReader 组。

我选择什么数据格式？ #

数据可能以多种格式到达您的数据湖帐户——人类可读的格式，如 JSON、CSV 或 XML 文件，压缩的二进制格式，如 .tar.gz 和各种大小——巨大的文件（几 TB），如从本地系统导出 SQL 表或从 IoT 解决方案导出大量小文件（几 KB），例如实时事件。虽然 ADLS Gen2 支持在不施加任何限制的情况下存储所有类型的数据，但最好考虑数据格式以最大限度地提高处理管道的效率并优化成本——您可以通过选择正确的格式和正确的文件大小来实现这两个目标。 Hadoop 有一组它支持的文件格式，用于优化存储和处理结构化数据。让我们看看一些常见的文件格式——Avro、Parquet 和 ORC。所有这些都是机器可读的二进制文件格式，提供压缩来管理文件大小，并且本质上是自描述的，文件中嵌入了模式。格式之间的区别在于数据的存储方式——Avro 以基于行的格式存储数据，而 Parquet 和 ORC 格式以列格式存储数据。

关键考虑#

 

• Avro 文件格式适用于 I/O 模式更重的写入或查询模式倾向于完整检索多行记录。例如。 Avro 格式受到消息总线的青睐，例如 Event Hub 或 Kafka 连续写入多个事件/消息。
• 当 I/O 模式读取量更大和/或查询模式专注于记录中的列的子集时，Parquet 和 ORC 文件格式受到青睐——其中可以优化读取事务以检索特定列而不是读取整个记录。

如何管理我的数据湖成本？ #

ADLS Gen2 为您的分析场景提供数据湖存储，目标是降低您的总拥有成本。可以在此处找到 ADLS Gen2 的定价。由于我们的企业客户满足多个组织的需求，包括中央数据湖上的分析用例，他们的数据和交易往往会急剧增加。由于很少或没有集中控制，相关成本也会增加。本部分提供了可用于管理和优化数据湖成本的关键注意事项。

关键考虑#

 

• ADLS Gen2 提供策略管理，您可以使用它来利用存储在您的 Gen2 帐户中的数据的生命周期。您可以在此处阅读有关这些政策的更多信息。例如。如果您的组织有保留数据 5 年的保留策略要求，您可以设置策略以在数据 5 年未修改时自动删除数据。如果您的分析方案主要对上个月摄取的数据进行操作，您可以将早于该月的数据移动到较低的层（冷层或存档层），这些层的数据存储成本较低。请注意，较低层的静态数据价格较低，但交易策略较高，因此如果您希望频繁处理数据，请不要将数据移动到较低层。

• 确保您为您的帐户选择了正确的复制选项，您可以阅读数据冗余文章以了解有关您的选项的更多信息。例如。虽然 GRS 账户确保您的数据跨多个区域复制，但它的成本也高于 LRS 账户（数据在同一数据中心复制）。当您拥有生产环境时，GRS 等复制选项对于通过高可用性和灾难恢复确保业务连续性非常有价值。但是，LRS 帐户可能足以满足您的开发环境。
• 正如您从 ADLS Gen2 的定价页面中看到的，您的读写交易按 4 MB 的增量计费。例如。如果您执行 10,000 次读取操作，并且每次读取的文件大小为 16 MB，则您需要为 40,000 次交易付费。当您在事务中读取几 KB 的数据时，您仍需为 4 MB 的事务付费。优化单个事务中的更多数据，即优化事务中的更高吞吐量不仅可以节省成本，还可以极大地提高您的性能。

如何监控我的数据湖？ #

了解您的数据湖的使用方式及其执行方式是操作您的服务并确保它可供使用其中包含的数据的任何工作负载使用的关键组成部分。这包括：

• 能够根据频繁操作来审计您的数据湖
• 了解关键性能指标，例如高延迟的操作
• 了解常见错误、导致错误的操作以及导致服务端节流的操作

关键考虑#

 

数据湖的所有遥测数据均可通过 Azure Monitor 中的 Azure 存储日志获得。 Azure Monitor 中的 Azure 存储日志是 Azure 存储的一项新预览功能，它允许您的存储帐户与 Log Analytics、事件中心以及使用标准诊断设置将日志存档到另一个存储帐户之间的直接集成。可以在 Azure 存储监视数据参考中找到指标和资源日志的完整列表及其关联架构的参考。

• 在考虑访问方式时，选择将 Azure 存储日志中的日志存储在何处变得很重要：
  • 如果要近乎实时地访问日志并能够将日志中的事件与来自 Azure Monitor 的其他指标相关联，则可以将日志存储在 Log Analytics 工作区中。这允许您使用 KQL 和作者查询来查询您的日志，这些查询枚举您工作区中的 StorageBlobLogs 表。
  • 如果要存储日志以用于近实时查询和长期保留，可以配置诊断设置以将日志发送到 Log Analytics 工作区和存储帐户。
  • 如果您想通过另一个查询引擎（例如 Splunk）访问您的日志，您可以配置您的诊断设置以将日志发送到事件中心并将日志从事件中心摄取到您选择的目的地。
• 可以通过 Azure 门户、PowerShell、Azure CLI 和 Azure 资源管理器模板启用 Azure Monitor 中的 Azure 存储日志。对于大规模部署，可以使用 Azure Policy 并完全支持修复任务。有关更多详细信息，请参阅：
  • Azure/社区政策
  • ciphertxt/AzureStoragePolicy

Azure Monitor 中 Azure 存储日志的常见 KQL 查询

以下查询可用于深入了解数据湖的性能和健康状况：

• Frequent operations

  StorageBlobLogs
  | where TimeGenerated > ago(3d)
  | summarize count() by OperationName
  | sort by count_ desc
  | render piechart

• High latency operations

  StorageBlobLogs
  | where TimeGenerated > ago(3d)
  | top 10 by DurationMs desc
  | project TimeGenerated, OperationName, DurationMs, ServerLatencyMs, 
  ClientLatencyMs = DurationMs - ServerLatencyMs
  

• Operations causing the most errors

    StorageBlobLogs
  | where TimeGenerated > ago(3d) and StatusText !contains "Success"
  | summarize count() by OperationName
  | top 10 by count_ desc

 

Azure Monitor 中 Azure 存储日志的所有内置查询的列表可在 GitHub 上的 Azure Montior 社区的 Azure 服务/存储帐户/查询文件夹中找到。

优化您的数据湖以获得更好的规模和性能#

正在建设中，寻求贡献

在本节中，我们将讨论如何优化数据湖存储以提高分析管道中的性能。在本节中，我们将重点介绍帮助您优化存储事务的基本原则。为确保我们拥有正确的上下文，没有优化数据湖的灵丹妙药或 12 步流程，因为很多考虑因素取决于您尝试解决的特定用途和业务问题。但是，当我们谈论优化数据湖以提高性能、可扩展性甚至成本时，归结为两个关键因素：-

• 优化高吞吐量 - 目标是每个事务至少获得几 MB（越高越好）。
• 优化数据访问模式——减少不必要的文件扫描，只读取您需要读取的数据。

作为优化的先决条件，了解有关事务配置文件和数据组织的更多信息非常重要。鉴于分析场景的不同性质，优化取决于您的分析管道、存储 I/O 模式和您操作的数据集，特别是数据湖的以下方面。

请注意，我们讨论的场景主要侧重于优化 ADLS Gen2 性能。除了存储性能考虑之外，分析管道的整体性能还会有特定于分析引擎的考虑，我们与 Azure 上的分析产品（如 Azure Synapse Analytics、HDInsight 和 Azure Databricks）的合作关系确保我们专注于打造整体体验更好的。同时，虽然我们以特定引擎为例，但请注意，这些示例主要讨论存储性能。

文件大小和文件数量#

分析引擎（您的摄取或数据处理管道）会为其读取的每个文件（与列出、检查访问和其他元数据操作相关）产生开销，而过多的小文件会对您的整体工作的性能产生负面影响。此外，当您的文件太小（在 KB 范围内）时，您通过 I/O 操作实现的吞吐量也很低，需要更多的 I/O 来获取您想要的数据。通常，最佳做法是将数据组织成更大的文件（目标至少为 100 MB 或更多）以获得更好的性能。

在很多情况下，如果您的原始数据（来自各种来源）本身并不大，您可以使用以下选项来确保您的分析引擎所操作的数据集仍然使用大文件进行优化。

• 在您的分析管道中添加数据处理层，以将多个小文件中的数据合并为一个大文件。您还可以利用这个机会以读取优化的格式（例如 Parquet）存储数据，以便进行下游处理。
• 在处理实时数据的情况下，您可以将实时流引擎（例如 Azure Stream Analytics 或 Spark Streaming）与消息代理（例如事件中心或 Apache Kafka）结合使用，以将您的数据存储为更大的文件。

文件格式#

正如我们已经讨论过的，优化您的存储 I/O 模式可以在很大程度上使您的分析管道的整体性能受益。值得一提的是，选择正确的文件格式不仅可以提供更好的性能，还可以降低数据存储成本。 Parquet 是一种非常流行的数据格式，值得为您的大数据分析管道进行探索。

Apache Parquet 是一种开源文件格式，针对读取繁重的分析管道进行了优化。 Parquet 的列式存储结构让您可以跳过不相关的数据，从而提高查询效率。这种跳过的能力还会导致只将您想要的数据从存储发送到分析引擎，从而降低成本并提高性能。此外，由于相似的数据类型（对于一列）存储在一起，与以文本文件格式存储相同数据相比，Parquet 有助于高效的数据压缩和编码方案，从而降低数据存储成本。

Azure Synapse Analytics、Azure Databricks 和 Azure 数据工厂等服务内置了本机功能，可以利用 Parquet 文件格式。

分区方案#

有效的数据分区方案可以提高分析管道的性能，还可以降低查询产生的总体事务成本。简单来说，分区是一种通过将具有相似属性的数据集分组到一个存储实体（例如文件夹）中来组织数据的方法。当您的数据处理管道查询具有相似属性的数据（例如过去 12 小时内的所有数据）时，分区方案（在这种情况下，由 datetime 完成）让您跳过不相关的数据，只寻找那些你要。

让我们以 Contoso 的 IoT 场景为例，其中数据从各种传感器实时摄取到数据湖中。现在，您有多种存储数据的选项，包括（但不限于）下面列出的选项：

• Option 1 - /<sensorid>/<datetime>/<temperature>, <sensorid>/<datetime>/<pressure>, <sensorid>/<datetime>/<humidity>
• Option 2 - /<datetime>/<sensorid>/<temperature>, /<datetime>/<sensorid>/<pressure>, /datetime>/<sensorid>/<humidity>
• Option 3 - <temperature>/<datetime>/<sensorid>, <pressure>/<datetime>/<sensorid>, <humidity>/<datetime>/<sensorid>

如果高优先级方案是根据传感器发送的值了解传感器的健康状况以确保传感器正常工作，那么您将每隔一小时左右运行一次分析管道，以对来自特定传感器的数据与来自其他传感器的数据进行三角测量以确保它们正常工作。在这种情况下，选项 2 将是组织数据的最佳方式。相反，如果您的高优先级方案是根据传感器数据了解该地区的天气模式以确保您需要采取哪些补救措施，您将定期运行分析管道，以根据该地区的传感器数据评估天气。在这种情况下，您可能希望通过传感器ID 上的日期和属性来优化组织。

Apache Spark 等开源计算框架为您可以在大数据应用程序中利用的分区方案提供本机支持。

使用查询加速 #

Azure Data Lake Storage 有一项名为 Query Acceleration 的功能，可在预览版中使用，旨在优化性能的同时降低成本。查询加速允许您通过指定更多谓词（认为这些谓词类似于您将在 SQL 查询的 WHERE 子句中提供的条件）和列投影（认为这些列作为您将在 SQL 查询的 SELECT 语句中指定的列）在非结构化数据上。

除了通过过滤查询使用的特定数据来提高性能外，查询加速还通过优化传输的数据来降低分析管道的整体成本，从而降低整体存储交易成本，并节省您的计算资源成本 否则，您本来可以阅读整个数据集并过滤所需的数据子集。

Recommended reading #

• Azure Databricks – Best Practices
• Use Azure Data Factory to migrate data from an on-premises Hadoop cluster to ADLS Gen2(Azure Storage)
• Use Azure Data Factory to migrate data from an AWS S3 to ADLS Gen2(Azure Storage)
• Securing access to ADLS Gen2 from Azure Databricks
• Understanding access control and data lake configurations in ADLS Gen2

原文：https://azure.github.io/Storage/docs/analytics/hitchhikers-guide-to-the…

本文：https://jiagoushi.pro/node/1752