ms-ai-architect/skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

15 KiB

Data Mesh Patterns and Domain Ownership

Last updated: 2026-06-24 Status: GA Category: Data Engineering for AI Type: reference Source: https://learn.microsoft.com/fabric/governance/onelake-catalog-overview


Innhold

Introduksjon

Data mesh er en desentralisert dataarkitektur som organiserer data etter forretningsdomener i stedet for sentraliserte datateam. Prinsippene -- domeneeierskap, data som produkt, selvbetjeningsplattform og foderert styring -- er spesielt relevante for store organisasjoner som bygger AI-losninger pa tvers av avdelinger. Microsoft Fabric stotter data mesh-arkitektur gjennom domener, OneLake shortcuts og foderert governance.

For norsk offentlig sektor, der departementer og direktorater har ulike datadomener med forskjellig regulering, er data mesh en naturlig tilnaerming. Direktoratet for digital tjenesteutvikling, NAV, Skatteetaten og andre etater kan eie sine egne dataprodukter mens de deler data gjennom en felles plattform. Fabric-domener muliggjor dette uten a duplisere data pa tvers av organisatoriske grenser.

AI-arbeidsbelastninger krever data fra mange domener: kundedata, transaksjonsdata, sensordata og referansedata. En data mesh-tilnaerming sikrer at hvert domene leverer kvalitetsdata som et produkt, med klare kontrakter og SLAer, noe som er kritisk for palitelige ML-modeller og AI-agenter.


Domain-Oriented Data Ownership

Fabric-domener som byggeklosser

Microsoft Fabric implementerer data mesh gjennom domener som logisk grupperer data etter forretningsomrade:

Organisasjon (Fabric Tenant)
+-- Domene: Veidata
|   +-- Arbeidsomrade: Trafikkmalinger
|   +-- Arbeidsomrade: Vegstandard
|   +-- Arbeidsomrade: Vaerdata
+-- Domene: Okonomi
|   +-- Arbeidsomrade: Budsjett
|   +-- Arbeidsomrade: Regnskap
+-- Domene: HR
|   +-- Arbeidsomrade: Kompetanse
|   +-- Arbeidsomrade: Bemanning
+-- Domene: AI/ML
    +-- Arbeidsomrade: Feature Store
    +-- Arbeidsomrade: Modelltrening

Roller i domenestyring

Rolle Ansvar Fabric-mapping
Fabric Admin Oppretter domener, tildeler domeneadministratorer Tenant-niva admin
Domain Admin Styrer domenet, godkjenner tilgang, delegerer innstillinger Forretningseier
Domain Contributor Tilordner arbeidsomrader til domenet Workspace admin
Data Producer Bygger og vedlikeholder dataprodukter Dataingeniorer
Data Consumer Bruker dataprodukter fra andre domener Analytikere, ML-ingeniorer

Opprette domener i Fabric

Domener opprettes via admin-portalen eller REST API:

# Via Fabric REST API
import requests

headers = {
    "Authorization": f"Bearer {access_token}",
    "Content-Type": "application/json"
}

# Opprett domene
domain_payload = {
    "displayName": "Veidata",
    "description": "Alle dataprodukter relatert til veiinfrastruktur og trafikk"
}

response = requests.post(
    "https://api.fabric.microsoft.com/v1/admin/domains",
    headers=headers,
    json=domain_payload
)

domain_id = response.json()["id"]
print(f"Domene opprettet: {domain_id}")

Subdomener for finmasket organisering

Domene: Veidata
+-- Subdomene: Trafikkstrom
|   +-- Trafikktellepunkter (Lakehouse)
|   +-- Reisetidsmaalinger (Lakehouse)
+-- Subdomene: Veistandard
|   +-- Dekketilstand (Lakehouse)
|   +-- Baerevne (Lakehouse)
+-- Subdomene: Hendelser
    +-- Ulykker (Lakehouse)
    +-- Vedlikehold (Lakehouse)

Data Product Versioning and Contracts

Data som produkt-prinsippet

Hvert dataprodukt bor oppfylle folgende krav:

Krav Beskrivelse Implementering i Fabric
Oppdagbart Lett a finne for konsumenter OneLake Catalog med domenfiltrering
Adresserbart Unik identifikator Workspace/Lakehouse/Table-sti
Palitelig SLA for tilgjengelighet og kvalitet Pipeline-monitorering + DQ-regler
Selvbeskrivende Dokumentert skjema og semantikk Metadata, tags, endorsements
Interoperabelt Standard format for deling Delta Lake / Parquet via OneLake
Sikkert Tilgangsstyring per domene Workspace RBAC + OneLake Security

Versjonering av dataprodukter

# Dataprodukt-versjonering via Delta Lake tidsreise
# Hver skriving til en Delta-tabell oppretter en ny versjon

