Curso de Unity Catalog - Gobernanza y Seguridad en Lakehouse

Comprender el metastore como raíz lógica del gobierno en Unity Catalog y punto central para organizar catálogos, esquemas y permisos.

Diseñar la relación entre metastores y workspaces considerando región, cloud, entornos, dominios, aislamiento y requisitos regulatorios.

Evaluar cuándo conviene compartir un metastore entre varios workspaces y cuándo separar por región, entorno o unidad organizativa.

Planificar workspaces de desarrollo, integración, preproducción y producción con reglas claras de acceso y promoción de objetos.

Definir ownership del metastore, administradores, grupos de plataforma, responsables de dominio y procedimientos de cambio.

Evitar diseños donde demasiados usuarios son administradores del metastore por comodidad operativa.

Documentar las decisiones de asignación de workspaces al metastore, incluyendo riesgos, restricciones y dependencias.

Revisar impacto de nombres, regiones, cloud storage, identidades y conectividad antes de habilitar el gobierno a escala.

Crear una política de gestión de metastore que contemple alta, baja, auditoría, cambios y segregación de funciones.

Diseñar un mapa de workspaces y metastores para una empresa con varios dominios de datos y entornos diferenciados.

Diseñar catálogos como grandes contenedores de gobierno para dominios, entornos, unidades de negocio, productos de datos o zonas Lakehouse.

Definir esquemas como agrupaciones funcionales dentro de catálogos, evitando mezclar objetos sin relación en estructuras genéricas.

Comparar estrategias de catálogo por entorno, por dominio, por tipo de dato, por producto o por patrón híbrido.

Evitar nombres ambiguos como `default`, `misc`, `sandbox` o `data` cuando impiden entender ownership y finalidad.

Diseñar convenciones de naming para catálogos, esquemas, tablas, vistas, volúmenes, funciones, modelos y external locations.

Separar zonas de ingestión, curación, consumo, experimentación, compartición y publicación analítica sin duplicar gobierno innecesariamente.

Definir reglas de creación de catálogos y esquemas: quién puede crearlos, bajo qué aprobación y con qué documentación mínima.

Organizar catálogos para facilitar permisos heredados, descubrimiento, auditoría y segregación de datos sensibles.

Crear una plantilla de documentación por catálogo con owner, finalidad, datos incluidos, sensibilidad, consumidores y ciclo de vida.

Diseñar una estructura de catálogos y esquemas para un Lakehouse empresarial con varios dominios y entornos.

Comprender los securable objects de Unity Catalog y cómo se organizan jerárquicamente para aplicar privilegios, ownership y herencia.

Diferenciar metastore, catalog, schema, table, view, volume, function, model, storage credential, external location y connection.

Interpretar privilegios como derechos concedidos a principals para operar sobre objetos gobernados dentro del metastore.

Diseñar permisos por grupos y service principals, evitando concesiones directas a usuarios salvo casos excepcionales y justificados.

Aplicar herencia de privilegios con cuidado, entendiendo cuándo simplifica y cuándo puede abrir accesos excesivos.

Diferenciar privilegios de lectura, escritura, uso, creación, modificación, ownership, administración y acceso a almacenamiento.

Revisar cómo cambian los permisos necesarios según el objeto: tabla, vista, volumen, modelo, función o external location.

Evitar conceder permisos amplios como patrón por defecto, especialmente en catálogos productivos o datos sensibles.

Crear una matriz de privilegios por rol: consumidor BI, data engineer, data scientist, steward, plataforma, auditor y aplicación.

Construir un modelo de permisos completo sobre un catálogo de laboratorio, validando accesos permitidos y denegados.

Diseñar un modelo de identidades basado en grupos corporativos, evitando gestionar permisos persona a persona dentro de Databricks.

Diferenciar usuarios interactivos, grupos, service principals, identidades de aplicación, jobs automatizados y cuentas de administración.

Crear grupos funcionales por dominio, rol, entorno y nivel de acceso: lectura, escritura, administración, publicación y auditoría.

Asignar service principals a pipelines, jobs, integraciones y herramientas externas con permisos mínimos y trazabilidad clara.

Evitar compartir usuarios técnicos o tokens personales en procesos productivos, porque dificulta auditoría y revocación.

