Configurer Auto Loader pour les charges de travail de production

Article
11/07/2024

Databricks vous recommande de suivre les meilleures pratiques en matière de diffusion en continu pour l’exécution d’Auto Loader en production.

Databricks recommande d’utiliser Auto Loader dans Delta Live Tables pour l’ingestion incrémentielle des données. Delta Live Tables étend les fonctionnalités d’Apache Spark Structured Streaming et vous permet d’écrire quelques lignes de code Python ou SQL déclaratif pour déployer un pipeline de données de qualité production avec :

Mise à l’échelle automatique de l’infrastructure de calcul pour la réduction des coûts
Contrôles de la qualité des données avec les attentes
Gestion automatique de l’évolution du schéma
Monitoring via des métriques dans le journal des événements

Surveillance du chargeur automatique

Interrogation des fichiers découverts par Auto Loader

Remarque

La fonction cloud_files_state est disponible dans Databricks Runtime 11.3 LTS et les versions ultérieures.

Auto Loader fournit une API SQL pour inspecter l’état d’un flux. À l’aide de la fonction cloud_files_state, vous pouvez obtenir des métadonnées sur les fichiers qui ont été découverts par un flux Auto Loader. Effectuez simplement des interrogations à partir de cloud_files_state, en fournissant l’emplacement du point de contrôle associé à un flux Auto Loader.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Écouter les mises à jour de flux

Pour surveiller davantage les flux du chargeur automatique, Databricks recommande l’utilisation de l’interface d’écouteur de requêtes de streaming d’Apache Spark.

Auto Loader signale les métriques à l’écouteur de requêtes de streaming à chaque lot. Vous pouvez afficher le nombre de fichiers présents dans le backlog et la taille de ce backlog dans les mesures numFilesOutstanding et numBytesOutstanding sous l’onglet Données brutes du tableau de bord de progression des requêtes de diffusion en continu :

{
  "sources" : [
    {
      "description" : "CloudFilesSource[/path/to/source]",
      "metrics" : {
        "numFilesOutstanding" : "238",
        "numBytesOutstanding" : "163939124006"
      }
    }
  ]
}

Dans Databricks Runtime 10.4 LTS et versions ultérieures, lorsque vous utilisez le mode Notification de fichiers, les métriques incluent également le nombre approximatif d’événements de fichiers qui se trouvent dans la file d’attente du cloud sous la forme approximateQueueSize pour AWS et Azure.

Considérations relatives au coût

Lorsque vous exécutez Auto Loader, votre principale source de coûts est le coût des ressources de calcul et de la détection des fichiers.

Pour réduire les coûts de calcul, Databricks recommande d’utiliser Databricks Jobs pour planifier Auto Loader comme programme de traitement par lots en utilisant Trigger.AvailableNow, plutôt qu’une exécution en continu tant que vous n’avez aucune exigence en matière de faible latence. Consultez Configurer des intervalles de déclencheur Structured Streaming.

Les coûts de détection de fichiers peuvent se présenter sous la forme d’opérations LIST sur vos comptes de stockage en mode Liste de répertoires et de demandes d’API sur le service d’abonnement et le service de file d’attente en mode Notification de fichiers. Pour réduire les coûts de détection de fichiers, Databricks recommande :

de fournir un déclencheur ProcessingTime lors de l’exécution continue d’Auto Loader en mode Liste de répertoires ;
Architecture des chargements de fichiers sur votre compte de stockage selon un ordre lexical afin de tirer parti de la liste incrémentielle (déconseillée) lorsque cela est possible
de tirer parti des notifications de fichiers lorsque la liste incrémentielle n’est pas possible ;
d’utiliser des étiquettes de ressources pour étiqueter les ressources créées par Auto Loader afin de suivre vos coûts.

Utilisation de Trigger.AvailableNow et limitation de débit

Remarque

Disponible dans Databricks Runtime 10.4 LTS et versions ultérieures.

L’exécution d’Auto Loader peut être planifiée dans Databricks Jobs comme un programme de traitement par lots en utilisant Trigger.AvailableNow. Le déclencheur AvailableNow demandera à Auto Loader de traiter tous les fichiers arrivés avant l’heure de début de la requête. Les nouveaux fichiers qui sont chargés après le démarrage du flux sont ignorés jusqu'au déclencheur suivant.

