Indexer des jeux de données volumineux dans Azure AI Recherche

Article
04/12/2024

Si les besoins de votre solution de recherche incluent l’indexation de Big Data ou de données complexes, cet article présente des stratégies pour prendre en charge les processus durables sur Recherche Azure AI.

Cet article suppose une certaine familiarité avec les deux méthodes de base pour importer des données, à savoir l’envoi (push) de données dans un index ou le tirage (pull) de données à partir d’une source de données prise en charge à l’aide d’un indexeur de recherche. Si votre scénario implique un enrichissement par IA à forte intensité de calcul, des indexeurs sont alors nécessaires, en raison de la dépendance de l’ensemble des compétences vis-à-vis des indexeurs.

Cet article vient compléter l’article Conseils pour de meilleures performances qui décrit les bonnes pratiques pour concevoir des index et des requêtes. Un index bien conçu qui inclut uniquement les champs et les attributs dont vous avez besoin est un prérequis important pour une indexation à grande échelle.

Pour obtenir un espace de stockage supérieur par partition, nous vous recommandons d’utiliser un service de recherche plus récent, créé après le 3 avril 2024.

Remarque

Les stratégies décrites dans cet article supposent une seule source de données volumineuse. Si votre solution nécessite l’indexation de plusieurs sources de données, consultez Indexer plusieurs sources de données dans Azure AI Recherche pour connaître l’approche recommandée.

Indexer des données volumineuses à l’aide des API push

Les API « push », telles que l’API REST Documents Index ou la méthode IndexDocuments (Kit SDK Azure pour .NET), constituent la forme d’indexation la plus répandue dans Recherche Azure AI. Pour les solutions qui utilisent une API push, la stratégie d’indexation de longue durée comprend l’un des composants suivants ou les deux :

Traitement par lot des documents
Gestion des threads

Traitement par lots de plusieurs documents par demande

Un mécanisme simple pour indexer une grande quantité de données consiste à envoyer plusieurs documents ou enregistrements dans une même demande. Tant que la charge utile entière est inférieure à 16 Mo, une demande peut gérer jusqu’à 1 000 documents dans une opération de chargement en bloc. Ces limites s’appliquent que vous utilisiez l’API REST Documents Index ou la méthode IndexDocuments du Kit de développement logiciel (SDK) .NET. Pour l’une ou l’autre des API, vous devez empaqueter 1 000 documents dans le corps de chaque requête.

Le traitement par lot des documents permet de réduire considérablement le temps nécessaire pour traiter un volume de données important. La détermination de la taille de lot optimale pour vos données est un composant clé de l’optimisation des vitesses d’indexation. Les deux principaux facteurs qui influencent la taille de lot optimale sont les suivants :

Le schéma de votre index
La taille de vos données

Étant donné que la taille de lot optimale dépend de votre index et de vos données, la meilleure approche consiste à tester différentes tailles de lot pour déterminer ce qui produit les vitesses d’indexation les plus rapides pour votre scénario. Le Tutoriel : Optimiser l’indexation avec l’API Push fournit un exemple de code pour tester les tailles de lot à l’aide du SDK .NET.

Ajouter des threads et une stratégie de nouvelle tentative

Les indexeurs ont une gestion de thread intégrée, mais lorsque vous utilisez les API push, votre code d’application doit gérer les threads. Assurez-vous qu’il existe suffisamment de threads pour tirer pleinement parti de la capacité disponible, en particulier si vous avez récemment augmenté les partitions ou que vous êtes passé à un service de recherche de niveau supérieur.

Augmentez le nombre de threads simultanés dans votre code client.
Au fur et à mesure que les requêtes atteignent le service de recherche, vous risquez de rencontrer des codes d’état HTTP indiquant que la requête n’a pas abouti. Pendant l’indexation, deux codes d’état HTTP courants sont :
- 503 Service indisponible : Cette erreur signifie que le système est surchargé et que votre requête ne peut pas être traitée pour le moment.
- 207 Multi-état : Cette erreur signifie que certains documents ont réussi, mais qu’au moins un a échoué.
Pour gérer les échecs, les requêtes doivent être retentées en utilisant une stratégie de nouvelle tentative avec backoff exponentiel.