Diseñar procesos de alta, baja y cambio de rol alineados con IAM corporativo y ciclo de vida del empleado.

Revisar permisos efectivos para detectar usuarios con accesos heredados, duplicados o fuera de su función real.

Separar responsabilidades entre administración de plataforma, ownership de datos, seguridad, explotación analítica y auditoría.

Documentar propietarios de grupos, reglas de membresía, revisiones periódicas y controles de acceso.

Construir un modelo de identidades de laboratorio con usuarios, grupos y service principals para distintos escenarios de gobierno.

Definir ownership como responsabilidad real sobre datos, permisos, calidad, documentación, ciclo de vida y decisiones de cambio.

Diferenciar owner técnico, owner funcional, data steward, administrador de plataforma, consumidor y auditor.

Diseñar administración delegada para que los dominios gestionen sus activos sin depender de un equipo central para cada cambio menor.

Evitar que todos los objetos sean propiedad de administradores globales o service principals sin contexto funcional.

Establecer procesos para transferir ownership cuando cambia un equipo, un producto de datos o una aplicación.

Revisar objetos huérfanos, owners obsoletos, owners personales y recursos creados fuera del proceso estándar.

Crear criterios para que un catálogo o esquema pueda pasar a producción: owner, documentación, permisos, linaje, calidad y clasificación.

Definir revisiones periódicas de ownership y accesos, especialmente en datos sensibles o de alto valor.

Documentar excepciones cuando un objeto requiere owner técnico compartido o administración centralizada.

Diseñar un modelo operativo de ownership para Unity Catalog con RACI, procesos y controles de revisión.

Diferenciar managed tables y external tables desde gobierno, almacenamiento, ciclo de vida, optimización, ownership y responsabilidad operativa.

Revisar el criterio de Databricks: las managed tables en Unity Catalog son el tipo recomendado por defecto para Delta Lake y Apache Iceberg, con gestión de lectura, escritura, almacenamiento y optimización desde Unity Catalog.

Decidir cuándo usar managed tables para simplificar gobierno, rendimiento, administración y optimización dentro de Databricks.

Decidir cuándo usar external tables por necesidades de interoperabilidad, datos existentes, ownership externo o herramientas fuera de Databricks.

Evitar registrar la misma ruta cloud varias veces en distintas tablas o catálogos, porque complica permisos y consistencia.

Diseñar ubicaciones de almacenamiento gestionadas por catálogo o esquema, evitando rutas improvisadas por equipo.

Definir políticas de ciclo de vida, retención, backup, borrado, archivado y restauración según criticidad del dato.

Revisar diferencias entre DROP, eliminación lógica, almacenamiento subyacente y responsabilidad sobre rutas externas.

Documentar ubicación, propietario, sensibilidad, formato, origen y consumidores de cada tabla crítica.

Construir una estrategia de tablas gestionadas y externas para un Lakehouse con dominios, entornos y datos compartidos.

Comprender storage credentials como objetos que representan la información de autenticación necesaria para acceder a rutas cloud.

Comprender external locations como objetos que representan rutas de cloud storage asociadas a una storage credential.

Diseñar external locations por dominio, entorno, zona, sensibilidad y patrón de acceso, evitando rutas demasiado amplias.

Aplicar permisos sobre external locations para controlar quién puede crear tablas externas, acceder a archivos o gestionar datos.

Separar permisos de cloud IAM y permisos de Unity Catalog, asegurando que ambos modelos no se contradicen.

Evitar que usuarios accedan directamente al bucket o contenedor cloud saltándose Unity Catalog y la trazabilidad de Databricks.

Diseñar credenciales de almacenamiento con mínimos privilegios, rotación, ownership y procedimientos de emergencia.

Revisar configuraciones específicas de cloud como roles, managed identities, service accounts, encryption, redes y policies.

Documentar cada external location con finalidad, ruta, credencial, owner, sensibilidad, consumidores y controles aplicados.

Crear external locations de laboratorio y validar accesos correctos desde SQL, notebooks, jobs y usuarios con distintos permisos.

Comprender los volumes como mecanismo gobernado para gestionar archivos no tabulares dentro de Unity Catalog.

