Kosten en computekeuzes

Compute is waar het geld naartoe gaat

Opslag is goedkoop. Queries en pipelines niet. Op een lakehouse volgt de computerekening de beslissingen van engineers: welk computetype een job gebruikt, hoe groot het is, hoe lang het stilstaat en wie er meer mag maken. Deze les geeft je een manier om die beslissingen bewust te nemen.

We vergelijken serverless en klassieke compute, beschrijven wat clusterpolicies regelen en laten zien hoe je ziet waar de uitgaven heen gaan. We noemen geen tarieven. Ze verschillen per overeenkomst en veranderen, en de les moet waar blijven als dat gebeurt.

Twee manieren om compute te draaien

Serverless compute wordt door Databricks beheerd. De documentatie zegt dat Databricks automatisch de benodigde computeresources toewijst en beheert, zodat je geen compute in je eigen cloudaccount inricht. Het dekt serverless notebooks, jobs en Lakeflow-pipelines, en streaming op serverless. De runtime is versionless: hij wordt automatisch geüpgraded en workloads draaien op de nieuwste versie. Serverless is in de meeste workspaces standaard beschikbaar en workspaces hebben Unity Catalog nodig. Facturering volgt het serverless-gebruik, dat je uit systeemtabellen zoals system.billing.usage leest.

Klassieke compute draait in je eigen cloudabonnement: jij kiest de nodetypes, het aantal workers, de runtimeversie en het autoscalingbereik. Je wint controle en draagt het operationele werk: dimensioneren, runtime-upgrades, stilstand en netwerkintegratie.

De documentatie verwijst naar een aparte pagina met beperkingen voor serverless en merkt op dat sommige functies die serverless-infrastructuur gebruiken, zoals SQL-warehouses en data quality monitoring, apart worden geconfigureerd. Lees de beperkingenpagina voor je een job verplaatst die ongebruikelijke bibliotheken of connectoren gebruikt.

Een beslisregel die werkt

Wij nemen serverless als standaard voor nieuwe pipelines en jobs en verlaten het alleen met een reden. Geldige redenen zijn specifiek:

• De workload heeft een bibliotheek, driver of eigen databron nodig die serverless niet ondersteunt.
• Een netwerk- of compliance-eis vraagt dat compute draait in een netwerk dat jij beheert en de netwerkopties van serverless dat niet dekken. Controleer eerst de actuele netwerkconnectiviteitsopties. Ons artikel over de herziening van privénetwerk en serverless-egress legt uit waar de grenzen liggen.
• Je hebt een vaste runtimeversie nodig voor reproduceerbaarheid. Onze serverless-playbook voor afhankelijkheden en reproduceerbaarheid laat zien hoe je omgevingen op serverless pint, wat vaak genoeg is.

"We gebruikten altijd klassieke clusters" is geen reden. "Serverless kost meer" ook niet. Meet eerst, met dezelfde job op beide, via de billingtabellen.

Klassieke compute: policies beslissen

Draai je klassieke compute, dan zijn computepolicies je belangrijkste controle. De documentatie zegt dat policies workspacebeheerders laten beperken wat een gebruiker of groep aan compute kan maken, met een set regels. Een policy kan voorgeschreven instellingen eisen, het aantal clusters per gebruiker begrenzen, instellingen verbergen of vastzetten zodat meer gebruikers zelf compute kunnen maken, attributen beperken die de uurkosten bepalen en cluster-gebonden bibliotheekinstallaties afdwingen.

Kostenrelevante instellingen zijn onder meer Max compute resources per user en Max DBUs per hour. Een lagere limiet beëindigt bestaande resources niet, dus een beheerder moet die met de hand stoppen.

Toegang tot policies loopt via rechten. Workspacebeheerders hebben toegang tot alle policies. Andere gebruikers hebben recht op een policy nodig en gebruikers zonder toegang tot een policy zien de policy-dropdown niet. Geef rechten aan groepen, in lijn met onze standaarden.

