Hvordan gjøre spørringer i GraphiQL

I motsetning til tradisjonelle REST-API-er, der serveren bestemmer hva du får i retur, spesifiserer du i GraphQL nøyaktig hvilke felter du vil ha ved hjelp av klammeparenteser { ... }. Du skriver spørringen i redigeringsfeltet i midten og trykker på «Play»-knappen for å kjøre den.

I venstremenyen finner du dokumentasjonen (Documentation Explorer / Docs), som lister opp alle tilgjengelige spørringer og informasjonsfelter du kan hente ut. Et godt tips er å bruke hurtigtasten Ctrl + Space inne i klammeparentesene – da får du opp en autofullføringsliste med gyldige felter på det aktuelle nivået.

Under viser vi noen vanlige spørringer som kan være nyttige for flere.

Hente ut oversikt over alle Dapla-team

For å hente ut en liste over team bruker vi feltet teams. Siden API-et støtter paginering, bruker vi argumentet first for å angi hvor mange resultater vi ønsker i retur.

I eksempelet under henter vi de to første teamene (first: 2), inkludert teamets kortnavn (slug), visningsnavn (displayName), samt hvilken seksjon teamet tilhører:

{
  teams(first: 2) {
    nodes {
      slug
      displayName
      section {
        name
        code
      }
    }
  }
}

Hente ut informasjon om et team

Dersom du bare ønsker informasjon om et spesifikt team, bruker du feltet team (i entall) og oppgir teamets kortnavn via argumentet slug.

I dette eksempelet henter vi detaljer for teamet play-obr, inkludert visningsnavn, autonominivå(isManaged), samt seksjonstilhørighet og navnet på seksjonssjefen:

{
  team(slug: "play-obr") {
    slug
    displayName
    isManaged
    section {
      name
      code
      manager {
        name
      }
    }
  }
}

Hente ut epostadresser til medlemmer av et team

For å se hvem som er tilknyttet et bestemt team, legger vi til feltet members. Siden listen over medlemmer også støtter paginering, bruker vi first: 10 sammen med nodes.

Hver node representerer en kobling til et medlem, der selve brukerdetaljene ligger under objektet user. Her henter vi ut navn og e-postadresse:

{
  team(slug: "play-obr") {
    slug
    displayName
    isManaged
    members(first: 10) {
      nodes {
        user {
          name
          email
        }
      }
    }
    section {
      name
      code
      manager {
        name
      }
    }
  }
}

Hente ut alle delte bøtter til et team

Hvis du vil se hvilke deltebøtter et team har opprettet, bruker du feltet sharedBuckets.

Under nodes kan du hente ut detaljer som det fulle bøttenavnet (name), kortnavn (shortName) og bøttetype/kategori (kind):

{
  team(slug: "play-obr") {
    slug
    displayName
    sharedBuckets {
      nodes {
        name
        shortName
        kind
      }
    }
  }
}

Hente ut epost til alle som har tilgang til en deltbøtte

Når du skal kontakte alle som har tilgang til en bestemt deltbøtte, så kan du gjøre et direkte oppslag på bøttenivå ved hjelp av feltet sharedBucket og bøttas fulle navn (name) for å hente ut epostadressene til alle som har tilgang.

Under feltet users henter du ut alle personer med tilgang via nodes. Her får du både brukerinformasjonen (name, email, jobTitle) og hvilket team tilgangen er forankret gjennom (team { slug }):

{
  sharedBucket(name: "ssb-play-obr-data-delt-delomatentest-prod") {
    name
    users {
      nodes {
        team {
          slug
        }
        user {
          name
          email
          jobTitle
        }
      }
    }
  }
}

Hvem er rammet?

De alle fleste blir ikke rammet av denne endringen. Tech Coachene har sjekket Github Actions workflower i standard stat-repoene, og de er ikke påvirket. Det kan hende noen ekspertteam som har særegen oppsett blir rammet.

De som kan være rammet: - Bruker GITHUB_TOKEN til autentisering i Workflow - Utfører operasjoner som trenger rettigheter utover les - Har ikke satt rettighetene de trenger/bruker i Github Actions workflowen eksplisitt

Når skal det skje?

Innstramming av rettigheten vil utføres onsdag 3. juni 2026 kl 09

Dersom jeg er rammet, hvordan fikser jeg problemene?

I utgangspunktet er det bare å sette rettighetene i Workflowen eksplisitt. F.eks

permissions:
  contents: write

Mer informasjon

• https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
• https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
• Ta kontakt med en Tech Coach eller Tech Lead forum om du har spørsmål eller utfordringer knyttet til endringen

Hva er SSB Guardian Client?

ssb-guardian-client er et klientbibliotek som integrerer sømløst med Maskinporten via Guardian-tjenesten i Dapla. Den håndterer automatisk henting av Maskinporten-tokens og forenkler kommunikasjon med eksterne API-er som krever Maskinporten-autentisering.

Installasjon

Du kan installere ssb-guardian-client via pip fra PyPI:

pip install ssb-guardian-client

Eller med Poetry:

poetry add ssb-guardian-client

Krav

For å bruke ssb-guardian-client trenger du:

• Python 3.10 eller høyere
• Tilgang til Dapla-plattformen
• Gyldige Maskinporten-klientopplysninger
• Miljøvariabelen DAPLA_ENVIRONMENT satt til: DEV, TEST, eller PROD

Grunnleggende bruk

from ssb_guardian_client import GuardianClient

# Opprett en GuardianClient-instans
client = GuardianClient()

# Hent et Maskinporten-token for egendefinert bruk
# Scopes kan sendes som enten en liste eller mellomromseparert streng
maskinporten_token = client.get_maskinporten_token(
    maskinporten_client_id="your-client-id",
    scopes=["scope1", "scope2"]  # Liste av scopes
)

# Eller med mellomromseparert streng:
maskinporten_token = client.get_maskinporten_token(
    maskinporten_client_id="your-client-id",
    scopes="scope1 scope2"  # Mellomromseparert streng
)

# Bruk tokenet for egendefinerte API-kall
import requests
response = requests.get(
    "https://api.example.com/data",
    headers={"Authorization": f"Bearer {maskinporten_token}"}
)

from ssb_guardian_client import GuardianClient

# Opprett en GuardianClient-instans
client = GuardianClient()

# Kall et eksternt API med Maskinporten-autentisering
response = client.call_api(
    api_endpoint_url="https://api.example.com/data",
    maskinporten_client_id="your-maskinporten-client-id",
    scopes="scope1 scope2",  # Mellomromseparert streng
)

# Responsen inneholder JSON-data fra API-et
print(response)

Komplett eksempel

Her er et komplett eksempel som viser typisk bruk:

import os
from ssb_guardian_client import GuardianClient

# Sørg for at miljøet er satt (vanligvis allerede satt i Dapla notebooks)
# os.environ["DAPLA_ENVIRONMENT"] = "TEST"

# Opprett en GuardianClient-instans
client = GuardianClient()

try:
    # Kall et eksternt API
    response = client.call_api(
        api_endpoint_url="https://api.external-service.no/v1/data",
        maskinporten_client_id="my-maskinporten-client",
        scopes="nav:some/scope nav:another/scope",
    )

    # Behandle responsen
    for item in response.get("data", []):
        print(f"- {item['name']}: {item['value']}")

except RuntimeError as e:
    print(f"API-kall feilet: {e}")

API-oversikt

client = GuardianClient()

Nyttige bruksområder

from ssb_guardian_client import GuardianClient

client = GuardianClient()

# Hent data fra Elhub
response = client.call_api(
    api_endpoint_url="https://api.elhub.no/data",
    maskinporten_client_id="elhub-client-id",
    scopes="elhub:publicstakeholder"
)

# Behandle dataene
data = response.get("results", [])
print(f"Hentet {len(data)} records")

# Kall NAV API
nav_response = client.call_api(
    api_endpoint_url="https://api.nav.no/v1/statistics",
    maskinporten_client_id="nav-maskinporten-client",
    scopes="nav:statistics/read nav:data/access"
)

# Prosesser NAV-data
statistics = nav_response.get("statistics", {})

Feilsøking

Ressurser

• Dokumentasjon: https://statisticsnorway.github.io/ssb-guardian-client
• Kildekode: https://github.com/statisticsnorway/ssb-guardian-client
• PyPI: https://pypi.org/project/ssb-guardian-client/
• Rapporter problemer: GitHub Issues

Oppsummering

ssb-guardian-client gjør det enkelt å:

• Kommunisere sikkert med eksterne API-er via Maskinporten
• Håndtere Maskinporten-autentisering uten kompleks token-administrasjon
• Arbeide på tvers av ulike miljøer (DEV, TEST, PROD)
• Integrere med Dapla-plattformen uten manuell autentisering

Prøv ssb-guardian-client neste gang du trenger å kalle eksterne API-er med Maskinporten-autentisering!

Hva er SSB Collector Client?

ssb-collector-client er en klientbibliotek som gir enkel tilgang til Data Collector-tjenesten i Dapla. Den håndterer autentisering automatisk via dapla-auth-client og tilbyr en intuitiv API for å jobbe med innsamlingsoppgaver.

Installasjon

Du kan installere ssb-collector-client via pip fra PyPI:

pip install ssb-collector-client

Eller med Poetry:

poetry add ssb-collector-client

Krav

For å bruke ssb-collector-client trenger du:

• Python 3.10 eller høyere
• Tilgang til en Data Collector-tjeneste
• Dapla-autentisering (håndteres automatisk)

Grunnleggende bruk

from ssb_collector_client import CollectorClient

# Initialiser klienten med URL-en til collector-tjenesten
client = CollectorClient("https://your-collector-service.no/tasks")

# Definer spesifikasjonen for innsamlingsoppgaven
specification = None

