For å effektivt håndtere komplekse datastrømmer i Microsoft Fabric, er det avgjørende å ha en strukturert tilnærming til konfigurasjonsparametere. Ved å bruke globale parametere kan du administrere miljøspesifikke innstillinger som workspace-identifikatorer og serveradresser på tvers av notebooks og datapipelines, noe som gir fleksibilitet og reduserer manuelt arbeid.

Selv om globale parametere ikke er en innebygd funksjonalitet i Fabric, finnes det metoder for å jobbe rundt dette. I denne guiden viser jeg hvordan du kan organisere parametere i en konfigurasjonsfil, hente dem dynamisk under kjøring, og opprette separate filer for ulike miljøer som utvikling, testing og produksjon.

‍

This post is also available in English on Medium.

For å effektivt håndtere komplekse datastrømmer i Microsoft Fabric, er det avgjørende å ha en strukturert tilnærming til konfigurasjonsparametere. Ved å bruke globale parametere kan du administrere miljøspesifikke innstillinger som workspace-identifikatorer og serveradresser på tvers av notebooks og datapipelines, noe som gir fleksibilitet og reduserer manuelt arbeid.

Selv om globale parametere ikke er en innebygd funksjonalitet i Fabric, finnes det metoder for å jobbe rundt dette. I denne guiden viser jeg hvordan du kan organisere parametere i en konfigurasjonsfil, hente dem dynamisk under kjøring, og opprette separate filer for ulike miljøer som utvikling, testing og produksjon.

1. Opprett en environment.json-fil

Første steg for å håndtere globale parametere i Microsoft Fabric er å opprette en konfigurasjonsfil, gjerne i JSON-format, som inneholder alle de nødvendige parameterne du trenger i prosessene dine.

Her er et eksempel på hvordan en typisk environment.json-fil kan se ut:

{   "environment_name": "dev",   "start_date": "2024-01-01",   "source_ws_id": "bd41d6f1-3ae4-4d00-8b4a-71efc91b3348",   "source_ls_id": "fad38627-ef32-4943-93ca-d7059932a630",   "semantic_model_ws_id": "320295e4-416f-46ae-a051-3b694a5274e4",   "semantic_model_id": "83aa1277-0cfc-44fb-90d9-c2bf787181b8"}

Når filen er opprettet, plasserer du den på rotnivå i ditt lakehouse. Dette gjør det enkelt å hente parameterne fra alle verktøy som har tilgang til OneLake.

Husk at selv om denne metoden gir fleksibilitet, er OneLake ikke ment som en sikker lagringsplass på lik linje med Azure Key Vault. Det betyr at du bør unngå å lagre passord eller nøkler konfigurasjonsfilen. For slik informasjon bør du heller vurdere å bruke Azure Key Vault. Legg heller inn en peker mot en Key Vault der nøkkelen er plassert.

2. Returnér parameter ved kjøring

Når environment.json-filen er opprettet og plassert i lakehouse, er neste steg å hente ut de nødvendige parameterne under kjøring av dine notebooks eller datapipelines. Dette kan gjøres ved å lese filen og returnere parameterne dynamisk.

For å forenkle denne prosessen kan du opprette en dedikert notebook som kun har som oppgave å returnere parameterne fra environment.json-filen. Denne notebooken kan du deretter kalle på fra ulike datapipelines eller notebooks. På denne måten slipper du å duplisere konfigurasjonslogikk i hver enkelt pipeline.

Her har du et eksempel på hvordan du kan hente ut parametere fra JSON-filen i en Python-notebook:

import jsonglobal_param_df = spark.read.option("multiline", "true").json("Files/environment.json").collect()json_object = json.dumps(global_param_df[0].asDict())mssparkutils.notebook.exit(json_object)

Fra en datapipeline kan du deretter kjøre denne notebooken som en aktivitet, og hente ut dens output slik:

@json(activity('ditt_notebook_navn').output.result.exitValue).parameter_name

3. Opprett ulike parameterfiler per miljø

Nå som du har etablert en metode for dynamisk å hente globale parametere fra en konfigurasjonsfil, kan du utvide denne tilnærmingen ved å opprette separate parameterfiler for hvert miljø. Dette gir deg fleksibiliteten til å tilpasse innstillingene avhengig av om du jobber i et utviklings-, test- eller produksjonsmiljø.

Ved å opprette egne environment.json-filer for hvert miljø, kan du gjøre det enklere å bytte mellom miljøene uten å måtte oppdatere hardkodede verdier i notebooks eller pipelines. Dette muliggjør miljøspesifikke tilpasninger som:

• Forskjellige datakilder: Du kan peke ditt utviklings- og testmiljø mot alternative datakilder for å forhindre at utvikling og testing skjer på produksjonsdata. Dette reduserer risikoen for at sensitive data blir eksponert eller feilaktig endret under utviklingsprosessen.
• Spesifikke startdatoer: For å effektivisere lastprosessen, kan du sette en annen startdato for hver last i de ulike miljøene. For eksempel kan du begrense historikken som lastes inn i utviklingsmiljøet for å gjøre testene raskere, mens produksjonsmiljøet kan laste all historikk.
• Overstyring av referanser: I situasjoner der du trenger å referere til Fabric-elementer som ligger i forskjellige workspaces, kan du overstyre referansene i konfigurasjonsfilene. Dette er nyttig når du tester eller utvikler på tvers av flere miljøer, og sørger for at alle referanser peker til riktig sted uten å måtte gjøre manuelle justeringer.

Og det var det! Denne tilnærmingen gir deg fleksibiliteten til å håndtere ulike miljøer, samtidig som du beholder en sentralisert og gjenbrukbar struktur. Lykke til!

‍