Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 5 de 5
Standard frente a performance optimized
Construye FinOps con cantidades de uso, precios efectivos, correcciones y metadatos de workload, no con estimaciones de horas de clúster.
- Duración
- 17 min aprox.
- Objetivo
- Construye FinOps con cantidades de uso, precios efectivos, correcciones y metadatos de workload, no con estimaciones de horas de clúster.
- Siguiente paso
- Continuar con el laboratorio
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
05Decisión de diseñoStandard frente a performance optimized
Construye FinOps con cantidades de uso, precios efectivos, correcciones y metadatos de workload, no con estimaciones de horas de clúster.
+
Standard frente a performance optimized
Construye FinOps con cantidades de uso, precios efectivos, correcciones y metadatos de workload, no con estimaciones de horas de clúster.
`system.billing.usage` ofrece registros regionales de consumo con SKU, producto origen, metadatos de job/notebook/warehouse, identidad y tags. Para coste monetario se une con la tabla de precios por SKU y vigencia; las correcciones pueden emitir retracciones y restatements, así que agrega `usage_quantity` con su signo en lugar de descartar filas negativas.
Un dashboard útil separa coste, volumen y resultado: coste por ejecución, por millón de filas o por SLA cumplido. Segmenta serverless por `billing_origin_product` y `usage_metadata`, porque varias capacidades comparten SKU. Define presupuestos y alertas como detección temprana, no como mecanismo que detiene automáticamente todos los workloads.
Modelo mental
FinOps no intenta minimizar cada factura aislada; optimiza el coste de entregar valor con fiabilidad. En Databricks, los registros de uso son hechos temporales que deben unirse con precios efectivos, metadatos de identidad y recursos, y resultados del workload. Las horas de clúster son una aproximación pobre para serverless, autoscaling, tarifas cambiantes o correcciones. system.billing.usage incluye cantidades y metadatos, pero un registro puede ser una retracción o corrección y no todo consumo se atribuye igual. La unidad útil es coste por pipeline exitoso, tabla publicada, terabyte procesado o consulta con SLA. Esa normalización separa crecimiento sano del derroche y evita premiar jobs baratos que fallan.
Entrada de facturación que retracta o ajusta una cantidad publicada previamente.
Debe netearse correctamente para no duplicar uso ni mostrar ahorros ficticios.Importe dividido por una unidad de valor o trabajo comparable.
Distingue aumento de gasto por crecimiento de una regresión de eficiencia.Porcentaje del coste asignado de forma trazable a propietario, producto o workload.
Expone cuánto del dashboard es accionable y cuánto permanece compartido o desconocido.SELECT
usage_date,
billing_origin_product,
custom_tags['cost_center'] AS cost_center,
sku_name,
SUM(usage_quantity) AS usage_quantity
FROM system.billing.usage
WHERE usage_date >= current_date() - INTERVAL 30 DAYS
GROUP BY usage_date, billing_origin_product,
custom_tags['cost_center'], sku_name
ORDER BY usage_date DESC, usage_quantity DESC;Para moneda, une con `system.billing.list_prices` respetando SKU y periodo; este ejemplo evita fingir que DBU equivale directamente a coste.
Puntos clave
- Suma registros de corrección con signo para obtener consumo neto.
- Une uso y precios por SKU y periodo de vigencia.
- Normaliza coste por unidad de negocio o trabajo terminado.
Evita
- Multiplicar todas las DBU por un único precio sin considerar SKU ni vigencia contractual.
- Ignorar correcciones negativas y sobreestimar consumo histórico.
Recuerdo activo