# Load specification from file
with open("<specification_file>.json") as specification_file:
    specification = json.load(specification_file)

# Start en ny oppgave
response = client.start(specification)
print(f"Task started: {response.status_code}")

# Hent alle kjørende oppgaver
tasks = client.running_tasks()
print(f"Running tasks: {tasks.json()}")

# Stopp en spesifikk oppgave ved ID
client.stop(task_id=1234)

from ssb_collector_client import CollectorClient

# Initialiser klienten
collector_url = "https://your-collector-service.no/tasks"
client = CollectorClient(collector_url)

# Definer spesifikasjonen for innsamlingen
specification = None

# Load specification from file
with open("<specification_file>.json") as specification_file:
    specification = json.load(specification_file)

# Start en ny innsamlingsoppgave
print("Starter innsamlingsoppgave...")
start_response = client.start(specification)

if start_response.status_code == 200:
    print("✓ Oppgaven ble startet vellykket")
else:
    print(f"✗ Feil ved start: {start_response.status_code}")

# Sjekk kjørende oppgaver
print("\nHenter kjørende oppgaver...")
tasks_response = client.running_tasks()
tasks = tasks_response.json()

for task in tasks:
    print(f"- Task ID: {task['id']}, Status: {task['status']}")

# Stopp en oppgave om nødvendig
if tasks:
    task_id = tasks[0]['id']  # Bruk faktisk task ID
    print(f"\nStopper oppgave {task_id}...")
    stop_response = client.stop(task_id)
    
    if stop_response.status_code == 200:
        print("✓ Oppgaven ble stoppet")
    else:
        print(f"✗ Kunne ikke stoppe oppgaven: {stop_response.status_code}")

API-oversikt

client = CollectorClient(base_url)

Autentisering

ssb-collector-client bruker dapla-auth-client for automatisk autentisering. Du trenger ikke å håndtere tokens manuelt - klienten tar seg av alt dette i bakgrunnen.

Nyttige bruksområder

# Sett opp daglig innsamling
specification = None

# Load specification from file
with open("<specification_file>.json") as specification_file:
    specification = json.load(specification_file)

client.start(specification)

# Sjekk status på alle oppgaver
tasks = client.running_tasks().json()

for task in tasks:
    if task['status'] == 'failed':
        print(f"Oppgave {task['id']} har feilet!")
        # Send varsling eller restart oppgaven

Ressurser

• Dokumentasjon: https://statisticsnorway.github.io/ssb-collector-client
• Kildekode: https://github.com/statisticsnorway/ssb-collector-client
• PyPI: https://pypi.org/project/ssb-collector-client/
• Rapporter problemer: GitHub Issues

Oppsummering

ssb-collector-client gjør det enkelt å:

• Administrere datainnsamlingsoppgaver programmatisk
• Automatisere periodisk datainnsamling
• Overvåke og kontrollere kjørende oppgaver
• Integrere med Dapla-plattformen uten manuell autentisering

Prøv ssb-collector-client i ditt neste datainnsamlingsprosjekt!

Hvorfor separere autentisering?

1. Redusere avhengigheter
   Mange brukere trenger kun autentiseringsbiten for å hente tokens til Google Cloud eller Keycloak. Tidligere måtte man installere og importere hele dapla-toolbelt, selv om man bare trengte én liten del. Ved å splitte ut en egen pakke blir installasjonen lettere og mer strømlinjeformet:

    [project]
    dependencies = [
        "dapla-auth-client >=1.0.0",
    ]

2. Modularitet og enklere vedlikehold
   Ved å holde autentiseringsflyten adskilt fra resten av dapla-toolbelt, kan vi lansere feilfikser og nye funksjoner for OAuth2/Keycloak uten å påvirke de andre modulene.

3. Lettvektskode for sluttbruker
   Å importere dapla-toolbelt dro med seg en rekke avhengigheter. Med dapla-auth-client får man kun det som trengs for autentisering, og slipper unødvendige pakker.

4. Skalerbarhet for fremtidige utvidelser
   En dedikert autentiseringspakke gir oss frihet til å legge til flere Identity Providers eller nye token-flows senere uten å måtte endre i dapla-toolbelt.

Overgang fra gammelt til nytt bruk

from google.cloud import storage
from dapla import AuthClient

storage_client = storage.Client(
    credentials=AuthClient.fetch_google_credentials()
)

from google.cloud import storage

storage_client = storage.Client()

Installere og ta i bruk dapla-auth-client

1. Installer pakken

poetry add dapla-auth-client

2. Bytt import

Dersom du tidligere importerte slik:

from dapla import AuthClient

bytter du til:

from dapla_auth_client import AuthClient

3. Fjern eksplisitte kall til Google‐credentials

Bytt ut:

storage_client = storage.Client(
    credentials=AuthClient.fetch_google_credentials()
)

med:

storage_client = storage.Client()

For funksjonen fetch_personal_token() for Keycloak i Dapla Lab, importerer du tilsvarende fra dapla_auth_client, men API-et er identisk:

from dapla_auth_client import AuthClient

token = AuthClient.fetch_personal_token()

De deprecated-metodene (fetch_google_credentials(), fetch_google_token(), osv.) vil fortsatt være tilgjengelige i dapla-auth-client en stund til, men gir advarsler ved bruk og fjernes i kommende versjoner. Vi anbefaler å migrere til ADC-mønsteret så snart som mulig.

For dere som bruker dapla-toolbelt og ikke har behov for å bruke AuthClient direkte, er det eneste dere trenger å gjøre å oppgradere dapla-toolbelt til nyeste versjon. Vi tar oss av alt det tekniske i bakgrunnen, slik at overgangen blir sømløs for dere.

Oppsummering

Ved å skille autentiseringsklassen ut i dapla-auth-client:

• Får brukerne en lettere installasjon når de kun trenger autentisering.
• Unngår man unødvendige avhengigheter fra dapla-toolbelt.
• Gjør vi koden mer modulær og enkel å vedlikeholde.
• Kan man bruke standard storage.Client() eller lignende funksjoner for Google Cloud, uten å tenke på credentials-henting.

Lykke til med migreringen!

1 Finn fram Vardok-ID

Alle seksjonsledere har fått tilsendt en oversikt over hvilke variabeldefinisjoner i Vardok som din seksjon er ansvarlig for. I oversikten finner man også ID-ene til variabeldefinisjonene, og man må vite Vardok-ID’en til variabeldefinisjonen man skal migrere før man begynner.

2 Avgjør eierskap

Diskuter før migreringen hvilket Dapla-team på seksjonen som skal “eie” variabeldefinisjonen. Det er kun ett team som kan være ansvarlig, og man definerer hvilket team det skal være når man velger team og tilgangsgruppe ved oppstart av Vardef-forvaltning (forklart i neste steg).

3 Starte Vardef-forvaltning

Selve migreringen gjøres fra en tjeneste som heter Vardef-forvaltning i Dapla Lab. Ønsker man å teste litt hvordan systemet fungerer uten fare for å gjøre noe galt, så kan man åpne tjenesten i test-miljøet på Dapla Lab: https://lab.dapla-test.ssb.no/. Her jobber man mot en test-versjon av Vardef-basen som blir slettet med jevne mellomrom, og ingen informasjon blir eksponert for eksterne. Ønsker man å migrere “på ekte”, så logger seg man inn i prodmiljøet: https://lab.dapla.ssb.no/.

4 Selve migrering

Inne tjenesten Vardef-forvaltning så ligger det ferdige notebooks for vanlige arbeidsflyter i Vardef. For å migrere fra Vardok til Vardef så åpner du notebooken migrerer_variabeldefinisjoner.ipynb under mappen ./variable_definitions/.

For å migrere variabeldefinisjonen med ID’en 10 i Vardok, så gjør du følgende:

1. Kjør første kodecelle
2. I andre kodecelle så fyller du inn Vardok-ID i variabelen min_id_liste. Under har jeg fylt inn 10:

Notebook

min_id_liste = [10]
print(f"✅ {len(min_id_liste)} vil bli migrert")

3. Deretter kjører du cellen.
4. Når du kjører den neste cellen så skjer selve migreringen. Hvis den vellykket så får du følgende beskjed i notebooken: INFO: ✅ Successfully migrated variable definition 'wkapinnt' with ID 'LlT6N-cz', bare at kortnavn og ID er unikt for din variabel. VIKTIG: Husk kortnavnet siden du trenger det i neste steg.

Og med det så er variabelen migrert fra Vardok til Vardef. Variabeldefinisjonen har nå fått utledet alle informasjon automatisk som er mulig å utlede, og resten må brukeren fylle inn selv. Husk at definisjonen nå er lagret i databasen til Vardef, men med status UTKAST. Dvs. at man kan endre på all informasjon og den er ikke publisert enda. For å publisere må man redigere innholdet i utkastet, og deretter kjøre en annen notebook som gjør selve publiseringen. Dette er forklart under.

5 Rediger innhold

For å redigere innholdet i et utkast i Vardef så kan man kjøre notebooken rediger_utkast_variabeldefinisjon.ipynb. Da gjør man følgende:

1. Åpne notebooken rediger_utkast_variabeldefinisjon.ipynb
2. Kjør gjennom de to første cellene og skriv inn kortnavnet til den migrerte variabelen (ble printet ut når du migrerte).
3. Etter kjøringen over ble det skrevet en yaml-fil med innholdet i variabeldefinisjonen. Her kan du gjøre endringer direkte i fila.
4. Når du er ferdig med å gjøre endringer så kan du kjøre den siste kodecellen for å lagre arbeidet ditt i et nytt utkast. Husk at du bør lagre ofte og man kan redigere utkast så mange ganger man vil.

