BigQuery cost optimization: 14 query-mönster som halverar fakturan

Den vanligaste chocken jag möter hos nya BigQuery-användare är fakturan. BigQuery är fantastiskt, men du betalar för data du läser, och slarviga frågor läser enormt mycket i onödan. Den goda nyheten är att de flesta besparingar inte kräver någon arkitekturändring, bara bättre vanor. Här går jag igenom de mönster jag själv lutar mig mot för att skära kostnaden, ofta i storleksordningen hälften.

Grundprincipen: läs mindre

Nästan all kostnadsoptimering i BigQuery kokar ner till en sak: läs mindre data. Modellen tar betalt för antal bytes frågan skannar, inte för hur smart frågan är. När jag tänker på kostnad tänker jag på hur jag kan få samma svar genom att röra mindre data.

Sluta med SELECT star

Eftersom BigQuery är kolumnär läser den bara de kolumner du ber om. En SELECT star läser allt, även kolumner du aldrig använder. Att lista exakt de kolumner du behöver är den enklaste och mest underskattade besparingen som finns.

• Välj kolumner explicit i stället för star.
• Filtrera tidigt så att mindre data går vidare i frågan.
• Undvik att skanna hela tabeller bara för att kontrollera en sak.

Partitionering och klustring

Om en tabell är partitionerad på datum och du filtrerar på datum läser BigQuery bara de partitioner som behövs. Klustring sorterar datan så att filter på de klustrade kolumnerna också skannar mindre. Tillsammans är de det kraftfullaste verktyget för att hålla skannade bytes nere på stora tabeller.

Att lägga upp tabeller med rätt partitionering från start är något jag alltid gör i vårt arbete med dataplattform, eftersom det är mycket billigare att göra rätt än att städa i efterhand.

Materialisera det som körs ofta

Om samma tunga aggregering körs hundra gånger om dagen är det slöseri att räkna om den varje gång. Genom att materialisera resultatet, antingen som en tabell eller en materialiserad vy, betalar du beräkningen en gång i stället för hundra. Det är ett av de tydligaste sätten att kapa upprepad kostnad.

Undvik onödiga omkörningar

Mycket kostnad kommer av att samma transformationer körs om i onödan, ofta för att schemaläggningen är trubbig. Jag ser till att tunga jobb bara körs när källdata faktiskt ändrats, och inkrementellt där det går, i stället för att bygga om hela tabeller från grunden varje natt.

Reserverad kapacitet mot betalning per fråga

En avgörande kostnadsfråga är vilken prismodell du kör på. Som standard betalar du per skannad mängd data, vilket är förutsägbart och rättvist för måttlig och ojämn användning. Men när användningen blir hög och jämn kan en kapacitetsbaserad modell, där du betalar för en reserverad beräkningskraft, bli billigare. Felet många gör är att byta till kapacitet i hopp om att spara pengar utan att först optimera frågorna. Då betalar du i stället för kapacitet som slösas på samma ineffektiva mönster. Jag optimerar därför alltid frågorna först och utvärderar prismodellen sedan, när jag vet hur den faktiska, städade förbrukningen ser ut.

Att fördela och följa kostnad per team

I en organisation där många team delar samma BigQuery-miljö blir det snabbt oklart vem som står för kostnaden. Utan synlighet finns ingen press att skriva effektiva frågor, eftersom notan ändå hamnar någon annanstans. Jag sätter därför upp etiketter och uppföljning så att kostnaden går att bryta ner per team eller projekt, vilket både skapar ansvar och gör det möjligt att se var de stora pengarna faktiskt går. När ett team ser sin egen förbrukning svart på vitt förändras beteendet ofta av sig självt, utan att jag behöver predika om optimering.

Mät innan du optimerar

Jag gissar aldrig var pengarna går. BigQuery visar exakt vilka frågor som skannar mest, och jag börjar alltid där. Ofta står en handfull frågor för en oproportionerlig del av fakturan, och att fixa dem ger mer än att finlira med resten. Mät först, optimera där det syns. Fler exempel finns i vår casebook.

Relaterat

• dbt-projektstruktur: Mappar, modeller och tests som skalar
• ETL vs ELT vs Reverse ETL: Modern data stack för svenska bolag
• BI-val: Looker vs Power BI vs Metabase vs Lightdash

Vill du ta det vidare?

Om din BigQuery-faktura växt snabbare än du gillar, hör av dig via kontaktsidan. Jag tittar på dina dyraste frågor och pekar ut var de största besparingarna finns.