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

在 Azure AI 搜索中为大型数据集编制索引

注意

Azure AI 搜索可通过Azure门户、REST API 和Azure SDK获取。 它也是 Foundry IQ 的基础；Foundry IQ 是一个托管式知识层，可将企业内容转化为供 Microsoft Foundry 门户中的智能体使用的、可复用且具备权限感知能力的知识库。

如果需要在搜索解决方案中为大型或复杂数据集编制索引，本文将探讨在 Azure AI 搜索中应对长时间运行进程的策略。

这些策略假定你熟悉两种导入数据的基本方法：将数据推送到索引，或使用搜索索引器从支持的数据源拉取数据。 如果你的场景涉及计算密集型 AI 扩充，则需要使用索引器，因为索引器的技能依赖性很强。

本文补充了提高性能的提示，其中提供了有关索引和查询设计的最佳做法。 设计良好的索引（仅包含所需的字段和属性）是大规模索引编制的重要先决条件。

使用在 2024 年 4 月 3 日之后创建的搜索服务，以获得每个分区更大的存储容量。 还可以 升级较旧的服务，以便从更高的分区存储中受益。

注意

本文中所述的策略假定针对单个大型数据源。 如果解决方案需要从多个数据源编制索引，请参阅在 Azure AI 搜索中为多个数据源编制索引，了解建议的方法。

使用推送 API 为数据编制索引

推送 API（例如文档索引 REST API 或 IndexDocuments 方法 (Azure SDK for .NET)）是 Azure AI 搜索中最常见的索引形式。 对于使用推送 API 的解决方案，长期运行的索引策略具有以下一个或两个组件：

  • 批量处理文档
  • 管理线程

每次请求批量处理多个文档

为大量数据编制索引的一种简单机制是在单个请求中提交多个文档或记录。 只要整个有效负载小于 16 MB，则请求就可以在一个批量上传操作中最多处理 1,000 个文档。 无论是在 .NET SDK 中使用文档索引 REST API 还是 IndexDocuments 方法，这些限制都适用。 不管使用什么 API，都可以在每个请求的正文中打包 1,000 个文档。

批处理文档可显著缩短处理大量数据所需的时间。 确定数据的最佳批大小是优化索引编制速度的关键。 影响最佳批大小的两个主要因素是：

  • 索引的架构
  • 数据的大小

因为最佳批大小取决于你的索引和数据，所以最好的方法是测试不同的批大小，以确定可为你的方案实现最快索引编制速度的批大小。 有关使用 .NET SDK 测试批大小的示例代码，请参阅教程：使用推送 API 优化索引编制。

管理线程和重试策略

索引器具有内置的线程管理，但在使用推送 API 时，应用程序代码需要管理线程。 请确保有足够的线程来充分利用可用容量，尤其是在最近 升级服务、 切换到更高的定价层或 增加的分区时。

  1. 增加客户端代码中的并发线程数量。

  2. 当你增加对搜索服务的请求数量时，可能会遇到 HTTP 状态代码，这些代码表明请求未完全成功。 在编制索引期间，有两个常见的 HTTP 状态代码：

    • 503 服务不可用：此错误表示系统负载过重，当前无法处理请求。

    • 207 多状态：此错误意味着某些文档成功，但至少一个文档失败。

  3. 为了处理故障，应使用指数退避充实策略来重试请求。

Azure .NET SDK 会自动重试 503s 和其他失败的请求，但要重试 207s，你需要实现自己的逻辑。 还可以使用 Polly 等开源工具来实现重试策略。

使用索引器和拉取 API

索引器 提供多个对长时间运行的进程有用的功能：

  • 批量处理文档
  • 对分区数据并行编制索引
  • 计划编制和变更检测，用于仅索引一段时间内新的和已更改的文档

索引器计划可以在最后的已知停止点恢复处理。 如果数据未能在处理窗口内完成索引，则索引器会在下一次运行时从上次停止的位置继续，前提是你使用的数据源提供更改检测功能。

将数据分区成较小的独立数据源可以实现并行处理。 可以拆分源数据，例如将其拆分到 Azure Blob 存储中的多个容器中，为每个分区创建数据源，然后根据搜索服务的搜索单位数并行运行索引器。

检查索引器批大小

与推送 API 一样，索引器允许配置每个批处理的项数。 对于基于 创建索引器 REST API 的 batchSize 索引器，请设置参数以自定义此设置以更好地匹配数据的特征。

