Concevoir une logique d’ingestion et une configuration de source de données

La conception d’une logique d’ingestion vous oblige à prendre des décisions critiques sur la façon dont les données passent des systèmes sources vers Azure Databricks. Ces décisions affectent la fraîcheur des données, l’efficacité du traitement et la fiabilité du système. Avant de sélectionner des outils ou d’écrire du code, vous devez comprendre les caractéristiques de vos sources de données et définir des stratégies d’extraction qui s’alignent sur vos besoins métier.

Dans cette unité, vous explorez les principales considérations relatives à la conception pour la logique d’ingestion de données et la configuration de la source de données dans Azure Databricks. L’accent est mis ici sur la logique conceptuelle et les modèles de conception : des détails spécifiques sur la sélection et l’implémentation d’outils sont abordés dans les unités ultérieures.

Comprendre les types d’extraction

Le type d’extraction détermine la façon dont vous capturez des données à partir de systèmes sources et affecte à la fois les chronologies et l’efficacité de votre pipeline de données. Azure Databricks prend en charge trois modèles d’extraction principaux, chacun adapté à différents scénarios.

Extraction complète

L’extraction complète lit l’intégralité du jeu de données à partir du système source pendant chaque exécution d’ingestion.

Cette approche fonctionne bien quand :

• Les systèmes sources ne prennent pas en charge le suivi des modifications
• Les volumes de données sont suffisamment petits pour retraiter efficacement
• Vous devez reconstruire régulièrement les tables de destination à partir de zéro.
• Les relations de données sont complexes et la logique incrémentielle serait sujette aux erreurs

L’extraction complète devient irréalisable à mesure que les volumes de données augmentent. Retraiter des millions d'enregistrements lorsque seuls quelques milliers ont changé gaspille des ressources de capacité de calcul et retarde les consommateurs en aval.

Extraction incrémentielle

L’extraction incrémentielle traite uniquement les enregistrements nouveaux ou modifiés depuis la dernière exécution d’ingestion. Le moteur effectue le suivi des données traitées et interroge uniquement les mises à jour.

Ce modèle nécessite :

• Indicateur de modification fiable dans les données sources (horodatage, numéro de séquence ou colonne de version)
• Gestion de l’état pour surveiller la dernière position traitée
• Logique permettant de gérer les enregistrements en retard ou hors commande

L’extraction incrémentielle améliore considérablement l’efficacité des jeux de données volumineux. Au lieu de lire des millions de lignes, vous ne pouvez traiter que des milliers de modifications par exécution.

Extraction en streaming

L’extraction en continu fournit une capture de données en quasi temps réel via un traitement continu. Au lieu d’être exécutés selon une planification, les travaux de diffusion en continu restent actifs et traitent les enregistrements à mesure qu’ils arrivent.

Envisagez la diffusion en continu quand :

• Les processus métier nécessitent une actualisation des données mesurée en secondes ou en minutes
• Les systèmes sources publient des événements dans des bus de messages ou des flux de modification
• Vous devez réagir aux événements au fur et à mesure qu’ils se produisent

L’extraction de streaming nécessite une infrastructure toujours activée, mais offre la latence la plus faible pour la disponibilité des données.

Conception pour la capture de données modifiées

La capture de données modifiées (CDC) est un modèle d’extraction spécialisé qui capture les modifications individuelles au niveau des lignes, notamment les insertions, les mises à jour et les suppressions. Le CDC diffère d'une simple extraction incrémentielle, car il conserve le type d'opération pour chaque modification.

Lors de la conception pour le CDC, tenez compte de la façon dont votre système source produit des enregistrements de modification :

• Journaux des transactions de base de données : les bases de données, telles que SQL Server, peuvent exposer des modifications au niveau des lignes à l’aide de sa fonctionnalité de CDC basée sur le journal des transactions. Les systèmes en aval tels qu’Azure Databricks peuvent ensuite lire ces modifications et les traiter dans le cadre du pipeline d’ingestion.
• Flux de données modifiées : les tables Delta et certaines bases de données telles qu’Azure Cosmos DB fournissent un suivi des modifications intégré qui expose les modifications de ligne avec des métadonnées.
• Instantanés périodiques : certains systèmes ne prennent pas en charge le CDC continu, ce qui vous oblige à comparer des instantanés pour déterminer les modifications.

