Qu’est-ce que Lakeflow Spark Declarative Pipelines ?

Lakeflow Spark Declarative Pipelines (SDP) est une infrastructure déclarative pour la création de pipelines de données par lots et de diffusion en continu dans SQL et Python. Ses concepts fondamentaux sont les pipelines, les flux, les tables de streaming, les vues matérialisées et les destinations, qui fonctionnent ensemble pour traiter les données grâce à une orchestration automatique et à des mises à jour incrémentielles.

Qu’est-ce que SDP ?

Lakeflow Spark Declarative Pipelines est une infrastructure déclarative pour le développement et l’exécution de pipelines de données par lots et de diffusion en continu dans SQL et Python. Lakeflow SDP se déploie et est interopérable avec les pipelines déclaratifs Apache Spark, tout en s’exécutant sur le runtime Databricks optimisé pour la performance, et l’API Pipelines déclaratifs flows Lakeflow Spark utilise la même API DataFrame que Apache Spark et Structured Streaming.

Les cas d’usage courants pour SDP sont les suivants :

• Ingestion incrémentielle de données à partir de sources telles que le stockage dans le cloud (Amazon S3, Azure ADLS Gen2 et Google Cloud Storage) et les bus de messages (Apache Kafka, Amazon Kinesis, Google Pub/Sub, Azure EventHub et Apache Pulsar).
• Transformations incrémentielles de traitement par lots et en flux avec des opérateurs avec et sans état.
• Traitement des flux en temps réel entre des systèmes transactionnels comme les bus de messages et les bases de données.

Pour plus d’informations sur le traitement déclaratif des données, consultez Procédures et traitement déclaratif des données dans Databricks.

Quels sont les avantages de SDP ?

La nature déclarative de SDP offre les avantages suivants par rapport au développement de processus de données avec les API Apache Spark et Spark Structured Streaming et à les exécuter avec Databricks Runtime à l’aide de l’orchestration manuelle via Lakeflow Jobs.

• Orchestration automatique : SDP orchestre automatiquement les étapes de traitement (appelées « flux ») pour garantir l’ordre d’exécution correct et le niveau maximal de parallélisme pour des performances optimales. En outre, les pipelines réessayent automatiquement et efficacement les opérations après des échecs temporaires. Le processus de nouvelle tentative commence par l’unité la plus granulaire et la plus rentable : la tâche Spark. Si la nouvelle tentative au niveau de la tâche échoue, SDP effectue une nouvelle tentative de flux, puis enfin l’intégralité du pipeline si nécessaire.
• Traitement déclaratif : SDP fournit des fonctions déclaratives qui peuvent réduire des centaines ou même des milliers de lignes de code Spark et Structured Streaming manuels à quelques lignes seulement. L’API SDP AUTO CDC simplifie le traitement des événements de capture de données modifiées (CDC) avec prise en charge de SCD Type 1 et SCD Type 2. Il élimine la nécessité d'un codage manuel pour gérer les événements hors ordre, et il ne nécessite pas de compréhension de la sémantique du streaming ou des concepts tels que les filigranes.
• Traitement incrémentiel : SDP fournit un moteur de traitement incrémentiel pour les vues matérialisées. Pour l’utiliser, vous écrivez votre logique de transformation avec la sémantique de traitement par lots, et le moteur traite uniquement les nouvelles données et les modifications apportées aux sources de données dans la mesure du possible. Le traitement incrémentiel réduit le retraitement inefficace lorsque de nouvelles données ou modifications se produisent dans les sources et élimine la nécessité d’un code manuel pour gérer le traitement incrémentiel.

Concepts clés

Le diagramme ci-dessous illustre les concepts les plus importants des pipelines déclaratifs Spark Lakeflow.

Datasets

Un pipeline produit trois types de jeux de données, chacun avec une sémantique de traitement différente :

Une table de streaming est un type de table gérée du catalogue Unity qui sert également de cible de streaming. Une table de diffusion en continu peut avoir un ou plusieurs flux de streaming (Append, AUTO CDC) écrits dans celui-ci. Vous pouvez définir des flux de streaming explicitement et séparément de leur table de diffusion en continu cible, ou implicitement dans le cadre d’une définition de table de diffusion en continu.

Une vue matérialisée est également une forme de table gérée du catalogue Unity et constitue une cible de traitement par lots. Une vue matérialisée peut avoir un ou plusieurs flux de vue matérialisés écrits dans celui-ci. Les vues matérialisées diffèrent des tables de diffusion en continu dans lesquelles vous définissez toujours les flux implicitement dans le cadre de la définition de vue matérialisée.

Pour plus d’informations, consultez les tables de streaming et les vues matérialisées.

Quand utiliser des vues, des vues matérialisées et des tables de streaming

Lors de l’implémentation de requêtes de pipeline, choisissez le type de jeu de données qui convient le mieux à votre cas d’usage.

Envisagez d’utiliser une vue pour :

• Décomposez une requête volumineuse ou complexe en requêtes plus faciles à gérer.
• Validez les résultats intermédiaires à l’aide des attentes.
• Réduisez les coûts de stockage et de calcul pour les résultats que vous n’avez pas besoin de conserver. Étant donné que les tables sont matérialisées, elles nécessitent des ressources de calcul et de stockage supplémentaires.

Utilisez une vue matérialisée dans les cas suivants :

