Saltar al contenido

Plataforma

Menú

Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.

Guardar progreso

Lección 5 de 5

Arquitectura de referencia de extremo a extremo

La superficie correcta depende de latencia, lenguaje, concurrencia y ciclo de vida, no de una preferencia universal.

17 min aprox.

Detalles

Data Intelligence Platform y arquitectura lakehouse

Construye un modelo mental preciso de almacenamiento, cómputo, gobierno y superficies de trabajo.

Reto observable

Ante un caso de negocio, dibuja una arquitectura lakehouse que separe almacenamiento, cómputo y gobierno, y justifica cada superficie con una decisión verificable.

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
Prerrequisitos
Ninguno obligatorio
Última revisión
25 ago 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
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.

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.

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.

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

Profundiza

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

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

Vista de lectura · sin ejecución

Learn Databricks

Learn Databricks · commit 08c378c

README.md

Módulo 01

Contenido del módulo