使用 Azure Data Lake Storage 的最佳做法

本文提供了最佳做法指南，可帮助你优化性能、降低成本并保护启用了 Data Lake Storage 的 Azure 存储帐户。

查找文档

Azure Data Lake Storage 不是专用的服务或帐户类型。 它是一组支持高吞吐量分析工作负载的功能。 Data Lake Storage 文档提供了有关使用这些功能的最佳做法和指导。 有关帐户管理的所有其他方面（例如设置网络安全、设计高可用性和灾难恢复）的信息，请参阅 Blob 存储文档的内容。

评估功能支持和已知问题

将帐户配置为使用 Blob 存储功能时，请使用以下模式。

1. 查看 Azure 存储帐户中的 Blob 存储功能支持一文，以确定帐户是否完全支持某项功能。 在启用了 Data Lake Storage 的帐户中，有些功能还不支持或只部分支持。 功能支持始终在扩展，因此请确保定期查看本文中的更新。

2. 查看《Azure Data Lake Storage 的已知问题》一文，了解你打算使用的功能是否存在任何限制或特殊指导。

3. 查阅功能相关文章，查找任何专门针对已启用 Data Lake Storage 的账户的指导。

理解文档中使用的术语

在两个内容集之间移动时，你会注意到术语有一些细微的差别。 例如，Blob 存储文档中介绍的内容使用术语 blob，而不是 文件。 严格来说，导入到存储账户中的文件会成为你账户中的 Blob 对象。 因此，该术语是正确的。 但是，如果你已经习惯了file这一术语，那么blob这个术语可能会让你感到困惑。 你还会看到术语容器被用来指代文件系统。 请将这些术语视为同义词。

考虑高级版

如果工作负荷需要低一致性延迟或每秒需要大量输入输出操作（IOPS），请考虑使用高级块 Blob 存储帐户。 这种类型的帐户通过高性能硬件提供数据。 数据存储在已针对低延迟进行优化的固态硬盘 (SSD) 上。 与传统的机械硬盘相比，SSD 提供更高的吞吐量。 高级性能的存储成本更高，但事务成本更低。 因此，如果你的工作负载会产生大量事务操作，那么高级性能块 Blob 存储帐户可能更具成本效益。

如果你的存储帐户将用于分析，我们强烈建议你将 Azure Data Lake Storage 与高级块 blob 存储帐户结合使用。 将高级块 blob 存储帐户与已启用 Data Lake Storage 的帐户一起使用的这一组合称为 Azure Data Lake Storage 的高级层。

针对数据摄取进行优化

从源系统引入数据时，源硬件、源网络硬件或与存储帐户的网络连接可能会造成瓶颈。

源硬件

无论是在Azure中使用本地计算机还是虚拟机（VM），请仔细选择适当的硬件。 对于磁盘硬件，请考虑使用固态硬盘（SSD）并选取具有更快轴的磁盘硬件。 对于网络硬件，尽可能使用最快的网络接口控制器（NIC）。 在 Azure 中，请使用 Azure D14 VM，其磁盘和网络硬件配置具备足够强大的性能。

与存储帐户的网络连接

源数据和存储帐户之间的网络连接有时可能会造成瓶颈。 当源数据位于本地部署环境中时，请考虑使用 Azure ExpressRoute 这样的专用连接。 如果源数据位于 Azure 中，则当数据与启用了 Data Lake Storage 的帐户位于同一 Azure 区域时，性能最佳。

配置数据引入工具，实现最大并行化

若要获得最佳性能，请通过尽可能多地并行执行读取和写入来使用所有可用的吞吐量。

下表汇总了几个热门引入工具的关键设置。

您的账户可扩展，能够为各种分析场景提供所需的吞吐量。 默认情况下，启用了 Data Lake Storage 的帐户在其默认配置中提供足够的吞吐量，以满足各种使用案例的需求。 如果遇到默认限制，请联系Azure支持部门。

结构数据集

请考虑预先规划数据的结构。 文件格式、文件大小和目录结构都可能影响性能和成本。

文件格式

可以采用各种格式引入数据。 数据可以以人工可读格式（如 JSON、CSV 或 XML）或压缩的二进制格式（例如 .tar.gz）显示。 数据可以有各种大小。 数据可由数个大型文件（几 TB）组成，例如从本地系统导出的 SQL 表的数据。 数据也可以大量小文件（几 KB）的形式提供，例如来自物联网 (IoT) 解决方案中实时事件的数据。 可以通过选择适当的文件格式和文件大小来优化效率和成本。

