Dataplattform på Google Cloud – BigQuery i praktiken

Google Cloud och BigQuery har på några år gått från nischval till förstahandsval för svenska bolag som bygger sin första riktiga dataplattform. Anledningen är enkel: BigQuery kräver ingen klusterhantering, skalar från gigabyte till petabyte utan omkonfigurering, och prissätts per fråga snarare än per uppetid. Men en dataplattform är mer än ett lagringslager — det är en kedja av inmatning, transformation, styrning och presentation som måste hänga ihop redan från dag ett, annars slutar den som ett dyrt datasjö-experiment ingen litar på.

I den här guiden går vi igenom hur vi bygger dataplattformar på Google Cloud åt svenska kunder 2026: referensarkitektur, val mellan Dataflow och tredjepartsverktyg för inmatning, BigQuery-specifika optimeringar som partitionering och klustring, orkestrering med dbt och Cloud Composer, åtkomststyrning och de kostnadsfällor som annars får CFO:n att ifrågasätta hela investeringen efter år ett.

Referensarkitektur — tre lager från källa till beslut

De flesta av våra GCP-projekt landar i samma grundstruktur, ofta kallad medaljongarkitektur: ett rått lager (raw) som speglar källsystemen exakt utan transformation, ett stagninglager (staging) med typning, deduplicering och grundläggande städning, och ett presentationslager (marts) med affärslogik och nyckeltal redo för BI-verktyg. Vi lägger varje lager i ett eget BigQuery-dataset med separat IAM-behörighet — analytiker får läsbehörighet till marts, men aldrig skrivåtkomst till raw.

Cloud Storage fungerar som landningszon för filbaserade källor (CSV, Parquet, exporter från affärssystem) innan de laddas in i BigQuery, medan direktanslutna källor som Cloud SQL eller SaaS-API:er ofta går raka vägen in. Separata projekt eller åtminstone separata dataset per miljö (dev, stage, prod) är inte valfritt — vi har sett för många kunder blanda testdata och produktionsdata i samma dataset, vilket gör kostnadsuppföljning och åtkomststyrning omöjlig att reda ut i efterhand.

Datainmatning — batch, streaming och verktygsval

Valet av inmatningsverktyg avgör hur mycket ingenjörstid plattformen kräver löpande. För SaaS-källor som Salesforce, HubSpot, Stripe och Zendesk rekommenderar vi Fivetran eller Airbyte (self-hostat eller Airbyte Cloud) — färdiga anslutningar, hanterad schemaövervakning och inget eget underhåll av API-integrationer. Fivetran kostar mer per rad men kräver nästan ingen drift; Airbyte är billigare i drift men kräver att någon äger infrastrukturen.

För förändringsdatafångst från operativa databaser (Cloud SQL, on-prem Postgres, MySQL) använder vi Datastream, som strömmar ändringar till BigQuery nästan i realtid utan att belasta källdatabasen med tunga batch-frågor. För anpassad logik eller höga volymer — strömmande sensordata, clickstream, händelser i miljontals per timme — bygger vi egna pipelines med Dataflow och Pub/Sub. Tumregeln vi ger kunder: under cirka 50 anslutningar och utan behov av skräddarsydd transformationslogik i farten, välj ett hanterat EL-verktyg. Ovanför det, eller vid strömmande data i realtid, är investeringen i Dataflow motiverad.

BigQuery i grunden — partitionering, klustring och prismodell

BigQuerys on-demand-prissättning ligger kring 6,25 dollar per TiB skannad data (efter första TiB gratis per månad), vilket är förutsägbart för de flesta bolag som skannar under cirka 50 TiB per månad. Över den gränsen blir kapacitetsbaserad prissättning via BigQuery Editions — där du köper slots (beräkningskapacitet) snarare än betalar per fråga — ofta billigare. Vi räknar hem break-even åt kunder innan vi rekommenderar bytet; det är sällan en självklarhet.

Den enskilt största kostnadshävstången är dock partitionering och klustring. En tabell partitionerad på datumkolumn och klustrad på de kolumner som oftast filtreras (kund-id, region, produktkategori) kan sänka skannad datavolym — och därmed kostnad — med 80–95 procent för typiska analytiska frågor, jämfört med en oplitionerad tabell.

För dashboards som behöver svarstider under en sekund lägger vi ofta till BI Engine — ett in-memory-lager framför BigQuery som cachar de mest frekventa frågorna utan att du behöver bygga en separat serveringsdatabas.

Kostnadskontroll i praktiken

Den vanligaste anledningen till att en BigQuery-räkning skenar är inte prismodellen — det är frågor utan WHERE-villkor på partitionskolumnen som skannar hela tabellhistoriken varje gång ett dashboard laddas om. Vi sätter alltid upp Cloud Billing-budgetar med aviseringar på 50, 80 och 100 procent av förväntad månadskostnad, och taggar varje dataset med kostnadsattributions-labels per team så att en avdelning som skannar oproportionerligt mycket data syns direkt i fakturan, inte tre månader senare.

