Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 3 de 5
Tags y chargeback
Equilibra coste y latencia en serverless mediante modos de rendimiento, entornos versionados y límites de microbatch.
- Duración
- 17 min aprox.
- Objetivo
- Equilibra coste y latencia en serverless mediante modos de rendimiento, entornos versionados y límites de microbatch.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute, políticas, etiquetas y costes
Atribuye consumo, controla guardrails y optimiza coste sin degradar el valor del workload.
- Consultar costes con system tables
- Etiquetar y atribuir consumo
- Elegir modos serverless y políticas
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.
Modelo mental
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.# 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.
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.
Recuerdo activo