Traçabilité des données Databricks : Traçabilité au niveau des colonnes pour Spark SQL et Delta

Traçabilité des données Databricks Il s'agit de la cartographie au niveau des colonnes de la façon dont les données circulent dans votre code Spark SQL et Delta Lake : quelles colonnes sources alimentent chaque table cible à travers vos couches bronze, argent et or, et quelles transformations (jointures, agrégations, etc.) sont appliquées. FUSIONNER La logique se met en place au fur et à mesure. Unity Catalog capture automatiquement la lignée des charges de travail qui y transitent ; Gudu SQLFlow Il couvre tout le reste en analysant le SQL lui-même, ce qui en fait l'outil idéal pour les migrations vers Databricks, le SQL exécuté en dehors d'Unity Catalog et les environnements qui s'étendent sur Databricks et d'autres plateformes.

Quand a-t-on besoin de plus que la simple filiation avec Unity Catalog ?

Unity Catalog est vraiment performant : pour les requêtes et les tâches exécutées via cette plateforme, Databricks capture automatiquement la traçabilité, sans outil supplémentaire. Si l'ensemble de votre infrastructure est hébergé sur un seul compte Databricks et que toutes vos charges de travail passent par Unity Catalog, commencez par là.

L'écart est structurel, et non un bug : la traçabilité capturée à l'exécution n'existe que pour le code déjà exécuté dans l'environnement de capture. Il reste donc quatre situations où les équipes optent pour une approche d'analyse syntaxique SQL :

• Avant que le code ne s'exécute sur Databricks. Vous migrez depuis Oracle, Teradata ou SQL Server et vous avez besoin du graphe de dépendances de l'ancien SQL — et du SQL Databricks réécrit — avant toute exécution en production.
• SQL qui n'interagit jamais avec Unity Catalog. SQL de notebook exporté vers des fichiers, scripts dans un dépôt Git, SQL généré par des planificateurs externes ou des outils ETL, code sur des espaces de travail non encore mis à niveau vers Unity Catalog.
• Domaines multiplateformes. Les pipelines qui démarrent dans SQL Server, effectuent des transformations dans Databricks et aboutissent dans Snowflake nécessitent un graphe de traçabilité unique pour ces trois environnements. SQLFlow intègre des analyseurs syntaxiques spécifiques à chaque dialecte pour 39 bases de données : Databricks et Snowflake. Spark SQL parmi eux — ainsi, toute la chaîne est analysée avec un seul moteur.
• Lignée dans un catalogue que vous utilisez déjà. Si votre organisation utilise DataHub, Microsoft Purview ou OpenMetadata comme standard plutôt que l'interface utilisateur de Databricks, vous avez besoin d'une traçabilité permettant l'exportation vers ces plateformes. SQLFlow inclut des adaptateurs d'exportation pour ces trois systèmes.

Ces deux approches sont complémentaires. Unity Catalog indique ce qui a été exécuté ; l’analyse statique SQL indique ce que fait le code, y compris le code qui n’a pas encore été exécuté.

Comment SQLFlow analyse le SQL de Databricks

Gudu SQLFlow is an automated Outil de traçabilité des données SQL built on the General SQL Parser, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. It ships a dedicated Databricks dialect parser in the Spark SQL family — not a generic ANSI grammar — so Databricks-specific constructs are parsed as first-class syntax rather than approximated.

L'analyse est entièrement statique. SQLFlow lit le texte SQL et, éventuellement, les métadonnées du schéma ; il ne lit jamais les lignes de vos tables Delta. Édition sur site Le texte SQL lui-même ne quitte jamais votre réseau : il est déployé sur Docker ou Kubernetes et s’exécute de manière isolée du réseau. Pour chaque instruction, l’analyseur syntaxique construit un modèle sémantique complet, résolvant chaque référence de colonne via des CTE, des sous-requêtes, des vues, etc. SÉLECTIONNER * Après l'expansion, l'analyseur de flux de données extrait les relations source-cible au niveau de la granularité des colonnes.

