Cómo evitar que la gobernanza dependa de que alguien rellene un campo a mano
La automatización de metadatos en pipelines de datos consiste en capturar linaje, clasificación de sensibilidad, calidad y ownership como parte de la propia ejecución del pipeline, en lugar de como documentación manual posterior.
En entornos multi-cloud, el reto adicional es que plataformas como Databricks Unity Catalog y AWS Glue Data Catalog / Lake Formation no comparten gobernanza de forma nativa: la federación entre catálogos permite consultar tablas de un lado desde el otro, pero no propaga permisos, tags ni políticas automáticamente entre ellos.
Por eso, antes de automatizar nada, hay que decidir explícitamente dónde vive la fuente de verdad de las políticas —o evaluar un catálogo abierto neutral como Apache Polaris o Apache Gravitino cuando el compromiso multi-motor es real y a largo plazo.
Automatizar metadatos no es añadir más campos a rellenar. Es diseñar el pipeline para que el metadato se genere solo, como efecto secundario de ejecutarse.
Es una escena habitual en comités de arquitectura: alguien pregunta quién es el owner de una tabla concreta, y la respuesta tarda tres días y dos reuniones en llegar. El catálogo dice una cosa, el pipeline hace otra, y la documentación en Confluence lleva ocho meses sin actualizarse. Ninguna de las tres fuentes está necesariamente equivocada: simplemente nadie las mantiene sincronizadas, porque mantenerlas sincronizadas a mano no es un trabajo que escale con el número de pipelines.
El patrón es conocido para cualquier Director de Tecnología que gestione más de una plataforma de datos: cada equipo documenta a su manera, con su propio criterio de qué es una tabla crítica y qué no, y con distinta disciplina a la hora de mantener esa documentación al día. El resultado no es falta de gobernanza sobre el papel: normalmente existe un framework, unas guías, incluso un comité. Sino un desfase permanente entre lo que dicen los documentos y lo que hacen los pipelines en producción.
Cuando además la organización opera en más de una nube o más de una plataforma; típicamente Databricks para transformación y ML, y servicios nativos de AWS, Azure o GCP para el resto del stack; el problema se multiplica: cada plataforma tiene su propio catálogo, su propio modelo de permisos y su propia forma de registrar linaje. Sin una decisión explícita de arquitectura, el resultado son catálogos duplicados y políticas que dicen cosas distintas sobre el mismo dato.
Automatizar metadatos significa que el linaje, la clasificación de sensibilidad, las métricas de calidad y el ownership se generan como parte de la ejecución del pipeline, leídos del propio código, del motor de ejecución o de reglas declarativas. No como una tarea de documentación separada que alguien debe recordar hacer después.
Esto tiene una implicación de diseño importante: el metadato deja de ser responsabilidad de una persona y pasa a ser responsabilidad del pipeline. Si el pipeline se ejecuta, el catálogo se actualiza. Si el pipeline cambia de esquema, el linaje lo refleja automáticamente. Nadie tiene que acordarse de nada.
Unity Catalog organiza los activos de datos en un espacio de nombres de tres niveles (catálogo.esquema.tabla) sobre un metastore a nivel de cuenta, normalmente uno por región de nube, al que se conectan todos los workspaces de Databricks (en AWS, Azure o GCP) sin necesidad de mover los datos. Su aportación diferencial frente a un catálogo tradicional es que unifica el gobierno no solo de tablas, sino también de ficheros, modelos de machine learning, notebooks y, cada vez más, herramientas usadas por agentes de IA, con linaje automático a nivel de columna y control de acceso de grano fino.
En el lado de AWS, AWS Glue Data Catalog actúa como repositorio de metadatos para Athena, Redshift Spectrum o EMR, y es el metastore técnico sobre el que se apoya AWS Lake Formation para aplicar permisos mediante LF-Tags: etiquetas que permiten definir control de acceso por atributo en lugar de permiso por permiso. El límite importante a tener en cuenta: tanto los permisos de Lake Formation como los LF-Tags están acotados a la cuenta de AWS donde se crean, y no se propagan automáticamente a otras cuentas ni a otras nubes.
Aquí es donde conviene evitar un malentendido habitual en arquitectura multi-cloud. AWS Glue ha incorporado federación de catálogo con catálogos Iceberg remotos, incluido Unity Catalog, lo que permite que motores como Athena o Redshift consulten tablas gobernadas por Unity Catalog sin duplicar los datos. Esto es realmente útil para el consumo, pero es una federación de consulta, no de gobierno: una tabla se vuelve consultable desde el otro lado, pero no se vuelve gobernada por el otro lado. Las políticas, los tags de sensibilidad y el linaje de negocio siguen viviendo donde se definieron originalmente.
Para una organización con un compromiso real y sostenido con más de un motor, esto hace cada vez más relevante evaluar catálogos abiertos como Apache Polaris: un catálogo Iceberg basado en REST, con RBAC de grano fino y credential vending nativo entre AWS, Azure y GCP; o Apache Gravitino, pensado como un catálogo de catálogos que federa metadatos heterogéneos sin obligar a centralizarlos en una única plataforma propietaria.
El patrón que realmente reduce la carga operativa es capturar linaje y calidad en el momento de la ejecución; a nivel de motor de procesamiento, no reconstruirlos después analizando logs o pidiendo a cada equipo que los documente. Cuando el linaje se genera como parte de cómo se ejecuta el pipeline, sigue siendo preciso aunque el pipeline cambie; cuando se documenta a mano, empieza a divergir de la realidad desde el primer cambio de esquema que nadie reporta.
Un catálogo que hay que actualizar a mano no es gobierno de metadatos. Es una lista de tareas pendientes con forma de base de datos.
¿Tu equipo de datos dedica más tiempo a mantener catálogos sincronizados a mano que a construir pipelines nuevos?
En Galde diseñamos arquitecturas de gobierno de metadatos automatizadas sobre Databricks, AWS y Unity Catalog, adaptadas al nivel real de complejidad multi-cloud de cada organización.
Desde data platforms, en Galde diseñamos e implementamos arquitecturas de pipelines con captura automática de linaje, calidad y clasificación de sensibilidad, sobre Databricks, Unity Catalog y los servicios de gobierno nativos de AWS, Azure o GCP.
Cuando la complejidad organizativa lo justifica: múltiples fuentes heterogéneas, necesidad de exponer datos a aplicaciones de negocio y no solo a dashboards, evaluamos también si una capa semántica como Palantir Foundry aporta valor por encima de la arquitectura de catálogos.
Este trabajo se apoya en el mismo enfoque de gobernanza de datos operativa que aplicamos al resto de dominios: automatizar la gobernanza en la herramienta, no delegarla en la disciplina individual de cada ingeniero de datos.
La gobernanza de metadatos manual no falla por falta de voluntad de los equipos: falla porque no escala. Cada pipeline nuevo, cada tabla derivada y cada nube adicional multiplican el esfuerzo de mantener catálogos, linaje y clasificación al día a mano. Automatizar esa captura como parte de la ejecución del pipeline, y decidir explícitamente dónde vive la fuente de verdad cuando hay más de una plataforma implicada, es lo que permite que el gobierno de datos crezca al mismo ritmo que la plataforma, en lugar de convertirse en el cuello de botella que la frena.
Puede consultarlas mediante federación de catálogo, pero no gobernarlas en el sentido de aplicar sus propias políticas de acceso o tags sobre ellas. Las políticas de esas tablas se siguen definiendo en Lake Formation; Unity Catalog las hace consultables desde el lado de Databricks.
La catalogación manual depende de que una persona documente cada tabla o pipeline, lo que garantiza desfases en cuanto cambia algo. La automatización genera linaje, clasificación y calidad como parte de la propia ejecución del pipeline, por lo que se mantiene actualizada sin intervención humana.
Pueden convivir, y en la práctica es lo más habitual en organizaciones medianas y grandes. Lo importante es decidir explícitamente qué catálogo es la fuente de verdad de las políticas para cada dominio de datos, en lugar de asumir que la federación entre ambos resuelve la gobernanza automáticamente.
Es la aplicación de reglas o modelos que detectan y etiquetan datos personales o sensibles en el momento en que entran al sistema. Importa especialmente en multi-cloud porque, sin ella, cada plataforma puede acabar clasificando el mismo dato de forma distinta, generando inconsistencias en el control de acceso.
Asignando de forma explícita un catálogo como fuente de verdad por dominio de datos, tratando cualquier federación hacia otras plataformas como una vista de solo consulta, y considerando catálogos abiertos como Apache Polaris o Apache Gravitino cuando el número de motores y nubes implicados hace inviable mantener una única plataforma propietaria como centro de gobierno.