Diseñar volúmenes para archivos de entrada, documentos, modelos, librerías, datos semiestructurados, imágenes, logs o artefactos analíticos.

Diferenciar cuándo un dato debe modelarse como tabla y cuándo tiene sentido gestionarlo como archivo en volumen.

Aplicar permisos sobre volúmenes para lectura, escritura, creación, modificación y administración de archivos.

Evitar rutas compartidas fuera de gobierno para intercambiar ficheros entre notebooks, jobs o equipos.

Diseñar convenciones de nombres, carpetas, lifecycle, sensibilidad y propietarios de volúmenes.

Controlar acceso a archivos sensibles, documentos con datos personales o artefactos generados por pipelines.

Integrar volúmenes en workflows de ingestión, ML, reporting, feature engineering y data products.

Auditar uso de volúmenes para detectar almacenamiento huérfano, archivos obsoletos o permisos excesivos.

Construir un caso práctico con volúmenes para archivos semiestructurados y documentación de gobierno asociada.

Diseñar vistas como capa de consumo para ocultar complejidad, estandarizar contratos y limitar exposición de datos internos.

Usar dynamic views cuando se requiere lógica de seguridad o transformación dependiente de identidad o pertenencia a grupos.

Comparar vistas dinámicas con row filters, column masks y ABAC para decidir el patrón adecuado.

Evitar vistas que replican toda la tabla sin aportar seguridad, semántica, contrato o simplificación.

Diseñar vistas de consumo para BI, reporting, científicos de datos, APIs internas y herramientas externas.

Aplicar permisos sobre vistas de forma que los usuarios no necesiten acceso directo a tablas base cuando no corresponde.

Controlar impactos de rendimiento cuando una vista añade filtros, joins, funciones o lógica compleja en tiempo de consulta.

Documentar vistas como contratos de consumo con owner, definición funcional, columnas, sensibilidad y consumidores.

Validar escenarios donde un mismo dataset debe verse de forma distinta según rol, país, unidad de negocio o finalidad.

Construir vistas dinámicas y vistas de consumo para proteger datos sensibles sin duplicar tablas.

Aplicar row filters para restringir filas visibles según usuario, grupo, región, departamento, tenant o regla de negocio.

Aplicar column masks para transformar u ocultar columnas sensibles como identificadores, emails, importes, datos personales o atributos confidenciales.

Comprender que Unity Catalog permite implementar seguridad de filas y columnas con ABAC o políticas asignadas a tablas y columnas.

Diseñar funciones reutilizables de filtrado o enmascarado que sean comprensibles, testables y mantenibles.

Evitar lógica opaca que hace imposible explicar por qué un usuario ve o no ve un dato concreto.

Validar seguridad granular con usuarios de prueba, grupos, escenarios positivos, escenarios negativos y auditoría de consultas.

Medir impacto de filtros y máscaras sobre rendimiento, optimización, joins, BI, vistas y pipelines.

Documentar políticas de seguridad granular con finalidad, owner, criterios, datos afectados y proceso de excepción.

Evitar usar solo vistas duplicadas para cada perfil cuando una política centralizada resulta más mantenible.

Construir un caso completo de seguridad por filas y columnas para un dataset sensible de laboratorio.

Diseñar un modelo de tags para clasificar datos por sensibilidad, dominio, país, regulación, criticidad, owner y finalidad.

Diferenciar tags informativos, tags gobernados, tags de clasificación, tags de privacidad y tags usados para políticas de acceso.

Comprender ABAC como enfoque para aplicar políticas de acceso basadas en atributos y tags, escalando controles sobre objetos y columnas.

Aplicar ABAC para row-level y column-level security mediante políticas centralizadas cuando el caso requiere gobierno a escala.

Evitar taxonomías de tags demasiado amplias, inconsistentes o sin owner, porque terminan perdiendo valor operativo.

Definir quién puede crear, modificar, asignar y auditar tags en catálogos, esquemas, tablas y columnas.

Diseñar políticas ABAC para datos personales, confidenciales, financieros, sanitarios, comerciales o restringidos por región.

Validar que las políticas ABAC no sustituyen permisos base, sino que añaden restricciones sobre accesos ya concedidos.

Documentar matriz de clasificación con ejemplos, criterios de uso, revisiones y proceso de corrección.

