UN API de traçabilité des données permet d'extraire la lignée par programmation : vous soumettez du code SQL via HTTP et recevez un graphe de lignée structuré au format JSON, listant chaque table et colonne source, chaque cible et les relations de transformation entre elles. API REST Gudu SQLFlow Il réalise précisément cela pour 39 dialectes SQL, avec une granularité au niveau des colonnes, y compris les procédures stockées et le SQL dynamique. La même analyse qui alimente les diagrammes interactifs de SQLFlow est disponible sous forme de données de traçabilité structurées via HTTP.
Consultez d'abord le résultat : collez une requête dans le Visualiseur de lignage SQLFlow gratuit, puis exportez le graphique au format JSON pour voir à quoi ressemble la lignée sous forme de données avant d'écrire une seule ligne de code d'intégration.
Pourquoi intégrer une API de traçabilité des données à votre infrastructure ?
Les diagrammes de lignage interactifs permettent aux humains d'explorer la filiation. Cependant, les utilisations les plus pertinentes du lignage sont automatisées : bloquer une requête d'extraction qui perturbe silencieusement un rapport en aval, maintenir à jour le lignage d'un catalogue de données sans intervention manuelle, ou encore répondre à la question « Quelles sont les sources de cette colonne ? » au sein de vos outils internes. Toutes ces applications nécessitent un accès aux données de lignage, disponibles à la demande, via un service accessible.
L'approche de SQLFlow repose sur l'analyse statique du SQL. L'API analyse le texte SQL que vous lui envoyez sans jamais modifier les lignes de vos tables, ce qui simplifie l'analyse de sécurité : seul le code SQL transite sur le réseau. édition sur site même cela reste à l'intérieur de votre réseau. Le moteur sous-jacent est le Analyseur SQL général, un compilateur SQL commercial frontal développé depuis le milieu des années 2000 et validé par rapport à environ 13 600 jeux de tests par dialecte, de sorte que la lignée que vous obtenez est construite à partir d'un modèle sémantique complet du SQL, et non d'une correspondance d'expressions régulières.
Ce que renvoie l'API REST SQLFlow
Conceptuellement, l'API expose l'intégralité de la surface d'analyse SQLFlow sous forme de JSON sur HTTP :
| Capacité | Vous envoyez | Vous revenez |
|---|---|---|
| Graphique de lignage | Texte SQL plus un identifiant de dialecte | Le graphe de lignage complet au niveau des colonnes au format JSON : tables, colonnes et relations source-cible |
| Trace en amont / en aval | Un tableau ou une colonne d'intérêt | Seul le sous-graphe alimentant cet objet (en amont) ou alimenté par lui (en aval) est concerné par l'analyse d'impact ciblée. |
| Lignée au niveau de la table | Texte SQL, granularité de table demandée | Un graphe de dépendance compact entre les tables lorsque les détails des colonnes seraient superflus. |
| lignée directe vs indirecte | Un drapeau sur la demande | Les relations de flux de données pures, ou en outre les colonnes qui façonnent les résultats par le biais de OÙ, REJOINDRE, et GROUPER PAR clauses |
| Graphe d'appel de procédure stockée | Corps de procédure PL/SQL ou T-SQL | Quelles procédures appellent lesquelles, avec une traçabilité via les paramètres, les tables temporaires et le SQL dynamique |
| Diagramme ER | Scripts DDL | Relations inférées entre clés primaires et étrangères sous forme de modèle entité-relation |
| Exportations | Un emploi analysé | JSON ou CSV pour les machines, PNG pour la documentation et les tickets |
Chaque requête spécifie explicitement son dialecte. SQLFlow intègre des analyseurs syntaxiques spécifiques à chaque dialecte pour 39 bases de données et moteurs de requêtes, de Snowflake, BigQuery, Databricks et Redshift à Oracle, SQL Server, Teradata, Hive et Trino. Ainsi, la syntaxe propre à chaque fournisseur, comme les tables temporaires T-SQL, est analysée conformément à sa définition, et non approximée par une grammaire ANSI générique. La liste complète est disponible sur le site web de SQLFlow. Présentation de l'outil de traçabilité des données SQL.
Exemple minimal : requête POST SQL, réception d’un graphe de lignage
L'interaction principale consiste en un appel HTTP. Vous envoyez une requête SQL et un dialecte ; la réponse est le graphe de lignage. Les chemins des points de terminaison, l'authentification et la documentation complète des paramètres se trouvent dans le Documentation de l'API SQLFlow; la forme de l'échange ressemble à ceci :
curl -s -X POST "$SQLFLOW_API/lineage" -H "Authorization: Bearer $SQLFLOW_TOKEN" --form "dbvendor=snowflake" --form 'sqltext=CREATE VIEW customer_ltv AS SELECT c.customer_id, SUM(o.amount) AS lifetime_value FROM customers c JOIN orders o ON o.customer_id = c.customer_id WHERE o.status = ''paid'' GROUP BY c.customer_id;'
La réponse est un graphique : une liste d’objets de base de données (tables, vues et leurs colonnes) et une liste des relations entre les colonnes. Version simplifiée et abrégée à des fins d’illustration :
{ "relations": [ { "type": "direct", "cible": {"objet": "customer_ltv", "colonne": "lifetime_value"}, "sources": [{"objet": "orders", "colonne": "amount", "via": "SUM"}] }, { "type": "direct", "cible": {"objet": "customer_ltv", "colonne": "customer_id"}, "sources": [{"objet": "customers", "colonne": "customer_id"}] }, { "type": "indirect", "cible": {"objet": "customer_ltv", "colonne": "lifetime_value"}, "sources": [{"objet": "orders", "colonne": "status", "via": "WHERE"}] } ] }
Notez la troisième relation. statut des commandes n'apparaît jamais dans le résultat de la vue, mais il filtre les lignes dont la somme est calculée, donc il a un impact certain. valeur_de_vieSQLFlow modélise cela comme lignée indirecte, distincte du flux de données direct et pouvant être demandée séparément. La plupart des outils de traçabilité ne font pas cette distinction, et c'est précisément ce dont un utilisateur d'analyse d'impact a besoin : la suppression statut des commandes cela fausserait cette vue même si aucune colonne de sortie n'en « provient ».
Cas d'utilisation : vérifications de lignage dans l'intégration continue
L'intégration la plus efficace est celle qui s'exécute avant le déploiement de code SQL défectueux. Dans une tâche d'intégration continue exécutée sur chaque demande d'extraction qui modifie le code SQL :
- Envoyez les fichiers SQL modifiés au point de terminaison de lignage et obtenez le nouveau graphique.
- Comparez-le au graphique de la branche principale : quelles colonnes ont gagné ou perdu des sources, quels objets en aval ont modifié leurs entrées.
- Échouez le contrôle ou publiez la différence en tant que commentaire de révision lorsqu'une modification touche des colonnes qui alimentent des cibles protégées telles que des rapports réglementaires ou des tableaux de bord de direction.
L'analyse étant statique, elle fonctionne sur du code qui n'a jamais été exécuté. La dépendance défectueuse est détectée lors de la revue de code, et non lors d'un échec d'exécution par lots à 2 h du matin. Le même principe s'applique aux migrations de schéma : avant une COLONNE DE CHUTE Dans les zones, un seul appel de traçage en aval vous indique chaque objet qui consomme la colonne, directement ou via un filtre.
Cas d'utilisation : alimenter votre catalogue de données
Les plateformes de catalogue excellent dans l'organisation des métadonnées, la gestion des droits de propriété et la découverte des données ; le traçage des requêtes SQL au niveau des colonnes est généralement leur point faible. SQLFlow s'intègre comme moteur de traçage : il analyse votre environnement SQL, puis transfère les résultats vers le catalogue que vous utilisez déjà. Les déploiements en entreprise incluent des adaptateurs d'exportation prêts à l'emploi. DataHub, Microsoft Purview et OpenMetadataLes exportations JSON et CSV alimentent toutes les données personnalisées. À grande échelle, ce système effectue des analyses par lots et incrémentales sur des ensembles de plus de 100 bases de données et plus d'un million de colonnes, avec un référentiel de traçabilité persistant. Ainsi, le catalogue reste à jour sans intervention manuelle.
Cas d'utilisation : traçabilité au sein de vos propres outils
Les plateformes de données internes développent sans cesse les mêmes fonctionnalités : un panneau « D’où vient cette métrique ? », un outil de vérification de la dépréciation, une carte des dépendances de migration. Plutôt que de créer un analyseur SQL, appelez l’API depuis votre service et affichez le graphique comme vous le souhaitez. Si vous préférez le diagramme interactif au JSON brut, SQLFlow propose également un widget JavaScript intégrable avec une API de plus de 30 méthodes, compatible avec toutes les applications web. Pour une intégration JVM côté serveur uniquement, une bibliothèque Java expose le même moteur. L’API, le widget et la bibliothèque renvoient tous des résultats cohérents car ils partagent un seul analyseur.
Comment cela se compare-t-il aux autres options de traçabilité programmatique ?
Il est utile de connaître trois catégories. Bibliothèques d'analyse syntaxique open source comme SQL Lineage et sqlglot sont réellement performantes pour analyser des instructions individuelles au sein d'un processus Python, et pour une logique SELECT et INSERT simple, elles peuvent suffire ; la lacune apparaît au niveau des procédures stockées, du SQL dynamique, des cas particuliers de dialecte et de la résolution des vues ou de l'expansion en étoile qui nécessitent un contexte de schéma. normes de lignage d'exécution comme OpenLineage capture la lignée à partir des événements d'exécution de tâches, ce qui est excellent pour la lignée au niveau de l'orchestrateur, exécution par exécution, mais ne voit que le code qui a réellement été exécuté, à la granularité fournie par l'intégration émettrice. Plateformes axées sur le catalogue Les API de traçabilité exposées couvrent l'ensemble des données ingérées, de sorte que leurs réponses ne sont détaillées que jusqu'à la source de l'ingestion. L'API REST de SQLFlow est un outil différent : un service d'analyse SQL spécialisé qui calcule la traçabilité au niveau des colonnes à partir du code lui-même, y compris les requêtes SQL jamais exécutées et les procédures ignorées par d'autres outils. Ces deux approches se complètent bien ; de nombreuses équipes utilisent SQLFlow pour calculer la traçabilité et un catalogue pour la mettre à disposition des utilisateurs finaux.
Où l'API s'exécute : dans le cloud ou sur votre propre réseau
L'API REST est disponible dans les deux déploiements SQLFlow. SQLFlow Cloud est la solution de démarrage la plus rapide : un SaaS avec une offre gratuite, une offre premium à $49,99 €/mois, sans infrastructure à gérer. SQLFlow sur site Déployable via Docker ou Kubernetes au sein de votre réseau, cette solution fonctionne en mode totalement isolé du réseau et est proposée au prix de $500/mois ou $4 800 en une seule fois par type de base de données sélectionné. Elle peut être installée sur deux serveurs. Il est courant de prototyper l'intégration dans le cloud, puis de transférer les mêmes appels d'API vers un hôte sur site afin que les requêtes SQL ne quittent jamais votre infrastructure.
Foire aux questions
L'API renvoie-t-elle la traçabilité au niveau des colonnes ou au niveau des tables ?
Les deux. Le niveau de détail par défaut est celui des colonnes : pour chaque colonne de sortie, vous obtenez les colonnes sources exactes ainsi que les fonctions, jointures et opérations ensemblistes qui les relient, avec distinction entre les relations directes et indirectes. Vous pouvez demander une granularité au niveau de la table lorsqu'un graphe de dépendances compact suffit.
Quels dialectes SQL l'API de traçabilité des données prend-elle en charge ?
39 dialectes, chacun avec son propre analyseur syntaxique : Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL, Trino, et bien d’autres. Vous spécifiez le dialecte dans chaque requête.
Peut-il analyser les procédures stockées et le SQL dynamique ?
Oui. Oracle PL/SQL et SQL Server T-SQL disposent d'analyseurs syntaxiques procéduraux dédiés. La traçabilité est assurée par les paramètres des procédures et les tables temporaires, le SQL dynamique intégré aux procédures est résolu et analysé, et l'API peut renvoyer le graphe d'appels de procédure à procédure.
L'API a-t-elle besoin d'accéder à mes données ?
Non. Il effectue une analyse statique du texte SQL que vous soumettez et ne lit jamais les données des lignes de la table. Avec l'édition sur site, le texte SQL lui-même reste également au sein de votre réseau.
Quels sont les formats de sortie disponibles ?
Le format JSON est privilégié pour les applications programmatiques ; l’exportation CSV est adaptée aux tableurs et aux chargements en masse, tandis que l’exportation PNG produit le diagramme rendu pour la documentation. Les déploiements en entreprise ajoutent des adaptateurs d’exportation pour DataHub, Microsoft Purview et OpenMetadata.
Où se trouve la documentation complète de l'API ?
À docs.gudusoft.com, couvrant les chemins d'accès aux points de terminaison, l'authentification, les paramètres de requête par capacité et le schéma de réponse complet. Pour connaître les forfaits incluant l'accès à l'API, consultez Tarification de SQLFlow.
Récupérez la lignée au format JSON à partir de votre SQL.
Collez une requête dans le visualiseur gratuit pour examiner la structure du graphique, puis connectez l'API REST à votre pipeline.