• Plusieurs requêtes en aval consomment la table. Étant donné qu’une vue matérialisée met en cache ses résultats, les requêtes en aval lisent les résultats précomputés au lieu de réinscrire la requête sur chaque accès.
• D’autres pipelines, travaux ou requêtes consomment la table. Comme une vue matérialisée est matérialisée dans une table Unity Catalog, les utilisateurs extérieurs au pipeline qui la définit peuvent l’interroger. Les vues ne sont pas matérialisées. Vous pouvez donc les utiliser uniquement dans le même pipeline.
• Vous souhaitez inspecter les résultats d’une requête pendant le développement. Étant donné qu’une vue matérialisée est matérialisée et peut être interrogée en dehors du pipeline, vous pouvez valider la validité des calculs au cours du développement. Après la validation, convertissez les requêtes qui ne nécessitent pas de matérialisation en vues.
• Votre requête effectue des agrégations ou des jointures, ou les données sources peuvent changer en raison de mises à jour et de suppressions plutôt que de croître uniquement. Une vue matérialisée maintient ses résultats cohérents avec l’état actuel des données sources, tandis qu’une table de diffusion en continu est conçue pour les sources d’ajout uniquement et traite chaque enregistrement une seule fois.

Utilisez une table de streaming dans les cas suivants :

• Une requête est définie sur une source de données qui augmente en continu ou de manière incrémentielle.
• Les résultats de requête doivent être calculés de manière incrémentielle.
• Le pipeline a besoin d’un débit élevé et d’une faible latence.

Flows

Un flux est le concept de traitement des données de base dans SDP qui prend en charge la sémantique de streaming et de traitement par lots. Un flux lit les données d’une source, applique une logique de traitement définie par l’utilisateur et écrit le résultat dans une cible. SDP partage le même type de flux de streaming (Append, Update, Complete) que Spark Structured Streaming. (Actuellement, seuls les flux d’ajout et de mise à jour sont exposés.) Pour plus d’informations, consultez les modes de sortie dans Structured Streaming.

Les pipelines déclaratifs Spark Lakeflow fournissent également des types de flux supplémentaires :

• AUTO CDC est un flux de streaming unique dans Lakeflow SDP qui gère les événements CDC hors ordre et prend en charge à la fois les SCD Type 1 et SCD Type 2. Les CDC automatiques ne sont pas disponibles dans les pipelines Apache Spark déclaratifs.
• La vue matérialisée est un flux de lots dans SDP qui traite uniquement les nouvelles données et les modifications apportées aux tables sources dans la mesure du possible.

Pour plus d’informations, consultez Charger et traiter des données de manière incrémentielle avec les flux de pipelines déclaratifs Spark Lakeflow.

Sinks

Un puits est un objectif de streaming pour un pipeline et prend en charge les tables Delta, les sujets Apache Kafka, les sujets Azure EventHubs et les sources de données Python personnalisées. Un récepteur peut avoir un ou plusieurs flux de streaming (Append, Update) écrits dans celui-ci.

Pour plus d’informations, consultez Récepteurs dans les pipelines déclaratifs Spark Lakeflow.

Pipelines

Un pipeline est l’unité de développement et d’exécution dans Lakeflow Spark Declarative Pipelines, et constitue le conteneur des flux, des tables de diffusion en continu, des vues matérialisées et des destinations que vous définissez. Vous utilisez SDP en définissant ces objets dans votre code source de pipeline, puis en exécutant le pipeline. Pendant que votre pipeline s’exécute, il analyse les dépendances de vos objets définis et orchestre automatiquement leur ordre d’exécution et de parallélisation.

Pour plus d’informations, consultez Qu’est-ce que les pipelines ?.

Vous pouvez également définir des vues matérialisées autonomes et des tables de streaming en dehors d’un pipeline, Azure Databricks gérant alors le pipeline pour vous. Pour comparer les deux approches, consultez pipelines autonomes et pipelines déclaratifs Lakeflow Spark.

Ingestion des données

Les pipelines prennent en charge toutes les sources de données disponibles dans Azure Databricks. Databricks recommande d’utiliser des tables de streaming pour la plupart des cas d’ingestion. Pour les fichiers dans le stockage d’objets cloud, le chargeur automatique fournit un chargement incrémentiel et idempotent. Pour les données en streaming, les pipelines peuvent ingérer directement depuis des bus de messages tels qu’Apache Kafka, Azure Event Hubs, Amazon Kinesis et Google Pub/Sub. Consultez Charger des données dans des pipelines.

Qualité des données

Les attentes sont des clauses facultatives sur les jeux de données qui valident les données au fur et à mesure qu’elles transitent par le pipeline. Vous définissez une attente en tant que contrainte booléenne SQL et spécifiez ce qui se passe lorsqu’un enregistrement échoue : avertir, supprimer l’enregistrement ou échouer la mise à jour. Voir Gérer la qualité des données avec les attentes de la chaîne de traitement.

Intégration delta

Toutes les tables créées et gérées par des pipelines sont des tables Delta. Ils offrent les mêmes garanties que Delta Lake, y compris les transactions ACID, le voyage dans le temps et l’application stricte du schéma. Les pipelines ajoutent des propriétés de table supplémentaires et effectuent une maintenance automatique à l’aide de l’optimisation prédictive, y compris les opérations OPTIMIZE et VACUUM. Voir Qu’est-ce que Delta Lake dans Azure Databricks ?.

Ressources additionnelles

• Tutoriel : Créer un pipeline ETL à l’aide de la capture de données modifiées
• Qu’est-ce que les pipelines ?
• Limitations du pipeline
• Informations de référence sur le développeur de pipelines