Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Associate + Professional
Unity Catalog, Git folders y CI/CD esencial
Une gobierno de datos con una entrega de código revisable y promocionable entre entornos.
- Aplicar el namespace y mínimo privilegio
- Diferenciar managed, external, volumes y credentials
- Promover el mismo código con variables por entorno
01Modelo mentalMetastore, catalog, schema y object
Unity Catalog gobierna objetos mediante jerarquía, ownership y herencia.
+
Metastore, catalog, schema y object
Unity Catalog gobierna objetos mediante jerarquía, ownership y herencia.
- Objetivo
- Unity Catalog gobierna objetos mediante jerarquía, ownership y herencia.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m10
Catalog contiene schemas; schemas contienen tablas, vistas, volúmenes y funciones.
Managed prioriza gestión Databricks; external conserva ciclo de vida cloud mediante credential y external location.
Modelo mental
Unity Catalog modela gobierno mediante una jerarquía de securables, ownership y privilegios heredables. El metastore contiene catálogos; los catálogos contienen esquemas; los esquemas agrupan tablas, vistas, volúmenes, funciones y modelos. Resolver catalog.schema.object identifica el recurso sin depender del contexto. El owner puede administrar el objeto y delegar, pero los usuarios ordinarios deben recibir capacidades concretas a través de grupos o service principals. Managed y external cambian el ciclo de vida del almacenamiento, no la existencia de gobierno. La jerarquía permite conceder a un nivel amplio cuando la política es realmente común o al objeto cuando se necesita aislamiento; facilidad no debe convertirse en ALL PRIVILEGES generalizado.
Objeto de Unity Catalog sobre el que se pueden conceder privilegios, establecer ownership y aplicar determinadas restricciones.
Proporciona la unidad concreta para diseñar y auditar mínimo privilegio dentro de la plataforma.Autoridad administrativa sobre un securable que permite modificarlo, conceder acceso y transferir su propiedad bajo reglas aplicables.
Debe asignarse a roles estables porque supera la simple capacidad de leer o escribir datos.Propagación de privilegios concedidos en un contenedor hacia objetos descendientes según la jerarquía de Unity Catalog.
Simplifica políticas por dominio, pero amplía alcance y exige revisar la concesión efectiva completa.CREATE SCHEMA IF NOT EXISTS main.sales;
CREATE TABLE main.sales.orders (id BIGINT) USING DELTA;Concede privilegios al grupo, no a individuos.
Puntos clave
- Tres niveles
- Ownership permite administrar
- Managed recomendado
Evita
- Nombres de una parte
- Credenciales a usuarios finales
Recuerdo activo
¿Qué contiene un schema?
Borrador privado · solo en este navegador02ImplementaciónPrivilegios, herencia y service principals
GRANT, REVOKE y DENY aplican mínimo privilegio a principals de cuenta.
+
Privilegios, herencia y service principals
GRANT, REVOKE y DENY aplican mínimo privilegio a principals de cuenta.
- Objetivo
- GRANT, REVOKE y DENY aplican mínimo privilegio a principals de cuenta.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m10
USE CATALOG y USE SCHEMA permiten recorrer namespace; SELECT autoriza lectura del objeto.
Concede a grupos o service principals y aprovecha herencia; DENY explícito prevalece donde esté soportado.
Modelo mental
GRANT añade una concesión; REVOKE retira una concesión concreta; DENY, donde esté soportado, establece una prohibición explícita que debe entenderse frente a herencia. Leer una tabla de tres niveles requiere poder recorrer catálogo y esquema mediante USE y disponer de SELECT efectivo sobre el objeto o un ancestro heredable. USE no permite leer filas y SELECT sin acceso a ancestros no basta para resolver el nombre. Las concesiones se asignan preferentemente a grupos y service principals, no individuo por individuo. El análisis de acceso calcula permisos efectivos desde todas las pertenencias y niveles: retirar un GRANT directo puede no cambiar nada si el mismo permiso llega heredado.
Operación que concede a un principal un privilegio específico sobre un securable determinado de Unity Catalog.
Es la base positiva del modelo de autorización y debe limitarse a la capacidad realmente necesaria.Operación que retira una concesión concreta sin eliminar otros caminos heredados o grupales que otorguen el mismo privilegio.
Explica por qué un usuario puede conservar acceso después de retirar únicamente su grant directo.Resultado agregado de ownership, grants directos, pertenencia a grupos, herencia y prohibiciones aplicables para una identidad.
Es el valor que debe comprobarse al diagnosticar acceso, no una sola sentencia aislada.GRANT USE CATALOG ON CATALOG main TO `analysts`;
GRANT USE SCHEMA ON SCHEMA main.gold TO `analysts`;
GRANT SELECT ON TABLE main.gold.daily_sales TO `analysts`;REVOKE retira una concesión; revisa herencia antes de asumir pérdida efectiva.
Puntos clave
- Principals son de cuenta
- USE no concede SELECT
- Grupos simplifican
Evita
- GRANT a cada persona
- SELECT sin USE ancestors
Recuerdo activo
¿USE SCHEMA permite leer tablas?
Borrador privado · solo en este navegador03OperaciónExternal locations, volumes y storage credentials
Lineage, audit logs y ABAC aportan trazabilidad y políticas centralizadas.
+
External locations, volumes y storage credentials
Lineage, audit logs y ABAC aportan trazabilidad y políticas centralizadas.
- Objetivo
- Lineage, audit logs y ABAC aportan trazabilidad y políticas centralizadas.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m10
Lineage registra relaciones entre objetos; system.access.audit registra acciones según disponibilidad.
ABAC usa governed tags y policies para máscaras y filtros a escala; una máscara directa encaja en casos aislados.
Modelo mental
Lineage responde de dónde proviene un objeto y qué consumidores dependen de él; audit logs responden quién realizó una acción, cuándo y desde qué contexto; ABAC aplica políticas mediante atributos y governed tags. Son controles relacionados pero no intercambiables. Lineage no demuestra que un usuario leyó una fila concreta, y audit no explica por sí solo la transformación semántica entre tablas. Una column mask o row filter directa sirve a un caso acotado; ABAC escala cuando la misma clasificación, como PII o región, debe gobernar muchos objetos. La política se diseña con tags controlados, funciones seguras y excepciones mínimas, y se prueba con identidades representativas.
Metadatos que relacionan objetos y columnas de entrada con resultados producidos por operaciones capturadas por la plataforma.
Permite análisis de impacto, descubrimiento de dependencias y explicación técnica del origen de una métrica.Registro temporal de acciones realizadas por principals sobre servicios y objetos, con contexto disponible de la solicitud.
Sustenta investigación de quién hizo qué, pero no reemplaza la semántica de transformación del lineage.Control de acceso basado en atributos que aplica políticas centralizadas usando governed tags y funciones de filtrado o máscara.
Escala protección coherente por clasificación sin configurar manualmente cada columna sensible de cada tabla.ALTER TABLE main.gold.customers ALTER COLUMN email SET MASK main.security.email_mask;Para muchas tablas sensibles, evalúa política ABAC con governed tags.
Puntos clave
- Lineage muestra dependencias
- Audit muestra acciones
- ABAC aplica por atributos
Evita
- Confundir lineage con auditoría
- UDF de máscara con acceso excesivo
Recuerdo activo
¿Qué diferencia audit y lineage?
Borrador privado · solo en este navegador04DiagnósticoGit folders y flujo de ramas
Git folders permiten ramas, commits y pull requests desde el workspace.
+
Git folders y flujo de ramas
Git folders permiten ramas, commits y pull requests desde el workspace.
- Objetivo
- Git folders permiten ramas, commits y pull requests desde el workspace.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m10
Sincronizan código con Git para colaboración y revisión.
No almacenan tablas ni sustituyen CI; conflictos se resuelven como en un repositorio normal.
Modelo mental
Git folders ofrece una copia de trabajo del repositorio dentro del workspace para ramas, commits, pulls y pushes. Git sigue siendo la fuente de verdad del código; el proveedor aloja pull requests, reglas de revisión y protección de ramas. Una rama representa una línea de cambios, no un ambiente de datos. Los notebooks y archivos se versionan, pero tablas, checkpoints, secretos y resultados de ejecución pertenecen a otras superficies. El flujo profesional crea una rama corta, modifica código y tests, sincroniza, abre pull request y deja que CI valide. Copiar carpetas como final_v2 evita conflictos momentáneamente, pero destruye historial común y hace imposible saber qué versión llegó a producción.
Directorio del workspace conectado a un repositorio remoto que permite trabajar con ramas y sincronizar archivos versionados.
Acerca desarrollo al compute sin convertir el workspace en sustituto del historial y gobierno del proveedor Git.Propuesta revisable para integrar commits de una rama, acompañada de diff, checks automáticos y decisiones humanas.
Introduce una frontera de calidad y seguridad antes de que el cambio alcance la rama protegida.Situación en la que Git no puede decidir automáticamente cómo combinar cambios concurrentes sobre contenido relacionado.
Debe resolverse entendiendo la intención; elegir siempre una versión puede borrar lógica o pruebas válidas.git checkout -b feature/orders-quality
git add src tests
git commit -m 'Add order quality checks'
git push -u origin feature/orders-qualityLa creación del PR ocurre en el proveedor Git.
Puntos clave
- Código versionado
- Ramas aíslan cambios
- PR revisa
Evita
- Commit de secretos
- Edición directa en main
Recuerdo activo
¿Dónde se aprueba un PR?
Borrador privado · solo en este navegador05Decisión de diseñoBundles, targets y variables por entorno
Declarative Automation Bundles empaqueta recursos y promueve el mismo código por targets.
+
Bundles, targets y variables por entorno
Declarative Automation Bundles empaqueta recursos y promueve el mismo código por targets.
- Objetivo
- Declarative Automation Bundles empaqueta recursos y promueve el mismo código por targets.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate + Professional
- Prerrequisitos
- m10
databricks.yml define bundle, includes, variables, artifacts, resources y targets.
validate comprueba configuración, deploy aplica recursos y run ejecuta; dev/test/prod cambian variables e identidad, no lógica.
Modelo mental
Declarative Automation Bundles, nombre actual de la capacidad antes conocida como Databricks Asset Bundles, describe recursos, artefactos, variables y targets como código. databricks.yml es la raíz; include separa definiciones; targets aplican overrides de ambiente; artifacts construye unidades como wheels; resources declara Jobs y pipelines. validate comprueba configuración, deploy crea o actualiza recursos y run ejecuta un recurso desplegado. El principio esencial es construir y probar una vez, luego promocionar el mismo commit o artefacto cambiando catálogo, identidad y parámetros por target. Duplicar código para dev y prod impide demostrar equivalencia. La identidad run_as productiva debe ser estable y mínima, nunca el usuario que lanzó el despliegue por casualidad.
Configuración nombrada que aplica valores y overrides específicos de un ambiente sobre una definición común de recursos.
Permite separar catálogo, workspace e identidad sin mantener copias divergentes del código productivo.Identidad estable bajo la que se ejecutan recursos desplegados, independiente de quien invoca el despliegue cuando se configura.
Evita que producción dependa de permisos personales y facilita aplicar mínimo privilegio a cada workload.Comando que resuelve y comprueba la configuración del bundle para un target antes de aplicar cambios remotos.
Detecta referencias y estructura inválidas temprano, aunque debe complementarse con tests de lógica e integración.bundle: {name: orders}
variables: {catalog: {default: dev}}
targets:
dev: {default: true}
prod:
variables: {catalog: prod}Añade resources e identidad run_as para producción.
Puntos clave
- Mismo artefacto
- Targets configuran
- CLI automatiza
Evita
- Código duplicado por target
- Deploy prod con identidad personal
Recuerdo activo