Traçabilité des données Teradata : Traçabilité des colonnes pour les migrations et la conformité

Traçabilité des données Teradata Il s'agit de la cartographie au niveau des colonnes de la façon dont les données circulent dans un environnement Teradata : quelles colonnes sources alimentent chaque table, vue et rapport cible, et par quelles jointures, expressions et QUALIFIER des filtres tout au long du parcours. Gudu SQLFlow Il construit automatiquement cette carte en analysant votre SQL Teradata avec un analyseur de dialecte Teradata dédié, l'un des 39 analyseurs spécifiques à un dialecte qu'il fournit, et la rend sous forme de diagramme interactif et explorable avec exportation JSON, CSV et PNG ainsi qu'une API REST.

Pourquoi la traçabilité des données Teradata nécessite un analyseur Teradata

Teradata SQL n'est pas ANSI SQL avec un logo différent. Un environnement typique fonctionnant depuis l'époque de BTEQ conserve des décennies de constructions spécifiques à chaque dialecte : ENSEMBLE et MULTISET définitions de tableaux, QUALIFIER Les clauses de filtrage basées sur les fonctions de fenêtrage, les colonnes de périodes nommées et les scripts écrits bien avant que l'on imagine qu'une machine aurait un jour besoin de les relire constituent des failles dans le système. Une grammaire ANSI générique échoue précisément sur ces instructions, et chaque instruction qu'un outil de traçabilité ne parvient pas à analyser représente une lacune dans votre graphe de lignage.

SQLFlow adopte une approche inverse. Il est construit sur le Analyseur SQL général, a commercial SQL compiler front-end developed since the mid-2000s and validated against roughly 13,600 per-dialect test fixtures. Its Teradata parser handles BTEQ-era SQL, ENSEMBLE/MULTISET tables, QUALIFIER, et les périodes nommées comme syntaxe Teradata de première classe, puis résout chaque référence de colonne via des CTE, des sous-requêtes, des vues, et SÉLECTIONNER * expansion avant l'extraction des relations source-cible à la granularité de la colonne.

Exemple concret : suivi d’une déduplication QUALIFY

Le QUALIFIER NUMÉRO_DE_LIGNE() L'insertion avec déduplication est l'un des modèles les plus courants dans les entrepôts de données Teradata, et un moyen fiable de contourner les outils de traçabilité qui ne parlent que l'ANSI :

INSERT INTO dw.customer_dim (customer_id, full_name, risk_rating) SELECT src.customer_id, TRIM(src.first_nm) || ' ' || TRIM(src.last_nm) AS full_name, src.risk_rating FROM staging.customer_feed src QUALIFY ROW_NUMBER() OVER ( PARTITION BY src.customer_id ORDER BY src.load_ts DESC) = 1;

En analysant cela avec SQLFlow, le diagramme affiche deux types de relations distincts :