Ett konkret exempel: hos en handelskund gick den månatliga BigQuery-notan från cirka 340 000 kronor per år till under 90 000 kronor efter att vi partitionerade de tre största transaktionstabellerna, bytte fem tunga dashboard-frågor mot materialiserade vyer, och satte maxgränser för hur många TiB varje tjänstekonto får skanna per dag. Ingen ny hårdvara, ingen ny licens — bara arkitektur. Vi kör alltid en dry run (bq query --dry_run) i CI innan en ny dbt-modell eller ett nytt dashboard går till produktion, så att kostnadsöverraskningar fångas innan de når fakturan.

Orkestrering och transformation — dbt och Cloud Composer

dbt är standardvalet för transformationslagret i praktiskt taget alla BigQuery-plattformar vi bygger 2026. Modellerna skrivs i SQL, versionshanteras i Git, testas automatiskt (unika nycklar, null-kontroller, referensintegritet) och dokumenteras med automatisk lineage. För schemaläggning och att knyta ihop inmatning och transformation i samma pipeline använder vi Cloud Composer (hanterad Airflow) — det håller ordning på beroenden mellan Fivetran-synk, Datastream och dbt-körningar utan att någon behöver klicka runt manuellt.

För mindre team utan dedikerad plattformsingenjör rekommenderar vi dbt Cloud istället för självhostad dbt Core på Composer — det sparar driftsansvar till priset av en licenskostnad som oftast är försvarbar redan vid två-tre aktiva utvecklare.

Åtkomststyrning och governance

IAM i BigQuery går ner till dataset-, tabell- och kolumnnivå. Vi sätter alltid upp rollbaserad åtkomst per lager snarare än per person, och lägger radnivåsäkerhet (row-level security policies) på tabeller som delas mellan avdelningar med olika behörighet — till exempel så att en säljregion bara ser sina egna kunder i samma tabell som resten av organisationen använder.

Dataplex fungerar som datakatalog och lineage-verktyg ovanpå plattformen, och Sensitive Data Protection (tidigare Cloud DLP) taggar och maskerar personuppgifter automatiskt vid inmatning. Värt att notera för svenska kunder: Google Cloud har ingen region i Sverige. Närmast EU-belägna region är europe-north1 (Finland) eller europe-west1 (Belgien) — vi väljer i praktiken alltid europe-north1 för nordiska kunder med krav på datalagring inom EU/EES.

BI-lager och självbetjäning

Looker Studio (gratis) räcker för enkla dashboards och interna rapporter, men saknar en governed semantic layer — varje användare kan definiera "intäkt" olika, vilket snabbt urholkar förtroendet för siffrorna. Looker med LookML löser det genom att centralisera mätetalsdefinitioner en gång och återanvända dem i alla dashboards. För organisationer som redan investerat i Microsofts ekosystem fungerar Power BI:s BigQuery-koppling bra, men med något högre latens än Lookers native-integration.

Vår rekommendation: starta med Looker Studio för snabb tid-till-värde, men planera för Looker eller ett motsvarande semantic layer-verktyg så snart fler än två-tre team börjar bygga egna dashboards ovanpå samma dataplattform — annars byggs inkonsekvens in i organisationen från start.

Google Cloud jämfört med Snowflake och Azure

Frågan vi får oftast innan projektet ens startar är om det ska vara Google Cloud överhuvudtaget. Snowflake har fördelen av att vara molnleverantörsoberoende och har historiskt haft ett enklare gränssnitt för multi-cloud-datadelning, men saknar BigQuerys inbyggda separation av lagring och beräkning på samma nivå — Snowflake-kluster (warehouses) måste dimensioneras och pausas manuellt för att undvika onödig körningstid. Azure Synapse eller Microsoft Fabric är ofta rätt val om resten av verksamheten redan är djupt investerad i Power BI, Entra ID och Azure-nätverk — då minskar friktionen i identitetshantering och nätverksintegration betydligt.

Vår tumregel: välj Google Cloud och BigQuery när ni vill ha lägst operativ overhead och betala strikt för det ni faktiskt frågar, välj Snowflake när ni behöver dela data mellan flera molnleverantörer eller externa parter, och välj Azure/Fabric när resten av IT-miljön redan är Microsoft-centrerad. Ingen av de tre är fel — men att byta i efterhand är ett halvårsprojekt, så avgör det tidigt tillsammans med hela IT-organisationen, inte bara dataplattformsteamet.

Slutsats

En dataplattform på BigQuery vinns inte av verktygsvalet i sig, utan av arkitekturbesluten som tas de första veckorna: lagerstruktur, partitioneringsstrategi och åtkomstmodell. Rätt uppsatt skalar den från startup till miljardomsättande bolag utan omskrivning. Fel uppsatt blir den en kostnadsöverraskning i nästa budgetrunda. Läs gärna vidare i vår praktiska guide till BigQuery-optimering eller jämför med ETL mot ELT för din dataplattform om ni fortfarande väljer inmatningsstrategi.

Vill du bygga eller migrera er dataplattform till Google Cloud? läs mer om våra tjänster eller boka ett samtal.