Jupyter-pyspark
Jupyter-pyspark er en tjeneste på Dapla Lab som lar brukerne kode i Jupyterlab. Tjenesten kommer med Python, Pyspark og noen vanlige Jupyterlab-extensions ferdig installert. Målgruppen for tjenesten er brukere som skal skrive produksjonskode med Pyspark i Jupyterlab.
Siden tjenesten er ment for produksjonskode så er det veldig få Python-pakker som er forhåndsinstallert. Antagelsen er at brukeren/teamet heller bør installere de pakkene de selv trenger, framfor at det ligger ferdiginstallerte pakker som skal dekke behovet til alle brukere/team i SSB. Det reduserer kompleksitet i tjenesten og dermed sannsynligheten for feilsituasjoner.
Forberedelser
Før man starter Jupyter-pyspark bør man ha lest kapitlet om Dapla Lab og satt opp Git- og GitHub-konfigurasjonen under Min konto. Deretter gjør du følgende:
- Logg deg inn på Dapla Lab
- Under Tjenestekatalog trykker du på Start-knappen for Jupyter-pyspark
- Gi tjenesten et navn
- Åpne Jupyter-pyspark konfigurasjoner
Konfigurasjon
Før man åpner en tjeneste kan man konfigurere hvor mye ressurser man ønsker, hvilket team man skal representere, om et GitHub-repo skal klones ved oppstart, og mange andre ting. Valgene man gjør kan også lagres slik at man å slipper å gjøre samme jobb senere. Figur 1 viser Tjeneste-delen i konfigurasjonen for Jupyter hvor man kan velge hvilken versjon av Jupyter man vil bruke.
Data
Under Data-menyen kan man velge hvilket team og tilgangsgruppe man skal representere. Man gjør dette ved å velge navnet på tilgangsgruppen, og denne er alltid på formen <teamnavn>-<tilgangsgruppe>. Figur 2 viser at brukeren har valgt tilgangsgruppen dapla-felles-developers, dvs. at de representerer tilgangsgruppen developers for teamet dapla-felles.
Under Team og tilgangsgruppe kan brukeren også velge å representere tilgangsgruppen data-admins for et team. I de tilfellene er det et krav om brukeren oppgir en skriftlig begrunnelse for hvorfor tilgangen er nødvendig. I tillegg må kan de maksimalt aktivere tilgangen i 8 timer.
Figur 3 viser en bruker som aktiverer sin data-admins tilgang for team dapla-felles. Hvis brukeren ikke oppgir en begrunnelse vil de få en feilmelding ved oppstart av tjenesten.
Git/GitHub
Under menyen Git/GitHub kan man konfigurere Git og GitHub slik at det blir lettere å jobbe med inne i tjenesten. Som standard arves informasjonen som er lagret under Min konto-Git i Dapla Lab. Informasjonen under tjenestekonfigurasjonen blir tilgjengeliggjort som miljøvariabler i tjenesten. Informasjonen blir også lagt i $HOME/.netrc slik at man kan benytte ikke trenger å gjøre noe mer for å jobbe mot GitHub fra tjenesten.
Figur 4 viser at brukeren som standard får aktivert Aktiver Git. Dette innebærer at Git-brukernavn, Git e-post og GitHub-token arves fra brukerkonfigurasjonen. I tillegg så opprettes SSBs standard Git-konfigurasjon i ~/.gitconfig.
Python/R
Under menyen Python/R kan man velge hvilke versjon av R og Python man ønsker å kjøre. Man kan velge mellom alle tidligere tilbudte kombinasjoner av R og Python.
I Figur 5 ser vi av navnet py311-spark3.5.3-v4-2024.11.21 at tjenesten som default vil startes versjon 3.11 av Python og og 3.5.3 av Spark. Etter hvert som nye versjoner av Python og Spark kommer, kan disse tilgjengeliggjøres i tjenesten, men brukeren kan velge å starte en eldre versjon av tjenesten.
Ressurser
Under menyen Resources kan man velge hvor mye CPU og RAM man ønsker i tjenesten, slik som vist i Figur 6. Velg så lite treng for ås gjøre jobben du skal gjøre.
Diskplass
Som default får alle som starter en instans av tjenesten en lokal disk på 10GB inne i tjenesten. Under Diskplass-menyen kan man velge å øke størrelsen på disken eller ikke noe disk i det hele tatt. Siden lokal disk i tjenesten hovedsakelig skal benyttes til å lagre en lokal kopi av koden som lagres på GitHub mens man gjør endringer bør ikke størrelsen på disken være stor. Figur 7 viser valgene som kan gjøres under Diskplass-fanen.
Tilgjengelige JAR-filer og bruk i PySpark
I /jupyter/lib-mappen i Jupyter-pyspark-miljøet er flere nyttige JAR-filer tilgjengelige for bruk med PySpark, inkludert støtte for Google Cloud Storage, BigQuery, Avro og Delta Lake. Disse JAR-filene kan inkluderes i PySpark-konfigurasjonen for å få tilgang til og arbeide med data fra disse kildene.
- Tilgjengelige JAR-filer:
gcs-connector-hadoop.jar: Kobler PySpark til Google Cloud Storage.spark-bigquery-with-dependencies_2.12.jar: Kobler PySpark til Google BigQuery.spark-avro_2.12.jar: Støtte for å lese og skrive Avro-data.delta-storage.jarogdelta-core_2.12.jar: Støtte for Delta Lake, som muliggjør ACID-transaksjoner og data versjonering.
- Legge til JAR-filer i PySpark:
For å bruke disse JAR-filene, konfigurer PySpark med stien til hver fil:
spark = SparkSession.builder \ .appName("Jupyter-pyspark-konfig") \ .config("spark.jars", "/jupyter/lib/gcs-connector-hadoop.jar," "/jupyter/lib/spark-bigquery-with-dependencies_2.12.jar," "/jupyter/lib/spark-avro_2.12.jar," "/jupyter/lib/delta-storage.jar," "/jupyter/lib/delta-core_2.12.jar") \ .getOrCreate()
- Eksempler på bruk av tilkoblingene:
Google Cloud Storage (GCS):
df = spark.read.format("parquet").load("gs://ditt-bucket-navn/path/to/data")Google BigQuery:
df = spark.read.format("bigquery") \ .option("table", "prosjekt_id.dataset_id.tabell_id") \ .load()Avro:
df = spark.read.format("avro").load("/path/to/avro/files")Delta Lake:
For å skrive til en Delta-tabell:
df.write.format("delta").save("/path/to/delta-table")For å lese fra en Delta-tabell:
delta_df = spark.read.format("delta").load("/path/to/delta-table")
Med disse instruksjonene kan brukerne effektivt konfigurere Jupyter-PySpark til å jobbe med eksterne datakilder og forskjellige dataformater i sitt PySpark-miljø.
Hvordan Spark Lokalt Fungerer og Arbeidsfordeling på Kjerner
Når Spark kjøres lokalt, starter det en SparkSession som kjører på en enkelt node (tjenesten din) uten å involvere en distribuert klynge. Lokalt i Spark kan du kontrollere ressursbruken og fordele arbeidsmengden på tilgjengelige CPU-kjerner for å optimalisere ytelsen.
Kjøring i Lokal Modus
Når Spark konfigureres til å kjøre i lokal modus, spesifiseres dette med "local[N]", der N representerer antall kjerner som Spark skal bruke. For eksempel: - "local[*]": Bruk alle tilgjengelige kjerner på maskinen. - "local[2]": Bruk 2 kjerner, uavhengig av hvor mange som er tilgjengelige.
Eksempel på konfigurasjon:
from pyspark.sql import SparkSession
spark = SparkSession.builder \
.appName("Lokal Spark") \
.master("local[*]") \ # Bruker alle tilgjengelige kjerner
.getOrCreate()Datatilgang
Man inspisere dataene fra en terminal inne i tjenesten:
- Åpne en instans av Jupyter-pyspark med data fra bøtter
- Åpne en terminal inne i Jupyter
- Gå til mappen med bøttene ved å kjøre dette fra terminalen
cd /buckets - Kjør
ls -ahli terminalen for å se på hvilke bøtter som er montert.
Installere pakker
Siden det nesten ikke er installert noen pakker i tjenesten så kan brukeren opprette et ssb-project og installere pakker som vanlig.
For å bygge et eksisterende ssb-project kan brukeren også bruke ssb-project.
Slette tjenesten
For å slette tjenesten kan man trykke på Slette-knappen i Dapla Lab under Mine tjenester. Når man sletter en tjeneste så slettes hele disken inne i tjenesten, og alle ressurser frigjøres. Vi anbefaler at man avslutter heller enn pauser tjenester som ikke benyttes.
Pause tjenesten
Man kan pause tjenesten ved å trykke på Pause-knappen i Dapla Lab under Mine tjenester. Når man pauser, slettes alt på den lokale disken som ikke er lagret under $HOME/work. Vi anbefaler at man avslutter heller enn pauser tjenester som ikke benyttes.
Monitorering
Man kan moniterere en instans av Jupyter-pyspark ved å trykke på Jupyter-pyspark-teksten under Mine tjenester i Dapla Lab, slik som vist i Figur 8.
Denne funksjonaliteten er under arbeid og mer informasjon kommer snart.
