Traçabilité des données Trino et Presto : Traçabilité des colonnes dans SQL fédéré

Traçabilité des données Trino Il s'agit de la cartographie au niveau des colonnes du flux de données dans Trino (et Presto) SQL : quelles colonnes sources, dans quels catalogues, alimentent chaque colonne de sortie, et par quels jointures, fonctions et filtres. Trino étant un moteur de requêtes fédéré, une seule instruction peut lire à partir de ruche, postgresql, et iceberg catalogues simultanément — une lignée précise doit donc résoudre chaque colonne jusqu'à sa qualification complète catalogue.schéma.table.colonne une identité, et pas seulement un nom de table. Gudu SQLFlow Il utilise pour cela des analyseurs syntaxiques dédiés aux dialectes Trino et Presto.

Pourquoi la fédération complique la traçabilité des données Trino

Dans un entrepôt de données classique, la traçabilité est assurée par une seule base de données : chaque table d'une requête appartient au même système et son nom, composé de deux parties, est utilisé pour la traçabilité. commandes de ventes est sans ambiguïté. Trino remet en cause cette hypothèse. Son objectif principal est de fusionner des données. à travers Des systèmes tels qu'une table Hive sur S3, une base de données opérationnelle PostgreSQL et une table Iceberg Lakehouse peuvent toutes apparaître dans le même système. SÉLECTIONNER.

Cela crée trois problèmes que la plupart des outils de lignage gèrent mal :

• Conflits de noms entre les catalogues. commandes de ventes de ruche et commandes de ventes postgresql Il s'agit de tables physiques distinctes dans des systèmes différents. Une analyse de lignage qui supprime le qualificateur de catalogue les fusionne en un seul nœud, et toute analyse d'impact en aval basée sur ce nœud est erronée.
• Qualification partielle. Les requêtes réelles utilisent rarement des noms en trois parties partout. Elles s'appuient sur le catalogue et le schéma par défaut de la session, les alias, et UTILISER Le résolveur doit reconstruire l'identité complète de chaque référence de colonne à partir de ce contexte.
• Frontières intersystèmes dans une seule déclaration. Un INSÉRER DANS L'iceberg.... qui sélectionne des données provenant de Hive et PostgreSQL est un déplacement de données entre trois systèmes Exprimée en une seule instruction, la traçabilité au niveau de la table indique les systèmes concernés ; seule la traçabilité au niveau de la colonne indique quelle colonne PostgreSQL s’est retrouvée dans quelle colonne Iceberg.

Le résolveur sémantique de SQLFlow conserve l'intégralité catalogue.schéma.table.colonne Un chemin est présent sur chaque nœud du graphe de lignage, afin que les colonnes inter-catalogues restent distinctes et traçables de bout en bout.

Exemple concret : cible Iceberg, sources Hive et PostgreSQL

Voici un exemple typique d'écriture fédérée : la création d'une table de valeur client dans un catalogue Iceberg à partir d'une base de données PostgreSQL opérationnelle jointe à l'historique des commandes Hive :

INSERT INTO iceberg.analytics.customer_value SELECT c.customer_id, lower(c.email) AS email, sum(o.order_total) AS lifetime_value, count(*) AS order_count FROM postgresql.crm.customers AS c JOIN hive.sales.orders AS o ON c.customer_id = o.customer_id WHERE o.order_status = 'COMPLETED' GROUP BY c.customer_id, lower(c.email);

Exécutez ce code via SQLFlow avec le dialecte Trino sélectionné et le diagramme affiche, pour chaque colonne de sortie :

Colonne cible (iceberg.analytics.customer_value)	Colonne source	Relation
identifiant_client	postgresql.crm.clients.customer_id	Direct, transit
e-mail	postgresql.crm.clients.email	Directement, par inférieur()
valeur_de_vie	hive.sales.orders.order_total	Directement, par somme()
nombre_de_commandes	commandes de ventes de ruche rangées	Directement, par compter(*)
toutes les colonnes	hive.sales.orders.order_status	Indirect (filtre WHERE)
toutes les colonnes	o.customer_id / c.customer_id	Indirect (condition JOIN, GROUP BY)

Notez les deux dernières lignes. statut de la commande n'apparaît jamais dans le résultat, mais modifier la façon dont il est rempli modifie chaque nombre dans valeur_clientSQLFlow modélise cela comme lignée indirecte (d'impact)Il existe un type de relation distinct et activable, parallèle au flux de données direct. La plupart des outils de traçabilité ne font pas cette distinction, or cette information est essentielle avant de modifier une colonne de filtre dans une table Hive partagée.

Trino et Presto sont des dialectes différents ; SQLFlow analyse les deux.

Trino est issu d'une branche de Presto (sous le nom de PrestoSQL) et a été renommé en 2020 ; depuis, les deux dialectes ont divergé. SQLFlow est fourni avec des analyseurs syntaxiques distincts spécifiques au dialecte pour Trino et pour PrestoParmi ses 39 dialectes pris en charge, aucun n'est une grammaire ANSI générique avec un indicateur de compatibilité. Si votre infrastructure exécute PrestoDB en parallèle d'un cluster Trino plus récent, vous sélectionnez le dialecte correspondant pour chaque source et les deux seront analysées correctement.

Les analyseurs syntaxiques proviennent du General SQL Parser (GSP), un compilateur SQL commercial frontal développé depuis le milieu des années 2000 et validé à l'aide d'environ 13 600 jeux de tests par dialecte. GSP construit un modèle sémantique complet de chaque instruction, résolvant les références de colonnes via les CTE, les sous-requêtes, les vues, etc. SÉLECTIONNER * L'expansion – et son analyseur de flux de données extrait les relations source-cible. L'expansion stellaire est plus importante à Trino que presque partout ailleurs : SÉLECTIONNER * Une jointure fédérée extrait des colonnes de plusieurs systèmes, et son expansion correcte nécessite les métadonnées de schéma de chaque catalogue, que SQLFlow peut ingérer en même temps que le SQL.