Construir una estrategia de clasificación y ABAC para un Lakehouse con datos sensibles y múltiples roles de consumo.

Usar workspace bindings para controlar qué catálogos pueden estar accesibles desde qué workspaces.

Diseñar aislamiento entre desarrollo, preproducción y producción para evitar que datos productivos se expongan en entornos no controlados.

Separar workspaces por dominio, región, nivel de sensibilidad o tipo de carga cuando la organización lo requiere.

Evitar que un catálogo productivo sea accesible desde workspaces de experimentación sin justificación y controles adicionales.

Diseñar políticas de acceso donde un mismo metastore puede gobernar varios workspaces sin perder segregación.

Validar comportamiento de usuarios que pertenecen a varios grupos y trabajan desde distintos workspaces.

Documentar qué catálogos se exponen en cada workspace y bajo qué criterios.

Revisar escenarios de BI, ML, exploración, ingestión y producción para decidir bindings adecuados.

Integrar workspace bindings en el proceso de alta de nuevos catálogos o nuevos workspaces.

Construir una matriz de workspace bindings para una organización con varios entornos y dominios.

Comprender el linaje como mecanismo para visualizar cómo fluyen y se transforman los datos desde origen hasta vistas, dashboards y consumo.

Usar Catalog Explorer para analizar linaje de tablas, vistas, notebooks, jobs, queries y otros activos cuando la plataforma lo captura.

Valorar el linaje como herramienta para análisis de impacto, auditoría, gobierno, depuración y priorización de cambios.

Identificar huecos de linaje cuando existen herramientas externas, scripts fuera de Databricks o procesos no integrados.

Incorporar linaje externo cuando otros sistemas transforman datos fuera de Unity Catalog y se necesita trazabilidad complementaria.

Usar linaje para responder preguntas de impacto: qué dashboards se rompen si cambia una tabla, qué procesos consumen una columna sensible o qué upstream alimenta un informe.

Evitar confiar ciegamente en linaje automático sin validar cobertura, permisos, actualización y sistemas externos.

Documentar ownership y criticidad de objetos apoyándose en relaciones de linaje.

Crear procesos de revisión de impacto antes de modificar tablas, columnas, vistas, eventos o modelos analíticos críticos.

Construir un caso práctico de análisis de impacto usando linaje en un pipeline bronze-silver-gold.

Diseñar auditoría como parte del gobierno operativo, no como actividad reactiva solo cuando hay un incidente.

Identificar eventos relevantes: accesos a datos, cambios de permisos, creación de objetos, modificaciones de ownership y uso de recursos.

Usar logs, system tables, audit logs o mecanismos disponibles para revisar actividad, consultas, cambios y patrones de acceso.

Crear consultas de auditoría para detectar privilegios excesivos, accesos inusuales, objetos sin owner y cambios sensibles.

Definir alertas o revisiones periódicas sobre acciones administrativas, external locations, grants, masks, filters y datos sensibles.

Separar auditoría técnica, auditoría de cumplimiento, auditoría de acceso y auditoría de operación de datos.

Evitar que la auditoría dependa de exportaciones manuales o conocimiento de una única persona.

Documentar evidencias de auditoría para revisiones internas, compliance, seguridad y certificaciones.

Diseñar dashboards de gobierno con KPIs de adopción, objetos gobernados, accesos, excepciones y riesgos pendientes.

Construir un informe de auditoría Unity Catalog sobre un entorno de laboratorio con hallazgos y acciones correctivas.

Usar Catalog Explorer como interfaz de descubrimiento, navegación y gestión de activos gobernados dentro de Unity Catalog.

Documentar tablas, columnas, esquemas, owners, comentarios, tags, sensibilidad, finalidad y consumidores.

Mejorar discoverability para que los usuarios encuentren datos fiables sin crear copias paralelas o pedir accesos informales.

Definir estándares de documentación mínima para publicar un dataset como consumible.

Usar descripciones, tags, lineage y ownership para diferenciar datos raw, curados, certificados, experimentales y obsoletos.

Evitar que Catalog Explorer se convierta en un inventario lleno de objetos sin contexto, nombres ambiguos y owners personales.

