Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 2 de 5
system.billing.usage
Dimensiona compute clásico con el cuello de botella real: memoria por partición, CPU, I/O, paralelismo y capacidad del driver.
- Duración
- 17 min aprox.
- Objetivo
- Dimensiona compute clásico con el cuello de botella real: memoria por partición, CPU, I/O, paralelismo y capacidad del driver.
- 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
02Implementaciónsystem.billing.usage
Dimensiona compute clásico con el cuello de botella real: memoria por partición, CPU, I/O, paralelismo y capacidad del driver.
+
system.billing.usage
Dimensiona compute clásico con el cuello de botella real: memoria por partición, CPU, I/O, paralelismo y capacidad del driver.
Más nodos pequeños y pocos nodos grandes pueden sumar cores y memoria similares, pero no se comportan igual. Joins y agregaciones con particiones grandes necesitan memoria por executor; workloads muy paralelos pueden aprovechar más workers. El driver planifica, recopila metadatos y recibe resultados de acciones como `collect()`, por lo que escalar workers no resuelve un driver sobrecargado.
Comienza con una familia general, autoscaling y límites observables. Revisa utilización de CPU, memoria, spill, I/O y duración por stage; cambia una variable cada vez. En AWS, Azure y GCP varían nombres, discos y mercados spot, pero el método es el mismo. Mantén el driver bajo demanda y usa spot/preemptible en workers sólo si el workload tolera interrupciones.
Modelo mental
Dimensionar compute clásico es equilibrar un sistema distribuido con dos escalas distintas: recursos por tarea y número de tareas simultáneas. La memoria que necesita una partición determina si cada executor puede completar su operador; el número de cores y executors determina cuánto paralelismo se materializa. El driver tiene otra función: planifica, coordina, recopila metadatos y puede colapsar aunque los workers estén ociosos si el código hace collect o crea un plan enorme. Una máquina mayor no sustituye un buen particionado, y más workers no arreglan una tarea indivisible. Se mide primero el cuello de botella con CPU, I/O, spill, GC, distribución de tareas y presión del driver.
Aumento del número de workers o executors para disponer de más slots y throughput agregado.
Sólo acelera si el plan ofrece paralelismo y la etapa no depende de una tarea caliente o secuencial.Uso de nodos con más CPU o memoria por proceso de ejecución.
Puede hacer caber particiones grandes, pero aumenta coste unitario y no corrige distribución deficiente.Carga de planificación, metadatos o resultados que consume memoria y CPU del proceso coordinador.
Un driver puede fallar aunque los executors tengan recursos; collect y planes enormes son señales distintas.{
"spark_version": "16.4.x-scala2.12",
"runtime_engine": "PHOTON",
"autoscale": {
"min_workers": 2,
"max_workers": 8
},
"autotermination_minutes": 20,
"custom_tags": {
"cost_center": "finance-data",
"environment": "prod"
}
}Los node types son deliberadamente externos al ejemplo porque cambian por nube; selecciónalos después de perfilar CPU, memoria y disco.
Puntos clave
- Dimensiona por recursos de la etapa crítica, no por volumen total de la tabla.
- El driver y los workers tienen responsabilidades distintas.
- Autoscaling no arregla skew ni un único task no paralelizable.
Evita
- Elevar `max_workers` cuando una sola tarea sesgada domina la duración.
- Usar spot/preemptible para el driver y exponer el job completo a una reclamación.
Recuerdo activo