# Lag en versjonert tabell med metadata
spark.sql("""
    CREATE TABLE IF NOT EXISTS lakehouse.default.traffic_product_v2 (
        measurement_id BIGINT,
        station_id STRING,
        timestamp TIMESTAMP,
        vehicle_count INT,
        avg_speed DOUBLE,
        road_surface_temp DOUBLE,
        -- Ny kolonne i v2
        weather_condition STRING
    )
    USING DELTA
    TBLPROPERTIES (
        'delta.columnMapping.mode' = 'name',
        'product.version' = '2.0',
        'product.owner' = 'veidata-teamet',
        'product.sla.freshness' = 'PT15M',
        'product.sla.availability' = '99.5%'
    )
""")

Datakontrakter

# data-contract.yaml - Kontrakt for trafikkdata-produktet
product:
  name: traffic-measurements
  version: "2.0"
  owner: veidata-teamet
  domain: veidata
  subdomain: trafikkstrom

schema:
  type: delta
  location: onelake://workspace/lakehouse/Tables/traffic_measurements
  columns:
    - name: measurement_id
      type: BIGINT
      nullable: false
      description: Unik ID for maalingen
    - name: station_id
      type: STRING
      nullable: false
      description: Tellepunkt-ID (NVDB-referanse)
    - name: timestamp
      type: TIMESTAMP
      nullable: false
      description: Maalingstidspunkt (UTC)
    - name: vehicle_count
      type: INT
      nullable: false
      description: Antall kjoretoy i perioden

quality:
  freshness: PT15M  # Maks 15 minutter gammelt
  completeness: 99.0%
  uniqueness:
    columns: [measurement_id]
    threshold: 100%

sla:
  availability: 99.5%
  response_time: P1D  # Innen 1 dag for support
  breaking_changes: 30d  # 30 dagers varsel for breaking changes

Cross-Domain Data Sharing via Shortcuts

OneLake Shortcuts for Data Mesh

Shortcuts er den primaere mekanismen for datadeling mellom domener uten a kopiere data:

Domene A: Veidata                    Domene B: AI/ML
+---------------------------+        +---------------------------+
| Lakehouse: Trafikk       |        | Lakehouse: Feature Store  |
| Tables/                  |        | Tables/                   |
|   traffic_measurements   |------->|   traffic_features (shortcut) |
|   road_conditions        |------->|   road_features (shortcut)    |
+---------------------------+        +---------------------------+
         |                                     |
         |                           +---------------------------+
         |                           | Lakehouse: Modelltrening  |
         +-------------------------->|   raw_traffic (shortcut)  |
                                     +---------------------------+

Opprette cross-domain shortcuts

# Opprett shortcut fra AI/ML-domenet til Veidata-domenet
import requests

shortcut_payload = {
    "name": "traffic_measurements",
    "path": "Tables",
    "target": {
        "oneLake": {
            "workspaceId": "veidata-workspace-id",
            "itemId": "trafikk-lakehouse-id",
            "path": "Tables/traffic_measurements"
        }
    }
}

response = requests.post(
    f"https://api.fabric.microsoft.com/v1/workspaces/{ml_workspace_id}/items/{feature_store_id}/shortcuts",
    headers=headers,
    json=shortcut_payload
)

Cross-tenant datadeling

For deling mellom organisasjoner (f.eks. mellom Direktoratet for digital tjenesteutvikling og Meteorologisk institutt):

Tenant A: Direktoratet for digital tjenesteutvikling       Tenant B: MET
+----------------------------+   +----------------------------+
| OneLake                    |   | OneLake                    |
| Workspace: Vaerdata        |   | Workspace: Observasjoner   |
| Tables/                    |   | Tables/                    |
|   weather_obs (shortcut) <------  weather_observations      |
+----------------------------+   +----------------------------+

Krav for cross-tenant deling:

  1. Fabric admin ma aktivere External Data Sharing i begge tenants
  2. Dataeier sender invitasjon
  3. Mottaker aksepterer og oppretter shortcut
  4. Data forblir read-only for mottaker

Federated Governance and Shared Platform

Foderert governance-modell

Styringsniva Ansvar Verktoy
Tenant-niva Globale policies, sikkerhetskrav Fabric Admin Portal
Domene-niva Domene-spesifikke regler, sertifisering Domain Settings, Delegated Settings
Workspace-niva Tilgangsstyring, kapasitet Workspace RBAC, Capacity assignment
Dataprodukt-niva Kvalitet, kontrakter, metadata DQ-regler, Endorsements

Delegerte innstillinger per domene

Fabric lar tenant-administratorer delegere visse innstillinger til domeneniva:

# Eksempel: Sertifiseringsinnstillinger per domene
# Via Fabric Admin Portal > Domains > Domain Settings > Delegated Settings