CDC active des cas d'utilisation qu'une extraction incrémentielle simple ne peut pas prendre en charge. Vous pouvez répliquer avec précision les suppressions, gérer les pistes d’audit et traiter les mises à jour qui modifient les colonnes clés.

Identifier les caractéristiques de type de fichier source

Lorsque les données arrivent en tant que fichiers plutôt qu’à partir de systèmes transactionnels, le format de fichier influence votre conception d’ingestion. Chaque format a des caractéristiques distinctes qui affectent le traitement.

Formats textuels

Les fichiers CSV et JSON sont des formats sources courants, car ils sont lisibles par l’homme et largement pris en charge. Toutefois, ils présentent des défis pour un traitement efficace :

• Variabilité du schéma : les fichiers peuvent avoir des ordres de colonnes incohérents, des champs manquants ou des variantes de type de données
• Aucune efficacité de compression : les formats de texte consomment généralement plus de stockage que les alternatives binaires
• Surcharge d’analyse : chaque valeur nécessite une conversion de texte en type pendant les lectures

Utilisez des formats textuels lorsque les systèmes sources peuvent uniquement produire ces formats ou lorsque les volumes de données sont suffisamment petits pour que les problèmes d’efficacité ne s’appliquent pas.

Formats en colonnes

Les fichiers Parquet et ORC stockent les données au format columnar, ce qui permet d’exécuter des requêtes analytiques efficaces. Ces formats offrent :

• Compression : le stockage en colonnes obtient de meilleurs ratios de compression en regroupant des valeurs similaires
• Élimination de colonnes : les requêtes lisent uniquement les colonnes dont elles ont besoin, ce qui réduit les E/S
• Schéma incorporé : le fichier contient des métadonnées décrivant les noms et les types de colonnes

Concevez votre ingestion pour favoriser les formats sources en colonnes lorsque vous avez le contrôle sur la façon dont les systèmes en amont exportent des données.

Formats semi-structurés

Les fichiers JSON XML et imbriqués représentent des données hiérarchiques qui ne correspondent pas à une structure tabulaire plate. Lors de l’ingestion de données semi-structurées :

• Planifiez l’extraction ou la définition du schéma.
• Déterminez s’il faut aplatir la structure ou conserver l’imbrication.
• Comptez des structures de document variables au sein de la même source.

Considérations relatives à la connexion à la source de données

La configuration de la source de données définit la façon dont Azure Databricks se connecte et s’authentifie avec les systèmes sources. Votre conception doit traiter la sécurité des connexions, la gestion des informations d’identification et les modèles d’accès.

Sources de stockage d’objets cloud

Le stockage cloud (Azure Data Lake Storage, Amazon S3 ou Google Cloud Storage) sert de zone d’atterrissage la plus courante pour l’ingestion. Lors de la configuration des connexions de stockage :

• Utilisez des emplacements externes du catalogue Unity pour régir l’accès aux chemins de stockage.
• Configurez les méthodes d’authentification appropriées (identité gérée, principal de service ou identifiants de stockage).
• Concevoir des structures de dossiers qui prennent en charge un traitement incrémentiel efficace.

La structure des dossiers a un impact significatif sur la façon dont Azure Databricks peut identifier et traiter efficacement de nouveaux fichiers. Tenez compte de ces modèles :

Partitionnement basé sur des dates : organisez les fichiers par hiérarchie de dates pour activer l’élagage de partition pendant les lectures incrémentielles :

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

Cette structure permet aux requêtes d’analyser uniquement les partitions de date pertinentes plutôt que de répertorier tous les fichiers.

Organisation basée sur des sources : lors de l’ingestion à partir de plusieurs sources, séparez les données par le système source pour simplifier la logique de traitement :

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

Dossiers d’état de traitement : utilisez des dossiers distincts pour suivre l’état du traitement des fichiers :

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

Lors de la conception de structures de dossiers, tenez compte des éléments suivants :