• Lignée directe : dw.customer_dim.full_name est dérivé de mise en scène.flux_client.premier_nm et dernier_nm à travers GARNITURE et concaténation ; identifiant_client et évaluation du risque passage inchangé.
• Lignée indirecte (d'impact) : charger_ts ne se retrouve jamais dans la cible, mais détermine quelle ligne survit à la déduplication. SQLFlow l'enregistre, ainsi que… identifiant_client dans son PARTITION PAR rôle — en tant que dépendance indirecte, activable/désactivable séparément dans le diagramme.

Cette couche indirecte est importante. Si quelqu'un modifie le grain de charger_tsLa déduplication commence silencieusement à conserver des lignes différentes, et aucun graphe de lignage direct ne vous avertirait. La plupart des outils concurrents ne modélisent pas du tout le lignage indirect ; SQLFlow le traite comme un type de relation distinct.

Cas d'utilisation 1 : traçabilité réglementaire des banques sur Teradata

Teradata est largement utilisé dans le secteur bancaire, et les banques supportent les obligations de traçabilité les plus importantes. La norme BCBS 239 exige des institutions qu'elles démontrent l'exactitude et l'intégrité de l'agrégation des données de risque ; concrètement, cela signifie indiquer aux auditeurs précisément quels champs sources alimentent chaque indicateur réglementaire et quelles transformations y subissent. La traçabilité au niveau des colonnes constitue cette preuve ; la traçabilité au niveau des tables est une approximation que les auditeurs remettent de plus en plus en question.

Les feuilles de calcul de traçabilité mises à jour manuellement échouent à ce test dès le lendemain de leur création. SQLFlow, en revanche, extrait la traçabilité directement du SQL : indiquez-lui vos DDL Teradata, vos définitions de vues et vos scripts de chargement, et il génère une provenance au niveau des colonnes pour chaque sortie réglementée, actualisable à chaque modification grâce à des analyses incrémentales, avec un référentiel de traçabilité persistant en arrière-plan.

Deux propriétés rendent cette solution utilisable au sein de l'environnement de contrôle d'une banque. Premièrement, SQLFlow effectue uniquement une analyse statique du code SQL ; il ne lit jamais les données des lignes, de sorte qu'aucun enregistrement client n'est modifié. Deuxièmement, Édition sur site S'exécutant sur Docker ou Kubernetes intégralement au sein de votre réseau, y compris dans des environnements isolés du réseau physique, même les données SQL restent confinées à votre infrastructure. Les déploiements d'entreprise analysent par lots des bases de données de plus de 100 bases et plus d'un million de colonnes, et les adaptateurs d'exportation pour DataHub, Microsoft Purview et OpenMetadata intègrent la traçabilité dans le catalogue déjà utilisé par votre équipe de gouvernance.

Cas d'utilisation 2 : migration depuis Teradata avec la véritable cartographie des dépendances

La plupart des projets de gestion de la lignée Teradata commencent aujourd'hui par une migration : l'infrastructure est transférée vers Snowflake, BigQuery ou Databricks, et il faut déterminer les dépendances entre les différentes données. Se fier aux noms de tables et aux connaissances empiriques est la principale cause des retards de migration. La cartographie des dépendances devrait provenir du SQL.

• Honnêtement, Scope. L'historique au niveau des colonnes indique quelles colonnes alimentent les rapports en aval et lesquelles sont inutiles — une logique que rien ne consomme et que vous pouvez désactiver au lieu de migrer.
• Vagues de migration séquentielles. Le graphe de lignage révèle l'ordre de dépendance réel entre les domaines, ce qui permet de déplacer les flux en amont avant les bases de données qui les consomment.
• Déjouez les pièges dialectaux. Des constructions comme QUALIFIER, ENSEMBLE La sémantique de déduplication des tables et les périodes nommées nécessitent une traduction précise. La traçabilité indique la place de chaque construction dans le flux de données et les conséquences d'une traduction erronée.
• Vérifier après la bascule. Comme SQLFlow analyse les deux dialectes, vous pouvez générer lignée de flocons de neige À partir du code SQL réécrit, comparez-le à la configuration de référence Teradata : mêmes cibles, mêmes colonnes sources, ou vous avez un bug de traduction.

Le même processus avant-après s'applique aux autres mises hors service de MPP héritées — voir la Traçabilité des données Netezza la page pour la variante de mise hors service, et la Traçabilité des données Oracle Cette page est disponible si votre infrastructure combine des sources Teradata et Oracle.

Comment SQLFlow ingère un environnement Teradata

Vous pouvez alimenter SQLFlow Teradata SQL quelle que soit l'échelle à laquelle vous travaillez :

• Collez une requête dans le navigateur pour un aperçu rapide d'une instruction.
• Téléverser des fichiers — Exportations DDL, définitions de vues, scripts ETL et de chargement — pour une analyse à l'échelle d'un projet.
• Connexion via JDBC extraire directement les métadonnées de schéma et les définitions d'objets depuis Teradata.
• Automatiser avec l'interface de ligne de commande sans interface graphique ou l'API REST pour maintenir la lignée à jour dans le cadre de votre pipeline de déploiement, et exportez les résultats au format JSON ou CSV pour toute personnalisation.

Pour une vue d'ensemble complète du fonctionnement du moteur sur l'ensemble des 39 dialectes (lignage direct versus indirect, inférence de diagrammes ER à partir de DDL, prise en charge de dbt, requête de lignage IA), veuillez consulter le Outil de traçabilité des données SQL page pilier.

Qu’en est-il des outils open source et de catalogage ?

Les analyseurs syntaxiques open source comme SQL Lineage et sqlglot sont réellement utiles pour extraire la provenance de déclarations individuelles, principalement ANSI, et les plateformes axées sur le catalogue sont performantes pour organiser les métadonnées et la propriété au sein d'une organisation. Le point faible de Teradata réside dans la profondeur de sa couverture dialectale : les scripts datant de l'ère BTEQ, vieux de plusieurs décennies, QUALIFIERLes logiques de déduplication complexes et les DDL spécifiques aux fournisseurs sont précisément les points faibles des grammaires génériques. Si vous évaluez des outils pour un environnement Teradata, le test est simple : exécutez votre script de chargement de production le plus complexe sur chaque candidat et comptez les instructions qui renvoient une traçabilité complète au niveau des colonnes.

Options de déploiement et tarification

Édition	Idéal pour	Tarification
SQLFlow Cloud	Aujourd'hui, j'essaie Teradata Lineage ; travail d'analyse individuel	Formule gratuite ; formule premium $49,99/mois
SQLFlow sur site	Banques et établissements réglementés — SQL ne quitte jamais votre réseau ; prise en charge de l’isolation physique	$500/mois ou $4 800 en une seule fois par type de base de données, installable sur deux serveurs
API REST / CLI / Bibliothèque Java	Intégration de la traçabilité dans les pipelines et les plateformes	Consultez la page des prix

L'ajout de types de bases de données sur site coûte 1 TP3T100 par mois ou 1 TP3T1 000 en une seule fois, ce qui est important en cours de migration lorsque vous devez analyser Teradata et Snowflake côte à côte. Plus de détails sur le page de tarification.

Foire aux questions

SQLFlow comprend-il la syntaxe spécifique à Teradata comme QUALIFY et les tables SET/MULTISET ?

Oui. SQLFlow utilise un analyseur syntaxique dédié au dialecte Teradata, et non une grammaire ANSI générique. SQL de l'ère BTEQ. ENSEMBLE/MULTISET définitions de tableaux, QUALIFIER Les clauses et les périodes nommées sont toutes analysables en tant que SQL Teradata, de sorte que l'extraction de lignage couvre les instructions qu'un analyseur générique rejette.

SQLFlow peut-il aider lors d'une migration de Teradata vers Snowflake ou BigQuery ?

Oui. Commencez par analyser l'environnement Teradata afin d'obtenir la cartographie précise des dépendances au niveau des colonnes : quelles données migrer, lesquelles mettre hors service et dans quel ordre ? Snowflake et BigQuery faisant partie des 39 dialectes de SQLFlow, vous pouvez analyser le code SQL réécrit après la migration et comparer sa provenance avec la base de données Teradata de référence pour vérifier la conversion.

Est-ce que SQLFlow lit les données de nos tables Teradata ?

Non. SQLFlow effectue une analyse statique du code SQL et peut lire les métadonnées du schéma, telles que les définitions des tables et des colonnes. Il n'interroge jamais les données des lignes. En mode local, même le texte SQL reste sur votre réseau.

Le traçage des lignes peut-il être entièrement effectué au sein de notre réseau à des fins de conformité ?

Oui. SQLFlow On-Premise se déploie sur Docker ou Kubernetes au sein de votre infrastructure, y compris dans des environnements isolés, au tarif de $500 par mois ou $4 800 en une seule fois par type de base de données. Il s'adapte aux environnements de plus de 100 bases de données et plus d'un million de colonnes, avec des analyses incrémentielles et des adaptateurs d'exportation pour DataHub, Microsoft Purview et OpenMetadata.

Quelles sont les entrées Teradata acceptées par SQLFlow ?

Requêtes SQL collées, fichiers téléchargés (DDL, vues, scripts de chargement) et métadonnées de schéma en direct récupérées via JDBC. Les résultats sont disponibles sous forme de diagrammes interactifs, JSON, CSV, PNG ou via l'API REST.

La traçabilité au niveau de la colonne est-elle suffisante pour BCBS 239 ?

La traçabilité au niveau des colonnes constitue la couche de preuves techniques : elle documente les champs sources qui alimentent chaque indicateur de risque et les transformations qu’ils subissent, y compris les dépendances indirectes liées aux filtres et aux conditions de jointure. Votre programme de conformité définit le périmètre complet ; SQLFlow assure l’exactitude et la mise à jour automatique de la couche de traçabilité, évitant ainsi une maintenance manuelle.