Een policydefinitie is JSON. De listing hieronder is schematisch: ze toont de bedoeling van drie regeltypen en je schrijft echte definities tegen de computepolicy-referentie.

{
  "autotermination_minutes": { "type": "fixed", "value": 20 },
  "autoscale.max_workers":   { "type": "range", "maxValue": 8 },
  "node_type_id":            { "type": "allowlist", "values": ["<approved-node-type-a>", "<approved-node-type-b>"] }
}

Lees de bedoeling: stilstaande clusters stoppen na twintig minuten, niemand kan voorbij acht workers schalen en alleen goedgekeurde nodetypes zijn beschikbaar. Zet één policy per use case in de bundle en geef je engineers de policy in plaats van vrije configuratie.

Zie waar de uitgaven heen gaan

Je kunt geen uitgaven beheren die je niet ziet. Serverless-gebruik wordt bijgehouden in system.billing.usage. Gebruik het met tags, zodat elke job en pipeline een eigenaar en use case draagt. Onze standaarden eisen tags op elke resource, zoals omgeving, eigenaar, kostenplaats en dataclassificatie.

-- Schematisch: controleer het schema van de systeemtabel in je workspace voor exacte kolomnamen.
SELECT usage_date,
       sku_name,
       custom_tags['owner']    AS owner,
       SUM(usage_quantity)     AS dbus
FROM   system.billing.usage
WHERE  usage_date >= current_date() - INTERVAL 30 DAYS
GROUP  BY usage_date, sku_name, custom_tags['owner']
ORDER  BY usage_date, dbus DESC;

Bekijk zo'n overzicht maandelijks met de eigenaren. Stel drie vragen bij elke grootverbruiker. Is het werk nog nodig? Is het zo frequent als de business nodig heeft? Is het het juiste computetype?

Hefbomen die zelden pijn doen

In onze ervaring verlagen deze wijzigingen de uitgaven zonder afbreuk aan de juistheid:

1. Trigger op gebeurtenis, niet uit gewoonte. Een pipeline die elke tien minuten draait voor data die dagelijks verandert, verspilt compute.
2. Gebruik incrementele runs in availableNow-stijl in plaats van een continu draaiende stream, wanneer de latency het toestaat (les 2).
3. Stop onnodige full refreshes. Incrementele verwerking is het doel van streaming tables.
4. Dimensioneer dev en test klein. Kleine steekproeven, kleine compute, korte timeouts. Kopieer de productieschaal niet naar dev.
5. Ruim het ongebruikte op. Tabellen die niemand leest en jobs die niemand gebruikt kosten nog steeds opslag, compute en aandacht.
6. Pin kostenrelevante standaarden in de bundle, zodat een nieuwe job goedkoop start en een reviewer elke wijziging ziet.

Guardrails

Voeg budgetten en alerts toe waar je platform ze ondersteunt, per workspace of per tag, en stuur ze naar de eigenaarsgroep. Zet een goedkeuringsstap op wijzigingen die een policylimiet verhogen. Een kostenalert is een kwaliteitssignaal: een onverwachte stijging wijst meestal op een lus, een full refresh of een ontbrekend filter.

Veelgemaakte fouten

• Eén policy voor iedereen. Verschillende workloads hebben verschillende limieten nodig.
• All-purpose compute voor geplande taken. De sessie van een persoon mag nooit een nachtelijke load dragen.
• Geen tags. Je kunt uitgaven niet toewijzen, dus niemand is eigenaar.
• Optimaliseren voor je meet. Kijk eerst naar de billingdata.
• Naar serverless verhuizen zonder de beperkingen te lezen.

Samenvatting

Neem serverless als standaard voor nieuw werk en verlaat het met een gedocumenteerde reden. Dwing op klassieke compute policies af voor autotermination, schaal en nodetypes. Tag alles, lees de billing-systeemtabellen maandelijks en gebruik eerst de hefbomen met weinig risico.

Hiermee zijn de zeven lessen compleet. In het eindproject bouw je een beheerde pipeline van begin tot eind.