• Surcharge de découverte de fichiers : structures plates avec des milliers de fichiers ralentissant les opérations de référencement. Les structures partitionnée réduisent les fichiers qu’Azure Databricks doit énumérer.
• Compatibilité du chargeur automatique : Le chargeur automatique Azure Databricks effectue efficacement le suivi des nouveaux fichiers dans le stockage cloud. Structurez les dossiers de façon à correspondre à la manière dont Auto Loader détecte les fichiers et effectue le contrôle de ces derniers.
• Extraction de colonne de partition : utilisez le partitionnement de style Hive (key=value) afin qu’Azure Databricks puisse extraire automatiquement les valeurs de partition en tant que colonnes sans analyser le contenu du fichier.

Sources de base de données

La connexion à des bases de données transactionnelles nécessite des considérations différentes de celles du stockage cloud :

• Connectivité réseau entre Azure Databricks et le serveur de base de données.
• Informations d’identification d’authentification stockées en toute sécurité (à l’aide de secrets plutôt que de valeurs codées en dur).
• Fonctionnalités de regroupement de connexions et de transfert de requête.
• Impact sur les performances du système source pendant l’extraction.

Sources de diffusion en continu

Les bus de messages et les flux d’événements (tels qu’Azure Event Hubs ou d’autres plateformes de messagerie courantes) nécessitent :

• Détails de connexion et authentification du courtier.
• Configuration du groupe de consommateurs pour le traitement parallèle.
• Gestion du décalage afin de suivre la position de consommation.
• Intégration du Registre de schémas pour la validation du format de message.

Sources d’application SaaS

Les applications d’entreprise telles que Salesforce, ServiceNow ou SAP exposent des données via des API avec des caractéristiques uniques :

• Limites de débit d’API qui limitent le débit d’extraction.
• Stratégies de pagination pour les jeux de résultats volumineux.
• Flux d’authentification (OAuth, clés API ou basées sur des certificats).
• Fonctionnalités de suivi des modifications ou de webhook disponibles.

Appliquer une infrastructure de conception pilotée par les exigences

La conception d’ingestion efficace commence par l’analyse des exigences avant de sélectionner des types d’extraction ou des formats de fichier. Utilisez l’infrastructure reproductible suivante pour guider vos décisions de conception.

Étape 1 : rassembler les exigences

Avant de prendre des décisions techniques, répondez à ces questions clés :

Catégorie d’exigence	Questions à répondre
Volume de données	Combien de données existent dans la source ? Combien de modifications entre les exécutions ? Quel est le taux de croissance ?
Exigences en matière de latence	Comment les données doivent-elles être fraîches pour les utilisateurs finaux ? Doit-on respecter des accords de niveau de service (SLA) ?
Capacités source	La source prend-elle en charge le suivi des modifications, le CDC ou uniquement une extraction complète ? Quels formats de fichier peuvent-ils produire ?
Qualité des données	Quelle est la fiabilité des données sources ? Quelle validation ou nettoyage est nécessaire ?
Contraintes réseau	Quelle bande passante existe entre la source et Azure Databricks ? Existe-t-il des exigences de pare-feu ou VPN ?
Coûts résultants	Quels sont les coûts de calcul, de stockage et de transfert de données de différentes approches ?

Étape 2 : mapper les exigences au type d'extraction

Utilisez votre analyse des exigences pour sélectionner le modèle d’extraction approprié :

Si vos exigences indiquent...	Ensuite, choisissez...
Petit volume de données (< 100 000 lignes), aucun suivi des modifications n’est disponible, une reconstruction simple acceptable	Extraction complète
Un volume de données volumineux, un indicateur de changement fiable existe (horodatage/séquence), une actualisation horaire ou quotidienne suffisante	Extraction incrémentielle
Actualisation en temps réel ou quasiment en temps réel requise, la source publie des événements, l’infrastructure de diffusion en continu disponible	Extraction en streaming
Il est nécessaire de capturer les suppressions et les types d’opérations; une piste d’audit est requise et la source prend en charge la capture du journal des transactions.	Extraction CDC

Étape 3 : Sélectionner le format de fichier source

Lorsque vous contrôlez le format source ou que vous devez choisir un format de zone de destination, adaptez le format selon vos besoins.

Si votre scénario implique...	Ensuite, préférez...
Jeux de données analytiques volumineux, requêtes en colonnes, besoin de compression	Parquet
Interopérabilité avec de nombreux systèmes, lisibilité humaine nécessaire	CSV ou JSON
Structures de données hiérarchiques ou imbriquées	JSON ou XML
Diffusion en continu à haute fréquence avec évolution du schéma	Avro avec le registre de schémas