Når en variabeldefinisjon er migrert fra Vardok til et utkast i Vardef, så kan man begynne å redigere innholdet. Det er obligatorisk å gå gjennom all informasjon og kvalitetssikre innholdet. Hvis det er behov for å avklare innholdet med andre i SSB, så skal dette gjøres før den publiseres. Når en variabel først er publsiert eksternt i Vardef så kan den ikke endres, kun opprette nye gyldighetsperioder eller gjøre mindre endringer.

6 Publiser

Når man er ferdig med redigere innholdet i variabeldefinisjonen og har publisert det til utkast, så kan man bruke notebooks til å publisere internt (publiser_variabeldefinisjon_internt.ipynb), eller publisere eksternt (publiser_variabeldefinisjon_eksternt.ipynb).

🥳Gratulerer! Du har nå migrert en variabeldefinisjon fra Vardok til Vardef.

Hvorfor analysere deltbøtter?

Analyse av deltbøtter gir innsikt i hvordan team deler og bruker data. Dette kan avdekke forbedringsmuligheter og bidra til å finne enklere måter å dele data på. Når en datakatalog er på plass, vil vi få enda bedre forståelse av effekten av datadeling. Denne innsikten gir oss mulighet til å justere prosessene våre og styrke samarbeidet mellom team.

Hvordan fungerer løsningen?

Løsningen visualiserer hvordan data deles mellom team gjennom deltbøtter. Den benytter Dapla Team-API for å hente informasjon om delingsforhold og eierskap. Dataene behandles og presenteres i en interaktiv graf som lar brukerne utforske relasjonene mellom team og deltbøtter.

Visualiseringen fokuserer på deltbøtter og gir et målrettet innblikk i delingsforholdene mellom team. Dette hjelper oss med å identifisere mønstre og muligheter for forbedring.

I grafen representerer:

• Gule noder: Deltbøtter, som fungerer som delingspunkter for data.
• Blå noder: Team, som enten eier eller bruker data fra deltbøtter.
• Grønne linjer: Eierforhold mellom team og deltbøtter.
• Røde linjer: Delingsforhold mellom team.

Brukere kan filtrere visualiseringen basert på team, deltbøtter, avdelinger og seksjoner for å fokusere på spesifikke områder. Dette gjør det enklere å analysere delingsforhold og identifisere forbedringsområder.

Hvordan data deles som grafer

Data visualiseres som grafer for å gi en intuitiv forståelse av relasjonene mellom team og deltbøtter. Grafene består av:

• Noder: Representerer team eller deltbøtter.
• Relasjoner: Viser sammenhenger mellom noder, som eierskap eller deling av data.

Denne tilnærmingen gjør det enklere å identifisere mønstre, som hvilke team som deler mest data, eller hvilke deltbøtter som er mest sentrale i delingsnettverket. Interaktive grafer gir brukerne bedre innsikt i delingsprosessene.

Tilgang til løsningen

Løsningen er tilgjengelig her: Interaktiv visualisering av bøtter og team. Du må ha en GitHub-bruker for å se den.

Last ned rådata

For egne analyser kan du laste ned rådataene som brukes i visualiseringen her: Last ned rådata.

GitHub Repository

For mer informasjon: ssb-dapla-bucket-analysis.

Oppdateringer og spørsmål

Si gjerne ifra om det er noen ønsker eller spørsmål til løsningen. Den er laget ganske raskt og oppdateres med nye data ved (u)jevne mellomrom.

Hvorfor bruke funksjoner?

Profesjonell kode, bortsett fra i skript, skrives nesten utelukkende innenfor funksjoner¹ og klasser. Noen av årsakene til dette er:

• Gjenbruk: Ting som gjøres flere ganger bør skilles ut til funksjoner for å unngå duplisert kode. Da kan retting og forbedring gjøres ett sted, i stedet for flere steder.

• Muliggjør automatisert testing: Kode utenfor funksjoner er det vanskelig å lage automatiserte tester for. Kode du ønsker å teste automatisk bør derfor ligge i funksjoner. På sikt bør vi erstatte mest mulig av manuell testing med automatiske tester.

• Enklere å forstå og forklare: Når koden er organisert i små funksjoner med tydelige navn, blir det lettere for deg og kollegaene dine å forstå hva koden gjør, og hver bit blir mindre kompleks. Tenk på funksjoner som «byggeklosser»: én funksjon gjør én ting, og navnet på funksjonen forteller tydelig hva denne tingen er. Det blir som å skrive en god innholdsfortegnelse i et dokument, slik at du raskt ser hva hvert avsnitt handler om.

• Automatisert kjøring av mange notebooks: Bygger du opp koden din med funksjoner så kan du automatisere kjøring av alt sammen, uten å bruke Papermill, som har problemer med ytelse.

Hvordan endre fra “vanlig” notebook til bruk av funksjoner?

KVAKK har laget en beskrivelse som viser hvordan du kan gå fra en “vanlig” notebook, hvor koden kjøres fra topp til bunn, uten bruk av funksjoner, og automatisert ved bruk av Papermill, og til en tilsvarende notebook med bruk av funksjoner.

Se Hvordan automatisere Jupyter notebooks ved bruk av funksjoner.

Verktøy for å sjekke funksjonsbruk

Tech-coachene på seksjon IT-partner har laget et skript, analyze_function_use.py, du kan bruke til å sjekke hvor mye bruk av funksjoner det er i python-koden i et repo. Det gir deg andelen av koden som ligger utenfor funksjoner, samt antall funksjoner.

Skriptet har ingen avhengigheter, så du kan kjøre det uten å installere noe ekstra.

Skriptet analyserer python-filer i et clonet GitHub-repo. For hver fil teller den opp antall kodelinjer som er innenfor en funksjonsblokk (eller metode, som er det navnet som brukes på funksjoner som hører til en klasse), og også totalt antall kodelinjer i filen. Dette summerer den for alle filer i repoet og beregner andelen av koden som er utenfor funksjonsblokker. Den dropper blanke linjer, kommentarer og filer som ligger tests-katalogen. I tillegg teller den opp antall funksjoner i repoet.

Eksempler

Et par eksempler på statistikk-repoer som er gode til å bruke funksjoner er stat-bygganlprod og stat-mnd-el på seksjon 422. Ta gjerne en titt på disse. Den første har kun 4 % av koden utenfor funksjoner og er liten, mens den andre har 634 funksjoner og er en større statistikk.

Ta gjerne også en titt på tech-coach-stat-repoet, som er en eksempelstatistikk som tech-coach’ene har begynt på, og som viser mye god kodepraksis.

Overblikk over prosessen.

I prosessen er det en del overføringer som må settes opp, men de kjøres automatisk når det først er i gang. Stegene vi skal gjennom er:

1. Transfer service fra datamottak til din kildebøtte
2. Kildomaten
3. Transfer service fra din produktbøtte til frasky-bøtten
4. Transfer service fra din frasky-bøtte til bakken.
5. Opprette mappestruktur på stammen
6. MoveIT og lasting til ISEE

Testløpet krever at du gjør alle stegene dobbelt opp. Én gang for prod, én gang for test. Det er viktig å ikke blande disse løpene i hverandre, og at filstiene viser til en prod-mappe eller test-mappe. Se flytdiagrammet nedenfor for konkrete filstier.

Transfer service fra datamottak til din kildebøtte.

Det første du skal gjøre er å sette opp transfer service fra datamottaket til din kildebøtte. Du kommer til å være godt kjent med å sette opp transfer service når vi er ferdige med dette, og det er en del detaljer som må stemme. Så det er bare å holde hodet kaldt, dobbeltsjekke at alt stemmer, prøve seg frem og be om hjelp hvis du står fast.

Siden det første steget involverer kildebøtta så trenger du å være data-admin på teamet ditt (du kan sjekke rollene dine i dapla ctrl) og søke om midlertidig tilgang via just in time (JIT) tjenesten.

For å komme seg til vinduet hvor du kan sette opp en transfer service går du først inn på denne lenken: https://console.cloud.google.com/

Deretter skal du klikke på en knapp øverst i skjermbildet på venstre side, til høyre for GoogleCloud logoen og få opp menyen hvor du velger hvilket prosjekt du skal jobbe med

Her skal du velge ditt team, du kan se teamnavnet i dapla-ctrl. Du skal inn på prosjektet som har ditt-teamnavn-kilde-p i navnet sitt. Hvis du ikke ser prosjektet ditt, sjekk at du har valgt ssb.no som organisasjon under “Select a resource”.

Når du er inne på prosjektet ditt kan du klikke i søkefeltet på toppen av siden, søke på “Storage transfer” og velge den.

Nå skal vi inn på “Transfer jobs” og klikke på “CREATE TRANSFER JOB”.

Noter deg hvordan du fant denne menyen, for litt senere i prosessen skal vi inn på et annet prosjekt og sette opp flere transfer jobs.

Datamottaket ligger i team SUV sitt dapla team som heter “suv-altinn-data-p”, og du kan finne skjemaene i bøtter med navnestrukturen ssb-suv-altinn-raXXXX-01-prod. Merk at 01 viser til versjonen av skjema, så hvis du får en ny versjon av skjemaet ditt vil den ha et annet versjonsnummer.

Hagebruksundersøkelsen har RA-nummeret 0571, så datamottaket sitt bøttenavn vil i dette tilfellet være ssb-suv-altinn-ra0571-01-prod.

Mappestrukturen i datamottaket er slik at det først er en mappe for året skjemaet ble mottatt, deretter for måneden, deretter for dagen, og her finner du hver enkelt innsending. I transfer job henviser vi bare til den øverste mappen, den fører automatisk med seg alt som ligger lenger “nede” i mappestrukturen.

Se på bildene for å se hvordan filstier og innstillingene for jobben skal se ut.

Det er lurt å skrive tydelig i “Description” feltet før du trykker “CREATE” hvilken undersøkelse det gjelder og hva transfer jobben gjør. Det sparer andre i teamet (og deg selv) forvirring senere.

