Индексирование больших наборов данных в поиске ИИ Azure

  • Статья

Если требования к решению поиска включают индексирование больших данных или сложных данных, эта статья сформулирует стратегии для размещения длительных процессов в поиске ИИ Azure.

В этой статье предполагается знакомство с двумя основными подходами к импорту данных: отправка данных в индекс или извлечение данных из поддерживаемого источника данных с помощью индексатора поиска. Если сценарий включает в себя обогащение искусственного интеллекта с интенсивным вычислением, то индексаторы необходимы, учитывая зависимость набора навыков от индексаторов.

Эта статья дополняет Советы для повышения производительности, которая предлагает рекомендации по проектированию индексов и запросов. Хорошо разработанный индекс, включающий только необходимые поля и атрибуты, является важным условием для крупномасштабного индексирования.

Мы рекомендуем использовать более новую службу поиска, созданную после 3 апреля 2024 г., для более высокого уровня хранилища на секцию.

Примечание.

В стратегиях, описанных в этой статье, предполагается один большой источник данных. Если для решения требуется индексирование из нескольких источников данных, ознакомьтесь с рекомендациями по индексу нескольких источников данных в поиске ИИ Azure.

Индексирование больших данных с помощью API push-уведомлений

API Push-интерфейсы, такие как REST API индекса документов или метод IndexDocuments (Azure SDK для .NET), являются наиболее распространенной формой индексирования в службе "Поиск ИИ Azure". Для решений, использующих API push-уведомлений, стратегия долгосрочного индексирования будет иметь один или оба следующих компонента:

  • Пакетные документы
  • Управление потоками

Пакетное несколько документов на запрос

Простой механизм индексирования большого количества данных заключается в отправке нескольких документов или записей в одном запросе. Если размер всех полезных данных не превышает 16 МБ, запрос может обрабатывать до 1000 документов в рамках одной операции массовой отправки. Эти ограничения применяются к использованию REST API индекса документов или метода IndexDocuments в пакете SDK для .NET. Для любого из этих API в текст каждого запроса включается 1000 документов.

Пакетные документы значительно сокращают время, необходимое для работы с большим объемом данных. Определение оптимального размера пакета для данных является ключевой задачей при оптимизации скорости индексирования. Существует два основных фактора, которые влияют на оптимальный размер пакета:

  • схема индекса;
  • размер данных.

Так как оптимальный размер пакета зависит от индекса и данных, лучше всего протестировать различные размеры пакетов, чтобы определить, какие результаты приводят к самым быстрым скоростям индексирования для вашего сценария. Руководство. Оптимизация индексирования с помощью API push-уведомлений предоставляет пример кода для тестирования размеров пакетов с помощью пакета SDK для .NET.

Добавление потоков и стратегии повторных попыток

Индексаторы имеют встроенное управление потоками, но при использовании API push-уведомлений код приложения должен управлять потоками. Убедитесь, что есть достаточно потоков для полного использования доступной емкости, особенно если вы недавно увеличили секции или обновились до службы поиска более высокого уровня.

  1. Увеличьте число параллельных потоков в клиентском коде.

  2. По мере увеличения запросов, поступающих в службу поиска, могут возникнуть коды состояния HTTP, указывающие, что запрос не полностью выполнен. При индексировании часто используются следующие два кода состояния HTTP:

    • 503 Service Unavailable (Служба недоступна). Эта ошибка означает, что система перегружена и запрос не может быть обработан сейчас.

    • 207 Multi-Status (Множественное состояние). Эта ошибка означает, что некоторые документы обработаны успешно, но хотя бы один — со сбоем.

  3. Для обработки сбоев запросы должны быть извлечены с помощью экспоненциальной стратегии повторных попыток.

Пакет SDK для Azure .NET автоматически повторяет 503 и другие неудачные запросы, но вам потребуется реализовать собственную логику для повтора 207s. Также для реализации стратегии повторных попыток можно использовать средства с открытым кодом, например Polly.

Индексирование с индексаторами и API-интерфейсами pull

Индексаторы имеют несколько возможностей, полезных для длительных процессов:

  • Пакетные документы
  • Параллельное индексирование секционированных данных
  • Планирование и обнаружение изменений для индексирования только новых и изменение документов с течением времени

Расписания индексатора могут возобновить обработку в последней известной точке остановки. Если данные не полностью индексированы в окне обработки, индексатор выбирает, где бы он ни остался на следующем запуске, если вы используете источник данных, обеспечивающий обнаружение изменений.

При секционировании данных на небольшие отдельные источники данных можно применять параллельную обработку. Вы можете разбить исходные данные, например на несколько контейнеров в Хранилище BLOB-объектов Azure, создать источник данных для каждой секции, а затем запустить индексаторы параллельно, при условии количества единиц поиска службы поиска.

Проверка размера пакета индексатора

Как и в случае с API отправки, индексаторы позволяют настраивать количество элементов в пакете. Для индексаторов на основе REST API создания индексатора можно задать аргумент batchSize, позволяющий настроить этот параметр для более точного соответствия характеристикам данных.

