Spørsmål og svar

Hvordan finner jeg et Google-prosjekt sin prosjekt-ID?

Prosjekt-ID-en til et Google-prosjekt er en unik identifikator som brukes til å identifisere prosjektet i Google Cloud Platform. Prosjekt-ID-en er en streng som består av små bokstaver, tall og bindestrek. Prosjekt-ID-en er ikke det samme som prosjektnavnet, som kan inneholde store bokstaver og mellomrom.

Du finner prosjekt-ID ved logge deg inn på GCC, åpne prosjektvelgeren, søk opp ditt prosjekt, og så ser du det i høyre kolonne, slik som vist i denne sladdete kolonnen i Figur 1.

Bilde som viser prosjektvelgeren i Google Cloud Console
Figur 1: Prosjektvelgeren i Google Cloud Console

Hvordan får jeg slettet et GitHub-repo under statisticsnorway?

Hovedregelen er at vi arkiverer repoer istedenfor å slette. Det skyldes at vi kan trenge å ettergå historikken i repoer ved et senere tidspunkt. Arkivering av repoer kan du gjøre selv under Settings i repoet.

I de tilfellene der du mener at det gir mest mening å slette repoet, så må dette gjøres av en Github-administrator. Da sender du en henvendelse til Kundeservice og ber om at repoet slettes. Husk å oppgi navnet på repoet du ønsker å få slettet.

Hvordan løser jeg feilmeldinger knyttet til at data rate exceeded i Jupyter?

Når du mottar følgende melding i Jupyter:

Feilmelding:

IOPub data rate exceeded.
The Jupyter server will temporarily stop sending output
to the client in order to avoid crashing it.
To change this limit, set the config variable
`--ServerApp.iopub_data_rate_limit`.

Current values:
ServerApp.iopub_data_rate_limit=1000000.0 (bytes/sec)
ServerApp.rate_limit_window=3.0 (secs)

betyr det at mengden data som sendes fra jupyter-kernelen til jupyterlab-frontend overskrider den tillatte grensen. Selv om det er mulig å justere ServerApp.iopub_data_rate_limit og ServerApp.rate_limit_window for å endre denne grensen, ønsker vi ikke dette. Å endre disse verdiene kan ha en negativ påvirkning på Jupyterlab sin ytelse.

Her er noen løsningsforslag:

  1. Reduser datamengden: Prøv å redusere datamengden du prøver å vise. Hvis du for eksempel viser en stor pandas dataframe, kan du vise kun toppradene med df.head() eller et tilfeldig utvalg med df.sample(10).
  2. Legg til forsinkelse: Bruk time.sleep()-funksjonen i Python for å legge til en pause mellom hver utskrift. Dette kan spre utdataene over en lengre tidsperiode, noe som kan hjelpe med å unngå å overskride datagrensen.
  3. Skriv til en fil: I stedet for å skrive utdata direkte i Jupyter, kan du vurdere å skrive dataene til en fil. Dette omgår IOPub-datahastighetsgrensen, og du kan se gjennom dataene i ettertid.
  4. Unngå utskrift: Hvis du kun trenger å utføre beregninger eller operasjoner på dataene, vurder å gjøre det uten å skrive ut resultatene i Jupyter.

Hvordan kan jeg gjenopprette filer fra bøtter?

Bøttene som opprettes i featuren dapla-buckets1 har en Retention policy som gjør at slettede eller overskrevne objekter kan gjenskapes i en viss periode.

I dapla-buckets blir overskrevne og slettede filer noncurrent. En noncurrent versjon blir slettet hvis den er mer enn 180 dager gammel og det er minst 2+ eller 3+ nyere versjoner i bøtta.2

Alle dapla-teamene har objektversjon aktivert som standard på alle bøtter.

Hvis bøttene ikke er opprettet gjennom featuren dapla-buckets, men kanskje av et ekspertteam eller ekspertteam, så må man først forhøre seg med teamet om versjonering er skrudd på for bøtta. Hvis den ikke er det så blir kun soft-deleted filer tatt vare på i 7 dager.

For å gjennopprette en non-current eller soft-deleted versjon så benytte funksjonalitet fra dapla-toolbelt. For å gjenskape en versjon så må man først bruke funksjonen get_versions() liste ut ID-en til versjonen:

notebook
from dapla import FileClient

# Set bucket name and folder name(if any)
bucket = "ssb-dapla-felles-data-produkt-prod" 
folder = "restore"

FileClient.get_versions(bucket, folder)

Output

[<Blob: ssb-dapla-felles-data-produkt-prod, restore/data1.parquet, 1717762669778835>,
 <Blob: ssb-dapla-felles-data-produkt-prod, restore/data1.parquet, 1718015249969499>,
 <Blob: ssb-dapla-felles-data-produkt-prod, restore/data2.parquet, 1717762673242818>,
 <Blob: ssb-dapla-felles-data-produkt-prod, restore/data3.parquet, 1717762677832930>]

Fra output over ser vi filen data1.parquet finnes i 2 versjoner. Vi kan undersøke den nærmere med følgende kode:

notebook
files = FileClient.get_versions("ssb-dapla-felles-data-produkt-prod", "restore/data1.parquet")

for file in files:
    print("Name          : ",file.name)
    print("Generation Id : ", file.generation)
    print("Updated on    : ", file.updated)
    print("Deleted on    : ", file.time_deleted)
    print("------------------------------------------")