Hadoop 支持一组已针对存储和处理结构化数据进行优化的文件格式。 一些常见的格式包括 Avro、Parquet 和 Optimized Row Columnar（ORC）格式。 所有这些格式都是计算机可读的二进制文件格式。 数据经过压缩，有助于你管理文件大小。 这些格式在每个文件中嵌入一个架构，使得它们成为自描述文件。 这些格式的区别在于数据的存储方式。 Avro 以基于行的格式存储数据，Parquet 和 ORC 则以纵栏格式存储数据。

当 I/O 模式更偏向写入密集型，或者查询模式更适合按完整记录检索多行数据时，请使用 Avro 文件格式。 例如，Avro 格式很适合与 Event Hubs 或 Kafka 这类可连续写入多个事件或消息的消息总线配合使用。

当 I/O 模式以读取为主，或者查询模式侧重于记录中的部分列时，请使用 Parquet 和 ORC 文件格式。 可对读取事务进行优化，只检索特定列，而不是读取整条记录。

Apache Parquet 是一种开源文件格式，专为读取密集型分析处理流水线而优化。 Parquet 的列式存储结构允许跳过不相关的数据。 查询效率将大幅提高，因为它们可以缩小从存储发送到分析引擎的数据的范围。 此外，由于类似的数据类型（适用于列）将一起存储，Parquet 支持高效的数据压缩和编码方案，这可以降低数据存储成本。 Azure Synapse Analytics、Azure Databricks 和 Azure 数据工厂 等服务具有可利用 Parquet 文件格式的原生功能。

文件大小

文件越大，性能越好，成本也更低。

通常，HDInsight 等分析引擎在处理每个文件时都会产生开销，这涉及到列出内容、检查访问权限和执行各种元数据操作等任务。 如果将数据存储为多个小型文件，则此选项可能会对性能产生负面影响。 通常可将数据组织成较大的文件（大小为 256 MB 到 100 GB），以获得更好的性能。 某些引擎和应用程序可能会在高效处理大于 100 GB 的文件方面遇到问题。

增加文件大小还可以降低事务成本。 读取和写入操作按 4 MB 的增量计费，因此，无论文件包含 4 MB 还是只有几 KB 的数据，都会收取操作费用。 有关定价信息，请参阅 Azure Data Lake Storage 定价。

有时，数据管道对原始数据（含有多个小文件）的控制有限。 通常，系统应该有某种过程将小文件聚合为较大的文件，供下游应用程序使用。 如果要实时处理数据，则可以将实时流式处理引擎（如Azure 流分析或 Spark 流式处理）与消息中转站（如事件中心或 Apache Kafka）一起使用，以较大文件的形式存储数据。 将小文件聚合为较大文件时，请考虑以读取优化格式（例如 Apache Parquet）保存这些大文件，供下游处理。

目录结构

每个工作负荷对数据的使用方式有不同的要求。 但是，在使用物联网（IoT）、批处理方案或针对时序数据进行优化时，请考虑这些常见布局。

IoT 结构

在 IoT 工作负载中，可能会引入大量数据，这些数据跨越许多产品、设备、组织和客户。 预先规划目录布局，以便于数据组织、保障安全，并提高下游使用者处理数据的效率。 一个可供参考的一般模板可以采用以下布局：

• {Region}/{SubjectMatter（s）}/{yyyy}/{mm}/{dd}/{hh}/

例如，在英国，飞机引擎的着陆遥测数据可能看起来像以下结构：

• UK/Planes/BA1293/Engine1/2017/08/11/12/

在此示例中，通过将日期放在目录结构的末尾，你可以使用 ACL 更轻松地保护区域和主题，使其仅供特定用户和组访问。 如果将数据结构放在开头，则保护这些区域和主题会困难得多。 例如，如果你只想提供对英国数据或特定航班的访问，则需要针对每个小时目录下的大量目录应用单独的权限。 随着时间的推移，此结构还会导致目录数量呈指数级增加。

批处理作业结构

批处理中常用的方法是将数据放入“in”目录。 然后，当数据处理完以后，再将新数据置于“out”目录中，供下游进程使用。 有的作业需要对单个文件进行处理，但可能不需要对大型数据集进行大规模并行处理。对于这种作业，有时会使用此目录结构。 与上面建议的 IoT 结构一样，好的目录结构会设置父级目录，用于存储区域和主题之类的内容（例如，组织、产品或制造者）。 考虑在结构中添加日期和时间，以便更好地在处理过程中进行组织、筛选式搜索，增强安全性并提高自动化程度。 日期结构的粒度级别取决于上传或处理数据的时间间隔，例如每小时、每天甚至每月。

有时候，数据损坏或格式异常会导致文件处理失败。 在这种情况下，目录结构中增设一个 /bad 文件夹可能会有所帮助，用于将文件移至其中以便进一步检查。 批处理作业还可能负责上报这些问题文件或发出相关通知，以便进行人工干预。 请考虑以下模板结构：

