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

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（适用于文件和目录）。

在容器级别使用 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 语句中指定的列）在非结构化数据上。

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