Et lite tips er å la denne jobben kjøre ofte, siden det vil gjøre at skjemaene behandles fortløpende i kildomaten istedenfor å komme i store overføringer. Andre overføringer trenger ikke kjøre mer enn en gang om dagen.

I denne jobben skal ikke filer slettes.

Kildomaten

Nå skal vi gå løs på den mest tekniske delen av oppsettet. Her blir det nok mye prøving og feiling for å få alt til å fungere, så ikke mist motet.

Kildomaten er en tjeneste som automatiserer bearbeiding av data som kommer inn i kildebøtta. Etter at den er satt opp så vil den automatisk bearbeide filer som havner i mappen den er stilt inn til å følge med på. Den vil enkelt forklart bearbeide hvert enkelt skjema hver for seg, og sende videre til produkt bøtta.

For mer informasjon om kildomaten kan du se veiledning for kildomaten her.

I første omgang holder vi det enkelt og setter opp rammen som vi senere skal fylle ut.

De to filene nedenfor skal opprettes og plasseres i mappen dapla-team-iac/automation/source-data/dapla-team-prod/hagebruk/

config.yaml

folder_prefix: hagebruk/altinn
memory_size: 1

process_source_data.py

import dapla as dp
from altinn import isee_transform, create_isee_filename

tags = ["SkjemaData", "Kontakt", "Brukeropplevelse"]

mapping = {
    "Altinn3 navn": "ISEE navn"
}

def main(source_file):
    if source_file.endswith(".xml"):
        fil = isee_transform(source_file, mapping, tag_list=tags) # transformerer XML'ene fra kildedatabøtta til pandas dataframe med riktig ISEE-feltnavn
        fil["FELTNAVN"] = fil["FELTNAVN"].str[:25].str.upper()
        if "altinn/test/" in source_file:
            dp.write_pandas(df = fil, gcs_path = f"ssb-primaer-j-skjema-data-produkt-prod/hagebruk/temp/test/altinn/{create_isee_filename(source_file)}", file_format="csv", index=False, sep=";")
        elif "altinn/prod/" in source_file:
            dp.write_pandas(df = fil, gcs_path = f"ssb-primaer-j-skjema-data-produkt-prod/hagebruk/inndata/altinn/{create_isee_filename(source_file)}", file_format="csv", index=False, sep=";")
        else: 
            raise ValueError (f'source_filen sitt navn inneholder verken altinn/test/ eller altinn/prod/: {source_file}')

Filstiene i process_source_data.py må du endre nå, mappingen kan du utsette til du er ferdig med å sette opp resten av overføringene.

Det er vanskelig å sjekke om mappingen din stemmer uten å ha forsøkt innlasting til ISEE, så det kan være greit å ordne resten av løpet først.

Mapping brukes for å omkode nytt variabelnavn fra Altinn 3 til ISEE feltnavn og er nødvendig for at dataene dine skal bli synlige i ISEE.

Det er viktig at filen som lages av kildomaten ikke har feltnavn som er lengre enn 25 tegn, er en csv fil og at det er semikolon som er skilletegnet. Dette er tatt høyde for i malen over.

Transfer service fra din produkt bøtte til frasky bøtten

Her skal vi starte med å flytte filene som kildomaten vår lager til bakken. Før filene kan sendes til bakken, så skal de innom frasky-bøtta. Det betyr at flyttingen ned til bakken involverer to transfer jobs.

Disse jobbene trenger ikke kjøre mer enn én gang om dagen, men pass på at jobben som flytter fra produkt til frasky kjører før jobben som flytter filer til bakken. Hva du kan sette på tidspunkt er vist på “Choose when to run job” bildene for hver jobb.

Først skal du skifte hvilket prosjekt du jobber i. Nå skal vi være i teamet som heter ditt-teamnavn-p, altså det som ikke har kilde i navnet sitt. I dette eksempelet er riktig team primaer-j-skjema-p.

Deretter skal transfer jobs settes opp på samme måte, se på skjermbildene for å se hvordan det skal se ut.

OBS! Det er viktig at filene slettes fra kilden etter flytting. Hvis det ikke slettes, så overføres samme skjema flere ganger og skaper enormt mange dubletter i ISEE.

Transfer service fra din frasky bøtte til bakken

I dette steget skal du fortsatt være i “ditt-teamnavn-p” prosjektet.

Nå flytter vi filene ned til bakken. Måten mottaket på bakken er lagt opp er at det finnes en mappe på linux for ditt dapla team under området cloud_sync.

Det vil ha filstien cloud_sync/team-navn/…

OBS! Det er viktig at filene slettes fra kilden etter flytting. Hvis det ikke slettes, så overføres samme skjema flere ganger og skaper enormt mange dubletter i ISEE.

Måten du skal sette opp transfer service kan du se her:

Når du har satt opp transfer service så skal du ned på bakken og opprette noen mapper på linux. Samme sted som stammene ligger så finnes også et område som heter cloud_sync, det er dit vi skal nå.

Ditt dapla team vil ha en egen mappe i cloud_sync som du skal finne.

Opprette mappestruktur på stammen

MoveIT og lasting til ISEE

Nå som vi har satt opp mappestrukturene som trengs så har vi en positiv overraskelse, det neste steget er enkelt for deg som statistikkansvarlig.

Først skal du opprette skjemaet i SFU og ISEE. Det skal hete RA-XXXXA3, hvor XXXX er ditt RA-nummer.

Deretter skal du sende en mail til kundeservice. I den skal du: - si at du trenger en MoveIt overføring fra cloudsync/standard/undersøkelse/altinn/prod/ og til din stamme sin wk24/datafangst/gSdv/ mappe. - at du trenger opplasting fra datafangst/gSdv mappen din til ISEE.

Du kan ta utgangspunkt i malen nedenfor. Hvis du ikke setter opp test-løpet så kan du fjerne de bitene.

Hei!

Trenger to moveit jobber og innlasting til ISEE fra stammen.

Jeg skal overføre RA-XXXXA3 til ISEE, delregisternummer 123456

MoveIt som flytter fra: /ssb/cloud_sync/primaer-j-skjema/standard/frasky/hagebruk/test/altinn/ Til: /ssb/stamme02/jordbruk/sbhagebruk/test/wk24/datafangst/gSdv

Test jobben burde kjøre 20 minutter over hver time så det rekker å bli med på lastingen til DB1T.

MoveIt som flytter fra: /ssb/cloud_sync/primaer-j-skjema/standard/frasky/hagebruk/prod/altinn/ Til: /ssb/stamme02/jordbruk/sbhagebruk/wk24/datafangst/gSdv

Begge MoveIt jobbene må slette filer fra cloud_sync når det er flyttet.

Trenger også at det opprettes lastejobb fra wk24 og test/wk24 til DB1P og DB1T.

OBS! Det er viktig at filene slettes fra kilden etter flytting. Hvis det ikke slettes, så overføres samme skjema flere ganger og skaper enormt mange dubletter i ISEE.

Når disse jobbene er satt opp så får du data inn i ISEE!

Prosessen er satt opp, hva nå?

Du burde nå få data lastet inn i tabellene ISEE er bygd på, som er et godt stykke men likevel er det en del jobb igjen.

Det er mange detaljer som skal stemme for at dataene som lastes inn skal dukke opp riktig i ISEE. Hvis mappingen ikke stemmer så vil ikke dataene dine bli synlige i ISEE, selv om de er lastet inn i systemet.

Du må sjekke at kodelister eksisterer for variablene dine, at disse matcher variabelverdiene som kommer fra Altinn 3 og at eventuelle endringer i Altinn 3 skjemaet er hensyntatt i skjemavisningen i ISEE. Ved behov kan du opprette nye kodelister som passer Altinn 3 dataene dine i klass-forvaltning.

Vær oppmerksom på at ofte vil noen kodelister som benyttes i Altinn 3 skjemaet skille seg fra det som ble brukt i altinn2, som vil kreve noen endringer i skjemabyggeren.

Det er mulig å abonnere på rapporter fra ISEE hvis du går inn på Administrasjon -> Oversikt datafangst -> Datafangstrapporter -> Legg inn epostadressen din.

Du kan også få varsler om noe skulle gå galt underveis i lastingen til ISEE.

Her er det noen ressurser som kan være til hjelp med å ferdigstille opplegget ditt:

Dokumentasjon for ssb-altinn-python pakken:

• https://statistics-norway.atlassian.net/wiki/spaces/altinnpython/overview
• https://statisticsnorway.github.io/ssb-altinn-python/

ISEE dokumentasjon:

• https://statistics-norway.atlassian.net/wiki/spaces/ISEE/pages/3958932070/Brukerdokumentasjon

Bruksområde

Bruksområdet for denne funksjonaliteten er å utforske Parquet-filer og ikke prosessere data i produksjon. Selv om man kan skrive ut et filtrert datasett med løsningen, så skal det ikke benyttes til prosessering som skal være reproduserbar siden det ikke dokumenteres med kode.

Skrive SQL

SQL-en som skrives må være duckdbsql siden det er dette extension’en benytter for å hente informasjon fra Parquet-filen.

Import og testdata

Først importerer vi noen biblioteker som vi skal benytte. For å benytte Pandera pakken må det lastes inn til ett virtuelt miljø, som vi i SSB benytter ssb-project for;

terminal

poetry add pandera

Versjonen av Pandera som benyttes i introduksjonen her er 0.20.4. Følgende pakker får jeg importert deretter;

import uuid
from typing import Dict
import pandas as pd
import numpy as np
import pandera as pan
from pandera.typing import DataFrame, Series
from pandera.errors import SchemaErrors

Jeg lager også følgende lekedata vi skal ta for oss i eksemplene;

size = 6

