Ett år med BigQuery

7 min read

Hei! Mitt navn er Lars, og jeg jobber som Data Engineer i Unacast. I dette innlegget skal jeg fortelle litt om min erfaring med å jobbe med “et databasesystem som alltid gir raske svar på spørringer, men som tar betalt per spørring”, nærmere bestemt Google BigQuery. Jeg skal trekke frem noen forskjeller i måten man jobber med slik et nymotens BI-verktøy sammenlignet med de mer tradisjonelle, belyse noen fordeler og advare om noen fallgruver vi har oppdaget underveis. Og siden jeg som forhenværende konsulent vet at det er lurt å gi bort konklusjonen allerede i innledningen, så gjør jeg selvsagt det: Å jobbe med BigQuery er helt topp, men man kan brenne seg hvis man ikke holder tunga rett i munnen.

Unacast er et dataselskap som bygger en plattform for lokasjonsdata og vil tilby innsikt i hva som foregår i den fysiske verden til dagens og neste generasjons datadrevne industrier. Vi samler inn data fra smarttelefoner i USA via samarbeid med forskjellige partnere, sammenstiller og beriker dataene og tilbyr dem til kunder innen markedsføring og forskning. Som “Data Engineer” er min jobb å sørge for at innsamlingen, prosesseringen, lagringen og rapporteringen av dataene går som den skal. Og siden vi er en oppstartsbedrift med et øye på fremtiden har vi som seg hør og bør kastet oss fullstendig på skyen, og landet på å bruke Google Cloud Platform til all vår infrastruktur med Google BigQuery i sentrum som database og spørremotor for våre data.

BigQuery er en “Software-as-a-Service” databasetjeneste spesielt beregnet på store datamengder. Tjenesten er serverløs og veldig enkel å bruke: Man trenger bare laste strukturerte data inn i systemet og kan deretter gjøre SQL-lignende spørringer på dem. Google står for alt av infrastruktur og vedlikehold, og sørger for å skalere automatisk slik at enhver spørring du måtte ønske å stille blir besvart innen rimelig tid. Dette løser de imponerende godt ved å spre dataene utover sitt store hav av maskiner og deretter utføre parallelliserte spørringer. Til forskjell fra mer tradisjonelle databasesystemer er det i BigQuery ingen indeksering, i stedet lagres dataene helst denormalisert og scannes i sin helhet for hver spørring. Og det er her vi finner den eneste kompliserende faktoren, nemlig betalingsmodellen: I tillegg til en symbolsk sum for lagringsplassen man benytter betaler man per spørring for datamengdene i kolonnene som refereres.

Et klassisk problem jeg ofte kjente på før da jeg som konsulent lagde interaktive rapporter for travle forretningsbrukere var spørringer som tok for lang tid. For å bøte på dette og ikke miste interessen til brukerne var det noen tiltak vi kunne gjøre, hvor de første på listen var å skrive om og effektivisere spørringene våre eller optimalisere databasen for de som ble gjort hyppigst. Om ikke det fungerte, kunne vi mellomlagre aggregater for de vanskeligste spørringene. Dersom ikke det heller var nok, var siste utvei å oppgradere databasen, dersom det fantes tilstrekkelig med fleksibilitet i budsjettet. Vi kviet oss for å foreslå dét, og gjorde det så godt vi kunne med det vi hadde. Ved en anledning kikket vi på BigQuery som en mulig løsning, men vi slo det fra oss fordi vi ikke helt trodde på lovnadene om ytelse, og fordi det var vanskelig å estimere hva regningen til slutt ville komme på.

Nå som jeg har jobbet med BigQuery over tid kan jeg bekrefte at påstandene om hva systemet er i stand til langt på vei var sanne. Å bruke BigQuery er virkelig veldig enkelt, og systemet har overrasket oss flere ganger ved å takle hårete spørringer vi ikke trodde vi ville slippe unna med. Det egner seg godt til ad-hoc utforskning av data, skedulerte transformasjoner som kan uttrykkes med SQL, og som kilde for rapportering. Vi kan raskt endre logikken vi bruker siden vi kan spørre rett på rådataene og slipper å materialisere aggregater, og trenger ikke henge oss opp i datamodellering siden dataene lagres denormalisert. Det eneste vi ikke kan gjøre er å sortere store datasett, men ellers støter vi ikke på vegger.

