GCP för dataintensiva svenska bolag: BigQuery + Vertex + Looker

För de flesta bolag spelar valet av moln mindre roll än man tror - de tre stora kan göra ungefär samma sak. Men för ett dataintensivt bolag, där analys och maskininlärning är själva affären, finns det ett tydligt argument för Google Cloud. Anledningen är att BigQuery, Vertex AI och Looker hänger ihop till en plattform där data inte behöver flyttas runt mellan system. Här går jag igenom hur den plattformen ser ut och varför den lyfter just dataintensiva verksamheter.

BigQuery som nav

Allt börjar i BigQuery. Det är inte bara ett datalager utan en serverless analysmotor du kan köra enorma frågor i utan att tänka på kapacitetsplanering. Du betalar för det du frågar eller för reserverad kapacitet, och skalningen sköter sig. För ett bolag vars konkurrensfördel ligger i att snabbt kunna analysera mycket data är den modellen befriande - du slipper dimensionera kluster och kan i stället fokusera på frågorna.

Den serverlösa modellen har en konsekvens som är värd att förstå: eftersom du betalar per skannad data blir hur du skriver dina frågor och hur du strukturerar dina tabeller en direkt kostnadsfråga. En slarvig fråga som läser hela datalagret kostar mer än en som bara rör de kolumner och partitioner den behöver. Det låter som en nackdel men är egentligen en styrka - kostnaden blir transparent och styrbar, och du betalar aldrig för stillastående kapacitet du inte använder.

Modellera i lager

En kraftfull motor räcker inte om datan är en träskmark. Jag strukturerar i tydliga lager: ett rålager med oförändrad data som sanningskälla, ett konformat lager som är rensat och affärsbegripligt, och ett presentationslager för konsumtion. Transformationerna sköts i SQL inne i BigQuery, gärna med ett verktyg som hanterar beroenden och tester mellan modellerna, så att de blir versionshanterade och granskningsbara.

• Rålager - oförändrad data, ert facit.
• Konformat lager - rensat, typat, begripligt.
• Presentationslager - aggregat och vyer för rapporter och ML.

Vertex AI för maskininlärning

Det här är där GCP drar ifrån för dataintensiva bolag. För många fall räcker BigQuery ML, där du tränar modeller med SQL direkt på datan utan att flytta den. När behoven växer tar Vertex AI vid med en samlad miljö för träning, modellregister, driftsättning och övervakning. Poängen är närheten - din data, dina modeller och din analys lever på samma plattform, vilket kortar vägen från idé till en modell i produktion betydligt.

Det är också här de flesta initiativ fastnar hos andra: en modell i en notebook är inte i produktion. Med Vertex AI Pipelines beskriver jag hela flödet - dataförberedelse, träning, utvärdering, driftsättning - som en återkörbar pipeline. Modeller hamnar i ett register med versioner, och prediktioner serveras antingen som batch tillbaka till BigQuery eller via en endpoint för realtid. Lika viktigt är att övervaka modellen för avdrift, så att du märker när den börjar tappa träffsäkerhet. Att datan redan ligger i BigQuery gör varje steg i den kedjan kortare.

Looker för det semantiska lagret

Det vanligaste sättet att tappa förtroende för data är att intäkt betyder olika saker i olika rapporter. Looker löser det med en modelleringsnivå där måtten definieras en gång och återanvänds överallt. Det betyder att en siffra är samma siffra oavsett vem som tittar, vilket är avgörande för en datadriven organisation. Looker sitter ovanpå BigQuery och drar nytta av samma grund.

Ingestion: få in data tillförlitligt

Innan något av detta fungerar måste data in i plattformen på ett sätt som går att lita på. För filer och periodiska laster använder jag laddning till BigQuery direkt eller via Cloud Storage som mellanlager. För strömmande data går vägen ofta genom Pub/Sub och Dataflow. Det viktiga är att landa rådata oförändrad i rålagret innan något transformeras, så att du alltid kan gå tillbaka till källan om en transformation visar sig fel. Den som bygger eget för varje källa drunknar i underhåll - använd färdiga kopplingar där de finns och bygg eget bara där en connector saknas.

Glöm inte grunden och kostnaden

Plattformen vilar på en ordentlig GCP-organisation: resurshierarki, IAM och org policies som ärvs nedåt, samt en medveten kostnadskontroll. BigQuery kan bli dyrt om frågorna får skena, så partitionera och klustra stora tabeller och välj prismodell medvetet. Att aktivera faktureringsexport tidigt ger underlag för uppföljning den dag kostnaden växer. Den här grunden hör ihop med min genomgång av Terraform-moduler för kundsetup.

Vanliga fallgropar

• Att transformera bort rådata och förlora sanningskällan.
• Ostrukturerade frågor i stället för lagrad, testad transformation.
• Mått som definieras olika i olika rapporter utan ett semantiskt lager.
• Ingen kostnadskontroll på frågor mot stora tabeller.

Relaterat

• Multi-region failover i GCP: Praktisk arkitektur för svenska e-handlare
• Container security: Snyk, Trivy och Falco för runtime-säkerhet i K8s
• Service mesh med Istio vs Linkerd: Trafikkontroll och mTLS i Kubernetes

Vill du ta det vidare?

Är data kärnan i er affär hjälper jag er att bygga en GCP-plattform där analys och ML vilar på samma grund. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.