Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
Tags y chargeback
Equilibra coste y latencia en serverless mediante modos de rendimiento, entornos versionados y límites de microbatch.
17 min aprox.
03OperaciónTags y chargeback
Equilibra coste y latencia en serverless mediante modos de rendimiento, entornos versionados y límites de microbatch.
+
Tags y chargeback
Equilibra coste y latencia en serverless mediante modos de rendimiento, entornos versionados y límites de microbatch.
Serverless jobs y pipelines ofrecen modo performance optimized para arranque rápido y modo standard para automatizaciones que toleran aproximadamente 4–6 minutos de inicio a cambio de menor coste. Los notebooks usan el modo interactivo adecuado. Serverless administra infraestructura y Photon, pero el ingeniero sigue controlando la forma de la consulta, paquetes, parámetros y cuánto dato procesa cada ejecución.
Los entornos serverless sustituyen la selección directa de Databricks Runtime y mantienen una API base estable. Fija versiones de paquetes y usa entornos/base environments, porque init scripts no están soportados. En streaming serverless, `Trigger.AvailableNow` procesa lo disponible; limita `maxFilesPerTrigger` o `maxBytesPerTrigger` para evitar microbatches impredecibles.
# requirements.txt
pydantic==2.11.7
requests==2.32.4
tenacity==9.1.2
# En el job, selecciona un entorno compatible y conserva
# este fichero versionado junto al código y sus pruebas.No dependas de una versión transitiva no fijada; valida el entorno en test antes de promoverlo.
¿Qué compensación introduce el modo standard de serverless jobs?
Profundiza
Serverless mueve el control desde nodos individuales hacia objetivos de servicio. El ingeniero ya no elige cada instancia ni un init script arbitrario; expresa el tipo de workload, sus dependencias compatibles, paralelismo y límites, y evalúa latencia, coste y estabilidad como propiedades observadas. Los modos de rendimiento intercambian rapidez de provisión y respuesta por consumo, mientras los entornos versionados reducen variación de runtime. En streaming, el tamaño de microbatch conecta dos mundos: lotes grandes aprovechan throughput pero elevan latencia y estado temporal; lotes pequeños reaccionan antes pero pagan más overhead. La ausencia de clúster visible no elimina decisiones de diseño, sólo cambia las palancas permitidas.
Conjunto versionado de runtime y dependencias compatibles usado por el compute administrado.
Aporta reproducibilidad sin control de imagen completa y obliga a declarar dependencias de forma soportada.Trabajo disponible que aún no ha sido procesado por el servicio.
Guía escalado y muestra si el throughput sostenido alcanza la tasa de entrada.Restricción de datos procesados en cada disparo de un stream.
Equilibra latencia, throughput, estado, coste y capacidad de recuperación tras una interrupción.Resumen
Puntos clave
- Usa modo standard cuando el SLA admite más arranque y prima el coste.
- Fija versiones de paquetes dentro del modelo de entorno serverless.
- La infraestructura gestionada no elimina la necesidad de acotar cada workload.
Evita
- Elegir performance optimized para miles de jobs batch cuyo SLA tolera el arranque standard.
- Copiar init scripts de compute clásico a una migración serverless.