Vous pouvez l'alimenter avec du SQL, quel que soit son format : instructions collées, fichiers importés, métadonnées de base de données via JDBC ou manifeste dbt pour les projets dbt ciblant Databricks. Le résultat est un diagramme interactif et explorable, ainsi que des données de traçabilité structurées aux formats JSON, CSV, PNG ou réponse d'une API REST.

Exemple : lignée au niveau des colonnes via une fusion Delta

FUSIONNER DANS est le pilier des pipelines Delta Lake, et une instruction où la traçabilité au niveau des tables est presque inutile, car une seule fusion lit, fait correspondre, met à jour et insère en une seule opération. Prenons l'exemple d'une insertion/mise à jour de la couche de référence :

FUSIONNER DANS gold.customer_ltv AS t UTILISANT ( SÉLECTIONNER o.customer_id, SUM(o.amount) AS lifetime_value, MAX(o.order_ts) AS last_order_ts DE silver.orders o OÙ o.status = 'completed' GROUPER PAR o.customer_id ) AS s SUR t.customer_id = s.customer_id LORSQUE CORRESPONDANCE ALORS METTRE À JOUR DÉFINIR t.lifetime_value = s.lifetime_value, t.last_order_ts = s.last_order_ts LORSQUE NON CORRESPONDANCE ALORS INSÉRER (customer_id, lifetime_value, last_order_ts) VALUES (s.customer_id, s.lifetime_value, s.last_order_ts);

SQLFlow résout cela en relations précises au niveau des colonnes. valeur vie client gold.customer_ltv.lifetime_value dérive de montant des commandes d'argent à travers SOMME(), par le biais des deux MISE À JOUR et le INSÉRER bifurquer. dernière_commande_ts dérive de argent.commandes.commande_ts à travers MAX(). L'alias de la sous-requête s est résolu ; la lignée pointe vers la table source réelle, et non vers la table intermédiaire.

Il est tout aussi important de savoir ce que SQLFlow classe comme lignée indirecte: statut des commandes d'argent n'atteint jamais la cible, mais le OÙ Le filtre appliqué façonne chaque valeur fusionnée, et identifiant_client conduit à la fois le GROUPER PAR et la condition de correspondance. SQLFlow modélise le flux de données direct et l'influence indirecte comme des types de relations distincts et activables séparément. La plupart des outils concurrents ne font pas cette distinction, et c'est précisément ce dont vous avez besoin lorsqu'on vous demande « est-ce que la modification du statut « Rupture de vocabulaire concernant la valeur vie client ? » La réponse honnête est oui, et seule une analyse de la lignée prenant en compte l’impact le démontre.

Migration vers (ou depuis) Databricks

La migration est l'une des raisons les plus fréquentes pour lesquelles les équipes analysent Databricks SQL en dehors de la plateforme. Unity Catalog ne peut pas vous aider à planifier une migration, car la traçabilité nécessaire décrit du code qui n'a jamais été exécuté sur Databricks. Un workflow basé sur un analyseur syntaxique permet, en revanche :