Output

Name          :  restore/data1.parquet
Generation Id :  1718436304922143
Updated on    :  2024-06-15 07:25:04.928000+00:00
Deleted on    :  2024-06-24 11:10:10.807000+00:00
------------------------------------------
Name          :  restore/data1.parquet
Generation Id :  1719227410801992
Updated on    :  2024-06-24 11:10:10.807000+00:00
Deleted on    :  None
------------------------------------------

Av output over ser vi at det er en fil som som har en verdi i Deleted on feltet og som kan gjenskapes. Ønsker vi å gjenskape versjonen ved å bruke restore_version()og referere til Generation ID:

notebook
FileClient.restore_version( source_bucket_name="ssb-dapla-kildomaten-data-delt-test",
                            source_file_name="restore/data3.parquet",
                            source_generation_id=1718436304922143,
                            new_name="" (optional)
                           )

Over har vi gjenopprettet en tidligere versjon av fil. Dette betyr at det nå er en ny Live-versjon av filen, og at den som tidligere var Live har blitt non-current. Ved gjenoppretting av non-current-versjoner så kan man også spesifisere nytt navn på filen med parameteret new_name= i restore_version()-funksjonen.

Man kan liste ut Live, non-current og soft-deleted versjoner fra GCC, som vist i Figur 2. Men man har ikke tilgang til Object details og kan derfor ikke hente ut ID-en til versjonen. Til dette må man benytte dapla-toolbelt fra Dapla Lab.

Bilde av hvordan man velger versjoner i GCC.
Figur 2: Hvordan liste ut versjoner fra GCC.

Hvordan sjekker jeg om Kildomaten er tilgjengelig for mitt team?

Du kan sjekke om teamet ditt har tilgang til Kildomaten ved å gå inn i teamets IaC-repo. Du finner IaC-repoet ved å søke etter team-navnet på statisticsnorway på Github. Repoet er det som heter <teamnavn>-iac. Inne i repoet går du inn filen infra/projects.yaml.

I eksemplet til høyre ser vi hvordan filen ser ut for det fiktive teamet dapla-example. For dette teamet ser vi at Kildomaten er skrudd på i prod-miljøet til teamet, men ikke test-miljøet.

dapla-example-iac/infra/projects.yaml
team_uniform_name: dapla-example

projects:
  - project_name: dapla-example
    env: test
    features:
      - dapla-buckets

  - project_name: dapla-example
    env: prod
    features:
      - dapla-buckets
      - transfer-service
      - kildomaten

Hvordan kan jeg se innholdet i mitt team sine bøtter?

For å se innholdet i ditt teams sine bøtter kan du enten gjøre dette med kode fra Jupyter, eller via Google Cloud Console (GCC). Les mer om hvordan man kan benytte GCC i SSB.

Husk at det er kun data-admins som skal kunne se innhold i kildeprosjektet til teamet. For å gjøre det må de aktivere en tilgang i JIT-applikasjonen.

Atlantis feiler når jeg skrur på en feature. Hva gjør jeg?

Når man skrur på en feature på Dapla, så er det verktøyet Atlantis som ruller ut infrastrukturen på GCP. I mange tilfeller kan det hjelpe å skrive atlantis plan i kommentarfeltet til PR’en, slik at Atlantis får kjørt planen en gang til. Hvis den da ikke viser noen feil, så kan du skrive atlantis apply i kommentarfeltet og endringene vil bli effektuert. Får du fortsatt feilmeldinger etter å ha kjørt atlantis plan på nytt, så bør du kontakte Kundeservice for hjelp.

Jeg får meldingen Account already exists når jeg prøver å logge meg inn på Dapla. Hvordan løser jeg det?

Det hender at man får melding om at Account already exists når man logger seg inn på en Dapla-tjeneste. For å løse dette gjør man følgende:

  1. Velg Add to existing account som vist i Figur 3.
  2. Velg Google slik som vist i Figur 4.

I Figur 4 skal du IKKE fylle inn Username or email og Password. Du skal kun trykke på Google-knappen.

Meldingen om at Account already exists forekommer svært sjelden, og typisk skjer det første gang man logger seg inn på en tjeneste.

Figur 3
Figur 4

Hvorfor viser git status endringer når jeg ikke har endret filene?

Dette kan noen ganger forekomme med notebooks eller ipynb-filer fordi de inneholder metadata som kan bli endret over tid. Siden ipynb-filer er et json-basert format, som inkluderer metadata som oppdaterer seg i bakgrunnen, så kan en endring i strukturen til metadataene føre til endringer i den underliggende json-fila selv om man ikke har gjort endringer i ipynb-fila. Endringene blir deretter plukket opp av git som følger med på endringer i filene.

En mulig løsning er å sjekke inn endringene i kodebasen.

I noen tilfeller viser git status at det har skjedd endringer i filer, men git diff viser ingen endring. I disse tilfellene kan det være ulike problemer i bakgrunnen. Se denne oversikten over problemer og tilhørende løsninger.

Fotnoter

  1. Featuren dapla-buckets inkluderer produkt- og kildebøtta i henholdsvis standard- og kildeprosjektet som de fleste statistikkproduserende team får ved opprettelse.↩︎

  2. I produktbøtta blir noncurrent versjoner slettet hvis det er mer enn 2 nyere versjoner, mens for kildebøtta er grensen på 3 nyere versjoner↩︎