Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 01 · Associate

Plataforma

Contenido abierto

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.

Lectura pública
Al terminar podrás
  • 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
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Associate
Ruta relacionada
core
Dominios blueprint
Databricks Intelligence Platform · Arquitectura
Estado
Revisión editorial interna
Fuentes principales
Data engineering with Databricks · Arquitectura lakehouse
Reportar un error
01
Modelo mental

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
Reportar un error en esta lección

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.

Snapshot

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.
Formato abierto

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.
Separación storage-compute

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.
SQLInspeccionar una tabla Delta
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 navegador
02
Implementación

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
Reportar un error en esta lección

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.

Control plane

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.
Compute plane

Recursos donde drivers y executors procesan datos y materializan resultados.

Concentra las decisiones de red, capacidad e identidad efectiva del workload.
Responsabilidad compartida

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.
JSONSeparar responsabilidades
{
  "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 navegador
03
Operación

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
Reportar un error en esta lección

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.

Protocolo de tabla

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.
Securable

Objeto de Unity Catalog sobre el que pueden evaluarse ownership y privilegios.

Permite aplicar mínimo privilegio al nivel correcto del namespace.
Motor de ejecución

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.
SQLResolver un objeto gobernado
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 navegador
04
Diagnóstico

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
Reportar un error en esta lección

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.

Metastore

Á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.
Namespace de tres niveles

Identificación inequívoca de un objeto mediante catálogo, esquema y nombre.

Hace reproducibles consultas y despliegues entre sesiones y entornos.
Workspace binding

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.
SQLExplorar el namespace
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 navegador
05
Decisión de diseño

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
Reportar un error en esta lección

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.

Superficie de ejecución

Servicio o entorno desde el que se desarrolla, programa o sirve un workload.

Conecta requisitos operativos con capacidades concretas de Databricks.
Ciclo de vida

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.
Carga declarativa

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.
PythonMatriz mínima de decisión
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

¿Qué superficie escogerías para un dashboard SQL con muchos usuarios?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Learn Databricks

Learn Databricks · commit 08c378c

README.md