Avec Trigger.AvailableNow, la détection des fichiers se fait de manière asynchrone avec le traitement des données, et les données peuvent être traitées sur plusieurs microlots avec limitation du débit. Par défaut, Auto Loader traite un maximum de 1000 fichiers par microlot. Vous pouvez configurer cloudFiles.maxFilesPerTrigger et cloudFiles.maxBytesPerTrigger pour déterminer le nombre de fichiers ou d’octets à traiter dans un microlot. La limite de fichiers est une limite stricte, mais la limite d’octets est une limite souple, ce qui signifie qu’il est possible de traiter plus d’octets que le paramètre maxBytesPerTrigger fourni. Lorsque les deux options sont fournies ensemble, Auto Loader traite autant de fichiers que nécessaire pour atteindre l'une des limites.

Emplacement du point de contrôle

Databricks recommande de définir l’emplacement de point de contrôle sur un emplacement sans stratégie de cycle de vie d’objet cloud. Si les fichiers dans l’emplacement du point de contrôle sont nettoyés en fonction de la stratégie, l’état du flux est endommagé. Si cela se produit, vous devez redémarrer le flux à partir de zéro.

Rétention des événements

Auto Loader assure le suivi des fichiers découverts à l’emplacement du point de contrôle à l’aide de RocksDB pour fournir des garanties d’ingestion « une seule fois ». Databricks recommande vivement l'utilisation de l'option cloudFiles.maxFileAge pour tous les flux d'ingestion de données à volume élevé ou de longue durée. Cette option provoque l'expiration des événements à partir de l'emplacement du point de contrôle, ce qui accélère le temps de démarrage d'Auto Loader. Le temps de démarrage peut atteindre des minutes par exécution d'Auto Loader, ce qui ajoute un coût inutile lorsque vous avez une limite supérieure à l'âge maximal des fichiers qui seront stockés dans le répertoire source. La valeur minimale que vous pouvez définir pour cloudFiles.maxFileAge est "14 days". Dans RocksDB, les suppressions apparaissent comme des entrées d’objet tombstone. Par conséquent, vous devez vous attendre à ce que l’utilisation du stockage augmente temporairement à mesure que les événements expirent avant de se stabiliser.

Avertissement

cloudFiles.maxFileAge est un mécanisme de contrôle des coûts pour les jeux de données volumineux. Un réglage cloudFiles.maxFileAge trop agressif peut entraîner des problèmes de qualité des données, notamment l'ingestion des données en double ou des fichiers manquants. Par conséquent, Databricks recommande un paramètre conservateur pour cloudFiles.maxFileAge, 90 jours, par exemple. Cette durée est similaire à ce que les solutions d'ingestion de données comparables recommandent.

Si vous essayez de régler l’option cloudFiles.maxFileAge, des fichiers non traités peuvent être ignorés par Auto Loader ou des fichiers déjà traités peuvent expirer et être traités à nouveau, ce qui entraîne la duplication des données. Voici quelques éléments à prendre en compte lors du choix de l’option cloudFiles.maxFileAge :

Si votre flux redémarre après une longue période, les événements de notification de fichiers extraits de la file d’attente qui sont antérieurs à cloudFiles.maxFileAge sont ignorés. De même, si vous utilisez la liste de répertoires, les fichiers qui seraient apparus pendant le temps d'arrêt et qui sont antérieurs à cloudFiles.maxFileAge sont ignorés.
Si vous utilisez le mode Liste des répertoires avec cloudFiles.maxFileAge défini sur "1 month" par exemple, que vous arrêtez votre flux et que vous le redémarrez avec cloudFiles.maxFileAge défini sur "2 months", les fichiers datant de plus d'un mois, mais plus récents que deux mois sont retraités.

Si vous définissez cette option la première fois que vous démarrez le flux, vous n'ingérerez pas de données plus anciennes que cloudFiles.maxFileAge. Par conséquent, si vous voulez ingérer les anciennes données, vous ne devez pas définir cette option lorsque vous démarrez votre flux. Toutefois, vous devez définir cette option lors des exécutions ultérieures.

Déclencher des renvois réguliers à l’aide de cloudFiles.backfillInterval

Auto Loader peut déclencher des renvois asynchrones à un intervalle donné, par exemple un jour pour un renvoi une fois par jour ou une semaine pour un renvoi une fois par semaine. Les systèmes de notification d’événements de fichiers ne garantissent pas la livraison à 100 % de tous les fichiers qui ont été chargés et ne fournissent pas d’accords de niveau de service stricts sur la latence des événements de fichiers. Databricks vous recommande de déclencher des renvois standard avec Auto Loader à l’aide de l’option cloudFiles.backfillInterval pour garantir que tous les fichiers sont découverts dans un SLA donné si l’exhaustivité des données est obligatoire. Le déclenchement de renvois normaux n’entraîne pas de doublons.

Partage via