Размеры пакетов по умолчанию зависят от источника данных. У Базы данных SQL Azure и Azure Cosmos DB по умолчанию размер пакета равен 1000. При индексировании же BLOB-объектов Azure размер пакета задается равным 10 документам с учетом того, что размер документа больше среднего.

Планирование индексаторов для длительных процессов

Планирование индексатора является важным механизмом обработки больших наборов данных и для размещения медленных процессов, таких как анализ изображений в конвейере обогащения.

Как правило, обработка индексатора выполняется в течение 2-часового окна. Если рабочая нагрузка индексирования занимает несколько дней, а не часов, можно поместить индексатор в последовательное повторяющееся расписание, которое начинается каждые два часа. Если в источнике данных включена функция отслеживания изменений, индексатор возобновляет обработку, в которой последний раз отключается. На этом этапе индексатор может работать с невыполненной работой в течение нескольких дней до обработки всех необработанных документов.

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

Если в источнике данных больше нет новых или обновленных документов, журнал выполнения индексатора будет сообщать 0/0 о документах, которые не обрабатываются, и обработка не выполняется.

Дополнительные сведения о настройке расписаний см. в статье "Создание REST API индексатора" или инструкции по планированию индексаторов для поиска ИИ Azure.

Примечание.

Некоторые индексаторы, которые выполняются в старой архитектуре среды выполнения, имеют 24-часовое, а не 2-часовое максимальное окно обработки. Ограничение составляет 2 часа для новых процессоров содержимого, работающих во внутренне управляемой мультитенантной среде. По возможности поиск Azure AI пытается выгрузить индексатор и обработку набора навыков в мультитенантную среду. Если индексатор не может быть перенесен, он будет работать в частной среде и может работать до 24 часов. Если вы запланируете индексатор, который отображает эти характеристики, предположим, что 24-часовое окно обработки.

Параллельное выполнение индексаторов

При секционировании данных можно создать несколько сочетаний индексатора-источника данных, которые извлекаются из каждого источника данных и записываются в один и тот же индекс поиска. Так как каждый индексатор отличается, их можно запускать одновременно, заполняя индекс поиска быстрее, чем если они выполняются последовательно.

Убедитесь, что у вас достаточно емкости. Одна единица поиска в службе в определенный момент времени может запустить один индексатор. Создание нескольких индексаторов полезно только в том случае, если они могут выполняться параллельно.

Количество заданий индексирования, которые могут выполняться одновременно, зависит от текстового и навыков индексирования. Дополнительные сведения см. в разделе "Выполнение индексатора".

Если источник данных является контейнером Хранилище BLOB-объектов Azure или Azure Data Lake служба хранилища 2-го поколения, перечисление большого количества больших двоичных объектов может занять много времени (даже часов), пока эта операция не будет завершена. Это приведет к тому, что в течение этого времени количество документов индексатора не увеличивается, и он может показаться, что это не делает никакого прогресса, когда это происходит. Если вы хотите ускорить обработку документов для большого количества больших двоичных объектов, рассмотрите возможность секционирования данных на несколько контейнеров и создание параллельных индексаторов, указывающих на один индекс.

  1. Войдите в портал Azure и проверка количество единиц поиска, используемых службой поиска. Выберите Параметры> Scale, чтобы просмотреть номер в верхней части страницы. Число индексаторов, которые будут выполняться параллельно, приблизительно равно количеству единиц поиска.

  2. Исходные данные секционирования между несколькими контейнерами или несколькими виртуальными папками в одном контейнере.

  3. Создайте несколько источников данных, по одному для каждой секции, в паре с собственным индексатором.

  4. Укажите один и тот же целевой индекс поиска в каждом индексаторе.

  5. Запланируйте индексаторы.

  6. Просмотрите состояние индексатора и журнал выполнения для подтверждения.

Существуют некоторые риски, связанные с параллельным индексированием. Во-первых, помните, что индексирование не выполняется в фоновом режиме, что повышает вероятность регулирования запросов или удаления.

Во-вторых, поиск по искусственному интеллекту Azure не блокирует индекс для обновлений. Одновременные операции записи управляются, вызывая повторную попытку, если определенная запись не выполнена при первой попытке, но вы можете заметить увеличение сбоев индексирования.

Хотя наборы из нескольких индексаторов и источников данных могут обслуживать один и тот же индекс, при запуске индексаторов следует соблюдать осторожность, так как они могут перезаписывать существующие значения в индексе. Если второй индексатор и источник данных обслуживают те же документы и поля, все значения после первого запуска будут перезаписаны. Значения полей заменяются в полном объеме; Индексатор не может объединять значения из нескольких запусков в одном поле.

Индексирование больших данных в Spark

Если у вас есть архитектура больших данных и данные в кластере Spark, рекомендуется использовать SynapseML для загрузки и индексирования данных. В этом руководстве приведены шаги по вызову служб ИИ Azure для обогащения ИИ, но вы также можете использовать API AzureSearchWriter для индексирования текста.

См. также