Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
All-purpose, jobs compute y SQL warehouses
All-purpose, jobs compute y SQL warehouses responden a ciclos de trabajo y consumidores diferentes.
- Duración
- 17 min aprox.
- Objetivo
- All-purpose, jobs compute y SQL warehouses responden a ciclos de trabajo y consumidores diferentes.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute clásico, serverless y SQL warehouses
Selecciona recursos por patrón de carga, aislamiento, latencia, gobernanza y coste total.
- Comparar serverless, classic y SQL warehouses
- Dimensionar sin sobredimensionar
- Aplicar auto-stop, políticas y modos de rendimiento
02ImplementaciónAll-purpose, jobs compute y SQL warehouses
All-purpose, jobs compute y SQL warehouses responden a ciclos de trabajo y consumidores diferentes.
+
All-purpose, jobs compute y SQL warehouses
All-purpose, jobs compute y SQL warehouses responden a ciclos de trabajo y consumidores diferentes.
All-purpose compute favorece desarrollo interactivo compartido. Jobs compute se crea para ejecuciones automatizadas y puede aislar dependencias por tarea o job. Un SQL warehouse ofrece un endpoint SQL para consultas, dashboards y herramientas BI.
Para producción repetible, jobs compute o serverless Jobs evita depender del estado de una sesión interactiva. Para BI, el SQL warehouse proporciona controles de escalado y concurrencia que no deben simularse con un notebook conectado permanentemente.
Modelo mental
All-purpose compute, jobs compute y SQL warehouses se distinguen por quién los usa y cuánto estado deben conservar. All-purpose acompaña una sesión humana interactiva y admite iteración; jobs compute acompaña un run automatizado y favorece un entorno reproducible; un SQL warehouse es un endpoint SQL optimizado para consultas, dashboards y herramientas BI concurrentes. No son tres tamaños del mismo cluster. Asignar producción a un recurso interactivo introduce estado residual, permisos personales y costes de inactividad. Servir BI desde un cluster de desarrollo mezcla colas y ciclos de escalado incompatibles. El modelo adecuado vincula cada recurso a una intención operativa y hace que el dato persista fuera de él.
Compute clásico orientado al trabajo interactivo de usuarios en notebooks y exploración.
Explica por qué no es la opción recomendada para Jobs productivos repetibles.Compute asociado a ejecuciones automatizadas y definido para las tareas de un workflow.
Reduce estado residual y vincula coste, logs y dependencias al run.Recurso de cómputo especializado que expone un endpoint SQL para analítica y BI.
Aporta aislamiento, concurrencia y ciclo de auto-stop acordes al consumo SQL.def compute_for(kind: str) -> str:
return {
"exploration": "all-purpose",
"scheduled_etl": "jobs compute",
"bi_sql": "sql warehouse",
}[kind]
Añade requisitos de serverless y aislamiento en una decisión real.
Puntos clave
- All-purpose es interactivo
- Jobs compute acompaña ejecuciones automatizadas
- SQL warehouse sirve SQL y BI
Evita
- Programar un notebook de producción sobre un cluster personal
- Conectar una herramienta BI al compute de desarrollo
Recuerdo activo