Le SDK .NET Azure retente automatiquement les requêtes qui échouent ou qui génèrent une erreur 503, mais vous devez implémenter votre propre logique de nouvelle tentative en cas d’erreurs 207. Des outils open source tels que Polly peuvent également être utilisés pour mettre en œuvre une stratégie de nouvelle tentative.

Indexer avec des indexeurs et les API « pull »

Les indexeurs offrent plusieurs fonctionnalités utiles pour les processus de longue durée :

Traitement par lot des documents
Indexation parallèle sur des données partitionnées
Planification et détection des modifications pour indexer uniquement les nouveaux documents et ceux modifiés au fil du temps

Les planifications d’un indexeur peuvent reprendre le traitement au dernier point d’arrêt connu. Si les données ne sont pas entièrement indexées au cours de la fenêtre de traitement, l’indexeur reprend à l’endroit où il s’est arrêté la prochaine fois qu’il est exécuté, si tant est que vous utilisiez une source de données prenant en charge la détection des modifications.

Le partitionnement des données en sources de données individuelles plus petites permet le traitement parallèle. Vous pouvez diviser les données sources, par exemple en plusieurs conteneurs dans Stockage Blob Azure, créer une source de données pour chaque partition, puis exécuter les indexeurs en parallèle en fonction du nombre d’unités de recherche de votre service de recherche.

Vérifier la taille de lot de l’indexeur

Comme avec l’API Push, les indexeurs vous permettent de configurer le nombre d’éléments par lot. Pour les indexeurs basés sur l’API REST de création d’un indexeur, vous pouvez définir l’argument batchSize pour personnaliser ce paramètre de façon à le faire mieux correspondre aux caractéristiques de vos données.

Les tailles de lot par défaut sont spécifiques à la source de données. Azure SQL Database et Azure Cosmos DB ont une taille de lot par défaut de 1 000. À l’inverse, l’indexation des objets blob Azure définit la taille des lots à 10 documents en fonction de la taille moyenne des documents la plus élevée.

Indexeurs planifiés pour les processus de longue durée

La planification des indexeurs est un mécanisme important pour le traitement des grands jeux de données et l’organisation des processus à exécution longue, comme l’analyse d’images dans un pipeline d’enrichissement.

En général, le traitement de l’indexeur s’exécute dans une fenêtre de 2 heures. Si la charge de travail d’indexation se mesure en jours plutôt qu’en heures, vous pouvez configurer une planification consécutive et périodique pour démarrer l’indexeur toutes les deux heures. En supposant que le suivi des modifications est activé dans la source de données, l’indexeur reprend le traitement là où il s’est arrêté la dernière fois. À cette cadence, un indexeur peut s’exécuter sur un backlog de documents pendant plusieurs jours jusqu’à ce que tous les documents non traités soient traités.

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

Quand il n’y a plus de documents nouveaux ou mis à jour dans la source de données, l’historique d’exécution de l’indexeur signale 0/0 documents traités et aucun traitement n’est effectué.

Pour plus d’informations sur la définition de planifications, consultez API REST de création d’indexeur ou Comment planifier des indexeurs pour Azure AI Recherche.

Remarque

Certains indexeurs fonctionnant sur une architecture d’exécution plus ancienne ont une fenêtre de traitement maximale de 24 heures au lieu de 2 heures. La limite de 2 heures s’applique aux processeurs de contenu plus récents qui s’exécutent dans un environnement multilocataire géré en interne. Dans la mesure du possible, Azure AI Recherche tente de décharger le traitement de l’indexeur et de l’ensemble de compétences vers l’environnement multilocataire. Si l’indexeur ne peut pas être migré, il s’exécute dans l’environnement privé et peut s’exécuter pendant 24 heures au maximum. Si vous planifiez un indexeur qui présente à ces caractéristiques, supposez une fenêtre de traitement de 24 heures.

