Cómo obtener el linaje de datos de tus AWS Glue Jobs

El catálogo no es el linaje

Es la confusión más común. El Glue Data Catalog es un inventario: nombres de bases, tablas, columnas, tipos y ubicaciones. Te dice que ready.customer_360 existe y tiene doce columnas.

Lo que no te dice es quién la escribe, qué tabla de origen alimenta cada una de esas doce columnas ni qué transformación se aplicó por el camino. Esa información no vive en el catálogo: vive en el código del job.

Dónde está de verdad la relación

En un Glue Job de PySpark, el linaje está repartido entre varias fuentes que hay que leer a la vez:

• El código, en las llamadas de lectura y escritura: spark.read.table(...), df.write.saveAsTable(...), spark.read.parquet(ruta).
• El SQL embebido, donde suele estar el detalle de columnas: los SELECT con alias, los JOIN y las agregaciones.
• Los parámetros del job, porque muy a menudo la base o el bucket llegan como argumento (--SOURCE_DB) y el código nunca menciona el nombre real.
• Las variables de entorno y dependencias, que completan lo anterior cuando el job importa utilidades compartidas.

Por eso el análisis estático simple falla tan a menudo: si solo miras el código, el destino es una variable; si solo miras la configuración, no sabes qué se hace con ella.

Por qué el enfoque manual no aguanta

La alternativa habitual es documentar a mano: un diagrama, una hoja de cálculo, una página en Confluence. Funciona el día que se escribe y empieza a envejecer al siguiente despliegue. En una plataforma con decenas de jobs, la documentación y la realidad divergen en semanas, y a partir de ahí nadie se fía de ella, que es peor que no tenerla.

El síntoma es reconocible: cuando alguien pregunta qué pasa si cambia una columna, la respuesta llega por chat y depende de quién esté conectado.

Qué hace falta para automatizarlo

Extraer el linaje de un Glue Job de forma fiable exige cuatro cosas:

1. Descubrir los jobs que existen en la cuenta, sin depender de que alguien mantenga una lista.
2. Recuperar sus artefactos: el script, el SQL, la configuración y los parámetros.
3. Interpretarlos juntos para inferir fuentes, destinos y transformaciones. Aquí es donde un modelo de lenguaje aporta, porque el patrón varía en cada equipo.
4. Acompañar cada relación de su evidencia: el fichero y la línea, la sentencia SQL o el parámetro concreto en el que se basa.

Ese cuarto punto es el que separa una herramienta usable de una caja negra. Sin evidencia, un linaje generado automáticamente es una afirmación que nadie puede comprobar, y en gobierno del dato eso no sirve.

Hasta dónde se puede llegar a nivel de columna

Cuando el SQL es explícito, el linaje de columna se puede determinar con precisión y además clasificar la transformación: direct, rename, cast, calculation, join o aggregation.

Cuando no lo es —un SELECT *, un DataFrame construido dinámicamente— la respuesta honesta es que no hay evidencia suficiente. Lo correcto es marcarlo como tal en lugar de inventar una relación plausible: un linaje con huecos declarados es útil, uno con relaciones inventadas es peligroso.

Cómo lo resuelve AI Data Lineage Mapper

El producto se conecta a tu cuenta AWS en modo solo lectura, mediante un rol que se asume entre cuentas protegido con ExternalId, o desplegado como appliance dentro de tu propio entorno. Descubre los recursos, tú eliges qué procesos analizar, y sobre ellos lee código, SQL, configuración y dependencias.

Cada relación propuesta llega con un nivel de confianza y su evidencia, y pasa por revisión humana antes de publicarse: se puede confirmar, rechazar o dejar pendiente. El modelo puede ejecutarse en tu propia infraestructura, de modo que el código de tus procesos no salga de tu red.

A partir de ahí el linaje queda persistido y explorable: grafo, recorrido aguas arriba y aguas abajo, análisis de impacto y consultas en lenguaje natural.