Diseñar procesos de revisión para certificar datasets, retirar objetos obsoletos y actualizar documentación.

Incluir criterios de calidad, frescura, SLA, sensibilidad y restricciones de uso en la descripción de activos críticos.

Coordinar data stewards, data owners y equipos técnicos en la mejora continua del catálogo.

Construir una ficha de dataset gobernado con documentación, tags, linaje, owner y permisos correctos.

Comprender Delta Sharing como mecanismo para compartir datos de forma abierta y gobernada con consumidores internos o externos.

Diseñar shares, recipients y providers con criterios de seguridad, auditoría, finalidad, contrato y ciclo de vida.

Diferenciar compartición interna entre workspaces, compartición externa con partners y publicación controlada de productos de datos.

Evitar exportaciones manuales a ficheros cuando un share gobernado puede ofrecer acceso más seguro y trazable.

Definir contratos de compartición con datasets incluidos, campos sensibles, frecuencia de actualización, restricciones y owner.

Revisar permisos, revocación, auditoría y caducidad de acceso para consumidores externos.

Aplicar masking, views o datasets específicos cuando no se debe compartir la tabla base completa.

Coordinar Delta Sharing con políticas legales, DPA, contratos, clasificación de datos y revisiones de seguridad.

Documentar productos de datos compartidos con finalidad, calidad, linaje, sensibilidad y consumidores autorizados.

Construir un caso de compartición segura de datos con un consumidor externo de laboratorio.

Comprender Clean Rooms como entornos de colaboración en los que varias partes pueden trabajar con datos sensibles bajo restricciones de acceso.

Identificar casos de uso: colaboración con partners, medición conjunta, análisis comercial, salud, marketing, fraude o datos restringidos.

Diseñar colaboraciones donde cada parte conserva control sobre sus datos y limita qué consultas, resultados o agregaciones están permitidas.

Evaluar requisitos de privacidad, consentimiento, minimización, agregación, anonimización y revisión legal antes de compartir datos.

Integrar Clean Rooms con Unity Catalog, Delta Sharing, permisos, owners y auditoría cuando el caso lo requiere.

Evitar usar Clean Rooms como atajo para compartir datos sin contrato, clasificación ni revisión de seguridad.

Definir roles: proveedor de datos, colaborador, aprobador, auditor, owner funcional y responsable técnico.

Documentar reglas de colaboración, datasets, consultas permitidas, resultados exportables y procedimiento de cierre.

Revisar riesgos residuales: reidentificación, combinaciones de datos, resultados demasiado detallados y uso fuera de finalidad.

Diseñar un caso práctico de colaboración segura entre dos organizaciones usando datos sintéticos.

Comprender Lakehouse Federation como forma de consultar fuentes externas sin mover necesariamente todos los datos al Lakehouse.

Diseñar connections y foreign catalogs con criterios de seguridad, ownership, finalidad y rendimiento.

Evaluar cuándo federar datos y cuándo ingerirlos físicamente en Delta por calidad, coste, latencia, transformación o gobierno.

Aplicar permisos de Unity Catalog sobre objetos federados para controlar consumo desde Databricks.

Revisar limitaciones de rendimiento, pushdown, compatibilidad SQL, credenciales, auditoría y dependencia del sistema origen.

Evitar que la federación se convierta en acceso indiscriminado a bases productivas sin control de carga ni seguridad.

Documentar sistemas externos conectados, owners, credenciales, tablas expuestas, consumidores y restricciones.

Integrar federación en análisis de linaje, auditoría y catálogo de datos cuando sea necesario.

Diseñar patrones de lectura federada para exploración, reporting limitado, transición o integración temporal.

Construir un caso de foreign catalog de laboratorio con permisos, documentación y consulta gobernada.

Gobernar modelos de machine learning dentro de Unity Catalog como activos con nombre, versiones, permisos, owners y ciclo de vida.

Comprender que Databricks permite gestionar el ciclo de vida de modelos en Unity Catalog para workflows de ML.

Diseñar permisos sobre modelos para entrenamiento, registro, revisión, despliegue, consumo y auditoría.

Relacionar datasets de entrenamiento, features, notebooks, jobs, modelos y endpoints mediante linaje y documentación.