random_data = pd.DataFrame({
    "id_nr": [str(uuid.uuid4()) for _ in range(size)],
    "lope_id_nr": ["L" + str(1).zfill(4) for _ in range(size)],
    "aar": np.random.choice(['2023', '2024'], size),
    "navn": np.random.choice(['Ola', 'Kari', 'Per', 'Ida'], size),
    "produkt": np.random.choice(['Eple', 'Gulrot', 'Brokkoli'], size),
    "salgsverdi": np.random.randint(1000, 10000, size),
    "vekt": np.random.randint(500, 5000, size)
})

random_data['kostverdi'] = (
    random_data['salgsverdi'] * 0.75
).astype(int)

bad_data = pd.DataFrame({
    "id_nr": ["random-id1", "random-id1", "random-id2",
              "random-id2", "random-id3"],
    "lope_id_nr": ["L0001", "L0002", "L0001", "L0001", "0001"],
    "aar": ['2023', '2023', '2024', '2024', '2024Q1'],
    "navn": ['Ola', 'Ola', 'Per', 'Kari', None],
    "produkt": ['Banan', 'Eple', 'Eple', 'Agurk', 'Eple'],
    "salgsverdi": [5000, 4000, 7000, 3000, 50],
    "vekt": [700, 600, 700, 100, 5],
    "kostverdi": [3500, 2500, 5000, 3100, 55],
})

data = pd.concat([random_data, bad_data], ignore_index=True)
data

Dataframen består av følgende kolonner:

• id_nr: identifiseringsnummer
• lope_nr_id: et slags løpenummerid
• aar: perioden i år for gjeldende rad
• navn: navn på enheten (person eller kunde)
• produkt: produktet det gjelder - la oss si i en frukt og grønt butikk
• salgsverdi: sluttverdien varen ble solgt for
• vekt: sluttvekten som ble solgt
• kostverdi: kostnaden tilknyttet innkjøp av produktet eller varen.

Det er elementer her som ikke nødvendigvis er fullt realistist med virkeligheten, men sammensetningen av disse kolonnene er mest bygd opp for å demonstrere mulighetene og fleksibiliteten ved bruk av pandera.

Grunnleggende bruk - schema

For å ta i bruk pandera må vi definere et schema. Schemaer definerer hvordan dataene forventes at skal se ut, spesielt når det kommer til datatyper.

Med pandera kan du validere både datatyper og innhold. Det er flere måter å definere ett schema på, men jeg kommer til å vise den anbefalte måten å gjøre det på. Den er ikke nødvendigvis den enkleste, men den er enkel nok, og har likheter til Pydantic.

Et schema i pandera defineres som følgende;

class SchemaValidation1(pan.DataFrameModel):
    
    id_nr: Series[str] = pan.Field(unique=True)
    lope_id_nr: Series[str] = pan.Field(
        str_startswith='L',
        str_length={'min_value': 5,
                    'max_value': 5}
    )
    aar: Series[str] = pan.Field(
        str_length={'min_value': 4,
                    'max_value': 4}
    )
    navn: Series[str] = pan.Field(
        nullable=False # Default
    )
    produkt: Series[str] = pan.Field(
        isin=['Eple', 'Banan', 'Gulrot', 'Brokkoli']
    )
    salgsverdi: Series[int] = pan.Field(ge=1000)
    vekt: Series[int] = pan.Field(ge=500)
    kostverdi: Series[int] = pan.Field(gt=700)

Så hva er det vi har definert her?

Vi har nå definert et eget Objekt, en class, kalt SchemaValidation1, som arver egenskapene til Pandera sitt objekt DataFrameModel. Mer avansert fra objekt og class verden trenger du ikke å gjøre eller kunne her egentlig, så ikke bli skremt med det første. Deretter definerer vi kolonnene som vi forventer i dette schemaet. Pandera er bygget på typing systemet til Python vel og merke, som enkelt forklart vil si at jeg kan bruke typing-pakkens objekter i definisjonen som han vil bruke til å validere for, men det gir også muligheten til å benytte pythons standardobjekter som str og int i definisjonen. Vi har også definert regler tilknyttet hver av disse kolonnene som da vil bli validert sammen med datatypene.

• id_nr er en Serie (kolonner i pandas dataframe er av datatypen pandas serie) med forventet datatype string (str). Regler som er satt er at innholdet er unikt, altså ingen duplikater i de verdiene som ligger i kolonnen.
• lope_id_nr er også forventet datatype string. Den har 2 regler; at alle verdier starter med ‘L’, og at teksten er minimum og maksimum 5 karakterer lang.
• aar er forventet å være string, med regel om at den er 4 tegn lang.
• navn er forventet å være string, med regel om at det ikke skal være noen manglende verdier (missing values). Dette er standard for alle regler, så det er ikke nødvendig å notere, men for demonstrasjonens skyld så gjorde jeg det her.
• produkt er forventet å være string, med regler om at innholdet er blant verdiene i en gitt liste. I dette tilfellet Eple, Banan, Gulrot, Brokkoli. Kanskje er dette varene butikken selger og har i sortimentet sitt.
• salgsverdi er forventet å være en integer (int). Regel som er satt her er at verdiene er større eller lik 1000.
• vekt er forventet å være en integer. Regel som er satt her er at verdiene er større eller lik 500.
• kostverdi er forventet å være en integer. Regel som er satt her er at verdiene er større enn 700.

Okei, da har vi definert schemaet. Vi skal bygge videre på dette snart. Det finnes mange flere innebygde valideringsregler enn de vi benytter her, og man må inn i dokumentasjonen til Pandera for å se om noe kan passe deg og ditt behov der, men her demonstrerer vi hvertfall noen som sikkert kommer til å bli brukt.

For å utføre valideringen gjør vi følgende;

try:
    valresult = SchemaValidation1.validate(data, lazy=True)
except SchemaErrors as error:
    # Rapport av feil utslag i dataframe
    valresult = error.failure_cases
    # Dataframe som ble sendt inn
    errdata = error.data
    # Antall feil utslag
    num_errors = error.error_counts
    # Rapportmeilding av feil utslag i dict
    error_message = error.message

valresult

Objektet SchemaValidation1 har en metode validate som vi kan sende inn dataframen som skal valideres opp mot schemaet(som vi arvet fra pandera DataFrameModel objektet). Jeg har satt lazy til True her fordi jeg vil at han skal validere alt og ikke stoppe ved første feil han finner. Dersom valideringen feiler har pandera et error objekt SchemaErrors hvor flere nyttige rapporter blir lagd tilgjengelig for oss. Du kan selv legge med flere av dem, men her tar vi for oss dataframen med alle feilmeldingene som dukker opp. Dersom valideringen gikk bra vil du få dataframen du sendte inn i retur.

Rapporten vi har fått ut nå i dataframen valresult har vi flere utslag på. Kolonnen id_nr finnes det duplikater blant annet. Kolonnen lope_id_nr er det funnes en som har slått ut i begge definerte reglene som nevnt tidligere. osv, osv. Denne rapporten har vi kanskje et potensial for å utnytte videre? Men det får være opp til den enkelte.

Behov for flere kontroller

Dersom de innebygde mulighetene for validering ikke strekker til kan man definere reglene selv ved å definere egne metoder med tilhørende decorator (alfakrøll over metoden). Under her definerer jeg SchemaValidation2 som sett bort ifra de nye metodene er nesten helt identisk med SchemaValidation1. Forskjellen er at nå har kolonnen id_nr kun regelen om at den skal ikke ha manglende verdier i stedet for at det skal unike verdier.

class SchemaValidation2(pan.DataFrameModel):
    
    id_nr: Series[str] = pan.Field(nullable=False) # Default
    lope_id_nr: Series[str] = pan.Field(
        str_startswith='L',
        str_length={'min_value': 5,
                    'max_value': 5}
    )
    aar: Series[str] = pan.Field(
        str_length={'min_value': 4,
                    'max_value': 4}
    )
    navn: Series[str] = pan.Field(nullable=False) # Default
    produkt: Series[str] = pan.Field(
        isin=['Eple', 'Banan', 'Gulrot', 'Brokkoli']
    )
    salgsverdi: Series[int] = pan.Field(ge=1000)
    vekt: Series[int] = pan.Field(ge=500)
    kostverdi: Series[int] = pan.Field(gt=700)

    # Sjekke at kolonne aar er tekst med tall i seg
    @pan.check("aar",
               # Valgfritt, men gir eget navn til regelen enn metodenavnet
               name="str_isdigits",
               # Valgfritt, men her kan man styre feilmeldingen
               error="str_not_digits")
    def check_isdigits(cls, s: Series[str]) -> Series[bool]:
        return s.str.isdigit()

    # En metode kan sjekke flere kolonner,
    # her sjekker vi både kostverdi og salgsverdi.
    # Validerer at Bananer har både høyere
    # salgsverdi og kostverdi enn Epler
    @pan.check("kostverdi", "salgsverdi",
               groupby="produkt",
               name="check_epler_bananer")
    def check_groupby(cls, grouped_value: Dict[str, Series[int]]) -> bool:
        return grouped_value["Eple"].sum() < grouped_value["Banan"].sum()

    # Trenger du å sjekke mer enn bare en kolonne av gangen?
    # f.eks. at forholde mellom flere kolonner
    # har en bestemt regel å følge?
    # Her sjekkes at kombinasjonen for kolonnene
    # id_nr og lope_id_nr er unike
    @pan.dataframe_check
    def unique_combo_idnr_lopeidnr(cls, df: pd.DataFrame) -> Series[bool]:
        df2 = df.copy()
        df3 = (
            df2
            .groupby(['id_nr', 'lope_id_nr'])
            .agg({'aar': 'count'})
            .rename(columns={'aar': 'duplikater'}) == 1
        ).reset_index()
        df2 = df2.merge(df3,
                        on=['id_nr', 'lope_id_nr'],
                        how='left')
        return df2['duplikater']

