Skip to main content

Når Airflow ikke passer

I noen tilfeller kan det være at man vil lage ein pipeline hvor Airflow ikke er egnet. Denne siden viser noen eksempler på hvordan man kan bygge pipelines uten Airflow.

Generelle prinsipper for pipelines​

Når data skal deles i datakatalogen, eller benyttes som del av et foredlet dataprodukt, bør man lage en automatisk ELT-pipeline. For at denne skal kunne bygges og vedlikeholdes på en robust og effektiv måte, er det en del prinsipper som bør følges:

  1. Reproduserbar infrastruktur – Alle ressurser som benyttes i GCP bør provisjoneres på en reproduserbar og versjonert metode, slik at man kan være sikker på at samme infrastruktur kjører i ulike miljøer, samt kunne sette opp infrastruktur på nytt dersom det skulle være nødvendig. I praksis betyr dette at ressurser defineres i Terraform, sjekkes inn i kode og deployes via CI/CD (for eksempel GitHub Actions).

  2. Keep it simple - Lag den enkleste arkitekturen som oppfyller kravene til pipelinen. I mange tilfeller betyr dette en eller flere Cloud Functions, eller data-verktøy som DBT. Under utvikling kan enkle scheduled queries være et nyttig verktøy, men det anbefales ikke å bruke dette i produksjon da disse er vanskelig å vedlikeholde.

  3. Idempotens og deduplisering - Det er ikke uvanlig at et steg i en pipeline kan kræsje etter at noe data har blitt importert. Når dette steget kjøres på nytt vil man dermed ende opp med at noen av dataene har blitt importert to ganger. Det er derfor viktig at enhver pipeline er laget slik at den tåler gjentatte kjøringer uten at det endelige dataproduktet har duplikater eller inkonsistente data. For eksempel kan man ha ulike BigQuery-tabeller for hvor dataene først lander (en "landingstabell") og visningen av dataene, der den førstnevnte kan inneholde duplikater, mens den endelige tabellen kun viser deduplisert data. Eksempelvis kan man få til dette ved å definere et view som dedupliserer dataene fra landingstabellen.

Pipeline-arkitekturer​

Når man skal hente data fra et annet system, kan man gjøre dette enten ved å eksplisitt spørre systemet ("pull"), eller ved å åpne for at systemet kan sende inn data selv ("push").

Pull-pipelines​

Integrasjoner som henter data ved "pulling" kjennetegnes ved følgende:

  • Kildesystemet må ha et endepunkt som er tilgjengelig fra internett
    • Det kan f.eks. være et REST API eller en database, og kan godt være passordbeskyttet eller sikret på annen måte
    • Unntaksmessig kan det settes opp VPN-kobling fra interne SVV-systemer til GCP
  • Integrasjonen er ansvarlig for oppdateringsfrekvens og validering av data
  • Kildesystemet trenger ikke kjenne til integrasjonen eller Saga
  • Henting av data skjer periodisk, f.eks. via en Cloud Scheduler

Eksempel​

Her er et eksempel på en "pull"-pipeline som bruker Cloud Functions, GCS og BigQuery, for et tenkt "Weather" API:

Example poller pipeline

  1. En Cloud Scheduler trigger hver time og kaller function'en weather-poller over HTTP
  2. Polleren gjør et REST-kall mot API og henter værdata i JSON-format
  3. Polleren lagrer JSON uendret i en GCS-bøtte weather-ingest
  4. En Cloud Function weather-standardizer lytter på nye filer i weather-ingest-bøtta, leser disse og konverterer dem til et standardisert format
  5. Standardizeren streamer data til en tabell internal.weather
  6. Et view standardized.weather dedupliserer data fra internal.weather basert på et definert unikhetskriterie (f.eks. målestasjon og tidspunkt)

Et annet eksempel finnes i "saga-team-template"-repoet, sammen med eksempler på bruk av Terraform for versjonert infrastruktur, og GitHub Actions for automatisk release og deploy.

Push-pipelines​

Integrasjoner som henter data ved "pushing" kjennetegnes ved følgende:

  • Integrasjonen må tilgjengeliggjøre et endepunkt som kildesystemet kan sende data til
    • Dette kan være f.eks. en Pub/Sub-topic, en GCS-bucket eller en BigQuery-tabell
  • Kildesystemet styrer oppdateringsfrekvens; kan være periodisk, kontinuerlig eller sporadisk
  • Kildesystemet må kjenne til Saga og autentisere seg mot GCP, typisk via en Service Account
  • Kildesystemet trenger ikke være eksponert på internett, men må kunne gjøre kall mot GCP

Eksempel​

Her er et eksempel på en veldig enkel "push"-pipeline der et kildesystem skriver direkte til BigQuery:

Example BigQuery push pipeline

  1. Kildesystemet skriver kontinuerlig data til BigQuery-tabellen raw.trafficdata
  2. En scheduled query transformerer og merger data i standardisert form inn i tabellen standardized.trafficdata

Merk at selv om denne arkitekturen ved første øyekast ser mye enklere ut enn "pull"-pipelinen, så er mye av kompleksiteten og ansvaret flyttet til kildesystemet; det blir opp til dette å sørge for at data blir sendt på riktig tid og i riktig format.

Sparring om arkitektur​

Om du er usikker på hvordan du bør bygge din pipeline kan Yggdrasil bistå med rådgiving. Ta kontakt på #saga-support om du ønsker dette.