默认批大小特定于数据源。 Azure SQL 数据库和 Azure Cosmos DB 的默认批大小为 1,000。 相比之下，Azure Blob 和SharePoint（预览版）索引设置批大小为 10 个文档，以识别较大的平均文档大小。

为长时间运行的进程计划索引器的运行

索引器调度是用于处理大型数据集以及适应运行缓慢的进程（例如富集管道中的图像分析）的重要机制。

通常，索引器处理在 2 小时的时段内运行。 如果索引工作负载需要数天而不是数小时才能完成，则可以将索引器置于每两小时启动一次的连续定期计划中。 假设数据源已启用更改跟踪，索引器会在上次中断的位置继续处理。 按这种节奏，索引器可以处理很多天的文档积压工作，直到处理完所有未处理的文档。 在初始运行期间或为大型 Blob 容器编制索引时，此模式尤其重要，其中仅 Blob 列出阶段可能需要数小时或数天。 在此期间，索引器显示没有 Blob 正在处理，但除非报告错误，否则它可能仍在遍历 Blob 列表。 文档处理和扩充仅在此阶段完成之后开始，并且此行为是预期的。

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

当数据源中不再有任何新的或更新的文档时，索引器执行历史记录会报告已处理的 0/0 个文档，并且不会进行任何处理。

有关设置计划的详细信息，请参阅创建索引器 REST API 或为 Azure AI 搜索计划索引器。

注意

最大处理窗口取决于索引器是否具有技能集。 带有技能集的索引器在内部管理的多租户环境中运行，最长运行时间为 2 小时。 配置为使用 共享专用链接 的索引器最多运行 24 小时。 无技能集的索引器最长运行 24 小时。

如果索引器使用具有扩充缓存的技能集，请在为大规模工作负荷启用缓存之前查看以下信息。

Caution

对于具有长时间运行技能、频繁中断或频繁失败的工作负载，富集缓存可能会增加初始引入或恢复期间的总重处理量。 扩充缓存不是备份，也不会跟踪哪些文档已完成处理。

并行运行索引器

如果已对数据进行了分区，可以创建多个索引器数据源组合，从每个数据源拉取并写入同一搜索索引。 由于每个索引器都是不同的，因此可以同时运行它们，因此填充搜索索引的速度比按顺序运行索引要快。

请确保有足够的容量。 服务中的每个搜索单位在任何给定的时间都只能运行一个索引器。 只有当索引器可以并行运行时，创建多个索引器才有用。

对于基于文本和基于技能的索引，可以同时运行的索引作业数有所不同。 有关详细信息，请参阅索引器执行。

如果数据源是 Azure Blob 存储容器或 Azure Data Lake Storage Gen 2，则在完成此操作前，枚举大量 Blob 可能需要很长时间（甚至数小时）。 结果是，在此期间你的索引器的成功处理文档计数可能不会增加，甚至看似毫无进展。 如果希望大量 Blob 的文档处理速度更快，请考虑将数据分区到多个容器，并创建指向单个索引的并行索引器。

  1. 在 Azure 门户中，转到你的搜索服务。

  2. 检查您的搜索服务所使用的搜索单位数。 选择“设置”“缩放”，在页面顶部查看数量。> 并行运行的索引器数约等于搜索单位数。

  3. 在多个容器之间进行源数据分区，或者对同一容器中的多个虚拟文件夹进行分区。

  4. 创建多个数据源（每个分区一个），与其自己的索引器配对。

  5. 在每个索引器中指定同一目标搜索索引。

  6. 计划索引器。

  7. 查看索引器状态和执行历史记录以进行确认。

存在一些与并行索引相关的风险。 首先，回想一下，索引不会在后台运行，这会增加查询被限制或删除的可能性。

其次，Azure AI 搜索不会锁定用于更新的索引。 如果特定写入在第一次尝试时不成功，则并发写入是通过调用重试来管理的，但你可能会注意到索引失败增加。

虽然多个索引器和数据源的组合可以指向同一个索引，但要小心索引器执行时会覆盖索引中现有的值。 如果第二个索引器数据源以相同的文档和字段为目标，则会覆盖第一次运行中的任何值。 字段值将被完全替换；索引器无法将多次运行中的值合并为同一字段。

为 Spark 上的大数据编制索引

如果你有大数据体系结构，并且数据位于 Spark 群集上，请使用 SynapseML 加载和索引数据。 本教程包括调用 Foundry Tools for AI 扩充的步骤，但也可以使用 AzureSearchWriter API 进行文本索引。

相关内容

  • Last updated on