De største fordelene BigQuery gir oss er at vi kan utvikle løsninger raskt og få resultater kjapt. Siden de underliggende systemene tilpasser seg vår bruk trenger vi ikke lage perfekte løsninger for å få resultatene vi vil ha. Når resultatene først kommer, er det fristende å sette det vi har laget i produksjon. Spesielt praktisk er det da selvsagt at løsningen skalerer automatisk, så det som fungerer i dag vil også fungere med morgendagens alltid økende datamengder. Og når man utsettes for så lite friksjon under arbeidet, ja, da er det lett å glemme det med betalingsmodellen. Og det er naturligvis dét som er fallgruven jeg nevnte innledningsvis.

Min far er filmklipper, og etter at jeg (som den gode sønnen jeg er) hadde testet ut materialet til denne teksten på ham, kunne han tilby følgende analogi: Overgangen fra tradisjonelle relasjonelle databaser til et system som BigQuery er litt som overgangen fra analog film til digital video.

Analog film er veldig dyrt. Derfor, for å spare penger, var man alltid påpasselig med å planlegge filminnspillinger nøye slik at minst mulig film gikk til spille. Når filmen så skulle klippes sammen i klipperommet var mye av planleggingsarbeidet allerede gjort, og det var begrensede mengder materiale som skulle bearbeides. Så kom det langt billigere alternativet digital video. For de på filmsettet var dette en gavepakke, for nå trengte man ikke lenger være like sparsommelig og kunne eksperimentere mer under innspillingen. Dette førte i sin tur til at mye mer og mindre gjennomtenkt materiale ble produsert, som filmklipperne så måtte gjøre en langt større jobb enn tidligere for å gå igjennom og klippe sammen. Med BigQuery ser vi at noe lignende skjer. Vi, filmskaperne i analogien, trenger ikke være så konservative lenger, og blir ledet til å sende langt større mengder mindre gjennomtenkte spørringer til databasens “klipperom” enn vi gjorde før. Fint for oss, som kan jobbe friere enn vi kunne tidligere, men kanskje spesielt fint for Google, som nå har fått oss til å sende dem dette ekstraarbeidet og gladelig tar seg betalt per spørring.

Friheten BigQuery gir oss fører altså med seg et ansvar om å være bevisst på hva den brukes til. Vi kan spørre rett på rådataene, men burde vi? Løsningen fungerer, men burde vi sette den i produksjon og gjøre oss avhengig av den? Det er fint med fleksibilitet, men behovet for å planlegge og finne effektive og helhetlige løsninger forsvinner ikke. Vi må passe på så vi ikke skyver arbeidet over på databasen bare fordi vi kan.

Konklusjonen jeg sitter igjen med etter ett år med BigQuery, er at det føles som at spillereglene er endret. En flaskehals er blitt fjernet og resultatene kommer raskere, men de underliggende utfordringene er de samme. Det er lett å nedprioritere beste praksis når man ikke umiddelbart merker konsekvensene av å gjør det – Systemene slutter ikke å fungere, men den månedlige regningen kan vokse ut av kontroll. Jeg savner ikke å jobbe med de tradisjonelle databasene jeg brukte før, men det jeg lærte da jeg gjorde det er like viktig den dag i dag. Dessuten, når mengdene data vokser i takten de gjør for tiden, er det neppe noen vei utenom!

Helt til slutt, et eksempel: Før presentasjonen ble jeg bekymret for at noen ville be meg underbygge påstanden om at BigQuery fungerer “uansett”, så jeg bestemte meg for å teste grensene med et eksperiment. Jeg fant frem til tabellene som inneholdt alt vi hadde av rådata fra de siste 30 dagene, og prøvde å telle antall unike ID-er i en av kolonnene. Spørringen måtte scanne 94 milliarder rader, 3.2 TB data, og ville koste omtrent 130 kroner. En mer krevende spørring enn de vi vanligvis stiller, og etter en ganske lang ventetid på 13 minutter kom svaret. Jeg gjentok spørringen for sikkerhets skyld, og regnet ut at jeg hadde brukt ca. 300 kroner totalt da jeg var ferdig. Skulle jeg gjentatt eksperimentet én gang i timen hver dag, ville kostnadene summert til en årslønn.

About Lars Bakke Krogvig

Lars Bakke Krogvig, Data Engineer hos Unacast. Tidligere konsulent innen BI, har en grad innen anvendt matematikk. Liker å tegne på whiteboard.