Schemaet SchemaValidation2 har som vi ser nå 3 metoder;

• check_isdigits som sjekker at teksten faktisk kun inneholder tall. Her sjekkes kun kolonnen aar.

• check_groupby som grupperer verdiene i kolonnen produkt. Det sjekkes her for kolonnene kostverdi og salgsverdi. Den sjekker at summen av bananer er høyere enn summen av epler (for å gjøre noe enkelt og irrelevant).

• de 2 første sjekkene kan kun jobbe med en kolonne av gangen, ev. en groupby på en annen kolonne med fokus på de gjeldende kolonnene en har tenkt å sjekke for. Den tredje siste sjekken er litt annerledes, for de andre sjekkene har benyttet decoratoren check, mens den siste har dataframe_check. Dette vil si at hele dataframen sendes inn, og her vil du ha full fleksibilitet til å sjekke det du måtte ønske på tvers av alle kolonner. Viktigste er at det returneres en serie(kolonne) av boolske verdier (True/False). I denne siste sjekken unique_combo_idnr_lopeidnr sjekkes det at kombinasjonen av kolonnene id_nr og lope_id_nr er unike i dataframen.

Igjen kan dataene valideres;

try:
    valresult = SchemaValidation2.validate(data, lazy=True)
except SchemaErrors as error:
    valresult = error.failure_cases

valresult

Desverre vil sjekker som gjelder hele dataframen registrere flere feil ettersom han sjekker alle kolonner for gjeldende rader. Derimot er fleksibiliteten ganske stor!

Bruk av validering i funksjonene

Over til et eksempel hvor pandera viser seg som veldig nyttig! La oss si at vi har klargjorte data klart, ihht. datatilstandene, og vi er da klare for å lage statistikkdata. Det er ikke gitt at løpet er helt rett fram mellom disse datatilstandene, men i dette eksempelet er jobben bare å få aggregert klargjorte data.

Nedenfor her lager jeg klargjorte data av de dataene som vi har jobbet med, og som er korrekte. Lager et tilhørende skjema, som bare arver fra det første schemaet vi lagde. Valideringen her vil selvsagt gå smertefritt igjennom.

klargjort_df = data.head(6)


class KlargjortSchema(SchemaValidation1):
    pass


try:
    klargjort_df = KlargjortSchema.validate(klargjort_df, lazy=True)
except SchemaErrors as error:
    valresult = error.failure_cases
    raise error

klargjort_df

Deretter definerer vi et eget schema for statistikkdata, med noen tilhørende regler og datatyper;

class StatistikkSchema(pan.DataFrameModel):
    
    aar: Series[pd.CategoricalDtype] = pan.Field(
        coerce=True, # Vil konvertere datatypene for meg
        str_length={'min_value': 4,
                    'max_value': 4})
    produkt: Series[pd.CategoricalDtype] = pan.Field(
        coerce=True, # Vil konvertere datatypene for meg
        isin=['Eple', 'Banan', 'Gulrot', 'Brokkoli'])
    salgsverdi: Series[int] = pan.Field(ge=0)

Så over til magien; Pandera schemaene kan innlemmes i hvilken som helst funksjon som har dataframes som input eller output, og det uten at du selv skriver at valideringen skal skje i funksjonen, det skjer automagisk! Og det gjøres som følgende;

# Lazy for at valideringen skal utføres igjennom hele dataframene
@pan.check_types(lazy=True)
def agg_statistikk(
    df: DataFrame[KlargjortSchema]
) -> DataFrame[StatistikkSchema]:
    dff = (
        df
        .copy()
        .groupby(['aar', 'produkt'], as_index=False)
        .agg({'salgsverdi': 'sum'})
    )
    return dff

Så nå ved å bruke funksjonen, vil du ikke få lagd statistikkdata uten at både klargjorte data blir validert og godkjent, og at statistikkdata som er på vei ut av funksjonen er validert og godkjent. I vårt tilfelle skal det gå fint nå;

statistikk_df = agg_statistikk(klargjort_df)
statistikk_df

Man skal også kunne validere flere schemaer samtidig også hvis en ønsker det. Altså at input til funksjonen sjekkes opp mot flere schema samtidig, eller at output blir det. Det er ikke blitt demonstrert her.

Med det samme kan vi sjekke datatypene, vi hadde satt at Pandera skulle endre datatypene for oss. Både før og etter;

from IPython.display import HTML, display

kdf = pd.DataFrame(klargjort_df.dtypes, columns=['Datatyper'])
sdf = pd.DataFrame(statistikk_df.dtypes, columns=['Datatyper'])

# Style dataframes
styled_df1 = kdf.style.set_caption("Klargjorte-data")
styled_df2 = sdf.style.set_caption("Statistikk data")

display(HTML(
f"""
<div style="display: flex; justify-content: space-around;">
<div>{styled_df1.to_html()}</div>
<div>{styled_df2.to_html()}</div>
</div>
"""
))

BONUS: Auto-transformasjon av kolonneverdier

Pandera har noe som kalles parsers, som gir oss muligheten til å utføre preprosesseringer på dataene før validering. Dette kan være flere typer transformasjoner som man bør sørge for er gjort før valideringen utføres, ev. om transformasjonen bare skal gjennomføres.

La oss ta et eksempel med en liten del av dataene vi har jobbet med til nå, da med data vi vet det ikke skal bli noe problemer med;

data['dekningsbidrag'] = data['salgsverdi'] - data['kostverdi']

df = data.head(3).copy()
df

Jeg beregner her dekningsbidraget for hver observasjon, som da er differansen mellom salgsverdi og kostverdi. Det er mer eller mindre en funksjon som avhenger av disse to variablene, og må holdes oppdatert.

Og la oss nå si at kostverdien på første observasjonen ikke skulle være på 75 % av salgsverdi slik vi startet med, men av en eller annen grunn heller skulle være på 85 %. Vi kan editere det inn;

df.loc[0, ['kostverdi']] = int(round(
    df.iloc[0]['salgsverdi'] * 0.85, 0)
                              )

df

Så nå har vi fått korrigert kostverdien på første observasjon, men dekningsbidraget er fortsatt den samme. Dette kan løses som en egen funksjon, men hvorfor ikke innlemme det i data valideringen vår, da pandera støtter slik transformering. Vi lager først et tilhørende schema;

class ParserSchema(SchemaValidation1):
    dekningsbidrag: Series[int]

    @pan.check("navn")
    def is_uppercase(cls, s: Series[str]) -> Series[bool]:
        return s.str.isupper()

    # konverterer all tekst i kolonnen til å ha kun store bokstaver
    @pan.parser("navn")
    def uppercase(cls, s: Series[str]) -> Series[str]:
        return s.str.upper()

    # Sørger for at dekningsbidrag blir rekalkulert
    @pan.dataframe_parser
    def kalkuler_dekningsbidrag(cls, df: pd.DataFrame) -> pd.DataFrame:
        df['dekningsbidrag'] = df['salgsverdi'] - df['kostverdi']
        return df

Så her tar jeg i bruk det aller første schema som vi definerte, men legger på dekningsbidrag som ikke har noen andre valideringer enn datatype. Med dataene vi har nå skal det ikke dukke opp noen feil med dette. Jeg legger ved en valideringsregel for navn i dette tilfelle, hvor nå alt i kolonnen navn skal være store bokstaver. Vi vet allerede at det ikke er noen store bokstaver der, så vi legger inn en metode som har decorator parser som vil transformere dette. I tillegg legger vi til en egen metode med decorator dataframe_parser for å rekalkulere dekningsbidraget.

Så sånn sett skulle man kanskje tro at valideringen av kolonnen navn vil kunne slå ut i valideringen, men som nevnt så kjøres transformasjonene først før valideringen. I tillegg, når valideringen går igjennom, vil du få dataframen du sendte inn i retur ved utførelsen av valideringen;

try:
    valresult = ParserSchema.validate(df, lazy=True)
except SchemaErrors as error:
    valresult = error.failure_cases

valresult

Som vi nå ser har valideringen gått fint for seg. Vi ser at alle verdier i kolonnen navn har blitt tekst med kun store bokstaver, og vi ser at dekningsbidraget har blitt rekalkulert så det nå er korrekt!

Oppsummering

For at vi skal kunne produsere og levere statistikk av høy kvalitet er det viktig at vi validerer data løpende i produksjonsløpene våre. Store deler av dataene våre er strukturerte, ev. tidy om du vil, og da er python pakken Pandera en sterk kandidat å benytte inn i kodene våre. Hvertfall hvis du programmerer i Python. For R så er pakken Validate aktuell. Her har vi introdusert generell bruk av Pandera for validering av data; hvordan definere schema og valideringsregler, hvordan validere en dataframe med det, og hvordan det kan tas i bruk i blant annet funksjoner. Trenger du hjelp til å implementere data validering med Pandera inn i koden din, så er Støtteteamene mulig å spørre, ellers kommer man ikke unna dokumentasjonen til Pandera selv.

Hvorfor Lonboard?

Geopandas’ explore-metode og explore-funksjonen i ssb-sgis-pakken bruker kartvisningsbiblioteket Folium. Hver gang et kart skal vises med Folium, blir kartdataene konvertert til GeoJSON-formatet, som deretter sendes ukomprimert fra Jupyter-serveren til nettleseren. Dette kan føre til lang overføringstid og potensielt høyt minneforbruk i nettleseren, spesielt når man forsøker å vise store datasett, som landsdekkende grunnkretser, tettsteder eller postnummerområder.

Lonboard håndterer store datamengder bedre ved å overføre data mellom serveren og nettleseren i Parquet-format i stedet for GeoJSON, som så leses av Deck.gl. Siden Parquet tilfeldigvis er SSBs standard lagringsformat, kan denne overføringen skje med minimal datakonvertering.

