Greenplum Data Lineage : Traçabilité des colonnes pour les entrepôts de données MPP

Traçabilité des données Greenplum Il s'agit de la carte au niveau des colonnes de la façon dont les données circulent dans un entrepôt Greenplum : depuis les tables externes et les schémas de transit, en passant par les chaînes ELT INSERT-SELECT et les vues, jusqu'aux tables de faits et de dimensions distribuées que les rapports lisent. Gudu SQLFlow il construit automatiquement cette carte en analysant votre SQL Greenplum avec un analyseur de dialecte Greenplum dédié — l'un des 39 analyseurs spécifiques à chaque dialecte qu'il fournit — et en générant un diagramme interactif que vous pouvez suivre colonne par colonne.

Pourquoi la traçabilité des données Greenplum nécessite un analyseur syntaxique dédié

Greenplum est une base de données MPP de la famille PostgreSQL, et la plupart de ses syntaxes de requêtes seront familières à quiconque connaît Postgres. Cependant, les éléments d'une infrastructure Greenplum qui témoignent le plus de son héritage sont précisément ceux qui divergent de PostgreSQL standard :

• Tables externes. CRÉER UNE TABLE EXTERNE avec gpfdist L'emplacement des fichiers est la porte d'entrée standard pour l'importation de données dans Greenplum. Un analyseur syntaxique qui rencontre des difficultés avec cette opération EMPLACEMENT et FORMAT Les clauses perdent le premier saut de chaque pipeline de chargement.
• Clés de distribution. DISTRIBUÉ PAR et DISTRIBUÉ ALÉATOIRE Les clauses apparaissent dans presque toutes les définitions de tables. Les grammaires ANSI génériques les rejettent, ce qui signifie qu'elles rejettent votre DDL et donc qu'il n'y a aucune traçabilité pour ces tables.
• Chaînes ELT INSERT-SELECT. Les entrepôts de données Greenplum transforment généralement les données au sein de la base de données : de la table de transit à la table conforme, puis à la table de faits, chaque étape étant une INSÉRER DANS ... SÉLECTIONNER avec des jointures, des conversions et des agrégats. La traçabilité doit être établie à chaque étape de la chaîne, et non calculée individuellement pour chaque instruction.

SQLFlow gère les trois car sa prise en charge de Greenplum utilise un analyseur syntaxique de dialecte distinct, et non PostgreSQL avec suppression des erreurs. Le moteur sous-jacent est le Analyseur SQL général, une interface de compilation SQL commerciale développée depuis le milieu des années 2000 et validée par rapport à environ 13 600 jeux de tests SQL par dialecte.

Exemple concret : chargement d’une table externe dans une table de faits distribuée

Voici une version condensée du modèle que suivent la plupart des pipelines de chargement de Greenplum. Les fichiers de commandes quotidiens arrivent via gpfdist, sont stockées dans une table externe et sont fusionnées dans une table de faits distribuée sur id_de_commande:

CRÉER UNE TABLE EXTERNE ext_stage.daily_orders ( order_id bigint, customer_id bigint, order_ts timestamp, amount numeric(12,2), channel text ) LOCATION ('gpfdist://etl-host:8081/daily_orders*.csv') FORMAT 'CSV' (HEADER); CRÉER UNE TABLE dw.fact_orders ( order_id bigint, customer_sk bigint, order_date date, net_amount numeric(12,2) ) DISTRIBUÉE PAR (order_id); INSERT INTO dw.fact_orders (order_id, customer_sk, order_date, net_amount) SELECT o.order_id, c.customer_sk, o.order_ts::date, o.amount - COALESCE(r.refund_amount, 0) FROM ext_stage.daily_orders o JOIN dw.dim_customer c ON c.customer_id = o.customer_id LEFT JOIN dw.stg_refunds r ON r.order_id = o.order_id WHERE o.channel <> 'test';

Exécutez ceci via SQLFlow et le diagramme montre, pour chaque colonne de dw.fact_orders, précisément d'où proviennent les données et ce qui leur est arrivé en cours de route :

