Connecteurs batch : automatiser l'import de données récurrent

La plupart des projets Data Cloud ne se limitent pas à un chargement initial : ils exigent un flux récurrent, fiable et traçable, alimentant les DMO au quotidien voire plusieurs fois par jour. Les connecteurs batch natifs (Amazon S3, Google Cloud Storage, SFTP) répondent à ce besoin en s'appuyant sur une logique de planification plutôt que sur des appels API déclenchés manuellement. Cet article détaille comment concevoir un pipeline batch robuste et industrialisable.

Le principe des connecteurs batch dans Data Cloud

Un connecteur batch fonctionne selon un modèle de polling : Data Cloud interroge périodiquement un emplacement défini (bucket S3, serveur SFTP) à la recherche de nouveaux fichiers correspondant à un pattern de nommage donné. Dès qu'un fichier est détecté, il est ingéré automatiquement selon le schéma associé au data stream. Ce mode diffère fondamentalement de l'Ingestion API : ici, c'est Data Cloud qui va chercher la donnée, pas le système source qui la pousse.

• Amazon S3 Connector : lecture de fichiers CSV/JSON/Parquet déposés dans un bucket, avec credentials IAM dédiés.
• SFTP / File-based Connector : compatible avec les systèmes legacy qui ne savent produire que des exports plats.
• Cloud Storage Connector (GCS, Azure Blob) : équivalent pour les écosystèmes non-AWS.

Concevoir une convention de nommage de fichiers

La fiabilité d'un connecteur batch repose largement sur la convention de nommage des fichiers déposés, qui doit permettre au connecteur de distinguer les nouveaux fichiers des fichiers déjà traités. Une convention robuste inclut systématiquement un horodatage :

customer_export_20260218_060000.csv
orders_delta_20260218_060000.csv

Évitez d'écraser un fichier existant (même nom réutilisé) : la plupart des connecteurs batch se basent sur la détection de nouveaux objets, et un fichier réécrit au même chemin peut ne pas être redétecté selon la configuration de polling.

Full load vs delta : bien choisir sa stratégie

Deux approches structurent la conception d'un flux batch récurrent :

1. Full load : le fichier contient l'intégralité du jeu de données à chaque exécution. Simple à mettre en œuvre côté source, mais coûteux en volume et en temps de traitement dès que la table dépasse quelques centaines de milliers de lignes.
2. Delta (incrémental) : seuls les enregistrements créés ou modifiés depuis la dernière extraction sont exportés, généralement en filtrant sur une colonne last_modified_date côté système source.

Le mode delta impose une gestion rigoureuse des suppressions : si un enregistrement est supprimé côté source, il ne remontera jamais dans un flux delta additif. Il faut alors soit exporter un flag is_deleted, soit prévoir un full load de contrôle périodique (hebdomadaire par exemple) pour resynchroniser et purger les orphelins.

Planification et fenêtres d'exécution

La fréquence de polling d'un connecteur batch est configurable, généralement de 15 minutes à 24 heures selon l'édition Data Cloud. Quelques règles pratiques :

• Aligner la fréquence de polling sur la fréquence réelle de dépôt des fichiers côté source : un polling toutes les 15 minutes sur un flux alimenté une fois par nuit consomme des cycles inutiles.
• Prévoir une marge de sécurité entre l'heure de génération du fichier côté source et l'heure de polling, pour absorber les latences réseau ou de job amont (ETL, extraction DB).
• Documenter les dépendances amont : si le job d'extraction source échoue ou est en retard, le connecteur batch ingérera un fichier vide ou partiel sans le signaler explicitement.

Bonne pratique : faites déposer un fichier marqueur (_SUCCESS ou équivalent) une fois l'export terminé côté source, et configurez le pipeline amont pour ne déclencher le dépôt du fichier de données qu'après validation de complétude.

Superviser et alerter

Un connecteur batch qui ne reçoit plus de fichier échoue silencieusement — Data Cloud ne lève pas d'alerte "fichier manquant" par défaut. Il est donc essentiel de mettre en place une supervision externe :

• Un job de contrôle (Scheduled Flow, ou script externe) qui vérifie la date du dernier enregistrement ingéré dans le DLO cible et alerte en cas de dépassement du SLA attendu.
• Le suivi des Data Stream Run History, accessible dans Setup, qui journalise chaque exécution avec le nombre de lignes traitées et les erreurs de mapping.
• Une checklist de reprise en cas d'échec : identifier le dernier fichier ingéré avec succès, régénérer les fichiers manquants côté source, et relancer manuellement le data stream si nécessaire.

Bien conçus, les connecteurs batch offrent un excellent rapport simplicité/fiabilité pour la majorité des flux d'entreprise. Pour les besoins de fraîcheur plus élevés (quasi temps réel), il faudra se tourner vers le streaming SDK ou le Change Data Capture, abordés dans les articles suivants de cette série.