Индексирование данных из Файлы Azure
Внимание
Файлы Azure индексатор в настоящее время находится в общедоступной предварительной версии в разделе Дополнительные условия использования. Используйте REST API предварительной версии для создания источника данных индексатора.
Из этой статьи вы узнаете, как настроить индексатор, который импортирует содержимое из Файлы Azure и делает его доступным для поиска в службе "Поиск ИИ Azure". Входные данные индексатора — это ваши файлы в одной общей папке. Выходные данные — это индекс поиска с содержимым, доступным для поиска, и метаданными, хранящимися в отдельных полях.
В этой статье описывается создание индексатора с информацией, относяющейся к индексации файлов в служба хранилища Azure. В нем используются ИНТЕРФЕЙСы REST API для демонстрации трех частей рабочего процесса, общего для всех индексаторов: создание источника данных, создание индекса, создание индексатора. Извлечение данных происходит при отправке запроса create Indexer.
Необходимые компоненты
Общая папка SMB, предоставляющая исходное содержимое. Общие папки NFS не поддерживаются.
Файлы, содержащие текст. Если у вас есть двоичные данные, можно включить обогащение ИИ для анализа изображений.
Разрешения на чтение служба хранилища Azure. Строка подключения "полный доступ" включает ключ, предоставляющий доступ к содержимому.
Используйте клиент REST, чтобы сформулировать вызовы REST, аналогичные приведенным в этой статье.
Поддерживаемые форматы документов
Индексатор Файлы Azure может извлекать текст из следующих форматов документов:
- CSV (см. раздел индексирование больших двоичных объектов CSV)
- EML
- EPUB
- GZ
- HTML
- JSON (см. индексирование BLOB-объектов JSON);
- KML (XML для географических представлений)
- Форматы Microsoft Office: DOCX/DOC/DOCM, XLSX/XLSM, PPTX/PPT/PPTM, MSG (outlook emails), XML (как 2003, так и 2006 WORD XML)
- Форматы открытых документов: ODT, ODS, ODP
- обычные текстовые файлы (см. также индексирование обычного текста);
- RTF
- XML
- ZIP
Как индексируются Файлы Azure
По умолчанию большинство файлов индексируются как один документ поиска в индексе, включая файлы со структурированным содержимым, например JSON или CSV, которые индексируются как один блок текста.
Составной или внедренный документ (например, ZIP-архив, документ Word со встроенной электронной почтой Outlook, содержащий вложения или . MSG-файл с вложениями) также индексируется как один документ. Например, все изображения, извлеченные из вложений файла MSG, будут возвращены в поле normalized_images. Если у вас есть изображения, попробуйте добавить обогащение ИИ, чтобы получить больше служебной программы поиска из этого содержимого.
Текстовое содержимое документа извлекается в строковое поле с именем content. Можно также извлечь стандартные и пользовательские метаданные.
Определение источника данных
Определение источника данных указывает данные для индексирования, учетных данных и политик для выявления изменений в данных. Источник данных определяется как независимый ресурс, чтобы его можно было использовать несколькими индексаторами.
Для типа "azurefile"
можно использовать 2020-06-30-preview или более поздней версии. Рекомендуется использовать последнюю предварительную версию API.
Создайте источник данных для задания его определения с помощью API предварительной версии для "type":
"azurefile"
.POST /datasources?api-version=2024-05-01-preview { "name" : "my-file-datasource", "type" : "azurefile", "credentials" : { "connectionString" : "DefaultEndpointsProtocol=https;AccountName=<account name>;AccountKey=<account key>;" }, "container" : { "name" : "my-file-share", "query" : "<optional-directory-name>" } }
Задайте для параметра type
"azurefile"
(обязательный).Задайте для параметра "Учетные данные" значение служба хранилища Azure строка подключения. В следующем разделе описаны поддерживаемые форматы.
Задайте для корневого файлового ресурса контейнер и используйте запрос, чтобы указать все вложенные папки.
Определение источника данных также может включать политики обратимого удаления, если требуется, чтобы индексатор удалил документ поиска, когда исходный документ помечен для удаления.
Поддерживаемые учетные данные и строка подключения
Индексаторы могут подключаться к общей папке с помощью следующих подключений.
Строка подключения учетной записи хранения полного доступа |
---|
{ "connectionString" : "DefaultEndpointsProtocol=https;AccountName=<your storage account>;AccountKey=<your account key>;" } |
Вы можете получить строка подключения на странице учетной записи хранения в портал Azure, выбрав ключи доступа в области навигации слева. Не забудьте выбрать полную строка подключения и не только ключ. |
Добавление полей поиска в индекс
В индексе поиска добавьте поля, чтобы принять содержимое и метаданные файлов Azure.
Создайте или обновите индекс , чтобы определить поля поиска, которые будут хранить содержимое файла и метаданные.
POST /indexes?api-version=2024-07-01 { "name" : "my-search-index", "fields": [ { "name": "ID", "type": "Edm.String", "key": true, "searchable": false }, { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false }, { "name": "metadata_storage_name", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true }, { "name": "metadata_storage_path", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true }, { "name": "metadata_storage_size", "type": "Edm.Int64", "searchable": false, "filterable": true, "sortable": true }, { "name": "metadata_storage_content_type", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true } ] }
Создайте поле ключа документа ("key": true"). Для содержимого BLOB-объектов лучшие кандидаты являются свойствами метаданных. Свойства метаданных часто включают символы, такие как
/
и-
недопустимые для ключей документов. Индексатор автоматически кодирует свойство метаданных ключа без требуемой конфигурации или сопоставления полей.metadata_storage_path
Полный путь к объекту или файлу (по умолчанию)metadata_storage_name
доступны только в том случае, если имена уникальныНастраиваемое свойство метаданных, которое добавляется в большие двоичные объекты. Для этого варианта требуется, чтобы при передаче это свойство метаданных добавлялось ко всем большим двоичным объектам. Так как ключ является обязательным свойством, все большие двоичные объекты, в которых отсутствует значение, не будут проиндексированы. При использовании настраиваемого свойства метаданных в качестве ключа следует избегать внесения изменений в это свойство. При изменении свойства ключа индексаторы добавят дубликаты документов для того же BLOB-объекта.
Добавьте поле content для хранения извлеченного текста из каждого файла через свойство "содержимое" большого двоичного объекта. Вам не требуется использовать это имя, но это позволяет воспользоваться преимуществами неявных сопоставлений полей.
Добавьте поля для стандартных свойств метаданных. В индексировании файлов стандартные свойства метаданных совпадают со свойствами метаданных большого двоичного объекта. Индексатор Файлы Azure автоматически создает внутренние сопоставления полей для этих свойств, которые преобразуют имена дефисированных свойств в имена подчеркиваемых свойств. Вам по-прежнему нужно добавить поля, которые вы хотите использовать определение индекса, но можно опустить создание сопоставлений полей в источнике данных.
- metadata_storage_name (
Edm.String
) — имя файла. Например, если у вас есть файл /my-share/my-folder/subfolder/resume.pdf, значение этого поля равноresume.pdf
. - metadata_storage_path (
Edm.String
) — полный URI файла, включая учетную запись хранения. Например:https://myaccount.file.core.windows.net/my-share/my-folder/subfolder/resume.pdf
- metadata_storage_content_type (
Edm.String
) — тип контента, указанный кодом, используемым для отправки файла. Например,application/octet-stream
. - metadata_storage_last_modified (
Edm.DateTimeOffset
) — метка времени последнего изменения для файла. Поиск по искусственному интеллекту Azure использует эту метку времени для идентификации измененных файлов, чтобы избежать переиндексирования всего после первоначального индексирования. - metadata_storage_size (
Edm.Int64
) — размер файла в байтах. - metadata_storage_content_md5 (
Edm.String
) — хэш MD5 содержимого файла, если он доступен. - metadata_storage_sas_token (
Edm.String
) — временный маркер SAS, который можно использовать пользовательскими навыками для получения доступа к файлу. Этот маркер не должен храниться для последующего использования, так как он может истекать.
- metadata_storage_name (
Настройка и запуск индексатора Файлы Azure
Когда индекс и источник данных уже созданы, можно создать индексатор. Конфигурация индексатора задает входные данные, параметры и свойства, управляющие поведением во время выполнения.
Создайте или обновите индексатор , предоставив ему имя и ссылаясь на источник данных и целевой индекс:
POST /indexers?api-version=2024-07-01 { "name" : "my-file-indexer", "dataSourceName" : "my-file-datasource", "targetIndexName" : "my-search-index", "parameters": { "batchSize": null, "maxFailedItems": null, "maxFailedItemsPerBatch": null, "configuration": { "indexedFileNameExtensions" : ".pdf,.docx", "excludedFileNameExtensions" : ".png,.jpeg" } }, "schedule" : { }, "fieldMappings" : [ ] }
В необязательном разделе "Конфигурация" укажите все критерии включения или исключения. Если не указано, извлекаются все файлы в общей папке.
indexedFileNameExtensions
Если оба иexcludedFileNameExtensions
параметры присутствуют, поиск ИИ Azure сначала просматриваетindexedFileNameExtensions
, а затем наexcludedFileNameExtensions
. Если одно и то же расширение файла присутствует в обоих списках, он будет исключен из индексирования.Укажите сопоставления полей, если существуют различия в имени или типе поля, или если в индексе поиска требуется несколько версий исходного поля.
В индексировании файлов часто можно опустить сопоставления полей, так как индексатор имеет встроенную поддержку сопоставления свойств "содержимого" и метаданных с аналогичными именованными и типизированными полями в индексе. Для свойств метаданных индексатор автоматически заменит дефисы символами
-
подчеркивания в индексе поиска.Дополнительные сведения о других свойствах см. в статье "Создание индексатора ".
Индексатор запускается автоматически при его создании. Это можно предотвратить, задав для параметра "Отключено" значение true. Чтобы управлять выполнением индексатора, запустите индексатор по запросу или поместите его в расписание.
Проверка состояния индексатора
Чтобы отслеживать состояние индексатора и журнал выполнения, отправьте запрос состояния индексатора:
GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2024-07-01
Content-Type: application/json
api-key: [admin key]
Ответ включает состояние и количество обработанных элементов. Он должен выглядеть примерно так:
{
"status":"running",
"lastResult": {
"status":"success",
"errorMessage":null,
"startTime":"2022-02-21T00:23:24.957Z",
"endTime":"2022-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
"executionHistory":
[
{
"status":"success",
"errorMessage":null,
"startTime":"2022-02-21T00:23:24.957Z",
"endTime":"2022-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
... earlier history items
]
}
Журнал выполнения содержит до 50 последних завершенных выполнений, которые сортируются в обратном хронологическом порядке, чтобы последнее выполнение было первым.
Следующие шаги
Теперь можно запустить индексатор, состояние монитора или запланировать выполнение индексатора. Следующие статьи относятся к индексаторам, которые извлекает содержимое из служба хранилища Azure: