Análisis de impacto: qué se rompe si cambias una tabla o una columna

Qué es exactamente el análisis de impacto

Es recorrer el linaje hacia abajo desde el activo que quieres cambiar y enumerar todo lo que depende de él: procesos que lo leen, tablas que se construyen a partir de él, datasets y rutas que acabarían afectados.

Su gemelo es el recorrido hacia arriba, que responde a la pregunta inversa: de dónde viene este dato y en quién estoy confiando cuando lo uso. Las dos direcciones salen del mismo grafo.

Por qué preguntar por chat no escala

El método habitual es escribir en un canal: «¿alguien usa curated.crm_orders?». Tiene tres problemas.

• Depende de quién esté disponible y de que se acuerde.
• Cubre solo lo que esa persona conoce, no lo que existe. Los consumidores olvidados son justo los que rompen.
• No deja rastro: la siguiente vez se vuelve a preguntar desde cero.

En una plataforma pequeña funciona. Cuando hay decenas de procesos y varias personas han entrado y salido del equipo, ese conocimiento tribal es exactamente el riesgo que hay que eliminar.

Qué necesita el linaje para poder responder

No todo linaje sirve para análisis de impacto. Para que la respuesta sea utilizable hacen falta cuatro propiedades:

1. Cobertura conocida. Saber qué procesos están analizados y cuáles no. Un grafo que parece completo pero cubre la mitad de los jobs produce falsos negativos, que son los peligrosos.
2. Profundidad configurable. Un nivel responde «quién lee esta tabla»; tres o cuatro responden «qué informe se queda en blanco el lunes».
3. Granularidad de columna cuando el cambio es un campo. Renombrar una columna no afecta a todos los consumidores de la tabla, solo a los que usan ese campo.
4. Confianza y evidencia por relación, para distinguir lo que está confirmado de lo que es una inferencia sin verificar.

Un ejemplo concreto

Quieres cambiar el tipo de orders.amount de decimal a entero. El recorrido hacia abajo muestra tres cosas:

• Un Glue Job lo lee y lo agrega en customer_360.total, con transformación aggregation.
• Una vista de Redshift lo expone a los informes.
• Una Lambda lo escribe a una ruta de S3 que consume otro equipo.

Sin el linaje habrías visto los dos primeros, que son los evidentes. El tercero, el que cruza a otro equipo, es el que produce la llamada del viernes por la tarde.

Del análisis puntual al gobierno continuo

El impacto no es solo una consulta antes de un cambio. El mismo grafo permite responder preguntas de gobierno que suelen quedar sin respuesta: qué pipelines no tienen ningún consumidor y probablemente sobran, qué activos comparten varios dominios, quién es el propietario de un dataset del que depende media plataforma.

Para eso el linaje tiene que estar publicado y vivo, no en una presentación de hace seis meses. Es la diferencia entre documentar y gobernar.

Cómo lo resuelve AI Data Lineage Mapper

El linaje se extrae del código, el SQL y la configuración de tus Glue Jobs, funciones Lambda y Step Functions, con evidencia y nivel de confianza por relación, y se publica solo después de revisión humana.

Sobre él, el explorador permite filtrar por tipo de nodo, dirección, profundidad de uno a cinco niveles, estado de revisión y confianza mínima. Y el Copilot responde en lenguaje natural a preguntas como qué procesos escriben una tabla o qué se vería afectado por un cambio, apoyándose en el linaje persistido.