Evitar que modelos se registren sin owner, datos de entrenamiento identificados, propósito, métricas o restricciones de uso.

Aplicar gobierno a features, funciones, volúmenes y artefactos usados por científicos de datos.

Diseñar separación entre experimentación, validación, producción y retirada de modelos.

Controlar acceso a datos sensibles usados en entrenamiento, especialmente cuando hay datos personales o regulados.

Documentar modelo con finalidad, versión, métricas, datasets, sensibilidad, aprobadores y limitaciones.

Construir un flujo de gobierno de modelo ML con datos, permisos, linaje, documentación y transición a producción.

Revisar cómo notebooks, jobs y workflows interactúan con objetos gobernados por Unity Catalog.

Diseñar service principals para ejecución automatizada con permisos mínimos sobre catálogos, esquemas, tablas y external locations.

Evitar que jobs críticos se ejecuten con usuarios personales o permisos excesivos por comodidad.

Controlar acceso a notebooks con credenciales, rutas, secretos, consultas sensibles o lógica de negocio crítica.

Definir permisos para crear, modificar, ejecutar y administrar workflows según rol y entorno.

Validar que un job productivo solo accede a objetos necesarios y no a catálogos completos sin justificación.

Integrar auditoría de ejecuciones, cambios de permisos, owner del job y lineage de salidas generadas.

Gestionar promoción de jobs desde desarrollo a producción con validación de permisos y configuración.

Documentar dependencias de cada workflow: tablas, vistas, volúmenes, credenciales, compute y owners.

Construir un workflow gobernado con service principal, permisos mínimos, tablas de entrada y salida, y auditoría.

Relacionar seguridad de Unity Catalog con compute: clusters, SQL warehouses, serverless, shared access mode y políticas corporativas.

Diseñar políticas de cluster que impidan configuraciones inseguras, librerías no aprobadas o acceso no controlado a datos.

Separar compute de desarrollo, exploración, producción, BI, ML y jobs automatizados según riesgo y necesidad.

Validar que los usuarios no pueden saltarse Unity Catalog accediendo directamente a cloud storage desde compute no gobernado.

Gestionar SQL warehouses para consumidores BI con permisos sobre catálogos, esquemas, vistas y tablas gobernadas.

Controlar librerías, init scripts, variables, secrets y configuraciones que pueden afectar seguridad del entorno.

Documentar qué compute puede acceder a qué datos, desde qué workspace y con qué identidad.

Revisar coste y seguridad conjuntamente, evitando warehouses abiertos o clusters sobredimensionados sin owner.

Aplicar controles distintos a cargas interactivas, automatizadas, productivas y exploratorias.

Diseñar una matriz de compute governance para Databricks con Unity Catalog y políticas de uso.

Clasificar datos personales, confidenciales, financieros, sanitarios, comerciales o estratégicos dentro de Unity Catalog.

Aplicar minimización, control de finalidad, permisos base, ABAC, masks, filters, vistas y auditoría según sensibilidad.

Diseñar procesos para identificar columnas sensibles, aplicar tags y mantenerlos actualizados durante cambios de schema.

Evitar que datos personales se dupliquen en tablas de exploración, exports, volúmenes o notebooks sin control.

Definir restricciones para desarrollo y pruebas con datos anonimizados, seudonimizados o sintéticos.

Revisar access reviews periódicas para confirmar que los usuarios mantienen solo accesos justificados.

Preparar evidencias para cumplimiento: quién accede, a qué, cuándo, bajo qué permiso y con qué finalidad.

Documentar excepciones de acceso a datos sensibles con aprobación, caducidad y revisión.

Coordinar Unity Catalog con DPO, seguridad, legal, data owners y equipos de plataforma.

Diseñar un caso de gobierno de datos personales con tags, ABAC, máscaras, filtros, auditoría y revisión de accesos.

Diseñar Unity Catalog considerando diferencias entre AWS, Azure y Google Cloud en identidad, almacenamiento, red y permisos.

Gestionar S3, ADLS Gen2 o Google Cloud Storage mediante storage credentials y external locations adaptadas a cada cloud.

Revisar roles, managed identities, service accounts, IAM policies, encryption y networking según proveedor.

Evitar aplicar una plantilla de cloud a otra sin revisar equivalencias y limitaciones operativas.

