Traçabilité des données Spark SQL : Traçabilité des colonnes pour les pipelines Spark

Traçabilité des données Spark SQL est la carte au niveau des colonnes de la façon dont les données circulent dans votre code Spark SQL : quelles colonnes sources alimentent chaque table écrite par un CRÉER LA TABLE ... COMME SÉLECTION ou INSERER ÉCRASERet à travers lesquels des vues temporaires, des jointures, des fonctions et des filtres sont utilisés en cours de route. Gudu SQLFlow Ce module génère cette carte en analysant statiquement votre requête Spark SQL grâce à un analyseur syntaxique dédié au dialecte Spark ; aucun cluster à instrumenter, aucun écouteur à connecter et aucune exécution de tâche n'est nécessaire. Collez le code SQL et obtenez le diagramme de lignage.

Écouteurs d'exécution vs analyse statique : deux façons d'obtenir la lignée Spark

Dans l'univers Spark, il existe deux approches fondamentalement différentes en matière de lignée, et la plupart des équipes finissent par avoir besoin des deux.

Lignée d'exécution L'approche adoptée par OpenLineage et son intégration Spark consiste à connecter un écouteur à la session Spark et à émettre des événements de traçabilité à chaque exécution de tâche. Elle est particulièrement performante : elle enregistre les opérations exécutées, leur date et heure d'exécution, ainsi que les jeux de données concernés, grâce à des métadonnées d'exécution inaccessibles par l'analyse statique. Si vous vous demandez « quelles opérations le pipeline d'hier soir a-t-il effectuées ? », la traçabilité en temps réel vous apporte la réponse.

lignée statique L'approche de SQLFlow consiste à analyser le texte SQL lui-même et à en déduire la lignée à partir du code, comme le ferait un compilateur. Cela permet de couvrir tout ce que la capture dynamique ne peut pas faire structurellement.

• Requête SQL que vous n'avez pas encore exécutée. Un nouveau pipeline dans une demande d'extraction, un script hérité d'une autre équipe, une série de tâches planifiées trimestriellement — aucun de ces éléments n'émet d'événements d'exécution avant leur exécution, éventuellement sur des données de production.
• Revue de code. Les réviseurs peuvent consulter le graphique complet des dépendances au niveau des colonnes d'une modification avant de l'approuver, au lieu de découvrir son impact après le déploiement.
• Audits de migration. Lorsque vous migrez des charges de travail vers Spark (généralement depuis Hive), vous avez besoin du graphe de dépendances de entier Le code source, y compris les tâches qui ne s'exécutent qu'en fin de mois, est analysé statiquement en une seule passe.

	Écouteurs d'exécution (OpenLineage)	Analyse statique (SQLFlow)
Lignée capturée	Pour chaque exécution de tâche, au fur et à mesure de son exécution	À partir du texte SQL, avant toute exécution
Nécessite	Écouteur configuré sur la session Spark ; les tâches doivent s'exécuter	Les fichiers SQL, plus les métadonnées de schéma facultatives
Couvre le code non exécuté	Non — pas de course, pas d'événement	Oui — demandes de fusion, listes d'attente, tâches rarement exécutées
Métadonnées d'exécution (durée, versions)	Oui	Non — uniquement au niveau du code
Utilisation typique	Observabilité opérationnelle des pipelines en production	Analyse d'impact, revue de code, audits de migration, documentation de conformité

Ces deux types de données sont complémentaires, et non concurrents. La traçabilité d'exécution décrit le déroulement des opérations ; la traçabilité statique décrit le comportement du code. Les adaptateurs d'exportation de SQLFlow pour DataHub, Microsoft Purview et OpenMetadata permettent d'intégrer la traçabilité statique dans le même catalogue que les événements d'exécution, afin que les deux vues soient accessibles simultanément.

Exemple : une chaîne de vues temporaires dans un CTAS

Le modèle qui met en échec les outils de traçabilité naïfs dans Spark SQL est la chaîne de vues temporaires. Les notebooks et les tâches exécutent régulièrement des étapes logiques à travers cette chaîne. CRÉER OU REMPLACER LA VUE TEMPORAIRE étapes avant une finale CRÉER LA TABLE ... COMME SÉLECTIONVoici un exemple concis mais réaliste :

