Configurer le chargeur automatique pour les charges de travail de production

Databricks vous recommande de suivre les meilleures pratiques en matière de diffusion en continu pour l’exécution du chargeur automatique en production.

Databricks recommande d'utiliser Auto Loader dans les pipelines déclaratifs Spark Lakeflow pour l'ingestion de données incrémentielles. Lakeflow Spark Declarative Pipelines étend les fonctionnalités d’Apache Spark Structured Streaming et vous permet d’écrire quelques lignes de Python déclaratif ou SQL pour déployer un pipeline de données de qualité de production avec :

• Mise à l’échelle automatique de l’infrastructure de calcul pour réduire les 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

Monitoring du chargeur automatique

Interrogation des fichiers découverts par le chargeur automatique

Le chargeur automatique 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 de chargeur automatique. Effectuez simplement des interrogations à partir de cloud_files_state, en fournissant l’emplacement du point de contrôle associé à un flux de chargeur automatique.

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

Écouter les mises à jour de flux

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

Le chargeur automatique 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 métriques numFilesOutstanding et numBytesOutstanding sous l’onglet Données brutes du tableau de bord de progression des requêtes de streaming :

{
  "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 de notification de fichier, les métriques incluent également le nombre approximatif d’événements de fichier dans la file d’attente cloud comme approximateQueueSize pour AWS et Azure.

Considérations relatives aux coûts

Lors de l’exécution du chargeur automatique, vos principales sources de coût sont les ressources de calcul et la découverte de fichiers.

Pour réduire les coûts de calculs, Databricks recommande d’utiliser des travaux Lakeflow pour planifier le chargeur automatique en tant que travaux par lots à l’aide de Trigger.AvailableNow au lieu de l’exécuter en continu, à moins que vous n'ayez des exigences en matière de faible latence. Consultez Configurer des intervalles de déclencheur Structured Streaming. Ces travaux de traitement par lots peuvent être déclenchés à l’aide de déclencheurs d’arrivée de fichiers pour réduire davantage la latence entre l’arrivée du fichier et le traitement.

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

• Ne pas utiliser les déclencheurs ProcessingTime ou Continuous lors de l’exécution continue du chargeur automatique en mode de liste de répertoires. Utilisez le chargeur automatique avec des événements de fichier à la place. Pour plus d’informations sur le fonctionnement du chargeur automatique avec les événements de fichier, consultez La vue d’ensemble du chargeur automatique avec des événements de fichier.
• Utilisation du mode de notification de fichier hérité si vous ne pouvez pas utiliser Auto Loader avec des événements de fichier. Dans ce mode, vous pouvez étiqueter les ressources créées par le chargeur automatique pour suivre vos coûts à l’aide de balises de ressources.

Archiver des fichiers dans le répertoire source pour réduire les coûts

Nous vous recommandons d’utiliser le chargeur automatique avec des événements de fichier pour réduire les coûts de découverte. Cela réduit également les coûts de calcul, car la découverte est incrémentielle.

Si vous ne pouvez pas utiliser d’événements de fichier et devez utiliser la liste des répertoires pour découvrir les fichiers, vous pouvez utiliser l’option cloudFiles.cleanSource pour archiver ou supprimer automatiquement des fichiers après que le chargeur automatique les traite pour réduire les coûts de découverte. Étant donné que le chargeur automatique nettoie les fichiers de votre répertoire source après le traitement, moins de fichiers doivent être répertoriés lors de la découverte.

Lorsque vous utilisez cloudFiles.cleanSource avec l’option MOVE, tenez compte des exigences suivantes :

• Le répertoire source et le répertoire de déplacement de destination doivent se trouver dans le même emplacement externe ou volume.
• Si votre répertoire source et de destination se trouve dans le même emplacement externe, il ne doit pas avoir de répertoires frères qui contiennent un stockage managé (par exemple, un volume managé ou un catalogue). Dans ce cas, le chargeur automatique ne peut pas obtenir les autorisations nécessaires pour écrire dans le répertoire de destination.

Databricks recommande d’utiliser cette option lorsque :

• Votre répertoire source accumule un grand nombre de fichiers au fil du temps.
• Vous devez conserver les fichiers traités pour la conformité ou l’audit (défini cloudFiles.cleanSource sur MOVE).
• Vous souhaitez réduire les coûts de stockage en supprimant les fichiers après l’ingestion (défini cloudFiles.cleanSource sur DELETE). Quand vous utilisez le mode DELETE, Databricks recommande d’activer le versioning sur le compartiment afin que les suppressions effectuées par Auto Loader agissent comme des suppressions temporaires et soient disponibles en cas de mauvaise configuration. De plus, Databricks recommande de configurer des stratégies de cycle de vie cloud pour purger les anciennes versions supprimées de façon non définitive après une période de grâce spécifiée (par exemple, 60 ou 90 jours), en fonction de vos besoins en matière de récupération.

Utilisation de Trigger.AvailableNow et limitation de débit

L’exécution du chargeur automatique peut être planifiée dans Lakeflow Jobs comme un programme de traitement par lots en utilisant Trigger.AvailableNow. Le déclencheur AvailableNow demandera au chargeur automatique 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 micro-lots avec une limitation du débit. Par défaut, le chargeur automatique traite un maximum de 1000 fichiers par micro-lot. Vous pouvez configurer cloudFiles.maxFilesPerTrigger et cloudFiles.maxBytesPerTrigger pour déterminer le nombre de fichiers ou d’octets à traiter dans un micro-lot. 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, le chargeur automatique traite autant de fichiers que nécessaire pour atteindre l’une des limites.

Emplacement du point de contrôle

L’emplacement du point de contrôle est utilisé pour stocker les informations d’état et de progression du flux. 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 conformément à la stratégie, l’état du flux est endommagé. Si cela se produit, vous devez redémarrer le flux à partir de zéro.

Suivi des événements de fichier

Le chargeur automatique 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 ». Pour les flux d’ingestion volumineux ou de longue durée, Databricks recommande la mise à niveau vers Databricks Runtime 15.4 LTS ou version ultérieure. Dans ces versions, le chargeur automatique n’attend pas que l’état rocksDB entier soit téléchargé avant le démarrage du flux, ce qui peut accélérer le temps de démarrage du flux. Si vous souhaitez empêcher les états de fichiers de croître sans limites, vous pouvez également envisager d’utiliser l’option cloudFiles.maxFileAge permettant d’expirer les événements de fichier antérieurs à un certain âge. La valeur minimale que vous pouvez définir pour cloudFiles.maxFileAge est "14 days". Les suppressions dans RocksDB apparaissent sous forme d’entrées marquées comme tombstones. Par conséquent, vous pouvez voir l’utilisation du stockage augmenter temporairement à mesure que les événements expirent, avant qu'elle ne commence à se stabiliser.

Si vous essayez de régler l’option cloudFiles.maxFileAge, des fichiers non traités peuvent être ignorés par le chargeur automatique 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 ont pu apparaître 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 et que vous utilisez cloudFiles.maxFileAge, par exemple défini sur "1 month", 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 pour la première fois. Toutefois, vous devez définir cette option lors des exécutions ultérieures.

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

Dans de rares cas, les fichiers peuvent être manqués ou en retard lorsqu’ils dépendent uniquement des systèmes de notification, par exemple lorsque les limites de rétention des messages de notification sont atteintes. Si vous avez des exigences strictes sur l’exhaustivité des données et le contrat SLA, envisagez de définir le paramètre cloudFiles.backfillInterval pour déclencher des remplissages asynchrones à un intervalle spécifié. Par exemple, définissez-le sur un jour pour les remplissages quotidiens, ou une semaine pour les remplissages hebdomadaires. Le déclenchement de renvois normaux n’entraîne pas de doublons.

Lorsque vous utilisez des événements de fichier, exécutez votre flux au moins une fois tous les 7 jours

Lorsque vous utilisez des événements de fichier, exécutez vos flux de chargeur automatique au moins une fois tous les 7 jours pour éviter une liste complète de répertoires. Exécuter fréquemment vos flux de chargeur automatique garantira que la découverte de fichiers soit incrémentielle.

Pour obtenir des meilleures pratiques complètes sur les événements de fichiers managés, consultez les meilleures pratiques pour le chargeur automatique avec les événements de fichier.