Comment générer la lignée Trino avec SQLFlow

1. Récupérez le SQL. Collez des requêtes individuelles, téléchargez des fichiers de scripts ETL et des définitions de vues, ou récupérez des métadonnées via JDBC. Pour une couverture complète de l'ensemble du système, Grabit/Ingéreur SQLFlow utilitaire extrait les métadonnées par lots.
2. Choisissez le dialecte. Trino ou Presto, selon la source. Si le même pipeline contient également des tâches Hive DDL ou Spark SQL, analysez chacune dans son propre dialecte ; SQLFlow les prend tous en charge, et les déploiements en entreprise stockent les résultats dans un référentiel de lignage persistant.
3. Explorez et exportez. Explorez n'importe quelle colonne en amont ou en aval dans le diagramme interactif, activez ou désactivez la traçabilité indirecte et exportez au format JSON, CSV ou PNG, ou interrogez le graphique via l'API REST. Depuis la version 8.2.3, vous pouvez également poser des questions en langage naturel (« quelles tables Iceberg dépendent de… »). postgresql.crm.clients.email?); chaque tableau et chaque colonne de la réponse de l'IA est validée par rapport au graphique analysé avant d'être affichée.

À l'échelle de l'entreprise, SQLFlow analyse par lots des ensembles de plus de 100 bases de données et plus d'un million de colonnes, effectue des analyses incrémentales, conserve un référentiel de lignage persistant et exporte vers DataHub, Microsoft Purview et OpenMetadata — de sorte que le lignage Trino se retrouve dans le catalogue que votre équipe utilise déjà.

Analyse SQL statique vs. traçabilité des événements en temps réel

L'autre méthode courante pour obtenir la traçabilité des requêtes Trino consiste à effectuer une capture d'exécution : intercepter les événements de requête du moteur et générer la traçabilité de chaque instruction exécutée (l'écosystème OpenLineage fonctionne ainsi). La capture d'exécution est particulièrement efficace pour enregistrer les opérations réellement exécutées, avec le contexte de session réel. Ses limites résident dans sa couverture et sa profondeur : elle ne prend en compte que les requêtes exécutées pendant la fenêtre de capture et nécessite l'instrumentation de chaque cluster.

L'analyse statique, l'approche de SQLFlow, analyse directement le code SQL. Cela inclut les tâches planifiées non encore exécutées, les définitions de vues et le code du référentiel en cours de révision ; elle ne nécessite aucun agent sur le cluster et ne lit jamais les données des lignes de table. Dans les environnements réglementés, Édition sur site (Docker/Kubernetes) conserve même le texte SQL au sein de votre réseau. De nombreuses équipes utilisent les deux méthodes : la surveillance des événements d’exécution pour le suivi opérationnel et l’analyse statique pour une analyse d’impact complète avant déploiement.

Lignée à travers le reste de la pile

Trino ne donne que rarement une image complète. Les tables Hive qu'il interroge ont généralement été chargées par des tâches Hive ou Spark, et les résultats alimentent souvent des entrepôts de données en aval. SQLFlow analyse ces couches avec le même moteur ; consultez les guides dédiés. Traçabilité des données de la ruche et Traçabilité des données ClickHouse, ou la totalité Présentation de l'outil de traçabilité des données SQL Couvrant l'ensemble des 39 dialectes, et grâce à l'analyse de chaque couche dans le référentiel de lignage persistant, vous pouvez retracer une colonne depuis la tâche Spark qui a écrit la table Hive, en passant par la requête fédérée Trino, jusqu'à la cible Iceberg.

Foire aux questions

SQLFlow prend-il en charge à la fois Trino et Presto ?

Oui. Trino et Presto sont deux des 39 analyseurs syntaxiques spécifiques à un dialecte de SQLFlow. Sélectionnez le dialecte correspondant à votre moteur ; si vous utilisez les deux, analysez chaque source avec son propre dialecte.

SQLFlow peut-il retracer la lignée à travers les catalogues Trino ?

Oui. SQLFlow associe chaque colonne à son identité complète catalog.schema.table.column, de sorte qu'une requête joignant les catalogues hive, postgresql et iceberg produit une traçabilité qui préserve la distinction des colonnes de chaque système, y compris pour les instructions INSERT qui déplacent des données entre les catalogues.

SQLFlow a-t-il besoin d'accéder à mon cluster Trino ou à mes données ?

Non. SQLFlow effectue une analyse statique du code SQL, en utilisant éventuellement les métadonnées du schéma pour résoudre les noms et développer SELECT *. Il ne lit jamais les lignes des tables et ne nécessite aucun agent sur le cluster. L'édition sur site conserve l'intégralité du code SQL au sein de votre réseau.

Que renvoie SQLFlow pour les colonnes des clauses WHERE et JOIN ?

Elles apparaissent comme une lignée indirecte (d'impact) : un type de relation distinct pour les colonnes qui influencent le résultat sans y figurer directement. Vous pouvez activer ou désactiver la lignée indirecte dans le diagramme — une distinction que la plupart des outils de lignée ne font pas.

Puis-je exporter la lignée Trino vers mon catalogue de données ?

Oui. Les déploiements en entreprise incluent des adaptateurs d'exportation pour DataHub, Microsoft Purview et OpenMetadata, ainsi que l'exportation JSON et CSV et une API REST pour les intégrations personnalisées.

Combien coûte SQLFlow ?

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