CRÉER OU REMPLACER LA VUE TEMPORAIRE clean_events COMME SELECT CAST(event_time AS TIMESTAMP) AS event_ts, user_id, lower(event_name) AS event_name, amount FROM raw.events WHERE event_date >= date_sub(current_date(), 30); CRÉER OU REMPLACER LA VUE TEMPORAIRE user_daily COMME SELECT user_id, to_date(event_ts) AS event_day, SUM(amount) AS daily_spend FROM clean_events WHERE event_name = 'purchase' GROUP BY user_id, to_date(event_ts); CRÉER LA TABLE analytics.user_spend_30d USING PARQUET COMME SELECT u.user_id, u.segment, d.event_day, d.daily_spend FROM user_daily d JOIN dim.users u ON u.user_id = d.user_id;

Demandez « où est-ce que analytics.user_spend_30d.daily_spend « D’où viennent-ils ? » et la réponse honnête nécessite de résoudre deux couches de vue : dépenses quotidiennes est SOMME(clean_events.amount), et clean_events.amount est montant.événements.brutSQLFlow effectue précisément cette résolution et affiche la chaîne complète. montant.événements.brut à travers événements de nettoyage et utilisateur_quotidien dans la table finale, avec le SOMME agrégation attachée au bord où elle se produit.

Il capture également ce que la plupart des outils laissent complètement de côté : lignée indirecteLes colonnes date_événement, nom_événement, et la clé de jointure ID de l'utilisateur n'apparaissent jamais dans dépenses quotidiennes, pourtant tous les trois déterminent sa valeur — modifiez le filtre de 30 jours ou le 'achat' Chaque prédicat et chaque valeur numérique du résultat sont modifiés. SQLFlow modélise ces modifications comme un type de relation distinct et activable, permettant ainsi de visualiser le flux de données pur ou l'ensemble de la surface d'impact. Pour une analyse des modifications de schéma, c'est la surface d'impact qui est la vue la plus pertinente.

Spark SQL construit SQLFlow résout

SQLFlow intègre un analyseur syntaxique pour le dialecte Spark SQL — l'un des 39 analyseurs spécifiques à chaque dialecte, et non une grammaire ANSI générique à laquelle on aurait ajouté des mots-clés Spark. Pour Spark SQL en particulier, il gère les instructions qui conservent la trace des requêtes.

• CRÉER LA TABLE ... COMME SÉLECTION (CTAS) — l'élément essentiel des pipelines par lots Spark ; chaque colonne de sortie est retracée jusqu'à ses sources via l'intégralité de la requête SELECT.
• INSÉRER DANS et INSERER ÉCRASER — y compris le mappage des colonnes positionnelles entre la liste SELECT et le schéma de la table cible.
• CRÉER OU REMPLACER LA VUE TEMPORAIRE — Les vues temporaires sont résolues et chaînées, de sorte que la lignée circule à travers les couches intermédiaires au lieu de s'y arrêter.
• CTE, sous-requêtes et SÉLECTIONNER * — Les références de colonnes sont résolues via des expressions de table communes et des sous-requêtes imbriquées, et les expressions en forme d'étoile sont développées en colonnes réelles lorsque les métadonnées du schéma sont disponibles.
• Fonctions, conversions de type et opérateurs ensemblistes — l'historique de chaque colonne de sortie indique les transformations qu'elle a subies. dépenses quotidiennes ce n'est pas seulement « à partir du montant » mais « à partir de ». montant via SOMME“.

Sous le capot, on trouve le moteur d'analyse syntaxique SQL général, une interface de compilation SQL commerciale développée depuis le milieu des années 2000 et validée à l'aide d'environ 13 600 jeux de données de test par dialecte. La qualité du lignage est avant tout un problème d'analyse syntaxique, et c'est ce corpus qui empêche les cas limites de syntaxe Spark de produire silencieusement des erreurs de syntaxe.

Où la traçabilité des données Spark SQL s'intègre-t-elle dans votre architecture ?

Spark fonctionne rarement de manière isolée. Ses tables résident généralement dans un métastore Hive, et une part croissante des charges de travail Spark s'exécute sur Databricks. SQLFlow les traite comme des dialectes à part entière, analysés séparément :

