Los datos de una empresa nunca están quietos. El negocio cambia, y con él cambian los datos que lo describen: se añade un nuevo tipo de información sobre los clientes, se deja de usar un campo que ya no tiene sentido, se cambia la forma en que se registra una transacción. Cada uno de estos cambios en la estructura de los datos — llamada esquema — es natural e inevitable. El problema es que, si no se gestiona bien, un cambio aparentemente inocente en la estructura de una tabla puede romper todo lo que depende de ella aguas abajo: pipelines que dejan de correr, informes que quedan vacíos, análisis que fallan. Gestionar estos cambios de forma controlada — la llamada schema evolution, o evolución de esquema — es una de las competencias que distinguen una operación de datos robusta de una frágil.
La tensión está en el corazón del problema: los datos necesitan evolucionar para acompañar al negocio, pero esa evolución amenaza la estabilidad de todo lo que los consume. Una estructura de datos congelada, que nunca cambia, sería estable pero rápidamente quedaría desalineada de la realidad. Una estructura que cambia sin cuidado sería flexible pero rompería constantemente lo que de ella depende. La evolución de esquema es el arte de permitir que los datos cambien sin que esos cambios causen daños — de conciliar la necesidad de evolucionar con la necesidad de no romper nada.
Este artículo explica por qué los cambios de esquema son tan peligrosos, qué tipos de cambio existen, y cómo gestionarlos de forma que los datos puedan evolucionar con seguridad.
Por qué un cambio inocente rompe todo
Una tabla de datos rara vez vive aislada. Típicamente, es consumida por muchas cosas aguas abajo: pipelines que la leen y transforman, informes que la muestran, modelos que la usan, otras tablas que de ella derivan. Cada uno de estos consumidores fue construido asumiendo que la tabla tiene una determinada estructura — determinados campos, con determinados tipos. Cuando esa estructura cambia, esos consumidores pueden romperse, porque la suposición en que se apoyaban dejó de ser verdad.
Lo que hace esto particularmente peligroso es la invisibilidad de la dependencia. Quien hace un cambio en una tabla rara vez conoce todo lo que depende de ella — todos los pipelines, informes y análisis que la consumen, muchas veces construidos por otras personas, a lo largo del tiempo. Así, un cambio hecho con la mejor de las intenciones, para mejorar la estructura de los datos, puede romper silenciosamente un informe crítico del otro lado de la empresa, y quien hizo el cambio ni se da cuenta. Es esta cadena de dependencias invisibles la que transforma una alteración aparentemente simple en un riesgo real.
No todos los cambios son iguales
Una distinción fundamental en la evolución de esquema es entre cambios seguros y cambios peligrosos. Algunos cambios son compatibles — no rompen lo que ya existe. Añadir un nuevo campo a una tabla, por ejemplo, es generalmente seguro: los consumidores que no conocen el nuevo campo simplemente lo ignoran y siguen funcionando como antes. Estos cambios aditivos pueden hacerse con relativa tranquilidad, porque no quitan nada en lo que alguien pudiera estar confiando.
Otros cambios son incompatibles — rompen lo que depende de ellos. Remover un campo, cambiar su tipo, o cambiar su significado son cambios peligrosos, porque cualquier consumidor que dependiera de aquel campo, tal como era, deja de funcionar. Distinguir estos dos tipos de cambio es el primer paso para gestionar la evolución de esquema: los cambios compatibles pueden hacerse con cuidado ligero; los incompatibles exigen un proceso mucho más cuidadoso, porque van, por definición, a romper algo si no se gestionan.
Los principios de una evolución segura
- Preferir cambios aditivos: añadir en vez de alterar o remover siempre que sea posible, porque añadir rara vez rompe lo que existe.
- Deprecar antes de remover: marcar un campo como obsoleto y dar tiempo a los consumidores para adaptarse antes de removerlo de hecho.
- Comunicar los cambios: avisar con antelación a quien depende de los datos, para que pueda prepararse en vez de ser tomado por sorpresa.
- Validar automáticamente: tener verificaciones que detectan cambios de esquema peligrosos antes de que lleguen a producción y rompan cosas.
La técnica de deprecar antes de remover
Una de las técnicas más valiosas en la evolución de esquema es nunca remover algo abruptamente, sino deprecarlo primero. Cuando un campo ya no es necesario y se quiere removerlo, en vez de borrarlo de inmediato — lo que rompería todo lo que de él dependiera — se marca como obsoleto y se comunica que va a ser removido dentro de un determinado plazo. Durante ese período, el campo sigue existiendo, pero todos saben que deben dejar de usarlo. Solo después de dado tiempo suficiente para que todos se adapten es que el campo se remueve efectivamente.
Este enfoque transforma un cambio peligroso y abrupto en una transición controlada y predecible. En vez de romper todo de una vez y obligar a correcciones de emergencia, se les da a los consumidores la oportunidad de adaptarse a su tiempo, con aviso previo. Es la diferencia entre demoler un edificio con personas dentro y darles tiempo para salir primero. Esta paciencia tiene un costo — mantener el campo obsoleto durante algún tiempo más — pero evita el caos y los incidentes que una remoción abrupta causaría.
Un caso concreto
Una empresa tenía una tabla central de clientes que era consumida por una cantidad impresionante de cosas — decenas de informes, varios pipelines, algunos modelos, y otras tablas que de ella derivaban, muchas construidas por diferentes equipos a lo largo de años. En cierto momento, el negocio cambió, y uno de los campos de esa tabla dejó de tener sentido, mientras era necesario cambiar el formato de otro. Un primer intento de hacer estos cambios salió mal: un equipo, para ordenar la tabla, removió el campo obsoleto y alteró el formato del otro directamente, sin darse cuenta de la extensión de las dependencias. El resultado fue un día de caos — varios informes de otras áreas quedaron vacíos o con errores, pipelines fallaron, y nadie entendió inmediatamente por qué, porque el cambio se había hecho en una tabla y los efectos se manifestaron en un lugar completamente diferente. Tras este susto, la empresa adoptó un enfoque disciplinado de evolución de esquema. Para futuros cambios, siguieron principios claros. Los cambios aditivos — añadir campos nuevos — se hacían con relativa tranquilidad. Pero para los cambios peligrosos, como remover un campo o cambiar su formato, adoptaron la técnica de deprecar antes de remover: marcaban el campo como obsoleto, comunicaban el cambio a todos los equipos con bastante antelación, daban tiempo para que todos se adaptaran, y solo después removían. Añadieron también validaciones automáticas que detectaban cambios de esquema peligrosos antes de que llegaran a producción. La siguiente vez que fue necesario remover un campo, el proceso salió sin incidentes: el campo fue deprecado, los equipos fueron avisados, tuvieron semanas para adaptarse, y cuando el campo finalmente se removió, nada se rompió, porque ya nadie dependía de él. El mismo cambio que antes había causado un día de caos pasó a ser una transición tranquila y predecible. La diferencia no estuvo en evitar el cambio — los datos tienen que evolucionar —, sino en gestionarlo de forma controlada en vez de hacerlo abruptamente.
Evolucionar sin miedo
El objetivo último de la evolución de esquema es permitir que los datos de una empresa sigan acompañando al negocio sin que esa necesaria evolución se vuelva una fuente de miedo y de incidentes. Una operación de datos que gestiona bien los cambios de esquema puede evolucionar su estructura de datos con confianza, sabiendo que tiene los procesos para hacerlo sin romper nada. Una que los gestiona mal queda presa en un dilema: o congela los datos y queda desalineada de la realidad, o los cambia y vive en crisis constante. La buena evolución de esquema remueve este dilema, permitiendo el cambio seguro.
Esta capacidad se conecta directamente con otras prácticas de datos maduros — los contratos de datos, que formalizan las promesas sobre la estructura de los datos, y la observabilidad, que detecta cuando algo cambia inesperadamente. Todas comparten el mismo objetivo: volver los datos robustos y fiables incluso en un mundo en constante cambio. La evolución de esquema es la pieza que garantiza que el inevitable cambio de la estructura de los datos ocurre de forma controlada, y no como una serie de sorpresas desagradables.
En la práctica
Si en tu empresa los cambios en la estructura de los datos se hacen de forma ad hoc, y de vez en cuando una alteración en una tabla rompe informes o pipelines del otro lado de la organización, necesitas un enfoque disciplinado a la evolución de esquema. Adopta principios simples: prefiere añadir a alterar, depreca antes de remover dando tiempo a las personas para adaptarse, comunica los cambios con antelación, y valida automáticamente los cambios peligrosos. ¿Los cambios en la estructura de tus datos se gestionan de forma controlada, o vives con el temor de que el próximo cambio rompa algo importante del otro lado de la empresa?
