Pipelines déclaratifs Spark : pourquoi l'ingénierie des données doit devenir déclarative de bout en bout

Les équipes d'ingénierie des données sont soumises à une pression pour fournir des données de meilleure qualité plus rapidement, mais le travail de création et d'exploitation des pipelines devient de plus en plus difficile, et non plus facile. Nous avons interrogé des centaines de data engineers et étudié des millions de charges de travail réelles, et nous avons découvert quelque chose de surprenant : les data engineers passent la majorité de leur temps non pas à écrire du code, mais à gérer la charge opérationnelle générée par l'assemblage des outils. La raison est simple : les frameworks d'ingénierie des données existants obligent les data engineer à gérer manuellement l'orchestration, le traitement incrémentiel des données, la qualité des données et les rattrapages, toutes des tâches courantes pour les pipelines de production. À mesure que les volumes de données et les cas d'utilisation augmentent, cette charge opérationnelle s'alourdit, transformant l'ingénierie des données en un goulot d'étranglement pour l'entreprise plutôt qu'en un accélérateur.

Ce n'est pas la première fois que l'industrie se heurte à ce mur. Au début, le traitement des données nécessitait d'écrire un nouveau programme pour chaque question, ce qui ne montait pas en charge. Le SQL a changé cela en rendant les requêtes individuelles déclaratives: vous spécifiez quel résultat vous voulez, et le moteur détermine comment le calculer. Les bases de données SQL sont désormais au cœur de chaque entreprise.

Mais l'ingénierie des données ne se résume pas à l'exécution d'une seule query. Les pipelines mettent à jour de manière répétée plusieurs datasets interdépendants au fil du temps. Comme les moteurs SQL s'arrêtent à la limite de la requête, tout ce qui va au-delà (traitement incrémentiel, gestion des dépendances, remplissages, qualité des données, nouvelles tentatives) doit encore être assemblé manuellement. En montant en charge, le raisonnement sur l'ordre d'exécution, le parallélisme et les modes de défaillance devient rapidement la principale source de complexité.

Ce qui manque, c'est un moyen de déclarer le pipeline dans son ensemble. Les pipelines déclaratifs Spark (SDP) étendent le traitement déclaratif des données des requêtes individuelles aux pipelines entiers, ce qui permet à Apache Spark de les planifier et de les exécuter de bout en bout. Au lieu de déplacer manuellement les données entre les étapes, vous déclarez quels datasets vous souhaitez voir exister et SDP est responsable de la manière de les maintenir corrects au fil du temps. Par exemple, dans un pipeline qui calcule les Ventes hebdomadaires, SDP déduit les dépendances entre les ensembles de données, élabore un plan d'exécution unique et met à jour les résultats dans le bon ordre. Il traite automatiquement uniquement les données nouvelles ou modifiées, exprime les règles de qualité des données en ligne et gère les rattrapages et les données tardives sans intervention manuelle. Parce que SDP comprend la sémantique des requêtes, il peut valider les pipelines en amont, s'exécuter en toute sécurité en parallèle et récupérer correctement après des échecs — des capacités qui nécessitent des API déclaratives de premier ordre, sensibles aux pipelines, intégrées directement dans Apache Spark.

L'ingénierie des données déclarative de bout en bout dans SDP offre de puissants avantages :

• Productivité accrue : les ingénieurs de données peuvent se concentrer sur l'écriture de la logique métier au lieu du code de liaison.
• Coûts réduits : le framework gère automatiquement l'orchestration et le traitement incrémentiel des données, ce qui le rend plus rentable que les pipelines écrits manuellement.
• Réduction de la charge opérationnelle : Les cas d'usage courants tels que les rattrapages, la qualité des données et les nouvelles tentatives sont intégrés et automatisés.

Pour illustrer les avantages de l'ingénierie des données déclarative de bout en bout, commençons par un pipeline de Ventes hebdomadaire écrit en PySpark. Comme PySpark n'est pas déclaratif de bout en bout, nous devons encoder manuellement l'ordre d'exécution, le traitement incrémentiel et la logique de qualité des données, et nous appuyer sur un orchestrateur externe tel qu'Airflow pour les nouvelles tentatives, les alertes et le monitoring (omis ici par souci de concision).

Ce pipeline, exprimé sous forme de projet SQL dbt, souffre de nombreuses limitations similaires : nous devons toujours coder manuellement le traitement incrémentiel des données, la qualité des données est gérée séparément et nous devons toujours nous appuyer sur un orchestrateur tel qu'Airflow pour les nouvelles tentatives et la gestion des échecs :

Réécrivons ce pipeline en SDP pour en explorer les avantages. Tout d'abord, installons SDP et créons un nouveau pipeline :

Ensuite, définissez votre pipeline avec le code suivant. Notez que nous mettons en commentaire l'API d'attente de qualité des données expect_or_drop, car nous travaillons avec la communauté pour la rendre open source :

Pour exécuter le pipeline, saisissez la commande suivante dans votre terminal :

Nous pouvons même valider notre pipeline en amont sans avoir à l'exécuter grâce à cette commande : c'est pratique pour détecter les erreurs de syntaxe et les incohérences de schéma :

Les backfills deviennent beaucoup plus simples : pour effectuer un backfill de la table raw_sales, exécutez cette commande :

Le code est beaucoup plus simple : seulement 20 lignes qui fournissent tout ce pour quoi les versions PySpark et dbt nécessitent des outils externes. Nous bénéficions également de ces avantages puissants :

• Traitement automatique et incrémentiel des données. Le framework suit quelles données ont été traitées et ne lit que les enregistrements nouveaux ou modifiés. Aucune requête MAX, aucun fichier de point de contrôle, ni aucune logique conditionnelle ne sont nécessaires.
• Qualité des données intégrée. Le décorateur @dp.expect_or_drop met automatiquement en quarantaine les enregistrements incorrects. Dans PySpark, nous avons manuellement divisé et écrit les bons/mauvais enregistrements dans des tables distinctes. Dans dbt, nous avions besoin d'un modèle distinct et d'un traitement manuel.
• Suivi automatique des dépendances. Le framework détecte que weekly_sales dépend de raw_sales et orchestre automatiquement l'ordre d'exécution. Aucun orchestrateur externe n'est nécessaire.
• Nouvelles tentatives et monitoring intégrés. Le framework gère les échecs et offre une observabilité via une interface utilisateur intégrée. Aucun outil externe requis.

Le SDP dans Apache Spark 4.1 possède les fonctionnalités suivantes qui en font un excellent choix pour les pipelines de données :

• Des API Python et SQL pour définir des datasets
• Prise en charge des requêtes par lots et en streaming
• Suivi automatique des dépendances entre les datasets et mises à jour parallèles efficaces
• CLI pour structurer, valider et exécuter des pipelines localement ou en production

Nous sommes enthousiasmés par la feuille de route de SDP, qui est développée de manière ouverte avec la communauté Spark. Les prochaines versions de Spark s'appuieront sur cette base avec la prise en charge de l'exécution continue et d'un traitement incrémentiel plus efficace. Nous prévoyons également d'intégrer des fonctionnalités de base comme le Change Data Capture (CDC) dans SDP, qui seront façonnées par des cas d'utilisation réels et les retours de la communauté. Notre objectif est de faire de SDP une base partagée et extensible pour la création de pipelines de traitement par lots (batch) et en flux (streaming) fiables à travers l'écosystème Spark.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original