Colonne cible	Colonnes sources	Transformation
fact_commandes.id_commande	ext_stage.daily_orders.order_id	Copie directe
commandes_clients.sk_client	dw.dim_customer.customer_sk	Directement, via rejoindre sur identifiant_client
fact_commandes.date_de_commande	ext_stage.daily_orders.order_ts	Casting to date
fact_orders.montant_net	montant des commandes quotidiennes, stg_refunds.montant_remboursement	Soustraction avec SE FONDRE

Notez ce qu'une vue au niveau du tableau aurait masqué : montant net est alimentée par deux tables différentes, et la table externe canal Cette colonne n'est jamais intégrée à la table de faits, et pourtant elle détermine quelles lignes y figurent. SQLFlow prend également en compte ce second type de relation.

Lignée directe vs lignée indirecte dans les chaînes ELT

Dans l'exemple ci-dessus, canal n'apparaît que dans le OÙ la clause et les clés de jointure apparaissent uniquement dans SUR conditions. Aucune d'entre elles n'apparaît dans le résultat, mais modifier l'une d'entre elles modifie les nombres dans ordres de faitsSQLFlow modélise ces éléments comme lignée indirecte (d'impact)Il s'agit d'un type de relation distinct du flux de données direct, et vous pouvez activer ou désactiver chaque relation indépendamment dans le diagramme. La plupart des outils de traçabilité ne font pas cette distinction, ce qui signifie que leur analyse d'impact passe à côté des dépendances de filtrage et de jointure.

Cela est d'autant plus important dans Greenplum que dans la plupart des environnements, en raison de la profondeur des chaînes INSERT-SELECT. Une architecture typique empile les tables externes, les tables de transit, la couche de conformité, la couche de faits et les vues de reporting les unes sur les autres. SQLFlow résout les références de colonnes à chaque étape, y compris les CTE, les sous-requêtes, les vues, etc. SÉLECTIONNER * expansion, de sorte qu'une trace provenant d'une colonne de rapport remonte jusqu'au flux de fichier source en un seul chemin continu.

Vous migrez depuis Greenplum ? Commencez par définir les dépendances de la carte.

De nombreuses infrastructures Greenplum sont désormais candidates à la migration vers des entrepôts de données cloud, et la principale source de dépassements de capacité lors de ces migrations réside dans les dépendances inconnues : une vue non documentée, une table de transit consultée discrètement par trois utilisateurs, une colonne nécessaire à un rapport en aval et supprimée par le nouveau modèle. Élaborer une cartographie des dépendances avant la migration permet d'éviter ces problèmes en production.

Un flux de travail de migration axé sur la lignée avec SQLFlow ressemble à ceci :

1. Scannez le domaine. Intégrez à SQLFlow vos définitions DDL Greenplum, vos définitions de vues et vos scripts de chargement : collés, importés sous forme de fichiers ou récupérés en direct via JDBC. Les déploiements en entreprise effectuent des analyses par lots sur des parcs de plus de 100 bases de données et plus d’un million de colonnes, avec des analyses incrémentales à mesure que le code est modifié.
2. Trouvez ce qui est réellement utilisé. La traçabilité au niveau des colonnes sépare les tables et les colonnes qui alimentent les sorties en direct de celles qui ne sont pas lues, vous permettant ainsi de migrer l'entrepôt de données réel au lieu de vingt ans d'accumulation.
3. Séquencez le mouvement. Le graphique de lignage vous donne l'ordre de dépendance : quels domaines peuvent évoluer indépendamment et lesquels entraînent avec eux une chaîne de flux en amont.
4. Vérifiez la cible. Étant donné que le même moteur analyse le dialecte de destination (Snowflake, BigQuery, Redshift, Databricks et les 39 autres dialectes pris en charge), vous pouvez schématiser le SQL migré et comparer la lignée avant et après.

Les équipes gérant des environnements hétérogènes utilisent la même approche sur d'autres plateformes MPP : voir les pages associées. Traçabilité des données Teradata et Lignée des données VerticaEt comme Greenplum est dérivé de PostgreSQL, les environnements qui utilisent également PostgreSQL standard peuvent gérer les deux avec un seul outil : Traçabilité des données PostgreSQL Cette page détaille les différences.

Comment intégrer Greenplum SQL à SQLFlow

• Coller ou télécharger : requêtes individuelles, scripts ou lots de .sql fichiers dans le navigateur.
• Métadonnées JDBC : Se connecter à Greenplum, extraire les définitions de tables et visualiser directement le SQL, afin que la traçabilité reflète ce qui est déployé plutôt que ce qui se trouve dans le dépôt.
• Ingestionneur Grabit : Extraction automatisée des métadonnées pour les analyses planifiées et répétables.
• API REST et interface de ligne de commande : analyse des performances à partir de l'intégration continue ou d'un pipeline d'orchestration via le API REST SQLFlow ou l'interface de ligne de commande sans interface graphique, et exporter les résultats au format JSON, CSV ou PNG.

L'analyse est entièrement statique et porte sur le texte SQL et les métadonnées du schéma. SQLFlow ne lit jamais les lignes de vos tables, et l'édition sur site (Docker ou Kubernetes, compatible avec les environnements isolés) conserve même le texte SQL au sein de votre réseau – un point crucial pour les secteurs réglementés où Greenplum est couramment utilisé. La traçabilité peut également être exportée vers DataHub, Microsoft Purview ou OpenMetadata si l'un de ces catalogues constitue votre système de référence.

Qu’en est-il des outils de traçabilité open source ?

Les analyseurs syntaxiques open source comme SQL Lineage et sqlglot Elles sont réellement utiles pour extraire les relations entre tables à partir de requêtes individuelles bien conçues, et si tel est votre seul problème, elles peuvent suffire. Le problème apparaît dans le code Greenplum en production : CRÉER UNE TABLE EXTERNE et DISTRIBUÉ PAR syntaxe, chaînes INSERT-SELECT à sauts multiples nécessitant une jonction entre instructions, SÉLECTIONNER * L'expansion nécessite des métadonnées de schéma, et la traçabilité indirecte passe par des filtres et des jointures. Exécutez l'un de vos scripts de chargement réels avec les deux méthodes et comparez les résultats : ce test tranche la question plus rapidement que n'importe quelle matrice de fonctionnalités.

Foire aux questions

SQLFlow prend-il en charge la syntaxe spécifique à Greenplum, comme les tables externes et DISTRIBUTED BY ?

Oui. SQLFlow intègre un analyseur syntaxique dédié au dialecte Greenplum, donc CRÉER UNE TABLE EXTERNE, DISTRIBUÉ PAR Les clauses et autres DDL Greenplum sont analysées correctement et participent au graphe de lignage au lieu de provoquer des erreurs.

Puis-je simplement utiliser le dialecte PostgreSQL pour Greenplum ?

Les requêtes SELECT simples seront généralement analysées, mais les instructions définissant vos pipelines de chargement (DDL des tables externes et définitions de tables distribuées) sont spécifiques à Greenplum. Utilisez le dialecte Greenplum pour que l'ensemble de votre infrastructure soit analysé ; SQLFlow prend en charge les deux, assurant ainsi la compatibilité avec les environnements Greenplum et PostgreSQL.

SQLFlow a-t-il besoin d'accéder aux données de mes tables Greenplum ?

Non. SQLFlow effectue une analyse statique du code SQL et peut lire les métadonnées du schéma via JDBC. Il ne lit jamais les lignes des tables, et l'édition sur site conserve l'intégralité du code SQL au sein de votre réseau.

SQLFlow peut-il aider à planifier une migration de Greenplum vers le cloud ?

Oui. Analysez l'environnement Greenplum pour obtenir le véritable graphe de dépendances au niveau des colonnes, utilisez-le pour définir la portée et la séquence de la migration, puis schématisez le SQL migré sur la plateforme cible (Snowflake, BigQuery, Redshift, Databricks et 35 autres dialectes sont pris en charge par le même moteur) afin de vérifier qu'aucune requête n'a été orpheline.

Quel est le coût de SQLFlow pour la lignée Greenplum ?

SQLFlow Cloud propose une version gratuite ; 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.