Exécuter des indexeurs en parallèle

Si vous avez partitionné vos données, vous pouvez créer plusieurs combinaisons indexeur-données-source qui extraient de chaque source de données et écrivent dans le même index de recherche. Étant donné que chaque indexeur est distinct, vous pouvez les exécuter en même temps, en remplissant un index de recherche plus rapidement que si vous les exécutiez de manière séquentielle.

Assurez-vous d’avoir une capacité suffisante. Une unité de recherche dans votre service peut exécuter un indexeur à tout moment donné. La création de plusieurs indexeurs est utile uniquement s’ils peuvent s’exécuter en parallèle.

Le nombre de travaux d’indexation qui peuvent s’exécuter simultanément varie selon l’indexation basée sur le texte et les compétences. Pour plus d’informations, consultez Exécution de l’indexeur.

Si votre source de données est un conteneur Stockage Blob Azure ou Azure Data Lake Storage Gen 2, l’énumération d’un grand nombre d’objets blob peut prendre beaucoup de temps (parfois des heures) jusqu’à ce que cette opération soit terminée. Ainsi, le nombre de documents réussis de votre indexeur n’augmente pas pendant cette période et il peut sembler qu’aucun progrès n’est réalisé, alors que c’est le cas. Si vous souhaitez que le traitement des documents soit plus rapide pour un grand nombre d’objets blob, envisagez de partitionner vos données dans plusieurs conteneurs et de créer des indexeurs parallèles pointant vers un seul index.

Connectez-vous au portail Azure et vérifiez le nombre d’unités de recherche utilisées par votre service de recherche. Sélectionnez Paramètres>Mettre à l’échelle pour afficher le nombre en haut de la page. Le nombre d’indexeurs qui s’exécutent en parallèle est approximativement égal au nombre d’unités de recherche.
Partitionnez vos données sources entre plusieurs conteneurs ou dossiers virtuels au sein du même conteneur.
Créez plusieurs sources de données, une pour chaque partition, associées à leur propre indexeur.
Spécifiez le même index de recherche cible dans chaque indexeur.
Planifiez les indexeurs.
Vérifiez l’état de l’indexeur et l’historique d’exécution pour confirmer.

Il existe certains risques associés à l’indexation parallèle. Premièrement, rappelez-vous que l’indexation ne s’exécute pas en arrière-plan, ce qui permet d’augmenter la probabilité que les requêtes soient limitées ou supprimées.

Deuxièmement, Azure AI Recherche ne verrouille pas l’index pour les mises à jour. Les écritures simultanées sont managées, une nouvelle tentative étant appelée si une écriture particulière ne réussit pas la première fois, mais vous remarquerez peut-être une augmentation des échecs d’indexation.

Même si plusieurs jeux indexeur-données-source peuvent cibler le même index, gardez à l’esprit qu’une exécution d’indexeur est susceptible de remplacer les valeurs existantes dans l’index. Si un deuxième jeu indexeur-données-source cible les mêmes documents et champs, toutes les valeurs de la première exécution sont remplacées. Les valeurs de champ sont remplacées dans leur entier ; un indexeur ne peut pas fusionner les valeurs de plusieurs exécutions dans le même champ.

Indexer le Big Data sur Spark

Si vous avez une architecture Big Data et que vos données se trouvent sur un cluster Spark, nous vous recommandons d’utiliser SynapseML pour le chargement et l’indexation des données. Le tutoriel comprend des étapes pour appeler Azure AI services pour l’enrichissement par IA, mais vous pouvez également utiliser l’API AzureSearchWriter pour l’indexation de texte.