Ikke alle i SSB jobber med Pandas, og for disse brukerne kan Lonboard visualisere tabeller fra DuckDB og PyArrow, i tillegg til Geopandas-tabeller.

Hvor kommer Anywidget inn? Anywidget er et rammeverk for å lage widgets. En widgets lar ta med interaktive komponenter inn i en Jupyter notebook, slik som en datovelger eller en filtrerbar og sorterbar tabell. Litt slik som Dash lar deg gjøre, men rett i Jupyter notebook. Å lage sin egen widget til Juypter er en ganske komplisert afære. Det krever at du pakker både Python kode og Javascript kode. Det krever at du må skrive kode for å støtte alle miljøer som kan kjøre Jupyter notbooks, slik som VScode, Jupyterlab eller Google Colab. Anywidget forenkler prosessen veldig, og sørger for at widget din virker på alle plattformer. Den forenkler kommunikasjonen mellom Python og Javascript siden, så det blir enklere å lage interaktivitet.

Anywidget er nå installert i Jupyter på Dapla Lab, slik at alle kan prøve ut både Lonboard, samt andre pakker som bygger på Anywidget. Et eksempel på en slik annen pakke er Vega-altair

Eksempel med grunnkretser i Innlandet fylke

Under er eksempel på hvordan man visualisere grunnkretsene i Innlandet fylke i en Jupyterlab Notebook på Dapla Lab. Gjør følgende først:

1. Start en Jupyter på Dapla Lab.
2. Opprett et ssb-project
3. Installer nødvendige pakker poetry add geopandas lonboard numpy mapclassify matplotlib libpysal
4. Åpne en ny notebook med kernelen som ble opprettet av ssb-project.

I den nyopprettede notebooken kan deretter hente inn data om grunngretser i Innlandet fylke og visualisere de med Lonboard.

import geopandas as gpd
import lonboard
from lonboard import basemap
from mapclassify import greedy
from matplotlib import colormaps
import numpy as np

grunnkretser = gpd.read_file(
    "https://nedlasting.geonorge.no/geonorge/Basisdata/Grunnkretser/GML/Basisdata_34_Innlandet_25833_Grunnkretser_GML.zip",
    layer="Grunnkrets",
    engine="pyogrio",
    columns=["grunnkretsnummer", "grunnkretsnavn", "kommunenummer"],
)

grunnkretser.head()

color = greedy(grunnkretser, strategy="balanced", balance="centroid").map(
    colormaps["Set2"].colors.__getitem__
)
color = (np.stack(color.to_numpy()) * 255).astype(np.uint8)

grunnkretser_wgs84 = grunnkretser.to_crs(4326)
layer = lonboard.PolygonLayer.from_geopandas(
    grunnkretser_wgs84,
    opacity=0.2,
    line_miter_limit=1,
    line_width_units = "pixels",
    get_fill_color=color,
    get_line_color=[255,255,255],
    auto_highlight=True,
)

kart = lonboard.Map(
    [layer],
    basemap_style=basemap.CartoBasemap.DarkMatterNoLabels,
    _height=500,
)

kart

Lonboard har i motsetning til Folium muligheten for interaktivitet. Hvis du velger en avgrensningsboks i kartet over, men knappen oppe i høyre hjørne, så blir det utvalet tilgjengleig i Python som kart.selected_bounds

if kart.selected_bounds:
    xmin, ymin, xmax, ymax = kart.selected_bounds
    utvalg = grunnkretser_wgs84.cx[xmin:xmax, ymin:ymax]
    print(f"Det er {len(utvalg)} grunnkretser i utvalget")
else:
  print("Du har ikke gjort et utvalg.")

Du kan også utvikle din egen widget, men selvom Anywidget forenkler prossessen mye, krever dette fremdeles ferdigheter i både Python og Javascript, så det er kansje ikke for alle.

Importere

Først så importerer vi noen biblioteker som vi skal benytte. Du kan benytte standard-kernelen som heter python3, for der er biblioteket som pseudonymiserer, dapla-toolbelt-pseudo, tilgjengelig.

import json

import dapla as dp
import pandas as pd
from dapla_pseudo import Depseudonymize, Pseudonymize
from dapla_pseudo.constants import MapFailureStrategy
from dapla_pseudo.utils import convert_to_date
from IPython.display import JSON

Versjonen av dapla-toolbelt-pseudo er 2.1.2.

Dataene vi skal bruke syntetiske fødselsnummer fra testversjonen SNR-katalogen. På den måten får vi også testet pseudonymiseringen via SNR-katalogen som er veldig vanlig i SSB. Denne SNR-katalogen ligger som en fil i en bøtte som alle i SSB har tilgang til.

path = "gs://ssb-dapla-felles-data-produkt-test/freg/snr_kat.csv"

df = dp.read_pandas(path, file_format="csv", dtype={"fnr": str, "fnr_date": str})

df.head(n=5).style.set_table_styles([
    {'selector': 'th', 'props': [('text-align', 'left')]}
])

Fra Tabell 1 ser vi at datasettet inkluderer en del kolonner. For utforsking av pseudonymiseringsfunksjonalitet så trenger vi kun fnr-kolonnen.

Forberedelse av datasettet

La oss kun beholde fnr-kolonnen og kopiere den en ny kolonne slik at vi enklere kan sammenligne før og etter pseudonymisering. I tillegg kutter jeg antall rader til 10, siden vi ikke trenger noe mer for formålet her.

df2 = df.head(n=10)
df3 = df2[["fnr"]]
df4 = df3.copy()
df4['fnr_original'] = df4['fnr']

df4.head(n=5).style.set_table_styles([
    {'selector': 'th', 'props': [('text-align', 'left')]}
])

Hvis du ønsker å teste hvordan krypteringsalgoritmene fungerer med kolonner som inneholder navn, så kan vi generere noe data med et også.

fornavn = [
    "Jo",
    "Hans-August",
    "Nils",
    "Eva",
    "Lars",
    "Øyvind",
    "Kenneth",
    "Johnny",
    "Rupinder",
    "Nicolas",
]
etternavn = [
    "Nordman",
    "Karlsen",
    "Nordmann",
    "Karlsen",
    "Carlsen",
    "Nordmann",
    "Carlsen",
    "Nordmann",
    "Karlsen",
    "Normann",
]

df4['fornavn'] = fornavn
df4['etternavn'] = etternavn
df5 = df4.copy()

Til slutt legger vi på noen ugyldige fødselsnummer slik at vi får testet hvordan algoritmene håndterer dette.

new_row1 = pd.DataFrame(
    [
        {
            "fnr": "99999999999",
            "fnr_original": "99999999999",
            "fornavn": "Michael",
            "etternavn": "Norman",
        }
    ]
)
df6 = pd.concat([df5, new_row1], ignore_index=True)

new_row2 = pd.DataFrame(
    [{"fnr": "XX", "fnr_original": "XX", "fornavn": "Ola Glenn", "etternavn": "Gåås"}]
)
df7 = pd.concat([df6, new_row2], ignore_index=True)

new_row3 = pd.DataFrame(
    [
        {
            "fnr": "X8b7k28",
            "fnr_original": "X8b7k28",
            "fornavn": "Lars",
            "etternavn": "Gaas",
        }
    ]
)
df8 = pd.concat([df7, new_row3], ignore_index=True)

df8.head(n=5).style.set_table_styles([
    {'selector': 'th', 'props': [('text-align', 'left')]}
])

Tabell 3 viser datasettet vi skal bruke til å teste med.

Pseudonymisering

Nå kan vi begynne å leke med dataene. Det første vi kan gjøre er å pseudonymisere med den mest vanlige algoritmen som benyttes i produksjon: Papis-nøkkelen.

result = (
    Pseudonymize.from_pandas(df8)
    .on_fields("fnr")
    .with_stable_id()
    .run()
)
result.to_pandas()

Unexpected length of metadata: 2

I Tabell 4 ser vi at kolonnen fnr har blitt pseudonymisert. Det er også verdt å legge merke til at kolonnen ikke endrer navn. Grunnen til at lengden på verdiene som er pseudonymiserte er på 7 tegn for de opprinnelige fødselsnummerne, er at det først skjer en oversetting fra fnr til snr før det pseudonymiseres, og snr-nummerserien er på 7 tegn. Med andre ord så preserverer algoritmen lengden på snr-nummeret siden det er dette som pseudonymiseres.

Det er også verdt å merke seg at verdier som er kortere enn 4 i lengde, f.eks. XX i rad 11, ikke blir pseudonymisert i det hele tatt. Verdier som er 4 eller lengre, vil bli pseudonymisert selv om de ikke fikk treff i SNR-katalogen.

data = json.loads(result.datadoc)
display(data)

{'document_version': '0.0.1',
 'pseudonymization': {'document_version': '0.1.0',
  'pseudo_variables': [{'short_name': 'fnr',
    'data_element_path': 'fnr',
    'data_element_pattern': '/fnr',
    'stable_identifier_type': 'FREG_SNR',
    'stable_identifier_version': '2023-08-31',
    'encryption_algorithm': 'TINK-FPE',
    'encryption_key_reference': 'papis-common-key-1',
    'encryption_algorithm_parameters': [{'keyId': 'papis-common-key-1'},
     {'strategy': 'skip'}]}]}}

display(result.metadata)

{'logs': ['No SID-mapping found for fnr 999********',
  'No SID-mapping found for fnr X8b****'],
 'metrics': {'MAPPED_SID': 10, 'FPE_LIMITATION': 1, 'MISSING_SID': 2}}

Depseudonymisering

La oss ta vare på den pseudonymiserte kolonnen og så depseudonymisere og se om resultatet blir riktig:

