Varför BigQuery?
BigQuery är Googles serverlösa data warehouse. För mellanstora svenska organisationer är valet ofta enkelt: låg driftbörda (ingenting att patcha eller skala), bra pris/prestanda på on-demand, stark integration mot GA4, Google Ads och Vertex AI, och en pålitlig motor som klarar både analytics och kompletta ELT-laster.
Det finns goda skäl att välja något annat. Är ni djupt i AWS är Redshift naturligare. Snowflake är leverantörsoberoende och har en mer flexibel kostnadsmodell vid stora, ojämna laster. Postgres med dbt klarar förvånansvärt långt om volymerna inte är extrema. Den här guiden förutsätter att BigQuery är valt - om det inte är det, börja där.
Referensarkitektur
En enkel, robust grund som skalar utan att bli ohanterlig.
Källinventering
Vilka system, vilka volymer, hur ofta uppdaterat, hur kritiskt? Bygg en prioriterad lista innan något kopplas in.
Projekt- och dataset-struktur
Ett GCP-projekt per miljö (dev/test/prod). Dataset uppdelade på lager: raw, staging, marts. Naming-konvention från dag ett.
Ingestion
Fivetran/Airbyte för standard-API:er. Egen pipeline (Cloud Run + Pub/Sub) eller scheduled queries för udda källor. Tydlig regel: råa data går till raw, oförädlad.
Modellering med dbt eller Dataform
Staging-modeller normaliserar källor. Mart-modeller bygger affärsentiteter. Tester på primärnycklar, not_null och affärsregler.
Konsumtion
Looker Studio (gratis) för enkla dashboards. Looker eller Metabase för mer avancerat. Direkt BigQuery-frågor från analysteam med Connected Sheets.
Åtkomst och säkerhet
IAM på dataset-nivå. Authorized views för känsliga kolumner. Audit logs på frågor. Inga personliga åtkomster - bara grupper.
Kostnadskontroll
Budget alerts. Query labels. Partitionering och clustering på stora tabeller. Reservering av kapacitet först när on-demand bevisligen kostar mer.
Datamodellering: raw → staging → marts
Tre tydliga lager. Råa data går till raw_-dataset oförändrade - så att man alltid kan reproducera om något går snett senare.staging_-modeller normaliserar källornas data utan affärslogik (typkonvertering, namnstandardisering, basala tester).marts_-modeller bygger affärsentiteter (kunder, beställningar, händelser) som är vad analysteamet faktiskt frågar mot.
Disciplinen är värd guld när källsystem byts ut. När CRM-leverantören byts ändras bara staging-lagret. Marterna består - och alla dashboards fortsätter fungera.
Ingestion-strategier
Managed connectors (Fivetran/Airbyte/Stitch)
För standard-API:er (CRM, marketing, betalningar). Snabbt att komma igång, men kostnaden växer per källa och rad - utvärdera när månadsnotan passerar 5 000 kr/källa.
Native GCP-tjänster
Datastream för CDC från Postgres/MySQL. BigQuery Data Transfer Service för Google-källor. Storage Transfer för fil-baserad inhämtning.
Egen pipeline (Cloud Run + Pub/Sub eller Cloud Functions)
För udda källor eller där managed connectors är för dyra. Kostnadseffektivt men kräver förvaltning. Inkludera retries, dead letters och larm från dag ett.
Scheduled queries och external tables
För platta filer i Cloud Storage. External tables låter er fråga direkt utan att duplicera data - bra för referensdata och arkiv.
Kostnadskontroll: on-demand vs. capacity
BigQuery-kostnaden består av två delar: lagring (billig - cirka $0,02/GB/månad för aktiv data) och fråge-compute. Fråge-compute har två modeller:
- On-demand: $6,25 per TB skannad data. Bra för oregelbundna laster och team som inte vet sin volym i förväg. Förvånansvärt billigt om tabellerna är partitionerade och clustrade.
- Capacity (slots): Fast månadskostnad per reserverad slot. Lönsamt först vid hög och förutsägbar last (vanligen 100+ aktiva användare eller tungt jobbflöde).
Praktiska kontroller:
- Sätt budget alerts på projekt-nivå (Google Cloud Billing).
- Partitionera tabeller på datum eller tidsfält - frågor på dagens data skannar då bara dagens partition.
- Clustra på de kolumner som filtreras mest.
- Sätt
maximum bytes billedper query för att förhindra olycksskott. - Använd query labels för att kunna spåra kostnad per team eller dashboard.
Datakvalitet och tester
En dataplattform som inte testas blir aldrig betrodd. dbt:s testramverk är minimum:
-
uniqueochnot_nullpå primärnycklar i alla staging- och mart-modeller. -
relationshipsför foreign keys mellan marter. -
accepted_valuespå enum-liknande kolumner. - Anpassade tester på affärsregler (t.ex. "ingen order har negativt belopp").
- Freshness-tester så att stale data larmar innan en dashboard visar fel.
Åtkomst och säkerhet
- IAM på dataset- eller tabellnivå - aldrig på enskilda personer, alltid på Google Groups.
- Authorized views eller column-level security för känsliga kolumner.
- Audit logs aktiverade och skickade till en separat plats för långtidslagring.
- Service accounts för pipelines, ingen personlig åtkomst i produktion.
- Datasekretess: tänk igenom GDPR-implikationer av att samla data från flera källor.
BI och konsumtion
Looker Studio är gratis och räcker långt för mindre organisationer. Looker ger semantiskt lager och styrning vid större skala. Metabaseär öppen källkod, snabbt att komma igång och uppskattat av analyster. Connected Sheets låter ekonomi- och affärsteam fråga BigQuery direkt från Google Sheets - underskattat verktyg.
Oavsett val: ge analysteamet direkt åtkomst till marterna. Tvinga inga onödiga semantiska lager för enkla frågor. Tröskeln för att svara på en affärsfråga är det som avgör om plattformen används eller inte.
Drift och förvaltning
CI/CD för dbt-projekt
Pull requests körs mot ett dev-projekt, mergas till main efter att tester passerat. Inga manuella deploys till prod.
Övervakning
Larm på pipeline-fel, freshness-tester, oväntade kostnadsökningar. Inga tysta misslyckanden.
Dokumentation
dbt docs genereras automatiskt. Komplettera med en handfull manuellt skrivna sidor om syfte och beroenden.
Stewardship
En person äger varje mart. Frågor om data ska veta vart de ska - inte fastna i ett #data-Slack-kanal-vakuum.
Vanliga frågor
Bygg eller modernisera er dataplattform
Tjänsten Dataplattform täcker allt från datagenomlysning till plattformsprojekt och löpande rådgivning.
Läs om tjänsten