FinOps brengt BigQuery-kosten van e-commercebedrijf met 77% omlaag
Door FinOps toe te passen op de BigQuery-processen bracht onze klant de kosten fors omlaag.
38% lagere BQ-kosten
binnen 20 dagen
77% lagere BQ-kosten
na 1 maand
Het doel
Onze klant, een e-commercebedrijf, zag de cloudkosten zo hard oplopen dat de investeringen in data-analyse eronder dreigden te lijden. Er was een verstandige en houdbare manier nodig om de uitgaven in de Google Cloud-omgeving te beheersen.
Met FinOps als uitgangspunt was het doel helder: de kosten van opslag en queries in BigQuery omlaag brengen, zonder in te leveren op inzicht en prestaties.
De uitdaging
De kosten liepen flink op doordat BigQuery (BQ) inefficiënt werd gebruikt, als gevolg van processen die een ander bedrijf had ingericht.
Concreet draaiden er meerdere processen ieder uur om gegevens bij te werken en toe te voegen. Die haalden data uit BigQuery, verrijkten die en stuurden het resultaat door naar een andere plek. Naarmate de tabellen groeiden, leverde dat problemen op:
- Te vaak bijwerken: de processen draaiden te frequent, met updates en toevoegingen per uur, wat zowel de opslag- als de querykosten flink opdreef.
- Te veel data ophalen: de processen haalden meer gegevens op dan nodig, waardoor er onnodig veel data werd doorzocht en betaald.
- Problemen bij groei: hoe groter de tabellen werden, hoe zwaarder die inefficiëntie ging wegen, en hoe harder de kosten stegen.
- Veel losse wijzigingen: de klant werkte vaak afzonderlijke records bij, wat in BigQuery duur is: dat platform is gemaakt voor grootschalige analyse, niet voor veel kleine aanpassingen.
De klant wilde uitzoeken waar dat vandaan kwam en de kosten terugbrengen, zonder functionaliteit in te leveren.
Begin je eigen succesverhaal met Crystalloids
Werk samen met Crystalloids en Google Cloud om je project tot leven te brengen.
De oplossing
Vanuit de FinOps-principes namen we een aantal maatregelen:
- Losse regels bijwerken vervangen door batches: Een grote kostenpost was het steeds bijwerken van afzonderlijke regels. Elke update verhoogde de hoeveelheid verwerkte data, omdat er per verwerkte regel een record werd bijgewerkt. BigQuery is sterk in het bevragen en analyseren van grote hoeveelheden data, maar niet gemaakt voor veel kleine wijzigingen. Omdat de prijs afhangt van de hoeveelheid verwerkte data, tikten die updates hard aan. We wezen het updatemechanisme aan als het punt om te verbeteren en stelden voor die wijzigingen te bundelen met een cache. In plaats van elke regel apart bij te werken, houden we de wijzigingen lokaal bij en voeren we aan het eind van elk proces één gebundelde update uit. Dat scheelde een groot aantal losse updates, drukte de kosten en maakte de queries efficiënter.
- Alleen de velden opvragen die nodig zijn: De SQL-queries in de processen haalden alle velden op (met *), waardoor er onnodig veel data werd doorzocht en de kosten opliepen. We keken per proces welke velden er werkelijk nodig waren en pasten de queries daarop aan. Door alleen die velden op te vragen ging de doorzochte hoeveelheid data van gigabytes naar megabytes, met een flinke kostenbesparing als gevolg.
- Tabellen partitioneren: Zonder partitionering doorzoekt BigQuery bij elke query de hele tabel, wat duurder wordt naarmate die tabel groeit. We adviseerden de tabellen te partitioneren langs logische lijnen, zoals tijdvakken of productcategorieën. Daardoor doorzoekt BigQuery alleen de relevante partities, wat de hoeveelheid verwerkte data en dus ook de kosten fors terugbrengt.
Het resultaat
Deze FinOps-maatregelen leverden direct op:
- 38% lagere BigQuery-kosten binnen 20 dagen.
- Na één maand lagen de kosten 77% lager dan daarvoor.
Door FinOps gericht toe te passen bespaart de klant op cloudkosten, houdt hij grip op zijn uitgaven en blijven de prestaties van de data-analyse op peil.