Documentar patrones aprobados por cloud para rutas, buckets, containers, credenciales, claves, redes y acceso privado.

Diseñar gobierno común a nivel lógico aunque la implementación cloud difiera por plataforma.

Gestionar organizaciones híbridas con varios clouds, regiones o cuentas, manteniendo criterios de clasificación y ownership.

Revisar costes, latencia, residencia de datos, soberanía, replicación y accesos externos en decisiones multi-cloud.

Crear una matriz de riesgos y controles por cloud para Unity Catalog y Lakehouse.

Construir un diseño multi-cloud conceptual con objetos Unity Catalog, storage credentials y external locations por proveedor.

Automatizar creación de catálogos, esquemas, permisos, external locations, grants, tags y objetos de gobierno de forma reproducible.

Usar SQL para operaciones de gobierno cuando conviene claridad, revisión y control directo de permisos.

Usar REST APIs y Databricks CLI para integración con procesos corporativos, scripts de administración y validaciones.

Usar Terraform para definir infraestructura y gobierno como código, reduciendo cambios manuales no auditables.

Separar configuración por entorno, dominio y nivel de criticidad, evitando copiar scripts con valores hardcodeados.

Diseñar módulos reutilizables para catálogos, esquemas, grupos, grants, external locations y policies.

Añadir validaciones en CI/CD para detectar privilegios excesivos, objetos sin owner o cambios no aprobados.

Controlar drift entre configuración declarada y estado real de Databricks.

Documentar cambios de gobierno mediante pull requests, revisiones, aprobaciones y plan de rollback.

Construir una automatización completa de Unity Catalog con Terraform y SQL para un dominio de datos de laboratorio.

Diseñar pipelines para promover objetos, permisos, scripts SQL, notebooks, jobs y documentación entre desarrollo, integración y producción.

Separar cambios de estructura, cambios de datos, cambios de permisos, cambios de políticas y cambios de documentación.

Revisar pull requests de gobierno con criterios de seguridad, owner, sensibilidad, linaje, naming y mínimos privilegios.

Automatizar pruebas de permisos con usuarios y grupos sintéticos antes de desplegar cambios en producción.

Validar que nuevas tablas o vistas incluyen owner, descripción, tags, calidad mínima y permisos correctos.

Gestionar rollback de permisos, objetos, policies y automatizaciones cuando un cambio rompe consumo o seguridad.

Integrar Databricks Asset Bundles, Terraform, SQL scripts o herramientas corporativas según el stack del equipo.

Evitar cambios manuales en producción que no queden reflejados en repositorio o sistema de auditoría.

Publicar evidencias de despliegue: objetos creados, grants aplicados, tests ejecutados y diferencias detectadas.

Construir un pipeline de gobierno de Unity Catalog con revisión, validación y promoción controlada.

Aplicar buenas prácticas de organización, external locations, managed storage, permisos por grupo y separación de entornos.

Revisar la recomendación de Databricks de evitar registrar solapamientos de rutas y diseñar external locations con granularidad adecuada.

Evitar catálogos enormes sin estructura funcional, porque dificultan descubrimiento, ownership y revisión de accesos.

Evitar external locations demasiado amplias que dan capacidad de acceso sobre rutas no necesarias.

Evitar conceder privilegios a usuarios individuales cuando el acceso debería gestionarse por grupos.

Evitar service principals con permisos globales para todos los pipelines por comodidad operativa.

Evitar duplicar datasets sensibles en sandboxes, exports, volúmenes o tablas temporales sin controles de gobierno.

Evitar aplicar row filters y masks sin pruebas, documentación, owner y medición de impacto.

Evitar automatizaciones que crean objetos sin comentarios, tags, owners ni revisión de permisos.

Crear una checklist de diseño de Unity Catalog para revisar nuevos dominios, catálogos y data products.

Gestionar solicitudes de acceso con criterios de rol, finalidad, duración, aprobación, grupo y entorno.

Resolver incidencias de permisos diferenciando falta de `USE CATALOG`, `USE SCHEMA`, `SELECT`, ownership, workspace binding o external location.

Diagnosticar errores de acceso a almacenamiento cloud, credenciales, rutas externas, encryption, policies y networking.

