Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu 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.
- Duración
- 17 min aprox.
- Objetivo
- La superficie correcta depende de latencia, lenguaje, concurrencia y ciclo de vida, no de una preferencia universal.
- Siguiente paso
- Continuar con el laboratorio
Ver detalles del módulo
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
05Decisió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.
Mostrar prerrequisitos
- 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