Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Associate
Data Intelligence Platform y arquitectura lakehouse
Construye un modelo mental preciso de almacenamiento, cómputo, gobierno y superficies de trabajo.
- Explicar la separación entre storage y compute
- Relacionar Delta Lake, Unity Catalog y motores de ejecución
- Elegir la superficie adecuada para cada carga
01Modelo mentalLake, warehouse y lakehouse sin simplificaciones
Un lakehouse combina la flexibilidad de un data lake con controles y rendimiento propios de un warehouse, manteniendo los datos en formatos abiertos.
+
Lake, warehouse y lakehouse sin simplificaciones
Un lakehouse combina la flexibilidad de un data lake con controles y rendimiento propios de un warehouse, manteniendo los datos en formatos abiertos.
- Objetivo
- Un lakehouse combina la flexibilidad de un data lake con controles y rendimiento propios de un warehouse, manteniendo los datos en formatos abiertos.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- Ninguno obligatorio
La separación entre almacenamiento y cómputo permite conservar una única copia gobernada de los datos y asignar motores distintos a ETL, BI o streaming. El object storage aporta durabilidad y elasticidad; el cómputo se crea, escala y termina según la carga.
Delta Lake añade un registro transaccional sobre archivos Parquet. Así, una tabla puede ofrecer ACID, evolución controlada del esquema e historial sin abandonar un formato accesible por varios motores. El valor no está en juntar productos, sino en reducir copias y fronteras operativas.
Modelo mental
Piensa en un lakehouse como un sistema de tablas confiables construido sobre almacenamiento de objetos, no como una mezcla superficial de data lake y warehouse. El almacenamiento conserva archivos baratos y durables; Delta Lake convierte conjuntos de esos archivos en snapshots transaccionales; Unity Catalog asigna nombres, propietarios y permisos; y distintos recursos de compute leen el mismo estado lógico. Este desacoplamiento evita que la copia física pertenezca a un motor concreto. Para razonar correctamente, separa siempre cuatro preguntas: dónde persisten los bytes, qué protocolo define una tabla válida, quién puede usarla y qué motor ejecuta la consulta. Esa separación explica simultáneamente elasticidad, interoperabilidad, gobierno y recuperación.
Vista inmutable y coherente de los archivos activos de una tabla en una versión concreta del transaction log.
Permite explicar por qué lectores concurrentes ven estados completos y reproducibles.Representación documentada de datos y transacciones que no depende exclusivamente de una aplicación propietaria para interpretarse.
Reduce copias y facilita que distintos motores trabajen sobre una fuente común.Diseño en el que persistencia y capacidad de ejecución tienen ciclos de vida y escalado independientes.
Permite elegir rendimiento, aislamiento y coste por workload sin trasladar los datos.DESCRIBE DETAIL main.learning.events;Comprueba format, location y propiedades antes de asumir cómo está almacenada una tabla.
Puntos clave
- Storage y compute tienen ciclos de vida independientes
- Delta conserva datos y transacciones en formatos abiertos
- Una única capa gobernada sirve a ETL, BI y streaming
Evita
- Describir lakehouse como un simple data lake con SQL
- Duplicar datos por cada motor sin justificar latencia o aislamiento
Recuerdo activo
¿Qué componente conserva el historial ACID de una tabla Delta?
Borrador privado · solo en este navegador02ImplementaciónPlano de control y plano de datos
El plano de control administra configuración y metadatos; el plano de cómputo procesa los datos dentro del perímetro definido para la cuenta.
+
Plano de control y plano de datos
El plano de control administra configuración y metadatos; el plano de cómputo procesa los datos dentro del perímetro definido para la cuenta.
- Objetivo
- El plano de control administra configuración y metadatos; el plano de cómputo procesa los datos dentro del perímetro definido para la cuenta.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- Ninguno obligatorio
El plano de control contiene servicios de interfaz, APIs, configuración y orquestación. El plano de cómputo alberga los recursos que ejecutan Spark o SQL y acceden al almacenamiento mediante las identidades configuradas.
En serverless, Databricks gestiona el plano de cómputo y su red; en compute clásico, la organización controla más elementos de la red y de las instancias. Esta diferencia afecta tiempo de arranque, responsabilidad operativa y controles de conectividad, no la ubicación lógica de las tablas en Unity Catalog.
Modelo mental
Un despliegue Databricks se entiende mejor como dos ámbitos de responsabilidad coordinados. El plano de control mantiene la experiencia del producto: configuración del workspace, APIs, definiciones de Jobs y coordinación de recursos. El plano de cómputo ejecuta instrucciones y accede a datos con una identidad autorizada. Esta división no significa que todo dato de usuario viaje al plano de control ni que el plano de cómputo decida permisos por sí mismo. El modelo mental útil sigue una solicitud: una persona o servicio declara qué ejecutar, el control plane autentica y orquesta, y el compute plane materializa el trabajo cerca de las fuentes gobernadas, sujeto a red e identidad.
Servicios administrados que ofrecen interfaz, APIs, configuración y coordinación de la plataforma.
Ubica correctamente autenticación y orquestación al analizar una arquitectura.Recursos donde drivers y executors procesan datos y materializan resultados.
Concentra las decisiones de red, capacidad e identidad efectiva del workload.Distribución explícita de tareas operativas y de seguridad entre Databricks, el proveedor cloud y el cliente.
Evita asumir que serverless elimina la obligación de gobernar datos, identidades y uso.{
"control_plane": ["workspace config", "jobs orchestration"],
"compute_plane": ["Spark execution", "data access"]
}Úsalo como lista de comprobación al revisar un diagrama de arquitectura.
Puntos clave
- El plano de control no es la ubicación de las tablas
- Serverless reduce la operación de infraestructura
- La conectividad debe diseñarse según el tipo de compute
Evita
- Afirmar que el plano de control ejecuta las transformaciones Spark
- Suponer que classic y serverless comparten idénticas opciones de red
Recuerdo activo
¿Qué cambia principalmente al elegir serverless?
Borrador privado · solo en este navegador03OperaciónObject storage y formatos abiertos
Delta Lake, Unity Catalog y los motores de ejecución resuelven problemas distintos y se complementan en una arquitectura gobernada.
+
Object storage y formatos abiertos
Delta Lake, Unity Catalog y los motores de ejecución resuelven problemas distintos y se complementan en una arquitectura gobernada.
- Objetivo
- Delta Lake, Unity Catalog y los motores de ejecución resuelven problemas distintos y se complementan en una arquitectura gobernada.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- Ninguno obligatorio
Delta Lake define el formato de tabla y las garantías transaccionales. Unity Catalog registra objetos, privilegios, linaje y credenciales. Spark, Photon y los SQL warehouses ejecutan consultas y transformaciones sobre esos objetos.
Una consulta se resuelve primero contra el namespace de Unity Catalog, después se autoriza con la identidad efectiva y finalmente se ejecuta en un recurso de cómputo. Confundir esas capas lleva a conceder permisos en el lugar equivocado o a intentar resolver un problema de layout añadiendo privilegios.
Modelo mental
Delta Lake, Unity Catalog y los motores de ejecución forman capas complementarias con contratos distintos. Delta responde qué archivos componen una versión válida y cómo se confirman cambios. Unity Catalog responde cómo se llama el objeto, quién lo posee, qué principal puede usarlo y de dónde procede. Spark, Photon o un SQL warehouse responden cómo calcular una consulta con recursos concretos. Ninguna capa sustituye a las demás: registrar Parquet en un catálogo no crea transacciones Delta, convertir archivos a Delta no concede SELECT y cambiar de motor no modifica por sí mismo el ownership. El examen suele presentar un síntoma; la habilidad es localizar la capa que tiene autoridad para resolverlo.
Reglas que determinan commits válidos, funcionalidades de lectura y escritura y compatibilidad de clientes.
Distingue una tabla Delta de una simple colección de archivos Parquet.Objeto de Unity Catalog sobre el que pueden evaluarse ownership y privilegios.
Permite aplicar mínimo privilegio al nivel correcto del namespace.Implementación que transforma un plan físico en tareas y operaciones sobre datos.
Explica por qué rendimiento y compatibilidad dependen del compute sin alterar el gobierno lógico.USE CATALOG main;
USE SCHEMA learning;
SELECT count(*) FROM events;El nombre se resuelve en Unity Catalog; la consulta se ejecuta en el compute asociado.
Puntos clave
- Delta es formato y protocolo de tabla
- Unity Catalog es gobierno y descubrimiento
- Spark, Photon y SQL warehouses son superficies de ejecución
Evita
- Tratar Unity Catalog como formato de almacenamiento
- Atribuir a Delta la gestión de usuarios y grupos
Recuerdo activo
¿Dónde se concede SELECT sobre una tabla?
Borrador privado · solo en este navegador04DiagnósticoWorkspace, metastore y recursos de cómputo
Workspace, metastore, catálogo y esquema forman ámbitos distintos; entenderlos evita nombres ambiguos y permisos mal aplicados.
+
Workspace, metastore y recursos de cómputo
Workspace, metastore, catálogo y esquema forman ámbitos distintos; entenderlos evita nombres ambiguos y permisos mal aplicados.
- Objetivo
- Workspace, metastore, catálogo y esquema forman ámbitos distintos; entenderlos evita nombres ambiguos y permisos mal aplicados.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- Ninguno obligatorio
Un workspace es la superficie de colaboración y ejecución. Un metastore de Unity Catalog gobierna catálogos y se asigna a workspaces; el namespace de tres niveles catalog.schema.object identifica tablas, vistas, funciones y volúmenes.
El workspace no es el propietario físico de una tabla de Unity Catalog. Varios workspaces asociados al mismo metastore pueden descubrir un objeto, aunque workspace bindings, privilegios y conectividad pueden limitar su uso.
Modelo mental
El namespace de Unity Catalog es una jerarquía de gobierno, mientras un workspace es una superficie de colaboración y ejecución. Un metastore se asigna a workspaces y contiene catálogos; cada catálogo contiene esquemas; cada esquema contiene tablas, vistas, volúmenes, funciones y otros objetos. El nombre completo catalog.schema.object hace que el significado no dependa del contexto accidental de la sesión. La asignación del metastore habilita un ámbito común, pero no concede acceso automáticamente: visibilidad, privilegios, workspace bindings y conectividad siguen siendo controles diferentes. Pensar en contenedores anidados evita la falsa idea de que copiar un notebook o cambiar de workspace duplica o transfiere la propiedad de una tabla.
Ámbito superior de Unity Catalog asignable a uno o varios workspaces y contenedor de catálogos.
Define la frontera administrativa en la que se resuelven objetos gobernados.Identificación inequívoca de un objeto mediante catálogo, esquema y nombre.
Hace reproducibles consultas y despliegues entre sesiones y entornos.Restricción que limita el uso de determinados securables a workspaces seleccionados.
Añade aislamiento de entorno sin confundirlo con permisos de usuario sobre datos.SHOW CATALOGS;
SHOW SCHEMAS IN main;
SHOW TABLES IN main.learning;Ejecuta las tres sentencias para localizar en qué nivel falla el descubrimiento.
Puntos clave
- El namespace recomendado tiene tres niveles
- El metastore se asigna a uno o varios workspaces
- Visibilidad y autorización no son equivalentes
Evita
- Usar nombres de una parte y depender del contexto de sesión
- Confundir ACL del workspace con privilegios sobre datos
Recuerdo activo
¿Cuál es el nombre completo de la tabla events?
Borrador privado · solo en este navegador05Decisión de diseñoArquitectura de referencia de extremo a extremo
La superficie correcta depende de latencia, lenguaje, concurrencia y ciclo de vida, no de una preferencia universal.
+
Arquitectura de referencia de extremo a extremo
La superficie correcta depende de latencia, lenguaje, concurrencia y ciclo de vida, no de una preferencia universal.
- Objetivo
- La superficie correcta depende de latencia, lenguaje, concurrencia y ciclo de vida, no de una preferencia universal.
- Duración estimada
- 17 min aprox.
- Dificultad
- Associate
- Prerrequisitos
- Ninguno obligatorio
Los notebooks favorecen exploración y desarrollo interactivo; Lakeflow Jobs ejecuta tareas productivas con dependencias; SQL warehouses atienden SQL y BI concurrente; Spark Declarative Pipelines en Lakeflow gestiona grafos incrementales declarativos.
Antes de seleccionar una superficie, fija SLA, patrón de ejecución, identidad, necesidad de estado y consumidores. Una transformación PySpark exploratoria puede empezar en notebook y terminar empaquetada como tarea de Job sin cambiar la tabla gobernada que produce.
Modelo mental
Elegir una superficie Databricks es emparejar el ciclo de vida del trabajo con un servicio, no decidir qué icono resulta más familiar. Un notebook favorece conversación interactiva y exploración; Lakeflow Jobs convierte tareas en ejecuciones repetibles; un SQL warehouse atiende SQL concurrente y herramientas BI; Spark Declarative Pipelines en Lakeflow expresa datasets y dependencias de forma declarativa. Antes de elegir, fija consumidor, lenguaje, latencia, frecuencia, estado, concurrencia, identidad y recuperación. El mismo cálculo puede prototiparse en notebook y desplegarse como tarea, pero la superficie productiva debe ofrecer contrato de entrada, observabilidad y reintento. Esta matriz evita usar clusters interactivos permanentes como solución universal.
Servicio o entorno desde el que se desarrolla, programa o sirve un workload.
Conecta requisitos operativos con capacidades concretas de Databricks.Secuencia de creación, actividad, escalado, recuperación y terminación de una ejecución.
Determina coste, estado residual y mecanismos de operación necesarios.Definición del resultado deseado y sus dependencias sin programar manualmente todo el orden de ejecución.
Permite que Lakeflow Pipelines gestione planificación y estado incremental.surface = {
"interactive_pyspark": "notebook",
"scheduled_etl": "lakeflow_job",
"concurrent_bi": "sql_warehouse",
"declarative_incremental": "lakeflow_pipeline",
}Añade SLA y restricciones de red antes de convertir la matriz en una decisión de arquitectura.
Puntos clave
- Notebook no equivale a despliegue productivo
- SQL warehouse prioriza cargas SQL y concurrencia
- Jobs y pipelines automatizan ciclos de ejecución distintos
Evita
- Ejecutar producción manualmente desde un notebook
- Usar un cluster interactivo permanente para consultas BI esporádicas
Recuerdo activo