• Vous migrez des tâches Hive vers Spark ? Analysez le code HQL existant avec… Analyseur de lignage des données Hive et les tâches réécrites avec l'analyseur Spark, et comparez les deux graphes de dépendance pour vérifier qu'aucun élément n'a été omis lors de la traduction.
• Vous utilisez Databricks ? Analyseur de lignage de données Databricks couvre le dialecte SQL de Databricks, qui a divergé du langage open-source Spark SQL d'une manière qu'une grammaire partagée unique ne gère pas correctement.
• Environnement mixte ? SQLFlow analyse les 39 dialectes pris en charge dans un seul référentiel de lignage. Ainsi, une tâche Spark lisant une table produite par une tâche Snowflake apparaît sous la forme d'un graphe continu. Voir la Présentation de l'outil de traçabilité des données SQL pour avoir une vue d'ensemble.

Les entrées sont flexibles : coller du code SQL, importer des fichiers, récupérer des métadonnées via JDBC ou importer un manifeste dbt pour les projets dbt sur Spark. La sortie est un diagramme interactif et détaillé, ainsi que des exportations aux formats JSON, CSV et PNG et une API REST pour l’automatisation — par exemple, l’analyse du code SQL modifié lors d’une requête d’extraction dans le cadre d’une étape d’intégration continue.

Déploiement et mise à l'échelle

SQLFlow Cloud propose une version gratuite pour une utilisation interactive ; la version premium coûte 49,99 £/mois. Les équipes dont les requêtes SQL ne peuvent pas quitter le réseau peuvent utiliser cette option. SQLFlow sur site — Docker ou Kubernetes, compatible avec les environnements isolés, $500/mois ou $4 800 en une seule fois par type de base de données sélectionné. Dans tous les cas, SQLFlow effectue une analyse statique du code SQL uniquement : il ne lit jamais les lignes de vos tables. Les déploiements en entreprise permettent d’effectuer des analyses par lots de plus de 100 bases de données et de plus d’un million de colonnes, avec des analyses incrémentales et un référentiel de lignage persistant.

Foire aux questions

Ai-je besoin d'un cluster Spark en fonctionnement pour obtenir la lignée ?

Non. SQLFlow analyse le texte Spark SQL de manière statique. Vous pouvez analyser un script qui n'a jamais été exécuté (une demande d'extraction, une livraison fournisseur, une migration en attente) et obtenir la même traçabilité au niveau des colonnes que pour du code en production.

En quoi cela diffère-t-il de l'intégration Spark d'OpenLineage ?

OpenLineage capture la lignée en temps réel grâce à un écouteur sur la session Spark, ce qui est idéal pour observer le déroulement exact des tâches en cours. SQLFlow, quant à lui, extrait la lignée directement du code SQL, couvrant ainsi également le code non exécuté. Il prend en charge les revues avant fusion et les audits de migration, et ne nécessite aucun accès au cluster. Ces deux outils sont complémentaires ; SQLFlow peut exporter la lignée vers DataHub, Purview ou OpenMetadata, en plus de la lignée d'exécution.

SQLFlow peut-il retracer la lignée à travers les vues temporaires ?

Oui. Chaînes de CRÉER OU REMPLACER LA VUE TEMPORAIRE Les instructions sont résolues de bout en bout, de sorte qu'une colonne dans un CTAS final remonte à travers chaque vue intermédiaire jusqu'à la table source physique, les fonctions et les agrégations étant appliquées à chaque étape.

Databricks SQL est-il identique à Spark SQL dans ce cas ?

Non — SQLFlow les analyse avec des analyseurs syntaxiques distincts. Databricks SQL possède ses propres extensions syntaxiques, et donc sa propre grammaire. Si vous utilisez Databricks, utilisez le dialecte Databricks ; pour Spark open source, EMR ou les clusters autogérés, utilisez le dialecte Spark SQL.

Est-ce que SQLFlow lit mes données ?

Non. Il analyse le code SQL et, en option, les métadonnées du schéma (définitions des tables et des colonnes). Les données des lignes ne sont jamais consultées. En mode sur site, même le texte SQL reste au sein de votre réseau.

Quel est le coût du traçage Spark SQL avec SQLFlow ?

SQLFlow Cloud est gratuit au départ ; la version Premium coûte 49,99 £/mois. La version sur site coûte 500 £/mois ou 4 800 £ (paiement unique) par type de base de données sélectionné, installable sur deux serveurs. Voir tarification pour plus de détails.