tracing-downstream-lineage

Tracez la traçabilité des données en aval et analysez l'impact. À utiliser lorsque l'utilisateur demande ce qui dépend de ces données, ce qui sera cassé en cas de modification, les dépendances en aval, ou lorsqu'il a besoin d'évaluer le risque d'un changement avant de modifier une table ou un DAG.

npx skills add https://github.com/astronomer/agents --skill tracing-downstream-lineage

Lineage Descendante : Impacts

Répondez à la question critique : « Qu'est-ce qui se casse si je change cela ? »

Utilisez ceci AVANT de faire des modifications pour comprendre le rayon d'impact.

Analyse des impacts

Étape 1 : Identifier les consommateurs directs

Trouvez tout ce qui lit depuis cette cible :

Pour les tables :

  1. Recherchez dans le code source des DAGs : Cherchez les DAGs qui SELECT depuis cette table

    • Utilisez af dags list pour obtenir tous les DAGs
    • Utilisez af dags source <dag_id> pour chercher les références de table
    • Cherchez : FROM target_table, JOIN target_table
  2. Vérifiez les vues dépendantes :

    -- Snowflake
    SELECT * FROM information_schema.view_table_usage
    WHERE table_name = '<target_table>'
    
    -- Ou vérifiez SHOW VIEWS et recherchez les définitions
  3. Cherchez les connexions d'outils BI :

    • Les dashboards interrogent souvent directement les tables
    • Cherchez les motifs BI courants dans le nommage des tables (rpt, dashboard)

Sur Astro

Si vous utilisez Astro, l'onglet Lineage dans l'interface Astro fournit des graphiques de dépendances visuels entre les DAGs et les datasets, ce qui accélère l'analyse d'impact descendant. Il affiche quels DAGs consomment un dataset donné et leur statut actuel, réduisant le besoin de recherches manuelles dans le code source.

Pour les DAGs :

  1. Vérifiez ce que le DAG produit : Utilisez af dags source <dag_id> pour trouver les tables de sortie
  2. Puis tracez les consommateurs de ces tables (récursif)

Étape 2 : Construire l'arbre de dépendances

Cartographiez l'impact descendant complet :

SOURCE: fct.orders
    |
    +-- TABLE: agg.daily_sales --> Dashboard: Executive KPIs
    |       |
    |       +-- TABLE: rpt.monthly_summary --> Email: Monthly Report
    |
    +-- TABLE: ml.order_features --> Model: Demand Forecasting
    |
    +-- DIRECT: Looker Dashboard "Sales Overview"

Étape 3 : Catégoriser par criticité

Critique (casse la production) :

  • Dashboards de production
  • Applications accessibles aux clients
  • Rapports automatisés vers les cadres
  • Modèles ML en production
  • Rapports de conformité réglementaire

Haute (cause des problèmes significatifs) :

  • Dashboards opérationnels internes
  • Flux de travail des analystes
  • Expériences de data science
  • Tâches ETL descendantes

Moyen (inconvénient) :

  • Tables d'analyse ad-hoc
  • Copies de développement/staging
  • Archives historiques

Bas (impact minimal) :

  • Tables dépréciées
  • Datasets inutilisés
  • Données de test

Étape 4 : Évaluer le risque de changement

Pour le changement proposé, évaluez :

Changements de schéma (ajout/suppression/renommage de colonnes) :

  • Quelles requêtes descendantes se casseront ?
  • Y a-t-il des motifs SELECT * qui récupéreront les nouvelles colonnes ?
  • Quelles transformations référencent les colonnes en cours de modification ?

Changements de données (valeurs, volumes, timing) :

  • Les agrégations descendantes resteront-elles valides ?
  • Y a-t-il des hypothèses de gestion des NULL qui se casseront ?
  • Les changements de timing affecteront-ils les SLA ?

Suppression/Dépréciation :

  • L'arbre de dépendances complet doit d'abord être migré
  • Communication nécessaire pour tous les stakeholders

Étape 5 : Trouver les stakeholders

Identifiez qui possède les ressources descendantes :

  1. Propriétaires de DAGs : Vérifiez le champ owners dans les définitions de DAG
  2. Propriétaires de dashboards : Généralement dans les métadonnées des outils BI
  3. Propriété d'équipe : Cherchez les motifs de nommage d'équipe ou la documentation

Résultat : Rapport d'impact

Résumé

« Changer fct.orders affectera X tables, Y DAGs et Z dashboards »

Diagramme d'impact

                    +--> [agg.daily_sales] --> [Executive Dashboard]
                    |
[fct.orders] -------+--> [rpt.order_details] --> [Ops Team Email]
                    |
                    +--> [ml.features] --> [Demand Model]

Impacts détaillés

Descendant Type Criticité Propriétaire Notes
agg.daily_sales Table Critique data-eng Mise à jour horaire
Executive Dashboard Dashboard Critique analytics Consulté quotidiennement par le PDG
ml.order_features Table Haute ml-team Réentraînement hebdomadaire

Évaluation des risques

Type de changement Niveau de risque Atténuation
Ajouter une colonne Bas Aucune action requise
Renommer une colonne Haute Mettre à jour 3 DAGs, 2 dashboards
Supprimer une colonne Critique Plan de migration complet requis
Changer le type de données Moyen Tester les agrégations descendantes

Actions recommandées

Avant de faire des changements :

  1. [ ] Notifier les propriétaires : @data-eng, @analytics, @ml-team
  2. [ ] Mettre à jour le DAG descendant : transform_daily_sales
  3. [ ] Tester le dashboard : Executive KPIs
  4. [ ] Programmer le changement pendant une fenêtre à faible impact

Skills connexes

  • Tracer la source des données : skill tracing-upstream-lineage
  • Vérifier la fraîcheur descendante : skill checking-freshness
  • Déboguer les DAGs cassés : skill debugging-dags
  • Ajouter des annotations de lineage manuel : skill annotating-task-lineage
  • Créer des extracteurs de lineage personnalisés : skill creating-openlineage-extractors

Skills similaires