# Hvert domene kan ha:
# - Egne sertifiseringsregler
# - Egne sensitivitetsetiketter (default label)
# - Egne godkjennere for dataprodukt-sertifisering

OneLake Catalog for oppdagbarhet

OneLake Catalog er det sentrale punktet for a oppdage dataprodukter pa tvers av domener:

Funksjon Beskrivelse
Explore-fane Bla gjennom og filtrer dataprodukter
Domenefilter Vis kun data fra et spesifikt domene
Endorsements Sertifiserte/promoverte dataprodukter
Govern-fane Innsikt i governance-status
Secure-fane Enhetlig visning av sikkerhetsroller

Governance-pipeline for dataprodukter

1. Data Producer lager dataprodukt i sitt domene
        |
2. Kvalitetskontroll (automatiserte DQ-regler)
        |
3. Metadata og dokumentasjon pafort
        |
4. Domain Admin gjennomgar og sertifiserer
        |
5. Dataprodukt publiseres i OneLake Catalog
        |
6. Konsumenter oppdager via Catalog og oppretter shortcuts

Scaling to 50+ Domains with OneLake

Kapasitetsplanlegging

For store organisasjoner med mange domener:

Antall domener Kapasitetsmodell Governance-tilnaerming
1-10 Delt kapasitet Sentralisert
10-25 Kapasitet per avdeling Delvis foderert
25-50 Kapasitet per domene Fullt foderert
50+ Dedikert kapasitet per domene + delt Hub-and-spoke

Deployment-monstre

Monster 1: Ett arbeidsomrade per Medallion-lag per domene

Domene: Veidata
+-- Workspace: veidata-bronze (Inntak)
+-- Workspace: veidata-silver (Transformasjon)
+-- Workspace: veidata-gold (Servering)

Domene: Okonomi
+-- Workspace: okonomi-bronze
+-- Workspace: okonomi-silver
+-- Workspace: okonomi-gold

Monster 2: Data mesh med domene-spesifikke dataprodukter

Domene: Veidata
+-- Workspace: trafikk-produkt (Bronze -> Gold)
+-- Workspace: vegstandard-produkt (Bronze -> Gold)
+-- Workspace: vaer-produkt (Bronze -> Gold)

Automatisering med Default Domains

For skalering kan default domains automatisk tilordne nye arbeidsomrader:

# Sett opp default domain slik at nye arbeidsomrader
# automatisk tilordnes riktig domene basert pa hvem som oppretter dem

# Eksempel: Alle arbeidsomrader opprettet av veidata-teamet
# tilordnes automatisk til Veidata-domenet

Overvaking pa tvers av domener

# Power BI-rapport over alle domener
# Bruk Fabric REST API for a samle metadata

def get_domain_health_metrics():
    """Samle helsemetrikker for alle domener."""
    domains = requests.get(
        "https://api.fabric.microsoft.com/v1/admin/domains",
        headers=headers
    ).json()

    metrics = []
    for domain in domains["domains"]:
        workspaces = requests.get(
            f"https://api.fabric.microsoft.com/v1/admin/domains/{domain['id']}/workspaces",
            headers=headers
        ).json()

        metrics.append({
            "domain": domain["displayName"],
            "workspace_count": len(workspaces["workspaces"]),
            "last_updated": domain.get("modifiedDateTime")
        })

    return metrics

Anti-patterns og fallgruver

Anti-pattern Problem Losning
Sentralisert data team Flaskehals, lang leveransetid Domene-eierskap med shared platform
Ingen datakontrakter Breaking changes uten varsel Eksplisitte kontrakter med SLAer
Data-kopiering mellom domener Inkonsistens, hoy lagringskostnad OneLake shortcuts
Alle domener pa en kapasitet Stoyende naboer Dedikert kapasitet per kritiske domener
Ingen sertifisering Konsumenter vet ikke hva de kan stole pa Endorsement-prosess
For mange smaa domener Governance-overhead Konsolider relaterte omrader

Referanser


For arkitekten

  • Bruk denne referansen naar kunder planlegger data mesh-arkitektur i Fabric, spesielt naar de har flere avdelinger/team som trenger a dele data for AI-formaal.
  • Start med domener i Fabric som den primaere mekanismen -- ikke overkompliser med ekstern tooling. Fabric har innebygd stotte for domener, foderert governance og cross-domain shortcuts.
  • OneLake shortcuts er nogkelen til data mesh i Fabric -- de eliminerer behovet for dataduplisering mellom domener og sikrer en enkelt kopi av sannheten.
  • For norsk offentlig sektor: Koble domener til organisasjonens struktur (direktorat, seksjon, enhet). Bruk Utredningsinstruksen og samordningsplikten som argumenter for a dele data som produkter.
  • Advar mot for tidlig skalering: Start med 3-5 domener for de viktigste datoomradene, la organisasjonen modnes, og utvid gradvis.