Saltar al contenido

Compute

Menú

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

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

17 min aprox.

Detalles

Compute clásico, serverless y SQL warehouses

Selecciona recursos por patrón de carga, aislamiento, latencia, gobernanza y coste total.

Reto observable

Para tres workloads con SLA y presupuesto, selecciona y dimensiona compute, y entrega una matriz comparativa con latencia, aislamiento y coste esperados.

Al terminar podrás
  • Comparar serverless, classic y SQL warehouses
  • Dimensionar sin sobredimensionar
  • Aplicar auto-stop, políticas y modos de rendimiento
Prerrequisitos
m01
Última revisión
25 ago 2026
Nivel
Associate
Ruta relacionada
core
Dominios blueprint
Compute services · Cost models
Estado
Revisión editorial interna
Fuentes principales
Compute · Serverless compute
Reportar un error
02
Implementación

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.

PythonSelección por carga
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.

¿Por qué preferir jobs compute para ETL programado?

Profundiza

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.

All-purpose compute

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.
Jobs compute

Compute asociado a ejecuciones automatizadas y definido para las tareas de un workflow.

Reduce estado residual y vincula coste, logs y dependencias al run.
SQL warehouse

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

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

Fuente revisada · vista externa

Azure Databricks Hands-on

Azure Databricks Hands-on · commit a91650b

HandsOn.dbc

Archivo importable

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
Tsuyoshi Matsuzaki
Licencia
No verificada
Formato
dbc
Abrir / descargar .dbc

Módulo 02

Contenido del módulo