result2 = result.to_pandas()
result2['pseudo_fnr'] = result2['fnr']

result_df = (
    Depseudonymize.from_pandas(result2)         
    .on_fields("fnr")                              
    .with_stable_id()                              
    .run()                                         
    .to_pandas() 
)

result_df.style.set_table_styles([
    {'selector': 'th', 'props': [('text-align', 'left')]}
])

Tabell 5 viser at depseudonymiseringen returnerer de opprinnelige fødselsnummerne.

Videre kan man utforske å pseudonymisere navn ved bruk av ulike algoritmer.

Hva er en fastbredde-fil?

En fastbredde-fil er en fil der hver rad har en fast lengde, og hver kolonne har en fast posisjon. Det er ingen komma eller andre tegn som skiller kolonnene, slik som i en CSV-fil. En fastbredde-fil er en ren tekstfil, dvs. at du kan åpne den opp i teksteditor og kikke på innholdet direkte.

Under er et eksempel hvor samme data er lagret både på CSV-formatet og som fastbredde-fil:

csv

012345;;Ola Nordmann;
345678;Kvinne;Kari Nordmann;

fastbredde-fil

012345      Ola Nordmann 
345678KvinneKari Nordmann

I csv-filen over til venstre ser vi at hver kolonne er separert med et semikolon, og at hver rad er separert med et linjeskift. I fastbredde-filen til høyre ser vi at hver kolonne har en fast lengde, den tomme kjønnsvariabelen på rad 1 fylles med spaces, hver rad har dermed den samme lengden i antall tegn. I tillegg er det et ekstra mellomrom etter Ola Nordmann ift. Kari Nordmann. Dette er fordi Ola Nordmann er 12 tegn lang, mens Kari Nordmann er 13 tegn lang.

Lese med Pandas

Vi kan bruke pandas-funksjonen read_fwf() for å lese inn en fastbredde-fil. Denne funksjonen tar inn en filsti, og en liste med bredder for hver kolonne. I tillegg kan vi spesifisere navn på kolonnene, og hvilken datatype kolonnene skal ha og hvordan missing-verdier skal representeres.

Vi er helt avhengig av å vite bredden på hver kolonne for å kunne lese inn en fastbredde-fil. Dette kan vi finne ut ved å åpne filen i en teksteditor og telle/gjette antall tegn i hver kolonne. Alternativt kan vi bruke innlesingsskriptet for SAS som finnes i Datadok, siden breddene er spesifisert der. Under er et ekspempel på hvordan vi kan lese inn en fastbredde-fil fra forrige avsnitt¹:

import pandas as pd
from io import StringIO  # Nødvendig siden vi sender en streng, ikke en filsti til .read_fwf
instring = "112345      Ola Nordmann \n345678KvinneKari Nordmann\n"
df = pd.read_fwf(StringIO(instring),
                 names=['pers_id', 'kjonn', 'navn'],  # Navngi kolonner
                 dtype='object',  # Alle kolonnene settes til "object"
                 na_values=['.', ' .'],  # Hvilke karakterer bruker SAS for tom verdi?
                 widths=[6, 6, 13])  # Tell/regn ut dissa sjøl
df

Koden over returnerer en Pandas Dataframe i minnet. Den kan vi lett lagre til Parquet-formatet. Men innlesingen måtte vi spesifisere en masse detaljer manuelt. Hvis vi skal lese inn mange filer med ulik struktur, så er ikke denne fremgangsmåten skalerbar. Dette er en fremgangsmåte for å lese inn noen få filer.

Datadok

Som nevnt over så finnes det et innlesingsskript for SAS i Datadok. Dette skriptet kan vi bruke til å lese inn en fastbredde-fil i Python. Vi kan også bruke det til å finne breddene på hver kolonne. Et slik skript har denne formen:

innlesingsskript.sas

DATA sas_data;
   INFILE '/ssb/bruker/felles/flatfileksempel_dapla_manual_blogg.dat' MISSOVER PAD LRECL=36;
   INPUT
      @1 pers_id 6.0
      @7 kjonn $CHAR6.0
      @13 navn $CHAR13.0
   ;
RUN;

Vi kunne lest av informasjonen her og omsatt innholdet til argumentene read_fwf() trenger. Men fortsatt innebærer dette potensielt en del manuelt arbeid.

Lese med saspy

En annen tilnærming enn å bruke .read_fwf fra Pandas er å bruke biblioteket saspy. Dette biblioteket lar oss kjøre SAS-kode fra Python, på SAS-serverene i prodsonen, og få Dataframes tilbake. Vi kan bruke det til å kjøre sas-skript hentet fra Datadok, konvertere til en pandas dataframe, og til slutt skrive til Parquet. I det følgende antar vi at du jobber i Jupyterlab i prodsonen (sl-jupyter-p), og at du har lagret innlesingsskriptet i en variabel, slik som vist under:

python

script = """
DATA sas_data;
   INFILE '/ssb/bruker/felles/flatfileksempel_dapla_manual_blogg.dat' MISSOVER PAD LRECL=36;
   INPUT
      @1 pers_id 6.0
      @7 kjonn $CHAR6.0
      @13 navn $CHAR13.0
   ;
RUN;
"""

La oss deretter kjøre følgende kode fra Jupyterlab:

python

from fagfunksjoner import saspy_session

# Kobler til sas-serverne
sas = saspy_session()

# Vi bruker tilkoblingen til å sende inn Datadok-skriptet
result = sas.submit(script)

# Lagre sas-loggen i en variabel
log = result["LOG"]

# Ber om å få dataframe tilbake
df_frasas = sas.sd2df("sas_data", "work")

# Lukker koblingen til sas-serverne
sas._endsas()

# Printer ut datasettet
df_frasas

I koden over har vi brukt en pakke som heter ssb-fagfunksjoner for å opprette koblingen til sas-serveren. Pakken inneholder et overbygg over saspy, og koden over forutsetter at du har lagret passordet ditt på en spesiell måte².

python

df_pd_dtypes = df_frasas.convert_dtypes()
df_pd_dtypes.dtypes

python

from fagfunksjoner import auto_dtype
df_auto = auto_dtype(df_frasas)
df_auto.dtypes

python

sas_script_path = "/ssb/bruker/felles/flatfileksempel_dapla_manual_blogg.sas"
with open(sas_script_path, "r", encoding="latin1") as sas_script:
    script = sas_script.read().strip()
    script = "DATA " + script.split("DATA ")[1] # Forkort ned scriptet til det vi trenger
print(script)

Lagre dataframen til parquet

Nå er det veldig lett å skrive filen til Parquet-formatet.

python

df_auto.to_parquet(
    "/ssb/bruker/felles/flatfileksempel_dapla_manual_blogg.parquet"
    )

NUDB

I omleggingen av NUDB (Nasjonal utdanningsdatabase), måtte vi konvertere hele arkivet vårt på 750+ dat-filer.

Det var ønskelig å slippe å lagre til sas7bdat i mellom, for å slippe mye dataduplikasjon og arbeidsprosesser. Målet vårt var pseudonymiserte parquetfiler i sky.

I stor grad kunne dette arbeidet automatiseres (bortsett fra å lagre ut innlastingsscript fra gamle datadok). Funksjonene jeg utviklet for dette, ligger stort sett i denne filen:
github.com/utd-nudb/prodsone/konverter_arkiv/archive.py

Installasjon

Pakken er avhengig av at Fame er installert miljøet der den benyttes. Siden den er installert på sl-fame-1.ssb.no¹ så vil de færreste har behov for å installere den selv.

Skulle du likevel ønske å installere pakken selv kan det gjøres med Poetry på følgende måte:

terminal

poetry add git+https://github.com/statisticsnorway/ssb-fame-to-python.git

Bruk av funksjonene

fython har to funksjoner: fame_to_csv og fame_to_df. Begge disse funksjonene tar inn de samme argumentene og de er listet opp i Tabell 1.

La se på noen eksempler.

python

from fython import fame_to_pandas

df = fame_to_pandas(
  ['sti/til/database1.db', 'sti/til/database2.db', 'm', '2012:1', '2022:12', '?']
  )

python

from fython import fame_to_pandas

df = fame_to_pandas(
  ['sti/til/database1.db', 'sti/til/database2.db', 'm', '2012:1', '2022:12', 'abc?d^']
  )

python

from fython import fame_to_csv

fame_to_csv(
  ['sti/til/database1.db', 'sti/til/database2.db', 'm', '2012:1', '2022:12', 'abc?d^', 'sti/til/csv-fil.csv']
  )

Kjøringer på serveren

Når du skal bruke fython så må du ta hensyn til hvilken server Fame er installert på, og hvilken server du har tenkt til å jobbe på. Fame er som sagt installert på sl-fame-1.ssb.no, mens Jupyterlab er installert på sl-jupyter-p.ssb.no. Dvs. at hvis du ønsker å bruke fython i en notebook i Jupyterlab, så må du bruke ssh til å koble deg til sl-fame-1.ssb.no, og så kjøre koden derfra. Koden din kan skrive en fil til ønsket stammeområdet, som du igjen kan lese inn direkte i Jupyterlab.

Automatiserte uttrekk

Hvis man ønsker at utrekk fra Fame skal skje automatisk på gitte tidspunkter eller intervaller, så kan man ta kontakt med Kundeservice. Fordelen med dette er at man ikke trenger å bruke ssh slik som beskrevet over. Man kan lese inn direkte fra stammeområdet.

Overføre data til Dapla

Hvis man ønsker å overføre data fra Fame til Dapla, så kan dette settes opp som en MoveIt-operasjon. For å sette opp en MoveIt-jobb må ma kontakte Kundeservice. Overføring til Dapla forutsetter at man har et Dapla-team, og at man setter opp en synkroniseringjobb med Transfer Service.