Revisar fallos en jobs causados por permisos de service principal, cambios de owner o policies nuevas.

Crear runbooks para errores frecuentes de Unity Catalog, consultas fallidas, objetos no visibles y grants incorrectos.

Analizar incidencias de seguridad: acceso indebido, privilegio excesivo, objeto sensible sin tag o usuario fuera de grupo.

Definir SLAs internos para resolución de accesos, creación de objetos, cambios de permisos y revisión de excepciones.

Mantener comunicación clara con usuarios de datos, explicando por qué un acceso se concede, se deniega o requiere aprobación.

Registrar acciones correctivas y aprendizajes para convertir incidencias repetidas en automatizaciones o reglas.

Construir un manual operativo de soporte Unity Catalog para equipos de plataforma y gobierno.

Definir métricas de adopción: porcentaje de tablas gobernadas, objetos con owner, datasets documentados, tags aplicados y accesos revisados.

Medir calidad del gobierno: privilegios excesivos, usuarios con acceso directo, objetos huérfanos, rutas externas amplias y datos sensibles sin clasificación.

Medir productividad: tiempo de concesión de accesos, tiempo de publicación de datasets, número de solicitudes manuales y automatización disponible.

Medir cumplimiento: auditorías realizadas, excepciones abiertas, accesos caducados, revisiones completadas y evidencias disponibles.

Crear dashboards ejecutivos y técnicos para seguimiento de Unity Catalog y riesgos pendientes.

Establecer niveles de madurez: inicial, controlado, estandarizado, automatizado, auditado y optimizado.

Revisar adopción por dominio, equipo, workspace, entorno, tipo de objeto y sensibilidad del dato.

Usar métricas para priorizar mejoras: ABAC, automatización, documentación, linaje, auditoría o limpieza de permisos.

Evitar métricas de vanidad que solo cuentan objetos creados sin medir calidad ni riesgo.

Construir un modelo de madurez de gobierno Lakehouse con KPIs, objetivos y plan de evolución.

Diseñar un modelo operativo que conecte data owners, data stewards, plataforma, seguridad, compliance, arquitectura y consumidores.

Definir procesos de alta de dominio, creación de catálogo, publicación de dataset, solicitud de acceso y revisión periódica.

Crear un RACI para permisos, ownership, external locations, ABAC, tags, auditoría, automatización y soporte.

Establecer un comité ligero de gobierno para decisiones transversales sin convertir cada cambio en burocracia.

Diseñar flujos de excepción para accesos urgentes, datos sensibles, proyectos regulatorios o investigación controlada.

Integrar gobierno en el ciclo de vida del producto de datos: diseño, desarrollo, validación, publicación, consumo y retirada.

Formar a equipos para que entiendan Unity Catalog como habilitador de autoservicio seguro, no como freno centralizado.

Documentar estándares, plantillas, checklists, ejemplos y anti-patrones para uso común.

Revisar periódicamente políticas según cambios de negocio, regulación, organización, cloud o Databricks.

Construir un operating model de Unity Catalog para una empresa con varios dominios de datos.

Diseñar una arquitectura de gobierno Lakehouse con metastore, workspaces, catálogos, esquemas, owners, grupos y service principals.

Crear catálogos por dominio y entorno con naming, documentación, owners, permisos base y workspace bindings.

Configurar storage credentials, external locations, managed storage, tablas gestionadas, tablas externas y volúmenes de laboratorio.

Aplicar permisos de mínimo privilegio sobre catálogos, esquemas, tablas, vistas, volúmenes, modelos y external locations.

Clasificar datos con tags, sensibilidad, owner, finalidad, dominio y controles asociados.

Implementar row filters, column masks, vistas dinámicas y ABAC para proteger datos sensibles con usuarios de prueba.

Publicar datasets de consumo con documentación, comentarios, linaje, owners, calidad mínima y permisos adecuados.

Crear auditoría y consultas de control para detectar accesos, grants, cambios, objetos sin owner y privilegios excesivos.

Automatizar parte del despliegue con Terraform, SQL, CLI o scripts versionados en repositorio.

Presentar el modelo final con arquitectura, matriz de permisos, controles de seguridad, métricas, runbooks y roadmap de adopción.