1. Cartographier le domaine source. Exécutez votre code SQL existant (Oracle, Teradata, SQL Server, y compris les procédures stockées et le code SQL dynamique qu'elles contiennent) via SQLFlow pour obtenir le graphe de dépendances réel. Vous saurez ainsi quelles bases de données migrer en priorité et quelles bases sont obsolètes.
2. Validez la réécriture. Analysez le code SQL Databricks réécrit à l'aide de l'analyseur syntaxique Databricks et comparez les graphes de traçabilité. Si les sources d'une colonne cible ont changé entre la version Teradata et la version Delta, vous avez détecté un bug de réécriture avant sa mise en production.
3. Vérifiez qu'aucun élément n'est orphelin. Après la bascule, effectuez une analyse par lots des deux environnements — SQLFlow gère des environnements de plus de 100 bases de données et plus d'un million de colonnes, avec des analyses incrémentales dans un référentiel de lignage persistant.

Cette même fonctionnalité interdialecte fonctionne en sens inverse ou latéralement : si une partie de votre entrepôt migre vers Snowflake, Flux de travail de lignée Snowflake Les deux plateformes utilisent le même moteur, ce qui permet d'obtenir un graphique comparable.

Exportation de la traçabilité des données Databricks vers DataHub, Purview ou OpenMetadata

Les plateformes privilégiant le catalogue sont d'excellents systèmes d'enregistrement des métadonnées, et de nombreuses organisations en imposent une pour l'ensemble de leurs plateformes de données. SQLFlow s'intègre comme moteur de traçabilité sous-jacent : il analyse le SQL, calcule la traçabilité au niveau des colonnes et la traçabilité indirecte, puis transmet le résultat via des adaptateurs d'exportation dédiés. DataHub, Microsoft Purview et OpenMetadataLes exportations JSON et CSV, ainsi qu'une API REST, permettent de couvrir tous les besoins spécifiques.

C'est aussi la solution pratique au problème multiplateforme : il est difficile de fusionner les lignées produites par deux extracteurs différents avec deux modèles différents en un seul graphe. Un seul analyseur syntaxique produisant un graphe unique pour les 39 dialectes, exporté vers le catalogue que vous utilisez déjà, résout ce problème.

Façons de le faire fonctionner

Option	Idéal pour	Notes
SQLFlow Cloud	Je le teste aujourd'hui sur une vraie base de données Databricks SQL.	Version gratuite dans le navigateur ; version premium à 49,99 €/mois
SQLFlow sur site	Environnements réglementés ; SQL doit rester interne	Docker/Kubernetes, compatible avec un environnement isolé ; 1 TP3T500/mois ou 1 TP3T4 800 en une seule fois par type de base de données, installable sur deux serveurs
API REST / CLI / Bibliothèque Java	Automatisation du traçage dans l'intégration continue ou sur votre propre plateforme	Même moteur, sans interface graphique ; widget JavaScript intégrable avec une API de plus de 30 méthodes pour le rendu de diagrammes dans votre produit

Foire aux questions

SQLFlow remplace-t-il la lignée d'Unity Catalog ?

Non, il le complète. Unity Catalog capture automatiquement la traçabilité des charges de travail qui y transitent. SQLFlow analyse statiquement le SQL, couvrant ainsi le code avant son exécution (migrations), le SQL exécuté en dehors d'Unity Catalog et les environnements s'étendant de Databricks à d'autres plateformes, puis exporte le résultat vers DataHub, Purview ou OpenMetadata.

SQLFlow a-t-il besoin d'accéder à mon espace de travail ou à mes données Databricks ?

Non. SQLFlow effectue une analyse statique du code SQL, en utilisant éventuellement les métadonnées du schéma pour résoudre les références. Il ne lit jamais les lignes de vos tables Delta. Avec l'édition sur site, même le texte SQL reste au sein de votre réseau.

SQLFlow peut-il retracer la lignée à travers les instructions MERGE INTO ?

Oui. Pour un Delta FUSIONNER DANSSQLFlow résout le problème. EN UTILISANT la sous-requête associe chaque colonne cible à ses véritables colonnes sources à travers les deux MISE À JOUR et INSÉRER branches, et classe les conditions de correspondance et les filtres comme lignée indirecte (impact).

Databricks est-il un dialecte distinct de Spark SQL dans SQLFlow ?

Oui. SQLFlow prend en charge 39 dialectes, dont Databricks et Spark SQL, chacun disposant de son propre analyseur syntaxique au sein de la famille Spark SQL. Choisissez Databricks pour les requêtes SQL écrites avec Databricks ; il existe également un analyseur syntaxique dédié. page de traçabilité Spark SQL pour les charges de travail Spark open-source.

Est-ce compatible avec les projets dbt sur Databricks ?

Oui. Importez le manifeste dbt et SQLFlow génère une traçabilité au niveau des colonnes de vos modèles, en utilisant le dialecte Databricks pour analyser le SQL compilé.

Combien coûte 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é. Plus d’informations sont disponibles sur le site web. page de tarification.