• {Region}/{SubjectMatter（s）}/In/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter（s）}/Out/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter（s）}/Bad/{yyyy}/{mm}/{dd}/{hh}/

例如，一家市场营销公司每天都会收到其北美客户发送的客户更新信息数据摘录。 该数据在处理前和处理后可能看起来像以下片段：

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

在将批量数据直接写入 Hive 或传统 SQL 数据库的常见情况下，不需要 in 或 out 目录，因为输出本身已经写入 Hive 表或外部数据库对应的单独文件夹中。 例如，每天从客户处提取的数据会进入各自对应的目录中。 然后，Azure 数据工厂、Apache Oozie 或 Apache Airflow 等服务会触发每日 Hive 或 Spark 作业来处理数据并将其写入 Hive 表。

时序数据结构

对于 Hive 工作负载，对时序数据进行分区修剪将有助于某些查询只读取一部分数据，从而提高性能。

引入时序数据的管道通常使用文件和文件夹的结构化命名来放置其文件。 下面是按日期构建的数据的常见示例：

/DataSet/YYYY/MM/DD/datafile_YYYY_MM_DD.tsv

请注意，日期/时间信息同时显示为文件夹和文件名。

对于日期和时间，以下是一种常见格式。

/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

同样，选择的文件夹和文件组织方式应针对更大的文件大小和每个文件夹中合理的文件数进行优化。

设置安全性

请首先查看有关 Blob 存储的安全性建议一文中的建议。 你可以找到有关如何防止数据意外或恶意删除、保护防火墙后面的数据以及使用Microsoft Entra ID作为标识管理基础的最佳做法指南。

然后，查看《Azure Data Lake Storage 中的访问控制模型》一文，了解特定于已启用 Data Lake Storage 的帐户的指导。 本文将帮助你了解如何使用 Azure 基于角色的访问控制 (Azure RBAC) 角色和访问控制列表 (ACL)，对分层文件系统中的目录和文件强制执行安全权限。

引入、处理和分析

可以从许多不同的源和许多不同的方式将数据引入到启用了Data Lake Storage的帐户中。

例如，可以从 HDInsight 和 Hadoop 群集引入大型数据集，也可以引入小型临时数据集以便为应用程序制作原型。 可以引入各种源生成的流数据，例如应用程序、设备和传感器。 对于这种类型的数据，请使用工具实时按事件捕获和处理数据，然后将事件批量写入帐户。 还可以引入包含页面请求历史记录等信息的 Web 服务器日志。 对于日志数据，请考虑编写自定义脚本或应用程序来上传这些脚本，以便你可以灵活地将数据上传组件包含在更大的大数据应用程序中。

数据在帐户中可用后，可以对该数据运行分析，创建可视化效果，甚至将数据下载到本地计算机或其他存储库（例如 Azure SQL 数据库或 SQL Server 实例）。

下表推荐了可用于引入、分析、可视化和下载数据的工具。 使用此表中的链接可以找到有关如何配置和使用每个工具的指导。

监控遥测数据

监控服务的使用情况和性能是服务运维的重要组成部分。 遥测示例包括频繁的操作、延迟较高的操作或导致服务端限制的操作。

可以通过Azure Monitor中的Azure 存储日志访问存储帐户的所有遥测数据。 此功能将存储帐户与 Log Analytics 和事件中心集成，同时允许将日志存档到另一个存储帐户。 若要查看指标和资源日志及其关联架构的完整列表，请参阅Azure 存储监视数据参考。

选择存储日志的位置取决于计划访问日志的方式。 例如，如果要近乎实时地访问日志，并且能够将日志中的事件与其他Azure Monitor指标相关联，请将日志存储在Log Analytics工作区中。 然后，使用 KQL 和创建者查询来查询日志，这些查询枚举了工作区中的 StorageBlobLogs 表。

如果要存储日志以便进行准实时查询和长期保留，请将诊断设置配置为将日志同时发送到Log Analytics工作区和存储帐户。

如果要通过另一个查询引擎（如 Splunk）访问日志，请将诊断设置配置为将日志发送到事件中心，并将日志从事件中心引入到所选目标。

可以通过Azure门户、PowerShell、Azure CLI和Azure 资源管理器模板在Azure Monitor中启用Azure 存储日志。 对于大规模部署，请使用Azure Policy，完全支持修正任务。 有关详细信息，请参阅 ciphertxt/AzureStoragePolicy。

另请参阅

• Azure Data Lake Storage 中的访问控制模型
• Data Lake 漫游指南
• Azure Data Lake Storage 概述