Étape 4 : Valider votre conception

Avant d’implémenter, vérifiez que votre conception répond à ces problèmes :

• Le type d’extraction répond aux exigences de latence. Si ce n’est pas le cas, les consommateurs en aval reçoivent des données obsolètes, ce qui peut entraîner des décisions commerciales incorrectes ou des violations du contrat SLA.

• L’approche est mise à l’échelle pour gérer la croissance des données projetées. Si ce n’est pas le cas, les pipelines qui fonctionnent aujourd’hui peuvent échouer ou devenir trop lents à mesure que les volumes de données augmentent.

• Les fonctionnalités système sources prennent en charge votre modèle choisi. Si ce n’est pas le cas, le pipeline échoue au moment de l’exécution ou nécessite des solutions de contournement coûteuses qui ajoutent de la complexité.

• Les estimations des coûts respectent les contraintes budgétaires. Si ce n’est pas le cas, la solution peut être techniquement saine, mais financièrement insoutenable pour l’utilisation de la production.

• Les contrôles de qualité des données sont planifiés pour le pipeline. Si ce n’est pas le cas, les données non valides ou endommagées se propagent aux systèmes en aval, provoquant des erreurs ou des analyses incorrectes.

Appliquer le Cadre : Un Exemple Pratique

Une plateforme de commerce électronique doit ingérer des données d’ordre. Les commandes sont stockées dans une base de données PostgreSQL et l’entreprise nécessite des rapports horaires.

Étape 1 : Collecter les exigences :

• Volume : 50 000 nouvelles commandes par jour, 2 millions de lignes totales, 15% croissance annuelle.
• Latence : une actualité d'une heure est acceptable pour le reporting.
• Source : PostgreSQL prend en charge des requêtes basées sur des horodatages, mais ne propose pas de CDC natif.
• Qualité : les données sources sont validées à l’entrée ; nettoyage minimal nécessaire.
• Réseau : connectivité directe via Azure Private Link.
• Coût : réduire l’utilisation du calcul ; les coûts de stockage sont secondaires.

Étape 2 : mapper vers le type d'extraction :

Volume volumineux avec une colonne d’horodatage fiable et une exigence de latence horaire → extraction incrémentielle.

Pourquoi pas les autres ?

• Extraction complète : Le retraitement horaire de 2 millions de lignes gaspille des ressources de calcul quand seulement 2 000 commandes changent par heure.
• Diffusion en continu : une latence d’une heure ne justifie pas le coût de l’infrastructure de diffusion en continu always-on.
• CDC : PostgreSQL n'expose pas de CDC natif à partir du journal de transactions, et le cas d'usage ne requiert pas le suivi des suppressions ni des types d'opération.

Étape 3 - Sélectionner le format de fichier :

Les données atterrissent dans Azure Data Lake Storage pour le traitement → Parquet pour un stockage en colonnes efficace. Disposition partitionnée à date pour la découverte incrémentielle → /landing/orders/year=2025/month=11/day=28/.

Pourquoi pas les autres ?

• CSV/JSON : tailles de fichiers plus grandes, aucun avantage de compression et performances de requête plus lentes pour les charges de travail analytiques.
• Avro : Mieux adapté à la diffusion en continu avec l’évolution du schéma ; l’ingestion par lots n’a pas besoin de ses fonctionnalités orientées diffusion en continu.
• XML : ajoute la complexité de l’analyse sans avantages pour les données d’ordre tabulaire structurées.

Étape 4 - Valider la conception :

• ✓ L’incrémentiel horaire répond à une exigence de latence d’une heure.
• ✓ Traiter uniquement les modifications se met efficacement à l'échelle avec la croissance.
• ✓ La colonne PostgreSQL order_updated_at active les requêtes incrémentielles.
• • Le traitement de milliers et de millions de lignes réduit les coûts de calcul.

Décision finale : extraction incrémentielle à l’aide de la colonne timestamp, planifiée toutes les heures, avec des données déposées sous forme de fichiers Parquet dans Azure Data Lake Storage.

À partir de cette base basée sur les exigences, vous êtes prêt à évaluer les outils et méthodes de chargement spécifiques qui implémentent votre conception d’ingestion.