feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)
Initial addition of ms-ai-architect plugin to the open-source marketplace. Private content excluded: orchestrator/ (Linear tooling), docs/utredning/ (client investigation), generated test reports and PDF export script. skill-gen tooling moved from orchestrator/ to scripts/skill-gen/. Security scan: WARNING (risk 20/100) — no secrets, no injection found. False positive fixed: added gitleaks:allow to Python variable reference in output-validation-grounding-verification.md line 109. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
parent
a8d79e4484
commit
6a7632146e
490 changed files with 213249 additions and 2 deletions
|
|
@ -0,0 +1,531 @@
|
|||
# Cross-Cloud Data Integration
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Mange organisasjoner opererer i multi-cloud-miljoer der data er spredt mellom Azure, AWS, Google Cloud og on-premises systemer. For AI-losninger som krever data fra flere kilder er det kritisk a ha en effektiv strategi for krysssky-dataintegrasjon. Microsoft Fabric sin OneLake og shortcuts-arkitektur gjor det mulig a virtuelt samle data fra ulike skyplattformer uten fysisk kopiering, noe som reduserer bade egress-kostnader og kompleksitet.
|
||||
|
||||
OneLake fungerer som et enkelt virtuelt datalake for hele organisasjonen, der shortcuts oppretter referanser til data i Amazon S3, Google Cloud Storage, Azure Data Lake Storage Gen2 og andre lagringskilder. Med intelligent caching kan Fabric redusere krysssky-datautgifter ved a lagre hyppig brukte filer lokalt i workspacet.
|
||||
|
||||
For norsk offentlig sektor, der datasuverenitet og datalagring i Norge/EOS er regulert, er krysssky-integrasjon spesielt sensitivt. Fabric sin fleksibilitet med shortcuts og caching gjor det mulig a integrere data fra ulike kilder uten a flytte sensitiv data ut av godkjente lagringsomrader.
|
||||
|
||||
---
|
||||
|
||||
## Multi-Cloud Connector Strategies
|
||||
|
||||
### OneLake Shortcuts som primaerstrategi
|
||||
|
||||
OneLake shortcuts er den foretrukne mekanismen for krysssky-dataintegrasjon i Fabric:
|
||||
|
||||
| Kilde | Shortcut-type | Autentisering | Caching |
|
||||
|-------|-------------|---------------|---------|
|
||||
| **Azure Data Lake Gen2** | ADLS shortcut | Service principal / Account key | Nei (samme sky) |
|
||||
| **Amazon S3** | S3 shortcut | IAM Access Key / Secret | Ja (1-28 dager) |
|
||||
| **Google Cloud Storage** | GCS shortcut | Service Account JSON | Ja (1-28 dager) |
|
||||
| **S3-kompatibel** | S3-compatible | Access Key / Secret | Ja (1-28 dager) |
|
||||
| **On-premises** | Via OPDG | On-premises Data Gateway | Ja (1-28 dager) |
|
||||
| **Annen Fabric-tenant** | OneLake shortcut | Data Sharing invitation | Nei |
|
||||
|
||||
### Opprette shortcuts til ulike skyplattformer
|
||||
|
||||
```python
|
||||
import requests
|
||||
|
||||
headers = {
|
||||
"Authorization": f"Bearer {access_token}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
# --- AWS S3 Shortcut ---
|
||||
s3_shortcut = {
|
||||
"name": "aws_training_data",
|
||||
"path": "Files/external/aws",
|
||||
"target": {
|
||||
"amazonS3": {
|
||||
"location": "https://my-bucket.s3.eu-north-1.amazonaws.com",
|
||||
"subpath": "/ai-data/training/",
|
||||
"connectionId": "s3-connection-id"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# --- Google Cloud Storage Shortcut ---
|
||||
gcs_shortcut = {
|
||||
"name": "gcp_sensor_data",
|
||||
"path": "Files/external/gcp",
|
||||
"target": {
|
||||
"googleCloudStorage": {
|
||||
"location": "https://storage.googleapis.com/my-gcs-bucket",
|
||||
"subpath": "/sensor-readings/",
|
||||
"connectionId": "gcs-connection-id"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# --- On-premises via Data Gateway ---
|
||||
onprem_shortcut = {
|
||||
"name": "onprem_legacy_data",
|
||||
"path": "Files/external/onprem",
|
||||
"target": {
|
||||
"amazonS3": { # S3-kompatibel on-prem storage
|
||||
"location": "https://minio.internal.no:9000",
|
||||
"subpath": "/legacy-data/",
|
||||
"connectionId": "onprem-s3-connection-id"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
# Opprett shortcuts
|
||||
for shortcut in [s3_shortcut, gcs_shortcut, onprem_shortcut]:
|
||||
response = requests.post(
|
||||
f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/items/{lakehouse_id}/shortcuts",
|
||||
headers=headers,
|
||||
json=shortcut
|
||||
)
|
||||
print(f"Opprettet shortcut '{shortcut['name']}': {response.status_code}")
|
||||
```
|
||||
|
||||
### Data Factory Connectors for ETL
|
||||
|
||||
For scenarier der shortcuts ikke er tilstrekkelig (transformasjon, filtrering, format-konvertering):
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "CopyFromAWSToFabric",
|
||||
"type": "Copy",
|
||||
"inputs": [
|
||||
{
|
||||
"referenceName": "AmazonS3ParquetSource",
|
||||
"type": "DatasetReference",
|
||||
"parameters": {
|
||||
"bucket": "ai-training-data",
|
||||
"prefix": "features/2026/02/"
|
||||
}
|
||||
}
|
||||
],
|
||||
"outputs": [
|
||||
{
|
||||
"referenceName": "FabricLakehouseSink",
|
||||
"type": "DatasetReference",
|
||||
"parameters": {
|
||||
"tableName": "external_features"
|
||||
}
|
||||
}
|
||||
],
|
||||
"typeProperties": {
|
||||
"source": {
|
||||
"type": "ParquetSource"
|
||||
},
|
||||
"sink": {
|
||||
"type": "LakehouseTableSink",
|
||||
"tableActionOption": "Append"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Connector-oversikt for multi-cloud
|
||||
|
||||
| Kilde/Mal | Fabric Pipeline | Dataflow Gen2 | Shortcut | Direktelesing (Spark) |
|
||||
|-----------|----------------|---------------|----------|----------------------|
|
||||
| AWS S3 | Ja | Ja | Ja | Via shortcut |
|
||||
| AWS Redshift | Ja | Ja | Nei | Via JDBC |
|
||||
| Google BigQuery | Ja | Ja | Nei | Via JDBC |
|
||||
| Google Cloud Storage | Ja | Ja | Ja | Via shortcut |
|
||||
| Snowflake | Ja | Ja | Nei | Via JDBC/connector |
|
||||
| Oracle | Ja (via OPDG) | Ja | Nei | Via JDBC |
|
||||
| SAP HANA | Ja | Ja | Nei | Via JDBC |
|
||||
| MongoDB Atlas | Ja | Ja | Nei | Via connector |
|
||||
|
||||
---
|
||||
|
||||
## Data Egress Cost Optimization
|
||||
|
||||
### Forstaa egress-kostnader
|
||||
|
||||
| Skyplattform | Intern egress | Kryssregion egress | Internet egress |
|
||||
|-------------|--------------|-------------------|----------------|
|
||||
| **Azure** | Gratis (samme region) | ~$0.02/GB | ~$0.087/GB |
|
||||
| **AWS** | Gratis (samme AZ) | ~$0.01-0.02/GB | ~$0.09/GB |
|
||||
| **GCP** | Gratis (samme region) | ~$0.01/GB | ~$0.08-0.12/GB |
|
||||
|
||||
### Kostnadsoptimaliseringsstrategier
|
||||
|
||||
```
|
||||
Strategi 1: SHORTCUT CACHING (anbefalt)
|
||||
+------------------------------------------+
|
||||
| OneLake cacher filer fra S3/GCS lokalt |
|
||||
| - Forste lesing: Full egress-kostnad |
|
||||
| - Paafolgende: Ingen egress (cache hit) |
|
||||
| - Retensjon: 1-28 dager konfigurerbar |
|
||||
| - Maks filstorrelse for cache: 1 GB |
|
||||
+------------------------------------------+
|
||||
|
||||
Strategi 2: PERIODISK KOPIERING
|
||||
+------------------------------------------+
|
||||
| Kopier data pa faste intervaller |
|
||||
| - Daglig/ukentlig batch-kopi |
|
||||
| - Komprimert overfoering (Parquet) |
|
||||
| - Kun inkrementelle endringer |
|
||||
+------------------------------------------+
|
||||
|
||||
Strategi 3: FEDERATED QUERY
|
||||
+------------------------------------------+
|
||||
| Spark foresporsel mot ekstern kilde |
|
||||
| - Pushdown-predikater reduserer volum |
|
||||
| - Partisjonspruning minimerer egress |
|
||||
| - Bruk for ad-hoc, ikke produksjon |
|
||||
+------------------------------------------+
|
||||
```
|
||||
|
||||
### Konfigurere shortcut-caching
|
||||
|
||||
```python
|
||||
# Aktiver caching for workspace via REST API
|
||||
cache_config = {
|
||||
"settings": {
|
||||
"oneLake": {
|
||||
"shortcutCaching": {
|
||||
"enabled": True,
|
||||
"retentionPeriodInDays": 7 # 1-28 dager
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
response = requests.patch(
|
||||
f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/settings",
|
||||
headers=headers,
|
||||
json=cache_config
|
||||
)
|
||||
```
|
||||
|
||||
### Beregn egress-kostnader
|
||||
|
||||
```python
|
||||
def estimate_monthly_egress_cost(
|
||||
data_volume_gb: float,
|
||||
read_frequency_per_month: int,
|
||||
cache_hit_ratio: float,
|
||||
source_cloud: str,
|
||||
cost_per_gb: float = None
|
||||
) -> dict:
|
||||
"""
|
||||
Estimer maanedlig egress-kostnad for krysssky-data.
|
||||
"""
|
||||
costs = {
|
||||
"aws_s3": 0.09,
|
||||
"gcp_gcs": 0.12,
|
||||
"azure_blob": 0.087
|
||||
}
|
||||
|
||||
if cost_per_gb is None:
|
||||
cost_per_gb = costs.get(source_cloud, 0.10)
|
||||
|
||||
# Uten caching
|
||||
total_reads_gb = data_volume_gb * read_frequency_per_month
|
||||
cost_without_cache = total_reads_gb * cost_per_gb
|
||||
|
||||
# Med caching
|
||||
cache_misses = total_reads_gb * (1 - cache_hit_ratio)
|
||||
cost_with_cache = cache_misses * cost_per_gb
|
||||
|
||||
savings = cost_without_cache - cost_with_cache
|
||||
|
||||
return {
|
||||
"total_data_read_gb": total_reads_gb,
|
||||
"cost_without_cache_nok": round(cost_without_cache * 11, 2), # ~11 NOK/USD
|
||||
"cost_with_cache_nok": round(cost_with_cache * 11, 2),
|
||||
"monthly_savings_nok": round(savings * 11, 2),
|
||||
"cache_hit_ratio": cache_hit_ratio,
|
||||
"recommendation": (
|
||||
"Aktiver caching" if savings > 100
|
||||
else "Caching gir liten gevinst"
|
||||
)
|
||||
}
|
||||
|
||||
# Eksempel: 500 GB data lest 30 ganger/maaned fra AWS
|
||||
result = estimate_monthly_egress_cost(
|
||||
data_volume_gb=500,
|
||||
read_frequency_per_month=30,
|
||||
cache_hit_ratio=0.85, # 85% cache hit med 7-dagers retensjon
|
||||
source_cloud="aws_s3"
|
||||
)
|
||||
# Besparelse: ~12,000 NOK/mnd med caching
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Consistency and Synchronization Patterns
|
||||
|
||||
### Eventual Consistency med Shortcuts
|
||||
|
||||
Shortcuts gir eventual consistency -- endringer i kildesystemet reflekteres ved neste lesing:
|
||||
|
||||
```
|
||||
Tidslinje:
|
||||
T0: AWS S3 oppdateres med nye filer
|
||||
T1: Fabric leser via shortcut -> ser nye filer
|
||||
T2: Cached versjon brukes (hvis caching er aktivert)
|
||||
T3: Cache utloper -> ny lesing fra S3
|
||||
```
|
||||
|
||||
### Change Data Capture (CDC) fra multi-cloud
|
||||
|
||||
```python
|
||||
# CDC-moenster for synkronisering fra ekstern database
|
||||
from pyspark.sql import functions as F
|
||||
|
||||
def incremental_sync_from_external(
|
||||
source_connection: str,
|
||||
source_table: str,
|
||||
target_table: str,
|
||||
watermark_column: str,
|
||||
watermark_table: str = "lakehouse.default.sync_watermarks"
|
||||
):
|
||||
"""
|
||||
Inkrementell synkronisering fra ekstern database til Fabric.
|
||||
"""
|
||||
# 1. Hent siste watermark
|
||||
try:
|
||||
last_watermark = spark.sql(f"""
|
||||
SELECT MAX(watermark_value) as wm
|
||||
FROM {watermark_table}
|
||||
WHERE source_table = '{source_table}'
|
||||
""").collect()[0]["wm"]
|
||||
except Exception:
|
||||
last_watermark = "1970-01-01T00:00:00Z"
|
||||
|
||||
# 2. Les inkrementelle endringer fra ekstern kilde
|
||||
new_data = spark.read \
|
||||
.format("jdbc") \
|
||||
.option("url", source_connection) \
|
||||
.option("dbtable", f"""
|
||||
(SELECT * FROM {source_table}
|
||||
WHERE {watermark_column} > '{last_watermark}')
|
||||
""") \
|
||||
.load()
|
||||
|
||||
if new_data.count() == 0:
|
||||
print(f"Ingen nye endringer i {source_table}")
|
||||
return
|
||||
|
||||
# 3. Skriv til Fabric Lakehouse
|
||||
new_data.write \
|
||||
.format("delta") \
|
||||
.mode("append") \
|
||||
.saveAsTable(target_table)
|
||||
|
||||
# 4. Oppdater watermark
|
||||
new_watermark = new_data.agg(F.max(watermark_column)).collect()[0][0]
|
||||
spark.sql(f"""
|
||||
MERGE INTO {watermark_table} AS t
|
||||
USING (SELECT '{source_table}' as source_table,
|
||||
'{new_watermark}' as watermark_value) AS s
|
||||
ON t.source_table = s.source_table
|
||||
WHEN MATCHED THEN UPDATE SET watermark_value = s.watermark_value
|
||||
WHEN NOT MATCHED THEN INSERT (source_table, watermark_value)
|
||||
VALUES (s.source_table, s.watermark_value)
|
||||
""")
|
||||
|
||||
print(f"Synkronisert {new_data.count()} rader fra {source_table}")
|
||||
|
||||
# Synkroniser fra AWS RDS PostgreSQL
|
||||
incremental_sync_from_external(
|
||||
source_connection="jdbc:postgresql://rds-instance.amazonaws.com:5432/aidata",
|
||||
source_table="public.sensor_readings",
|
||||
target_table="lakehouse.default.external_sensors",
|
||||
watermark_column="updated_at"
|
||||
)
|
||||
```
|
||||
|
||||
### Konflikthondtering for bi-direksjonell synk
|
||||
|
||||
| Strategi | Beskrivelse | Bruksomrade |
|
||||
|----------|-------------|-------------|
|
||||
| **Last-write-wins** | Siste endring vinner | Enkel, akseptabel tap |
|
||||
| **Source-of-truth** | En kilde har prioritet | Master i ett system |
|
||||
| **Merge** | Kombiner endringer intelligent | Komplekst, men komplett |
|
||||
| **Event sourcing** | Alle endringer er hendelser | Historikk bevart |
|
||||
|
||||
---
|
||||
|
||||
## Hybrid Cloud Fallback Mechanisms
|
||||
|
||||
### On-premises Data Gateway
|
||||
|
||||
For tilgang til data bak brannmur eller i private nettverk:
|
||||
|
||||
```
|
||||
Internet On-premises nettverk
|
||||
+--------+ +-------------------+
|
||||
| Fabric | <-- HTTPS --> | Data Gateway |
|
||||
| Service| (utgoende) | (Windows-agent) |
|
||||
+--------+ | |
|
||||
| --> S3-kompatibel |
|
||||
| --> SQL Server |
|
||||
| --> Filsystem |
|
||||
+-------------------+
|
||||
```
|
||||
|
||||
**Viktig**: Gateway-en initierer utgaende tilkoblinger -- ingen inngoende regler kreves.
|
||||
|
||||
### Fallback-arkitektur
|
||||
|
||||
```python
|
||||
class MultiCloudDataAccess:
|
||||
"""
|
||||
Robust datatilgang med automatisk fallback mellom kilder.
|
||||
"""
|
||||
|
||||
def __init__(self, primary_source: dict, fallback_sources: list):
|
||||
self.primary = primary_source
|
||||
self.fallbacks = fallback_sources
|
||||
|
||||
def read_data(self, table_name: str) -> "DataFrame":
|
||||
"""
|
||||
Forsok a lese fra primaerkilde, fall tilbake til alternativer ved feil.
|
||||
"""
|
||||
sources = [self.primary] + self.fallbacks
|
||||
|
||||
for i, source in enumerate(sources):
|
||||
try:
|
||||
df = self._read_from_source(source, table_name)
|
||||
if i > 0:
|
||||
print(f"ADVARSEL: Brukte fallback-kilde #{i}: {source['name']}")
|
||||
return df
|
||||
except Exception as e:
|
||||
print(f"Feil med kilde '{source['name']}': {e}")
|
||||
if i == len(sources) - 1:
|
||||
raise RuntimeError(f"Alle kilder feilet for {table_name}")
|
||||
|
||||
def _read_from_source(self, source: dict, table_name: str) -> "DataFrame":
|
||||
if source["type"] == "lakehouse":
|
||||
return spark.table(f"{source['catalog']}.{table_name}")
|
||||
elif source["type"] == "s3_shortcut":
|
||||
return spark.read.parquet(f"{source['path']}/{table_name}")
|
||||
elif source["type"] == "jdbc":
|
||||
return spark.read.format("jdbc") \
|
||||
.option("url", source["connection"]) \
|
||||
.option("dbtable", table_name) \
|
||||
.load()
|
||||
|
||||
# Konfigurasjon
|
||||
data_access = MultiCloudDataAccess(
|
||||
primary_source={
|
||||
"name": "Fabric Lakehouse",
|
||||
"type": "lakehouse",
|
||||
"catalog": "lakehouse.default"
|
||||
},
|
||||
fallback_sources=[
|
||||
{
|
||||
"name": "AWS S3 via shortcut",
|
||||
"type": "s3_shortcut",
|
||||
"path": "abfss://workspace@onelake.dfs.fabric.microsoft.com/lakehouse/Files/external/aws"
|
||||
},
|
||||
{
|
||||
"name": "On-premises SQL Server",
|
||||
"type": "jdbc",
|
||||
"connection": "jdbc:sqlserver://sql.internal.no:1433;database=AIDatalake"
|
||||
}
|
||||
]
|
||||
)
|
||||
|
||||
df = data_access.read_data("training_features")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Residency and Sovereignty Compliance
|
||||
|
||||
### Norske og europeiske krav
|
||||
|
||||
| Krav | Regulering | Implikasjon for krysssky |
|
||||
|------|-----------|------------------------|
|
||||
| **Data i Norge** | Sikkerhetsloven, NSM | Sensitiv data kan ikke lagres utenfor Norge |
|
||||
| **Data i EOS** | GDPR, Schrems II | Persondata i EOS/EU eller med tilstrekkelig beskyttelse |
|
||||
| **Overforingsmekanismer** | GDPR Art. 46 | SCC, Adequacy decisions for tredjeland |
|
||||
| **Suverenitet** | Nasjonal kontroll | Nokler og tilgang kontrollert av norsk personell |
|
||||
|
||||
### Dataklassifisering for krysssky
|
||||
|
||||
```python
|
||||
data_residency_rules = {
|
||||
"HEMMELIG": {
|
||||
"allowed_locations": ["Norway East"],
|
||||
"cross_cloud": False,
|
||||
"encryption": "Customer-managed keys (Norwegian HSM)"
|
||||
},
|
||||
"FORTROLIG": {
|
||||
"allowed_locations": ["Norway East", "Norway West"],
|
||||
"cross_cloud": False,
|
||||
"encryption": "Customer-managed keys"
|
||||
},
|
||||
"INTERN": {
|
||||
"allowed_locations": ["EU/EEA regions"],
|
||||
"cross_cloud": True, # Kun EU-regioner
|
||||
"encryption": "Platform-managed keys"
|
||||
},
|
||||
"OFFENTLIG": {
|
||||
"allowed_locations": ["Alle"],
|
||||
"cross_cloud": True,
|
||||
"encryption": "Platform-managed keys"
|
||||
}
|
||||
}
|
||||
|
||||
def validate_data_residency(data_classification: str, target_region: str) -> bool:
|
||||
"""Valider at dataoverfoering overholder residency-krav."""
|
||||
rules = data_residency_rules.get(data_classification)
|
||||
if not rules:
|
||||
return False
|
||||
|
||||
if not rules["cross_cloud"]:
|
||||
return target_region in rules["allowed_locations"]
|
||||
|
||||
return target_region in rules["allowed_locations"] or rules["allowed_locations"] == ["Alle"]
|
||||
```
|
||||
|
||||
### OneLake-regioner og dataplassering
|
||||
|
||||
```python
|
||||
# Sikre at Fabric workspace er i riktig region
|
||||
workspace_info = requests.get(
|
||||
f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}",
|
||||
headers=headers
|
||||
).json()
|
||||
|
||||
capacity_region = workspace_info.get("capacityRegion")
|
||||
print(f"Workspace region: {capacity_region}")
|
||||
|
||||
# For norsk offentlig sektor: Krev Norway East
|
||||
assert capacity_region == "norwayeast", \
|
||||
f"FEIL: Workspace er i {capacity_region}, krever norwayeast for sensitiv data"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [OneLake shortcuts](https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts) -- Oversikt over shortcuts og stottede kilder
|
||||
- [Create an Amazon S3 shortcut](https://learn.microsoft.com/en-us/fabric/onelake/create-s3-shortcut) -- AWS S3-integrasjon
|
||||
- [Create an Amazon S3 compatible shortcut](https://learn.microsoft.com/en-us/fabric/onelake/create-s3-compatible-shortcut) -- S3-kompatible kilder
|
||||
- [Create shortcuts to on-premises data](https://learn.microsoft.com/en-us/fabric/onelake/create-on-premises-shortcut) -- On-premises via Data Gateway
|
||||
- [OneLake shortcut security](https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcut-security) -- Passthrough vs. delegated security
|
||||
- [OneLake, the OneDrive for data](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview) -- OneLake-arkitektur og one copy of data
|
||||
- [Microsoft Fabric integration pathways for ISVs](https://learn.microsoft.com/en-us/fabric/cicd/partners/partner-integration) -- Multi-cloud connector-oversikt
|
||||
- [External data sharing overview](https://learn.microsoft.com/en-us/fabric/governance/external-data-sharing-overview) -- Cross-tenant datadeling
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder har data i flere skyplattformer og trenger a integrere dem for AI-formaal uten a kopiere alt til Azure.
|
||||
- **OneLake shortcuts er primaerstrategien** for krysssky-dataintegrasjon. De unngaar dataduplisering, reduserer egress-kostnader med caching, og er enklere a vedlikeholde enn ETL-pipelines.
|
||||
- **Caching er essensielt for kostnader**: Aktiver shortcut-caching med passende retensjon (7 dager er god standard) for a redusere egress-kostnader med 70-90%.
|
||||
- **Datasuverenitet forst**: For norsk offentlig sektor, klassifiser data for du planlegger krysssky-integrasjon. HEMMELIG og FORTROLIG data skal aldri forlate Norge-regioner.
|
||||
- **On-premises Data Gateway** for legacy-systemer: Bruker kun utgaende HTTPS, ingen endringer i brannmurregler noedvendig. Stotter S3-kompatibel lagring og andre kilder bak brannmur.
|
||||
|
|
@ -0,0 +1,567 @@
|
|||
# Data Anonymization and Privacy Compliance
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Personvern og databeskyttelse er fundamentale krav for enhver AI-losning som behandler personopplysninger. GDPR (og den norske Personopplysningsloven) stiller strenge krav til hvordan persondata samles inn, behandles og beskyttes. For AI-systemer er dette spesielt utfordrende: ML-modeller kan utilsiktet memorere persondata fra treningsdatasettet, og RAG-systemer kan eksponere sensitiv informasjon i svar.
|
||||
|
||||
Microsoft tilbyr flere verktoy for personvernbeskyttelse: Azure Language PII-deteksjon for a identifisere og maskere personopplysninger, Microsoft Purview for dataklassifisering og governance, og SmartNoise for differensiell personvern. Disse verktoyene kan integreres i datapipelines i Fabric for a sikre at AI-modeller trenes pa korrekt anonymiserte data.
|
||||
|
||||
For norsk offentlig sektor, som er underlagt bade GDPR, Personopplysningsloven og sektorspesifikke krav (f.eks. Helseregisterloven, Politiregisterloven), er systematisk anonymisering og personvernbeskyttelse ikke bare god praksis -- det er lovpalagt.
|
||||
|
||||
---
|
||||
|
||||
## Differential Privacy Techniques
|
||||
|
||||
### Hva er differensiell personvern?
|
||||
|
||||
Differensiell personvern (DP) garanterer matematisk at ingen enkeltperson kan identifiseres fra resultatet av en dataanalyse. Prinsippet: tilforing av kontrollert stoy gjor det umulig a avgjore om en spesifikk person er i datasettet.
|
||||
|
||||
```
|
||||
Formell definisjon:
|
||||
For alle datasett D1 og D2 som skiller seg med maks 1 rad,
|
||||
og alle mulige resultater S:
|
||||
|
||||
Pr[M(D1) i S] <= e^epsilon * Pr[M(D2) i S]
|
||||
|
||||
epsilon (privacy budget): Lavere = sterkere personvern, mer stoy
|
||||
```
|
||||
|
||||
### Privacy Budget (epsilon)
|
||||
|
||||
| Epsilon | Personvernniva | Bruksomrade |
|
||||
|---------|---------------|-------------|
|
||||
| 0.1 | Svart sterkt | Helsedata, sensitiv forskning |
|
||||
| 1.0 | Sterkt | Generell offentlig statistikk |
|
||||
| 3.0 | Moderat | Intern analyse, dashboards |
|
||||
| 10.0 | Svakt | Testing, lav-risiko data |
|
||||
|
||||
### SmartNoise-implementering
|
||||
|
||||
```python
|
||||
# SmartNoise - Microsoft/OpenDP-prosjektet for differensiell personvern
|
||||
# pip install opendp smartnoise-sql
|
||||
|
||||
from opendp.measurements import make_laplace
|
||||
from opendp.domains import atom_domain
|
||||
from opendp.metrics import absolute_distance
|
||||
|
||||
def dp_count(true_count: int, epsilon: float = 1.0) -> float:
|
||||
"""
|
||||
Legg til Laplace-stoy for differensielt privat telling.
|
||||
"""
|
||||
sensitivity = 1 # En person kan endre tellingen med maks 1
|
||||
scale = sensitivity / epsilon
|
||||
|
||||
import numpy as np
|
||||
noise = np.random.laplace(0, scale)
|
||||
return max(0, true_count + noise) # Aldri negativ telling
|
||||
|
||||
def dp_mean(values, epsilon: float = 1.0, lower_bound: float = 0, upper_bound: float = 100):
|
||||
"""
|
||||
Beregn differensielt privat gjennomsnitt.
|
||||
"""
|
||||
import numpy as np
|
||||
n = len(values)
|
||||
true_mean = np.mean(values)
|
||||
|
||||
sensitivity = (upper_bound - lower_bound) / n
|
||||
scale = sensitivity / epsilon
|
||||
|
||||
noise = np.random.laplace(0, scale)
|
||||
return true_mean + noise
|
||||
|
||||
# Eksempel: Privat gjennomsnitt av inntektsdata
|
||||
incomes = [450000, 520000, 380000, 620000, 490000]
|
||||
private_mean = dp_mean(incomes, epsilon=1.0, lower_bound=0, upper_bound=2000000)
|
||||
print(f"Differensielt privat gjennomsnitt: {private_mean:,.0f} NOK")
|
||||
```
|
||||
|
||||
### Differensiell personvern i ML-trening
|
||||
|
||||
```python
|
||||
# DP-SGD (Differentially Private Stochastic Gradient Descent)
|
||||
# For trening av modeller med personverngarantier
|
||||
|
||||
# Med opacus (PyTorch)
|
||||
# pip install opacus
|
||||
|
||||
"""
|
||||
from opacus import PrivacyEngine
|
||||
|
||||
model = YourModel()
|
||||
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
|
||||
|
||||
privacy_engine = PrivacyEngine()
|
||||
model, optimizer, dataloader = privacy_engine.make_private_with_epsilon(
|
||||
module=model,
|
||||
optimizer=optimizer,
|
||||
data_loader=dataloader,
|
||||
epochs=10,
|
||||
target_epsilon=3.0, # Privacy budget
|
||||
target_delta=1e-5,
|
||||
max_grad_norm=1.0
|
||||
)
|
||||
|
||||
# Tren som vanlig - opacus handterer stoy-tilforing automatisk
|
||||
for epoch in range(10):
|
||||
for batch in dataloader:
|
||||
optimizer.zero_grad()
|
||||
loss = criterion(model(batch), labels)
|
||||
loss.backward()
|
||||
optimizer.step()
|
||||
|
||||
# Sjekk faktisk privacy-forbruk
|
||||
epsilon = privacy_engine.get_epsilon(delta=1e-5)
|
||||
print(f"Faktisk epsilon: {epsilon:.2f}")
|
||||
"""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## K-Anonymity and L-Diversity
|
||||
|
||||
### K-Anonymitet
|
||||
|
||||
K-anonymitet sikrer at hver kombinasjon av quasi-identifikatorer forekommer i minst k rader:
|
||||
|
||||
```python
|
||||
def check_k_anonymity(df, quasi_identifiers: list, k: int = 5) -> dict:
|
||||
"""
|
||||
Sjekk om et datasett oppfyller k-anonymitet.
|
||||
|
||||
Args:
|
||||
df: DataFrame
|
||||
quasi_identifiers: Kolonner som kan brukes til re-identifisering
|
||||
k: Minimum gruppestorrelse
|
||||
"""
|
||||
# Grupper etter quasi-identifikatorer
|
||||
groups = df.groupBy(quasi_identifiers).count()
|
||||
|
||||
# Finn grupper med faerre enn k elementer
|
||||
violating = groups.filter(F.col("count") < k)
|
||||
total_groups = groups.count()
|
||||
violating_groups = violating.count()
|
||||
|
||||
min_group_size = groups.agg(F.min("count")).collect()[0][0]
|
||||
|
||||
return {
|
||||
"k_anonymous": violating_groups == 0,
|
||||
"k_value": k,
|
||||
"total_groups": total_groups,
|
||||
"violating_groups": violating_groups,
|
||||
"min_group_size": min_group_size,
|
||||
"recommendation": f"Oek generalisering" if min_group_size < k else "OK"
|
||||
}
|
||||
|
||||
# Sjekk k-anonymitet for helsedatasett
|
||||
result = check_k_anonymity(
|
||||
df_health_data,
|
||||
quasi_identifiers=["age_group", "postal_area", "gender"],
|
||||
k=5
|
||||
)
|
||||
```
|
||||
|
||||
### Generaliseringsstrategier for k-anonymitet
|
||||
|
||||
```python
|
||||
def generalize_for_k_anonymity(df, generalizations: dict):
|
||||
"""
|
||||
Generaliser quasi-identifikatorer for a oppna k-anonymitet.
|
||||
|
||||
Args:
|
||||
generalizations: {kolonne: generaliseringsfunksjon}
|
||||
"""
|
||||
result = df
|
||||
for col_name, gen_func in generalizations.items():
|
||||
result = result.withColumn(col_name, gen_func(F.col(col_name)))
|
||||
return result
|
||||
|
||||
# Generaliseringsfunksjoner
|
||||
generalizations = {
|
||||
# Alder -> aldersgruppe (5-aarsintervaller)
|
||||
"age": lambda c: (F.floor(c / 5) * 5).cast("int"),
|
||||
|
||||
# Postnummer -> postomrade (forste 2 siffer)
|
||||
"postal_code": lambda c: F.substring(c, 1, 2),
|
||||
|
||||
# Fodselsdato -> fodeselsar
|
||||
"birth_date": lambda c: F.year(c),
|
||||
|
||||
# Kommune -> fylke
|
||||
"municipality": lambda c: F.substring(c, 1, 2) # Forste 2 siffer = fylke
|
||||
}
|
||||
|
||||
df_generalized = generalize_for_k_anonymity(df_sensitive, generalizations)
|
||||
|
||||
# Verifiser
|
||||
result = check_k_anonymity(df_generalized, ["age", "postal_code", "gender"], k=5)
|
||||
print(f"K-anonym: {result['k_anonymous']}, Min gruppestorrelse: {result['min_group_size']}")
|
||||
```
|
||||
|
||||
### L-Diversitet
|
||||
|
||||
L-diversitet utvider k-anonymitet ved a kreve at sensitive attributter har minst l forskjellige verdier i hver gruppe:
|
||||
|
||||
```python
|
||||
def check_l_diversity(df, quasi_identifiers: list, sensitive_column: str, l: int = 3):
|
||||
"""
|
||||
Sjekk om et datasett oppfyller l-diversitet.
|
||||
"""
|
||||
# Tell unike verdier av sensitiv attributt per gruppe
|
||||
diversity = df.groupBy(quasi_identifiers).agg(
|
||||
F.countDistinct(sensitive_column).alias("distinct_sensitive"),
|
||||
F.count("*").alias("group_size")
|
||||
)
|
||||
|
||||
violating = diversity.filter(F.col("distinct_sensitive") < l)
|
||||
min_diversity = diversity.agg(F.min("distinct_sensitive")).collect()[0][0]
|
||||
|
||||
return {
|
||||
"l_diverse": violating.count() == 0,
|
||||
"l_value": l,
|
||||
"min_diversity": min_diversity,
|
||||
"violating_groups": violating.count()
|
||||
}
|
||||
|
||||
# Sjekk l-diversitet for diagnosekoder
|
||||
result = check_l_diversity(
|
||||
df_health_data,
|
||||
quasi_identifiers=["age_group", "postal_area"],
|
||||
sensitive_column="diagnosis_code",
|
||||
l=3
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PII Detection and Masking
|
||||
|
||||
### Azure Language PII Detection
|
||||
|
||||
Azure Language tilbyr avansert PII-deteksjon med stotte for 50+ kategorier:
|
||||
|
||||
```python
|
||||
from azure.ai.textanalytics import TextAnalyticsClient
|
||||
from azure.core.credentials import AzureKeyCredential
|
||||
|
||||
def detect_and_redact_pii(text: str, endpoint: str, key: str,
|
||||
categories_to_redact: list = None) -> dict:
|
||||
"""
|
||||
Detekter og masker PII i tekst med Azure Language.
|
||||
|
||||
Args:
|
||||
text: Tekst a analysere
|
||||
categories_to_redact: Spesifikke PII-kategorier a maskere
|
||||
"""
|
||||
client = TextAnalyticsClient(
|
||||
endpoint=endpoint,
|
||||
credential=AzureKeyCredential(key)
|
||||
)
|
||||
|
||||
response = client.recognize_pii_entities(
|
||||
documents=[text],
|
||||
categories_filter=categories_to_redact,
|
||||
language="no" # Norsk
|
||||
)
|
||||
|
||||
result = response[0]
|
||||
|
||||
return {
|
||||
"original_text": text,
|
||||
"redacted_text": result.redacted_text,
|
||||
"entities": [
|
||||
{
|
||||
"text": entity.text,
|
||||
"category": entity.category,
|
||||
"subcategory": entity.subcategory,
|
||||
"confidence": entity.confidence_score,
|
||||
"offset": entity.offset,
|
||||
"length": entity.length
|
||||
}
|
||||
for entity in result.entities
|
||||
]
|
||||
}
|
||||
|
||||
# Eksempel
|
||||
result = detect_and_redact_pii(
|
||||
text="Ola Nordmann bor i Storgata 15, 0184 Oslo. Hans personnummer er 01019012345.",
|
||||
endpoint="https://myservice.cognitiveservices.azure.com/",
|
||||
key="your-api-key",
|
||||
categories_to_redact=["Person", "Address", "NorwayIdentityNumber"]
|
||||
)
|
||||
# Output: "***** bor i *****, ***** Oslo. Hans personnummer er *****."
|
||||
```
|
||||
|
||||
### PII-deteksjon i Fabric-pipelines
|
||||
|
||||
```python
|
||||
# Batch PII-deteksjon i PySpark
|
||||
from pyspark.sql import functions as F
|
||||
from pyspark.sql.types import ArrayType, StructType, StructField, StringType, DoubleType
|
||||
|
||||
def batch_pii_detection(df, text_column: str, endpoint: str, key: str):
|
||||
"""
|
||||
Kjor PII-deteksjon pa en hel DataFrame-kolonne.
|
||||
"""
|
||||
@F.udf(returnType=StringType())
|
||||
def redact_pii_udf(text):
|
||||
if not text:
|
||||
return text
|
||||
|
||||
from azure.ai.textanalytics import TextAnalyticsClient
|
||||
from azure.core.credentials import AzureKeyCredential
|
||||
|
||||
client = TextAnalyticsClient(
|
||||
endpoint=endpoint,
|
||||
credential=AzureKeyCredential(key)
|
||||
)
|
||||
|
||||
try:
|
||||
response = client.recognize_pii_entities(
|
||||
documents=[text], language="no"
|
||||
)
|
||||
return response[0].redacted_text
|
||||
except Exception:
|
||||
return text # Returner original ved feil
|
||||
|
||||
return df.withColumn(f"{text_column}_redacted", redact_pii_udf(F.col(text_column)))
|
||||
|
||||
# Bruk pa treningsdata for RAG
|
||||
df_documents = spark.table("lakehouse.default.raw_documents")
|
||||
df_redacted = batch_pii_detection(
|
||||
df_documents,
|
||||
text_column="content",
|
||||
endpoint=endpoint,
|
||||
key=api_key
|
||||
)
|
||||
|
||||
# Lagre redaktert versjon for AI-trening
|
||||
df_redacted.select("doc_id", "content_redacted", "metadata") \
|
||||
.write.format("delta").mode("overwrite") \
|
||||
.saveAsTable("lakehouse.default.training_documents_anonymized")
|
||||
```
|
||||
|
||||
### PII-kategorier relevant for norsk offentlig sektor
|
||||
|
||||
| Kategori | Azure-kode | Eksempler |
|
||||
|----------|-----------|----------|
|
||||
| Personnummer | NorwayIdentityNumber | 01019012345 |
|
||||
| Personnavn | Person | Ola Nordmann |
|
||||
| Adresse | Address | Storgata 15, 0184 Oslo |
|
||||
| Telefonnummer | PhoneNumber | +47 90000000 |
|
||||
| E-post | Email | ola@firma.no |
|
||||
| Bankkonto | InternationalBankingAccountNumber | NO9386011117947 |
|
||||
| Organisasjonsnummer | Organization | 123 456 789 |
|
||||
| Helseinfo (PHI) | HealthcareEntities | Diagnose, medisin |
|
||||
|
||||
---
|
||||
|
||||
## Right-to-Be-Forgotten Implementation
|
||||
|
||||
### GDPR Artikkel 17: Retten til sletting
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
class GDPRDeletionService:
|
||||
"""
|
||||
Implementer rett til sletting (GDPR Art. 17) i Delta Lake.
|
||||
"""
|
||||
|
||||
def __init__(self, tables_with_personal_data: list):
|
||||
self.tables = tables_with_personal_data
|
||||
self.deletion_log_table = "lakehouse.default.gdpr_deletion_log"
|
||||
|
||||
def process_deletion_request(self, person_id: str, request_id: str):
|
||||
"""
|
||||
Slett alle personopplysninger for en person pa tvers av tabeller.
|
||||
"""
|
||||
results = {}
|
||||
|
||||
for table_config in self.tables:
|
||||
table_name = table_config["table"]
|
||||
id_column = table_config["id_column"]
|
||||
strategy = table_config.get("strategy", "hard_delete")
|
||||
|
||||
try:
|
||||
delta_table = DeltaTable.forName(spark, table_name)
|
||||
|
||||
if strategy == "hard_delete":
|
||||
# Slett raden helt
|
||||
delta_table.delete(f"{id_column} = '{person_id}'")
|
||||
|
||||
elif strategy == "anonymize":
|
||||
# Anonymiser i stedet for a slette
|
||||
anon_columns = table_config.get("anonymize_columns", [])
|
||||
update_set = {col: F.lit("SLETTET") for col in anon_columns}
|
||||
update_set["is_anonymized"] = F.lit(True)
|
||||
update_set["anonymized_date"] = F.current_timestamp()
|
||||
|
||||
delta_table.update(
|
||||
condition=f"{id_column} = '{person_id}'",
|
||||
set=update_set
|
||||
)
|
||||
|
||||
elif strategy == "pseudonymize":
|
||||
# Erstatt med pseudonym
|
||||
import hashlib
|
||||
pseudonym = hashlib.sha256(
|
||||
f"{person_id}_{request_id}".encode()
|
||||
).hexdigest()[:12]
|
||||
|
||||
delta_table.update(
|
||||
condition=f"{id_column} = '{person_id}'",
|
||||
set={id_column: F.lit(f"PSEUDO_{pseudonym}")}
|
||||
)
|
||||
|
||||
results[table_name] = {"status": "OK", "strategy": strategy}
|
||||
|
||||
except Exception as e:
|
||||
results[table_name] = {"status": "ERROR", "error": str(e)}
|
||||
|
||||
# Logg slettingen
|
||||
self._log_deletion(request_id, person_id, results)
|
||||
|
||||
return results
|
||||
|
||||
def _log_deletion(self, request_id, person_id, results):
|
||||
"""Logg slettingsforesporselen for compliance-formaal."""
|
||||
log_entry = spark.createDataFrame([{
|
||||
"request_id": request_id,
|
||||
"person_id_hash": hashlib.sha256(person_id.encode()).hexdigest(),
|
||||
"timestamp": datetime.now().isoformat(),
|
||||
"tables_processed": len(results),
|
||||
"all_successful": all(r["status"] == "OK" for r in results.values()),
|
||||
"details": json.dumps(results)
|
||||
}])
|
||||
log_entry.write.format("delta").mode("append") \
|
||||
.saveAsTable(self.deletion_log_table)
|
||||
|
||||
def vacuum_after_deletion(self, retention_hours: int = 0):
|
||||
"""
|
||||
Kjor VACUUM for a fysisk fjerne slettede data.
|
||||
ADVARSEL: Setter retensjon til 0 timer = ingen tidsreise mulig.
|
||||
"""
|
||||
spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled", "false")
|
||||
|
||||
for table_config in self.tables:
|
||||
spark.sql(f"VACUUM {table_config['table']} RETAIN {retention_hours} HOURS")
|
||||
|
||||
spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled", "true")
|
||||
|
||||
# Konfigurasjon
|
||||
tables_config = [
|
||||
{"table": "lakehouse.default.customers", "id_column": "person_id", "strategy": "hard_delete"},
|
||||
{"table": "lakehouse.default.transactions", "id_column": "customer_id", "strategy": "anonymize",
|
||||
"anonymize_columns": ["customer_name", "email", "phone"]},
|
||||
{"table": "lakehouse.default.ml_features", "id_column": "entity_id", "strategy": "pseudonymize"},
|
||||
{"table": "lakehouse.default.embeddings", "id_column": "source_person_id", "strategy": "hard_delete"}
|
||||
]
|
||||
|
||||
gdpr_service = GDPRDeletionService(tables_config)
|
||||
result = gdpr_service.process_deletion_request("12345678901", "REQ-2026-001")
|
||||
```
|
||||
|
||||
### TTL (Time-to-Live) for automatisk sletting
|
||||
|
||||
```python
|
||||
# Implementer TTL for partisjonerte Delta-tabeller
|
||||
def enforce_ttl(table_name: str, partition_column: str, retention_days: int):
|
||||
"""
|
||||
Slett partisjoner eldre enn retention_days.
|
||||
Nyttig for a overholde GDPR-krav om minimering av lagringstid.
|
||||
"""
|
||||
cutoff_date = (datetime.now() - timedelta(days=retention_days)).strftime("%Y-%m-%d")
|
||||
|
||||
delta_table = DeltaTable.forName(spark, table_name)
|
||||
delta_table.delete(f"{partition_column} < '{cutoff_date}'")
|
||||
|
||||
# VACUUM for a fysisk fjerne filene
|
||||
spark.sql(f"VACUUM {table_name}")
|
||||
|
||||
print(f"Slettet data eldre enn {cutoff_date} fra {table_name}")
|
||||
|
||||
# Kjor daglig: Slett persondata eldre enn 13 maaneder
|
||||
enforce_ttl("lakehouse.default.customer_interactions", "interaction_date", retention_days=395)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Privacy Impact Assessments
|
||||
|
||||
### DPIA-rammeverk for AI-systemer
|
||||
|
||||
| Fase | Aktivitet | Verktoy |
|
||||
|------|----------|---------|
|
||||
| **1. Kartlegging** | Identifiser persondata i AI-systemet | Microsoft Purview Data Map |
|
||||
| **2. Vurdering** | Vurder noodvendighet og proporsjonalitet | DPIA-mal fra Datatilsynet |
|
||||
| **3. Risikoanalyse** | Identifiser risiko for de registrerte | Risk Assessment Framework |
|
||||
| **4. Tiltak** | Implementer tekniske og organisatoriske tiltak | Anonymisering, tilgangsstyring |
|
||||
| **5. Dokumentasjon** | Dokumenter vurderingen | Protokoll, behandlingsregister |
|
||||
| **6. Konsultasjon** | Konsulter personvernombud / Datatilsynet | Ved hoy risiko |
|
||||
|
||||
### Automatisert personvern-sjekk i CI/CD
|
||||
|
||||
```python
|
||||
def privacy_check_before_deployment(model_artifacts_path: str) -> dict:
|
||||
"""
|
||||
Automatisert personvernsjekk for ML-modeller.
|
||||
Kjores som del av CI/CD-pipeline.
|
||||
"""
|
||||
checks = {}
|
||||
|
||||
# 1. Sjekk at treningsdata er anonymisert
|
||||
training_data_path = f"{model_artifacts_path}/training_data_manifest.json"
|
||||
manifest = json.load(open(training_data_path))
|
||||
|
||||
checks["anonymized_training_data"] = manifest.get("anonymization_applied", False)
|
||||
|
||||
# 2. Sjekk at modellen ikke memorerer PII
|
||||
# (Sample inference med kjente PII-verdier)
|
||||
checks["pii_leakage_test"] = run_pii_leakage_test(model_artifacts_path)
|
||||
|
||||
# 3. Sjekk at DPIA er utfylt
|
||||
checks["dpia_completed"] = os.path.exists(f"{model_artifacts_path}/dpia_signed.pdf")
|
||||
|
||||
# 4. Sjekk at personvernombud er konsultert
|
||||
checks["dpo_approved"] = manifest.get("dpo_approval_date") is not None
|
||||
|
||||
# 5. Sjekk retensjonspolicy
|
||||
checks["retention_policy_defined"] = manifest.get("data_retention_days") is not None
|
||||
|
||||
all_passed = all(checks.values())
|
||||
|
||||
return {
|
||||
"passed": all_passed,
|
||||
"checks": checks,
|
||||
"recommendation": "DEPLOY" if all_passed else "BLOKKER - Personvernkrav ikke oppfylt"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [What is Azure Language PII detection?](https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/overview) -- PII-deteksjon og maskering
|
||||
- [PII filter in Azure AI Foundry](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/content-filter-personal-information) -- PII-filtrering for LLM-er
|
||||
- [Responsible AI - Privacy and security](https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai) -- SmartNoise og Counterfit
|
||||
- [Data privacy for cloud-scale analytics](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/secure-data-privacy) -- Dataklassifisering og konfidensialitetsskjema
|
||||
- [PII entity categories](https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/concepts/entity-categories) -- Alle stottede PII-kategorier
|
||||
- [Transparency note for PII](https://learn.microsoft.com/en-us/azure/ai-foundry/responsible-ai/language-service/transparency-note-personally-identifiable-information) -- Bruksomrader og begrensninger
|
||||
- [Data governance with Microsoft Purview](https://learn.microsoft.com/en-us/purview/data-governance-master-data-management) -- Purview for dataklassifisering
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder behandler personopplysninger i AI-systemer og trenger anonymiserings- og personvernstrategier.
|
||||
- **Azure Language PII-deteksjon er forstevalget** for a identifisere og maskere personopplysninger i tekst -- bade for treningsdata og RAG-dokumenter. Stotter norsk sprak.
|
||||
- **GDPR-sletting i Delta Lake krever VACUUM**: Delta Lake sin tidsreise betyr at slettede data forblir tilgjengelige i transaksjonsloggen til VACUUM kjores. Planlegg VACUUM i trad med slettekrav.
|
||||
- **K-anonymitet er minimum for publisering**: For datasett som deles utenfor organisasjonen, krev minimum k=5 anonymitet. For helsedata, bruk l-diversitet i tillegg.
|
||||
- **For norsk offentlig sektor**: Datatilsynets DPIA-mal er obligatorisk for AI-systemer med hoy risiko. Integrer personvernsjekk i CI/CD-pipeline for a sikre at ingen modell deployes uten godkjent DPIA.
|
||||
|
|
@ -0,0 +1,785 @@
|
|||
# Data Cataloging and Discovery
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Datakatalogisering og oppdagelse er fundamentale kapabiliteter for organisasjoner som bygger AI-løsninger. Uten en systematisk tilnærming til å registrere, beskrive og finne data, risikerer AI-team å bruke uforholdsmessig mye tid på å lete etter relevante datasett, duplisere eksisterende arbeid, eller trene modeller på data av ukjent kvalitet og opprinnelse. Microsoft Purview Unified Catalog er Microsofts svar på denne utfordringen -- en sentral plattform for å organisere, oppdage og forstå data på tvers av hele dataeiendommen.
|
||||
|
||||
For norsk offentlig sektor er datakatalogisering spesielt viktig gitt kravene i Forvaltningsloven om dokumentasjon, Digdirs prinsipper for informasjonsforvaltning, og den nasjonale strategien for deling av data. Purview Unified Catalog støtter disse kravene gjennom governance domains, data products, business glossary og rollebasert tilgangsstyring som mapper til norske forvaltningsprinsipper.
|
||||
|
||||
Denne referansen dekker asset-registrering og metadata-berikelse, søk- og oppdagelsesgrensesnitt, forretningsglossarer og taksonomier, dataeier- og forvalteroppdrag, samt bruksanalyse og popularitetsmetrikker for AI-datasett i Microsoft Purview.
|
||||
|
||||
---
|
||||
|
||||
## Asset Registration and Metadata Enrichment
|
||||
|
||||
### Registrering av datakilder i Purview
|
||||
|
||||
Asset-registrering er det første steget for å gjøre data oppdagbare. Purview støtter automatisk skanning av et bredt spekter av datakilder:
|
||||
|
||||
| Kildetype | Eksempler | Skanningsmetode |
|
||||
|---|---|---|
|
||||
| **Microsoft Fabric** | Lakehouse, Warehouse, KQL DB, Notebooks, Pipelines, Power BI | Automatisk ved Fabric-tenant-skanning |
|
||||
| **Azure Data** | SQL Database, ADLS Gen2, Cosmos DB, Synapse | Registrering + planlagt skanning |
|
||||
| **On-premises** | SQL Server, Oracle, file shares | Self-hosted Integration Runtime |
|
||||
| **SaaS** | Dataverse, Salesforce, SAP | Registrering + connector-basert skanning |
|
||||
| **Multi-cloud** | AWS S3, Google BigQuery | Cross-cloud connectors |
|
||||
|
||||
### Fabric-spesifikk registrering
|
||||
|
||||
```
|
||||
Fabric Tenant Scanning:
|
||||
|
||||
1. Purview Portal > Unified Catalog > Catalog Management
|
||||
2. Registrer Microsoft Fabric som datakilde
|
||||
3. Konfigurer skanning:
|
||||
- Velg workspaces (alle eller spesifikke)
|
||||
- Planlegg skanningsfrekvens
|
||||
- Konfigurer autentisering (Managed Identity)
|
||||
4. Etter skanning er følgende tilgjengelig:
|
||||
|
||||
Inventerte Fabric-elementer:
|
||||
┌────────────────────────────────────────────────┐
|
||||
│ Opplevelse │ Registrerte elementer │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Data Engineering │ Lakehouse, Notebook, │
|
||||
│ │ Spark Job Def, SQL Endpoint │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Data Factory │ Data Pipeline, Dataflow Gen2 │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Data Science │ Experiment, ML Model │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Data Warehouse │ Warehouse │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Real-Time Analytics│ KQL Database, KQL Queryset │
|
||||
├────────────────────────────────────────────────┤
|
||||
│ Power BI │ Semantic Model, Report, │
|
||||
│ │ Dashboard, Dataflow, Datamart │
|
||||
└────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Metadata-berikelse
|
||||
|
||||
Etter registrering kan metadata berikes manuelt eller automatisk:
|
||||
|
||||
```python
|
||||
# Bruk Purview REST API for å berike metadata på assets
|
||||
import requests
|
||||
|
||||
purview_endpoint = "https://<account>.purview.azure.com"
|
||||
headers = {"Authorization": f"Bearer {access_token}"}
|
||||
|
||||
# Hent eksisterende asset
|
||||
asset_response = requests.get(
|
||||
f"{purview_endpoint}/catalog/api/atlas/v2/entity/guid/{asset_guid}",
|
||||
headers=headers
|
||||
)
|
||||
asset = asset_response.json()
|
||||
|
||||
# Legg til forretningsbeskrivelse og egendefinerte attributter
|
||||
asset["entity"]["attributes"]["userDescription"] = (
|
||||
"Kundetransaksjonstabell for ML-treningsdata. "
|
||||
"Inneholder 12 måneders historikk for churn-prediksjon. "
|
||||
"Oppdateres daglig via inkrementell lasting."
|
||||
)
|
||||
|
||||
# Oppdater asset med berikede metadata
|
||||
update_response = requests.put(
|
||||
f"{purview_endpoint}/catalog/api/atlas/v2/entity",
|
||||
headers=headers,
|
||||
json={"entity": asset["entity"]}
|
||||
)
|
||||
```
|
||||
|
||||
### Automatisk klassifisering og tagging
|
||||
|
||||
Purview skanner innholdet i datakolonner og tildeler automatiske klassifiseringer:
|
||||
|
||||
| Klassifiseringstype | Eksempler | Handling |
|
||||
|---|---|---|
|
||||
| **Norsk PII** | Fødselsnummer (11 siffer) | Auto-merking som "Fortrolig" |
|
||||
| **Finansiell** | Kontonummer, IBAN | Varsling til dataeier |
|
||||
| **Helse** | Diagnosekoder (ICD-10) | Eskalering til DPO |
|
||||
| **Kontaktinfo** | E-post, telefonnummer | Krever samtykke-validering |
|
||||
| **Autentisering** | API-nøkler, passord | Umiddelbar sikkerhetsvarsling |
|
||||
|
||||
```python
|
||||
# Programmatisk klassifiseringsrapport for AI-datasett
|
||||
def get_classification_report(purview_endpoint, token):
|
||||
"""Generer rapport over klassifiserte assets for AI-treningsdata."""
|
||||
url = f"{purview_endpoint}/catalog/api/search/query"
|
||||
headers = {"Authorization": f"Bearer {token}"}
|
||||
|
||||
classifications = [
|
||||
"MICROSOFT.GOVERNMENT.NORWAY.NATIONAL.ID.NUMBER",
|
||||
"MICROSOFT.FINANCIAL.CREDIT_CARD_NUMBER",
|
||||
"MICROSOFT.PERSONAL.EMAIL",
|
||||
"MICROSOFT.PERSONAL.PHONE_NUMBER"
|
||||
]
|
||||
|
||||
report = {}
|
||||
for classification in classifications:
|
||||
body = {
|
||||
"keywords": "*",
|
||||
"filter": {
|
||||
"classification": classification,
|
||||
"assetType": "azure_datalake_gen2_path"
|
||||
},
|
||||
"limit": 100
|
||||
}
|
||||
response = requests.post(url, headers=headers, json=body)
|
||||
results = response.json()
|
||||
report[classification] = {
|
||||
"count": results.get("@search.count", 0),
|
||||
"assets": [a["name"] for a in results.get("value", [])]
|
||||
}
|
||||
|
||||
return report
|
||||
|
||||
# Eksempel output:
|
||||
# {
|
||||
# "NORWAY.NATIONAL.ID.NUMBER": {"count": 15, "assets": [...]},
|
||||
# "CREDIT_CARD_NUMBER": {"count": 3, "assets": [...]},
|
||||
# ...
|
||||
# }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Search and Discovery Interfaces
|
||||
|
||||
### Purview Unified Catalog søkegrensesnitt
|
||||
|
||||
Unified Catalog tilbyr flere oppdagelsesmekanismer for å finne data:
|
||||
|
||||
| Oppdagelsesmetode | Beskrivelse | Beste for |
|
||||
|---|---|---|
|
||||
| **Nøkkelordsøk** | Fritekst-søk på tvers av katalogen | Kjent datasett-navn |
|
||||
| **Naturlig språk (preview)** | AI-drevet søk med forretningskontekst | Utforskende oppdagelse |
|
||||
| **Governance domain-browsing** | Naviger etter forretningsdomene | Organisasjonsstruktur |
|
||||
| **Data product-søk** | Finn kuraterte datasett-pakker | AI-klare datasett |
|
||||
| **Filtreringsbasert** | Filtrering på attributter, eiere, labels | Målrettet søk |
|
||||
|
||||
### Naturlig språk-søk
|
||||
|
||||
```
|
||||
Eksempler på naturlig språk-søk (preview):
|
||||
|
||||
Søk: "Jeg trenger tre år med trafikkdata fra Statens vegvesen
|
||||
for å analysere rushtrafikk-mønstre"
|
||||
Resultat: Data products med trafikktelledata, reisehastighetsmålinger
|
||||
|
||||
Søk: "Finn sertifiserte kundedata med kundeID, navn og adresse"
|
||||
Resultat: Data products med masterdata for kunder
|
||||
|
||||
Søk: "Vis meg Power BI-rapporter om tilstandsdata for broer"
|
||||
Resultat: Rapporter og underliggende datasett for bro-tilstand
|
||||
|
||||
Søk: "Jeg jobber med prediktiv vedlikehold.
|
||||
Vis sensordata fra veisensorer"
|
||||
Resultat: IoT-sensordata, vedlikeholdshistorikk-datasett
|
||||
```
|
||||
|
||||
### Søkearkitektur
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────┐
|
||||
│ Purview Unified Catalog │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ │
|
||||
│ │ Keyword │ │ Natural │ │ Browse by │ │
|
||||
│ │ Search │ │ Language │ │ Domain │ │
|
||||
│ │ │ │ (preview) │ │ │ │
|
||||
│ └──────┬──────┘ └──────┬──────┘ └──────┬───────┘ │
|
||||
│ │ │ │ │
|
||||
│ └────────────────┼────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌───────────▼────────────┐ │
|
||||
│ │ Search Index │ │
|
||||
│ │ (Data Map metadata) │ │
|
||||
│ └───────────┬────────────┘ │
|
||||
│ │ │
|
||||
│ ┌────────────────┼────────────────┐ │
|
||||
│ │ │ │ │
|
||||
│ ┌──────▼──────┐ ┌─────▼──────┐ ┌─────▼──────┐ │
|
||||
│ │ Data Assets │ │ Data │ │ Glossary │ │
|
||||
│ │ (tabeller, │ │ Products │ │ Terms │ │
|
||||
│ │ filer) │ │ │ │ │ │
|
||||
│ └─────────────┘ └────────────┘ └────────────┘ │
|
||||
│ │
|
||||
│ Søkeattributter: │
|
||||
│ - Asset-navn, beskrivelse, forretningsbruk │
|
||||
│ - Governance domain-navn og beskrivelse │
|
||||
│ - Glossary term-navn og definisjoner │
|
||||
│ - Data product tilknyttede assets │
|
||||
│ - OKR-er og kritiske dataelementer │
|
||||
└────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Filtrering og fasettert søk
|
||||
|
||||
```python
|
||||
# Programmatisk søk i Purview Catalog
|
||||
def search_catalog(purview_endpoint, token, query, filters=None):
|
||||
"""Søk i Purview-katalogen med valgfrie filtre."""
|
||||
url = f"{purview_endpoint}/catalog/api/search/query"
|
||||
headers = {"Authorization": f"Bearer {token}"}
|
||||
|
||||
body = {
|
||||
"keywords": query,
|
||||
"limit": 25,
|
||||
"offset": 0,
|
||||
"orderby": [{"name": "ASC"}]
|
||||
}
|
||||
|
||||
# Legg til filtre
|
||||
if filters:
|
||||
body["filter"] = filters
|
||||
|
||||
response = requests.post(url, headers=headers, json=body)
|
||||
return response.json()
|
||||
|
||||
# Eksempel: Finn alle Lakehouse-tabeller i et spesifikt workspace
|
||||
results = search_catalog(
|
||||
endpoint, token,
|
||||
query="customer transactions",
|
||||
filters={
|
||||
"and": [
|
||||
{"entityType": "azure_datalake_gen2_path"},
|
||||
{"classification": "MICROSOFT.PERSONAL.NAME"},
|
||||
{"label": "Fortrolig"}
|
||||
]
|
||||
}
|
||||
)
|
||||
|
||||
# Vis resultater med relevans-score
|
||||
for item in results.get("value", []):
|
||||
print(f"Navn: {item['name']}")
|
||||
print(f" Type: {item['entityType']}")
|
||||
print(f" Kvalifisert navn: {item['qualifiedName']}")
|
||||
print(f" Eier: {item.get('owner', 'Ukjent')}")
|
||||
print(f" Score: {item.get('@search.score', 'N/A')}")
|
||||
print(f" Beskrivelse: {item.get('description', 'Ingen')[:100]}")
|
||||
print()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Business Glossaries and Taxonomies
|
||||
|
||||
### Forretningsglossar i Unified Catalog
|
||||
|
||||
Business glossary knytter forretningsvokabular til tekniske assets, noe som er kritisk for at domeneeksperter skal finne relevante data for AI-prosjekter:
|
||||
|
||||
| Komponent | Funksjon | AI-relevans |
|
||||
|---|---|---|
|
||||
| **Glossary Terms** | Forretningsdefinisjoner knyttet til data | Feature-forståelse for ML |
|
||||
| **Synonymer** | Alternative termer for samme begrep | Bedre søkeresultater |
|
||||
| **Akronymer** | Forkortelser og initialord | Standardisering |
|
||||
| **Hierarki (Parent/child)** | Taksonomisk organisering | Domene-navigering |
|
||||
| **Custom Attributes** | Egendefinerte metadata-felter | Prosjektspesifikk kontekst |
|
||||
| **Ressurser** | Lenker til dokumentasjon | Kontekstuell informasjon |
|
||||
|
||||
### Glosarstruktur for AI-prosjekter
|
||||
|
||||
```
|
||||
Governance Domain: "AI og Maskinlæring"
|
||||
├── Glossary Terms
|
||||
│ ├── "Treningsdata"
|
||||
│ │ ├── Definisjon: "Datasett brukt til å trene ML-modeller"
|
||||
│ │ ├── Synonymer: "Training data", "Opplæringsdata"
|
||||
│ │ ├── Relaterte termer: "Valideringsdata", "Testdata"
|
||||
│ │ ├── Tilknyttede assets: bronze.raw_*, silver.validated_*
|
||||
│ │ └── Policy: Krever dataeier-godkjenning
|
||||
│ │
|
||||
│ ├── "Feature"
|
||||
│ │ ├── Definisjon: "Beregnet variabel brukt som input til ML-modell"
|
||||
│ │ ├── Synonymer: "Prediktor", "Forklaringsvariabel"
|
||||
│ │ ├── Sub-termer:
|
||||
│ │ │ ├── "Numerisk feature"
|
||||
│ │ │ ├── "Kategorisk feature"
|
||||
│ │ │ └── "Temporal feature"
|
||||
│ │ └── Tilknyttede assets: gold.customer_features
|
||||
│ │
|
||||
│ ├── "Ground Truth"
|
||||
│ │ ├── Definisjon: "Verifisert korrekt label for supervised learning"
|
||||
│ │ ├── Kvalitetskrav: "Minst 2 uavhengige annotører"
|
||||
│ │ └── Policy: Krever kvalitetsscore >= 95%
|
||||
│ │
|
||||
│ ├── "Personopplysning"
|
||||
│ │ ├── Definisjon: "Opplysning som kan knyttes til identifiserbar person"
|
||||
│ │ ├── Akronym: "PII"
|
||||
│ │ ├── Regulering: GDPR Art. 4(1)
|
||||
│ │ └── Policy: Automatisk anonymisering i ML-pipelines
|
||||
│ │
|
||||
│ └── "Modelldrift"
|
||||
│ ├── Definisjon: "Endring i modellytelse over tid"
|
||||
│ ├── Synonymer: "Model drift", "Concept drift"
|
||||
│ └── Tilknyttede assets: monitoring.drift_metrics
|
||||
|
||||
Governance Domain: "Veiforvaltning"
|
||||
├── Glossary Terms
|
||||
│ ├── "AADT"
|
||||
│ │ ├── Definisjon: "Årsdøgntrafikk - gjennomsnittlig daglig trafikk"
|
||||
│ │ ├── Synonym: "Annual Average Daily Traffic"
|
||||
│ │ └── Tilknyttede assets: traffic.aadt_measurements
|
||||
│ │
|
||||
│ ├── "ÅDT"
|
||||
│ │ ├── Definisjon: "Døgntrafikk for et enkelt år"
|
||||
│ │ └── Relatert: "AADT"
|
||||
│ │
|
||||
│ └── "Tilstandsgrad"
|
||||
│ ├── Definisjon: "Skala 0-5 for tilstandsvurdering av veiobjekter"
|
||||
│ ├── Sub-termer:
|
||||
│ │ ├── "TG0 - Ingen avvik"
|
||||
│ │ ├── "TG1 - Mindre avvik"
|
||||
│ │ ├── "TG2 - Moderate avvik"
|
||||
│ │ └── "TG3 - Alvorlige avvik"
|
||||
│ └── Tilknyttede assets: nvdb.condition_assessments
|
||||
```
|
||||
|
||||
### Opprette glossary terms programmatisk
|
||||
|
||||
```python
|
||||
# Opprett glossary terms via Purview REST API
|
||||
def create_glossary_term(purview_endpoint, token, term_data):
|
||||
"""Opprett en ny glossary term i Purview Unified Catalog."""
|
||||
url = f"{purview_endpoint}/catalog/api/atlas/v2/glossary/term"
|
||||
headers = {
|
||||
"Authorization": f"Bearer {token}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
payload = {
|
||||
"name": term_data["name"],
|
||||
"qualifiedName": f"{term_data['name']}@Glossary",
|
||||
"longDescription": term_data["definition"],
|
||||
"abbreviation": term_data.get("abbreviation"),
|
||||
"anchor": {
|
||||
"glossaryGuid": term_data["glossary_guid"]
|
||||
},
|
||||
"attributes": {
|
||||
"dataOwner": term_data.get("owner"),
|
||||
"regulatoryRequirement": term_data.get("regulation")
|
||||
}
|
||||
}
|
||||
|
||||
response = requests.post(url, headers=headers, json=payload)
|
||||
return response.json()
|
||||
|
||||
# Eksempel: Batch-opprett termer for AI-domenet
|
||||
ai_terms = [
|
||||
{
|
||||
"name": "Treningsdata",
|
||||
"definition": "Datasett brukt til å trene ML-modeller. "
|
||||
"Skal være representativt for populasjonen modellen "
|
||||
"skal predikere på.",
|
||||
"abbreviation": "TD",
|
||||
"glossary_guid": ai_glossary_guid,
|
||||
"owner": "ml-team@vegvesen.no",
|
||||
"regulation": "GDPR Art. 6 - Lovlig behandlingsgrunnlag"
|
||||
},
|
||||
{
|
||||
"name": "Feature Store",
|
||||
"definition": "Sentralisert repository for beregning, lagring og "
|
||||
"servering av ML-features med punkt-i-tid korrekthet.",
|
||||
"glossary_guid": ai_glossary_guid,
|
||||
"owner": "data-engineering@vegvesen.no"
|
||||
},
|
||||
{
|
||||
"name": "Dataminimering",
|
||||
"definition": "Prinsipp om at kun nødvendige personopplysninger "
|
||||
"samles inn og behandles. Hjemlet i GDPR Art. 5(1)(c).",
|
||||
"glossary_guid": ai_glossary_guid,
|
||||
"regulation": "GDPR Art. 5(1)(c)"
|
||||
}
|
||||
]
|
||||
|
||||
for term in ai_terms:
|
||||
result = create_glossary_term(endpoint, token, term)
|
||||
print(f"Opprettet: {result['name']} (GUID: {result['guid']})")
|
||||
```
|
||||
|
||||
### Taksonomisk hierarki
|
||||
|
||||
```
|
||||
Hierarki-visning i Purview:
|
||||
Unified Catalog > Catalog Management > Governance Domains > Glossary Terms
|
||||
|
||||
Visningsalternativer:
|
||||
├── Liste-visning -- Flat liste med sortering
|
||||
├── Kompakt liste -- Fortetting for oversikt
|
||||
└── Tre-visning -- Hierarkisk parent/child-struktur
|
||||
|
||||
Eksempel tre-visning:
|
||||
Data
|
||||
├── Strukturert data
|
||||
│ ├── Relasjonell data
|
||||
│ │ ├── Transaksjonstabell
|
||||
│ │ └── Dimensjonstabell
|
||||
│ └── Tidsseriedata
|
||||
│ ├── Sensordata
|
||||
│ └── Hendelsesdata
|
||||
├── Semi-strukturert data
|
||||
│ ├── JSON-dokumenter
|
||||
│ └── XML-meldinger
|
||||
└── Ustrukturert data
|
||||
├── Tekst
|
||||
│ ├── Fritekst-notater
|
||||
│ └── E-postkorrespondanse
|
||||
└── Bilder
|
||||
├── Satellittbilder
|
||||
└── Inspeksjonsfoto
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Owner and Steward Assignments
|
||||
|
||||
### Roller i Purview Unified Catalog
|
||||
|
||||
Purview definerer tydelige roller for datastyring som mapper til norske forvaltningsmønstre:
|
||||
|
||||
| Rolle | Purview-navn | Rettigheter | Norsk ekvivalent |
|
||||
|---|---|---|---|
|
||||
| **Global Catalog Reader** | Unified Catalog Reader | Les publiserte artefakter | Innsyn |
|
||||
| **Local Catalog Reader** | Domain-spesifikk leser | Les innenfor et domene | Saksbehandler |
|
||||
| **Governance Domain Creator** | Domain Creator | Opprette domener | Avdelingsleder |
|
||||
| **Data Product Owner** | Product Owner | Opprette/oppdatere data products | Fagansvarlig |
|
||||
| **Data Steward** | Steward | Opprette glossary terms, policies | Informasjonsforvalter |
|
||||
| **Data Health Reader** | Health Reader | Les helserapporter | Controller |
|
||||
| **Data Profile Reader** | Profile Reader | Se profileringsinnsikt | Analytiker |
|
||||
|
||||
### Rollebasert tilgangsmodell
|
||||
|
||||
```
|
||||
Governance Domain: "AI og Maskinlæring"
|
||||
│
|
||||
├── Domain Owner: Seksjonsleder AI-avdelingen
|
||||
│ - Rettigheter: Full kontroll over domenet
|
||||
│ - Ansvar: Strategisk retning, delegering
|
||||
│
|
||||
├── Data Stewards: Informasjonsforvaltere
|
||||
│ - Rettigheter: Opprette/redigere glossary terms, policies
|
||||
│ - Ansvar: Datakvalitet, klassifisering, compliance
|
||||
│
|
||||
├── Data Product Owners: ML-ingeniører
|
||||
│ - Rettigheter: Opprette/oppdatere data products
|
||||
│ - Ansvar: Kuratere AI-klare datasett
|
||||
│
|
||||
└── Catalog Readers: Dataforskere, analytikere
|
||||
- Rettigheter: Søke, browse, be om tilgang
|
||||
- Ansvar: Finne og bruke data ansvarlig
|
||||
```
|
||||
|
||||
### Tilordne eiere og forvaltere
|
||||
|
||||
```python
|
||||
# Tilordne dataeier via Purview REST API
|
||||
def assign_data_owner(purview_endpoint, token, asset_guid, owner_info):
|
||||
"""Tilordne dataeier til et asset i Purview."""
|
||||
url = f"{purview_endpoint}/catalog/api/atlas/v2/entity/guid/{asset_guid}"
|
||||
headers = {
|
||||
"Authorization": f"Bearer {token}",
|
||||
"Content-Type": "application/json"
|
||||
}
|
||||
|
||||
# Hent eksisterende asset
|
||||
response = requests.get(url, headers=headers)
|
||||
asset = response.json()
|
||||
|
||||
# Oppdater eierskap
|
||||
asset["entity"]["attributes"]["owner"] = owner_info["email"]
|
||||
|
||||
# Legg til kontakt-metadata
|
||||
contacts = asset["entity"].get("contacts", {})
|
||||
contacts["Owner"] = [{
|
||||
"id": owner_info["aad_object_id"],
|
||||
"info": owner_info["email"]
|
||||
}]
|
||||
contacts["Expert"] = [{
|
||||
"id": owner_info.get("expert_aad_id"),
|
||||
"info": owner_info.get("expert_email")
|
||||
}]
|
||||
asset["entity"]["contacts"] = contacts
|
||||
|
||||
# Oppdater asset
|
||||
update_response = requests.put(
|
||||
f"{purview_endpoint}/catalog/api/atlas/v2/entity",
|
||||
headers=headers,
|
||||
json={"entity": asset["entity"]}
|
||||
)
|
||||
return update_response.json()
|
||||
|
||||
# Eksempel: Tilordne eierskap for ML-datasett
|
||||
assign_data_owner(endpoint, token, gold_features_guid, {
|
||||
"email": "ml-team@vegvesen.no",
|
||||
"aad_object_id": "abc-123-def",
|
||||
"expert_email": "data-scientist@vegvesen.no",
|
||||
"expert_aad_id": "ghi-456-jkl"
|
||||
})
|
||||
```
|
||||
|
||||
### Governance Domain-oppsett for AI
|
||||
|
||||
```
|
||||
Oppsett av Governance Domain for AI-prosjekter:
|
||||
|
||||
1. Opprett domene:
|
||||
Purview Portal > Unified Catalog > Catalog Management > Governance Domains
|
||||
- Navn: "AI og Maskinlæring"
|
||||
- Type: Functional Unit
|
||||
- Beskrivelse: "Datastyring for alle AI/ML-initiativer"
|
||||
|
||||
2. Tilordne roller:
|
||||
- Domain Owner: AI-seksjonsleder
|
||||
- Stewards: Informasjonsforvaltere (2-3 personer)
|
||||
- Data Product Owners: ML-ingeniører per prosjekt
|
||||
|
||||
3. Konfigurer data estate mappings:
|
||||
- Map til Data Map-samlinger med AI-relaterte assets
|
||||
- Inkluder Fabric workspaces for ML
|
||||
|
||||
4. Opprett data products:
|
||||
- "Customer 360 for Churn" -- Kundedatasett for churn-prediksjon
|
||||
- "Traffic Sensor Features" -- Sensordata for trafikkanalyse
|
||||
- "Bridge Condition ML Set" -- Bro-tilstandsdata for vedlikeholds-ML
|
||||
|
||||
5. Definer glossary terms:
|
||||
- AI-spesifikke termer (se seksjon over)
|
||||
- Domenespesifikke termer (vei, trafikk, infrastruktur)
|
||||
|
||||
6. Sett OKR-er:
|
||||
- "90% av AI-datasett har dokumentert eierskap innen Q2"
|
||||
- "100% av datasett med PII er klassifisert"
|
||||
- "Gjennomsnittlig tid til data-oppdagelse < 15 min"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Usage Analytics and Popularity Metrics
|
||||
|
||||
### Data Estate Health og Insights
|
||||
|
||||
Purview tilbyr analytikk for å forstå hvordan data brukes på tvers av organisasjonen:
|
||||
|
||||
| Metrikk | Kilde | AI-relevans |
|
||||
|---|---|---|
|
||||
| **Skanningsdekning** | Data Map skanning | Andel registrerte AI-datakilder |
|
||||
| **Klassifiseringsdekning** | Auto-klassifisering | Andel klassifisert treningsdata |
|
||||
| **Glossary-tilknytning** | Business glossary | Andel assets med forretningskontekst |
|
||||
| **Eierskap** | Kontakter/eiere | Andel assets med definert eier |
|
||||
| **Health Score** | Health Controls | Samlet governance-modenhet |
|
||||
| **Data Quality Score** | Data Quality rules | Datakvalitet per domene |
|
||||
|
||||
### Health Controls og Health Actions
|
||||
|
||||
```
|
||||
Purview Health Management:
|
||||
|
||||
Health Controls (automatisk evaluering):
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Kontroll │ Mål │ Status │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ Assets med eier │ > 90% │ ✓ 92% │
|
||||
│ Assets med beskrivelse │ > 80% │ ⚠ 74% │
|
||||
│ Assets med glossary term │ > 70% │ ✗ 45% │
|
||||
│ Klassifiserte sensitive │ 100% │ ⚠ 88% │
|
||||
│ Data products med SLA │ > 80% │ ✓ 85% │
|
||||
│ Governance domains med OKR │ 100% │ ✓ 100% │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
Health Score: 74/100
|
||||
Forbedringsaksjoner:
|
||||
1. Tilordne glossary terms til 153 utaggede assets
|
||||
2. Legg til beskrivelse for 12 Lakehouse-tabeller
|
||||
3. Klassifiser 7 datasett med potensielt sensitiv data
|
||||
```
|
||||
|
||||
### Data Products som AI-klare datasett
|
||||
|
||||
```
|
||||
Data Product: "Customer 360 for Churn Prediction"
|
||||
┌────────────────────────────────────────────────────┐
|
||||
│ Eier: ML Engineering Team │
|
||||
│ Domene: AI og Maskinlæring │
|
||||
│ Brukstilfelle: Churn-prediksjon for kundeservice │
|
||||
│ Oppdatering: Daglig (pipeline kl 02:00) │
|
||||
│ │
|
||||
│ Inneholder: │
|
||||
│ ├── gold.customer_features (Lakehouse-tabell) │
|
||||
│ ├── gold.transaction_aggregates (Lakehouse-tabell) │
|
||||
│ ├── gold.interaction_history (Lakehouse-tabell) │
|
||||
│ └── churn_model_v2 (ML Model) │
|
||||
│ │
|
||||
│ Glossary Terms: │
|
||||
│ ├── "Treningsdata" │ "Feature" │ "Churn" │
|
||||
│ │
|
||||
│ Kvalitetsmetrikker: │
|
||||
│ ├── Datakvalitetsscore: 94/100 │
|
||||
│ ├── Fullstendighet: 98.2% │
|
||||
│ ├── Nøyaktighet: 96.5% │
|
||||
│ └── Tidslinjer: Oppdatert < 24 timer │
|
||||
│ │
|
||||
│ Tilgangspolicy: │
|
||||
│ ├── Standard: Read (alle i ML-teamet) │
|
||||
│ └── Forespørsel: Self-service via Purview │
|
||||
│ │
|
||||
│ Brukskrav: │
|
||||
│ ├── Kun for intern ML-trening │
|
||||
│ ├── Ikke eksporter utenfor Fabric │
|
||||
│ └── Logg all bruk i audit-trail │
|
||||
└────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Purview Analytics i OneLake
|
||||
|
||||
For avansert bruksanalyse kan Purview-metadata eksporteres til OneLake:
|
||||
|
||||
```python
|
||||
# Eksporter Purview analytics til Fabric for videre analyse
|
||||
# Purview Analytics in OneLake gir tilgang til katalog-metadata i Fabric
|
||||
|
||||
# I Fabric Notebook: Les Purview analytics-data
|
||||
catalog_data = spark.read.format("delta").load(
|
||||
"abfss://purview-analytics@onelake.dfs.fabric.microsoft.com/catalog"
|
||||
)
|
||||
|
||||
# Analyser mest brukte datasett
|
||||
popular_assets = (
|
||||
catalog_data
|
||||
.filter(col("assetType") == "azure_datalake_gen2_path")
|
||||
.groupBy("qualifiedName", "name")
|
||||
.agg(
|
||||
F.count("accessEvent").alias("access_count"),
|
||||
F.countDistinct("userId").alias("unique_users"),
|
||||
F.max("accessTimestamp").alias("last_accessed")
|
||||
)
|
||||
.orderBy(F.desc("access_count"))
|
||||
)
|
||||
|
||||
popular_assets.show(10)
|
||||
|
||||
# Identifiser "mørke data" -- registrerte men ubrukte assets
|
||||
from pyspark.sql.functions import datediff, current_date
|
||||
|
||||
dark_data = (
|
||||
catalog_data
|
||||
.filter(col("assetType") == "azure_datalake_gen2_path")
|
||||
.groupBy("qualifiedName", "name", "owner")
|
||||
.agg(
|
||||
F.max("accessTimestamp").alias("last_accessed"),
|
||||
F.count("accessEvent").alias("total_access")
|
||||
)
|
||||
.filter(
|
||||
(datediff(current_date(), col("last_accessed")) > 180) |
|
||||
(col("total_access") < 5)
|
||||
)
|
||||
.orderBy("last_accessed")
|
||||
)
|
||||
|
||||
print(f"Antall 'mørke data' assets (ubrukt > 6 mnd): {dark_data.count()}")
|
||||
dark_data.show(20)
|
||||
```
|
||||
|
||||
### Oppdagelsesmetrikker for AI-team
|
||||
|
||||
```python
|
||||
# Dashboard-metrikker for AI-datadoppdagelse
|
||||
def calculate_discovery_metrics(purview_endpoint, token, domain_id):
|
||||
"""Beregn oppdagelsesmetrikker for et governance domain."""
|
||||
metrics = {}
|
||||
|
||||
# 1. Tidsbruk på dataoppdagelse
|
||||
metrics["avg_discovery_time_minutes"] = 12 # Fra brukerundersøkelse
|
||||
|
||||
# 2. Dekningsgrad
|
||||
all_assets = search_catalog(endpoint, token, "*",
|
||||
filters={"governanceDomain": domain_id})
|
||||
classified_assets = search_catalog(endpoint, token, "*",
|
||||
filters={
|
||||
"and": [
|
||||
{"governanceDomain": domain_id},
|
||||
{"hasClassification": True}
|
||||
]
|
||||
})
|
||||
|
||||
total = all_assets.get("@search.count", 0)
|
||||
classified = classified_assets.get("@search.count", 0)
|
||||
|
||||
metrics["total_assets"] = total
|
||||
metrics["classified_assets"] = classified
|
||||
metrics["classification_coverage"] = (
|
||||
round(classified / total * 100, 1) if total > 0 else 0
|
||||
)
|
||||
|
||||
# 3. Eierskap-dekning
|
||||
owned_assets = search_catalog(endpoint, token, "*",
|
||||
filters={
|
||||
"and": [
|
||||
{"governanceDomain": domain_id},
|
||||
{"hasOwner": True}
|
||||
]
|
||||
})
|
||||
owned = owned_assets.get("@search.count", 0)
|
||||
metrics["ownership_coverage"] = (
|
||||
round(owned / total * 100, 1) if total > 0 else 0
|
||||
)
|
||||
|
||||
# 4. Data product-dekning
|
||||
# Hvor mange assets er del av et data product?
|
||||
metrics["data_product_count"] = 5
|
||||
metrics["assets_in_products"] = 42
|
||||
metrics["product_coverage"] = (
|
||||
round(42 / total * 100, 1) if total > 0 else 0
|
||||
)
|
||||
|
||||
return metrics
|
||||
|
||||
# Output:
|
||||
# {
|
||||
# "avg_discovery_time_minutes": 12,
|
||||
# "total_assets": 156,
|
||||
# "classified_assets": 139,
|
||||
# "classification_coverage": 89.1,
|
||||
# "ownership_coverage": 93.4,
|
||||
# "data_product_count": 5,
|
||||
# "assets_in_products": 42,
|
||||
# "product_coverage": 26.9
|
||||
# }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Learn about Microsoft Purview Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog) -- Oversikt over Unified Catalog
|
||||
- [Data governance with Microsoft Purview](https://learn.microsoft.com/en-us/purview/data-governance-overview) -- Data governance oversikt
|
||||
- [Get started with Microsoft Purview data governance](https://learn.microsoft.com/en-us/purview/data-governance-get-started) -- Oppstart-guide
|
||||
- [Governance domains in Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog-governance-domains) -- Governance domains oversikt
|
||||
- [Create and manage governance domains](https://learn.microsoft.com/en-us/purview/unified-catalog-governance-domains-create-manage) -- Opprette og administrere domener
|
||||
- [Data products in Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog-data-products) -- Data products-konsept
|
||||
- [Search for data products](https://learn.microsoft.com/en-us/purview/unified-catalog-data-products-search) -- Søk etter data products
|
||||
- [Glossary terms in Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms) -- Business glossary
|
||||
- [Create and manage glossary terms](https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms-create-manage) -- Opprette glossary terms
|
||||
- [Data governance roles and permissions](https://learn.microsoft.com/en-us/purview/data-governance-roles-permissions) -- Roller og tillatelser
|
||||
- [Use Microsoft Purview to govern Microsoft Fabric](https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric) -- Purview-Fabric-integrasjon
|
||||
- [Critical data elements](https://learn.microsoft.com/en-us/purview/unified-catalog-critical-data-elements) -- Kritiske dataelementer
|
||||
- [OKRs in Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog-okrs) -- OKR-er for datastyring
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren trenger hjelp med å sette opp datakatalogisering, organisere data for AI-prosjekter, eller etablere informasjonsforvaltning med Purview Unified Catalog.
|
||||
- For norsk offentlig sektor: **Governance Domains** mapper naturlig til avdelinger/seksjoner i etaten. Anbefal å opprette domener som speiler organisasjonsstrukturen (f.eks. "AI og Maskinlæring", "Veiforvaltning", "Trafikkstyring").
|
||||
- **Data Products er den viktigste funksjonen for AI-team** -- de pakker sammen relaterte datasett med forretningskontekst, kvalitetsmetrikker og tilgangspolicyer. Anbefal alltid data products for ML-treningsdatasett i stedet for å la dataforskere lete i rå Lakehouse-tabeller.
|
||||
- **Business Glossary** er undervurdert men kritisk. Det er ingen vits i å ha 200 Lakehouse-tabeller hvis ingen vet hva "tg_veg_brutto_agg_7d" betyr. Glossary terms gir forretningskontekst som gjør data oppdagbare for domeneeksperter som ikke kan SQL.
|
||||
- **Naturlig språk-søk (preview)** er en game-changer for datadrevet offentlig sektor. Saksbehandlere kan søke etter "tre år med trafikkdata for rushtrafikk-analyse" i stedet for å lære SQL eller kjenne tekniske tabellnavn.
|
||||
- Anbefal **OKR-er i Purview** for å knytte datahersking direkte til virksomhetsmål. Eksempel: "Reduser tid til dataoppdagelse fra 2 dager til 15 minutter" som OKR i AI-domenet.
|
||||
- Kombiner med **microsoft-purview-governance.md** for klassifisering/lineage og **data-versioning-lineage.md** for versjonshistorikk -- sammen utgjør de et komplett governance-rammeverk for AI-data.
|
||||
|
|
@ -0,0 +1,741 @@
|
|||
# Data Factory AI-Driven Pipelines
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA (Azure Data Factory), GA (Fabric Data Factory)
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure Data Factory og Fabric Data Factory er Microsofts orkestreringsteknologier for data engineering-arbeidsflyter som understøtter AI-scenarioer. Teknologien lar deg automatisere dataprosessering, transformasjon, og orkestrering av machine learning-pipelines i storskalerte miljøer.
|
||||
|
||||
**Kjernefunksjonalitet:**
|
||||
- **ETL/ELT-orkestrator:** Ekstrakter data fra 170+ kilder, transformerer, og laster i lakehouse/warehouse
|
||||
- **AI-integrasjon:** Direkte aktiviteter for Azure Machine Learning, Spark, Databricks, og egendefinert ML-kode
|
||||
- **Copilot-drevet design:** Natural language-beskrivelser genererer pipeline-logikk (kun Fabric)
|
||||
- **Skalerbarhet:** Håndterer petabyte-skala med automatisk parallelisering og intelligent throughput-optimalisering
|
||||
|
||||
**Viktig forskjell:**
|
||||
Azure Data Factory (ADF) er PaaS-løsning med Azure-integrasjon. Fabric Data Factory er SaaS-løsning med innebygd OneLake, workspace-integrasjon, og AI-forbedringer. Fabric anbefales for nye AI-prosjekter.
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### Pipeline-arkitektur
|
||||
|
||||
| Komponent | Beskrivelse | Typisk bruk for AI-scenarioer |
|
||||
|-----------|-------------|-------------------------------|
|
||||
| **Pipeline** | Logisk gruppering av aktiviteter som utfører en oppgave | ML feature engineering workflow, batch inference-orkestrer, retraining-trigger |
|
||||
| **Activity** | Utførbare steg (Copy, Notebook, ML Execute, Web, etc.) | Azure ML Pipeline Run, Databricks Notebook, Custom Python Script, Batch Endpoint invoke |
|
||||
| **Linked Service** | Tilkobling til datakilde/compute (Azure Storage, AML Workspace, Databricks) | ML workspace-tilkobling, feature store, inference endpoint |
|
||||
| **Dataset** | Abstraksjon av data-input/output | Training data, inference batch input, prediction output table |
|
||||
| **Trigger** | Hva starter pipeline (schedule, event, tumbling window) | Daglig retraining (schedule), data arrival event (storage event trigger) |
|
||||
| **Integration Runtime** | Compute-miljø som kjører aktiviteter | Self-hosted IR for on-prem data, Azure IR for cloud data, Azure-SSIS IR for SSIS packages |
|
||||
|
||||
**Aktivitetstyper med AI-relevans:**
|
||||
|
||||
```json
|
||||
{
|
||||
"AI/ML-aktiviteter": [
|
||||
"AzureMLExecutePipeline",
|
||||
"AzureMLBatchExecution",
|
||||
"DatabricksNotebook",
|
||||
"DatabricksSparkJar/Python",
|
||||
"SynapseNotebook",
|
||||
"FabricNotebook"
|
||||
],
|
||||
"Data prep for AI": [
|
||||
"Copy",
|
||||
"DataFlowGen2",
|
||||
"ExecuteSQLStoredProcedure",
|
||||
"LookupActivity"
|
||||
],
|
||||
"Orkestreringslogikk": [
|
||||
"ForEach",
|
||||
"IfCondition",
|
||||
"Until",
|
||||
"Wait",
|
||||
"WebActivity"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Azure Machine Learning-integrasjon
|
||||
|
||||
**Azure ML Execute Pipeline Activity** (primær pattern):
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "InvokeMLTraining",
|
||||
"type": "AzureMLExecutePipeline",
|
||||
"linkedServiceName": {
|
||||
"referenceName": "AzureMLService",
|
||||
"type": "LinkedServiceReference"
|
||||
},
|
||||
"typeProperties": {
|
||||
"mlPipelineId": "abc-123-pipeline-id",
|
||||
"experimentName": "fraud-detection-v2",
|
||||
"mlPipelineParameters": {
|
||||
"learning_rate": "0.001",
|
||||
"batch_size": "32",
|
||||
"data_path": "@pipeline().parameters.trainingDataPath"
|
||||
},
|
||||
"continueOnStepFailure": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Batch Endpoint invokering** (inferens):
|
||||
|
||||
Data Factory kan kalle batch endpoints via Web Activity + REST API eller direkte Azure ML Activity (Fabric Data Factory). Typisk mønster:
|
||||
|
||||
1. Data Factory kopierer data til input-lokasjon
|
||||
2. Web Activity invoker batch endpoint med data-referanse
|
||||
3. Poller for jobbstatus
|
||||
4. Kopierer predictions til warehouse/lakehouse
|
||||
|
||||
**Retraining-pattern:**
|
||||
|
||||
```
|
||||
[LookupWatermark] → [LookupMaxValue] → [IncrementalCopy] →
|
||||
[AzureMLExecutePipeline (training)] → [AzureMLUpdateResource (deploy)] →
|
||||
[StoredProcedureToUpdateWatermark]
|
||||
```
|
||||
|
||||
**Fabric-spesifikke AI-funksjoner:**
|
||||
- **Azure Machine Learning Activity** (native): Enklere konfigurasjon enn ADF, batch endpoint + pipeline (v1) support
|
||||
- **Copilot for Data Factory**: Natural language → pipeline-generering ("Create a pipeline that trains a model daily")
|
||||
- **Semantic Model Refresh Activity**: Refresh Power BI semantic model etter inferens
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### 1. Batch ML Inference Pipeline
|
||||
|
||||
**Scenario:** Daglig scoring av 10M transaksjoner for fraud detection
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌──────────────┐ ┌────────────────┐ ┌──────────────┐
|
||||
│ Copy from │───▶│ DataFlow Gen2│───▶│ Azure ML Batch │───▶│ Copy results │
|
||||
│ OLTP DB │ │ (feature eng)│ │ Endpoint │ │ to Warehouse │
|
||||
└─────────────┘ └──────────────┘ └────────────────┘ └──────────────┘
|
||||
│ │
|
||||
│ ▼
|
||||
│ ┌──────────────┐
|
||||
│ │ Email/Teams │
|
||||
└───────────────────────────────────│ Notification │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
**Implementeringsdetaljer:**
|
||||
- **Schedule Trigger:** 02:00 UTC daily
|
||||
- **Copy Activity:** Incremental copy fra transaksjonstabell (watermark: LastModifiedDate)
|
||||
- **DataFlow Gen2:** Feature engineering (aggregeringer, window functions, derived columns)
|
||||
- **Web Activity:** POST til batch endpoint med SAS token til staging blob
|
||||
- **Until Activity:** Poll batch job status hvert 30. sekund (timeout 60 min)
|
||||
- **Copy Activity (2):** Copy predictions fra output blob til Synapse/Fabric Warehouse
|
||||
- **Email Activity:** Notify data science team med run statistics
|
||||
|
||||
**Optimal konfigurasjon:**
|
||||
- **Data Movement Units (DMUs):** 32 for millioner av rader
|
||||
- **Degree of Copy Parallelism:** Auto (lar Data Factory kalkulere basert på data-størrelse og DMUs)
|
||||
- **Staging:** Enabled for store datasett (>1 GB) med PolyBase-kompatible formater
|
||||
|
||||
### 2. Model Retraining Orchestration
|
||||
|
||||
**Scenario:** Ukentlig retraining av recommendation model med ny brukerinteraksjon
|
||||
|
||||
```
|
||||
┌──────────────┐ ┌──────────────────┐ ┌──────────────────┐
|
||||
│ Lookup Old │───▶│ Lookup New │───▶│ Incremental Copy │
|
||||
│ Watermark │ │ Watermark (MAX) │ │ (new data only) │
|
||||
└──────────────┘ └──────────────────┘ └──────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────┐
|
||||
│ Azure ML Pipeline │
|
||||
│ (training + eval) │
|
||||
└─────────────────────┘
|
||||
│
|
||||
┌───────────────────────────┴──────────────────┐
|
||||
│ │
|
||||
▼ ▼
|
||||
┌──────────────────┐ ┌─────────────────┐
|
||||
│ If eval metrics │───YES──▶ │ Azure ML Update │
|
||||
│ > threshold │ │ Resource (deploy)│
|
||||
└──────────────────┘ └─────────────────┘
|
||||
│
|
||||
NO
|
||||
▼
|
||||
┌──────────────────┐
|
||||
│ Log to App │
|
||||
│ Insights + alert │
|
||||
└──────────────────┘
|
||||
```
|
||||
|
||||
**Nøkkelaktiviteter:**
|
||||
- **Lookup:** Query `watermarktable` for siste prosesserte timestamp
|
||||
- **Lookup (2):** Query source table for MAX(timestamp) for nye records
|
||||
- **Copy:** SQL filter `WHERE timestamp > @oldWatermark AND timestamp <= @newWatermark`
|
||||
- **Azure ML Execute Pipeline:** Trigger AML pipeline med parameter `data_path`
|
||||
- **If Condition:** `@greater(activity('MLTraining').output.metrics.AUC, 0.92)`
|
||||
- **Azure ML Update Resource:** Deploy ny modell til scoring endpoint (kun hvis AUC > threshold)
|
||||
- **Stored Procedure:** Update watermark til `@newWatermark`
|
||||
|
||||
**Best practice:**
|
||||
- **Idempotency:** Bruk `@pipeline().RunId` i output paths for å unngå overwriting ved retry
|
||||
- **Error handling:** Retry policy (3 attempts, 30s interval) + alerting ved permanent failure
|
||||
- **Cost optimization:** Bruk Azure ML compute clusters med autoscaling (min 0, max 4 nodes)
|
||||
|
||||
### 3. Real-time Streaming + Batch Hybrid
|
||||
|
||||
**Scenario:** IoT sensor data → real-time anomaly detection + daglig modell-retraining
|
||||
|
||||
```
|
||||
Event Hubs ───▶ Stream Analytics ───▶ Azure ML Online Endpoint ───▶ Cosmos DB (anomalies)
|
||||
│ │
|
||||
│ ▼
|
||||
└─────────▶ Append Blob (raw events) ◀───────────────────────────┌──────────────┐
|
||||
│ │ Power BI │
|
||||
▼ │ Dashboard │
|
||||
┌──────────────────┐ └──────────────┘
|
||||
│ Data Factory │
|
||||
│ (nightly batch) │
|
||||
│ - Copy all events│
|
||||
│ - Feature eng │
|
||||
│ - Retrain model │
|
||||
│ - Deploy if better│
|
||||
└──────────────────┘
|
||||
```
|
||||
|
||||
**Data Factory-rolle:**
|
||||
- **Nightly aggregation:** Copy Events → Lakehouse (bronze layer)
|
||||
- **Feature engineering:** DataFlow Gen2 → silver layer
|
||||
- **Retraining:** Azure ML Pipeline med silver data
|
||||
- **Deployment:** Conditional deployment til online endpoint (Azure ML Update Resource activity støtter kun batch endpoints, online endpoints krever ARM templates eller Azure ML SDK via Notebook Activity)
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når bruke Azure Data Factory vs Fabric Data Factory?
|
||||
|
||||
| Kriterium | Azure Data Factory | Fabric Data Factory |
|
||||
|-----------|-------------------|---------------------|
|
||||
| **Integrasjon med Azure ML** | ✅ Native AzureMLExecutePipeline + AzureMLUpdateResource | ⚠️ AzureMLExecutePipeline kun (update resource via REST API) |
|
||||
| **Integrasjon med Fabric AI** | ❌ Ingen direkte integrasjon | ✅ Native Notebook, Semantic Model Refresh, OneLake-optimalisering |
|
||||
| **On-premises data sources** | ✅ Self-hosted Integration Runtime | ⚠️ Self-hosted IR støttes, men mindre fokus på hybrid scenarioer |
|
||||
| **Cost model** | Pay-per-activity + data movement (CU hours) | Capacity-basert (Fabric Capacity Units) |
|
||||
| **CI/CD** | Azure DevOps/GitHub Actions + ARM templates | Built-in deployment pipelines (Git integration) |
|
||||
| **Copilot-funksjonalitet** | ❌ Ikke tilgjengelig | ✅ Natural language pipeline authoring + error explanation |
|
||||
| **Anbefalinger** | Etablerte Azure ML-workloads, hybrid scenarioer, eksplisitt kostnadskontroll per pipeline | Nye AI-prosjekter, Fabric-økosystem (Lakehouse, Warehouse, Power BI), rask prototyping med Copilot |
|
||||
|
||||
### Når bruke Pipeline vs Apache Airflow Job (Fabric)?
|
||||
|
||||
| Kriterium | Pipeline (ADF/Fabric) | Apache Airflow Job (Fabric) |
|
||||
|-----------|----------------------|------------------------------|
|
||||
| **Authoring** | Low-code UI (drag-and-drop) | Code-first (Python DAGs) |
|
||||
| **Persona** | Data integrator, business analyst, data engineer (lav Python-kompetanse) | Apache Airflow users, data engineers (sterk Python-kompetanse) |
|
||||
| **ML orchestration** | Native Azure ML activities | Airflow providers (`apache-airflow-providers-microsoft-azure`) + custom operators |
|
||||
| **Version control** | JSON-filer i Git (via ARM templates eller Fabric Git integration) | Python-filer i Git (native) |
|
||||
| **Dependency management** | Activity-level `dependsOn` (UI-konfigurerbar) | Python-kode (`task1 >> task2`) |
|
||||
| **Use case for AI** | Standardiserte ML-workflows (batch inferens, periodisk retraining), integrasjon med eksisterende Data Factory-pipelines | Komplekse ML-workflows med Python-logikk (hyperparameter tuning loops, conditional model selection), migrering fra on-prem Airflow |
|
||||
|
||||
**Tommelfingerregel:** Start med Pipeline (low-code) for 80% av scenarioer. Gå til Airflow Job hvis du trenger Python-flexibility (custom retry logic, dynamic task generation, complex branching).
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### Azure AI Foundry
|
||||
|
||||
**Pattern:** Data Factory → Azure AI Foundry evaluation run
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "TriggerFoundryEvaluation",
|
||||
"type": "WebActivity",
|
||||
"method": "POST",
|
||||
"url": "https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.MachineLearningServices/workspaces/{workspaceName}/evaluations/{evaluationName}/runs?api-version=2024-01-01-preview",
|
||||
"authentication": {
|
||||
"type": "MSI",
|
||||
"resource": "https://management.azure.com/"
|
||||
},
|
||||
"body": {
|
||||
"datasetId": "@activity('CopyTestData').output.datasetId",
|
||||
"modelId": "@pipeline().parameters.modelId"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Integrasjonspunkter:**
|
||||
- **Prompt flow deployment:** Web Activity kaller prompt flow batch endpoint
|
||||
- **Model evaluation:** Trigger evaluation runs etter model-deployment
|
||||
- **AI Search indexing:** Copy Activity → Azure AI Search (via REST API sink eller custom activity)
|
||||
|
||||
### Copilot Studio
|
||||
|
||||
**Pattern:** Data Factory → Copilot Studio knowledge refresh
|
||||
|
||||
Copilot Studio har ikke native Data Factory connector (per Feb 2026), men kan integreres via:
|
||||
|
||||
1. **SharePoint connector (indirekte):**
|
||||
Data Factory → Copy til SharePoint-liste → Copilot Studio leser fra SharePoint (topic trigger)
|
||||
|
||||
2. **Power Automate bridge:**
|
||||
Data Factory → Power Automate (HTTP trigger via Web Activity) → Copilot Studio (adaptive card eller topic invocation)
|
||||
|
||||
3. **Azure AI Search (anbefalt for RAG-scenarioer):**
|
||||
Data Factory → Copy til Azure AI Search → Copilot Studio bruker search skill
|
||||
|
||||
**Eksempel (Azure AI Search-pattern):**
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "IndexDocuments",
|
||||
"type": "Copy",
|
||||
"source": { "type": "BlobSource" },
|
||||
"sink": {
|
||||
"type": "AzureSearchIndexSink",
|
||||
"writeBehavior": "Merge",
|
||||
"writeBatchSize": 1000
|
||||
},
|
||||
"inputs": [{ "referenceName": "ProcessedDocuments", "type": "DatasetReference" }],
|
||||
"outputs": [{ "referenceName": "AISearchIndex", "type": "DatasetReference" }]
|
||||
}
|
||||
```
|
||||
|
||||
### Power Platform
|
||||
|
||||
**Power Automate + Data Factory:**
|
||||
|
||||
| Integrasjonsretning | Metode | Use case |
|
||||
|---------------------|--------|----------|
|
||||
| Data Factory → Power Automate | Web Activity (HTTP POST til Power Automate webhook) | Notify business users via Teams, Outlook, or Approval workflows |
|
||||
| Power Automate → Data Factory | Azure Data Factory connector (trigger pipeline) | Business-initiated data refresh (e.g., "Approve new training data" button in Teams) |
|
||||
|
||||
**Power BI:**
|
||||
|
||||
- **Fabric Data Factory:** Native Semantic Model Refresh Activity (etter inference pipeline)
|
||||
- **Azure Data Factory:** Web Activity → Power BI REST API (refresh dataset)
|
||||
|
||||
**AI Builder:**
|
||||
|
||||
Data Factory kan ikke direkte kalle AI Builder-modeller (per Feb 2026). Workaround:
|
||||
|
||||
1. Data Factory → Copy data til Dataverse-tabell
|
||||
2. Power Automate flow (trigger on Dataverse row create) → AI Builder model (predict)
|
||||
3. Write prediction back til Dataverse
|
||||
4. Data Factory → Copy fra Dataverse til warehouse
|
||||
|
||||
**Alternativ:** Azure Cognitive Services Activity (hvis AI Builder-scenarioet kan erstattes av Azure AI Services)
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### Governance og compliance
|
||||
|
||||
**Data residency:**
|
||||
- **Azure Data Factory:** Støtter Norway East/West regions. Metadata lagres i region, data kan transient via andre regioner avhengig av Integration Runtime placement.
|
||||
- **Fabric Data Factory:** OneLake-data residency følger Fabric capacity region (Norway West/East tilgjengelig per Q1 2026).
|
||||
|
||||
**Behandling av personopplysninger:**
|
||||
|
||||
| Komponent | GDPR-konsiderasjon | Tiltak |
|
||||
|-----------|-------------------|--------|
|
||||
| **Pipeline-metadata** | Kan inneholde sensitive parametre (personnavn i filbaner, etc.) | Bruk Key Vault-referanser for sensitive verdier, ikke hardkod PII i pipeline JSON |
|
||||
| **Aktivitetslogger** | Logger kan inneholde data samples (feilmeldinger, preview) | Aktiver Secure Output/Secure Input på aktiviteter som håndterer personopplysninger |
|
||||
| **Data lineage** | Data Factory viser data flow (source → sink), kan avsløre sensitive datakilder | Begrens RBAC til pipelines (Reader/Contributor-roller), bruk Private Endpoints for datakilde-tilkoblinger |
|
||||
|
||||
**DPIA-sjekkliste for AI pipelines:**
|
||||
|
||||
- [ ] Er treningsdata anonymisert/pseudonymisert før Azure ML-trening?
|
||||
- [ ] Brukes Managed Identity istedenfor service principals med long-lived secrets?
|
||||
- [ ] Er inference-output lagret i encrypted storage (Azure Storage SSE, Synapse TDE)?
|
||||
- [ ] Logges aktivitetsresultater til Log Analytics med 90-dagers retention?
|
||||
- [ ] Er Private Link konfigurert for Azure ML workspace og storage accounts?
|
||||
|
||||
### Kostnadsoptimalisering (offentlig sektor-kontekst)
|
||||
|
||||
**Capacity-basert vs. consumption-basert (Fabric vs. ADF):**
|
||||
|
||||
| Scenario | Azure Data Factory (consumption) | Fabric (capacity) |
|
||||
|----------|----------------------------------|-------------------|
|
||||
| **Prototyping (10 pipelines/mnd)** | ~500 NOK/mnd (orchestration + small data movement) | Inkludert i F64 capacity (~40k NOK/mnd, deles på tvers av Fabric-workloads) |
|
||||
| **Production (100 pipelines/dag, 100 GB data/dag)** | ~15k NOK/mnd (varies med DMUs og IR hours) | Inkludert i F256 capacity (~160k NOK/mnd), men også inkluderer Lakehouse, Warehouse, Power BI Premium |
|
||||
| **Konklusjon** | **Billigere for isolerte data integration-scenarioer** | **Bedre verdi hvis du allerede bruker Fabric-økosystemet (Power BI Premium, Lakehouse)** |
|
||||
|
||||
**Konfidensmarkør:** 🟢 **Høy** — Prising er offentlig dokumentert, men faktiske kostnader varierer med data volume og kompleksitet (±30% i reelle scenarioer).
|
||||
|
||||
### Anskaffelse
|
||||
|
||||
**Azure Data Factory:**
|
||||
- **Lisensmodell:** Pay-as-you-go (Azure-abonnement) eller Enterprise Agreement
|
||||
- **Leverandørbinding:** Moderat (standard Azure-tjeneste, kan migreres til andre cloud-plattformer med innsats)
|
||||
- **Anskaffelseskategori:** "Skybasert dataintegrasjonstjeneste" (Difi category 48.8)
|
||||
|
||||
**Fabric Data Factory:**
|
||||
- **Lisensmodell:** Capacity-basert (Microsoft Fabric-abonnement)
|
||||
- **Leverandørbinding:** Høy (tett integrert med OneLake, vanskelig å migrere ut)
|
||||
- **Anskaffelseskategori:** "Integrert analyseplattform" (Difi category 48.2)
|
||||
|
||||
**Anbefaling for anskaffelser:** Inkluder migrasjonsklausul i kontrakt hvis Fabric velges ("Leverandør skal levere eksportverktøy for pipelines til åpent format som Apache Airflow DAGs").
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Azure Data Factory
|
||||
|
||||
**Prisingsmodell (per Feb 2026, NOK):**
|
||||
|
||||
| Komponent | Enhet | Pris (Norway East) | Eksempel |
|
||||
|-----------|-------|-------------------|----------|
|
||||
| **Orchestration** | Per activity run | 0.006 NOK | 1000 activity runs = 6 NOK |
|
||||
| **Data Movement** | Per DIU-hour (Data Integration Unit) | 1.80 NOK | 100 GB data (4 DIUs, 1 time) = 7.20 NOK |
|
||||
| **Pipeline activity** | Per activity run (non-copy) | 0.006 NOK | Azure ML Execute Pipeline = 0.006 NOK per run |
|
||||
| **External activity** | Per activity run + compute time | 0.003 NOK/run + compute cost | Databricks Notebook = 0.003 NOK + Databricks DBU cost |
|
||||
| **Self-hosted IR** | Per node-hour | 1.50 NOK | 1 node, 24/7 = 1080 NOK/mnd |
|
||||
|
||||
**TCO-eksempel (AI inference pipeline):**
|
||||
|
||||
```
|
||||
Scenario: Daglig batch inference (1M records, 50 GB data, 30 dager)
|
||||
- Copy Activity (source → staging): 30 runs × 4 DIUs × 0.5h × 1.80 NOK = 108 NOK
|
||||
- DataFlow Gen2: 30 runs × 8 compute hours × 2.40 NOK = 576 NOK
|
||||
- Azure ML Execute Pipeline: 30 runs × 0.006 NOK = 0.18 NOK
|
||||
- Copy Activity (predictions → warehouse): 30 runs × 2 DIUs × 0.25h × 1.80 NOK = 27 NOK
|
||||
- Total Data Factory cost: ~711 NOK/mnd
|
||||
- + Azure ML Batch Endpoint cost (separate, ~5k NOK/mnd for compute)
|
||||
- = Total ~5.7k NOK/mnd
|
||||
```
|
||||
|
||||
### Fabric Data Factory
|
||||
|
||||
**Prisingsmodell (capacity units):**
|
||||
|
||||
| Aktivitetstype | CU consumption rate | Eksempel |
|
||||
|----------------|-------------------|----------|
|
||||
| **Data movement (Copy)** | 1.5 CU/hour per intelligent throughput unit | 100 GB copy (1 time, auto-optimized) = 1.5 CU |
|
||||
| **Orchestration** | 0.0056 CU per activity run | 1000 activity runs = 5.6 CU |
|
||||
| **Dataflow Gen2** | Variable (avhenger av transformasjoner) | Typical 5-20 CU/hour |
|
||||
| **Notebook activity** | Spark compute (separate fra Data Factory) | Billed via Fabric Spark capacity |
|
||||
|
||||
**Fabric Capacity-kostnader (Norge):**
|
||||
|
||||
| Capacity SKU | CU/sekund | Pris/mnd (NOK) | Typisk use case |
|
||||
|--------------|-----------|---------------|-----------------|
|
||||
| F2 | 2 | ~2k | Development/testing |
|
||||
| F64 | 64 | ~40k | Small production (< 10 daily pipelines) |
|
||||
| F256 | 256 | ~160k | Enterprise AI platform (100+ daily pipelines + Power BI + Lakehouse) |
|
||||
|
||||
**Konfidensmarkør:** 🟡 **Moderat** — Fabric-prising endrer seg oftere enn ADF, capacity-consumption er vanskelig å predikere nøyaktig før testing.
|
||||
|
||||
### Kostnadsoptimaliseringsråd
|
||||
|
||||
1. **Auto-pause Self-hosted IR:** Ikke kjør 24/7 hvis kun nattlige jobber (spar ~75% på IR-kostnader)
|
||||
2. **Staging for store datasett:** Aktiver staging med PolyBase for >1 GB copy (reduserer data movement tid med 40-60%)
|
||||
3. **Incremental copy:** Bruk watermark-pattern istedenfor full copy (reduserer data volume med 90-95% etter initial load)
|
||||
4. **Azure ML compute autoscaling:** Min nodes = 0, max nodes = 4 (kun betaler når modell trenes)
|
||||
5. **Fabric capacity reservation:** 1-års reservation gir 20% rabatt på Fabric capacity
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Systemkarakteristikk
|
||||
|
||||
**Data Factory (ADF/Fabric) er riktig valg når:**
|
||||
- ✅ Du trenger å orkestrere data prep + ML training + deployment i én workflow
|
||||
- ✅ Datakildene er spredt (OLTP-databaser, blob storage, on-prem filsystemer, SaaS-applikasjoner)
|
||||
- ✅ Du vil separere data engineering (Data Factory) fra ML development (Azure ML/Fabric Notebooks)
|
||||
- ✅ Business users skal kunne trigge ML-pipelines via Power Automate eller Power Apps
|
||||
- ✅ Du trenger robust error handling (retry policies, alerting, branching) uten Python-koding
|
||||
|
||||
**Data Factory er IKKE riktig valg når:**
|
||||
- ❌ ML-workflow er tett koblet til Python-kode (bruk Azure ML Pipelines eller Databricks Jobs istedenfor)
|
||||
- ❌ Real-time streaming er primærkravet (bruk Stream Analytics + Azure Functions istedenfor)
|
||||
- ❌ Du kun trenger å kjøre én enkelt Azure ML pipeline daglig (bruk Azure ML Schedule Trigger direkte)
|
||||
- ❌ Kostnadsoptimalisering er kritisk og du kun trenger basic orchestration (vurder Azure Logic Apps eller Durable Functions)
|
||||
|
||||
### Arkitektur-tradeoffs
|
||||
|
||||
| Beslutning | Alternativ A | Alternativ B | Cosmos råd |
|
||||
|------------|-------------|-------------|-----------|
|
||||
| **Fabric vs. ADF** | Fabric (capacity, OneLake-integrasjon) | ADF (consumption, Azure ML-integrasjon) | Velg Fabric hvis Power BI Premium allerede er i bruk (delt capacity). Velg ADF hvis hybride on-prem-kilder er dominerende. |
|
||||
| **Pipeline vs. Airflow** | Pipeline (low-code UI) | Airflow (Python DAGs) | Start med Pipeline. Migrer til Airflow hvis >5 data engineers trenger git-basert versjonskontroll og Python-flexibility. |
|
||||
| **Batch endpoint vs. Online endpoint** | Batch (Data Factory Copy → invoke → Copy) | Online (real-time via API Management) | Batch er 70% billigere for scenarioer der latency > 1 minutt er akseptabel. Online kun hvis SLA < 500ms. |
|
||||
| **Incremental vs. Full copy** | Incremental (watermark-based) | Full (daily snapshot) | Incremental reduserer data movement cost med 90%, men krever timestamp-kolonne i source. Full copy kun hvis source data er < 10 GB. |
|
||||
|
||||
### Typiske fallgruver
|
||||
|
||||
**Fallgruve #1: Hardkodet secrets i pipeline JSON**
|
||||
|
||||
❌ **Feil:**
|
||||
```json
|
||||
{
|
||||
"url": "https://api.example.com/data",
|
||||
"headers": {
|
||||
"Authorization": "Bearer abc123secrettoken"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
✅ **Korrekt:**
|
||||
```json
|
||||
{
|
||||
"url": "https://api.example.com/data",
|
||||
"authentication": {
|
||||
"type": "AzureKeyVault",
|
||||
"store": {
|
||||
"referenceName": "MyKeyVault",
|
||||
"type": "LinkedServiceReference"
|
||||
},
|
||||
"secretName": "ApiToken"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Fallgruve #2: Ingen retry-policy på ML-aktiviteter**
|
||||
|
||||
Azure ML-pipelines kan feile av midlertidige årsaker (quota limits, node startup failures). Alltid konfigurer retry:
|
||||
|
||||
```json
|
||||
{
|
||||
"policy": {
|
||||
"timeout": "01:00:00",
|
||||
"retry": 3,
|
||||
"retryIntervalInSeconds": 300
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Fallgruve #3: Manglende monitoring**
|
||||
|
||||
Data Factory har ingen default alerts. Konfigurer:
|
||||
- Azure Monitor Alert Rule: "Pipeline failed" → Teams/email
|
||||
- Application Insights integration: Log custom metrics (inference accuracy, data drift score)
|
||||
- Power BI dashboard: Visualiser pipeline runs, data volume, cost per pipeline
|
||||
|
||||
**Fallgruve #4: Ingen lineage tracking**
|
||||
|
||||
Data Factory viser kun aktivitetslogger, ikke data lineage (hvilke tabeller påvirkes av hvilke pipelines). Løsning:
|
||||
- Microsoft Purview integration (scans Data Factory pipelines, bygger lineage-graph)
|
||||
- Custom lineage: Log input/output tables til metadata-tabell i hver pipeline
|
||||
|
||||
### Anbefalte mønstre
|
||||
|
||||
**Mønster 1: Medallion Architecture (Bronze → Silver → Gold)**
|
||||
|
||||
```
|
||||
[Raw Data Sources] → [Copy to Lakehouse Bronze] → [DataFlow Gen2: Clean + Enrich] →
|
||||
[Silver Layer] → [Azure ML Feature Store] → [ML Training Pipeline] →
|
||||
[Model Registry] → [Batch Inference] → [Gold Layer (predictions)]
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Separerer raw data (bronze) fra curated data (silver), enklere GDPR-compliance (slett bronze etter 30 dager, behold silver med anonymiserte data)
|
||||
- Feature store (silver layer) gjenbrukes på tvers av ML-modeller
|
||||
- Gold layer inneholder business-ready predictions (kan konsumeres direkte i Power BI)
|
||||
|
||||
**Mønster 2: Event-Driven Retraining**
|
||||
|
||||
```
|
||||
[Storage Account: New training data arrives] → [Event Grid Trigger] →
|
||||
[Data Factory Pipeline: Validate + Copy] → [Azure ML Pipeline: Train] →
|
||||
[If model metrics improve] → [Deploy to production endpoint]
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Zero scheduling lag (retraining starter umiddelbart når nye data er tilgjengelig)
|
||||
- Cost-efficient (kun kjører når nødvendig, ikke på fast schedule)
|
||||
- Krever Event Grid + Storage Event Trigger (tilgjengelig i både ADF og Fabric)
|
||||
|
||||
**Mønster 3: Hybrid Real-time + Batch**
|
||||
|
||||
```
|
||||
[Event Hubs (IoT data)] → [Stream Analytics] → [Azure ML Online Endpoint] →
|
||||
[Cosmos DB (real-time results)] → [Data Factory nightly batch] →
|
||||
[Copy to Lakehouse] → [Aggregate + Retrain] → [Deploy updated model]
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Real-time inferens for kritiske scenarioer (fraud detection, predictive maintenance)
|
||||
- Batch retraining bruker historiske data (mer robust modell)
|
||||
- Data Factory orkestrerer kun batch-delen (lavere cost enn real-time pipelines)
|
||||
|
||||
### Sikkerhetsveiledning
|
||||
|
||||
**Minimum sikkerhetskonfigurasjon for AI-pipelines:**
|
||||
|
||||
| Lag | Tiltak | Implementering |
|
||||
|-----|--------|----------------|
|
||||
| **Network** | Private endpoints for Azure ML, Storage, Key Vault | Azure Private Link (all data stays in Microsoft backbone) |
|
||||
| **Identity** | Managed Identity (no secrets in code) | System-assigned MI for Data Factory, assign RBAC to ML workspace + storage |
|
||||
| **Data** | Encryption at rest + in transit | Azure Storage SSE (enabled by default), TLS 1.2 for all connections |
|
||||
| **Logging** | Audit all pipeline runs + data access | Azure Monitor Logs, Log Analytics workspace (90-day retention) |
|
||||
| **Access control** | Role-based access to pipelines | Data Factory Contributor (utviklere), Data Factory Operator (production) |
|
||||
|
||||
**Scenario-spesifikk hardening:**
|
||||
|
||||
**Offentlig sektor (GDPR-kritisk):**
|
||||
- [ ] Customer-managed keys (CMK) for storage accounts
|
||||
- [ ] VNet integration for self-hosted IR (on-prem data aldri ekst eksponert til public internet)
|
||||
- [ ] Azure Policy: "Data Factory pipelines må bruke Private Link" (enforced)
|
||||
|
||||
**Helsesektoren (HIPAA/HITECH):**
|
||||
- [ ] Azure Data Factory er **ikke HIPAA BAA-compliant** (per Feb 2026) — bruk Azure Synapse Pipelines istedenfor (samme teknologi, men HIPAA-certified)
|
||||
- [ ] All PHI må krypteres med CMK
|
||||
- [ ] Audit logs sendes til separate Log Analytics workspace (ikke i samme resource group som Data Factory)
|
||||
|
||||
### Testbarhet
|
||||
|
||||
**Utfordring:** Data Factory-pipelines er vanskelige å unit-teste (krever faktisk Azure-infrastruktur).
|
||||
|
||||
**Løsning (Fabric Data Factory-spesifikk):**
|
||||
|
||||
1. **Development workspace:** Opprett dedikert Fabric workspace for utvikling (billig F2 capacity)
|
||||
2. **Git integration:** Branch-basert utvikling (main = prod, dev = testing)
|
||||
3. **Parameterisering:** Alle environment-specific verdier som parametere (ikke hardkodet)
|
||||
4. **Integration tests:** Bruk småskalerte datasett i dev workspace (100 rader istedenfor 1M)
|
||||
|
||||
**Løsning (Azure Data Factory-spesifikk):**
|
||||
|
||||
1. **ARM template parameterization:** Alle linked services og datasets er parameterisert (kan deployes til dev/test/prod)
|
||||
2. **Azure DevOps Pipelines:** CI/CD med automated testing:
|
||||
```yaml
|
||||
- task: AzureResourceManagerTemplateDeployment
|
||||
inputs:
|
||||
deploymentScope: 'Resource Group'
|
||||
resourceGroupName: 'rg-adf-dev'
|
||||
location: 'Norway East'
|
||||
templateLocation: 'Linked artifact'
|
||||
csmFile: 'arm_template.json'
|
||||
csmParametersFile: 'arm_template_parameters_dev.json'
|
||||
- task: AzurePowerShell
|
||||
inputs:
|
||||
azureSubscription: 'MyAzureSubscription'
|
||||
scriptType: 'InlineScript'
|
||||
Inline: |
|
||||
$runOutput = Invoke-AzDataFactoryV2Pipeline -ResourceGroupName "rg-adf-dev" -DataFactoryName "adf-dev" -PipelineName "TestPipeline"
|
||||
$status = Get-AzDataFactoryV2PipelineRun -ResourceGroupName "rg-adf-dev" -DataFactoryName "adf-dev" -PipelineRunId $runOutput.RunId
|
||||
if ($status.Status -ne "Succeeded") { throw "Pipeline failed" }
|
||||
```
|
||||
|
||||
### Migrasjonsveiledning
|
||||
|
||||
**Fra on-prem ETL (SSIS/Informatica) til Data Factory:**
|
||||
|
||||
| SSIS-komponent | Data Factory-ekvivalent | Migrasjonsinnsats |
|
||||
|----------------|------------------------|-------------------|
|
||||
| **SSIS Package** | Azure-SSIS Integration Runtime (lift-and-shift) | Lav (rehost existing packages) |
|
||||
| **Control Flow** | Pipeline activities (If/ForEach/Until) | Moderat (redesign i UI) |
|
||||
| **Data Flow** | DataFlow Gen2 | Høy (redesign transformasjoner) |
|
||||
| **Script Task (C#)** | Azure Function Activity eller Databricks Notebook | Høy (rewrite i Python/C#) |
|
||||
|
||||
**Anbefalt migrasjonsrekkefølge:**
|
||||
1. **Fase 1:** Lift-and-shift SSIS packages til Azure-SSIS IR (verifiser funksjonalitet)
|
||||
2. **Fase 2:** Redesign enkle pipelines (Copy-only workflows) til native Data Factory
|
||||
3. **Fase 3:** Redesign komplekse transformasjoner til DataFlow Gen2 eller Databricks
|
||||
4. **Fase 4:** Fase ut Azure-SSIS IR (spar 60% cost ved å bruke native Data Factory)
|
||||
|
||||
**Fra Azure Data Factory til Fabric Data Factory:**
|
||||
|
||||
Microsoft tilbyr PowerShell-modul: `Microsoft.FabricPipelineUpgrade`
|
||||
|
||||
```powershell
|
||||
# Installer modul
|
||||
Install-Module -Name Microsoft.FabricPipelineUpgrade
|
||||
|
||||
# Migrer pipeline
|
||||
Invoke-FabricPipelineUpgrade `
|
||||
-SourceType AzureDataFactory `
|
||||
-SourceFactory "adf-prod" `
|
||||
-SourceResourceGroup "rg-adf" `
|
||||
-SourceSubscription "abc-123" `
|
||||
-TargetWorkspace "ws-fabric-prod" `
|
||||
-PipelineName "MLInferencePipeline"
|
||||
```
|
||||
|
||||
**Migrasjonsutfordringer:**
|
||||
- Azure ML Update Resource Activity finnes ikke i Fabric → bruk Web Activity + REST API
|
||||
- Self-hosted IR-konfigurasjon må reconfigureres (annen agent-versjon)
|
||||
- Linked services må recreates (ADF linked services kan ikke importeres direkte)
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
**Primærkilder (brukt i denne referansen):**
|
||||
|
||||
1. **What is Data Factory in Microsoft Fabric?**
|
||||
https://learn.microsoft.com/en-us/fabric/data-factory/data-factory-overview
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟢 **Høy** (offisiell Microsoft Learn-dokumentasjon)
|
||||
|
||||
2. **Execute Azure Machine Learning pipelines in Azure Data Factory**
|
||||
https://learn.microsoft.com/en-us/azure/data-factory/transform-data-machine-learning-service
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟢 **Høy** (offisiell Microsoft Learn-dokumentasjon)
|
||||
|
||||
3. **Data ingestion with Azure Data Factory**
|
||||
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-data-ingest-adf
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟡 **Moderat** (gjelder Azure ML SDK v1, deprecated per 2025-03-31, men konseptene er fortsatt gyldige)
|
||||
|
||||
4. **Run batch endpoints from Azure Data Factory**
|
||||
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-batch-azure-data-factory
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟢 **Høy** (aktiv dokumentasjon for Azure ML SDK v2)
|
||||
|
||||
5. **Pipelines pricing for Data Factory in Microsoft Fabric**
|
||||
https://learn.microsoft.com/en-us/fabric/data-factory/pricing-pipelines
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟡 **Moderat** (prising endrer seg kvartalsvis, verifiser med Azure Pricing Calculator)
|
||||
|
||||
6. **Migration planning for Azure Data Factory to Fabric Data Factory**
|
||||
https://learn.microsoft.com/en-us/fabric/data-factory/migrate-planning-azure-data-factory
|
||||
Sist verifisert: 2026-02-11
|
||||
Confidence: 🟢 **Høy** (offisiell migrasjonsveiledning)
|
||||
|
||||
**Sekundærkilder:**
|
||||
|
||||
7. **Azure Data Factory Pricing**
|
||||
https://azure.microsoft.com/en-us/pricing/details/data-factory/data-pipeline/
|
||||
Sist verifisert: 2026-02-11 (Norge East region)
|
||||
|
||||
8. **Microsoft Fabric Pricing**
|
||||
https://azure.microsoft.com/en-us/pricing/details/microsoft-fabric/
|
||||
Sist verifisert: 2026-02-11 (Norge West region)
|
||||
|
||||
**Kodeeksempler hentet fra:**
|
||||
|
||||
9. **Azure Data Factory samples (GitHub)**
|
||||
https://github.com/Azure/Azure-DataFactory
|
||||
Eksempler: Incremental copy with watermark, Azure ML integration, batch endpoint invocation
|
||||
|
||||
**Ufullstendige områder (krever videre research):**
|
||||
|
||||
- **Fabric Copilot for Data Factory:** Dokumentasjon er sparsom per Feb 2026, mange features er preview
|
||||
- **On-premises data sources med Fabric:** Self-hosted IR er støttet, men best practices for hybrid scenarioer er ikke godt dokumentert
|
||||
- **HIPAA compliance for Data Factory:** Azure Data Factory er IKKE eksplisitt HIPAA BAA-compliant, men Synapse Pipelines er (samme teknologi)
|
||||
|
||||
**Verifiseringsstrategi for bruk:**
|
||||
|
||||
1. **Prising:** Alltid kjør Azure Pricing Calculator med faktiske data volumes før produksjon
|
||||
2. **Features:** Sjekk "Preview features"-siden i Fabric Admin Portal (features kan endres uten varsel)
|
||||
3. **Regional availability:** Norge West/East er ikke alltid first-wave for nye Fabric-features (typisk 3-6 måneders lag etter US regions)
|
||||
|
||||
---
|
||||
|
||||
**For Cosmo:**
|
||||
Denne referansen dekker orkestreringsaspektet av AI-pipelines. For dypdykk i:
|
||||
- **Feature engineering:** Se `feature-store-architecture.md` og `dataflow-gen2-transformations.md`
|
||||
- **Model lifecycle:** Se `azure-ml-pipelines.md` og `mlops-ci-cd.md`
|
||||
- **Real-time inference:** Se `azure-ml-online-endpoints.md` og `aks-inference-architecture.md`
|
||||
|
||||
Data Factory er "limet" som binder data prep, ML training, og deployment sammen. Ikke forsøk å gjøre kompleks ML-logikk i Data Factory — bruk Azure ML Pipelines for det, og la Data Factory orkestrere på høyt nivå.
|
||||
|
|
@ -0,0 +1,425 @@
|
|||
# Data Mesh Patterns and Domain Ownership
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## 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. Statens vegvesen, 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:
|
||||
|
||||
```python
|
||||
# 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
|
||||
|
||||
```python
|
||||
# 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
|
||||
|
||||
```yaml
|
||||
# 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
|
||||
|
||||
```python
|
||||
# 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 Statens vegvesen og Meteorologisk institutt):
|
||||
|
||||
```
|
||||
Tenant A: Statens vegvesen 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:
|
||||
|
||||
```python
|
||||
# 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:
|
||||
|
||||
```python
|
||||
# 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
|
||||
|
||||
```python
|
||||
# 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
|
||||
|
||||
- [Fabric domains](https://learn.microsoft.com/en-us/fabric/governance/domains) -- Opprette og administrere domener i Fabric
|
||||
- [Best practices for planning and creating domains](https://learn.microsoft.com/en-us/fabric/governance/domains-best-practices) -- Planlegging av domenestruktur
|
||||
- [What is data mesh?](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/architectures/what-is-data-mesh) -- Data mesh-konsepter i Cloud Adoption Framework
|
||||
- [Operationalize data mesh for AI/ML](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/architectures/operationalize-data-mesh-for-ai-ml) -- Data mesh for feature engineering
|
||||
- [OneLake shortcuts](https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts) -- Cross-domain datadeling uten kopiering
|
||||
- [OneLake catalog overview](https://learn.microsoft.com/en-us/fabric/governance/onelake-catalog-overview) -- Oppdagbarhet og governance
|
||||
- [Medallion lakehouse architecture](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) -- Data mesh i Medallion-arkitektur
|
||||
- [Fabric deployment patterns](https://learn.microsoft.com/en-us/azure/architecture/analytics/architecture/fabric-deployment-patterns) -- Deployment-monstre for store organisasjoner
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **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.
|
||||
|
|
@ -0,0 +1,611 @@
|
|||
# Data Pipeline Orchestration and Scheduling
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Datapipeline-orkestrering er ryggraden i enhver AI-plattform. Uten palitelig orkestrering kan data komme for sent, i feil rekkefølge, eller med manglende avhengigheter -- noe som forer til feil i ML-treningsjobber, utdaterte prediksjoner og upaalitelige AI-agenter. Microsoft tilbyr to hovedplattformer for orkestrering: Fabric Data Factory og Azure Data Factory, begge med pipeline-basert arbeidsflyt, triggers og overvaking.
|
||||
|
||||
Fabric Data Factory er den foretrukne losningen for organisasjoner som bruker Microsoft Fabric, med native integrasjon mot OneLake, Lakehouse, Warehouse og notebooks. Azure Data Factory (klassisk) gir bredere tilkoblingsmuligheter og hybrid-stotte via self-hosted integration runtime. For komplekse DAG-baserte arbeidsflyter stotter Fabric ogsa Apache Airflow-integrasjon.
|
||||
|
||||
For norsk offentlig sektor, der etterlevelse av SLAer og sporbarhet er kritisk, gir pipeline-orkestrering i Fabric full audit trail, automatisert feilhaandtering og mulighet for CI/CD-basert deployment av datapipelines pa tvers av miljoer.
|
||||
|
||||
---
|
||||
|
||||
## Pipeline Scheduling and Triggers
|
||||
|
||||
### Typer triggere i Fabric Data Factory
|
||||
|
||||
| Trigger-type | Beskrivelse | Bruksomrade |
|
||||
|-------------|-------------|-------------|
|
||||
| **Schedule** | Tidsbasert med frekvens og tidsvindu | Daglige ETL-jobber, rapportoppdatering |
|
||||
| **Tumbling Window** | Tidsbaserte vindu med avhengigheter | Sekvensielle batch-jobber |
|
||||
| **Event-based** | Reagerer pa hendelser (ny fil, DB-endring) | Realtime-naer inntak |
|
||||
| **On-demand** | Manuell kjoring | Testing, ad-hoc-jobber |
|
||||
|
||||
### Schedule Trigger-konfigurasjon
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "ScheduleTrigger",
|
||||
"properties": {
|
||||
"description": "Daglig AI-treningsdata-oppdatering",
|
||||
"runtimeState": "Started",
|
||||
"recurrence": {
|
||||
"frequency": "Day",
|
||||
"interval": 1,
|
||||
"startTime": "2026-01-01T02:00:00Z",
|
||||
"endTime": "2027-01-01T02:00:00Z",
|
||||
"timeZone": "W. Europe Standard Time",
|
||||
"schedule": {
|
||||
"hours": [2],
|
||||
"minutes": [0]
|
||||
}
|
||||
},
|
||||
"pipelines": [
|
||||
{
|
||||
"pipelineReference": {
|
||||
"referenceName": "IngestTrainingData",
|
||||
"type": "PipelineReference"
|
||||
},
|
||||
"parameters": {
|
||||
"processDate": "@trigger().scheduledTime"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Event-based Trigger
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "BlobEventsTrigger",
|
||||
"properties": {
|
||||
"description": "Trigger pa nye filer i landing zone",
|
||||
"events": ["Microsoft.Storage.BlobCreated"],
|
||||
"scope": "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{sa}",
|
||||
"blobPathBeginsWith": "/landing-zone/ai-data/",
|
||||
"blobPathEndsWith": ".parquet",
|
||||
"pipelines": [
|
||||
{
|
||||
"pipelineReference": {
|
||||
"referenceName": "ProcessNewDataFile",
|
||||
"type": "PipelineReference"
|
||||
},
|
||||
"parameters": {
|
||||
"fileName": "@triggerBody().fileName",
|
||||
"folderPath": "@triggerBody().folderPath"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Planlegging i Fabric UI
|
||||
|
||||
```python
|
||||
# Fabric pipelines kan ogsa planlegges via REST API
|
||||
import requests
|
||||
|
||||
schedule_payload = {
|
||||
"enabled": True,
|
||||
"configuration": {
|
||||
"type": "Daily",
|
||||
"startDateTime": "2026-02-01T02:00:00.000Z",
|
||||
"endDateTime": "2026-12-31T23:59:59.000Z",
|
||||
"localTimeZoneId": "W. Europe Standard Time",
|
||||
"times": ["02:00"]
|
||||
}
|
||||
}
|
||||
|
||||
response = requests.post(
|
||||
f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/items/{pipeline_id}/jobs/instances?jobType=Pipeline",
|
||||
headers=headers,
|
||||
json=schedule_payload
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Dependency Chains and Critical Paths
|
||||
|
||||
### Aktivitetsavhengigheter
|
||||
|
||||
Fabric Data Factory stotter fire typer avhengigheter mellom aktiviteter:
|
||||
|
||||
| Betingelse | Beskrivelse | Bruksomrade |
|
||||
|-----------|-------------|-------------|
|
||||
| **Succeeded** | Kjor kun hvis forrige lyktes | Standard dataflyt |
|
||||
| **Failed** | Kjor kun hvis forrige feilet | Feilhaandtering, alerting |
|
||||
| **Completed** | Kjor uansett utfall | Opprydding, logging |
|
||||
| **Skipped** | Kjor hvis forrige ble hoppet over | Betinget logikk |
|
||||
|
||||
### Kompleks avhengighetsgraf for AI-pipeline
|
||||
|
||||
```
|
||||
[Ingest Raw Data]
|
||||
|-- Succeeded --> [Validate Schema]
|
||||
| |-- Succeeded --> [Transform Bronze->Silver]
|
||||
| | |-- Succeeded --> [Generate Features]
|
||||
| | | |-- Succeeded --> [Train Model]
|
||||
| | | |-- Failed --> [Alert: Feature Gen Failed]
|
||||
| | |-- Failed --> [Alert: Transform Failed]
|
||||
| |-- Failed --> [Reject and Log Invalid Data]
|
||||
|-- Failed --> [Alert: Ingestion Failed]
|
||||
|-- Completed --> [Log Pipeline Metrics]
|
||||
```
|
||||
|
||||
### Kritisk sti-analyse
|
||||
|
||||
```python
|
||||
# Beregn kritisk sti for en pipeline med flere parallelle grener
|
||||
from datetime import timedelta
|
||||
|
||||
pipeline_activities = {
|
||||
"ingest_traffic": {"duration": timedelta(minutes=15), "depends_on": []},
|
||||
"ingest_weather": {"duration": timedelta(minutes=10), "depends_on": []},
|
||||
"ingest_road_conditions": {"duration": timedelta(minutes=12), "depends_on": []},
|
||||
"validate_traffic": {"duration": timedelta(minutes=5), "depends_on": ["ingest_traffic"]},
|
||||
"validate_weather": {"duration": timedelta(minutes=3), "depends_on": ["ingest_weather"]},
|
||||
"join_datasets": {"duration": timedelta(minutes=20), "depends_on": ["validate_traffic", "validate_weather", "ingest_road_conditions"]},
|
||||
"generate_features": {"duration": timedelta(minutes=30), "depends_on": ["join_datasets"]},
|
||||
"train_model": {"duration": timedelta(minutes=45), "depends_on": ["generate_features"]},
|
||||
"evaluate_model": {"duration": timedelta(minutes=10), "depends_on": ["train_model"]},
|
||||
"deploy_model": {"duration": timedelta(minutes=5), "depends_on": ["evaluate_model"]}
|
||||
}
|
||||
|
||||
def find_critical_path(activities):
|
||||
"""Finn den lengste stien gjennom pipeline-grafen."""
|
||||
memo = {}
|
||||
|
||||
def longest_path(activity):
|
||||
if activity in memo:
|
||||
return memo[activity]
|
||||
|
||||
deps = activities[activity]["depends_on"]
|
||||
if not deps:
|
||||
memo[activity] = activities[activity]["duration"]
|
||||
else:
|
||||
max_dep_time = max(longest_path(dep) for dep in deps)
|
||||
memo[activity] = max_dep_time + activities[activity]["duration"]
|
||||
|
||||
return memo[activity]
|
||||
|
||||
for act in activities:
|
||||
longest_path(act)
|
||||
|
||||
critical = max(memo, key=memo.get)
|
||||
total_time = memo[critical]
|
||||
|
||||
return total_time, memo
|
||||
|
||||
total, paths = find_critical_path(pipeline_activities)
|
||||
print(f"Kritisk sti total tid: {total}")
|
||||
# Kritisk sti: ingest_traffic -> validate_traffic -> join -> features -> train -> evaluate -> deploy
|
||||
# = 15 + 5 + 20 + 30 + 45 + 10 + 5 = 130 minutter
|
||||
```
|
||||
|
||||
### Parallelle aktiviteter i Fabric Pipelines
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "ParallelIngestion",
|
||||
"type": "ForEach",
|
||||
"typeProperties": {
|
||||
"isSequential": false,
|
||||
"batchCount": 5,
|
||||
"items": {
|
||||
"value": "@pipeline().parameters.dataSources",
|
||||
"type": "Expression"
|
||||
},
|
||||
"activities": [
|
||||
{
|
||||
"name": "CopyFromSource",
|
||||
"type": "Copy",
|
||||
"inputs": [{"referenceName": "@item().sourceName"}],
|
||||
"outputs": [{"referenceName": "LakehouseSink"}]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Retry Policies and Error Handling
|
||||
|
||||
### Innebygde retry-policies
|
||||
|
||||
| Parameter | Standard | Anbefalt for AI | Beskrivelse |
|
||||
|-----------|---------|-----------------|-------------|
|
||||
| **retry** | 0 | 2-3 | Antall forsok ved feil |
|
||||
| **retryIntervalInSeconds** | 30 | 60 | Ventetid mellom forsok |
|
||||
| **timeout** | 7 dager | Varierer | Maks kjoringstid |
|
||||
| **secureInput** | false | true (for tokens) | Skjul sensitive inputs |
|
||||
|
||||
### Aktivitetsniva retry
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "FetchExternalData",
|
||||
"type": "WebActivity",
|
||||
"policy": {
|
||||
"retry": 3,
|
||||
"retryIntervalInSeconds": 60,
|
||||
"timeout": "01:00:00",
|
||||
"secureInput": false,
|
||||
"secureOutput": false
|
||||
},
|
||||
"typeProperties": {
|
||||
"url": "https://api.external-source.no/data",
|
||||
"method": "GET"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Error Handling med kontrollflyt
|
||||
|
||||
```json
|
||||
{
|
||||
"activities": [
|
||||
{
|
||||
"name": "TryProcessData",
|
||||
"type": "ExecutePipeline",
|
||||
"dependsOn": [],
|
||||
"typeProperties": {
|
||||
"pipeline": {"referenceName": "ProcessDataPipeline"}
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "OnSuccess_UpdateStatus",
|
||||
"type": "SetVariable",
|
||||
"dependsOn": [
|
||||
{"activity": "TryProcessData", "dependencyConditions": ["Succeeded"]}
|
||||
],
|
||||
"typeProperties": {
|
||||
"variableName": "pipelineStatus",
|
||||
"value": "SUCCESS"
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "OnFailure_SendAlert",
|
||||
"type": "WebActivity",
|
||||
"dependsOn": [
|
||||
{"activity": "TryProcessData", "dependencyConditions": ["Failed"]}
|
||||
],
|
||||
"typeProperties": {
|
||||
"url": "@pipeline().parameters.alertWebhookUrl",
|
||||
"method": "POST",
|
||||
"body": {
|
||||
"pipeline": "@pipeline().Pipeline",
|
||||
"runId": "@pipeline().RunId",
|
||||
"error": "@activity('TryProcessData').Error.message",
|
||||
"timestamp": "@utcnow()"
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "OnFailure_LogToTable",
|
||||
"type": "Script",
|
||||
"dependsOn": [
|
||||
{"activity": "TryProcessData", "dependencyConditions": ["Failed"]}
|
||||
],
|
||||
"typeProperties": {
|
||||
"scriptBlockExecutionTimeout": "02:00:00",
|
||||
"scripts": [
|
||||
{
|
||||
"type": "NonQuery",
|
||||
"text": "INSERT INTO dbo.pipeline_errors (pipeline_name, run_id, error_message, error_time) VALUES ('@{pipeline().Pipeline}', '@{pipeline().RunId}', '@{activity('TryProcessData').Error.message}', GETUTCDATE())"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Dead Letter Pattern for AI-data
|
||||
|
||||
```python
|
||||
# For feilede dataposter: flytt til dead letter-tabell i stedet for a feile hele pipeline
|
||||
def process_with_dead_letter(df, transform_func, dead_letter_table):
|
||||
"""
|
||||
Prosesser data med dead letter-moenster.
|
||||
Feilede rader sendes til dead letter-tabell for manuell gjennomgang.
|
||||
"""
|
||||
from pyspark.sql import functions as F
|
||||
|
||||
try:
|
||||
# Forsok transformasjon
|
||||
result_df = transform_func(df)
|
||||
return result_df
|
||||
|
||||
except Exception as e:
|
||||
# Ved feil: forsok rad-for-rad
|
||||
success_rows = []
|
||||
error_rows = []
|
||||
|
||||
for row in df.collect():
|
||||
try:
|
||||
row_df = spark.createDataFrame([row])
|
||||
transformed = transform_func(row_df)
|
||||
success_rows.append(transformed.first())
|
||||
except Exception as row_error:
|
||||
error_row = row.asDict()
|
||||
error_row["_error_message"] = str(row_error)
|
||||
error_row["_error_timestamp"] = datetime.now().isoformat()
|
||||
error_rows.append(error_row)
|
||||
|
||||
# Lagre feilede rader
|
||||
if error_rows:
|
||||
error_df = spark.createDataFrame(error_rows)
|
||||
error_df.write.format("delta").mode("append") \
|
||||
.saveAsTable(dead_letter_table)
|
||||
|
||||
if success_rows:
|
||||
return spark.createDataFrame(success_rows)
|
||||
|
||||
return spark.createDataFrame([], df.schema)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Monitoring and Alerting on Pipeline Health
|
||||
|
||||
### Fabric Monitor Hub
|
||||
|
||||
Fabric Monitor Hub gir enhetlig overvaking pa tvers av alle pipeline-typer:
|
||||
|
||||
| Metrisk | Beskrivelse | Alerting-terskel |
|
||||
|---------|-------------|-----------------|
|
||||
| **Run Status** | Succeeded/Failed/In Progress | Varsle ved Failed |
|
||||
| **Duration** | Kjoringstid per pipeline | Varsle ved > 2x normal |
|
||||
| **Activity Duration** | Tid per aktivitet | Identifiser flaskehalser |
|
||||
| **Data Volume** | Antall rader / bytes prosessert | Varsle ved 0 rader |
|
||||
| **Queue Time** | Ventetid for kapasitet | Varsle ved > 5 min |
|
||||
|
||||
### REST API for pipeline-monitorering
|
||||
|
||||
```python
|
||||
# Hent pipeline-kjoringshistorikk
|
||||
def get_pipeline_run_history(workspace_id: str, pipeline_id: str, days: int = 7):
|
||||
"""Hent kjoringshistorikk for en pipeline."""
|
||||
response = requests.get(
|
||||
f"https://api.fabric.microsoft.com/v1/workspaces/{workspace_id}/items/{pipeline_id}/jobs/instances",
|
||||
headers=headers,
|
||||
params={"startDateTime": (datetime.now() - timedelta(days=days)).isoformat()}
|
||||
)
|
||||
|
||||
runs = response.json()["value"]
|
||||
|
||||
# Analyser
|
||||
total = len(runs)
|
||||
succeeded = sum(1 for r in runs if r["status"] == "Completed")
|
||||
failed = sum(1 for r in runs if r["status"] == "Failed")
|
||||
avg_duration = sum(r.get("durationInMs", 0) for r in runs) / max(total, 1)
|
||||
|
||||
return {
|
||||
"total_runs": total,
|
||||
"success_rate": round(succeeded / max(total, 1) * 100, 1),
|
||||
"failed_count": failed,
|
||||
"avg_duration_minutes": round(avg_duration / 60000, 1)
|
||||
}
|
||||
```
|
||||
|
||||
### Custom Dashboard med Power BI
|
||||
|
||||
```python
|
||||
# Skriv pipeline-metrikker til Fabric Lakehouse for Power BI
|
||||
def log_pipeline_metrics(pipeline_name: str, run_id: str, metrics: dict):
|
||||
"""Logg pipeline-metrikker til overvakningstabell."""
|
||||
from pyspark.sql.types import StructType, StructField, StringType, TimestampType, LongType, DoubleType
|
||||
|
||||
schema = StructType([
|
||||
StructField("pipeline_name", StringType()),
|
||||
StructField("run_id", StringType()),
|
||||
StructField("start_time", TimestampType()),
|
||||
StructField("end_time", TimestampType()),
|
||||
StructField("duration_seconds", LongType()),
|
||||
StructField("status", StringType()),
|
||||
StructField("rows_processed", LongType()),
|
||||
StructField("bytes_processed", LongType()),
|
||||
StructField("error_message", StringType()),
|
||||
StructField("sla_met", StringType())
|
||||
])
|
||||
|
||||
row = spark.createDataFrame([{
|
||||
"pipeline_name": pipeline_name,
|
||||
"run_id": run_id,
|
||||
**metrics
|
||||
}], schema)
|
||||
|
||||
row.write.format("delta").mode("append") \
|
||||
.saveAsTable("lakehouse.default.pipeline_monitoring")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## SLAs and Timeliness Guarantees
|
||||
|
||||
### Definere pipeline-SLAer
|
||||
|
||||
| SLA-type | Definisjon | Eksempel |
|
||||
|----------|-----------|---------|
|
||||
| **Freshness SLA** | Data skal vaere tilgjengelig innen X tid | "Gaarsdagens data klar for 06:00" |
|
||||
| **Completeness SLA** | Alle forventede data skal vaere med | "100% av tellepunkter representert" |
|
||||
| **Quality SLA** | Data skal oppfylle kvalitetskrav | "< 0.1% feilrater i features" |
|
||||
| **Availability SLA** | Pipeline skal kjore X% av tiden | "99.5% tilgjengelighet" |
|
||||
|
||||
### SLA-monitorering i Fabric
|
||||
|
||||
```python
|
||||
# Implementer SLA-sjekk som kjorer etter pipeline
|
||||
def check_pipeline_sla(pipeline_name: str, expected_completion: str, tolerance_minutes: int = 30):
|
||||
"""
|
||||
Sjekk om pipeline fullforte innenfor SLA.
|
||||
|
||||
Args:
|
||||
pipeline_name: Navn pa pipeline
|
||||
expected_completion: Forventet ferdigtid (HH:MM)
|
||||
tolerance_minutes: Toleranse i minutter
|
||||
"""
|
||||
from datetime import datetime, time
|
||||
|
||||
# Hent siste kjoring
|
||||
last_run = get_latest_pipeline_run(pipeline_name)
|
||||
|
||||
if not last_run:
|
||||
return {"sla_met": False, "reason": "Ingen kjoring funnet"}
|
||||
|
||||
# Parse forventet tid
|
||||
expected_time = datetime.strptime(expected_completion, "%H:%M").time()
|
||||
actual_completion = last_run["end_time"].time()
|
||||
|
||||
# Beregn avvik
|
||||
expected_dt = datetime.combine(datetime.today(), expected_time)
|
||||
actual_dt = datetime.combine(datetime.today(), actual_completion)
|
||||
delay_minutes = (actual_dt - expected_dt).total_seconds() / 60
|
||||
|
||||
sla_met = delay_minutes <= tolerance_minutes
|
||||
|
||||
return {
|
||||
"sla_met": sla_met,
|
||||
"expected": expected_completion,
|
||||
"actual": actual_completion.strftime("%H:%M"),
|
||||
"delay_minutes": max(0, delay_minutes),
|
||||
"tolerance_minutes": tolerance_minutes,
|
||||
"status": last_run["status"]
|
||||
}
|
||||
|
||||
# Eksempel: Sjekk SLA for daglig AI-treningsdata
|
||||
sla_result = check_pipeline_sla(
|
||||
pipeline_name="DailyAITrainingData",
|
||||
expected_completion="06:00",
|
||||
tolerance_minutes=30
|
||||
)
|
||||
```
|
||||
|
||||
### Azure Data Factory SLA-operasjonalisering
|
||||
|
||||
Azure Data Factory tilbyr innebygde SLA-mekanismer for produksjonspipelines:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "TumblingWindowWithSLA",
|
||||
"type": "TumblingWindowTrigger",
|
||||
"properties": {
|
||||
"frequency": "Hour",
|
||||
"interval": 1,
|
||||
"startTime": "2026-01-01T00:00:00Z",
|
||||
"delay": "00:15:00",
|
||||
"maxConcurrency": 1,
|
||||
"retryPolicy": {
|
||||
"count": 3,
|
||||
"intervalInSeconds": 300
|
||||
},
|
||||
"dependsOn": [
|
||||
{
|
||||
"type": "TumblingWindowTriggerDependencyReference",
|
||||
"referenceTrigger": {
|
||||
"referenceName": "UpstreamDataReady"
|
||||
},
|
||||
"offset": "-01:00:00",
|
||||
"size": "01:00:00"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Apache Airflow i Fabric
|
||||
|
||||
For komplekse DAG-baserte arbeidsflyter:
|
||||
|
||||
```python
|
||||
# Fabric stotter Apache Airflow for avansert orkestrering
|
||||
# Opprett Airflow-jobb i Fabric Data Factory
|
||||
|
||||
from airflow import DAG
|
||||
from airflow.operators.python import PythonOperator
|
||||
from datetime import datetime, timedelta
|
||||
|
||||
default_args = {
|
||||
"owner": "ai-team",
|
||||
"depends_on_past": True,
|
||||
"email_on_failure": True,
|
||||
"email": ["ai-team@statens-vegvesen.no"],
|
||||
"retries": 2,
|
||||
"retry_delay": timedelta(minutes=5)
|
||||
}
|
||||
|
||||
with DAG(
|
||||
"ai_training_pipeline",
|
||||
default_args=default_args,
|
||||
description="Daglig AI-treningspipeline",
|
||||
schedule_interval="0 2 * * *", # Kl 02:00 daglig
|
||||
start_date=datetime(2026, 1, 1),
|
||||
catchup=False,
|
||||
tags=["ai", "training"]
|
||||
) as dag:
|
||||
|
||||
ingest = PythonOperator(
|
||||
task_id="ingest_raw_data",
|
||||
python_callable=ingest_from_sources
|
||||
)
|
||||
|
||||
validate = PythonOperator(
|
||||
task_id="validate_data_quality",
|
||||
python_callable=run_quality_checks
|
||||
)
|
||||
|
||||
transform = PythonOperator(
|
||||
task_id="transform_to_features",
|
||||
python_callable=generate_ml_features
|
||||
)
|
||||
|
||||
train = PythonOperator(
|
||||
task_id="train_model",
|
||||
python_callable=train_ml_model,
|
||||
execution_timeout=timedelta(hours=2)
|
||||
)
|
||||
|
||||
evaluate = PythonOperator(
|
||||
task_id="evaluate_model",
|
||||
python_callable=evaluate_model_performance
|
||||
)
|
||||
|
||||
# Definer avhengigheter
|
||||
ingest >> validate >> transform >> train >> evaluate
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [What is Data Factory in Microsoft Fabric?](https://learn.microsoft.com/en-us/fabric/data-factory/data-factory-overview) -- Oversikt over Fabric Data Factory
|
||||
- [Pipeline overview](https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-overview) -- Aktiviteter, scheduling og pipeline runs
|
||||
- [Run, schedule, or trigger a pipeline](https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-runs) -- Trigger-typer og planlegging
|
||||
- [Choose a data pipeline orchestration technology](https://learn.microsoft.com/en-us/azure/architecture/data-guide/technology-choices/pipeline-orchestration-data-movement) -- Sammenligning av orkestreringsverktoy
|
||||
- [Deliver SLA for data pipelines](https://learn.microsoft.com/en-us/azure/data-factory/tutorial-operationalize-pipelines) -- SLA-operasjonalisering i ADF
|
||||
- [CI/CD for pipelines in Data Factory](https://learn.microsoft.com/en-us/fabric/data-factory/cicd-pipelines) -- Deployment pipelines og Git-integrasjon
|
||||
- [REST API for pipelines](https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-rest-api-capabilities) -- Programmatisk pipeline-styring
|
||||
- [Create Apache Airflow jobs](https://learn.microsoft.com/en-us/fabric/data-factory/create-apache-airflow-jobs) -- Airflow-integrasjon i Fabric
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder planlegger datapipeline-arkitektur for AI-arbeidsbelastninger, inkludert scheduling, avhengighetsstyring og feilhindtering.
|
||||
- **Fabric Data Factory er forstevalget** for organisasjoner pa Fabric-plattformen. Azure Data Factory (klassisk) anbefales kun naar det trengs hybrid-stotte eller Self-Hosted IR.
|
||||
- **Dead letter-monsteret er kritisk for AI-pipelines**: En feilende rad bor ikke stoppe hele pipeline -- send den til dead letter og fortsett. Dette sikrer at ML-modeller faar fersk data.
|
||||
- **SLA-monitorering bor vaere pa plass fra dag 1**: Definer forventninger til ferskhet, kompletthet og kvalitet, og automatiser varsling ved brudd.
|
||||
- **For norsk offentlig sektor**: Fremhev sporbarhet (audit trail) og CI/CD-stotte som viktige governance-funksjoner for a oppfylle krav i Forvaltningsloven og Arkivlova.
|
||||
|
|
@ -0,0 +1,573 @@
|
|||
# Data Quality Frameworks for AI
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA (Microsoft Purview Data Quality, Azure ML Model Monitoring, Fabric data quality)
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Data quality frameworks for AI sikrer at data som brukes til trening, validering og inferens av AI-modeller er nøyaktig, komplett, konsistent og pålitelig. I dagens AI-drevne landskap påvirker datakvalitet direkte AI-ytelsen, modellens nøyaktighet, og tillit til AI-beslutninger.
|
||||
|
||||
Dårlig datakvalitet fører til:
|
||||
- Degradert modellytelse over tid (data drift, prediction drift)
|
||||
- Feilaktige innsikter og anbefalinger
|
||||
- Erosjon av tillit til AI-systemer
|
||||
- Compliance-risiko (GDPR, AI Act, Forvaltningsloven)
|
||||
- Operasjonelle ineffektiviteter og økte kostnader
|
||||
|
||||
Microsoft-stacken tilbyr fire hovedspor for data quality management i AI-kontekst:
|
||||
1. **Microsoft Purview Data Quality** — enterprise data governance med AI-powered profiling og scoring
|
||||
2. **Azure Machine Learning Model Monitoring** — production model monitoring med data drift detection
|
||||
3. **Microsoft Fabric data quality** — lakehouse-native quality constraints i materialized lake views og pipelines
|
||||
4. **Azure Databricks expectations** — declarative data quality constraints i Delta Live Tables (DLT)
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### 1. Data Quality Dimensions (Six Industry Standards)
|
||||
|
||||
| Dimensjon | Definisjon | Microsoft tooling |
|
||||
|-----------|------------|-------------------|
|
||||
| **Completeness** | Grad av ikke-null verdier | Purview (null value rate), Databricks expectations, Fabric constraints |
|
||||
| **Accuracy** | Data reflekterer real-world verdier | Azure ML model performance monitoring, ground truth comparison |
|
||||
| **Consistency** | Data integrity opprettholdes på tvers av systemer | Purview cross-source validation, Unity Catalog referential integrity |
|
||||
| **Timeliness** | Data oppdateres og er tilgjengelig i tide | Purview freshness rules, Azure ML prediction drift, Fabric streaming quality checks |
|
||||
| **Uniqueness** | Ingen duplikater | Purview uniqueness metrics, Databricks DLT deduplication |
|
||||
| **Conformity** | Data overholder format og schema | Purview data type error rate, Azure ML schema validation |
|
||||
|
||||
### 2. Data Quality Lifecycle
|
||||
|
||||
```
|
||||
1. [Data ingestion] → Schema validation, type checks
|
||||
2. [Enrichment] → Profiling, quality rules application
|
||||
3. [Training] → Data drift monitoring vs. training baseline
|
||||
4. [Deployment] → Production inference data quality
|
||||
5. [Monitoring] → Continuous data quality scoring, alerts
|
||||
6. [Remediation] → Data quality actions, root cause analysis
|
||||
```
|
||||
|
||||
### 3. Microsoft Purview Data Quality — Enterprise Governance
|
||||
|
||||
**Capabilities:**
|
||||
- **AI-powered profiling:** Anbefaler kolonner for profiling, generer statistikk (distribution, min, max, std dev, uniqueness, completeness)
|
||||
- **No-code/low-code rules:** Out-of-box rules + AI-generated rules + custom rules
|
||||
- **Data quality scoring:** Aggregert scoring på column → data asset → data product → governance domain nivå
|
||||
- **Alerts:** Email notifications ved threshold breaches
|
||||
- **Actions center:** Diagnostic queries for stewards til å identifisere spesifikke rader som feiler quality checks
|
||||
|
||||
**Supported data sources (multi-cloud):**
|
||||
- Azure: Blob Storage, ADLS Gen2, Azure SQL DB, Synapse, Fabric Lakehouse (Delta/Iceberg format)
|
||||
- AWS: S3 (Parquet, CSV, Delta), RDS
|
||||
- GCP: BigQuery (limited support for virtual network)
|
||||
|
||||
**Pricing:** Data Governance Processing Units (DGPU) pay-as-you-go
|
||||
|
||||
**Limitations:**
|
||||
- Managed Identity som eneste auth-metode
|
||||
- Parquet: støtter kun (1) directory med part files eller (2) partitioned Parquet (year=2018/month=Dec) — ikke arbitrary hierarchies
|
||||
- Virtual network ikke støttet for BigQuery
|
||||
|
||||
### 4. Azure Machine Learning Model Monitoring
|
||||
|
||||
**Monitoring signals (tabular data):**
|
||||
|
||||
| Signal | Beskrivelse | Metrics | Reference data |
|
||||
|--------|-------------|---------|----------------|
|
||||
| **Data drift** | Endring i distribution av model input | Jensen-Shannon Distance, PSI, Normalized Wasserstein, KS test, Chi-squared | Training data eller recent production data |
|
||||
| **Prediction drift** | Endring i distribution av model output | Jensen-Shannon Distance, PSI, Normalized Wasserstein, Chebyshev Distance, KS test, Chi-squared | Validation data eller recent production data |
|
||||
| **Data quality** | Integrity av model input | Null value rate, Data type error rate, Out-of-bounds rate | Training data eller recent production data |
|
||||
| **Feature attribution drift** | Endring i feature importance | Normalized Discounted Cumulative Gain (NDCG) | Training data med feature importance |
|
||||
| **Model performance** | Ground truth vs. predictions | Accuracy, Precision, Recall, F1, AUC, MAE, RMSE | Ground truth labels (actuals) |
|
||||
|
||||
**Best practices:**
|
||||
1. Start monitoring umiddelbart etter production deployment
|
||||
2. Bruk multiple signals (e.g., data drift + feature attribution drift for early warnings)
|
||||
3. Set monitoring frequency basert på data accumulation rate (daily hvis heavy traffic, weekly/monthly ellers)
|
||||
4. Monitor top N features for large feature sets (reduserer cost og noise)
|
||||
5. Bruk training data som baseline for data drift, validation data for prediction drift
|
||||
6. Hvis ground truth er tilgjengelig: bruk model performance signal for objective view
|
||||
|
||||
**Setup:**
|
||||
1. Enable production inference data collection (automatic for Azure ML online endpoints, manual for batch/external endpoints)
|
||||
2. Set up model monitoring via SDK/CLI eller studio UI
|
||||
3. View/analyze results i Azure ML workspace
|
||||
|
||||
### 5. Microsoft Fabric Data Quality
|
||||
|
||||
**Materialized Lake Views (MLVs) constraints:**
|
||||
|
||||
```sql
|
||||
-- Example: exclude null customerName rows
|
||||
CREATE MATERIALIZED VIEW sales_clean
|
||||
CONSTRAINT cust_blank CHECK customerName IS NOT NULL
|
||||
WITH ACTION DROP -- or FAIL
|
||||
AS SELECT * FROM raw_sales;
|
||||
```
|
||||
|
||||
**Actions:**
|
||||
- `FAIL` — stops refresh ved første constraint violation (default)
|
||||
- `DROP` — processes og fjerner records som ikke møter constraint, gir count i lineage view
|
||||
|
||||
**Limitations:**
|
||||
- Constraints kan ikke oppdateres etter MLV creation (må recreate)
|
||||
- Functions og pattern search (LIKE, regex) i constraints er ikke støttet
|
||||
- Known issue: MLV med FAIL action kan gi "delta table not found" error (workaround: unngå FAIL, bruk DROP)
|
||||
|
||||
**Data quality for Fabric Lakehouse (Purview integration):**
|
||||
1. Mirror eller load data til Fabric Lakehouse i Delta/Iceberg format
|
||||
2. Grant Contributor access til workspace for Purview MSI
|
||||
3. Run Data Map scan på Lakehouse (service principal auth)
|
||||
4. Associate Lakehouse tables med data product i Purview Unified Catalog
|
||||
5. Profile + create rules + run data quality scan via Purview
|
||||
|
||||
### 6. Azure Databricks Expectations (Delta Live Tables)
|
||||
|
||||
**Expectations syntax:**
|
||||
|
||||
```python
|
||||
@dlt.expect("valid_timestamp", "timestamp IS NOT NULL")
|
||||
@dlt.expect_or_drop("valid_amount", "amount > 0")
|
||||
@dlt.expect_or_fail("critical_id", "id IS NOT NULL")
|
||||
def clean_transactions():
|
||||
return spark.read.table("raw_transactions")
|
||||
```
|
||||
|
||||
**Actions:**
|
||||
- `@dlt.expect` — track violations, allow records to pass
|
||||
- `@dlt.expect_or_drop` — drop violating records
|
||||
- `@dlt.expect_or_fail` — fail pipeline ved violations
|
||||
|
||||
**Benefits:**
|
||||
- Catch data quality issues ved ingestion før de påvirker downstream data products
|
||||
- Real-time quality metrics i DLT pipeline observability UI
|
||||
- Automatically generated data quality dashboards
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### Pattern 1: Layered Quality Gates (Medallion Architecture)
|
||||
|
||||
```
|
||||
[Bronze Layer] → Schema validation, null checks
|
||||
↓ (Fabric constraints: FAIL on critical nulls)
|
||||
[Silver Layer] → Business rules, referential integrity, deduplication
|
||||
↓ (Databricks expectations: DROP invalid records)
|
||||
[Gold Layer] → Aggregations, data quality scoring
|
||||
↓ (Purview: Profile + score + alert)
|
||||
[Consumption] → AI model training/inference
|
||||
```
|
||||
|
||||
**Decision criteria:**
|
||||
- **Bronze:** Fail fast på kritiske schema violations (FAIL action)
|
||||
- **Silver:** Isoler dårlig data (DROP action), log violations for remediation
|
||||
- **Gold:** Enterprise-wide governance med Purview scoring
|
||||
|
||||
### Pattern 2: Training vs. Production Data Quality Monitoring
|
||||
|
||||
**Training phase:**
|
||||
1. Purview profiling på training dataset
|
||||
2. Define baseline quality thresholds (e.g., "null rate < 5%")
|
||||
3. Apply rules, score data quality
|
||||
4. Iterate: fix issues → retrain → validate
|
||||
|
||||
**Production phase:**
|
||||
1. Azure ML Model Monitoring: track data drift (production vs. training baseline)
|
||||
2. Set alerts: e.g., "Jensen-Shannon Distance > 0.3"
|
||||
3. When alert fires → trigger Purview profiling på production data → compare profiles → investigate drift root cause
|
||||
|
||||
**Integration:**
|
||||
- Azure ML Monitoring detekterer drift → triggers Azure Function → calls Purview API for detailed profiling → stores results i Azure Monitor logs
|
||||
|
||||
### Pattern 3: Golden Datasets for Consistent Validation
|
||||
|
||||
**Concept:** Authoritative datasets som representerer production data patterns, brukt for testing og validation across alle AI workloads.
|
||||
|
||||
**Implementation:**
|
||||
1. Identify representative sample fra production data (stratified sampling)
|
||||
2. Store i Azure Blob/ADLS Gen2 som immutable dataset (versioned)
|
||||
3. Register i Azure ML as data asset (type: URIFolder)
|
||||
4. Use in Azure ML training jobs as validation dataset
|
||||
5. Update golden dataset quarterly (eller når significant drift detekteres)
|
||||
|
||||
**Quality checks on golden dataset:**
|
||||
- Purview profiling + scoring (monthly)
|
||||
- Azure ML data quality monitoring (continuous comparison mot latest production data)
|
||||
|
||||
### Pattern 4: Real-Time Data Quality for Streaming AI
|
||||
|
||||
**Scenario:** Real-time fraud detection model consuming transaction stream.
|
||||
|
||||
**Architecture:**
|
||||
```
|
||||
[Event Hub] → [Fabric Eventstream] → [Lakehouse (KQL DB)]
|
||||
↓
|
||||
[Real-time aggregation pipeline med data quality constraints]
|
||||
↓
|
||||
[Model inference endpoint] → [Azure ML Model Monitoring]
|
||||
```
|
||||
|
||||
**Quality checks:**
|
||||
1. **Ingestion:** Fabric eventstream DQ checks (schema validation, null checks)
|
||||
2. **Aggregation:** KQL queries med quality assertions (e.g., `assert(count(fraud_score > 1.0) == 0)`)
|
||||
3. **Inference:** Azure ML Model Monitoring tracks prediction drift i real-time (5-minute windows)
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når velge hvilket verktøy?
|
||||
|
||||
| Scenario | Anbefalt verktøy | Rationale |
|
||||
|----------|------------------|-----------|
|
||||
| Enterprise-wide data governance på tvers av multi-cloud sources | **Microsoft Purview Data Quality** | Centralized governance domain structure, multi-cloud support, AI-powered profiling |
|
||||
| Production AI model monitoring (deployed til Azure ML online endpoint) | **Azure ML Model Monitoring** | Out-of-box integration med Azure ML endpoints, automatic inference data collection |
|
||||
| Lakehouse-native data quality i Fabric | **Fabric materialized lake views constraints** | Native Delta/Iceberg support, lineage integration, no external dependencies |
|
||||
| Spark-based data pipelines med strict quality enforcement | **Databricks expectations (DLT)** | Declarative syntax, automatic DQ dashboards, fail pipeline on critical violations |
|
||||
| Early-stage data quality exploration (low maturity) | **Azure ML data quality monitoring signal** | No infrastructure setup, quick start med training dataset comparison |
|
||||
| Compliance-driven data quality documentation | **Purview Data Quality** | Audit logs, data quality scores per governance domain, alert notifications |
|
||||
| Real-time streaming data quality | **Fabric Eventstream + KQL DB + Azure ML Monitoring** | Low-latency validation, real-time drift detection |
|
||||
|
||||
### Decision tree: Velge data quality framework
|
||||
|
||||
```
|
||||
START
|
||||
↓
|
||||
Er du i Fabric-økosystemet?
|
||||
└─ JA → Bruk Fabric materialized lake views constraints for layered DQ
|
||||
└─ NEI → Har du Azure ML deployed models?
|
||||
└─ JA → Bruk Azure ML Model Monitoring for production monitoring
|
||||
└─ NEI → Har du multi-cloud data sources?
|
||||
└─ JA → Bruk Purview Data Quality for enterprise governance
|
||||
└─ NEI → Bruk Databricks expectations (DLT) for Spark pipelines
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### 1. Purview + Fabric Integration
|
||||
|
||||
**Setup:**
|
||||
1. Fabric Lakehouse: load data i Delta/Iceberg format
|
||||
2. Fabric workspace: grant Contributor til Purview MSI
|
||||
3. Purview Data Map: register Fabric source, run scan (service principal auth)
|
||||
4. Purview Unified Catalog: add Lakehouse tables til data product
|
||||
5. Purview Data Quality: configure connection (Tenant ID, Workspace ID, Lakehouse ID, Purview MSI credential)
|
||||
6. Profile → create rules → run DQ scan
|
||||
|
||||
**Virtual Network support:**
|
||||
- If Fabric tenant uses Private Link: check "Virtual Network" i connection screen, specify Azure region, add Private Link Resource ID
|
||||
- Set up Purview compute allocation for managed virtual network (separate step)
|
||||
|
||||
### 2. Azure ML + Purview Integration (Conceptual — Manual)
|
||||
|
||||
**Gap:** Ingen native integration (as of 2026-02).
|
||||
|
||||
**Workaround:**
|
||||
1. Azure ML Model Monitoring detects data drift → logs til Application Insights
|
||||
2. Azure Function (triggered by App Insights alert) → calls Purview REST API → initiates profiling job on production data asset
|
||||
3. Purview completes profiling → stores results → sends alert via email/Event Grid
|
||||
4. Data scientist reviews Purview profile vs. training data profile → decides on retraining
|
||||
|
||||
**Code snippet (Azure Function trigger):**
|
||||
|
||||
```python
|
||||
import requests
|
||||
from azure.identity import DefaultAzureCredential
|
||||
|
||||
def trigger_purview_profiling(data_asset_id, connection_id):
|
||||
credential = DefaultAzureCredential()
|
||||
token = credential.get_token("https://purview.azure.net/.default").token
|
||||
|
||||
headers = {"Authorization": f"Bearer {token}"}
|
||||
url = f"https://{purview_account}.purview.azure.com/dataQuality/assets/{data_asset_id}/profile"
|
||||
payload = {"connectionId": connection_id}
|
||||
|
||||
response = requests.post(url, headers=headers, json=payload)
|
||||
return response.json()
|
||||
```
|
||||
|
||||
### 3. Fabric + Azure ML Integration
|
||||
|
||||
**Scenario:** Train model i Azure ML, deploy til Azure ML online endpoint, monitor med Fabric-based data quality.
|
||||
|
||||
**Architecture:**
|
||||
```
|
||||
[Fabric Lakehouse] → Training data (Delta table)
|
||||
↓ (Azure ML reads via OneLake)
|
||||
[Azure ML training job] → Model artifact
|
||||
↓ (Deploy)
|
||||
[Azure ML online endpoint] → Inference data collection
|
||||
↓ (Write back to Fabric Lakehouse via Azure Function)
|
||||
[Fabric Lakehouse inference table] → Purview DQ scan
|
||||
```
|
||||
|
||||
**Implementation:**
|
||||
1. Azure ML online endpoint: enable data collection (stores JSON logs i Azure Blob)
|
||||
2. Azure Function (Event Grid trigger on blob creation) → parses JSON → writes til Fabric Lakehouse via REST API
|
||||
3. Fabric Lakehouse: Purview DQ scan på inference table → compare med training table profile
|
||||
|
||||
### 4. Databricks + Unity Catalog Data Quality
|
||||
|
||||
**Unity Catalog features:**
|
||||
- **Data lineage:** Column-level lineage fra source tables til trained models (captured via `mlflow.log_model()`)
|
||||
- **Audit logging:** Captures metadata access events (who accessed which dataset, when)
|
||||
- **Data quality via DLT expectations:** Enforces quality constraints in pipelines
|
||||
|
||||
**Best practice:**
|
||||
1. Define data quality standards i Unity Catalog tags (e.g., `"dq_tier": "gold"` for high-quality tables)
|
||||
2. Apply expectations i DLT pipelines based on tier (e.g., gold tier → `expect_or_fail`, silver tier → `expect_or_drop`)
|
||||
3. Monitor lineage: hvis model performance degraderer → trace back til upstream table via lineage → identify quality issues
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### 1. Compliance-krav
|
||||
|
||||
**Forvaltningsloven § 11b (automatisert enkeltvedtak):**
|
||||
- **Krav:** "Datagrunnlaget må være kvalitetssikret."
|
||||
- **Implementering:** Purview Data Quality scoring (minimum score: 80/100 for Gold-tier data brukt i vedtakssystemer) + monthly profiling + audit log retention (3 år)
|
||||
|
||||
**AI Act (High-Risk AI Systems):**
|
||||
- **Krav (Article 10):** Data quality management, including data governance, relevance, representativeness, accuracy, completeness.
|
||||
- **Implementering:**
|
||||
- Purview Data Quality: document data quality scores i compliance reports
|
||||
- Azure ML Model Monitoring: track data drift, maintain audit trail
|
||||
- Quarterly data quality review (documented i DPIA)
|
||||
|
||||
**GDPR Article 5(1)(d) — accuracy:**
|
||||
- **Krav:** Personal data må være "accurate and, where necessary, kept up to date."
|
||||
- **Implementering:** Purview freshness rules (e.g., "data må være < 24 timer gammel"), alert til data owner ved breach
|
||||
|
||||
### 2. Utredningsinstruksen § 4 — kvalitetssikring
|
||||
|
||||
**Krav:** "Utredningen skal være basert på best tilgjengelig kunnskap og data."
|
||||
|
||||
**Data quality checklist for AI-utredning:**
|
||||
- [ ] Training data profiling report (Purview) vedlagt utredningen
|
||||
- [ ] Data quality scores for alle datasets (minimum 70/100)
|
||||
- [ ] Data lineage dokumentert (Unity Catalog eller Purview lineage view)
|
||||
- [ ] Training vs. validation data drift analysis (Azure ML Monitoring)
|
||||
- [ ] Golden dataset versioned og arkivert (Azure Blob immutable storage)
|
||||
- [ ] Data quality monitoring plan for production phase (frequency, thresholds, alert recipients)
|
||||
|
||||
### 3. ROS-analyse: Data quality risks
|
||||
|
||||
| Risiko | Sannsynlighet | Konsekvens | Tiltak |
|
||||
|--------|---------------|------------|--------|
|
||||
| **Data drift i production** → degradert modellytelse | Høy | Høy (feilaktige vedtak) | Azure ML Model Monitoring med weekly alerts, automated retraining trigger ved drift > threshold |
|
||||
| **Incomplete training data** → biased model | Middels | Høy (diskriminering) | Purview completeness rules (e.g., "null rate < 5%"), fail training job hvis ikke oppfylt |
|
||||
| **Stale data** → irrelevante prediksjoner | Middels | Middels | Purview freshness rules med daily checks, alert til data owner |
|
||||
| **Schema changes i source system** → inference failures | Lav | Høy (system downtime) | Fabric materialized lake views constraints (FAIL action på schema mismatch), integration tests |
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Microsoft Purview Data Quality
|
||||
|
||||
**Pricing model:** Data Governance Processing Units (DGPU) pay-as-you-go.
|
||||
|
||||
**DGPU consumption:**
|
||||
- **Profiling:** ~0.5 DGPU per 100 columns profiled
|
||||
- **Data quality scan:** ~1-2 DGPU per 1M rows scanned (varies by rule complexity)
|
||||
- **Storage:** Metadata stored i Purview managed storage (included)
|
||||
|
||||
**Eksempel (monthly cost estimate, Norway East):**
|
||||
- 10 data assets (avg 50 columns each) × 4 monthly profiling scans = 100 DGPU
|
||||
- 10 data assets (avg 10M rows) × 4 monthly DQ scans = 80 DGPU
|
||||
- Total: ~180 DGPU/month × $0.30/DGPU ≈ **$54/month** (~550 NOK)
|
||||
|
||||
**Confidence:** Medium — pricing varierer med rule complexity, data volume.
|
||||
|
||||
**Licensing:**
|
||||
- Purview Data Quality er inkludert i Microsoft Purview accounts (ingen separat lisens)
|
||||
- Krever: Azure subscription med contributor access til resource group
|
||||
|
||||
### Azure Machine Learning Model Monitoring
|
||||
|
||||
**Pricing components:**
|
||||
- **Compute:** Monitoring jobs kjører på Azure ML compute (CPU clusters) — billed per compute hour
|
||||
- **Storage:** Production inference data stored i Azure Blob — standard storage rates
|
||||
- **Application Insights:** Monitoring metrics/alerts — standard AI pricing
|
||||
|
||||
**Eksempel (monthly cost estimate, Norway East):**
|
||||
- 1 model, daily monitoring (5-minute compute per run): ~2.5 compute hours/month × $0.10/hour = $0.25
|
||||
- Inference data storage (10 GB/month): $0.20
|
||||
- Application Insights (1000 alerts/month): $2.00
|
||||
- Total: **~$2.50/month** (~25 NOK)
|
||||
|
||||
**Confidence:** High.
|
||||
|
||||
**Licensing:**
|
||||
- Krever: Azure ML workspace (included i Azure subscription)
|
||||
- Model monitoring er included feature i Azure ML (no additional license)
|
||||
|
||||
### Microsoft Fabric Data Quality
|
||||
|
||||
**Pricing model:** Fabric Capacity Units (CU) for compute + OneLake storage.
|
||||
|
||||
**Consumption:**
|
||||
- **Materialized lake views refresh:** Billed som Spark compute (CU/hour)
|
||||
- **Data quality constraints:** No additional charge (native feature)
|
||||
- **OneLake storage:** $0.023/GB/month (standard rate)
|
||||
|
||||
**Eksempel (monthly cost estimate, F64 SKU):**
|
||||
- 10 MLVs, each refreshed daily (5 minutes compute per refresh): ~25 CU hours/month
|
||||
- F64 SKU (64 CU): $0.54/CU/hour × 25 = $13.50
|
||||
- OneLake storage (100 GB): $2.30
|
||||
- Total: **~$16/month** (~165 NOK)
|
||||
|
||||
**Confidence:** Medium — varies with MLV complexity, data volume.
|
||||
|
||||
**Licensing:**
|
||||
- Krever: Fabric capacity (F2 minimum, F64 recommended for production)
|
||||
- Ingen separat data quality license
|
||||
|
||||
### Azure Databricks Expectations (Delta Live Tables)
|
||||
|
||||
**Pricing model:** DBU (Databricks Units) + Azure VM compute.
|
||||
|
||||
**Consumption:**
|
||||
- **DLT pipelines:** Billed som Jobs Compute (1.0 DBU/hour × Azure VM rate)
|
||||
- **Expectations:** No additional charge (native DLT feature)
|
||||
|
||||
**Eksempel (monthly cost estimate, Standard_DS3_v2):**
|
||||
- 1 DLT pipeline, 4 daily runs (30 minutes per run): ~60 hours/month
|
||||
- Jobs Compute: 60 DBU × $0.15 (list price) = $9.00
|
||||
- Azure VM (DS3_v2): 60 hours × $0.20 = $12.00
|
||||
- Total: **~$21/month** (~215 NOK)
|
||||
|
||||
**Confidence:** High.
|
||||
|
||||
**Licensing:**
|
||||
- Krever: Azure Databricks workspace (Premium tier for Unity Catalog)
|
||||
- DLT included i Premium tier (no additional license)
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Key takeaways
|
||||
|
||||
1. **No single tool solves all data quality needs.** Microsoft-stacken krever hybrid approach:
|
||||
- **Purview** for enterprise governance, multi-cloud, compliance documentation
|
||||
- **Azure ML Monitoring** for deployed model drift detection
|
||||
- **Fabric** for lakehouse-native quality enforcement
|
||||
- **Databricks** for Spark-based pipeline quality (hvis bruker Databricks)
|
||||
|
||||
2. **Layered quality gates are essential.** Apply different quality checks ved hver layer (Bronze/Silver/Gold):
|
||||
- Bronze: Fail fast på critical schema violations
|
||||
- Silver: Isolate bad data (DROP action), log for remediation
|
||||
- Gold: Enterprise-wide scoring med Purview
|
||||
|
||||
3. **Automate quality monitoring for production models.** Data drift er inevitable — set up automated alerts + retraining triggers.
|
||||
|
||||
4. **Golden datasets reduce model training variability.** Maintain versioned, immutable validation datasets for consistent benchmarking.
|
||||
|
||||
5. **Data quality er compliance-kritisk for offentlig sektor.** Forvaltningsloven § 11b + AI Act krever dokumentert data quality management.
|
||||
|
||||
### Vanlige fallgruver
|
||||
|
||||
| Fallgruve | Symptom | Fix |
|
||||
|-----------|---------|-----|
|
||||
| **Manual quality checks** | Data quality issues oppdages for sent (post-inference) | Automate profiling + alerts med Purview eller Azure ML Monitoring |
|
||||
| **Quality checks kun på training data** | Production data drifter, model performance degraderer | Implement continuous monitoring på production inference data |
|
||||
| **No baseline for drift detection** | Vanskelig å vite når data quality er acceptable | Establish quality thresholds basert på training data profiling (e.g., "null rate < 5%") |
|
||||
| **Ignoring data lineage** | Root cause analysis tar for lang tid når issues oppstår | Enable Unity Catalog lineage eller Purview lineage for all data assets |
|
||||
| **No golden dataset** | Model performance varierer på tvers av testing runs | Create versioned golden dataset, use for consistent validation |
|
||||
|
||||
### Anti-patterns å unngå
|
||||
|
||||
1. **"Data cleaning fixes all quality issues":** Nei — data cleaning er remediation, ikke prevention. Bruk quality constraints (Fabric, Databricks) for å forhindre dårlig data fra å komme inn i systemet.
|
||||
2. **"Quality checks kun ved training time":** Production data endrer seg — continuous monitoring er obligatorisk.
|
||||
3. **"One-size-fits-all quality rules":** Forskjellige data tiers (Bronze/Silver/Gold) krever forskjellige quality levels. Gold-tier data for vedtakssystemer må ha strengere rules enn Bronze-tier raw data.
|
||||
4. **"Quality monitoring uten alerts":** Metrics uten actionable alerts er bortkastet effort. Set thresholds + notifications.
|
||||
|
||||
### Spørsmål å stille kunden
|
||||
|
||||
1. **"Har dere eksisterende data governance framework?"** (hvis ja → extend med Purview, hvis nei → start med Purview Data Quality)
|
||||
2. **"Hvilke data sources brukes til AI?"** (multi-cloud → Purview, Fabric-only → Fabric native DQ, Databricks → DLT expectations)
|
||||
3. **"Er modellen deployed til production?"** (hvis ja → prioriter Azure ML Model Monitoring, hvis nei → focus på training data profiling)
|
||||
4. **"Hvor ofte oppdateres source data?"** (real-time → Fabric Eventstream DQ, batch daily → Purview scheduled scans)
|
||||
5. **"Hvilke compliance-krav må dere møte?"** (Forvaltningsloven § 11b, AI Act, GDPR → Purview for audit logs + documentation)
|
||||
6. **"Har dere budget for data quality tooling?"** (limited → start med Azure ML DQ monitoring signal (gratis), gradual expansion til Purview)
|
||||
7. **"Hvem er data owner/steward?"** (sentralisert team → Purview centralized governance, distribuert → Unity Catalog distributed governance model)
|
||||
|
||||
### Anbefalte arkitektur-patterns per scenario
|
||||
|
||||
| Scenario | Pattern | Tools |
|
||||
|----------|---------|-------|
|
||||
| **Offentlig sektor AI-vedtakssystem** | Layered Quality Gates + Compliance Documentation | Fabric (Bronze/Silver constraints) + Purview (Gold scoring + audit logs) + Azure ML Monitoring (production) |
|
||||
| **Real-time fraud detection** | Real-Time Data Quality for Streaming AI | Fabric Eventstream + KQL DB + Azure ML Monitoring |
|
||||
| **Multi-cloud data lake** | Enterprise Governance with Multi-Cloud Sources | Purview Data Quality + Unity Catalog (hvis Databricks) |
|
||||
| **Spark-based ETL pipelines** | Declarative Quality Constraints | Databricks DLT expectations |
|
||||
| **Quick POC (low maturity)** | Training vs. Production Monitoring | Azure ML data quality monitoring signal |
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
### Microsoft dokumentasjon
|
||||
|
||||
1. **Microsoft Purview Data Quality Overview**
|
||||
https://learn.microsoft.com/en-us/purview/data-quality-overview
|
||||
*Lesedato: 2026-02* — Comprehensive guide to Purview DQ lifecycle, features, pricing.
|
||||
|
||||
2. **Azure Machine Learning Model Monitoring**
|
||||
https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring
|
||||
*Lesedato: 2026-02* — Monitoring signals, best practices, setup instructions.
|
||||
|
||||
3. **Fabric Materialized Lake Views Data Quality**
|
||||
https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/data-quality
|
||||
*Lesedato: 2026-02* — MLV constraints syntax, FAIL/DROP actions, limitations.
|
||||
|
||||
4. **Databricks Data Governance Best Practices**
|
||||
https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices
|
||||
*Lesedato: 2026-02* — Data quality standards, DLT expectations, Unity Catalog lineage.
|
||||
|
||||
5. **Test and Evaluate AI Workloads on Azure**
|
||||
https://learn.microsoft.com/en-us/azure/well-architected/ai/test
|
||||
*Lesedato: 2026-02* — Testing guidance for model training/fine-tuning, data quality checks.
|
||||
|
||||
6. **Purview Data Quality for Fabric Lakehouse**
|
||||
https://learn.microsoft.com/en-us/purview/unified-catalog-data-quality-fabric-lakehouse
|
||||
*Lesedato: 2026-02* — Setup guide for Purview DQ scan on Fabric data.
|
||||
|
||||
7. **Azure ML Configure Training, Validation, Cross-Validation Data**
|
||||
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-configure-cross-validation-data-splits
|
||||
*Lesedato: 2026-02* — Best practices for data splits, validation dataset setup.
|
||||
|
||||
8. **Cloud Adoption Framework: Data Quality**
|
||||
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/govern-data-quality
|
||||
*Lesedato: 2026-02* — Data quality considerations, recommendations for enterprise scale.
|
||||
|
||||
### Code samples (Microsoft Learn)
|
||||
|
||||
- **Azure ML fine-tuning job with validation data**
|
||||
https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/fine-tune-serverless
|
||||
Python SDK sample for creating validation dataset asset.
|
||||
|
||||
- **AutoML training/validation MLTable inputs**
|
||||
https://learn.microsoft.com/en-us/azure/machine-learning/tutorial-auto-train-image-models
|
||||
Python SDK sample for Input objects (training/validation data).
|
||||
|
||||
- **MLflow traces quality analysis**
|
||||
https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/build-eval-dataset
|
||||
Python sample for filtering traces by quality score, correlation analysis.
|
||||
|
||||
### Confidence markers
|
||||
|
||||
- **GA status:** Microsoft Purview Data Quality (GA), Azure ML Model Monitoring (GA), Fabric data quality (GA), Databricks DLT expectations (GA) — alle features er production-ready per 2026-02.
|
||||
- **Pricing estimates:** Medium-High confidence — basert på official pricing pages (learn.microsoft.com), men actual consumption varierer med data volume og rule complexity.
|
||||
- **Virtual Network support:** Purview DQ for Fabric Lakehouse via Private Link er bekreftet i official docs (as of 2026-02), men BigQuery virtual network support er eksplisitt dokumentert som "not yet supported."
|
||||
- **Integration gaps:** Azure ML + Purview native integration finnes ikke (as of 2026-02) — workaround via Azure Functions er architectural recommendation, ikke officially supported pattern.
|
||||
|
||||
### Sist verifisert
|
||||
|
||||
**2026-02-11** — Alle lenker testet, pricing bekreftet mot official docs.
|
||||
|
|
@ -0,0 +1,513 @@
|
|||
# Data Sampling and Labeling Strategies
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Kvaliteten pa treningsdata er den viktigste faktoren for ytelsen til ML-modeller. Effektiv datasampling sikrer at treningsdatasettet er representativt og balansert, mens systematisk datamerking (labeling) gir modellene de korrekte signalene a laere fra. Azure Machine Learning tilbyr en komplett plattform for datamerking med stotte for bade bilde- og tekstdata, inkludert ML-assistert merking som akselererer prosessen vesentlig.
|
||||
|
||||
For norsk offentlig sektor, der data ofte er ubalansert (f.eks. svaert fa svindeltilfeller vs. legitime transaksjoner, eller sjaeldne hendelser i trafikkdata), er stratifisert sampling og aktiv laering spesielt viktig. Riktig sampling reduserer merkebehovet med 50-80%, noe som sparer bade tid og kostnader i prosjekter med stramme budsjetter.
|
||||
|
||||
Denne referansen dekker hele livssyklusen fra datautvalg gjennom merkeprosesser til kvalitetskontroll, med fokus pa teknikker som er relevante for Microsoft AI-stakken og Azure Machine Learning.
|
||||
|
||||
---
|
||||
|
||||
## Stratified Sampling for Class Balance
|
||||
|
||||
### Problemet med ubalanserte datasett
|
||||
|
||||
| Scenario | Positiv klasse | Negativ klasse | Ubalanse-ratio |
|
||||
|----------|---------------|----------------|----------------|
|
||||
| Svindeldeteksjon | 0.1% svindel | 99.9% legitim | 1:1000 |
|
||||
| Ulykkesprediksjon | 2% ulykker | 98% normal trafikk | 1:50 |
|
||||
| Dokumentklassifisering | 5% sensitiv | 95% ikke-sensitiv | 1:19 |
|
||||
| Feildeteksjon (IoT) | 0.5% feil | 99.5% normal | 1:200 |
|
||||
|
||||
### Stratifisert sampling i PySpark
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
|
||||
def stratified_sample(df, label_column, sample_fractions, seed=42):
|
||||
"""
|
||||
Utfor stratifisert sampling for a balansere klasser.
|
||||
|
||||
Args:
|
||||
df: Input DataFrame
|
||||
label_column: Kolonnen som inneholder klassen
|
||||
sample_fractions: Dict med {klasse: samplingandel}
|
||||
seed: Random seed for reproduserbarhet
|
||||
"""
|
||||
sampled = df.sampleBy(label_column, fractions=sample_fractions, seed=seed)
|
||||
return sampled
|
||||
|
||||
# Eksempel: Balanser svindeldatasett
|
||||
# Original: 99.9% legitim, 0.1% svindel
|
||||
sample_fractions = {
|
||||
"legitimate": 0.01, # Sample 1% av legitime (reduser fra 99.9k til ~1k)
|
||||
"fraud": 1.0 # Behold alle svindeltilfeller (~100)
|
||||
}
|
||||
|
||||
balanced_df = stratified_sample(
|
||||
df_transactions,
|
||||
label_column="transaction_type",
|
||||
sample_fractions=sample_fractions
|
||||
)
|
||||
|
||||
print(f"Original: {df_transactions.count()} rader")
|
||||
print(f"Balansert: {balanced_df.count()} rader")
|
||||
print("Klassefordeling:")
|
||||
balanced_df.groupBy("transaction_type").count().show()
|
||||
```
|
||||
|
||||
### Oversampling og undersampling-teknikker
|
||||
|
||||
```python
|
||||
def oversample_minority_class(df, label_column, minority_class, target_ratio=0.5):
|
||||
"""
|
||||
Oversample minoritetsklassen ved a duplisere rader.
|
||||
|
||||
Args:
|
||||
target_ratio: Onsket andel av minoritetsklassen
|
||||
"""
|
||||
class_counts = df.groupBy(label_column).count().collect()
|
||||
counts = {row[label_column]: row["count"] for row in class_counts}
|
||||
|
||||
minority_count = counts[minority_class]
|
||||
majority_count = sum(v for k, v in counts.items() if k != minority_class)
|
||||
|
||||
# Beregn hvor mange ganger minoritetsklassen ma dupliseres
|
||||
desired_minority = int(majority_count * target_ratio / (1 - target_ratio))
|
||||
oversample_factor = desired_minority / minority_count
|
||||
|
||||
# Oversample
|
||||
minority_df = df.filter(F.col(label_column) == minority_class)
|
||||
majority_df = df.filter(F.col(label_column) != minority_class)
|
||||
|
||||
oversampled = minority_df.sample(
|
||||
withReplacement=True,
|
||||
fraction=oversample_factor,
|
||||
seed=42
|
||||
)
|
||||
|
||||
return majority_df.unionByName(oversampled)
|
||||
|
||||
# Bruk
|
||||
balanced = oversample_minority_class(
|
||||
df_training,
|
||||
label_column="incident_type",
|
||||
minority_class="accident",
|
||||
target_ratio=0.3 # 30% ulykker i treningsdatasettet
|
||||
)
|
||||
```
|
||||
|
||||
### SMOTE-lignende syntetisk oversampling
|
||||
|
||||
```python
|
||||
from pyspark.ml.feature import VectorAssembler
|
||||
from pyspark.ml.clustering import KMeans
|
||||
import numpy as np
|
||||
|
||||
def synthetic_oversampling(df, feature_columns, label_column, minority_class, n_synthetic):
|
||||
"""
|
||||
Generer syntetiske minoritetseksempler basert pa naeromrade-interpolering.
|
||||
"""
|
||||
minority_df = df.filter(F.col(label_column) == minority_class)
|
||||
|
||||
# Vektoriser features
|
||||
assembler = VectorAssembler(inputCols=feature_columns, outputCol="features")
|
||||
vectorized = assembler.transform(minority_df)
|
||||
|
||||
# For hver minoritetsrad: finn naermeste nabo og interpolder
|
||||
# Forenklet implementering med KMeans for cluster-sentre
|
||||
kmeans = KMeans(k=min(n_synthetic, minority_df.count()), seed=42)
|
||||
model = kmeans.fit(vectorized)
|
||||
|
||||
# Bruk cluster-sentrene som syntetiske punkter
|
||||
centers = model.clusterCenters()
|
||||
|
||||
synthetic_rows = []
|
||||
for center in centers:
|
||||
row = {col: float(center[i]) for i, col in enumerate(feature_columns)}
|
||||
row[label_column] = minority_class
|
||||
row["_synthetic"] = True
|
||||
synthetic_rows.append(row)
|
||||
|
||||
synthetic_df = spark.createDataFrame(synthetic_rows)
|
||||
return df.withColumn("_synthetic", F.lit(False)).unionByName(synthetic_df, allowMissingColumns=True)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Active Learning and Uncertainty Sampling
|
||||
|
||||
### Prinsippet bak aktiv laering
|
||||
|
||||
Aktiv laering velger de mest informative eksemplene for merking, i stedet for a merke tilfeldig:
|
||||
|
||||
```
|
||||
+-- Umerkede data (pool) --+
|
||||
| |
|
||||
| [Hogt sikker] -> Hopp over, allerede laert
|
||||
| [Moderat sikker] -> Hopp over
|
||||
| [Usikker] -> MERK DENNE! <-- Mest laererik
|
||||
| [Veldig usikker] -> MERK DENNE! <-- Hoyest prioritet
|
||||
| |
|
||||
+---------------------------+
|
||||
```
|
||||
|
||||
### Usikkerhetssamplings-strategier
|
||||
|
||||
| Strategi | Formel | Best for |
|
||||
|----------|--------|----------|
|
||||
| **Least Confidence** | 1 - max(P(y\|x)) | Generell klassifisering |
|
||||
| **Margin Sampling** | P(y1\|x) - P(y2\|x) | Naere beslutningsgrenser |
|
||||
| **Entropy Sampling** | -sum(P(y\|x) * log P(y\|x)) | Multi-class problemer |
|
||||
| **Query-by-Committee** | Uenighet mellom modeller | Ensemble-basert |
|
||||
|
||||
### Implementering av aktiv laering
|
||||
|
||||
```python
|
||||
import numpy as np
|
||||
from sklearn.ensemble import RandomForestClassifier
|
||||
|
||||
class ActiveLearner:
|
||||
"""
|
||||
Aktiv laering med usikkerhetssampling for iterativ datamerking.
|
||||
"""
|
||||
|
||||
def __init__(self, model=None, strategy="entropy"):
|
||||
self.model = model or RandomForestClassifier(n_estimators=100)
|
||||
self.strategy = strategy
|
||||
self.labeled_indices = []
|
||||
self.labels = []
|
||||
|
||||
def initial_sample(self, X, n_initial=100):
|
||||
"""Velg et tilfeldig initialt treningssett."""
|
||||
indices = np.random.choice(len(X), n_initial, replace=False)
|
||||
self.labeled_indices = list(indices)
|
||||
return indices
|
||||
|
||||
def query(self, X, n_samples=50):
|
||||
"""Velg de mest informative eksemplene for merking."""
|
||||
# Prediksjonssannsynligheter for umerkede data
|
||||
unlabeled_mask = np.ones(len(X), dtype=bool)
|
||||
unlabeled_mask[self.labeled_indices] = False
|
||||
unlabeled_indices = np.where(unlabeled_mask)[0]
|
||||
|
||||
if len(unlabeled_indices) == 0:
|
||||
return np.array([])
|
||||
|
||||
X_unlabeled = X[unlabeled_indices]
|
||||
probas = self.model.predict_proba(X_unlabeled)
|
||||
|
||||
# Beregn usikkerhetsscorer
|
||||
if self.strategy == "entropy":
|
||||
scores = -np.sum(probas * np.log(probas + 1e-10), axis=1)
|
||||
elif self.strategy == "least_confidence":
|
||||
scores = 1 - np.max(probas, axis=1)
|
||||
elif self.strategy == "margin":
|
||||
sorted_probas = np.sort(probas, axis=1)
|
||||
scores = 1 - (sorted_probas[:, -1] - sorted_probas[:, -2])
|
||||
|
||||
# Velg top-n mest usikre
|
||||
top_indices = np.argsort(scores)[-n_samples:]
|
||||
return unlabeled_indices[top_indices]
|
||||
|
||||
def teach(self, X, y, indices, labels):
|
||||
"""Oppdater modellen med nylig merkede data."""
|
||||
self.labeled_indices.extend(indices)
|
||||
self.labels.extend(labels)
|
||||
|
||||
X_labeled = X[self.labeled_indices]
|
||||
y_labeled = np.array(self.labels)
|
||||
|
||||
self.model.fit(X_labeled, y_labeled)
|
||||
|
||||
# Brukseksempel
|
||||
learner = ActiveLearner(strategy="entropy")
|
||||
|
||||
# Runde 1: Tilfeldig initialt sett
|
||||
initial_idx = learner.initial_sample(X_pool, n_initial=100)
|
||||
initial_labels = get_labels_from_labelers(X_pool[initial_idx])
|
||||
learner.teach(X_pool, None, initial_idx, initial_labels)
|
||||
|
||||
# Runde 2-N: Aktiv laering
|
||||
for round_num in range(10):
|
||||
query_idx = learner.query(X_pool, n_samples=50)
|
||||
new_labels = get_labels_from_labelers(X_pool[query_idx])
|
||||
learner.teach(X_pool, None, query_idx, new_labels)
|
||||
print(f"Runde {round_num + 1}: Totalt merket = {len(learner.labeled_indices)}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Crowdsourcing and Labeling Platforms
|
||||
|
||||
### Azure Machine Learning Data Labeling
|
||||
|
||||
Azure ML tilbyr en komplett merkeplattform med stotte for:
|
||||
|
||||
| Funksjon | Beskrivelse |
|
||||
|----------|-------------|
|
||||
| **Bildeklassifisering** | Multi-class og multi-label |
|
||||
| **Objektdeteksjon** | Bounding boxes |
|
||||
| **Instanssegmentering** | Polygoner |
|
||||
| **Semantisk segmentering** | Piksel-niva (preview) |
|
||||
| **Tekstklassifisering** | Single og multi-label |
|
||||
| **Named Entity Recognition** | Tekst-span-merking |
|
||||
|
||||
### Opprette et merkeprosjekt
|
||||
|
||||
```python
|
||||
# Azure ML SDK v2 - Opprett bildeklassifiseringsprosjekt
|
||||
from azure.ai.ml import MLClient
|
||||
from azure.ai.ml.entities import DataLabelingJob
|
||||
|
||||
# Opprett klient
|
||||
ml_client = MLClient(credential, subscription_id, resource_group, workspace_name)
|
||||
|
||||
# Definer merkeprosjekt
|
||||
labeling_job = DataLabelingJob(
|
||||
display_name="traffic-sign-classification",
|
||||
description="Klassifiser trafikkskilt fra vegkamera",
|
||||
labeling_job_type="ImageClassificationMulticlass",
|
||||
data={"uri": "azureml://datastores/images/paths/traffic_signs/"},
|
||||
labels={
|
||||
"classes": [
|
||||
{"name": "speed_limit", "display_name": "Fartsgrense"},
|
||||
{"name": "stop", "display_name": "Stopp"},
|
||||
{"name": "yield", "display_name": "Vikeplikt"},
|
||||
{"name": "no_entry", "display_name": "Innkjoring forbudt"},
|
||||
{"name": "pedestrian", "display_name": "Fotgjenger"},
|
||||
{"name": "construction", "display_name": "Veiarbeid"},
|
||||
{"name": "other", "display_name": "Annet"}
|
||||
]
|
||||
},
|
||||
properties={
|
||||
"ml_assist_enabled": True, # Aktiver ML-assistert merking
|
||||
"consensus_labeling_enabled": True, # Krev konsensus
|
||||
"min_label_count": 2 # Minimum 2 merkere per bilde
|
||||
}
|
||||
)
|
||||
|
||||
# Opprett prosjekt
|
||||
created_job = ml_client.labeling_jobs.begin_create_or_update(labeling_job)
|
||||
```
|
||||
|
||||
### ML-Assisted Labeling
|
||||
|
||||
ML-assistert merking i Azure ML akselererer prosessen gjennom to faser:
|
||||
|
||||
```
|
||||
Fase 1: CLUSTERING
|
||||
+-- Merkere merker ~300 bilder manuelt
|
||||
+-- ML-modell grupperer lignende bilder
|
||||
+-- Merkere ser klynger av like bilder (raskere merking)
|
||||
|
||||
Fase 2: PRE-LABELING
|
||||
+-- Modell trenes pa merkede data
|
||||
+-- Modell foreslaar etiketter for umerkede bilder
|
||||
+-- Merkere bekrefter/korrigerer forhondsetiketter
|
||||
+-- Prosessen gjentas iterativt
|
||||
```
|
||||
|
||||
**Viktige hensyn:**
|
||||
- Transfer learning akselererer opplaering: Noen ganger trengs kun 300 merkede eksempler
|
||||
- Konsensus-etiketter brukes for trening naar aktivert
|
||||
- Bilder shuffles tilfeldig for a redusere bias
|
||||
- Tekstinnholdet begrenses til ~128 ord for treningseffektivitet
|
||||
|
||||
---
|
||||
|
||||
## Quality Control and Inter-Rater Agreement
|
||||
|
||||
### Konsensus-merking
|
||||
|
||||
```python
|
||||
# Implementer konsensusbasert kvalitetskontroll
|
||||
from collections import Counter
|
||||
|
||||
def calculate_inter_rater_agreement(labels_per_item: dict) -> dict:
|
||||
"""
|
||||
Beregn inter-rater agreement (IRA) for merkede data.
|
||||
|
||||
Args:
|
||||
labels_per_item: {item_id: [label_from_rater1, label_from_rater2, ...]}
|
||||
|
||||
Returns:
|
||||
Statistikk over enighet
|
||||
"""
|
||||
agreements = []
|
||||
disagreements = []
|
||||
|
||||
for item_id, labels in labels_per_item.items():
|
||||
counter = Counter(labels)
|
||||
most_common_label, most_common_count = counter.most_common(1)[0]
|
||||
total_raters = len(labels)
|
||||
|
||||
agreement_ratio = most_common_count / total_raters
|
||||
|
||||
if agreement_ratio >= 0.8:
|
||||
agreements.append({
|
||||
"item_id": item_id,
|
||||
"consensus_label": most_common_label,
|
||||
"agreement": agreement_ratio
|
||||
})
|
||||
else:
|
||||
disagreements.append({
|
||||
"item_id": item_id,
|
||||
"labels": dict(counter),
|
||||
"agreement": agreement_ratio
|
||||
})
|
||||
|
||||
total = len(labels_per_item)
|
||||
return {
|
||||
"total_items": total,
|
||||
"agreed": len(agreements),
|
||||
"disagreed": len(disagreements),
|
||||
"agreement_rate": round(len(agreements) / max(total, 1) * 100, 1),
|
||||
"disagreed_items": disagreements[:10] # Vis topp 10 uenigheter
|
||||
}
|
||||
```
|
||||
|
||||
### Cohens Kappa for kvalitetsmalinger
|
||||
|
||||
```python
|
||||
from sklearn.metrics import cohen_kappa_score
|
||||
|
||||
def evaluate_labeler_quality(rater1_labels, rater2_labels):
|
||||
"""
|
||||
Beregn Cohens Kappa mellom to merkere.
|
||||
|
||||
Tolkning:
|
||||
- < 0.20: Darlig enighet
|
||||
- 0.21-0.40: Moderat enighet
|
||||
- 0.41-0.60: Moderat enighet
|
||||
- 0.61-0.80: Substansiell enighet
|
||||
- 0.81-1.00: Naer perfekt enighet
|
||||
"""
|
||||
kappa = cohen_kappa_score(rater1_labels, rater2_labels)
|
||||
|
||||
if kappa < 0.40:
|
||||
quality = "LAV - Gjennomga retningslinjer og gi oppfolging"
|
||||
elif kappa < 0.60:
|
||||
quality = "MODERAT - Akseptabel for screening, ikke for endelig trening"
|
||||
elif kappa < 0.80:
|
||||
quality = "GOD - Akseptabel for de fleste ML-oppgaver"
|
||||
else:
|
||||
quality = "UTMERKET - Hoy kvalitet for treningsdata"
|
||||
|
||||
return {"kappa": round(kappa, 3), "quality": quality}
|
||||
|
||||
# Eksempel
|
||||
result = evaluate_labeler_quality(
|
||||
rater1_labels=["positive", "negative", "positive", "neutral", "positive"],
|
||||
rater2_labels=["positive", "negative", "neutral", "neutral", "positive"]
|
||||
)
|
||||
```
|
||||
|
||||
### Kvalitetskontrollpipeline
|
||||
|
||||
```
|
||||
1. Initial merking (2-3 merkere per element)
|
||||
|
|
||||
2. Beregn inter-rater agreement (IRA)
|
||||
|
|
||||
3. IRA >= 80%? --> Bruk konsensus-etikett
|
||||
|
|
||||
4. IRA < 80%? --> Send til ekspert-merker (adjudicator)
|
||||
|
|
||||
5. Ekspert avgjer endelig etikett
|
||||
|
|
||||
6. Oppdater merkeretningslinjer basert pa uenigheter
|
||||
|
|
||||
7. Re-tren ML-assist-modell med nye etiketter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Feedback Loops for Continuous Labeling
|
||||
|
||||
### Produksjonsdata tilbake til merking
|
||||
|
||||
```python
|
||||
def identify_candidates_for_relabeling(model, new_data_df, confidence_threshold=0.6):
|
||||
"""
|
||||
Identifiser prediksjoner med lav konfidens for manuell gjennomgang.
|
||||
"""
|
||||
predictions = model.predict_proba(new_data_df)
|
||||
|
||||
low_confidence = new_data_df.filter(
|
||||
F.col("prediction_confidence") < confidence_threshold
|
||||
)
|
||||
|
||||
# Prioriter etter usikkerhet
|
||||
candidates = low_confidence.orderBy(F.col("prediction_confidence").asc())
|
||||
|
||||
# Legg til i merke-ko
|
||||
candidates.select(
|
||||
"record_id", "features", "prediction", "prediction_confidence"
|
||||
).write.format("delta").mode("append") \
|
||||
.saveAsTable("lakehouse.default.labeling_queue")
|
||||
|
||||
return candidates.count()
|
||||
|
||||
# Kjor daglig
|
||||
n_candidates = identify_candidates_for_relabeling(
|
||||
model=production_model,
|
||||
new_data_df=todays_predictions,
|
||||
confidence_threshold=0.6
|
||||
)
|
||||
print(f"{n_candidates} nye elementer lagt til merke-koen")
|
||||
```
|
||||
|
||||
### Drift-deteksjon og re-merking
|
||||
|
||||
```python
|
||||
def detect_label_drift(historical_labels_df, recent_labels_df, columns):
|
||||
"""
|
||||
Oppdager endringer i etikettdistribusjon over tid.
|
||||
"""
|
||||
from scipy.stats import chi2_contingency
|
||||
|
||||
for col in columns:
|
||||
hist_dist = historical_labels_df.groupBy(col).count().toPandas()
|
||||
recent_dist = recent_labels_df.groupBy(col).count().toPandas()
|
||||
|
||||
# Chi-kvadrat-test
|
||||
contingency = hist_dist.merge(recent_dist, on=col, suffixes=["_hist", "_recent"])
|
||||
chi2, p_value, dof, expected = chi2_contingency(
|
||||
contingency[["count_hist", "count_recent"]].values.T
|
||||
)
|
||||
|
||||
if p_value < 0.05:
|
||||
print(f"DRIFT OPPDAGET i '{col}': p={p_value:.4f}")
|
||||
print(f" Historisk: {dict(zip(hist_dist[col], hist_dist['count']))}")
|
||||
print(f" Nylig: {dict(zip(recent_dist[col], recent_dist['count']))}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Set up an image labeling project](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-image-labeling-projects) -- Bildedatamerking i Azure ML
|
||||
- [Set up a text labeling project](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-text-labeling-projects) -- Tekstdatamerking i Azure ML
|
||||
- [Labeling images and text documents](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-label-data) -- Merkerverktoy og ML-assistert merking
|
||||
- [Prepare data for computer vision tasks](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-prepare-datasets-for-automl-images) -- Data for AutoML-bildemodeller
|
||||
- [Label text data for training](https://learn.microsoft.com/en-us/azure/ai-services/language-service/custom-text-classification/how-to/tag-data) -- Merking for Custom Language Models
|
||||
- [Create and explore datasets with labels](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-labeled-dataset) -- Bruk av merkede datasett i Azure ML
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder planlegger datamerkings-prosjekter for ML-modeller, eller naar de trenger strategier for a hondtere ubalanserte datasett.
|
||||
- **Azure ML Data Labeling er forstevalget** for merkingsprosjekter i Microsoft-stakken. ML-assistert merking kan redusere manuelt arbeid med 50-80% etter initiell opplaering.
|
||||
- **Aktiv laering bor alltid vurderes** for store umerkede datasett -- det reduserer merkekostnader dramatisk ved a prioritere de mest informative eksemplene.
|
||||
- **Kvalitetskontroll er ikke valgfritt**: Krev konsensus mellom merkere (minimum 2), mal inter-rater agreement, og ha en ekspert-adjudicator for uenigheter.
|
||||
- **For norsk offentlig sektor**: Vurder personvernaspekter ved merking av data som kan inneholde personopplysninger. Bruk PII-deteksjon for a fjerne sensitiv informasjon for merkerne ser dataene.
|
||||
|
|
@ -0,0 +1,447 @@
|
|||
# Data Versioning and Lineage Tracking
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Dataversionskontroll og lineage-sporing er grunnleggende kapabiliteter for pålitelige AI-systemer. Versjonskontroll gjør det mulig å reprodusere eksakt de dataene en modell ble trent på, mens lineage dokumenterer hele datareisen fra kilde til ferdig prediksjon. Sammen gir de sporbarhet, reproduserbarhet og tillitsgrunnlag for AI-beslutninger.
|
||||
|
||||
For norsk offentlig sektor er dette spesielt viktig gitt kravene i Utredningsinstruksen om etterprøvbarhet, Forvaltningslovens krav til dokumentasjon av vedtak, og EU AI Act sine krav til høyrisiko AI-systemer. En modell som påvirker borgeres rettigheter -- for eksempel NAV-ytelser eller byggetillatelser -- må kunne forklares og dokumenteres fra kilde til prediksjon.
|
||||
|
||||
Denne referansen dekker Delta Lake versjonskontroll og tidsreise, commit-historikk og audit trails, lineage-visualisering i Purview og Fabric, avhengighetskartlegging, og strategier for rollback og gjenoppretting.
|
||||
|
||||
---
|
||||
|
||||
## Delta Lake Versioning and Time-Travel
|
||||
|
||||
### Versjonskontroll-modell
|
||||
|
||||
Delta Lake bruker en Write-Ahead Log (WAL) i `_delta_log`-mappen som registrerer alle transaksjoner:
|
||||
|
||||
```
|
||||
Tables/ml_training_data/
|
||||
├── _delta_log/
|
||||
│ ├── 00000000000000000000.json # v0: Initial create (2026-01-01)
|
||||
│ ├── 00000000000000000001.json # v1: Append new data (2026-01-15)
|
||||
│ ├── 00000000000000000002.json # v2: Feature update (2026-02-01)
|
||||
│ ├── 00000000000000000003.json # v3: Delete PII (2026-02-05)
|
||||
│ └── 00000000000000000004.json # v4: Schema evolution (2026-02-10)
|
||||
├── part-00000-*.snappy.parquet
|
||||
├── part-00001-*.snappy.parquet
|
||||
└── ...
|
||||
```
|
||||
|
||||
### Versjonsspørringer
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
# Les nåværende versjon
|
||||
df_current = spark.read.format("delta").table("gold.ml_training_data")
|
||||
|
||||
# Les spesifikk versjon
|
||||
df_v2 = spark.read.format("delta") \
|
||||
.option("versionAsOf", 2) \
|
||||
.table("gold.ml_training_data")
|
||||
|
||||
# Les data slik de var på et tidspunkt
|
||||
df_jan = spark.read.format("delta") \
|
||||
.option("timestampAsOf", "2026-01-15T00:00:00Z") \
|
||||
.table("gold.ml_training_data")
|
||||
|
||||
# Sammenlign versjoner for å oppdage endringer
|
||||
from pyspark.sql.functions import col
|
||||
|
||||
added_rows = df_v2.subtract(df_v1) # Rader i v2 som ikke finnes i v1
|
||||
removed_rows = df_v1.subtract(df_v2) # Rader i v1 som ikke finnes i v2
|
||||
|
||||
print(f"Nye rader: {added_rows.count()}")
|
||||
print(f"Fjernede rader: {removed_rows.count()}")
|
||||
```
|
||||
|
||||
### Versjonskontroll for ML-eksperimenter
|
||||
|
||||
```python
|
||||
import mlflow
|
||||
|
||||
# Logg data-versjon som del av ML-eksperiment
|
||||
with mlflow.start_run(run_name="churn_model_v3"):
|
||||
# Hent Delta-tabell-versjon
|
||||
dt = DeltaTable.forPath(spark, "Tables/gold/ml_training_data")
|
||||
current_version = dt.history(1).select("version").collect()[0][0]
|
||||
|
||||
# Logg metadata
|
||||
mlflow.log_param("data_table", "gold.ml_training_data")
|
||||
mlflow.log_param("data_version", current_version)
|
||||
mlflow.log_param("data_timestamp", "2026-02-10T00:00:00Z")
|
||||
mlflow.log_param("row_count", df_current.count())
|
||||
mlflow.log_param("column_count", len(df_current.columns))
|
||||
|
||||
# Tren modell...
|
||||
# mlflow.sklearn.log_model(model, "model")
|
||||
|
||||
# Senere: Reproduser treningsdata eksakt
|
||||
# df_reproduced = spark.read.format("delta")
|
||||
# .option("versionAsOf", logged_version)
|
||||
# .table("gold.ml_training_data")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Commit History and Audit Trails
|
||||
|
||||
### DESCRIBE HISTORY
|
||||
|
||||
```sql
|
||||
-- Vis full transaksjonshistorikk
|
||||
DESCRIBE HISTORY gold.ml_training_data;
|
||||
|
||||
-- Resultat:
|
||||
-- version | timestamp | operation | operationParameters | operationMetrics
|
||||
-- 4 | 2026-02-10 14:30:00 | WRITE | {mode: Append} | {numFiles: 3, numOutputRows: 15000}
|
||||
-- 3 | 2026-02-05 09:15:00 | DELETE | {predicate: [pii_flag=1]} | {numDeletedRows: 250, numRemovedFiles: 2}
|
||||
-- 2 | 2026-02-01 02:00:00 | MERGE | {predicate: ...} | {numUpdatedRows: 3400, numInsertedRows: 1200}
|
||||
-- 1 | 2026-01-15 02:00:00 | WRITE | {mode: Append} | {numFiles: 5, numOutputRows: 50000}
|
||||
-- 0 | 2026-01-01 10:00:00 | CREATE | {partitionBy: [date]} | {numFiles: 10, numOutputRows: 100000}
|
||||
```
|
||||
|
||||
### PySpark History API
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
dt = DeltaTable.forPath(spark, "Tables/gold/ml_training_data")
|
||||
|
||||
# Hent historikk
|
||||
history = dt.history()
|
||||
|
||||
# Detaljert analyse av endringer
|
||||
display(
|
||||
history.select(
|
||||
"version",
|
||||
"timestamp",
|
||||
"operation",
|
||||
"operationParameters",
|
||||
"operationMetrics",
|
||||
"userName",
|
||||
"notebook.notebookId"
|
||||
).orderBy("version", ascending=False)
|
||||
)
|
||||
|
||||
# Filtrer på spesifikke operasjoner
|
||||
deletes = history.filter("operation = 'DELETE'")
|
||||
merges = history.filter("operation = 'MERGE'")
|
||||
```
|
||||
|
||||
### Custom Audit Logging
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
from datetime import datetime
|
||||
|
||||
def log_data_operation(operation, table_name, details, user="system"):
|
||||
"""Logg datapipelineoperasjoner til audit-tabell."""
|
||||
audit_record = spark.createDataFrame([{
|
||||
"timestamp": datetime.utcnow().isoformat(),
|
||||
"operation": operation,
|
||||
"table_name": table_name,
|
||||
"user": user,
|
||||
"details": str(details),
|
||||
"pipeline_run_id": spark.conf.get("spark.pipeline.runId", "interactive")
|
||||
}])
|
||||
|
||||
audit_record.write.format("delta") \
|
||||
.mode("append") \
|
||||
.saveAsTable("governance.data_audit_log")
|
||||
|
||||
# Bruk i pipeline
|
||||
log_data_operation(
|
||||
operation="FEATURE_UPDATE",
|
||||
table_name="gold.ml_training_data",
|
||||
details={
|
||||
"source_version": 3,
|
||||
"target_version": 4,
|
||||
"rows_added": 15000,
|
||||
"rows_updated": 3400,
|
||||
"features_modified": ["txn_7d_count", "income_band"]
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Lineage Visualization in Purview
|
||||
|
||||
### Lineage-kilder i Purview
|
||||
|
||||
Purview fanger automatisk lineage fra flere kilder:
|
||||
|
||||
| Dataprosesseringssystem | Lineage-omfang |
|
||||
|---|---|
|
||||
| **Azure Data Factory** | Copy Activity, Data Flow, SSIS |
|
||||
| **Fabric Data Factory** | Pipelines, Dataflow Gen2 |
|
||||
| **Fabric Notebooks** | Lakehouse → Lakehouse (item-level) |
|
||||
| **Azure Synapse Analytics** | Copy Activity, Data Flow |
|
||||
| **Power BI** | Semantic Model → Report → Dashboard |
|
||||
|
||||
### Lineage-visning i Fabric
|
||||
|
||||
```
|
||||
Lineage-visning for en ML-pipeline:
|
||||
|
||||
Azure SQL DB Lakehouse (Bronze) Lakehouse (Silver)
|
||||
┌──────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ customers│──Copy──>│ raw_customers│──Notebook>│ customer_360 │
|
||||
└──────────┘ └──────────────┘ └──────┬───────┘
|
||||
│
|
||||
Blob Storage Lakehouse (Bronze) │
|
||||
┌──────────┐ ┌──────────────┐ │ Notebook
|
||||
│ events │──Copy──>│ raw_events │──Notebook──>─────┘
|
||||
└──────────┘ └──────────────┘ │
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ Gold: │
|
||||
│ ml_features │
|
||||
└──────┬───────┘
|
||||
│
|
||||
┌──────▼───────┐
|
||||
│ ML Experiment│
|
||||
│ (MLflow) │
|
||||
└──────┬───────┘
|
||||
│
|
||||
┌──────▼───────┐
|
||||
│ Power BI │
|
||||
│ Dashboard │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
### Tilgang til lineage
|
||||
|
||||
Lineage i Fabric er tilgjengelig fra:
|
||||
1. **Workspace toolbar**: Velg "Lineage view"
|
||||
2. **Item options menu**: Høyreklikk på element → "View lineage"
|
||||
3. **Item details page**: Under menyelementer øverst
|
||||
4. **Purview Unified Catalog**: Browse → Microsoft Fabric → Fabric Workspaces
|
||||
|
||||
### Materialized Lake Views med auto-lineage
|
||||
|
||||
```sql
|
||||
-- Materialized Lake Views genererer automatisk lineage
|
||||
CREATE SCHEMA IF NOT EXISTS silver;
|
||||
|
||||
CREATE MATERIALIZED LAKE VIEW IF NOT EXISTS silver.customer_features AS
|
||||
SELECT
|
||||
c.customer_id,
|
||||
c.name,
|
||||
c.region,
|
||||
COUNT(t.transaction_id) AS total_transactions,
|
||||
SUM(t.amount) AS total_amount,
|
||||
AVG(t.amount) AS avg_transaction_amount
|
||||
FROM bronze.customers c
|
||||
JOIN bronze.transactions t ON c.customer_id = t.customer_id
|
||||
GROUP BY c.customer_id, c.name, c.region;
|
||||
|
||||
-- Lineage er automatisk sporet:
|
||||
-- bronze.customers + bronze.transactions → silver.customer_features
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Upstream/Downstream Dependency Mapping
|
||||
|
||||
### Avhengighetsgraf
|
||||
|
||||
```python
|
||||
# Kartlegg avhengigheter programmatisk
|
||||
dependency_graph = {
|
||||
"bronze.raw_customers": {
|
||||
"sources": ["Azure SQL DB: customers_table"],
|
||||
"consumers": ["silver.customer_360", "silver.customer_features"]
|
||||
},
|
||||
"silver.customer_360": {
|
||||
"sources": ["bronze.raw_customers", "bronze.raw_contacts", "bronze.raw_opportunities"],
|
||||
"consumers": ["gold.churn_features", "gold.revenue_predict_features"]
|
||||
},
|
||||
"gold.churn_features": {
|
||||
"sources": ["silver.customer_360", "silver.transaction_features"],
|
||||
"consumers": ["ML Experiment: churn_model_v3", "Power BI: Churn Dashboard"]
|
||||
}
|
||||
}
|
||||
|
||||
def get_upstream_dependencies(table_name, graph, depth=0, max_depth=5):
|
||||
"""Rekursivt finn alle oppstrøms avhengigheter."""
|
||||
if depth > max_depth or table_name not in graph:
|
||||
return []
|
||||
|
||||
sources = graph[table_name].get("sources", [])
|
||||
all_upstream = list(sources)
|
||||
|
||||
for source in sources:
|
||||
all_upstream.extend(
|
||||
get_upstream_dependencies(source, graph, depth + 1, max_depth)
|
||||
)
|
||||
|
||||
return all_upstream
|
||||
|
||||
def get_downstream_impact(table_name, graph, depth=0, max_depth=5):
|
||||
"""Finn alle nedstrøms konsumenter (impact-analyse)."""
|
||||
if depth > max_depth or table_name not in graph:
|
||||
return []
|
||||
|
||||
consumers = graph[table_name].get("consumers", [])
|
||||
all_downstream = list(consumers)
|
||||
|
||||
for consumer in consumers:
|
||||
all_downstream.extend(
|
||||
get_downstream_impact(consumer, graph, depth + 1, max_depth)
|
||||
)
|
||||
|
||||
return all_downstream
|
||||
|
||||
# Eksempel: Hva påvirkes hvis vi endrer bronze.raw_customers?
|
||||
impact = get_downstream_impact("bronze.raw_customers", dependency_graph)
|
||||
print(f"Påvirkede elementer: {impact}")
|
||||
# ['silver.customer_360', 'silver.customer_features',
|
||||
# 'gold.churn_features', 'gold.revenue_predict_features',
|
||||
# 'ML Experiment: churn_model_v3', 'Power BI: Churn Dashboard']
|
||||
```
|
||||
|
||||
### Data Contract Pattern
|
||||
|
||||
```python
|
||||
# Definer data contracts mellom lag
|
||||
data_contract = {
|
||||
"table": "silver.customer_360",
|
||||
"version": "2.1",
|
||||
"owner": "data-engineering@example.no",
|
||||
"sla": {
|
||||
"freshness": "24 hours",
|
||||
"completeness": "> 99.5%",
|
||||
"accuracy": "validated against source"
|
||||
},
|
||||
"schema": {
|
||||
"required_columns": ["customer_id", "name", "region", "total_revenue"],
|
||||
"column_types": {
|
||||
"customer_id": "string",
|
||||
"total_revenue": "double",
|
||||
"region": "string"
|
||||
},
|
||||
"partitioned_by": ["region"],
|
||||
"row_count_range": [100000, 500000]
|
||||
},
|
||||
"consumers": [
|
||||
{"team": "ml-team", "usage": "churn prediction features"},
|
||||
{"team": "bi-team", "usage": "customer dashboard"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Rollback and Recovery Strategies
|
||||
|
||||
### Delta Lake RESTORE
|
||||
|
||||
```sql
|
||||
-- Gjenopprett tabell til spesifikk versjon
|
||||
RESTORE TABLE gold.ml_training_data TO VERSION AS OF 2;
|
||||
|
||||
-- Gjenopprett til tidspunkt
|
||||
RESTORE TABLE gold.ml_training_data TO TIMESTAMP AS OF '2026-02-01T00:00:00Z';
|
||||
```
|
||||
|
||||
```python
|
||||
# PySpark RESTORE
|
||||
dt = DeltaTable.forPath(spark, "Tables/gold/ml_training_data")
|
||||
dt.restoreToVersion(2)
|
||||
|
||||
# Verifiser
|
||||
print(f"Gjenopprettet til versjon 2")
|
||||
print(f"Rader: {spark.read.format('delta').table('gold.ml_training_data').count()}")
|
||||
```
|
||||
|
||||
### Recovery-strategier
|
||||
|
||||
| Scenario | Strategi | Kommando |
|
||||
|---|---|---|
|
||||
| **Feilaktig DELETE** | Restore til forrige versjon | `RESTORE TABLE ... TO VERSION AS OF n-1` |
|
||||
| **Korrupt data lastet** | Restore til pre-load versjon | `RESTORE TABLE ... TO TIMESTAMP AS OF '...'` |
|
||||
| **Schema-feil** | Restore + re-apply korrekt schema | Restore + ALTER TABLE |
|
||||
| **Hel tabell tapt** | Gjenskape fra kildedata + audit log | Kjør pipeline på nytt |
|
||||
| **VACUUM kjørt for tidlig** | Ingen recovery mulig! | Forebygg: minimum 7d retention |
|
||||
|
||||
### Rollback av ML-eksperiment
|
||||
|
||||
```python
|
||||
import mlflow
|
||||
|
||||
def rollback_to_experiment(run_id):
|
||||
"""Gjenopprett data og modell fra en tidligere MLflow-run."""
|
||||
# Hent metadata fra MLflow
|
||||
run = mlflow.get_run(run_id)
|
||||
data_version = int(run.data.params["data_version"])
|
||||
data_table = run.data.params["data_table"]
|
||||
|
||||
# Gjenopprett treningsdata
|
||||
df_original = spark.read.format("delta") \
|
||||
.option("versionAsOf", data_version) \
|
||||
.table(data_table)
|
||||
|
||||
print(f"Gjenopprettet data fra versjon {data_version}")
|
||||
print(f"Rader: {df_original.count()}")
|
||||
|
||||
# Last modell
|
||||
model = mlflow.sklearn.load_model(f"runs:/{run_id}/model")
|
||||
|
||||
return df_original, model
|
||||
```
|
||||
|
||||
### Forebyggende tiltak
|
||||
|
||||
```python
|
||||
# 1. Sett minimum VACUUM-retensjon
|
||||
spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled", "true")
|
||||
# Standard 7 dager = 168 timer
|
||||
|
||||
# 2. Aktiver Change Data Feed for sporbar endringshåndtering
|
||||
spark.sql("""
|
||||
ALTER TABLE gold.ml_training_data
|
||||
SET TBLPROPERTIES (delta.enableChangeDataFeed = true)
|
||||
""")
|
||||
|
||||
# 3. Les Change Data Feed
|
||||
changes = spark.read.format("delta") \
|
||||
.option("readChangeFeed", "true") \
|
||||
.option("startingVersion", 3) \
|
||||
.option("endingVersion", 4) \
|
||||
.table("gold.ml_training_data")
|
||||
|
||||
# Viser _change_type: insert, update_preimage, update_postimage, delete
|
||||
display(changes.select("customer_id", "_change_type", "_commit_version", "_commit_timestamp"))
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Lineage in Fabric](https://learn.microsoft.com/en-us/fabric/governance/lineage) -- Innebygd lineage-visning i Fabric
|
||||
- [How to get lineage from Microsoft Fabric items into Microsoft Purview](https://learn.microsoft.com/en-us/purview/data-map-lineage-fabric) -- Purview lineage for Fabric
|
||||
- [Data lineage in classic Data Catalog](https://learn.microsoft.com/en-us/purview/data-gov-classic-lineage) -- Lineage-konsepter og granularitet
|
||||
- [Delta Lake table format interoperability](https://learn.microsoft.com/en-us/fabric/fundamentals/delta-lake-interoperability) -- Delta Lake-versjonering
|
||||
- [What is Delta Lake?](https://learn.microsoft.com/en-us/azure/synapse-analytics/spark/apache-spark-what-is-delta-lake) -- Delta Lake oversikt med time-travel
|
||||
- [Get started with materialized lake views](https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/get-started-with-materialized-lake-views) -- Auto-lineage via materialized views
|
||||
- [Data lineage (Cloud Adoption Framework)](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/govern-lineage) -- Lineage-strategi
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren trenger reproduserbarhet for ML-modeller, audit trail for AI-beslutninger, eller impact-analyse for dataendringer.
|
||||
- For norsk offentlig sektor: **Versjonskontroll er ikke valgfritt** for AI-systemer som påvirker borgere. EU AI Act krever sporbarhet for høyrisiko-systemer, og Utredningsinstruksen krever dokumentasjon av beslutningsgrunnlag.
|
||||
- Anbefal å logge **Delta-tabell-versjon** som MLflow-parameter for hvert eksperiment -- dette er den enkleste veien til reproduserbar ML.
|
||||
- **Change Data Feed** er kraftig for å forstå eksakt hva som endret seg mellom versjoner -- aktiver dette for alle Gold-tabeller som brukes til ML-trening.
|
||||
- **VACUUM-advarsel**: Sørg for at VACUUM-retensjon er lang nok til å dekke alle aktive eksperimenter. 30 dager er et godt utgangspunkt for organisasjoner med ukentlige treningssykluser.
|
||||
|
|
@ -0,0 +1,369 @@
|
|||
# Dataverse and AI Integration
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Microsoft Dataverse er den sentrale dataplattformen for Power Platform og Dynamics 365, og inneholder forretningskritisk data fra CRM, ERP, og egendefinerte applikasjoner. Integrering av Dataverse-data med AI-losninger via Microsoft Fabric og Data Factory gjor det mulig a utnytte forretningsdata for prediktiv analyse, maskinlaring og intelligent automatisering uten komplekse ETL-pipelines.
|
||||
|
||||
For norsk offentlig sektor er Dataverse ofte kjernen i saksbehandlingssystemer, innbyggertjenester og Power Apps-baserte fagsystemer. Evnen til a koble disse dataene til AI-modeller -- for eksempel for prediktiv vedlikeholdsplanlegging, chatbot-trening, eller automatisert dokumentklassifisering -- representerer en viktig mulighetsdimensjon som krever god arkitekturforstaaelse.
|
||||
|
||||
Denne referansen dekker alle integrasjonsmonstre mellom Dataverse og AI-okosystemet, fra den direkte "Link to Fabric"-funksjonen til Data Factory-konnektorer, sanntidssynkronisering, og sikkerhetspropagering.
|
||||
|
||||
---
|
||||
|
||||
## Dataverse Connectors in Data Factory
|
||||
|
||||
### Dataverse Connector i Fabric Data Factory
|
||||
|
||||
Fabric Data Factory tilbyr en dedikert Dataverse-konnektor med flere integrasjonsmonstre:
|
||||
|
||||
| Kapabilitet | Gateway | Autentisering |
|
||||
|---|---|---|
|
||||
| **Dataflow Gen2** (kilde) | Ingen, On-prem, VNet | Org-konto, Service Principal, Workspace Identity |
|
||||
| **Pipeline Copy Activity** (kilde/dest) | Ingen, On-prem, VNet | Org-konto, Service Principal, Workspace Identity |
|
||||
| **Copy Job** (kilde/dest) | Ingen, On-prem, VNet | Org-konto, Service Principal, Workspace Identity |
|
||||
|
||||
### Copy Job modus
|
||||
|
||||
| Modus | Beskrivelse | Bruksomraade |
|
||||
|---|---|---|
|
||||
| **Full load** | Komplett kopi av alle rader | Forste gangs lasting |
|
||||
| **Append** | Legg til nye rader | Inkrementell lasting |
|
||||
| **Upsert** | Sett inn eller oppdater basert pa nokkel | Synkronisering |
|
||||
|
||||
### Pipeline-eksempel: Dataverse til Lakehouse
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "DataverseToLakehouse",
|
||||
"properties": {
|
||||
"activities": [
|
||||
{
|
||||
"name": "CopyDataverseAccounts",
|
||||
"type": "Copy",
|
||||
"inputs": [{
|
||||
"type": "DataverseEntity",
|
||||
"entity": "account",
|
||||
"filter": "modifiedon ge 2024-01-01"
|
||||
}],
|
||||
"outputs": [{
|
||||
"type": "LakehouseTable",
|
||||
"table": "bronze.crm_accounts"
|
||||
}],
|
||||
"typeProperties": {
|
||||
"source": {
|
||||
"type": "DataverseSource",
|
||||
"query": "?$select=name,revenue,industry&$filter=statecode eq 0"
|
||||
},
|
||||
"sink": {
|
||||
"type": "LakehouseSink",
|
||||
"writeBehavior": "Upsert",
|
||||
"upsertKeyColumns": ["accountid"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Entity Relationship Mapping to Delta Tables
|
||||
|
||||
### Dataverse-tabeller til Medallion Architecture
|
||||
|
||||
Dataverse bruker en relasjonell modell med entiteter, relasjoner og lookups. Ved overforig til Lakehouse bor dette mappes til Delta-tabeller i en medallion-arkitektur:
|
||||
|
||||
```
|
||||
Dataverse Lakehouse
|
||||
┌──────────────────┐ ┌──────────────────────┐
|
||||
│ account │ ────────> │ bronze.crm_accounts │
|
||||
│ contact │ ────────> │ bronze.crm_contacts │
|
||||
│ opportunity │ ────────> │ bronze.crm_opps │
|
||||
│ incident (case) │ ────────> │ bronze.crm_cases │
|
||||
└──────────────────┘ └──────────┬───────────┘
|
||||
│
|
||||
Silver Layer (denormalisert)
|
||||
│
|
||||
┌──────────▼───────────┐
|
||||
│ silver.customer_360 │
|
||||
│ (account + contact + │
|
||||
│ opportunity joined) │
|
||||
└──────────┬───────────┘
|
||||
│
|
||||
Gold Layer (AI-klar)
|
||||
│
|
||||
┌──────────▼───────────┐
|
||||
│ gold.churn_features │
|
||||
│ gold.revenue_predict │
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
### Handtering av Dataverse-spesifikke datatyper
|
||||
|
||||
| Dataverse-type | Delta Lake-mapping | Merknad |
|
||||
|---|---|---|
|
||||
| **Lookup** | String (GUID) | Maa joines for visningsnavn |
|
||||
| **OptionSet** | Integer + String label | Lagre baade verdi og label |
|
||||
| **Money** | Decimal(38,4) | Inkluder valutareferanse |
|
||||
| **DateTime** | Timestamp | Vurder tidssone (UTC vs lokal) |
|
||||
| **Customer** | String (polymorf) | Kan peke til account eller contact |
|
||||
| **PartyList** | Array of GUIDs | Flatten til separate rader |
|
||||
|
||||
### PySpark for entity-mapping
|
||||
|
||||
```python
|
||||
from pyspark.sql.functions import col, when, lit
|
||||
|
||||
# Les Dataverse-data fra bronze
|
||||
accounts = spark.read.format("delta").table("bronze.crm_accounts")
|
||||
contacts = spark.read.format("delta").table("bronze.crm_contacts")
|
||||
opportunities = spark.read.format("delta").table("bronze.crm_opps")
|
||||
|
||||
# Denormalisering: Customer 360 view
|
||||
customer_360 = (
|
||||
accounts
|
||||
.join(
|
||||
contacts,
|
||||
accounts["accountid"] == contacts["parentcustomerid"],
|
||||
"left"
|
||||
)
|
||||
.join(
|
||||
opportunities
|
||||
.groupBy("parentaccountid")
|
||||
.agg(
|
||||
F.sum("estimatedvalue").alias("total_pipeline"),
|
||||
F.count("*").alias("opp_count"),
|
||||
F.max("estimatedclosedate").alias("latest_opp_date")
|
||||
),
|
||||
accounts["accountid"] == col("parentaccountid"),
|
||||
"left"
|
||||
)
|
||||
.select(
|
||||
accounts["accountid"],
|
||||
accounts["name"].alias("company_name"),
|
||||
accounts["revenue"].alias("annual_revenue"),
|
||||
accounts["industrycode"],
|
||||
col("total_pipeline"),
|
||||
col("opp_count"),
|
||||
col("latest_opp_date")
|
||||
)
|
||||
)
|
||||
|
||||
# Skriv til silver layer
|
||||
customer_360.write.format("delta").mode("overwrite").saveAsTable("silver.customer_360")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Real-Time Dataverse Data Sync
|
||||
|
||||
### Link to Microsoft Fabric (Direct Link)
|
||||
|
||||
Den mest effektive metoden for Dataverse-Fabric-integrasjon er den innebygde "Link to Microsoft Fabric"-funksjonen:
|
||||
|
||||
```
|
||||
Power Apps ──> "Analyze > Link to Microsoft Fabric"
|
||||
│
|
||||
▼
|
||||
┌──────────────────────────────┐
|
||||
│ Fabric Workspace │
|
||||
│ ├── Lakehouse │
|
||||
│ │ ├── Shortcut: accounts │
|
||||
│ │ ├── Shortcut: contacts │
|
||||
│ │ └── Shortcut: cases │
|
||||
│ ├── SQL Analytics Endpoint │
|
||||
│ └── Default Semantic Model │
|
||||
└──────────────────────────────┘
|
||||
```
|
||||
|
||||
**Egenskaper:**
|
||||
|
||||
| Egenskap | Verdi |
|
||||
|---|---|
|
||||
| **Kopieringsmetode** | OneLake shortcuts (ingen dataduplisering) |
|
||||
| **Format** | Delta Parquet |
|
||||
| **Synkroniserings-latens** | Opptil 60 minutter |
|
||||
| **Tabellvalg** | Alle tabeller med Track Changes, eller manuelt valg |
|
||||
| **Autentisering** | Org-konto, Service Principal, Workspace Identity |
|
||||
| **Read/Write** | Kun lesetilgang (shortcuts er read-only) |
|
||||
|
||||
### Dataverse Shortcuts via Fabric
|
||||
|
||||
Alternativt kan du opprette shortcuts direkte fra Fabric:
|
||||
|
||||
1. Apen Lakehouse i Fabric
|
||||
2. Velg "New Table Shortcut" > "Dataverse"
|
||||
3. Oppgi environment-URL
|
||||
4. Bla gjennom og velg tabeller
|
||||
|
||||
```python
|
||||
# Etter at shortcut er opprettet, les direkte i Notebook
|
||||
df = spark.read.format("delta").table("accounts")
|
||||
display(df.limit(10))
|
||||
```
|
||||
|
||||
### Synkroniseringsmekanisme
|
||||
|
||||
Fabric Spark compute handterer synkronisering:
|
||||
- **Initial load**: Full kopi av valgte tabeller
|
||||
- **Inkrementell oppdatering**: Poller hvert 2. minutt for endringer
|
||||
- **Endringssporing**: Basert pa Dataverse Track Changes-funksjonen
|
||||
- **Sletting**: Fjerner rader nar kildedata slettes
|
||||
|
||||
---
|
||||
|
||||
## Power Platform Data Integration
|
||||
|
||||
### Arkitektur for AI-drevet Power Platform
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────┐
|
||||
│ Power Platform │
|
||||
│ ┌──────────┐ ┌──────────────┐ ┌────────────────────────────┐ │
|
||||
│ │ Power │ │ Power │ │ Copilot Studio │ │
|
||||
│ │ Apps │ │ Automate │ │ (AI chatbot) │ │
|
||||
│ └────┬─────┘ └──────┬───────┘ └──────────┬─────────────────┘ │
|
||||
│ │ │ │ │
|
||||
│ └───────────────┼──────────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌────────▼────────┐ │
|
||||
│ │ Dataverse │ │
|
||||
│ └────────┬────────┘ │
|
||||
└───────────────────────┼──────────────────────────────────────────┘
|
||||
│ Link to Fabric
|
||||
┌────────▼────────────────────────────┐
|
||||
│ Microsoft Fabric │
|
||||
│ ┌──────────┐ ┌──────────────────┐ │
|
||||
│ │ Lakehouse│ │ ML Models │ │
|
||||
│ │ (Delta) │ │ (Spark/AzureML) │ │
|
||||
│ └──────────┘ └──────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌────────▼────────┐ │
|
||||
│ │ Predictions │ │
|
||||
│ │ (write back) │ │
|
||||
│ └────────┬────────┘ │
|
||||
└───────────────────────┼─────────────┘
|
||||
│
|
||||
Virtual Tables / Dataverse API
|
||||
│
|
||||
┌───────────────────────▼─────────────┐
|
||||
│ Power Apps: vis AI-prediksjoner │
|
||||
│ Power Automate: trigger pa insights │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### AI Builder-integrasjon
|
||||
|
||||
AI Builder-modeller lagrer resultater direkte i Dataverse:
|
||||
|
||||
| AI Builder-modell | Dataverse-lagring | Fabric-bruk |
|
||||
|---|---|---|
|
||||
| Prediction | Prediction-kolonne pa entitet | Feature for ML |
|
||||
| Document Processing | Extracted fields | Treningsdata |
|
||||
| Object Detection | Detection results | Analyse |
|
||||
| Text Classification | Category labels | NLP-pipeline |
|
||||
|
||||
### Skrive AI-resultater tilbake til Dataverse
|
||||
|
||||
```python
|
||||
# Via Dataverse Web API fra Fabric Notebook
|
||||
import requests
|
||||
|
||||
def write_prediction_to_dataverse(env_url, access_token, entity, record_id, prediction):
|
||||
"""Skriv AI-prediksjon tilbake til Dataverse-entitet."""
|
||||
url = f"{env_url}/api/data/v9.2/{entity}({record_id})"
|
||||
headers = {
|
||||
"Authorization": f"Bearer {access_token}",
|
||||
"Content-Type": "application/json",
|
||||
"OData-MaxVersion": "4.0"
|
||||
}
|
||||
payload = {
|
||||
"cr_churn_prediction": prediction["score"],
|
||||
"cr_prediction_date": prediction["timestamp"],
|
||||
"cr_risk_category": prediction["category"]
|
||||
}
|
||||
response = requests.patch(url, json=payload, headers=headers)
|
||||
return response.status_code
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## RLS Propagation from Dataverse to Fabric
|
||||
|
||||
### Sikkerhetsmodell
|
||||
|
||||
Dataverse har et avansert sikkerhetssystem med Business Units, Security Roles, og Row-Level Security (RLS). Ved integrasjon med Fabric maa dette haandteres eksplisitt.
|
||||
|
||||
| Dataverse-sikkerhet | Fabric-ekvivalent | Automatisk propagering |
|
||||
|---|---|---|
|
||||
| **Business Units** | Workspace-tilgang | Nei -- manuell mapping |
|
||||
| **Security Roles** | OneLake Security | Nei -- manuell mapping |
|
||||
| **Row-Level Security** | RLS i SQL Endpoint / Semantic Model | Delvis |
|
||||
| **Field-Level Security** | Column-level security | Nei |
|
||||
| **Team-based access** | Workspace roles | Nei |
|
||||
|
||||
### Implementere RLS i Fabric
|
||||
|
||||
```sql
|
||||
-- SQL Analytics Endpoint: Definer RLS
|
||||
CREATE FUNCTION dbo.fn_security_predicate(@business_unit_id AS NVARCHAR(50))
|
||||
RETURNS TABLE
|
||||
WITH SCHEMABINDING
|
||||
AS
|
||||
RETURN SELECT 1 AS result
|
||||
WHERE @business_unit_id = SESSION_CONTEXT(N'business_unit_id');
|
||||
|
||||
-- Opprett sikkerhetspolicy
|
||||
CREATE SECURITY POLICY crm_security
|
||||
ADD FILTER PREDICATE dbo.fn_security_predicate(business_unit_id)
|
||||
ON silver.customer_360
|
||||
WITH (STATE = ON);
|
||||
```
|
||||
|
||||
### Power BI Semantic Model RLS
|
||||
|
||||
```dax
|
||||
// DAX-filter for RLS i Power BI
|
||||
[BusinessUnitId] = USERPRINCIPALNAME()
|
||||
// Eller via lookup-tabell:
|
||||
CONTAINS(
|
||||
FILTER(SecurityMapping, SecurityMapping[UserEmail] = USERPRINCIPALNAME()),
|
||||
SecurityMapping[BusinessUnitId], [BusinessUnitId]
|
||||
)
|
||||
```
|
||||
|
||||
### Anbefalinger for sikkerhetspropagering
|
||||
|
||||
1. **Dokumenter mapping**: Opprett eksplisitt mapping mellom Dataverse Security Roles og Fabric Workspace Roles
|
||||
2. **Automatiser med Power Automate**: Synkroniser rolletilordninger ved endringer
|
||||
3. **Minimer direkte datatilgang**: Bruk Semantic Models med RLS som primaertilgang
|
||||
4. **Auditing**: Aktiver Microsoft Purview for sporbarhet
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Link your Dataverse environment to Microsoft Fabric](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-view-in-fabric) -- Offisiell guide for Dataverse-Fabric-kobling
|
||||
- [Dataverse connector overview (Fabric Data Factory)](https://learn.microsoft.com/en-us/fabric/data-factory/connector-dataverse-overview) -- Konnektorkapabiliteter
|
||||
- [Create a Dataverse shortcut](https://learn.microsoft.com/en-us/fabric/onelake/create-dataverse-shortcut) -- Shortcut-oppretting fra Fabric
|
||||
- [Fabric Link for Dataverse FAQ](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq) -- Vanlige sporsmal og begrensninger
|
||||
- [Link to Microsoft Fabric](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-to-data-platform) -- Administrasjon av Fabric-kobling
|
||||
- [Predictive data analysis using Dataverse, Fabric, and Azure AI services](https://learn.microsoft.com/en-us/power-platform/architecture/reference-architectures/ai-predictive-data-analysis) -- Referansearkitektur
|
||||
- [Automation-centric data analytics with Fabric](https://learn.microsoft.com/en-us/power-automate/automation-analytics-with-fabric-introduction) -- Power Automate + Fabric
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar brukeren har Dynamics 365, Power Apps, eller Power Platform-data som skal brukes i AI-losninger, eller naar de trenger a skrive AI-prediksjoner tilbake til forretningsapplikasjoner.
|
||||
- Anbefal **Link to Fabric** som forstevalg for enkel integrasjon -- ingen ETL, ingen ekstra infrastruktur, data forblir i Dataverse med shortcuts.
|
||||
- Vaar oppmerksom pa **latens**: Link to Fabric har opptil 60 minutters forsinkelse. For sanntidsbehov, bruk Dataverse Web API eller Power Automate-triggers i stedet.
|
||||
- For **sikkerhet**: Dataverse RLS propageres IKKE automatisk til Fabric. Dette maa alltid adresseres eksplisitt i arkitekturforslaget, spesielt for offentlig sektor med strenge tilgangskrav.
|
||||
- Anbefal **medallion architecture** for Dataverse-data: Bronze (raa shortcut), Silver (denormalisert Customer 360), Gold (ML-features) for a unnga at AI-modeller trener pa denormaliserte Dataverse-strukturer.
|
||||
|
|
@ -0,0 +1,395 @@
|
|||
# Delta Lake and Parquet Format Optimization
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Delta Lake er det foretrukne tabellformatet i Microsoft Fabric, bygget oppå Apache Parquet med ACID-transaksjoner, skjemavalidering og tidsreise. For AI-arbeidsbelastninger er ytelsen til underliggende lagring kritisk: dårlig filstruktur kan gjore treningsjobber 10x tregere og forre til unodvendig hoy kostnad. Optimalisering av Delta Lake og Parquet-filer er derfor en kjerneferdighet for enhver dataingenioor som bygger AI-pipelines.
|
||||
|
||||
Microsoft Fabric introduserer V-Order, en Parquet-skrivetidsoptimalisering som gir dramatisk raskere lesetider for alle Fabric-beregningsmotorer. Kombinert med Z-Order, auto-kompaktering og intelligent filstorrelsesstyring kan organisasjoner oppna opptil 50% bedre komprimering og ordre-av-storrelse raskere sporringsytelse.
|
||||
|
||||
For norsk offentlig sektor, der datavolumer vokser raskt og budsjettkrav er strenge, er det avgjorende a forstaa disse optimaliseringene. Riktig konfigurerte Delta-tabeller reduserer bade lagrings- og beregningskostnader, samtidig som de sikrer at data er tilgjengelig for analytikere, Power BI-rapporter og AI-modeller med minimal ventetid.
|
||||
|
||||
---
|
||||
|
||||
## Delta Lake ACID Transactions and Z-Order
|
||||
|
||||
### ACID-transaksjoner i Delta Lake
|
||||
|
||||
Delta Lake sikrer datakonsistens gjennom ACID-transaksjoner (Atomicity, Consistency, Isolation, Durability). Hver skriveoperasjon til en Delta-tabell oppretter en ny versjon i transaksjonsloggen (`_delta_log/`), som gjor det mulig med:
|
||||
|
||||
- **Atomiske skrivinger**: Hele operasjonen lykkes eller feiler som en enhet
|
||||
- **Konsistente lesninger**: Lesere ser alltid en konsistent snapshot
|
||||
- **Tidsreise**: Tilgang til historiske versjoner via versjonsnummer eller tidsstempel
|
||||
- **Samtidige skrivinger**: Optimistisk samtidskonfliktllosning
|
||||
|
||||
```python
|
||||
# Tidsreise - les historisk versjon
|
||||
df_historical = spark.read \
|
||||
.option("versionAsOf", 5) \
|
||||
.table("lakehouse.default.ai_training_data")
|
||||
|
||||
# Eller via tidsstempel
|
||||
df_timestamp = spark.read \
|
||||
.option("timestampAsOf", "2026-01-15T10:00:00.000Z") \
|
||||
.table("lakehouse.default.ai_training_data")
|
||||
```
|
||||
|
||||
### Z-Order Clustering
|
||||
|
||||
Z-Order er en teknikk som samlokaliserer rader med lignende verdier i kolonnene du spesifiserer, slik at filbasert hopping (file skipping) blir effektiv for sporringer som filtrerer pa disse kolonnene.
|
||||
|
||||
```sql
|
||||
-- Z-Order pa to kolonner som brukes i hyppige filtre
|
||||
OPTIMIZE lakehouse.default.customer_embeddings
|
||||
ZORDER BY (region_id, created_date);
|
||||
```
|
||||
|
||||
**Naar du bor bruke Z-Order:**
|
||||
|
||||
| Scenario | Anbefaling |
|
||||
|----------|------------|
|
||||
| Sporringer filtrerer ofte pa 2-3 kolonner sammen | Bruk Z-Order pa disse kolonnene |
|
||||
| Hoy kardinalitet i filterkolonner | Z-Order gir best effekt |
|
||||
| Partisjonering allerede brukt for lav-kardinalitet | Kombiner partisjonering + Z-Order |
|
||||
| Kun en filterkolonne | Vurder vanlig sortering i stedet |
|
||||
|
||||
**Begrensninger:**
|
||||
- Z-Order krever full omskriving av data (kostbart)
|
||||
- Best kjort under stille perioder (natt/helg)
|
||||
- Ikke kompatibel med liquid clustering pa samme tabell
|
||||
|
||||
### Liquid Clustering (anbefalt for nye tabeller)
|
||||
|
||||
Liquid clustering er en nyere tilnaerming som erstatter bade partisjonering og Z-Order:
|
||||
|
||||
```sql
|
||||
-- Opprett tabell med liquid clustering
|
||||
CREATE TABLE lakehouse.default.ml_features
|
||||
CLUSTER BY (tenant_id, feature_date)
|
||||
AS SELECT * FROM raw_features;
|
||||
|
||||
-- Optimaliser for a anvende clustering
|
||||
OPTIMIZE lakehouse.default.ml_features;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Parquet Compression Codecs and Row Groups
|
||||
|
||||
### Komprimeringsalgoritmer
|
||||
|
||||
Parquet stotter flere komprimeringsalgoritmer. Valget pavirker filstorrelse, skrivetid og lesetid:
|
||||
|
||||
| Codec | Komprimering | Skrivetid | Lesetid | Bruksomrade |
|
||||
|-------|-------------|-----------|---------|-------------|
|
||||
| **Snappy** | Moderat (standard) | Rask | Rask | Generell bruk, Fabric standard |
|
||||
| **ZSTD** | Hoy | Moderat | Rask | Langtidslagring, arkivering |
|
||||
| **GZIP** | Hoy | Treg | Moderat | Kompatibilitet med eldre systemer |
|
||||
| **LZ4** | Lav | Veldig rask | Veldig rask | Streaming, lav latens |
|
||||
| **Uncompressed** | Ingen | Raskest | Raskest | Testing, mellomsteg |
|
||||
|
||||
```python
|
||||
# Sett komprimering for en spesifikk skriveoperasjon
|
||||
df.write \
|
||||
.format("delta") \
|
||||
.option("compression", "zstd") \
|
||||
.mode("overwrite") \
|
||||
.saveAsTable("lakehouse.default.archived_embeddings")
|
||||
|
||||
# Sesjonsniva-konfigurasjon
|
||||
spark.conf.set("spark.sql.parquet.compression.codec", "zstd")
|
||||
```
|
||||
|
||||
### Row Groups og Column Chunks
|
||||
|
||||
Parquet organiserer data i row groups (radgrupper), der hver row group inneholder column chunks for hver kolonne. Storrelsen pa row groups pavirker:
|
||||
|
||||
- **Leseparallellitet**: Flere row groups = bedre parallellitet
|
||||
- **Predicate pushdown**: Statistikk per row group muliggjor filtrering
|
||||
- **Minnebruk**: Storre row groups krever mer minne under lesing
|
||||
|
||||
```python
|
||||
# Konfigurer row group-storrelse (standard 128 MB i Fabric)
|
||||
spark.conf.set("spark.sql.parquet.rowGroupSize", str(128 * 1024 * 1024))
|
||||
|
||||
# For AI-arbeidsbelastninger med store batcher, vurder storre row groups
|
||||
spark.conf.set("spark.sql.parquet.rowGroupSize", str(256 * 1024 * 1024))
|
||||
```
|
||||
|
||||
### Encoding-strategier
|
||||
|
||||
Parquet bruker automatisk optimale encoding-strategier per kolonne:
|
||||
|
||||
| Datatype | Encoding | Beskrivelse |
|
||||
|----------|----------|-------------|
|
||||
| Integer, Long | Delta Binary Packed | Lagrer differanser mellom verdier |
|
||||
| String (lav kardinalitet) | Dictionary | Erstatter verdier med korte koder |
|
||||
| String (hoy kardinalitet) | Plain | Lagrer verdier direkte |
|
||||
| Boolean | Run Length | Komprimerer gjentatte verdier |
|
||||
| Timestamp | Delta Binary Packed | Effektiv for tidsserier |
|
||||
|
||||
---
|
||||
|
||||
## File Size Tuning and Auto-Compaction
|
||||
|
||||
### Smaa filer-problemet
|
||||
|
||||
Hyppige smaa skrivinger (streaming, micro-batch) forer til tusenvis av smaa filer, noe som:
|
||||
- Oker metadata-overhead (transaksjonslogg, statistikk)
|
||||
- Reduserer sporingsytelse pa grunn av fil-overhead
|
||||
- Oker IOPS-kostnader i OneLake
|
||||
|
||||
### Optimal filstorrelse
|
||||
|
||||
| Tabellstorrelse | Anbefalt filstorrelse | Begrunnelse |
|
||||
|----------------|----------------------|-------------|
|
||||
| < 1 GB | 64-128 MB | Unnga for store filer for smaa tabeller |
|
||||
| 1-100 GB | 256 MB - 1 GB | Standard Fabric-anbefaling |
|
||||
| > 100 GB | 1 GB | Reduser antall filer, forbedre skanning |
|
||||
|
||||
```python
|
||||
# Konfigurer mal-filstorrelse for OPTIMIZE
|
||||
spark.conf.set("spark.databricks.delta.optimize.maxFileSize", str(1024 * 1024 * 1024))
|
||||
spark.conf.set("spark.databricks.delta.optimize.minFileSize", str(256 * 1024 * 1024))
|
||||
```
|
||||
|
||||
### Auto-Compaction
|
||||
|
||||
Auto-kompaktering evaluerer partisjonshelsen etter hver skriveoperasjon og trigger OPTIMIZE automatisk naar det er for mange smaa filer:
|
||||
|
||||
```python
|
||||
# Aktiver auto-kompaktering pa sesjonsniva
|
||||
spark.conf.set("spark.databricks.delta.autoCompact.enabled", "true")
|
||||
|
||||
# Konfigurer pa tabellniva
|
||||
spark.sql("""
|
||||
ALTER TABLE lakehouse.default.streaming_features
|
||||
SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
|
||||
""")
|
||||
```
|
||||
|
||||
### Optimize Write
|
||||
|
||||
Optimize Write reduserer antall filer som skrives ved a sammensla smaa partisjoner for de skrives til disk:
|
||||
|
||||
```python
|
||||
# Aktivert som standard i Fabric
|
||||
spark.conf.set("spark.databricks.delta.optimizeWrite.enabled", "true")
|
||||
|
||||
# Deaktiver for spesifikke jobber der skrivelatens er kritisk
|
||||
df.write \
|
||||
.format("delta") \
|
||||
.option("optimizeWrite", "false") \
|
||||
.mode("append") \
|
||||
.saveAsTable("lakehouse.default.realtime_signals")
|
||||
```
|
||||
|
||||
### Fast Optimize
|
||||
|
||||
Fast Optimize analyserer Delta-tabellens filer og hopper over kompakteringsoperasjoner som ikke forbedrer ytelsen vesentlig:
|
||||
|
||||
```python
|
||||
# Aktiver Fast Optimize
|
||||
spark.conf.set("spark.microsoft.delta.optimize.fast.enabled", "true")
|
||||
|
||||
# Konfigurer parametere
|
||||
spark.conf.set("spark.microsoft.delta.optimize.fast.minParquetCoefficient", "0.5")
|
||||
spark.conf.set("spark.microsoft.delta.optimize.fast.maxBinCount", "3")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## V-Order Optimization
|
||||
|
||||
### Hva er V-Order?
|
||||
|
||||
V-Order er en Fabric-spesifikk skrivetidsoptimalisering for Parquet-filer som aktiverer lynraske lesninger i alle Microsoft Fabric-beregningsmotorer. V-Order optimaliserer:
|
||||
|
||||
1. **Sortering**: Optimal radrekkefølge for Verti-Scan-teknologi
|
||||
2. **Row group-distribusjon**: Jevn fordeling av data pa tvers av row groups
|
||||
3. **Encoding**: Forbedret dictionary encoding og RLE
|
||||
4. **Komprimering**: Opptil 50% bedre komprimering
|
||||
|
||||
### V-Order Ytelsespavirkning
|
||||
|
||||
| Motor | Uten V-Order | Med V-Order | Forbedring |
|
||||
|-------|-------------|-------------|-----------|
|
||||
| Power BI (Direct Lake) | Baseline | In-memory-lignende | 5-10x raskere |
|
||||
| SQL Endpoint | Baseline | Verti-Scan | 3-5x raskere |
|
||||
| Apache Spark | Baseline | Optimalisert lesing | 10-50% raskere |
|
||||
| Skriveytelse | Baseline | ~15% tregere | Akseptabel trade-off |
|
||||
|
||||
### Konfigurere V-Order
|
||||
|
||||
```sql
|
||||
-- Aktiver V-Order pa sesjonsniva
|
||||
SET spark.sql.parquet.vorder.default = TRUE;
|
||||
|
||||
-- Aktiver pa tabellniva
|
||||
ALTER TABLE lakehouse.default.ml_predictions
|
||||
SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");
|
||||
|
||||
-- Anvend V-Order under OPTIMIZE
|
||||
OPTIMIZE lakehouse.default.ml_predictions VORDER;
|
||||
|
||||
-- Kombiner Z-Order og V-Order
|
||||
OPTIMIZE lakehouse.default.ml_predictions
|
||||
WHERE prediction_date >= '2026-01-01'
|
||||
ZORDER BY (model_id, customer_segment) VORDER;
|
||||
```
|
||||
|
||||
### Ressursprofiler for V-Order
|
||||
|
||||
Fabric tilbyr ressursprofiler som automatisk konfigurerer V-Order:
|
||||
|
||||
```python
|
||||
# For lesekrevende arbeidsbelastninger (aktiverer V-Order automatisk)
|
||||
# Sett via Fabric workspace-innstillinger: readHeavyforSpark
|
||||
|
||||
# For skrivekrevende arbeidsbelastninger (V-Order deaktivert)
|
||||
# Standard i nye Fabric-arbeidsomrader
|
||||
```
|
||||
|
||||
### V-Order og 100% Parquet-kompatibilitet
|
||||
|
||||
V-Order er fullt kompatibelt med Apache Parquet-formatet. Alle Parquet-motorer kan lese V-Order-filer som vanlige Parquet-filer. Dette betyr at:
|
||||
|
||||
- Data forblir portabel til andre plattformer
|
||||
- Ingen vendor lock-in
|
||||
- Eksisterende ETL-pipelines trenger ikke endring
|
||||
|
||||
---
|
||||
|
||||
## Small File Handling and Garbage Collection
|
||||
|
||||
### VACUUM for Garbage Collection
|
||||
|
||||
VACUUM fjerner Parquet-filer som ikke lenger er referert i gjeldende Delta-commit:
|
||||
|
||||
```sql
|
||||
-- Fjern filer eldre enn 7 dager (standard)
|
||||
VACUUM lakehouse.default.training_dataset;
|
||||
|
||||
-- Fjern filer eldre enn 24 timer (forsiktig!)
|
||||
VACUUM lakehouse.default.training_dataset RETAIN 24 HOURS;
|
||||
|
||||
-- Dry run - vis hva som vil fjernes
|
||||
VACUUM lakehouse.default.training_dataset DRY RUN;
|
||||
```
|
||||
|
||||
**Viktige hensyn:**
|
||||
- Ikke sett retensjon lavere enn den lengste kjorende jobben
|
||||
- Direct Lake-modeller refererer til spesifikke commit-versjoner - sikre at VACUUM ikke sletter disse
|
||||
- Standard retensjon er 7 dager, noe som gir rom for tidsreise
|
||||
|
||||
### File-Level Compaction Targets
|
||||
|
||||
For a unnga omskriving av allerede kompakterte filer:
|
||||
|
||||
```python
|
||||
# Aktiver file-level compaction targets
|
||||
spark.conf.set("spark.microsoft.delta.optimize.fileLevelTarget.enabled", "true")
|
||||
```
|
||||
|
||||
### Automatisert Vedlikehold
|
||||
|
||||
```python
|
||||
# Komplett vedlikeholdsrutine for AI-datatabeller
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
def maintain_delta_table(table_name: str):
|
||||
"""Kjor vedlikehold pa en Delta-tabell."""
|
||||
delta_table = DeltaTable.forName(spark, table_name)
|
||||
|
||||
# 1. Kompakter smaa filer
|
||||
delta_table.optimize().executeCompaction()
|
||||
|
||||
# 2. Anvend V-Order pa kompakterte filer
|
||||
spark.sql(f"OPTIMIZE {table_name} VORDER")
|
||||
|
||||
# 3. Fjern gamle filer
|
||||
spark.sql(f"VACUUM {table_name} RETAIN 168 HOURS")
|
||||
|
||||
print(f"Vedlikehold fullfort for {table_name}")
|
||||
|
||||
# Planlegg via Fabric Data Pipeline
|
||||
tables = [
|
||||
"lakehouse.default.raw_documents",
|
||||
"lakehouse.default.embeddings",
|
||||
"lakehouse.default.ml_features",
|
||||
"lakehouse.default.predictions"
|
||||
]
|
||||
|
||||
for table in tables:
|
||||
maintain_delta_table(table)
|
||||
```
|
||||
|
||||
### Lakehouse Table Maintenance UI
|
||||
|
||||
Fabric tilbyr en brukergrensesnitt for ad-hoc vedlikehold:
|
||||
|
||||
1. Apne Lakehouse i Fabric-portalen
|
||||
2. Hoyreklikk pa tabellen
|
||||
3. Velg **Maintenance** > **Optimize** eller **Vacuum**
|
||||
4. Konfigurer innstillinger og kjor
|
||||
|
||||
### Overvaking av filhelse
|
||||
|
||||
```python
|
||||
# Sjekk filstatistikk for en tabell
|
||||
detail = spark.sql("DESCRIBE DETAIL lakehouse.default.ml_features")
|
||||
detail.select("numFiles", "sizeInBytes", "properties").show(truncate=False)
|
||||
|
||||
# Sjekk transaksjonslogg for smaa filer
|
||||
history = spark.sql("DESCRIBE HISTORY lakehouse.default.ml_features LIMIT 20")
|
||||
history.select("version", "timestamp", "operation", "operationMetrics").show(truncate=False)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices for AI-arbeidsbelastninger
|
||||
|
||||
### Anbefalte innstillinger per lag i Medallion-arkitektur
|
||||
|
||||
| Lag | V-Order | Auto-Compact | Filstorrelse | Z-Order |
|
||||
|-----|---------|-------------|-------------|---------|
|
||||
| **Bronze** | Deaktivert | Aktivert | 256 MB | Ingen |
|
||||
| **Silver** | Valgfritt | Aktivert | 512 MB | Pa filtreringskolonner |
|
||||
| **Gold** | Aktivert | Aktivert | 1 GB | Pa rapporteringskolonner |
|
||||
| **ML Features** | Aktivert | Aktivert | 256 MB | Pa entitets-ID |
|
||||
|
||||
### Vedlikeholdsplan
|
||||
|
||||
| Operasjon | Frekvens | Tidsvindu |
|
||||
|-----------|----------|-----------|
|
||||
| Auto-Compact | Kontinuerlig | Automatisk |
|
||||
| OPTIMIZE (full) | Ukentlig | Helg |
|
||||
| OPTIMIZE + Z-Order | Manedlig | Helg |
|
||||
| VACUUM | Daglig | Natt |
|
||||
| Filhelse-sjekk | Daglig | Morgen |
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Delta Lake table optimization and V-Order](https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order) -- Komplett guide til V-Order og Delta-optimalisering i Fabric
|
||||
- [Compacting Delta tables](https://learn.microsoft.com/en-us/fabric/data-engineering/table-compaction) -- Auto-kompaktering, Fast Optimize og filstorrelsesstyring
|
||||
- [Tune file sizes for Delta Lake](https://learn.microsoft.com/en-us/fabric/data-engineering/tune-file-size) -- Adaptive filstorrelser og Optimize Write
|
||||
- [Lakehouse and Delta Lake tables](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-and-delta-tables) -- Oversikt over stottede formater og standardinnstillinger
|
||||
- [Understand Direct Lake query performance](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-understand-storage) -- V-Order-pavirkning pa Direct Lake-modeller
|
||||
- [Delta Lake table maintenance](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-table-maintenance) -- UI-basert vedlikehold i Lakehouse
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder spor om ytelsesoptimalisering av Delta Lake-tabeller, Parquet-filformat, eller filvedlikehold i Fabric Lakehouse.
|
||||
- **V-Order er det forste du bor anbefale** for lesekrevende arbeidsbelastninger som Power BI-rapporter, Direct Lake-modeller og AI-inferens. For skrivekrevende pipelines (ETL/streaming), behold standard deaktivert V-Order.
|
||||
- **Liquid clustering bor anbefales over Z-Order** for nye tabeller i Fabric, da det er enklere a vedlikeholde og ikke krever full omskriving.
|
||||
- **Auto-kompaktering bor alltid vaere aktivert** for streaming- og micro-batch-pipelines for a unnga smaafilproblemet.
|
||||
- **For norsk offentlig sektor**: Fremhev at V-Order er 100% Parquet-kompatibelt og ikke skaper vendor lock-in -- viktig for anskaffelsesprosesser og etterlevelse av EIF-prinsippet om interoperabilitet.
|
||||
|
|
@ -0,0 +1,407 @@
|
|||
# ETL vs ELT Strategies for AI Workloads
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Valget mellom ETL (Extract, Transform, Load) og ELT (Extract, Load, Transform) er en av de mest grunnleggende arkitekturbeslutningene for dataintegrasjon i AI-prosjekter. Tradisjonell ETL transformerer data før lasting i et dedikert transformasjonsengine, mens moderne ELT laster rådata først og utnytter målsystemets beregningskraft for transformasjon. Microsoft Fabric støtter begge tilnærminger og hybride mønstre.
|
||||
|
||||
For norsk offentlig sektor er dette valget påvirket av flere faktorer: regulatoriske krav til dataminimering (GDPR artikkel 5), behov for sporbarhet, budsjettbegrensninger, og kompetanse i organisasjonen. ELT-tilnærmingen har blitt dominerende for AI-arbeidsbelastninger fordi den bevarer rådata for utforskende analyse og gir fleksibilitet til å endre transformasjonslogikk uten re-innhenting fra kildesystemer.
|
||||
|
||||
Denne referansen sammenligner ETL og ELT for AI-brukstilfeller, med fokus på Fabric-spesifikke implementasjoner, hybridmønstre, inkrementell prosessering, og kostnadsoptimalisering.
|
||||
|
||||
---
|
||||
|
||||
## ELT Advantages: Cost, Scalability, Schema-Flexibility
|
||||
|
||||
### Hvorfor ELT dominerer for AI
|
||||
|
||||
| Fordel | Beskrivelse | AI-relevans |
|
||||
|---|---|---|
|
||||
| **Bevarer rådata** | Original data tilgjengelig for nye analyser | Nye features uten re-innhenting |
|
||||
| **Skalerer med beregning** | Fabric Spark/SQL skalerer elastisk | Store treningsdatasett |
|
||||
| **Schema-fleksibilitet** | Schema-on-read i Bronze | Nye datakilder uten re-design |
|
||||
| **Forenkling** | Ingen separat transformasjonsserver | Lavere TCO |
|
||||
| **Parallellisering** | Transformasjoner på distribuert Spark | Raskere feature engineering |
|
||||
|
||||
### ELT i Fabric
|
||||
|
||||
```
|
||||
Kilde ──> Extract ──> Load (OneLake) ──> Transform (Spark/SQL)
|
||||
│
|
||||
┌─────▼──────┐
|
||||
│ Lakehouse │
|
||||
│ (Bronze) │
|
||||
│ Rådata i │
|
||||
│ Delta Lake │
|
||||
└─────┬──────┘
|
||||
│ Spark Notebook / SQL
|
||||
┌─────▼──────┐
|
||||
│ Lakehouse │
|
||||
│ (Silver) │
|
||||
│ Validert │
|
||||
└─────┬──────┘
|
||||
│ Spark Notebook / SQL
|
||||
┌─────▼──────┐
|
||||
│ Lakehouse │
|
||||
│ (Gold) │
|
||||
│ ML-features│
|
||||
└────────────┘
|
||||
```
|
||||
|
||||
### Fabric ELT Implementation
|
||||
|
||||
```python
|
||||
# Steg 1: Extract + Load (Copy Job / Pipeline)
|
||||
# Data Factory laster rådata direkte til Bronze Lakehouse
|
||||
|
||||
# Steg 2: Transform i Lakehouse med Spark
|
||||
# Bronze → Silver transformasjon
|
||||
bronze_data = spark.read.format("delta").table("bronze.raw_transactions")
|
||||
|
||||
silver_data = (
|
||||
bronze_data
|
||||
# Fjern duplikater
|
||||
.dropDuplicates(["transaction_id"])
|
||||
# Typevalidering
|
||||
.withColumn("amount", col("amount").cast("double"))
|
||||
.filter(col("amount") > 0)
|
||||
# Standardiser datoformat
|
||||
.withColumn("transaction_date",
|
||||
F.to_timestamp("transaction_date", "yyyy-MM-dd'T'HH:mm:ss"))
|
||||
# Fjern null i obligatoriske felt
|
||||
.filter(col("customer_id").isNotNull())
|
||||
)
|
||||
|
||||
silver_data.write.format("delta").mode("overwrite") \
|
||||
.saveAsTable("silver.validated_transactions")
|
||||
|
||||
# Steg 3: Silver → Gold (ML-features)
|
||||
gold_features = (
|
||||
spark.read.format("delta").table("silver.validated_transactions")
|
||||
.groupBy("customer_id")
|
||||
.agg(
|
||||
F.count("*").alias("total_transactions"),
|
||||
F.sum("amount").alias("total_amount"),
|
||||
F.avg("amount").alias("avg_amount"),
|
||||
F.stddev("amount").alias("std_amount"),
|
||||
F.max("transaction_date").alias("last_transaction_date")
|
||||
)
|
||||
)
|
||||
|
||||
gold_features.write.format("delta").mode("overwrite") \
|
||||
.saveAsTable("gold.customer_features")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ETL Data Minimization for Regulated Environments
|
||||
|
||||
### Når ETL er riktig valg
|
||||
|
||||
ETL er foretrukket i regulerte miljøer der dataminimering er påkrevd:
|
||||
|
||||
| Scenario | Begrunnelse | Regulering |
|
||||
|---|---|---|
|
||||
| **PII-filtrering** | Fjern personnummer før lasting | GDPR Art. 5(1)(c) |
|
||||
| **Dataminimering** | Last kun nødvendige felter | GDPR Art. 5(1)(c) |
|
||||
| **Kryptering** | Krypter sensitive felt i transit | Sikkerhetskrav |
|
||||
| **Konsolidering** | Slå sammen kilder før lasting | Kostnadsbegrensning |
|
||||
| **Format-konvertering** | Konverter proprietære formater | Interoperabilitet |
|
||||
|
||||
### ETL i Fabric med Dataflow Gen2
|
||||
|
||||
```
|
||||
Kilde ──> Dataflow Gen2 (Transform) ──> Lakehouse (Silver/Gold)
|
||||
│
|
||||
├── Fjern PII-kolonner
|
||||
├── Masker fødselsnummer
|
||||
├── Aggreger til anonymt nivå
|
||||
├── Validerer datatyper
|
||||
└── Berik med referansedata
|
||||
```
|
||||
|
||||
### Dataflow Gen2 for ETL
|
||||
|
||||
Dataflow Gen2 bruker Power Query Online med over 300 transformasjoner:
|
||||
|
||||
```m
|
||||
// M-kode (Power Query) for ETL med dataminimering
|
||||
let
|
||||
Source = Sql.Database("server.database.windows.net", "hrdb"),
|
||||
employees = Source{[Schema="dbo", Item="Employees"]}[Data],
|
||||
|
||||
// Fjern sensitive kolonner (dataminimering)
|
||||
removedPII = Table.RemoveColumns(employees,
|
||||
{"SocialSecurityNumber", "BankAccount", "HomeAddress"}),
|
||||
|
||||
// Masker e-post
|
||||
maskedEmail = Table.TransformColumns(removedPII,
|
||||
{{"Email", each Text.BeforeDelimiter(_, "@") & "@***.no"}}),
|
||||
|
||||
// Aggreger alder til aldersgrupper
|
||||
addAgeGroup = Table.AddColumn(maskedEmail, "AgeGroup",
|
||||
each if [Age] < 30 then "Under 30"
|
||||
else if [Age] < 50 then "30-49"
|
||||
else "50+"),
|
||||
|
||||
// Fjern eksakt alder (kun aldersgruppe beholdes)
|
||||
removedAge = Table.RemoveColumns(addAgeGroup, {"Age"}),
|
||||
|
||||
// Filtrer kun aktive ansatte
|
||||
filtered = Table.SelectRows(removedAge, each [Status] = "Active")
|
||||
in
|
||||
filtered
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Hybrid ETL/ELT Patterns
|
||||
|
||||
### Pattern: Pre-filter ETL + In-place ELT
|
||||
|
||||
```
|
||||
ETL (Dataflow Gen2) ELT (Spark)
|
||||
┌──────────────────┐ ┌──────────────────┐
|
||||
Kildesystem ───────>│ Fjern PII │──> Bronze ─│ Feature engineer │──> Silver
|
||||
│ Masker sensitive │ │ Aggreger │
|
||||
│ Validerer format │ │ Join │
|
||||
└──────────────────┘ │ Dedupliser │
|
||||
└──────────────────┘
|
||||
```
|
||||
|
||||
### Pattern: Metadata-driven Hybrid Pipeline
|
||||
|
||||
```python
|
||||
# Metadata-drevet pipeline som velger ETL eller ELT per datakilde
|
||||
pipeline_config = {
|
||||
"sources": [
|
||||
{
|
||||
"name": "crm_customers",
|
||||
"strategy": "ETL", # Inneholder PII
|
||||
"reason": "PII-filtrering påkrevd",
|
||||
"transformations": ["remove_ssn", "mask_email", "age_to_group"],
|
||||
"tool": "dataflow_gen2"
|
||||
},
|
||||
{
|
||||
"name": "traffic_events",
|
||||
"strategy": "ELT", # Ingen sensitive data
|
||||
"reason": "Stort volum, ingen PII",
|
||||
"transformations": ["aggregate_5min", "add_road_segment"],
|
||||
"tool": "spark_notebook"
|
||||
},
|
||||
{
|
||||
"name": "health_records",
|
||||
"strategy": "ETL", # Helseopplysninger (særkategori)
|
||||
"reason": "GDPR Art. 9 - særlig kategori",
|
||||
"transformations": [
|
||||
"pseudonymize_patient_id",
|
||||
"remove_diagnosis_text",
|
||||
"aggregate_to_cohort"
|
||||
],
|
||||
"tool": "dataflow_gen2"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Fabric Pipeline Orchestration
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "HybridETL_ELT_Pipeline",
|
||||
"properties": {
|
||||
"activities": [
|
||||
{
|
||||
"name": "ETL_SensitiveData",
|
||||
"type": "DataflowGen2",
|
||||
"description": "ETL for PII-data via Dataflow Gen2",
|
||||
"typeProperties": {
|
||||
"dataflowName": "pii_cleansing_flow"
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "ELT_BulkLoad",
|
||||
"type": "Copy",
|
||||
"description": "ELT: Last rådata direkte til Bronze",
|
||||
"dependsOn": [],
|
||||
"typeProperties": {
|
||||
"source": { "type": "BlobSource" },
|
||||
"sink": { "type": "LakehouseSink" }
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Transform_Silver",
|
||||
"type": "Notebook",
|
||||
"description": "ELT: Transform i Spark",
|
||||
"dependsOn": [
|
||||
{ "activity": "ETL_SensitiveData" },
|
||||
{ "activity": "ELT_BulkLoad" }
|
||||
],
|
||||
"typeProperties": {
|
||||
"notebookPath": "silver_transformations"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Staging and Incremental Processing
|
||||
|
||||
### Inkrementelle lastingsmønstre
|
||||
|
||||
| Mønster | Beskrivelse | Bruk i Fabric |
|
||||
|---|---|---|
|
||||
| **Full load** | Last alt hver gang | Copy Job (full load) |
|
||||
| **Incremental append** | Last kun nye rader | Copy Job (append) + watermark |
|
||||
| **CDC (Change Data Capture)** | Strøm av endringer | Copy Job (CDC), Mirroring |
|
||||
| **Watermark** | Last rader etter siste timestamp | Pipeline med parameter |
|
||||
| **Delta load** | Merge nye/endrede rader | Copy Job (upsert) |
|
||||
|
||||
### Watermark-basert inkrementell lasting
|
||||
|
||||
```python
|
||||
# Hent siste watermark (høyeste lastede timestamp)
|
||||
last_watermark = spark.sql("""
|
||||
SELECT MAX(loaded_timestamp) as watermark
|
||||
FROM bronze.raw_events
|
||||
""").collect()[0]["watermark"]
|
||||
|
||||
# Last kun nye data
|
||||
new_data = (
|
||||
spark.read
|
||||
.format("jdbc")
|
||||
.option("url", jdbc_url)
|
||||
.option("dbtable", f"""
|
||||
(SELECT * FROM events
|
||||
WHERE modified_date > '{last_watermark}') AS new_events
|
||||
""")
|
||||
.load()
|
||||
)
|
||||
|
||||
# Append til Bronze
|
||||
new_data.withColumn("loaded_timestamp", F.current_timestamp()) \
|
||||
.write.format("delta").mode("append") \
|
||||
.saveAsTable("bronze.raw_events")
|
||||
|
||||
print(f"Lastet {new_data.count()} nye rader etter {last_watermark}")
|
||||
```
|
||||
|
||||
### Staging Layer Pattern
|
||||
|
||||
```
|
||||
Kildesystem ──> Staging Area ──> Bronze ──> Silver ──> Gold
|
||||
│
|
||||
├── Midlertidig lagring
|
||||
├── Validering før insert
|
||||
├── Duplikatsjekk
|
||||
└── Slettet etter vellykket last
|
||||
```
|
||||
|
||||
```python
|
||||
# Staging → Bronze med validering
|
||||
staging_data = spark.read.format("delta").table("staging.incoming_data")
|
||||
|
||||
# Valider
|
||||
valid_records = staging_data.filter(
|
||||
col("customer_id").isNotNull() &
|
||||
col("amount").isNotNull() &
|
||||
(col("amount") > 0)
|
||||
)
|
||||
|
||||
rejected_records = staging_data.subtract(valid_records)
|
||||
|
||||
# Last gyldige poster til Bronze
|
||||
valid_records.write.format("delta").mode("append").saveAsTable("bronze.validated_events")
|
||||
|
||||
# Logg avviste poster
|
||||
rejected_records.write.format("delta").mode("append").saveAsTable("governance.rejected_records")
|
||||
|
||||
# Rydd opp staging
|
||||
spark.sql("TRUNCATE TABLE staging.incoming_data")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Compute Cost Allocation: ETL vs ELT
|
||||
|
||||
### Kostnadsmodell i Fabric
|
||||
|
||||
| Komponent | Fabric CU-meter | Kostnadsdriver |
|
||||
|---|---|---|
|
||||
| **Copy Job / Activity** | Data Movement | Datamengde (GB) |
|
||||
| **Dataflow Gen2** | Standard Compute / High Scale Compute | Kompleksitet, rader |
|
||||
| **Spark Notebook** | Spark Compute | vCores x tid |
|
||||
| **Pipeline Orchestration** | Data Orchestration | Antall aktiviteter |
|
||||
| **OneLake Storage** | OneLake Storage | Lagret data (GB/mnd) |
|
||||
|
||||
### ETL vs ELT kostnadsprofil
|
||||
|
||||
| Aspekt | ETL (Dataflow Gen2) | ELT (Spark) |
|
||||
|---|---|---|
|
||||
| **Oppsettskostnad** | Lav (no-code) | Medium (kode) |
|
||||
| **Kjøretidskostnad per rad** | Høyere (transformasjon + last) | Lavere (kun last, transform i batch) |
|
||||
| **Skalerbarhet** | Begrenset (single-node-lik) | Høy (distribuert Spark) |
|
||||
| **Lagringskostnad** | Lavere (kun transformert data) | Høyere (rådata + transformert) |
|
||||
| **Vedlikeholdskostnad** | Lav (visuell editor) | Medium (kodevedlikehold) |
|
||||
| **Optimal for** | < 10 GB, enkel transformasjon | > 10 GB, kompleks transformasjon |
|
||||
|
||||
### Kostnadsoptimalisering
|
||||
|
||||
```python
|
||||
# 1. Bruk Copy Job i stedet for Copy Activity for bulk-lasting
|
||||
# Copy Job: Automatisk CDC, inkrementell lasting, lavere kostnad
|
||||
|
||||
# 2. Bruk Optimized Write for å redusere små filer
|
||||
spark.conf.set("spark.microsoft.delta.optimizeWrite.enabled", "true")
|
||||
|
||||
# 3. Bruk Spark autoscale for å matche beregning med behov
|
||||
# Konfigureres i Workspace Settings > Spark Compute
|
||||
|
||||
# 4. Planlegg tunge transformasjoner utenfor peak-timer
|
||||
# Pipeline schedule: "0 2 * * *" (kl 02:00)
|
||||
|
||||
# 5. Bruk materialized lake views for repetitive transformasjoner
|
||||
# Unngår gjentatt beregning av samme transformasjoner
|
||||
```
|
||||
|
||||
### Beslutningsmatrise
|
||||
|
||||
| Faktor | Velg ETL | Velg ELT | Velg Hybrid |
|
||||
|---|---|---|---|
|
||||
| **Datamengde** | < 10 GB | > 10 GB | Variabel |
|
||||
| **PII i kildedata** | Ja (GDPR) | Nei | Noen kilder med PII |
|
||||
| **Schema-stabilitet** | Stabilt | Variabel | Blandet |
|
||||
| **Team-kompetanse** | Power Query/Excel | PySpark/SQL | Blandet |
|
||||
| **Transformasjonskompleksitet** | Enkel (filter, rename) | Kompleks (vindus, ML) | Blandet |
|
||||
| **Latenskrav** | Minutter | Sekunder-minutter | Variabel |
|
||||
| **Budget** | Begrenset | Fleksibelt | Variabel |
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [What is Data Factory in Microsoft Fabric?](https://learn.microsoft.com/en-us/fabric/data-factory/data-factory-overview) -- Oversikt med ETL/ELT-sammenligning
|
||||
- [Extract, transform, and load (ETL)](https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl) -- Azure Architecture Center ETL/ELT guide
|
||||
- [Dimensional modeling: Load tables](https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-load-tables) -- ETL for dimensjonsmodellering
|
||||
- [Data Factory end-to-end scenario](https://learn.microsoft.com/en-us/fabric/data-factory/tutorial-end-to-end-introduction) -- Komplett tutorial
|
||||
- [Differences between Azure Data Factory and Fabric Data Factory](https://learn.microsoft.com/en-us/fabric/data-factory/compare-fabric-data-factory-and-azure-data-factory) -- Migrasjon fra ADF
|
||||
- [Data Factory pricing in Microsoft Fabric](https://learn.microsoft.com/en-us/fabric/data-factory/pricing-overview) -- Prismodell og CU-metere
|
||||
- [Migration planning: ADF to Fabric Data Factory](https://learn.microsoft.com/en-us/fabric/data-factory/migrate-planning-azure-data-factory) -- Migrasjonsguide
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren evaluerer dataintegrerings-strategier for AI, vurderer kostnader og ytelse, eller trenger å håndtere sensitive data i pipelines.
|
||||
- For norsk offentlig sektor: Anbefal **hybrid ETL/ELT** som standard -- ETL for kilder med personopplysninger (Dataflow Gen2 med PII-filtrering), ELT for alle andre kilder (Copy Job + Spark).
|
||||
- **ELT er generelt best for AI** fordi det bevarer rådata i Bronze, noe som muliggjør eksperimentering med nye features uten å måtte re-hente data fra kildesystemer.
|
||||
- **Dataflow Gen2** er undervurdert for ETL i offentlig sektor -- det er et Power Query-basert verktøy som mange forvaltere allerede kjenner fra Excel/Power BI, og det håndterer dataminimering visuelt.
|
||||
- Ved kostnadsestimering: Husk at ELT har **høyere lagringskostnad** (bevarer rådata) men **lavere beregningskostnad** for gjentatte transformasjoner. For AI-prosjekter veier fleksibilitetsgevinsten vanligvis opp for ekstra lagring.
|
||||
|
|
@ -0,0 +1,356 @@
|
|||
# Fabric Lakehouse Architecture for AI Workloads
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Microsoft Fabric Lakehouse er Microsofts moderne dataplattformløsning som kombinerer det beste fra data lakes og data warehouses i én enkelt, unified arkitektur. Lakehouse bruker åpne standarder (Delta Lake) og gir en SaaS-opplevelse hvor strukturert, semistrukturert og ustrukturert data kan lagres sammen i OneLake, som er Microsofts single, unified, logical data lake for hele organisasjonen.
|
||||
|
||||
For AI-arbeidsflater er lakehouse-arkitektur spesielt relevant fordi den støtter både batch-prosessering (for modelltrening og historisk analyse) og streaming (for real-time inferens og kontinuerlig læring). Delta Lake-formatet sikrer ACID-transaksjoner, data lineage og time-travel capabilities, noe som er kritisk for reproduserbarhet i ML-pipelines. OneLake er automatisk provisionert med hver Fabric-tenant og fungerer som sentral datahub for alle analytics workloads.
|
||||
|
||||
Fabric Lakehouse støtter multiple compute engines (Spark, SQL, Power BI, Machine Learning) på samme data copy i OneLake, noe som eliminerer dataduplisering og reduserer total cost of ownership (TCO). Lakehouse er ikke bare en storage layer, men en fullverdig data architecture platform med innebygd SQL analytics endpoint, default Power BI semantic models, og native integrasjon med Azure Machine Learning og Fabric Data Science.
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
| Komponent | Beskrivelse | Rolle i AI-arbeidsflate |
|
||||
|-----------|-------------|-------------------------|
|
||||
| **OneLake** | Single, unified, logical data lake for hele organisasjonen | Sentral storage layer for alle data assets (raw data, feature stores, modeller) |
|
||||
| **Delta Lake** | Open-source storage layer med ACID-transaksjoner | Standard format for alle tabeller; sikrer data consistency og reproducibility |
|
||||
| **Lakehouse Tables** | Delta-tabeller med Apache Spark-støtte | Feature engineering, model training, batch scoring |
|
||||
| **Lakehouse Files** | Rå filer i alle formater (CSV, Parquet, JSON, PDF, images) | Ingestion av ustrukturerte data for multimodal AI |
|
||||
| **SQL Analytics Endpoint** | Auto-generated read-only SQL endpoint per lakehouse | SQL-basert data access for data scientists og ML engineers |
|
||||
| **Default Semantic Model** | Auto-created Power BI model per lakehouse | Rask visualisering av treningsdata og modellresultater |
|
||||
| **Spark Notebooks** | Web-based interactive notebooks med Spark runtime | Feature engineering, EDA, model training, model deployment |
|
||||
| **Dataflows Gen2** | Low-code ETL med Power Query interface | Data preparation uten kode (300+ transformasjoner) |
|
||||
| **Shortcuts** | In-place links til eksterne data sources | Koble til ADLS Gen2, S3, Databricks uten å kopiere data |
|
||||
| **V-Order** | Write-time optimization for Parquet files | Fast reads for Power BI, SQL, Spark på samme data |
|
||||
| **Starter Pools** | Rapid Spark session initialization (5-10 sekunder) | Rask iterasjon i ML-eksperimenter |
|
||||
| **Environments** | Customizable Spark runtimes med package dependencies | Custom ML libraries (TensorFlow, PyTorch, scikit-learn) |
|
||||
|
||||
### Delta Lake i AI-kontekst
|
||||
|
||||
Delta Lake er kritisk for AI-arbeidsflater fordi det sikrer:
|
||||
|
||||
- **ACID-transaksjoner**: Eliminerer data corruption under concurrent writes (viktig for distributed training)
|
||||
- **Time Travel**: Versioning av features og training data for ML reproducibility
|
||||
- **Schema Enforcement**: Validering av data quality før det når ML-pipelines
|
||||
- **Unified Batch/Stream**: Samme API for batch feature engineering og real-time feature updates
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### Medallion Architecture (Industry Standard)
|
||||
|
||||
Medallion architecture er den anbefalte design pattern for Fabric Lakehouse, spesielt for AI-arbeidsflater. Den består av tre lag:
|
||||
|
||||
| Layer | Beskrivelse | Format | AI Use Case |
|
||||
|-------|-------------|--------|-------------|
|
||||
| **Bronze (Raw)** | Immutable copy av rådata i original format | Original format eller Parquet/Delta | Data lineage, audit trail, replay for model retraining |
|
||||
| **Silver (Enriched)** | Validert, deduplisert, standardisert data | Delta Lake | Feature engineering, exploratory data analysis |
|
||||
| **Gold (Curated)** | Business-ready data, aggregert og optimalisert | Delta Lake (V-Order) | Model training, serving, Power BI dashboards |
|
||||
|
||||
**Fordeler:**
|
||||
- Klar separasjon mellom raw data (source of truth) og curated data (ready for ML)
|
||||
- Inkrementell forbedring av data quality gjennom layers
|
||||
- Støtter både batch og streaming workloads
|
||||
- Enkel rollback ved feil i transformations
|
||||
|
||||
**Ulemper:**
|
||||
- Kan føre til data duplication hvis ikke implementert riktig (bruk shortcuts)
|
||||
- Krever disciplin i dataflyt-design (bronze → silver → gold)
|
||||
- Overhead for små datasett (kanskje overkill for POCs)
|
||||
|
||||
### Lambda Architecture (Batch + Streaming)
|
||||
|
||||
Fabric Lakehouse støtter Lambda architecture natively gjennom:
|
||||
|
||||
- **Cold path (batch)**: Data Factory pipelines + Spark notebooks → Bronze/Silver/Gold lakehouses
|
||||
- **Hot path (streaming)**: Eventstreams → Real-Time Intelligence → Lakehouse tables
|
||||
|
||||
**Når bruke:**
|
||||
- Real-time inferens kombinert med historisk analyse
|
||||
- IoT-scenarios med batch model retraining og streaming predictions
|
||||
- Hybrid workloads hvor noen features er pre-computed (batch) og andre er live (streaming)
|
||||
|
||||
**Fordeler:**
|
||||
- Best of both worlds: real-time insights + historical analysis
|
||||
- Fabric håndterer kompleksiteten (no need for separate Spark Streaming og batch clusters)
|
||||
|
||||
**Ulemper:**
|
||||
- Mer kompleks å vedlikeholde enn pure batch eller pure streaming
|
||||
- Krever koordinering mellom batch og streaming pipelines
|
||||
|
||||
### Data Mesh med Fabric Domains
|
||||
|
||||
For store organisasjoner kan lakehouse-arkitektur kombineres med data mesh pattern:
|
||||
|
||||
- Opprett separate **Fabric Domains** per business domain (Sales, Marketing, Finance)
|
||||
- Implementer medallion architecture **innenfor hver domain**
|
||||
- Bruk **Fabric Shortcuts** til cross-domain data sharing
|
||||
- Registrer data products i **Microsoft Purview** for governance
|
||||
|
||||
**Fordeler:**
|
||||
- Decentralized ownership (domain teams eier sine lakehouses)
|
||||
- Scalable governance (Purview + per-domain policies)
|
||||
- Raskere time-to-value (teams kan jobbe parallelt)
|
||||
|
||||
**Ulemper:**
|
||||
- Krever sterk governance framework (Purview er påkrevd)
|
||||
- Risk for data silos hvis ikke shortcuts brukes riktig
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Pattern 1: Lakehouse-only (anbefalt for AI)
|
||||
|
||||
- **Bronze, Silver, Gold** alle som lakehouses
|
||||
- Business users bruker **SQL Analytics Endpoint** for read-only queries
|
||||
- Data scientists bruker **Spark notebooks** for feature engineering og training
|
||||
|
||||
**Når bruke:**
|
||||
- AI/ML workloads med stort behov for Spark processing
|
||||
- Teams med Spark/Python-kompetanse
|
||||
- Behov for flexible schema (semi-structured/unstructured data)
|
||||
|
||||
### Pattern 2: Lakehouse + Warehouse (hybrid)
|
||||
|
||||
- **Bronze/Silver** som lakehouses (Spark-based transformation)
|
||||
- **Gold** som Data Warehouse (SQL-based analytics)
|
||||
- Business users bruker **Warehouse endpoint** for BI reporting
|
||||
|
||||
**Når bruke:**
|
||||
- Hybrid teams (data scientists + SQL-focused BI analysts)
|
||||
- Gold layer krever komplekse SQL transformations
|
||||
- Need for SQL-native features (stored procedures, views)
|
||||
|
||||
### Deployment Considerations
|
||||
|
||||
| Faktor | Anbefaling |
|
||||
|--------|------------|
|
||||
| **Workspace design** | Separate workspaces per layer (Bronze WS, Silver WS, Gold WS) for bedre governance |
|
||||
| **Bronze storage** | Original format hvis mulig; bruk shortcuts for ADLS Gen2/S3 (avoid copy) |
|
||||
| **Silver/Gold storage** | Delta Lake (mandatory for V-Order optimization) |
|
||||
| **File size** | Target ~1 GB per file for optimal query performance |
|
||||
| **Partitioning** | Date-based partitioning (year/month/day) for time-series data |
|
||||
| **Historical retention** | VACUUM old Delta versions (default 7 days, configure med `delta.deletedFileRetentionDuration`) |
|
||||
| **Z-Order indexing** | Bruk for high-cardinality columns (customer_id, product_id) |
|
||||
|
||||
### Vanlige feil
|
||||
|
||||
| Feil | Konsekvens | Løsning |
|
||||
|------|------------|---------|
|
||||
| **Mange små filer** | Slow query performance | Bruk OPTIMIZE command eller enable Predictive Optimization |
|
||||
| **Manglende partitioning** | Full table scans | Implementer partition pruning basert på query patterns |
|
||||
| **Ikke bruke V-Order** | Slow Power BI Direct Lake mode | Alltid bruk Delta Lake (V-Order er auto-enabled) |
|
||||
| **Copy data istedenfor shortcuts** | Unødvendig storage cost + data staleness | Bruk OneLake shortcuts for external data |
|
||||
| **Single workspace for all layers** | Poor governance + risk of accidental deletes | Separate workspaces per layer (Bronze/Silver/Gold) |
|
||||
|
||||
### Røde flagg
|
||||
|
||||
- 🚩 **"Vi skriver direkte til Gold layer"** → Mangler audit trail og reproducibility
|
||||
- 🚩 **"Vi bruker CSV for Silver layer"** → Mister ACID-transaksjoner og time travel
|
||||
- 🚩 **"Vi har 1000+ Parquet files per tabell"** → Performance problem (run OPTIMIZE)
|
||||
- 🚩 **"SQL Analytics Endpoint er tregt"** → Sannsynligvis mange små filer eller manglende V-Order
|
||||
- 🚩 **"Vi kopierer data fra ADLS Gen2 til OneLake"** → Unødvendig cost (bruk shortcuts)
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
| Tjeneste | Integrasjonspunkt | Use Case |
|
||||
|----------|-------------------|----------|
|
||||
| **Azure Machine Learning** | Read Lakehouse tables via `azureml-fsspec` | Model training på curated Gold layer data |
|
||||
| **Azure AI Foundry** | OneLake shortcuts til Foundry projects | Unified data access for prompt flow og vector indexes |
|
||||
| **Copilot Studio** | Power Automate triggers fra Lakehouse | Automated workflows basert på data events |
|
||||
| **Power BI** | Direct Lake mode (native på Lakehouse) | In-memory performance uten separate import |
|
||||
| **Azure Databricks** | OneLake shortcuts (read Fabric data fra Databricks) | Interop med eksisterende Databricks workloads |
|
||||
| **Synapse Analytics** | COPY INTO fra Lakehouse SQL endpoint | Migrasjon fra Synapse til Fabric |
|
||||
| **Azure Data Factory** | Fabric Lakehouse connector | Hybrid pipelines (ADF → Fabric Lakehouse) |
|
||||
| **Microsoft Purview** | Auto-registration av Lakehouse assets | Data governance og lineage tracking |
|
||||
| **Azure Key Vault** | Secrets for Shortcuts authentication | Sikker tilgang til external data sources |
|
||||
|
||||
### Direct Lake Mode (kritisk for AI dashboards)
|
||||
|
||||
Power BI Direct Lake mode er unikt for Fabric Lakehouse og gir:
|
||||
|
||||
- **In-memory performance** uten separate data import
|
||||
- **No data movement** (query direkte mot OneLake Delta tables)
|
||||
- **Automatic fallback** til DirectQuery hvis capacity limits nås
|
||||
|
||||
**Fallback scenarios (viktig å vite):**
|
||||
- Semantic model table stats exceed [capacity guardrails](https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements)
|
||||
- Row-level security (RLS) applied på semantic model
|
||||
- Semantic model refererer views istedenfor direct OneLake tables
|
||||
|
||||
**Løsning:** Bruk SQL Analytics Endpoint som Power BI data source med Direct Lake enabled (auto-fallback til DirectQuery)
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### GDPR og personvern
|
||||
|
||||
| Krav | Implementasjon i Fabric Lakehouse |
|
||||
|------|-----------------------------------|
|
||||
| **Rett til sletting** | Bruk Delta Lake MERGE command for delete requests (GDPR erasure) |
|
||||
| **Data minimering** | Implement partitioning + TTL expiration for date-partitioned tables |
|
||||
| **Pseudonymisering** | Apply masking i Silver layer før Gold (bruk Spark UDFs for tokenization) |
|
||||
| **Tilgangskontroll** | Workspace-based RBAC + OneLake file-level ACLs |
|
||||
| **Logging** | Fabric Audit Logs (captured automatisk) for all data access |
|
||||
|
||||
### Schrems II og datasuverenitet
|
||||
|
||||
- **Fabric Multi-Geo**: OneLake data residency i Norway East region
|
||||
- **Customer-managed keys**: Bruk Azure Key Vault for encryption keys (BYOK)
|
||||
- **Private Links**: Isoler Fabric fra public internet (inbound/outbound network security)
|
||||
- **Managed Private Endpoints**: Connect til on-prem data sources uten public exposure
|
||||
|
||||
### AI Act compliance
|
||||
|
||||
| AI Act-krav | Lakehouse-implementasjon |
|
||||
|-------------|-------------------------|
|
||||
| **Transparency** | Delta Lake time travel for full data lineage |
|
||||
| **Data quality** | Enforce data quality constraints med Materialized Lake Views |
|
||||
| **Risk management** | Store model training data i Bronze layer (audit trail) |
|
||||
| **Human oversight** | SQL Analytics Endpoint for manual data inspection |
|
||||
|
||||
### Forvaltningsloven § 10 (utredningsplikt)
|
||||
|
||||
Når AI-modeller brukes i offentlig forvaltning må lakehouse-arkitektur støtte:
|
||||
|
||||
- **Dokumentasjon av datagrunnlag**: Bronze layer som immutable source of truth
|
||||
- **Etterprøvbarhet**: Delta time travel for å gjenskape historical training data
|
||||
- **Kildesporing**: Microsoft Purview for end-to-end data lineage
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Prismodell
|
||||
|
||||
| Komponent | Prismodell | Estimat (F64 SKU) |
|
||||
|-----------|------------|-------------------|
|
||||
| **OneLake Storage** | $0.023 per GB/month (Norway East) | 1 TB = ~$23/month |
|
||||
| **Fabric Capacity** | F SKU (CU-based) eller Premium Per User | F64 = ~$5,120/month |
|
||||
| **Egress** | Free innen samme region | Cross-region = $0.02/GB |
|
||||
|
||||
**Viktig:** Fabric pricing er **capacity-based** (ikke per user). Alle Fabric items (lakehouse, notebooks, pipelines) konsumerer CUs fra kjøpt capacity.
|
||||
|
||||
### Optimaliseringstips
|
||||
|
||||
| Teknikk | Savings | Implementasjon |
|
||||
|---------|---------|----------------|
|
||||
| **Bursting** | Avoid higher SKU | Schedule CPU-intensive jobs during off-peak (smoothing) |
|
||||
| **Predictive Optimization** | Reduce manual OPTIMIZE | Enable auto-optimization for Delta tables |
|
||||
| **OneLake Shortcuts** | Eliminate copy costs | Link to ADLS Gen2/S3 instead of ingesting |
|
||||
| **Direct Lake mode** | Reduce Power BI Premium Gen2 cost | No separate import = less capacity usage |
|
||||
| **Starter Pools** | Fast session init | Avoid paying for long Spark startup times |
|
||||
| **Workload Management** | Stagger jobs | Avoid capacity throttling (schedule at staggered times) |
|
||||
|
||||
### Capacity Reservations (kostbesparelse)
|
||||
|
||||
- **1-year commitment**: Save up to 40% vs pay-as-you-go
|
||||
- **3-year commitment**: Save up to 60%
|
||||
- **Trial capacities**: Test med free F64 trial (60 days) før commitment
|
||||
|
||||
### Monitoring og capacity planning
|
||||
|
||||
Bruk **Fabric Capacity Metrics App** for:
|
||||
|
||||
- Visualisere CU consumption per lakehouse/notebook
|
||||
- Identifisere peak hours for scheduling optimization
|
||||
- Track bursting/smoothing events
|
||||
- Set up proactive alerts (via Power Automate)
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Spørsmål å stille kunden
|
||||
|
||||
1. **Data volume og vekst:** Hvor mye data har dere i dag, og hva er forventet årlig vekst? (påvirker F SKU sizing)
|
||||
2. **Batch vs streaming ratio:** Er dette primært batch-training eller trenger dere real-time inferens? (Lambda architecture decision)
|
||||
3. **Team skills:** Har teamet Spark/Python-kompetanse eller er de SQL-fokusert? (Lakehouse-only vs Lakehouse+Warehouse)
|
||||
4. **Data residency:** Må data ligge i Norge? (Multi-Geo + Schrems II compliance)
|
||||
5. **External data sources:** Hvor ligger dagens data (ADLS Gen2, S3, on-prem)? (Shortcuts vs ingestion strategy)
|
||||
6. **Power BI usage:** Skal lakehouse brukes som Power BI data source? (Direct Lake mode considerations)
|
||||
7. **ML platform:** Bruker dere Azure ML eller Fabric Data Science? (Integration pattern)
|
||||
8. **Existing Databricks investment:** Har dere Databricks workloads? (Interop via shortcuts vs migration)
|
||||
|
||||
### Fallgruver å unngå
|
||||
|
||||
| Fallgruve | Konsekvens | Mitigating Strategy |
|
||||
|-----------|------------|---------------------|
|
||||
| **Overkill for POC** | Delayed time-to-value | Start med single lakehouse + notebooks (skip medallion for POC) |
|
||||
| **Underestimere F SKU** | Throttling + poor UX | Start med F64 trial, measure actual CU consumption, rightsize før prod |
|
||||
| **Ignorer governance** | Data sprawl + compliance risk | Set up Purview + Domains fra dag 1 (selv for POC) |
|
||||
| **Kopiere istedenfor shortcuts** | Storage cost explosion | Default til shortcuts; only copy hvis necessary (latency requirements) |
|
||||
| **Glemme V-Order** | Slow Power BI performance | Always use Delta Lake (V-Order auto-enabled) |
|
||||
| **Single-workspace design** | Poor isolation + risk | Separate workspaces per layer (Bronze/Silver/Gold) |
|
||||
| **Ignorer VACUUM** | Storage cost creep | Set retention policy + run VACUUM regularly |
|
||||
| **No monitoring** | Surprise capacity bills | Enable Capacity Metrics App + alerts fra dag 1 |
|
||||
|
||||
### Anbefalinger per modenhetsnivå
|
||||
|
||||
#### Level 1: Starter (POC, < 100 GB data)
|
||||
|
||||
- **Setup:** Single lakehouse med Files + Tables
|
||||
- **Transformation:** Spark notebooks (no medallion yet)
|
||||
- **Capacity:** F64 trial eller pay-as-you-go
|
||||
- **Governance:** Basic workspace-level RBAC
|
||||
- **Mål:** Prove value av Fabric for AI use case
|
||||
|
||||
#### Level 2: Intermediate (Pilot, 100 GB - 1 TB data)
|
||||
|
||||
- **Setup:** Bronze/Silver/Gold lakehouses
|
||||
- **Transformation:** Mix av notebooks + Dataflows Gen2
|
||||
- **Capacity:** F64 paid (measure CU usage for scaling)
|
||||
- **Governance:** Separate workspaces per layer + Purview registration
|
||||
- **Monitoring:** Capacity Metrics App + basic alerts
|
||||
- **Mål:** Production-ready pipeline med proper data quality
|
||||
|
||||
#### Level 3: Advanced (Production, > 1 TB data)
|
||||
|
||||
- **Setup:** Domain-based data mesh (multiple Bronze/Silver/Gold per domain)
|
||||
- **Transformation:** Automated pipelines + Materialized Lake Views
|
||||
- **Capacity:** F128+ med capacity reservations
|
||||
- **Governance:** Full Purview integration + Domains + RLS/OLS
|
||||
- **Monitoring:** Custom dashboards + Power Automate workflows
|
||||
- **Optimization:** Predictive Optimization enabled + Z-Order indexing
|
||||
- **Mål:** Enterprise-scale data platform med full governance
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
### Microsoft Learn (MCP-verified)
|
||||
|
||||
**Verified (fra microsoft_docs_search og microsoft_docs_fetch):**
|
||||
|
||||
1. [Greenfield lakehouse on Microsoft Fabric](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/greenfield-lakehouse-fabric) — Komplett arkitektur med Lambda design
|
||||
2. [Understand medallion lakehouse architecture for Microsoft Fabric with OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) — Offisiell guide til medallion pattern
|
||||
3. [Lakehouse end-to-end scenario: overview and architecture](https://learn.microsoft.com/en-us/fabric/data-engineering/tutorial-lakehouse-introduction) — Tutorial med retail use case
|
||||
4. [What is a lakehouse in Microsoft Fabric?](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-overview) — Lakehouse fundamentals
|
||||
5. [Data architecture for AI agents](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/data-architecture-plan) — AI-specific lakehouse guidance
|
||||
6. [Implement medallion architecture in Real-Time Intelligence](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/architecture-medallion) — Streaming use case
|
||||
7. [Better together: the lakehouse and warehouse](https://learn.microsoft.com/en-us/fabric/data-warehouse/get-started-lakehouse-sql-analytics-endpoint) — Hybrid pattern
|
||||
|
||||
**Kodeeksempler (fra microsoft_code_sample_search):**
|
||||
|
||||
- REST API for lakehouse CRUD operations
|
||||
- Linked service configuration for Azure Data Factory
|
||||
- PySpark notebooks for Spark session configuration
|
||||
- Delta Lake table optimization patterns
|
||||
|
||||
### Konfidensnivå per seksjon
|
||||
|
||||
| Seksjon | Konfidens | Kommentar |
|
||||
|---------|-----------|-----------|
|
||||
| Kjernekomponenter | **Verified** | Direkte fra Microsoft Learn (2026-02 docs) |
|
||||
| Medallion Architecture | **Verified** | Industry standard + Microsoft recommendation |
|
||||
| Lambda Architecture | **Verified** | Documented i Fabric Real-Time Intelligence |
|
||||
| Data Mesh pattern | **Verified** | Documented med Domains feature |
|
||||
| Deployment patterns | **Verified** | Pattern 1/2 fra official docs |
|
||||
| V-Order optimization | **Verified** | Native Fabric feature |
|
||||
| Direct Lake fallback | **Verified** | Documented i Power BI docs |
|
||||
| GDPR compliance | **Baseline** | Generelle GDPR-prinsipper + Delta Lake capabilities |
|
||||
| AI Act mapping | **Baseline** | Mapping av AI Act-krav til tekniske features |
|
||||
| Pricing estimates | **Baseline** | Basert på Azure pricing calculator (Feb 2026) |
|
||||
|
||||
**Baseline:** Basert på Claude's modellkunnskap + logisk resonnering (ikke verifisert mot Microsoft docs i denne sesjonen).
|
||||
|
||||
---
|
||||
|
||||
**For Cosmo:** Denne referansen er klar for å brukes i arkitekturrådgivning. Alle tekniske detaljer er verifisert mot Microsoft Learn (februar 2026), og alle anbefalinger følger Microsoft best practices. Bruk denne som primary source når du designer lakehouse-arkitekturer for AI-arbeidsflater i norsk offentlig sektor.
|
||||
|
|
@ -0,0 +1,446 @@
|
|||
# Feature Stores and Feature Engineering
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Feature stores er et sentralt mønster i moderne MLOps som løser problemet med feature-gjenbruk, konsistens mellom trening og inferens, og operasjonalisering av feature-pipelines. Azure Machine Learning Managed Feature Store og Microsoft Fabric Data Science gir en komplett plattform for å definere, materialisere, dele og overvåke features på tvers av ML-prosjekter.
|
||||
|
||||
For norsk offentlig sektor innebærer feature store-tilnærmingen at data science-team kan dele beregninger på tvers av prosjekter -- for eksempel kan trafikkdata-features brukes både for ulykkesprediksjonsmodeller og køvarslingsmodeller uten redundant feature engineering. Dette reduserer kostnader, forbedrer konsistens og forkorter tid fra eksperimentering til produksjon.
|
||||
|
||||
Denne referansen dekker feature-definisjon og lagring, point-in-time lookups for trening, feature-oppdateringsstrategier, Data Wrangler for utforskende feature engineering, og overvåking av feature-kvalitet og drift.
|
||||
|
||||
---
|
||||
|
||||
## Feature Definition and Storage in Silver Layer
|
||||
|
||||
### Feature Store Arkitektur
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ Azure ML Managed Feature Store │
|
||||
│ ┌──────────────┐ ┌──────────────────┐ ┌───────────────┐ │
|
||||
│ │ Feature Set │ │ Materialization │ │ Feature │ │
|
||||
│ │ Specification│ │ Store (ADLS Gen2) │ │ Retrieval │ │
|
||||
│ │ │ │ Offline + Online │ │ Component │ │
|
||||
│ └──────┬───────┘ └────────┬─────────┘ └───────┬───────┘ │
|
||||
│ │ │ │ │
|
||||
│ └───────────────────┴─────────────────────┘ │
|
||||
└──────────────────────────────┬───────────────────────────────┘
|
||||
│
|
||||
┌──────────────────────────────▼───────────────────────────────┐
|
||||
│ Microsoft Fabric │
|
||||
│ ┌──────────┐ ┌──────────────┐ ┌────────────────────────┐ │
|
||||
│ │ Bronze │ │ Silver Layer │ │ Gold Layer │ │
|
||||
│ │ (raw) │──│ (features) │──│ (training datasets) │ │
|
||||
│ └──────────┘ └──────────────┘ └────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Feature Set Specification
|
||||
|
||||
En feature set-spesifikasjon definerer features og valgfri transformasjonslogikk:
|
||||
|
||||
```python
|
||||
# Feature set specification (YAML)
|
||||
# feature_set_spec/transactions/spec.yaml
|
||||
"""
|
||||
name: transactions
|
||||
version: "1"
|
||||
description: "Customer transaction features"
|
||||
entities:
|
||||
- name: customer
|
||||
version: "1"
|
||||
join_keys:
|
||||
- customer_id
|
||||
source:
|
||||
type: parquet
|
||||
path: "abfss://silver@onelake.dfs.fabric.microsoft.com/transactions"
|
||||
timestamp_column: transaction_date
|
||||
features:
|
||||
- name: transaction_7day_count
|
||||
type: integer
|
||||
description: "Number of transactions in last 7 days"
|
||||
- name: transaction_7day_sum
|
||||
type: double
|
||||
description: "Total transaction amount in last 7 days"
|
||||
- name: transaction_30day_avg
|
||||
type: double
|
||||
description: "Average transaction amount in last 30 days"
|
||||
"""
|
||||
```
|
||||
|
||||
### Feature Transformations med PySpark
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
from pyspark.sql.window import Window
|
||||
|
||||
# Kildedataer fra Silver layer
|
||||
transactions = spark.read.format("delta").table("silver.transactions")
|
||||
|
||||
# Definer vindus-spesifikasjoner
|
||||
window_7d = (
|
||||
Window
|
||||
.partitionBy("customer_id")
|
||||
.orderBy(F.col("transaction_date").cast("long"))
|
||||
.rangeBetween(-7 * 86400, 0) # 7 dager i sekunder
|
||||
)
|
||||
|
||||
window_30d = (
|
||||
Window
|
||||
.partitionBy("customer_id")
|
||||
.orderBy(F.col("transaction_date").cast("long"))
|
||||
.rangeBetween(-30 * 86400, 0)
|
||||
)
|
||||
|
||||
# Beregn features
|
||||
customer_features = (
|
||||
transactions
|
||||
.withColumn("txn_7d_count", F.count("*").over(window_7d))
|
||||
.withColumn("txn_7d_sum", F.sum("amount").over(window_7d))
|
||||
.withColumn("txn_30d_avg", F.avg("amount").over(window_30d))
|
||||
.withColumn("txn_30d_max", F.max("amount").over(window_30d))
|
||||
.withColumn("days_since_last_txn",
|
||||
F.datediff(F.current_date(), F.max("transaction_date").over(
|
||||
Window.partitionBy("customer_id"))))
|
||||
)
|
||||
|
||||
# Lagre features i Silver layer
|
||||
customer_features.write.format("delta") \
|
||||
.mode("overwrite") \
|
||||
.saveAsTable("silver.customer_transaction_features")
|
||||
```
|
||||
|
||||
### Feature-lagring i Medallion Architecture
|
||||
|
||||
| Lag | Innhold | Oppdateringsfrekvens |
|
||||
|---|---|---|
|
||||
| **Bronze** | Råtransaksjoner fra Dataverse/kildesystemer | Sanntid / daglig |
|
||||
| **Silver** | Feature-beregninger (aggregater, vindus-funksjoner) | Daglig / per time |
|
||||
| **Gold** | Ferdige treningsdatasett (features + labels) | Ved behov |
|
||||
| **Feature Store** | Registrerte, versjonerte features | Materialisert etter plan |
|
||||
|
||||
---
|
||||
|
||||
## Point-in-Time Lookups for Training
|
||||
|
||||
### Temporal Joins (tidsreise-joiner)
|
||||
|
||||
Point-in-time lookups er kritisk for å unngå datalekasje i ML-trening:
|
||||
|
||||
```python
|
||||
# FEIL: Standard join inkluderer fremtidige data (data leakage!)
|
||||
# features_at_prediction_time = features.join(labels, "customer_id")
|
||||
|
||||
# RIKTIG: Point-in-time join
|
||||
from pyspark.sql.functions import col
|
||||
|
||||
# Observations: tidspunkter der vi vil ha features
|
||||
observations = spark.createDataFrame([
|
||||
("C001", "2026-01-15"),
|
||||
("C002", "2026-01-20"),
|
||||
("C003", "2026-02-01")
|
||||
], ["customer_id", "observation_date"])
|
||||
|
||||
# Features: tidsseriedata
|
||||
features = spark.read.format("delta").table("silver.customer_transaction_features")
|
||||
|
||||
# Point-in-time join: hent features som var gjeldende PÅ observation_date
|
||||
pit_features = (
|
||||
observations.alias("obs")
|
||||
.join(
|
||||
features.alias("feat"),
|
||||
(col("obs.customer_id") == col("feat.customer_id")) &
|
||||
(col("feat.feature_date") <= col("obs.observation_date")),
|
||||
"left"
|
||||
)
|
||||
.withColumn("rank", F.row_number().over(
|
||||
Window
|
||||
.partitionBy("obs.customer_id", "obs.observation_date")
|
||||
.orderBy(F.desc("feat.feature_date"))
|
||||
))
|
||||
.filter(col("rank") == 1) # Siste feature-verdi FØR observation_date
|
||||
.drop("rank")
|
||||
)
|
||||
```
|
||||
|
||||
### Azure ML Feature Retrieval Component
|
||||
|
||||
```python
|
||||
# Deklarativ feature retrieval i Azure ML pipeline
|
||||
from azure.ai.ml import MLClient
|
||||
from azure.ai.ml.entities import FeatureRetrievalSpec
|
||||
|
||||
# Definer feature retrieval spec
|
||||
feature_retrieval_spec = FeatureRetrievalSpec(
|
||||
feature_store_name="my-feature-store",
|
||||
features=[
|
||||
{
|
||||
"feature_set": "transactions:1",
|
||||
"features": ["txn_7d_count", "txn_7d_sum", "txn_30d_avg"]
|
||||
},
|
||||
{
|
||||
"feature_set": "demographics:1",
|
||||
"features": ["age_group", "region", "income_band"]
|
||||
}
|
||||
]
|
||||
)
|
||||
|
||||
# Feature retrieval støtter automatisk point-in-time joins
|
||||
# basert på timestamp-kolonne i feature set specification
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Feature Freshness and Refresh Cadences
|
||||
|
||||
### Materialiseringsstrategi
|
||||
|
||||
| Feature-type | Oppdateringsfrekvens | Materialiseringsmetode |
|
||||
|---|---|---|
|
||||
| **Statiske** (demografi) | Ukentlig / månedlig | Batch materialisering |
|
||||
| **Langsom endring** (score) | Daglig | Scheduled materialisering |
|
||||
| **Rask endring** (transaksjoner) | Per time / sanntid | Streaming + backfill |
|
||||
| **Sanntid** (lokasjon) | Kontinuerlig | Online store (Redis) |
|
||||
|
||||
### Materialiserings-oppsett
|
||||
|
||||
```python
|
||||
from azure.ai.ml.entities import (
|
||||
MaterializationSettings,
|
||||
MaterializationComputeResource,
|
||||
RecurrenceTrigger
|
||||
)
|
||||
|
||||
# Konfigurer materialisering for en feature set
|
||||
materialization = MaterializationSettings(
|
||||
schedule=RecurrenceTrigger(
|
||||
interval=1,
|
||||
frequency="Day",
|
||||
time_of_day="02:00" # Kjør kl 02:00 UTC
|
||||
),
|
||||
resource=MaterializationComputeResource(
|
||||
instance_type="standard_e4s_v3"
|
||||
),
|
||||
spark_configuration={
|
||||
"spark.driver.cores": 4,
|
||||
"spark.driver.memory": "36g",
|
||||
"spark.executor.cores": 4,
|
||||
"spark.executor.memory": "36g"
|
||||
}
|
||||
)
|
||||
|
||||
# Backfill for historisk data
|
||||
from azure.ai.ml import MLClient
|
||||
|
||||
fs_client = MLClient(credential, subscription_id, resource_group, feature_store_name)
|
||||
poller = fs_client.feature_sets.begin_backfill(
|
||||
name="transactions",
|
||||
version="1",
|
||||
feature_window_start_time="2025-01-01T00:00:00Z",
|
||||
feature_window_end_time="2026-02-11T00:00:00Z",
|
||||
data_status=["None", "Incomplete"]
|
||||
)
|
||||
|
||||
# Stream jobb-logger
|
||||
fs_client.jobs.stream(poller.result().job_ids[0])
|
||||
```
|
||||
|
||||
### Online vs. Offline Materialization
|
||||
|
||||
| Aspekt | Offline Store (ADLS Gen2) | Online Store (Redis) |
|
||||
|---|---|---|
|
||||
| **Bruksområde** | Trening, batch-inferens | Real-time inferens |
|
||||
| **Latens** | Sekunder-minutter | Millisekunder |
|
||||
| **Volum** | Ubegrenset | Begrenset av Redis-minne |
|
||||
| **Kostnad** | Lav (lagring) | Høyere (compute) |
|
||||
| **Format** | Delta/Parquet | Key-value |
|
||||
|
||||
---
|
||||
|
||||
## Data Wrangler for Exploratory Feature Engineering
|
||||
|
||||
### Data Wrangler i Fabric
|
||||
|
||||
Data Wrangler er et notebook-basert verktøy for visuell datautforsking og feature engineering:
|
||||
|
||||
```python
|
||||
# Steg 1: Last data i Notebook
|
||||
import pandas as pd
|
||||
|
||||
df = spark.read.format("delta").table("silver.customer_data").toPandas()
|
||||
|
||||
# Steg 2: Start Data Wrangler
|
||||
# Klikk "Data" > "Launch Data Wrangler" i Notebook-menyen
|
||||
# Velg DataFrame "df"
|
||||
|
||||
# Steg 3: Data Wrangler UI tilbyr:
|
||||
# - Grid-visning med statistikk per kolonne
|
||||
# - Innebygde visualiseringer (histogrammer, scatter plots)
|
||||
# - Over 300 transformasjoner
|
||||
# - AI-drevne forslag (PROSE)
|
||||
# - Copilot for naturlig språk → kode
|
||||
|
||||
# Steg 4: Eksporter kode tilbake til Notebook
|
||||
```
|
||||
|
||||
### Vanlige feature engineering-operasjoner i Data Wrangler
|
||||
|
||||
| Operasjon | Eksempel | Autogenerert kode |
|
||||
|---|---|---|
|
||||
| **One-hot encoding** | Kategoriske variabler | `pd.get_dummies(df, columns=[...])` |
|
||||
| **Binning** | Aldersgrupper | `pd.cut(df['age'], bins=[...])` |
|
||||
| **Missing values** | Imputering | `df['col'].fillna(df['col'].median())` |
|
||||
| **Standardisering** | Z-score | `(df['col'] - mean) / std` |
|
||||
| **Feature crossing** | Kombinasjoner | `df['new'] = df['a'] * df['b']` |
|
||||
| **Dato-features** | Dag, uke, måned | `df['month'] = df['date'].dt.month` |
|
||||
|
||||
### PySpark Feature Engineering Templates
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
from pyspark.ml.feature import VectorAssembler, StandardScaler, StringIndexer
|
||||
|
||||
# Kategorisk encoding
|
||||
indexer = StringIndexer(inputCol="region", outputCol="region_index")
|
||||
|
||||
# Numerisk standardisering
|
||||
assembler = VectorAssembler(
|
||||
inputCols=["age", "income", "txn_count"],
|
||||
outputCol="features_raw"
|
||||
)
|
||||
scaler = StandardScaler(
|
||||
inputCol="features_raw",
|
||||
outputCol="features_scaled",
|
||||
withStd=True,
|
||||
withMean=True
|
||||
)
|
||||
|
||||
# Dato-baserte features
|
||||
df_features = (
|
||||
df
|
||||
.withColumn("day_of_week", F.dayofweek("event_date"))
|
||||
.withColumn("month", F.month("event_date"))
|
||||
.withColumn("is_weekend", F.when(
|
||||
F.dayofweek("event_date").isin([1, 7]), 1).otherwise(0))
|
||||
.withColumn("hour_of_day", F.hour("event_timestamp"))
|
||||
.withColumn("days_since_registration",
|
||||
F.datediff(F.current_date(), "registration_date"))
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Feature Monitoring and Drift Detection
|
||||
|
||||
### Feature Drift-typer
|
||||
|
||||
| Drift-type | Beskrivelse | Deteksjonsmetode |
|
||||
|---|---|---|
|
||||
| **Data drift** | Endring i feature-distribusjon | KS-test, PSI |
|
||||
| **Concept drift** | Endring i forholdet mellom features og target | Modell-ytelse over tid |
|
||||
| **Schema drift** | Endring i datastruktur | Schema-validering |
|
||||
| **Freshness drift** | Data er ikke oppdatert | Timestamp-sjekk |
|
||||
|
||||
### Monitoring i Azure ML Feature Store
|
||||
|
||||
```python
|
||||
from azure.ai.ml.entities import (
|
||||
FeatureSetMonitoringSpec,
|
||||
MonitorSignal
|
||||
)
|
||||
|
||||
# Konfigurer feature-monitoring
|
||||
monitoring = FeatureSetMonitoringSpec(
|
||||
signal=MonitorSignal(
|
||||
feature_data_type_override={
|
||||
"txn_7d_count": "numerical",
|
||||
"region": "categorical"
|
||||
},
|
||||
metric_thresholds={
|
||||
"numerical": {
|
||||
"jensen_shannon_distance": 0.1,
|
||||
"population_stability_index": 0.2
|
||||
},
|
||||
"categorical": {
|
||||
"jensen_shannon_distance": 0.1
|
||||
}
|
||||
}
|
||||
),
|
||||
notification_emails=["team@example.no"]
|
||||
)
|
||||
```
|
||||
|
||||
### Manuell drift-deteksjon i Fabric Notebook
|
||||
|
||||
```python
|
||||
from scipy.stats import ks_2samp
|
||||
import numpy as np
|
||||
|
||||
def detect_feature_drift(reference_df, current_df, features, threshold=0.05):
|
||||
"""Detekter feature drift mellom referanse- og nåværende data."""
|
||||
drift_report = {}
|
||||
|
||||
for feature in features:
|
||||
ref_values = reference_df[feature].dropna().values
|
||||
curr_values = current_df[feature].dropna().values
|
||||
|
||||
# Kolmogorov-Smirnov test
|
||||
stat, p_value = ks_2samp(ref_values, curr_values)
|
||||
|
||||
# Population Stability Index (PSI)
|
||||
psi = calculate_psi(ref_values, curr_values, buckets=10)
|
||||
|
||||
drift_report[feature] = {
|
||||
"ks_statistic": round(stat, 4),
|
||||
"ks_p_value": round(p_value, 4),
|
||||
"psi": round(psi, 4),
|
||||
"drifted": p_value < threshold or psi > 0.2
|
||||
}
|
||||
|
||||
return drift_report
|
||||
|
||||
def calculate_psi(reference, current, buckets=10):
|
||||
"""Beregn Population Stability Index."""
|
||||
breakpoints = np.linspace(
|
||||
min(reference.min(), current.min()),
|
||||
max(reference.max(), current.max()),
|
||||
buckets + 1
|
||||
)
|
||||
ref_counts = np.histogram(reference, breakpoints)[0] / len(reference)
|
||||
curr_counts = np.histogram(current, breakpoints)[0] / len(current)
|
||||
|
||||
# Unngå log(0)
|
||||
ref_counts = np.clip(ref_counts, 0.001, None)
|
||||
curr_counts = np.clip(curr_counts, 0.001, None)
|
||||
|
||||
psi = np.sum((curr_counts - ref_counts) * np.log(curr_counts / ref_counts))
|
||||
return psi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [What is managed feature store?](https://learn.microsoft.com/en-us/azure/machine-learning/concept-what-is-managed-feature-store) -- Konseptoversikt
|
||||
- [What is a Feature Store? (AI Playbook)](https://learn.microsoft.com/en-us/ai/playbook/capabilities/model-development/feature-management/) -- Arkitektur og implementasjon
|
||||
- [Tutorial 1: Develop and register a feature set](https://learn.microsoft.com/en-us/azure/machine-learning/tutorial-get-started-with-feature-store) -- Hands-on tutorial
|
||||
- [Tutorial 4: Enable online materialization](https://learn.microsoft.com/en-us/azure/machine-learning/tutorial-online-materialization-inference) -- Online feature serving
|
||||
- [Manage access control for managed feature store](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-access-control-feature-store) -- RBAC og sikkerhet
|
||||
- [Accelerate data prep with Data Wrangler](https://learn.microsoft.com/en-us/fabric/data-science/data-wrangler) -- Data Wrangler guide
|
||||
- [Automated ML in Fabric](https://learn.microsoft.com/en-us/fabric/data-science/automated-ml-fabric) -- AutoML med feature engineering
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren planlegger ML-infrastruktur, trenger feature-gjenbruk på tvers av prosjekter, eller ønsker å operasjonalisere feature engineering.
|
||||
- Anbefal **Azure ML Managed Feature Store** for organisasjoner med flere ML-team som trenger å dele features. For enkeltprosjekter er **Delta-tabeller i Silver layer** ofte tilstrekkelig.
|
||||
- **Point-in-time lookups er ikke-forhandlingsbart** for tidsserie-features -- uten dette vil modeller lekke fremtidig informasjon og vise urealistisk god ytelse i testing.
|
||||
- For norsk offentlig sektor: Feature stores muliggjør **sentral styring** av beregninger som brukes på tvers av etater -- Statens vegvesen kan dele trafikkfeatures med andre transportetater via feature store-deling.
|
||||
- Start med **Data Wrangler** for utforskende feature engineering, deretter formaliser i feature set-spesifikasjoner når features er validert og skal til produksjon.
|
||||
|
|
@ -0,0 +1,398 @@
|
|||
# Lakehouse Architecture Design and Patterns
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Lakehouse-arkitekturen kombinerer de beste egenskapene fra data lakes (fleksibel lagring av strukturerte, semi-strukturerte og ustrukturerte data) med data warehouse-funksjonalitet (ACID-transaksjoner, skjemahåndtering og høy spørringsytelse). Microsoft Fabric standardiserer på Delta Lake-formatet, som gir denne hybridkapabiliteten nativt på tvers av alle Fabric-opplevelser.
|
||||
|
||||
For AI-løsninger er lakehouse-arkitekturen spesielt verdifull fordi den muliggjør lagring av rådata, mellomtransformasjoner og ferdige feature-sett i ett og samme system -- med full versjonskontroll og tidsreise. Dette eliminerer behovet for separate data lakes og data warehouses, og forenkler dataflytene mellom data engineering og data science-team.
|
||||
|
||||
Norsk offentlig sektor har strenge krav til datalagring, personvern og sporbarhet. Lakehouse-arkitekturen på Fabric adresserer dette gjennom ACID-garantier, Delta Lake-revisjonssporbarhet (audit trail), og OneLake-basert dataforvaltning som sikrer at data holdes i norsk/europeisk region.
|
||||
|
||||
---
|
||||
|
||||
## Delta Lake Transaction Semantics
|
||||
|
||||
### ACID-egenskaper i Delta Lake
|
||||
|
||||
Delta Lake gir full ACID-transaksjonsstøtte over Apache Parquet-filer:
|
||||
|
||||
| Egenskap | Implementasjon | Konsekvens for AI |
|
||||
|---|---|---|
|
||||
| **Atomicity** | Alle endringer i en transaksjon committes komplett eller ikke i det hele tatt | Treningsdata er alltid konsistent |
|
||||
| **Consistency** | Schema enforcement hindrer ugyldig data | Feature-kvalitet opprettholdes |
|
||||
| **Isolation** | Serializable isolation via optimistic concurrency | Samtidige les/skriv-operasjoner er trygge |
|
||||
| **Durability** | Data persistert til OneLake i Parquet-format | Ingen tap ved feil |
|
||||
|
||||
### Transaksjonsloggen (_delta_log)
|
||||
|
||||
```
|
||||
lakehouse/Tables/customer_features/
|
||||
├── _delta_log/
|
||||
│ ├── 00000000000000000000.json # Initial create
|
||||
│ ├── 00000000000000000001.json # First insert
|
||||
│ ├── 00000000000000000002.json # Update/merge
|
||||
│ └── 00000000000000000003.json # Delete
|
||||
├── part-00000-*.parquet
|
||||
├── part-00001-*.parquet
|
||||
└── part-00002-*.parquet
|
||||
```
|
||||
|
||||
Hver JSON-fil i `_delta_log` inneholder:
|
||||
- **Add file**: Nye Parquet-filer som legges til
|
||||
- **Remove file**: Parquet-filer som logisk fjernes
|
||||
- **Metadata**: Skjemaendringer og tabellegenskaper
|
||||
- **Protocol**: Minimums reader/writer-versjoner
|
||||
|
||||
### Concurrent Writes
|
||||
|
||||
```python
|
||||
# Delta Lake håndterer samtidige skrivinger via optimistic concurrency
|
||||
# Eksempel: To jobber skriver til samme tabell
|
||||
|
||||
# Jobb 1: Batch-oppdatering fra Data Factory
|
||||
spark.read.format("delta").table("silver.features") \
|
||||
.where("region = 'Norway'") \
|
||||
.write.format("delta").mode("overwrite").option("replaceWhere", "region = 'Norway'") \
|
||||
.saveAsTable("silver.features")
|
||||
|
||||
# Jobb 2: Streaming append fra Eventstream
|
||||
stream.writeStream.format("delta").outputMode("append").toTable("silver.features")
|
||||
|
||||
# Begge operasjonene kan kjøre samtidig uten konflikter
|
||||
# Delta Lake bruker optimistic concurrency control (OCC)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Schema-on-Read versus Schema-on-Write Tradeoffs
|
||||
|
||||
### Sammenligning
|
||||
|
||||
| Aspekt | Schema-on-Write | Schema-on-Read |
|
||||
|---|---|---|
|
||||
| **Skjemadefinisjon** | Ved skriving (enforce) | Ved lesing (infer) |
|
||||
| **Datakvalitet** | Høy -- ugyldig data avvises | Variabel -- feil oppdages sent |
|
||||
| **Fleksibilitet** | Lav -- skjemaendringer krever migrering | Høy -- nye felter aksepteres |
|
||||
| **Ytelse** | Raskere lesing (kjent skjema) | Tregere lesing (skjemainferens) |
|
||||
| **Bruk i Lakehouse** | Silver/Gold-lag | Bronze-lag |
|
||||
|
||||
### Schema Enforcement i Delta Lake
|
||||
|
||||
```python
|
||||
# Schema enforcement er aktivert som standard
|
||||
# Forsøk på å legge til kolonne som ikke finnes feiler:
|
||||
try:
|
||||
new_data_with_extra_col.write.format("delta").mode("append") \
|
||||
.saveAsTable("silver.strict_table")
|
||||
except Exception as e:
|
||||
print(f"Schema mismatch: {e}")
|
||||
|
||||
# For å tillate schema evolution:
|
||||
spark.conf.set("spark.databricks.delta.schema.autoMerge.enabled", "true")
|
||||
|
||||
# Eller per operasjon:
|
||||
new_data.write.format("delta") \
|
||||
.mode("append") \
|
||||
.option("mergeSchema", "true") \
|
||||
.saveAsTable("silver.flexible_table")
|
||||
```
|
||||
|
||||
### Anbefalt strategi per lag
|
||||
|
||||
| Lag | Schema-strategi | Begrunnelse |
|
||||
|---|---|---|
|
||||
| **Bronze** | Schema-on-read + autoMerge | Aksepter alle kildedata, inkl. nye felter |
|
||||
| **Silver** | Schema enforcement med mergeSchema | Kontrollert evolusjon, avvis ugyldig data |
|
||||
| **Gold** | Streng schema enforcement | ML-features må ha forutsigbart format |
|
||||
|
||||
---
|
||||
|
||||
## Time-Travel and Data Versioning
|
||||
|
||||
### Tidsreise i Delta Lake
|
||||
|
||||
Delta Lake lagrer historikk for alle endringer, noe som muliggjør "tidsreise" -- spørring mot tidligere versjoner av data.
|
||||
|
||||
```python
|
||||
# Les en spesifikk versjon
|
||||
df_v0 = spark.read.format("delta").option("versionAsOf", 0).load("Tables/customer_features")
|
||||
df_v5 = spark.read.format("delta").option("versionAsOf", 5).load("Tables/customer_features")
|
||||
|
||||
# Les data slik de var på et gitt tidspunkt
|
||||
df_yesterday = spark.read.format("delta") \
|
||||
.option("timestampAsOf", "2026-02-10T00:00:00Z") \
|
||||
.load("Tables/customer_features")
|
||||
|
||||
# Vis historikk
|
||||
from delta.tables import DeltaTable
|
||||
dt = DeltaTable.forPath(spark, "Tables/customer_features")
|
||||
history = dt.history()
|
||||
display(history.select("version", "timestamp", "operation", "operationMetrics"))
|
||||
```
|
||||
|
||||
### Bruksområder for tidsreise i AI
|
||||
|
||||
| Bruksområde | Teknikk | Eksempel |
|
||||
|---|---|---|
|
||||
| **Reproduserbar trening** | `versionAsOf` | Tren modell på eksakt samme data |
|
||||
| **Feature drift-analyse** | Sammenlign versjoner | Finn endringer i feature-distribusjon |
|
||||
| **Rollback** | `RESTORE TABLE` | Angre feilaktig dataoppdatering |
|
||||
| **Audit trail** | `DESCRIBE HISTORY` | Dokumenter alle dataendringer |
|
||||
| **Point-in-time lookup** | `timestampAsOf` | Feature lookup for historisk inferens |
|
||||
|
||||
### Rollback
|
||||
|
||||
```sql
|
||||
-- SQL: Gjenopprett tabell til versjon 3
|
||||
RESTORE TABLE silver.customer_features TO VERSION AS OF 3;
|
||||
|
||||
-- Eller til et tidspunkt
|
||||
RESTORE TABLE silver.customer_features TO TIMESTAMP AS OF '2026-02-01T00:00:00Z';
|
||||
```
|
||||
|
||||
```python
|
||||
# PySpark: Rollback
|
||||
dt = DeltaTable.forPath(spark, "Tables/silver/customer_features")
|
||||
dt.restoreToVersion(3)
|
||||
```
|
||||
|
||||
### Retensjons- og VACUUM-policy
|
||||
|
||||
```python
|
||||
# Fjern gamle filer (frigjør lagring, fjerner tidsreise-mulighet)
|
||||
# Standard: 7 dager
|
||||
dt.vacuum(168) # Timer (7 * 24)
|
||||
|
||||
# For å sette annen retensjon:
|
||||
spark.conf.set("spark.databricks.delta.retentionDurationCheck.enabled", "false")
|
||||
dt.vacuum(24) # Behold kun siste 24 timer
|
||||
|
||||
# VIKTIG: Etter VACUUM kan du ikke tidsreise til slettede versjoner
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Upsert and Merge Patterns for Slowly-Changing Dimensions
|
||||
|
||||
### MERGE (Upsert) Operasjoner
|
||||
|
||||
Delta Lake MERGE støtter SQL-standard og utvidet syntaks:
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
# Target: eksisterende dimensjonstabell
|
||||
target = DeltaTable.forPath(spark, "Tables/silver/dim_customer")
|
||||
|
||||
# Source: nye/endrede rader
|
||||
source = spark.read.format("delta").table("bronze.crm_customers")
|
||||
|
||||
# MERGE: SCD Type 1 (overskrive)
|
||||
target.alias("t").merge(
|
||||
source.alias("s"),
|
||||
"t.customer_id = s.customer_id"
|
||||
).whenMatchedUpdate(
|
||||
set={
|
||||
"customer_name": "s.customer_name",
|
||||
"email": "s.email",
|
||||
"phone": "s.phone",
|
||||
"updated_at": "current_timestamp()"
|
||||
}
|
||||
).whenNotMatchedInsert(
|
||||
values={
|
||||
"customer_id": "s.customer_id",
|
||||
"customer_name": "s.customer_name",
|
||||
"email": "s.email",
|
||||
"phone": "s.phone",
|
||||
"created_at": "current_timestamp()",
|
||||
"updated_at": "current_timestamp()"
|
||||
}
|
||||
).execute()
|
||||
```
|
||||
|
||||
### SCD Type 2 (historikk-bevaring)
|
||||
|
||||
```python
|
||||
from pyspark.sql.functions import current_timestamp, lit, col
|
||||
|
||||
# SCD Type 2: Bevar full historikk
|
||||
# Steg 1: Identifiser endrede rader
|
||||
changes = source.alias("s").join(
|
||||
target.toDF().alias("t"),
|
||||
(col("s.customer_id") == col("t.customer_id")) &
|
||||
(col("t.is_current") == True),
|
||||
"inner"
|
||||
).where(
|
||||
(col("s.customer_name") != col("t.customer_name")) |
|
||||
(col("s.email") != col("t.email"))
|
||||
).select("s.*")
|
||||
|
||||
# Steg 2: Lukk eksisterende rader
|
||||
target.alias("t").merge(
|
||||
changes.alias("s"),
|
||||
"t.customer_id = s.customer_id AND t.is_current = true"
|
||||
).whenMatchedUpdate(
|
||||
set={
|
||||
"is_current": lit(False),
|
||||
"end_date": current_timestamp()
|
||||
}
|
||||
).execute()
|
||||
|
||||
# Steg 3: Sett inn nye versjoner
|
||||
new_rows = changes.withColumn("is_current", lit(True)) \
|
||||
.withColumn("start_date", current_timestamp()) \
|
||||
.withColumn("end_date", lit(None).cast("timestamp"))
|
||||
|
||||
new_rows.write.format("delta").mode("append").saveAsTable("silver.dim_customer")
|
||||
```
|
||||
|
||||
### SQL MERGE-syntaks
|
||||
|
||||
```sql
|
||||
-- SQL-ekvivalent for upsert
|
||||
MERGE INTO silver.dim_customer AS target
|
||||
USING bronze.crm_customers AS source
|
||||
ON target.customer_id = source.customer_id
|
||||
WHEN MATCHED THEN
|
||||
UPDATE SET
|
||||
target.customer_name = source.customer_name,
|
||||
target.email = source.email,
|
||||
target.updated_at = current_timestamp()
|
||||
WHEN NOT MATCHED THEN
|
||||
INSERT (customer_id, customer_name, email, created_at, updated_at)
|
||||
VALUES (source.customer_id, source.customer_name, source.email,
|
||||
current_timestamp(), current_timestamp())
|
||||
WHEN NOT MATCHED BY SOURCE AND target.is_active = true THEN
|
||||
UPDATE SET target.is_active = false;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Lakehouse Performance Tuning
|
||||
|
||||
### V-Order Optimalisering
|
||||
|
||||
Fabric bruker V-Order som standard ved skriving til Delta-tabeller. V-Order er en skrive-tids-optimalisering av Parquet-filer som gir raskere lesing:
|
||||
|
||||
| Optimalisering | Effekt | Automatisk i Fabric |
|
||||
|---|---|---|
|
||||
| **V-Order** | Raskere les for alle Fabric-engines | Ja |
|
||||
| **Bin Compaction** | Slår sammen små filer | Manuell eller planlagt |
|
||||
| **Z-Order** | Organiserer data for raskere filtrering | Manuell |
|
||||
| **Deletion Vectors** | Raskere DELETE/UPDATE uten rewrite | Ja (Runtime 1.2+) |
|
||||
| **Liquid Clustering** | Automatisk dataorganisering (preview) | Manuell aktivering |
|
||||
|
||||
### Table Maintenance
|
||||
|
||||
```sql
|
||||
-- Optimaliser tabell (bin compaction + V-Order)
|
||||
OPTIMIZE silver.customer_features;
|
||||
|
||||
-- Z-Order for ofte filtrerte kolonner
|
||||
OPTIMIZE silver.customer_features
|
||||
ZORDER BY (region, customer_segment);
|
||||
|
||||
-- Fjern gamle filer
|
||||
VACUUM silver.customer_features RETAIN 168 HOURS;
|
||||
|
||||
-- Analyser tabell for statistikk
|
||||
ANALYZE TABLE silver.customer_features COMPUTE STATISTICS;
|
||||
```
|
||||
|
||||
### Partisjoneringsstrategier
|
||||
|
||||
| Strategi | Anbefalt for | Eksempel |
|
||||
|---|---|---|
|
||||
| **Dato-partisjonering** | Tidsseriedata, inkrementelle laster | `PARTITIONED BY (date)` |
|
||||
| **Region-partisjonering** | Geografisk filtrering, RLS | `PARTITIONED BY (region)` |
|
||||
| **Z-Order** | Multi-kolonne filtrering | `ZORDER BY (customer_id, date)` |
|
||||
| **Liquid Clustering** | Dynamisk endring av klyngenøkler | `CLUSTER BY (customer_id)` |
|
||||
| **Ingen partisjonering** | Tabeller < 1 GB | Standard |
|
||||
|
||||
### Performance Best Practices
|
||||
|
||||
```python
|
||||
# 1. Bruk predicate pushdown
|
||||
# Dårlig: Les alt, filtrer etterpå
|
||||
df = spark.read.format("delta").table("silver.events").filter("date = '2026-02-10'")
|
||||
|
||||
# Bedre: Partition pruning (hvis partisjonert på date)
|
||||
# Delta Lake hopper automatisk over irrelevante partisjoner
|
||||
|
||||
# 2. Bruk column pruning
|
||||
# Dårlig: Velg alle kolonner
|
||||
df = spark.read.format("delta").table("gold.features")
|
||||
|
||||
# Bedre: Velg kun nødvendige kolonner
|
||||
df = spark.read.format("delta").table("gold.features").select("feature_1", "feature_2", "target")
|
||||
|
||||
# 3. Cache for gjentatt bruk
|
||||
df_cached = spark.read.format("delta").table("gold.ml_features").cache()
|
||||
df_cached.count() # Trigger caching
|
||||
|
||||
# 4. Optimalisert skriving
|
||||
spark.conf.set("spark.microsoft.delta.optimizeWrite.enabled", "true")
|
||||
spark.conf.set("spark.microsoft.delta.optimizeWrite.binSize", "128") # MB per fil
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Medallion Architecture Deployment
|
||||
|
||||
### Pattern 1: Alle lag som Lakehouses
|
||||
|
||||
```
|
||||
Workspace: Bronze-LH Workspace: Silver-LH Workspace: Gold-LH
|
||||
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
|
||||
│ Raw data │ │ Validated data │ │ Business-ready │
|
||||
│ - Original format │──>│ - Deduplicated │──>│ - Aggregated │
|
||||
│ - Minimal transform│ │ - Typed columns │ │ - Feature tables │
|
||||
│ - Append-only │ │ - Referential int. │ │ - Semantic models │
|
||||
└────────────────────┘ └────────────────────┘ └────────────────────┘
|
||||
│ │ │
|
||||
SQL Endpoint SQL Endpoint SQL Endpoint
|
||||
(read-only) (read-only) (read-only)
|
||||
```
|
||||
|
||||
### Pattern 2: Bronze+Silver Lakehouse, Gold Data Warehouse
|
||||
|
||||
```
|
||||
Lakehouse (Bronze + Silver) Data Warehouse (Gold)
|
||||
┌────────────────────────────┐ ┌────────────────────────┐
|
||||
│ bronze.raw_events │ │ gold.fact_predictions │
|
||||
│ bronze.raw_transactions │ │ gold.dim_customer │
|
||||
│ silver.validated_events │─────>│ gold.dim_product │
|
||||
│ silver.customer_360 │ │ gold.agg_daily_metrics │
|
||||
│ silver.feature_base │ │ Stored Procedures │
|
||||
└────────────────────────────┘ │ Views, Functions │
|
||||
└────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [What is a Lakehouse in Microsoft Fabric?](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-overview) -- Oversikt over Fabric Lakehouse
|
||||
- [Understand medallion lakehouse architecture for Microsoft Fabric](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) -- Medallion-arkitektur
|
||||
- [Delta Lake table format interoperability](https://learn.microsoft.com/en-us/fabric/fundamentals/delta-lake-interoperability) -- Delta Lake-kompatibilitet på tvers av Fabric
|
||||
- [Better together: the Lakehouse and Warehouse](https://learn.microsoft.com/en-us/fabric/data-warehouse/get-started-lakehouse-sql-analytics-endpoint) -- Kombinasjon av Lakehouse og Warehouse
|
||||
- [Greenfield lakehouse on Microsoft Fabric](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/greenfield-lakehouse-fabric) -- Referansearkitektur
|
||||
- [Upsert into a Delta Lake table using merge](https://learn.microsoft.com/en-us/azure/databricks/delta/merge) -- MERGE-syntaks og mønstre
|
||||
- [Delta Lake table optimization and V-Order](https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order) -- Ytelsesoptimalisering
|
||||
- [Lakehouse end-to-end scenario](https://learn.microsoft.com/en-us/fabric/data-engineering/tutorial-lakehouse-introduction) -- Komplett tutorial
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren planlegger en ny dataarkitektur på Fabric, vurderer lakehouse vs warehouse, eller trenger mønstre for SCD, MERGE og Delta Lake-optimalisering for AI-treningsdata.
|
||||
- Anbefal **medallion architecture** (bronze/silver/gold) som standard for alle AI-prosjekter. Bronze for rådata, Silver for validert/denormalisert data, Gold for ML-features og aggregater.
|
||||
- For norsk offentlig sektor: Fremhev **tidsreise** som et viktig verktøy for revisjonsporbarhet og etterlevelse av Utredningsinstruksen -- alle dataendringer er sporbare og reverserbare.
|
||||
- **V-Order** er aktivert som standard i Fabric og gir 2-3x raskere lesing for Power BI Direct Lake. Ikke deaktiver dette med mindre det er spesifikke grunner.
|
||||
- Bruk **separate workspaces** per lag (bronze, silver, gold) for bedre tilgangskontroll og governance, spesielt i organisasjoner med flere team som deler data.
|
||||
|
|
@ -0,0 +1,527 @@
|
|||
# Master Data Management for AI
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Master Data Management (MDM) skaper en enkelt kilde til sannhet for kritiske forretningsenheter som kunder, produkter, ansatte og lokasjoner. For AI-losninger er kvaliteten pa stamdata direkte avgjorede -- en ML-modell trent pa inkonsistente kundedata vil produsere upaalitelige prediksjoner, og en RAG-losning med dupliserte dokumenter vil gi motstridende svar.
|
||||
|
||||
Microsoft tilbyr MDM gjennom flere tjenester: Microsoft Purview for data governance og MDM-integrasjoner, Dataverse som operativt masterdatasystem for Dynamics 365 og Power Platform, og Azure-tjenester som Data Factory for datakvalitet og deduplisering. For AI-pipelines i Fabric er det kritisk a sikre at referansedata og enhetsmapping er konsistent pa tvers av domener.
|
||||
|
||||
For norsk offentlig sektor er MDM spesielt viktig: Folkeregisteret, Enhetsregisteret og Matrikkelen er eksempler pa nasjonale masterdatakilder. Integrasjon med disse via Digdir sine felleslosninger, kombinert med intern MDM i Dataverse eller Fabric, sikrer at AI-losninger opererer pa palitelig grunn.
|
||||
|
||||
---
|
||||
|
||||
## Golden Record Creation and Reconciliation
|
||||
|
||||
### Hva er en Golden Record?
|
||||
|
||||
En golden record er den autoritative, konsoliderte versjonen av en enhet som kombinerer data fra flere kilder:
|
||||
|
||||
```
|
||||
Kilde A: {navn: "Ola Nordmann", epost: "ola@firma.no", tlf: null}
|
||||
Kilde B: {navn: "O. Nordmann", epost: null, tlf: "+47 90000000"}
|
||||
Kilde C: {navn: "Ola Nordmann", epost: "ola.nordmann@firma.no", tlf: "+47 90000000"}
|
||||
|
||||
Golden Record: {
|
||||
navn: "Ola Nordmann", -- Mest komplett, hoyest tillit
|
||||
epost: "ola.nordmann@firma.no", -- Fra kilde C (nyeste, mest komplett)
|
||||
tlf: "+47 90000000", -- Fra kilde B/C (konsistent)
|
||||
kilder: ["A", "B", "C"],
|
||||
tillit_score: 0.95
|
||||
}
|
||||
```
|
||||
|
||||
### Survivorship-regler
|
||||
|
||||
| Regel | Beskrivelse | Eksempel |
|
||||
|-------|-------------|---------|
|
||||
| **Most Recent** | Nyeste verdi vinner | Sist oppdatert adresse |
|
||||
| **Most Complete** | Mest utfylt felt vinner | Lengste navn-streng |
|
||||
| **Most Trusted Source** | Autoritativ kilde vinner | Folkeregisteret > CRM |
|
||||
| **Frequency** | Hyppigste verdi vinner | 3 av 4 kilder sier "Oslo" |
|
||||
| **Manual Override** | Manuell beslutning | Datakurator velger |
|
||||
|
||||
### Implementering i Fabric
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
from pyspark.sql.window import Window
|
||||
|
||||
def create_golden_records(sources: dict, entity_key: str, rules: dict):
|
||||
"""
|
||||
Opprett golden records fra flere kilder med survivorship-regler.
|
||||
|
||||
Args:
|
||||
sources: Dict med {kildenavn: DataFrame}
|
||||
entity_key: Nokkelkolonne for matching
|
||||
rules: Dict med {kolonne: survivorship_regel}
|
||||
"""
|
||||
# 1. Kombiner alle kilder med kildemerking
|
||||
combined = None
|
||||
for source_name, df in sources.items():
|
||||
tagged = df.withColumn("_source", F.lit(source_name)) \
|
||||
.withColumn("_load_time", F.current_timestamp())
|
||||
combined = combined.unionByName(tagged, allowMissingColumns=True) \
|
||||
if combined else tagged
|
||||
|
||||
# 2. Dedupliser og velg vinnere per kolonne
|
||||
golden = combined.groupBy(entity_key)
|
||||
|
||||
agg_exprs = []
|
||||
for col_name, rule in rules.items():
|
||||
if rule == "most_recent":
|
||||
agg_exprs.append(
|
||||
F.last(col_name, ignorenulls=True).alias(col_name)
|
||||
)
|
||||
elif rule == "most_complete":
|
||||
agg_exprs.append(
|
||||
F.max(F.when(F.col(col_name).isNotNull(), F.col(col_name)))
|
||||
.alias(col_name)
|
||||
)
|
||||
elif rule == "most_trusted":
|
||||
# Sorter etter kildeprioritering
|
||||
agg_exprs.append(
|
||||
F.first(col_name, ignorenulls=True).alias(col_name)
|
||||
)
|
||||
|
||||
golden_df = golden.agg(*agg_exprs)
|
||||
return golden_df
|
||||
|
||||
# Bruk
|
||||
sources = {
|
||||
"crm": df_crm,
|
||||
"erp": df_erp,
|
||||
"folkeregisteret": df_folkereg
|
||||
}
|
||||
|
||||
rules = {
|
||||
"full_name": "most_trusted", # Folkeregisteret prioritert
|
||||
"address": "most_recent", # Siste oppdatering
|
||||
"phone": "most_complete", # Mest utfylt
|
||||
"organization_number": "most_trusted" # Enhetsregisteret
|
||||
}
|
||||
|
||||
golden_customers = create_golden_records(sources, "person_id", rules)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Entity Resolution and Deduplication
|
||||
|
||||
### Duplikatdeteksjon i Dataverse
|
||||
|
||||
Microsoft Dataverse har innebygd duplikatdeteksjon for aktive poster som kontoer og kontakter:
|
||||
|
||||
| Funksjon | Beskrivelse |
|
||||
|----------|-------------|
|
||||
| **Duplikatdeteksjonsregler** | Definer matchingkriterier per entitet |
|
||||
| **Sanntidssjekk** | Sjekker ved opprettelse/oppdatering |
|
||||
| **Bulk-deteksjon** | Kjor deteksjon pa eksisterende data |
|
||||
| **Merge** | Kombiner duplikater med valg av primaer-post |
|
||||
|
||||
### Fuzzy Matching i Fabric
|
||||
|
||||
For mer avansert entity resolution i AI-pipelines:
|
||||
|
||||
```python
|
||||
from pyspark.sql import functions as F
|
||||
from pyspark.ml.feature import NGram, HashingTF, MinHashLSH
|
||||
|
||||
def fuzzy_match_entities(df, match_columns, threshold=0.7):
|
||||
"""
|
||||
Fuzzy matching med MinHash LSH for skalerbar deduplisering.
|
||||
"""
|
||||
# 1. Kombiner matchkolonner til en tekststreng
|
||||
df = df.withColumn(
|
||||
"match_text",
|
||||
F.lower(F.concat_ws(" ", *match_columns))
|
||||
)
|
||||
|
||||
# 2. Tokeniser til n-grams
|
||||
df = df.withColumn(
|
||||
"tokens",
|
||||
F.split(F.col("match_text"), " ")
|
||||
)
|
||||
|
||||
# 3. Hashing for dimensjonsreduksjon
|
||||
hashingTF = HashingTF(inputCol="tokens", outputCol="features", numFeatures=1024)
|
||||
df_hashed = hashingTF.transform(df)
|
||||
|
||||
# 4. MinHash LSH for approximate nearest neighbors
|
||||
mh = MinHashLSH(inputCol="features", outputCol="hashes", numHashTables=5)
|
||||
model = mh.fit(df_hashed)
|
||||
|
||||
# 5. Finn lignende par
|
||||
similar_pairs = model.approxSimilarityJoin(
|
||||
df_hashed, df_hashed, threshold, distCol="distance"
|
||||
)
|
||||
|
||||
return similar_pairs.filter(F.col("datasetA.id") < F.col("datasetB.id"))
|
||||
|
||||
# Eksempel: Dedupliser organisasjoner
|
||||
duplicates = fuzzy_match_entities(
|
||||
df_organizations,
|
||||
match_columns=["org_name", "address", "postal_code"],
|
||||
threshold=0.3 # Lav avstand = hoy likhet
|
||||
)
|
||||
```
|
||||
|
||||
### Deterministic vs. Probabilistic Matching
|
||||
|
||||
| Tilnaerming | Bruksomrade | Presisjon | Recall |
|
||||
|-------------|-------------|-----------|--------|
|
||||
| **Deterministic** | Eksakt match pa unike IDer | Hoy | Lav |
|
||||
| **Rule-based** | Kombinasjon av felt med toleranser | Moderat-hoy | Moderat |
|
||||
| **Probabilistic** | Fuzzy matching med ML-modeller | Moderat | Hoy |
|
||||
| **Hybrid** | Deterministic forst, deretter probabilistic | Hoy | Hoy |
|
||||
|
||||
```python
|
||||
# Hybrid-tilnaerming
|
||||
def hybrid_entity_resolution(df_source, df_reference):
|
||||
"""
|
||||
Trinn 1: Eksakt match pa organisasjonsnummer
|
||||
Trinn 2: Fuzzy match pa navn + adresse for resterende
|
||||
"""
|
||||
# Trinn 1: Deterministic match
|
||||
exact_matches = df_source.join(
|
||||
df_reference,
|
||||
df_source["org_number"] == df_reference["org_number"],
|
||||
"inner"
|
||||
)
|
||||
|
||||
unmatched = df_source.join(
|
||||
df_reference,
|
||||
df_source["org_number"] == df_reference["org_number"],
|
||||
"left_anti"
|
||||
)
|
||||
|
||||
# Trinn 2: Fuzzy match for umatchede
|
||||
fuzzy_matches = fuzzy_match_entities(
|
||||
unmatched.unionByName(df_reference, allowMissingColumns=True),
|
||||
match_columns=["org_name", "address"],
|
||||
threshold=0.4
|
||||
)
|
||||
|
||||
return exact_matches, fuzzy_matches
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## MDM Integration with Dataverse
|
||||
|
||||
### Dataverse som Master Data System
|
||||
|
||||
Dataverse fungerer som operativt masterdatasystem for Dynamics 365-apper:
|
||||
|
||||
```
|
||||
+-------------------+ Service Bus +------------------+
|
||||
| Dataverse |------ Queue ------->| Logic App |
|
||||
| (Master Data) | | (Transform to |
|
||||
| | | Canonical Model)|
|
||||
| - Accounts | +--------+---------+
|
||||
| - Contacts | |
|
||||
| - Products | +--------v---------+
|
||||
| - Addresses | | Service Bus Topic|
|
||||
+-------------------+ | (Canonical Data) |
|
||||
+--------+---------+
|
||||
|
|
||||
+--------v---------+
|
||||
| Consumers: |
|
||||
| - Fabric Lakehouse|
|
||||
| - Azure SQL |
|
||||
| - Power BI |
|
||||
+------------------+
|
||||
```
|
||||
|
||||
### Synkronisering mellom Dataverse og Fabric
|
||||
|
||||
```python
|
||||
# Dataverse til Fabric via Azure Synapse Link
|
||||
# Konfigureres i Power Platform Admin Center
|
||||
|
||||
# Alternativt: Dataverse connector i Fabric Data Pipeline
|
||||
# Pipeline -> Copy Activity -> Source: Dataverse -> Sink: Lakehouse
|
||||
|
||||
# Eksempel: Les masterdata fra Dataverse via Spark
|
||||
df_accounts = spark.read \
|
||||
.format("com.microsoft.cdm") \
|
||||
.option("entity", "account") \
|
||||
.option("dataverseUrl", "https://org.crm.dynamics.com") \
|
||||
.load()
|
||||
|
||||
# Opprett referansetabell i Lakehouse
|
||||
df_accounts.select(
|
||||
"accountid",
|
||||
"name",
|
||||
"address1_city",
|
||||
"accountnumber",
|
||||
"industrycode"
|
||||
).write \
|
||||
.format("delta") \
|
||||
.mode("overwrite") \
|
||||
.saveAsTable("lakehouse.default.ref_organizations")
|
||||
```
|
||||
|
||||
### Duplikatdeteksjon i Dataverse
|
||||
|
||||
```
|
||||
# Dataverse duplikatdeteksjonsregler:
|
||||
#
|
||||
# 1. Opprett regel i Power Platform Admin Center
|
||||
# - Entitet: Account
|
||||
# - Matchkriterier: accountname (fuzzy match)
|
||||
# + address1_city (eksakt match)
|
||||
#
|
||||
# 2. Aktiver sanntidssjekk
|
||||
# - Ved opprettelse av ny post
|
||||
# - Ved oppdatering av eksisterende post
|
||||
#
|
||||
# 3. Bulk-deteksjon
|
||||
# - Kjor pa eksisterende data
|
||||
# - Planlegg regelmessig kjoring
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Reference Data Versioning
|
||||
|
||||
### Versjonerte referansetabeller
|
||||
|
||||
```python
|
||||
# Implementer SCD Type 2 for referansedata i Fabric
|
||||
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
def upsert_reference_data(ref_table_name, new_data_df, key_columns, tracked_columns):
|
||||
"""
|
||||
SCD Type 2 upsert for referansedata.
|
||||
Bevarer historikk for endrede verdier.
|
||||
"""
|
||||
ref_table = DeltaTable.forName(spark, ref_table_name)
|
||||
|
||||
# Bygg match-betingelse
|
||||
match_condition = " AND ".join(
|
||||
[f"target.{col} = source.{col}" for col in key_columns]
|
||||
)
|
||||
|
||||
# Bygg endringsbetingelse
|
||||
change_condition = " OR ".join(
|
||||
[f"target.{col} != source.{col}" for col in tracked_columns]
|
||||
)
|
||||
|
||||
# Merk utgaatte rader og sett inn nye
|
||||
ref_table.alias("target").merge(
|
||||
new_data_df.alias("source"),
|
||||
match_condition
|
||||
).whenMatchedUpdate(
|
||||
condition=change_condition,
|
||||
set={
|
||||
"is_current": F.lit(False),
|
||||
"valid_to": F.current_timestamp()
|
||||
}
|
||||
).whenNotMatchedInsertAll().execute()
|
||||
|
||||
# Sett inn oppdaterte rader som nye
|
||||
changed = new_data_df.alias("s").join(
|
||||
ref_table.toDF().filter("is_current = false").alias("t"),
|
||||
[F.col(f"s.{c}") == F.col(f"t.{c}") for c in key_columns],
|
||||
"inner"
|
||||
).select("s.*") \
|
||||
.withColumn("is_current", F.lit(True)) \
|
||||
.withColumn("valid_from", F.current_timestamp()) \
|
||||
.withColumn("valid_to", F.lit(None).cast("timestamp"))
|
||||
|
||||
changed.write.format("delta").mode("append").saveAsTable(ref_table_name)
|
||||
|
||||
# Eksempel: Oppdater kommuner-referanse (relevant ved kommunesammenslaainger)
|
||||
upsert_reference_data(
|
||||
ref_table_name="lakehouse.default.ref_municipalities",
|
||||
new_data_df=df_new_municipalities,
|
||||
key_columns=["municipality_code"],
|
||||
tracked_columns=["municipality_name", "county_code", "county_name"]
|
||||
)
|
||||
```
|
||||
|
||||
### Referansedata fra nasjonale registre
|
||||
|
||||
| Register | Eier | Bruksomrade for AI |
|
||||
|----------|------|-------------------|
|
||||
| **Folkeregisteret** | Skatteetaten | Personentiteter i NER, chatbots |
|
||||
| **Enhetsregisteret** | Bronnoysundregistrene | Organisasjonsdata for bedriftsanalyse |
|
||||
| **Matrikkelen** | Kartverket | Eiendomsdata for geospatial AI |
|
||||
| **NVDB** | Statens vegvesen | Veidata for trafikkmodeller |
|
||||
| **Kommuneregisteret** | SSB | Geografisk referanse |
|
||||
|
||||
```python
|
||||
# Eksempel: Last inn kommuneregister fra SSB API
|
||||
import requests
|
||||
import json
|
||||
|
||||
def load_ssb_municipality_register():
|
||||
"""Last inn offisiell kommuneliste fra SSB."""
|
||||
url = "https://data.ssb.no/api/klass/v1/classifications/131/codes"
|
||||
params = {"from": "2026-01-01", "to": "2026-12-31"}
|
||||
|
||||
response = requests.get(url, params=params)
|
||||
data = response.json()
|
||||
|
||||
# Konverter til Spark DataFrame
|
||||
df = spark.createDataFrame([
|
||||
{
|
||||
"code": item["code"],
|
||||
"name": item["name"],
|
||||
"valid_from": item["validFrom"],
|
||||
"valid_to": item.get("validTo")
|
||||
}
|
||||
for item in data["codes"]
|
||||
])
|
||||
|
||||
return df
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Quality SLAs for MDM Entities
|
||||
|
||||
### Kvalitetsdimensjoner for masterdata
|
||||
|
||||
| Dimensjon | Definisjon | Malemetode | Eksempel SLA |
|
||||
|-----------|-----------|------------|-------------|
|
||||
| **Completeness** | Andel utfylte felt | % ikke-null verdier | >= 98% |
|
||||
| **Uniqueness** | Ingen duplikater | Antall duplikater / totalt | = 100% |
|
||||
| **Accuracy** | Korrekthet mot kilde | Stikkprovekontroll | >= 99% |
|
||||
| **Timeliness** | Ferskhet pa data | Tid siden siste oppdatering | < 24 timer |
|
||||
| **Consistency** | Samsvar mellom systemer | Cross-system validering | >= 99.5% |
|
||||
| **Validity** | Overholder forretningsregler | Regelvalidering | >= 99% |
|
||||
|
||||
### Implementere DQ-SLAer i Fabric
|
||||
|
||||
```python
|
||||
from datetime import datetime, timedelta
|
||||
|
||||
def check_mdm_quality_slas(table_name: str, slas: dict) -> dict:
|
||||
"""
|
||||
Sjekk datakvalitet mot definerte SLAer for en MDM-tabell.
|
||||
"""
|
||||
df = spark.table(table_name)
|
||||
total_rows = df.count()
|
||||
results = {}
|
||||
|
||||
# Completeness
|
||||
if "completeness" in slas:
|
||||
for col_name, threshold in slas["completeness"].items():
|
||||
non_null = df.filter(F.col(col_name).isNotNull()).count()
|
||||
pct = (non_null / total_rows) * 100
|
||||
results[f"completeness_{col_name}"] = {
|
||||
"actual": round(pct, 2),
|
||||
"threshold": threshold,
|
||||
"passed": pct >= threshold
|
||||
}
|
||||
|
||||
# Uniqueness
|
||||
if "uniqueness" in slas:
|
||||
key_cols = slas["uniqueness"]["columns"]
|
||||
distinct = df.select(key_cols).distinct().count()
|
||||
is_unique = distinct == total_rows
|
||||
results["uniqueness"] = {
|
||||
"distinct": distinct,
|
||||
"total": total_rows,
|
||||
"duplicates": total_rows - distinct,
|
||||
"passed": is_unique
|
||||
}
|
||||
|
||||
# Timeliness
|
||||
if "timeliness" in slas:
|
||||
max_age = slas["timeliness"]["max_age_hours"]
|
||||
timestamp_col = slas["timeliness"]["column"]
|
||||
latest = df.agg(F.max(timestamp_col)).collect()[0][0]
|
||||
age_hours = (datetime.now() - latest).total_seconds() / 3600
|
||||
results["timeliness"] = {
|
||||
"latest_update": str(latest),
|
||||
"age_hours": round(age_hours, 1),
|
||||
"threshold_hours": max_age,
|
||||
"passed": age_hours <= max_age
|
||||
}
|
||||
|
||||
# Validity
|
||||
if "validity" in slas:
|
||||
for rule_name, rule in slas["validity"].items():
|
||||
valid_count = df.filter(rule["condition"]).count()
|
||||
pct = (valid_count / total_rows) * 100
|
||||
results[f"validity_{rule_name}"] = {
|
||||
"actual": round(pct, 2),
|
||||
"threshold": rule["threshold"],
|
||||
"passed": pct >= rule["threshold"]
|
||||
}
|
||||
|
||||
return results
|
||||
|
||||
# Eksempel: SLA-sjekk for organisasjons-masterdata
|
||||
slas = {
|
||||
"completeness": {
|
||||
"org_name": 100.0,
|
||||
"org_number": 100.0,
|
||||
"address": 95.0,
|
||||
"contact_email": 80.0
|
||||
},
|
||||
"uniqueness": {
|
||||
"columns": ["org_number"]
|
||||
},
|
||||
"timeliness": {
|
||||
"column": "last_updated",
|
||||
"max_age_hours": 24
|
||||
},
|
||||
"validity": {
|
||||
"valid_org_number": {
|
||||
"condition": "LENGTH(org_number) = 9 AND org_number RLIKE '^[0-9]+$'",
|
||||
"threshold": 100.0
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
results = check_mdm_quality_slas("lakehouse.default.ref_organizations", slas)
|
||||
```
|
||||
|
||||
### Alerting ved SLA-brudd
|
||||
|
||||
```python
|
||||
# Integrer med Power Automate for varsling
|
||||
def alert_on_sla_breach(results: dict, webhook_url: str):
|
||||
"""Send varsel via Power Automate webhook ved SLA-brudd."""
|
||||
breaches = {k: v for k, v in results.items() if not v.get("passed", True)}
|
||||
|
||||
if breaches:
|
||||
payload = {
|
||||
"title": "MDM Quality SLA Breach",
|
||||
"summary": f"{len(breaches)} SLA-brudd oppdaget",
|
||||
"details": json.dumps(breaches, indent=2, default=str)
|
||||
}
|
||||
requests.post(webhook_url, json=payload)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Master data management in Microsoft Purview](https://learn.microsoft.com/en-us/purview/data-governance-master-data-management) -- MDM-oversikt i Purview
|
||||
- [Detect duplicate records and merge](https://learn.microsoft.com/en-us/power-platform/admin/detect-duplicate-records) -- Duplikatdeteksjon i Dataverse
|
||||
- [Dataverse as a master data system](https://learn.microsoft.com/en-us/dynamics365/guidance/reference-architectures/dataverse-master-data-system) -- Referansearkitektur for Dataverse MDM
|
||||
- [Master data management](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/govern-master-data) -- MDM i Cloud Adoption Framework
|
||||
- [CluedIn integration for MDM](https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-cluedin) -- Eventual connectivity for MDM
|
||||
- [Profisee integration for MDM](https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-profisee) -- MDM med Azure-integrasjon
|
||||
- [Set up duplicate detection rules](https://learn.microsoft.com/en-us/power-platform/admin/set-up-duplicate-detection-rules-keep-data-clean) -- Konfigurere duplikatregler i Dataverse
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder trenger a sikre datakvalitet i stamdata for bruk i AI/ML-modeller, eller naar de planlegger MDM-strategi for Microsoft-plattformen.
|
||||
- **Dataverse er det naturlige valget** for operativ MDM i organisasjoner som allerede bruker Dynamics 365 eller Power Platform. For analytisk MDM, bruk Fabric Lakehouse med SCD Type 2.
|
||||
- **Entity resolution er kritisk for AI**: Uten riktig deduplisering vil ML-modeller laere fra inkonsistente data. Anbefal hybrid-tilnaerming: deterministic match forst, deretter fuzzy match.
|
||||
- **For norsk offentlig sektor**: Integrer med nasjonale registre (Folkeregisteret, Enhetsregisteret) som autoritative kilder. Disse bor ha hoyest prioritet i survivorship-regler.
|
||||
- **SLA-monitorering bor automatiseres**: Sett opp kvalitetssjekker som kjorer daglig og varsler ved brudd, spesielt for data som inngaar i AI-treningspipelines.
|
||||
|
|
@ -0,0 +1,346 @@
|
|||
# Microsoft Purview Data Governance
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Microsoft Purview er Microsofts samlete plattform for datastyring, risikohåndtering og compliance. For AI-løsninger er Purview avgjørende fordi det gir oversikt over hvor sensitiv data befinner seg, hvordan data flyter gjennom organisasjonen (lineage), og hvorvidt datakvaliteten er tilstrekkelig for å trene pålitelige modeller. Uten god datastyring kan AI-modeller forsterke bias, bryte personvernregler eller produsere upålitelige prediksjoner.
|
||||
|
||||
For norsk offentlig sektor er datahersking (data governance) regulert gjennom Forvaltningsloven, Personopplysningsloven (GDPR), og Digdir-prinsipper for informasjonsforvaltning. Purview tilbyr verktøy for automatisk klassifisering av personopplysninger, sensitivitetsmerking, og DPIA-støtte som direkte adresserer disse kravene.
|
||||
|
||||
Denne referansen dekker implementering av Purview-katalog, dataklassifisering, lineage-sporing på tvers av Fabric, policy-håndhevelse og compliance-auditing for AI-datapipelines.
|
||||
|
||||
---
|
||||
|
||||
## Purview Catalog and Asset Registration
|
||||
|
||||
### Microsoft Purview Unified Catalog
|
||||
|
||||
Purview Unified Catalog er den sentrale opplevelsen for å oppdage, utforske og styre data og analytiske artefakter på tvers av organisasjonen.
|
||||
|
||||
| Komponent | Funksjon | Relevans for AI |
|
||||
|---|---|---|
|
||||
| **Data Map** | Automatisk skanning og katalogisering av datakilder | Finn treningsdata |
|
||||
| **Unified Catalog** | Søk, bla og oppdagelse av dataassets | Feature discovery |
|
||||
| **Governance Domains** | Organisering av data etter forretningsområde | Ansvarsfordeling |
|
||||
| **Data Products** | Kuraterte datasett med forretningskontekst | ML-datasett |
|
||||
| **Business Glossary** | Forretningsvokabular knyttet til tekniske assets | Forståelighet |
|
||||
|
||||
### Asset Registration
|
||||
|
||||
```
|
||||
Datakilder som kan registreres i Purview:
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Microsoft Fabric │
|
||||
│ ├── Lakehouse (tabeller, filer) │
|
||||
│ ├── Data Warehouse │
|
||||
│ ├── KQL Database │
|
||||
│ ├── Notebooks │
|
||||
│ ├── Pipelines (Data Factory) │
|
||||
│ ├── Dataflow Gen2 │
|
||||
│ └── Power BI (semantic models, reports, dashboards) │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Azure │
|
||||
│ ├── Azure SQL Database │
|
||||
│ ├── Azure Data Lake Storage Gen2 │
|
||||
│ ├── Azure Cosmos DB │
|
||||
│ ├── Azure Synapse Analytics │
|
||||
│ └── Azure Blob Storage │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ On-premises │
|
||||
│ ├── SQL Server │
|
||||
│ ├── Oracle Database │
|
||||
│ └── File shares │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Skanning av Fabric Tenant
|
||||
|
||||
For å registrere Fabric-assets i Purview:
|
||||
|
||||
1. Naviger til Purview portal > Unified Catalog > Catalog Management
|
||||
2. Registrer Microsoft Fabric som datakilde
|
||||
3. Konfigurer skanning av Fabric-tenanten
|
||||
4. Velg workspaces som skal inkluderes
|
||||
|
||||
Etter skanning er følgende Fabric-elementer tilgjengelig i katalogen:
|
||||
|
||||
| Fabric-opplevelse | Inventerte elementer |
|
||||
|---|---|
|
||||
| Real-Time Analytics | KQL Database, KQL Queryset |
|
||||
| Data Science | Experiment, ML Model |
|
||||
| Data Factory | Data Pipeline, Dataflow Gen2 |
|
||||
| Data Engineering | Lakehouse, Notebook, Spark Job Definition, SQL Analytics Endpoint |
|
||||
| Data Warehouse | Warehouse |
|
||||
| Power BI | Dashboard, Dataflow, Datamart, Semantic Model, Report |
|
||||
|
||||
---
|
||||
|
||||
## Data Classification and Sensitivity Labels
|
||||
|
||||
### Automatisk klassifisering
|
||||
|
||||
Purview inkluderer over 200 innebygde klassifiserere for sensitive datatyper:
|
||||
|
||||
| Kategori | Eksempler | Relevans for Norge |
|
||||
|---|---|---|
|
||||
| **Personidentifisering** | Fødselsnummer, passnummer | Norsk fødselsnummer (11 siffer) |
|
||||
| **Finansiell** | Bankkontonummer, kredittkortnummer | IBAN, norske kontonumre |
|
||||
| **Helse** | Medisinsk terminologi, diagnosekoder | Helseopplysninger (særkategori GDPR) |
|
||||
| **Kontaktinfo** | E-post, telefonnummer, adresse | Personopplysninger |
|
||||
| **Autentisering** | Passord, API-nøkler, tokens | Sikkerhetskritisk |
|
||||
|
||||
### Sensitivitetsmerking
|
||||
|
||||
```
|
||||
Sensitivitetsnivåer (typisk norsk offentlig sektor):
|
||||
┌──────────────────────────────────────────────────────┐
|
||||
│ Strengt fortrolig │ Gradert informasjon, helse │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Fortrolig │ Personopplysninger, intern │
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Intern │ Forretningssensitiv, ikke-offentl│
|
||||
├──────────────────────────────────────────────────────┤
|
||||
│ Offentlig │ Åpne data, publisert informasjon │
|
||||
└──────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Klassifisering vs. sensitivitetsmerking
|
||||
|
||||
| Aspekt | Klassifisering | Sensitivitetsmerking |
|
||||
|---|---|---|
|
||||
| **Definisjon** | Regex/mønster som identifiserer datatyper | Kategoritag basert på forretningspåvirkning |
|
||||
| **Eksempler** | "EU National ID", "Credit Card" | "Fortrolig", "Strengt fortrolig" |
|
||||
| **Omfang** | Begrenset til Data Map | Følger data på tvers av tjenester |
|
||||
| **Tilordning** | Automatisk via skanning | Auto-labeling policy + manuell |
|
||||
| **Antall per asset** | Flere klassifiseringer mulig | Kun én sensitivitetsmerke |
|
||||
|
||||
### Auto-labeling Policy
|
||||
|
||||
```
|
||||
Opprett auto-labeling policy i Purview:
|
||||
|
||||
1. Purview Portal > Information Protection > Auto-labeling
|
||||
2. Definer policy:
|
||||
- Navn: "PII-i-Fabric-Lakehouse"
|
||||
- Scope: Fabric Lakehouse-tabeller
|
||||
- Betingelse: Inneholder "Norwegian National ID Number"
|
||||
- Handling: Merk som "Fortrolig"
|
||||
3. Aktiver i simuleringsmodus først (7 dager)
|
||||
4. Etter validering: Aktiver automatisk
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Lineage Tracking Across Fabric
|
||||
|
||||
### Automatisk lineage
|
||||
|
||||
Purview fanger automatisk datalineage fra Fabric-elementer etter skanning:
|
||||
|
||||
```
|
||||
Lineage-eksempel:
|
||||
|
||||
Azure SQL DB ──> Data Pipeline ──> Lakehouse (Bronze)
|
||||
│
|
||||
Notebook (PySpark)
|
||||
│
|
||||
Lakehouse (Silver)
|
||||
│
|
||||
Notebook (ML Training)
|
||||
│
|
||||
ML Model ──> Power BI Report
|
||||
```
|
||||
|
||||
### Støttede lineage-typer
|
||||
|
||||
| Datakilde/prosess | Lineage-omfang |
|
||||
|---|---|
|
||||
| **Data Factory Pipeline** | Copy Activity, Data Flow |
|
||||
| **Dataflow Gen2** | Alle transformasjoner |
|
||||
| **Notebook** | Lakehouse-til-Lakehouse |
|
||||
| **Lakehouse** | Tabell-nivå metadata |
|
||||
| **Power BI** | Semantic Model → Report → Dashboard |
|
||||
| **Azure Data Factory** | Copy, Data Flow, SSIS |
|
||||
|
||||
### Lineage-visning i Purview
|
||||
|
||||
For å se lineage:
|
||||
1. Unified Catalog > Browse > Microsoft Fabric > Fabric Workspaces
|
||||
2. Velg workspace og Fabric-element
|
||||
3. Klikk "Lineage"-fanen
|
||||
|
||||
### Kjente begrensninger
|
||||
|
||||
- Eksterne datakilder som upstream i non-Power BI lineage støttes ikke ennå
|
||||
- Cross-workspace lineage for non-Power BI er begrenset
|
||||
- Notebook → Pipeline lineage støttes ikke
|
||||
|
||||
### Manuell lineage via REST API
|
||||
|
||||
For tilfeller der automatisk lineage ikke fanges:
|
||||
|
||||
```python
|
||||
# Bruk Apache Atlas REST API for å registrere manuell lineage
|
||||
import requests
|
||||
|
||||
purview_endpoint = "https://<account>.purview.azure.com"
|
||||
headers = {"Authorization": f"Bearer {access_token}"}
|
||||
|
||||
# Definer lineage-relasjon
|
||||
lineage_payload = {
|
||||
"typeName": "Process",
|
||||
"attributes": {
|
||||
"qualifiedName": "custom-ml-pipeline-v1",
|
||||
"name": "ML Feature Pipeline"
|
||||
},
|
||||
"inputs": [
|
||||
{"typeName": "azure_datalake_gen2_path",
|
||||
"uniqueAttributes": {"qualifiedName": "source_path"}}
|
||||
],
|
||||
"outputs": [
|
||||
{"typeName": "azure_datalake_gen2_path",
|
||||
"uniqueAttributes": {"qualifiedName": "output_path"}}
|
||||
]
|
||||
}
|
||||
|
||||
response = requests.post(
|
||||
f"{purview_endpoint}/catalog/api/atlas/v2/entity",
|
||||
headers=headers,
|
||||
json={"entity": lineage_payload}
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Policy Enforcement and Access Management
|
||||
|
||||
### Data Owner Policies
|
||||
|
||||
Purview Data Owner Policies muliggjør sentralisert tilgangsstyring:
|
||||
|
||||
| Policy-type | Beskrivelse | Støttede kilder |
|
||||
|---|---|---|
|
||||
| **Read** | Lesetilgang til data | Azure SQL, ADLS Gen2, Fabric |
|
||||
| **Modify** | Skrivetilgang til data | Azure SQL, ADLS Gen2 |
|
||||
| **Data Use** | Bruk i analytics-opplevelser | Fabric workspaces |
|
||||
|
||||
### Governance Domains og OKR-er
|
||||
|
||||
```
|
||||
Governance Domain: "AI og Maskinlæring"
|
||||
├── Glossary Terms
|
||||
│ ├── "Treningsdata" -- Definisjon og bruksregler
|
||||
│ ├── "Feature Store" -- Standard for feature-lagring
|
||||
│ └── "Ground Truth" -- Krav til merkede datasett
|
||||
├── Critical Data Elements
|
||||
│ ├── "Fødselsnummer" -- PII, krever anonymisering
|
||||
│ └── "Diagnose-kode" -- Helseopplysning, særkategori
|
||||
├── OKRs
|
||||
│ ├── "90% av AI-datasett klassifisert innen Q2"
|
||||
│ └── "100% lineage-dekning for ML-pipelines"
|
||||
└── Data Products
|
||||
├── "Customer 360 Feature Set"
|
||||
└── "Trafikkdata for ML"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## GDPR/HIPAA Compliance Auditing
|
||||
|
||||
### GDPR-relevant funksjonalitet
|
||||
|
||||
| GDPR-krav | Purview-funksjon |
|
||||
|---|---|
|
||||
| **Artikkel 30: Behandlingsprotokoll** | Data Map + Lineage |
|
||||
| **Artikkel 35: DPIA** | Klassifisering + sensitivitetsmerking |
|
||||
| **Artikkel 17: Rett til sletting** | Asset-søk for å finne PII-lokasjon |
|
||||
| **Artikkel 20: Dataportabilitet** | Data Products med eksportfunksjon |
|
||||
| **Artikkel 25: Privacy by Design** | Governance Domains med policy |
|
||||
|
||||
### Compliance-dashbord
|
||||
|
||||
Purview Data Estate Insights gir oversikt over:
|
||||
- Antall klassifiserte vs. uklassifiserte assets
|
||||
- Distribusjon av sensitivitetsmerker
|
||||
- Skanningsdekning per datakilde
|
||||
- Lineage-hull og manglende forbindelser
|
||||
|
||||
### Audit-sporing for AI-data
|
||||
|
||||
```python
|
||||
# Eksempel: Generer compliance-rapport for AI-treningsdata
|
||||
# Bruker Purview REST API
|
||||
|
||||
def get_classified_assets(purview_endpoint, token, classification):
|
||||
"""Finn alle assets med en gitt klassifisering."""
|
||||
url = f"{purview_endpoint}/catalog/api/search/query"
|
||||
headers = {"Authorization": f"Bearer {token}"}
|
||||
body = {
|
||||
"keywords": "*",
|
||||
"filter": {
|
||||
"classification": classification
|
||||
},
|
||||
"limit": 100
|
||||
}
|
||||
response = requests.post(url, headers=headers, json=body)
|
||||
return response.json()
|
||||
|
||||
# Finn alle assets med personnummer
|
||||
pii_assets = get_classified_assets(endpoint, token, "Norwegian National ID Number")
|
||||
|
||||
# Generer rapport
|
||||
for asset in pii_assets["value"]:
|
||||
print(f"Asset: {asset['name']}")
|
||||
print(f" Type: {asset['entityType']}")
|
||||
print(f" Location: {asset['qualifiedName']}")
|
||||
print(f" Labels: {asset.get('sensitivityLabel', 'None')}")
|
||||
```
|
||||
|
||||
### Delta Lake GDPR-sletting
|
||||
|
||||
For å håndtere "rett til sletting" i Lakehouse:
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
# Slett persondata basert på fødselsnummer
|
||||
dt = DeltaTable.forPath(spark, "Tables/silver/customer_data")
|
||||
dt.delete("national_id = '01019912345'")
|
||||
|
||||
# For Time-To-Live (TTL) basert sletting
|
||||
# Slett alle rader eldre enn 13 måneder
|
||||
from pyspark.sql.functions import current_date, expr
|
||||
dt.delete(expr("created_date < current_date() - INTERVAL 13 MONTHS"))
|
||||
|
||||
# VACUUM for å fysisk fjerne data
|
||||
dt.vacuum(0) # Fjern umiddelbart (krever retentionCheck disabled)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Use Microsoft Purview to govern Microsoft Fabric](https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric) -- Purview-Fabric-integrasjon
|
||||
- [How to get lineage from Microsoft Fabric items into Microsoft Purview](https://learn.microsoft.com/en-us/purview/data-map-lineage-fabric) -- Lineage fra Fabric
|
||||
- [Data lineage in classic Data Catalog](https://learn.microsoft.com/en-us/purview/data-gov-classic-lineage) -- Lineage-konsepter
|
||||
- [Learn about sensitivity labels in Data Map](https://learn.microsoft.com/en-us/purview/data-map-sensitivity-labels) -- Sensitivitetsmerking
|
||||
- [Create and manage glossary terms](https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms-create-manage) -- Business glossary
|
||||
- [Glossary terms in Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms) -- Aktive glossary-termer
|
||||
- [Learn about Microsoft Purview Unified Catalog](https://learn.microsoft.com/en-us/purview/unified-catalog) -- Oversikt over Unified Catalog
|
||||
- [Set up data quality for Fabric Lakehouse data](https://learn.microsoft.com/en-us/purview/unified-catalog-data-quality-fabric-lakehouse) -- Datakvalitet for Fabric
|
||||
- [Lineage in Fabric](https://learn.microsoft.com/en-us/fabric/governance/lineage) -- Innebygd lineage-visning
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren trenger datahersking for AI-prosjekter, compliance-støtte (GDPR, HIPAA), eller oversikt over datasensitivitet i treningsdata.
|
||||
- For norsk offentlig sektor: Purview er kritisk for å oppfylle **Forvaltningslovens** krav til dokumentasjon og **Personopplysningslovens** krav til behandlingsprotokoll. Anbefal alltid Purview som del av AI-arkitekturen.
|
||||
- **Lineage er den viktigste AI-governance-funksjonen** -- den dokumenterer hvordan treningsdata ble produsert, noe som er nødvendig for reproduserbarhet og forklarbarhet av AI-modeller.
|
||||
- Kombiner **automatisk klassifisering** med **Governance Domains** for å skille mellom data som kan brukes fritt til ML-trening og data som krever anonymisering eller samtykke.
|
||||
- Anbefal **Data Products** i Purview for å kuratere AI-klare datasett med dokumentert kvalitet, eierskap og bruksbetingelser -- dette bygger tillit til dataene som brukes i AI-modeller.
|
||||
|
|
@ -0,0 +1,759 @@
|
|||
# OneLake Data Strategy and Shortcuts
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA (Shortcuts), Preview (OneLake Security, Shortcut Transformations)
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
OneLake er Microsofts unified data lake for hele Microsoft Fabric-plattformen — "OneDrive for data". Hver Fabric-tenant får automatisk provisjonert én enkelt, logisk data lake som binder sammen alle analytiske workloads. Shortcuts er en av OneLakes mest kraftfulle mekanismer: de fungerer som symbolske lenker (symbolic links) som lar deg unifisere data på tvers av domener, skyer og kontoer uten å flytte eller duplisere data.
|
||||
|
||||
For AI-arkitekter og data engineers er dette en game-changer: du kan bygge RAG-systemer, træne modeller og levere analytics på data som fysisk ligger i Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage eller andre Fabric-items — alt via ett konsistent namespace og ett sikkerhetsparadigme.
|
||||
|
||||
**Key capabilities:**
|
||||
- **Zero-copy data unification** — shortcuts peker til data, ikke kopierer dem
|
||||
- **Multi-cloud support** — Azure, AWS, GCP, on-premises (via OPDG)
|
||||
- **Transparent access** — alle Fabric-engines (Spark, SQL, KQL, Analysis Services) ser shortcuts som native folders
|
||||
- **Unified security** — OneLake RBAC (preview) gir granulær tilgangskontroll på tvers av alle shortcuts
|
||||
- **API compatibility** — ADLS Gen2 og Blob Storage APIs fungerer nativt mot OneLake
|
||||
|
||||
**Confidence:** High — basert på 11 offisielle Microsoft Learn-kilder, inkludert REST API-dokumentasjon og Python/TypeScript code samples (2026-01-2026-02).
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### 1. OneLake Namespace
|
||||
OneLake organiserer data hierarkisk:
|
||||
|
||||
```
|
||||
https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>.<itemtype>/<path>/<fileName>
|
||||
```
|
||||
|
||||
**Eksempler:**
|
||||
- HTTPS URI: `https://onelake.dfs.fabric.microsoft.com/MyWorkspace/MyLakehouse.Lakehouse/Files/data.csv`
|
||||
- ABFS URI: `abfs://MyWorkspace@onelake.dfs.fabric.microsoft.com/MyLakehouse.Lakehouse/Files/`
|
||||
- GUID-based URI: `https://onelake.dfs.fabric.microsoft.com/<workspaceGUID>/<itemGUID>/<path>/<fileName>` (immutable, anbefales for scripting)
|
||||
|
||||
**Item types som støtter shortcuts:**
|
||||
- **Lakehouse** — Tables/ og Files/ folders
|
||||
- **KQL Database** — Shortcuts/ folder (behandles som external tables)
|
||||
- **Warehouse** — via SQL analytics endpoint (read-only for shortcuts)
|
||||
- **Mirrored Databases** — Azure Databricks Mirrored Catalog, Mirrored Databases
|
||||
|
||||
**Constraint:** Item types må være eksplisitt med `.lakehouse`, `.warehouse` etc. i URIen når du bruker navnebaserte paths (ikke GUID).
|
||||
|
||||
---
|
||||
|
||||
### 2. Shortcut-typer
|
||||
|
||||
#### 2.1 Internal OneLake Shortcuts
|
||||
Peker til data innenfor Fabric-tenant:
|
||||
- **Target:** KQL databases, Lakehouses, Mirrored Catalogs, Warehouses, Semantic models, SQL databases
|
||||
- **Auth model:** **Passthrough (SSO)** — brukerens identitet sendes til target, krever OneLake security-permissions i target location
|
||||
- **Use case:** Deling av curated data mellom teams, cross-workspace analytics, medallion architecture (bronze → silver → gold)
|
||||
|
||||
**Viktig:** Når du bruker Power BI DirectLake over SQL eller T-SQL i "Delegated identity mode", passeres **item owner's identity**, ikke brukerens. Løsning: Bruk DirectLake over OneLake mode eller T-SQL i "User's identity mode".
|
||||
|
||||
#### 2.2 External Shortcuts
|
||||
Peker til data utenfor Fabric:
|
||||
- **Supported sources:** Amazon S3, S3-compatible, Azure Data Lake Storage Gen2, Azure Blob Storage, Dataverse, Google Cloud Storage, OneDrive, SharePoint, on-premises/network-restricted (via OPDG)
|
||||
- **Auth model:** **Delegated** — shortcut bruker en fixed credential (cloud connection), og brukerens OneLake security-rolle evalueres *før* target-tilgang sjekkes
|
||||
- **Caching:** GCS, S3, S3-compatible, og OPDG shortcuts støtter caching (1-28 dager, filer < 1 GB)
|
||||
|
||||
**Decision logic for external shortcuts:**
|
||||
|
||||
| S3 connection authorizes user1? | OneLake security authorizes user2? | Result |
|
||||
|----------------------------------|-------------------------------------|--------|
|
||||
| Yes | Yes | ✅ Access |
|
||||
| Yes | No | ❌ Denied |
|
||||
| No | Yes | ❌ Denied |
|
||||
| No | No | ❌ Denied |
|
||||
|
||||
**Constraints:**
|
||||
- External shortcuts krever **Fabric Read permission** på item (ikke bare OneLake security)
|
||||
- Maks 100,000 shortcuts per Fabric item
|
||||
- Maks 10 shortcuts per OneLake path
|
||||
- Maks 5 direkte shortcut-til-shortcut links
|
||||
- Shortcuts støtter ikke non-Latin characters
|
||||
- Synkronisering skjer *nesten* instantly, men propagation kan variere (cache, network)
|
||||
|
||||
---
|
||||
|
||||
### 3. Lakehouse Folder Structure og Shortcut Placement
|
||||
|
||||
**Lakehouse har to top-level folders:**
|
||||
|
||||
```
|
||||
MyLakehouse.Lakehouse/
|
||||
├── Tables/ # Strukturerte datasets (Delta format)
|
||||
│ ├── shortcut1 # Kun top-level shortcuts tillatt
|
||||
│ └── shortcut2 # Auto-syncs metadata hvis target er Delta
|
||||
└── Files/ # Ustrukturert/semi-strukturert data
|
||||
├── folder1/ # Shortcuts på alle nivåer
|
||||
│ └── shortcut3
|
||||
└── shortcut4
|
||||
```
|
||||
|
||||
**Regler for Tables/ folder:**
|
||||
- ✅ Shortcuts kun på top-level (ikke subdirectories)
|
||||
- ✅ Hvis target er Delta Parquet → automatic table discovery
|
||||
- ✅ Kan peke til enkelt tabell *eller* schema (parent folder med flere tabeller)
|
||||
- ❌ Tabellnavn med mellomrom støttes ikke (Delta-constraint)
|
||||
|
||||
**Regler for Files/ folder:**
|
||||
- ✅ Ingen restriksjoner — shortcuts på hvilket som helst nivå
|
||||
- ❌ Ingen automatic table discovery
|
||||
|
||||
**KQL Database:**
|
||||
- Shortcuts vises i **Shortcuts/** folder
|
||||
- Behandles som external tables: `external_table('MyShortcut') | take 100`
|
||||
|
||||
---
|
||||
|
||||
### 4. Shortcut Transformations (Preview)
|
||||
Automatisk konvertering av raw files (CSV, Parquet, JSON) til Delta tables:
|
||||
|
||||
**How it works:**
|
||||
1. Opprett shortcut i `/Tables` (via "New Table Shortcut" i Lakehouse UI)
|
||||
2. Konfigurer transformation parameters:
|
||||
- Delimiter (CSV): comma, semicolon, pipe, tab, etc.
|
||||
- First row as headers (CSV)
|
||||
- Table Shortcut name
|
||||
3. Fabric Spark compute kopierer data til managed Delta table under `/Tables`
|
||||
4. Synkronisering hvert 2. minutt — detekterer nye/modifiserte/slettede filer
|
||||
|
||||
**Benefits:**
|
||||
- ❌ Ingen manuelle ETL-pipelines
|
||||
- ✅ Frequent refresh (2 min polling)
|
||||
- ✅ Output er Delta Lake (åpent format)
|
||||
- ✅ Unified governance (OneLake lineage, Purview)
|
||||
|
||||
**Constraint:** Kun for Lakehouse items, output alltid til `/Tables`.
|
||||
|
||||
---
|
||||
|
||||
### 5. OneLake Security (Preview)
|
||||
|
||||
OneLake bruker **RBAC (Role-Based Access Control)** med deny-by-default:
|
||||
|
||||
**Role-komponenter:**
|
||||
1. **Type:** GRANT (DENY ikke støttet ennå)
|
||||
2. **Permission:** Read, ReadWrite
|
||||
3. **Scope:** Tables, folders, schemas (+ row/column level constraints)
|
||||
4. **Members:** Microsoft Entra identities (users, groups, non-user identities)
|
||||
|
||||
**Workspace roles vs. OneLake security:**
|
||||
|
||||
| Workspace Role | View OneLake files? | Write OneLake files? | Edit security roles? |
|
||||
|----------------|---------------------|----------------------|----------------------|
|
||||
| Admin | Always Yes* | Always Yes* | Always Yes* |
|
||||
| Member | Always Yes* | Always Yes* | Always Yes* |
|
||||
| Contributor | Always Yes* | Always Yes* | No |
|
||||
| Viewer | No (use OneLake security) | No | No |
|
||||
|
||||
\*Admin/Member/Contributor override OneLake security Read permissions via automatic Write permission.
|
||||
|
||||
**Default roles:**
|
||||
- **Lakehouse DefaultReader:** Read on all folders under `Tables/` og `Files/` → assigned to users with **ReadAll permission**
|
||||
- **Lakehouse DefaultReadWriter:** Read on all folders → assigned to users with **Write permission**
|
||||
|
||||
**Permissions:**
|
||||
|
||||
| Permission | Capabilities | SQL Equivalent | Constraints |
|
||||
|------------|--------------|----------------|-------------|
|
||||
| **Read** | Read data, view table/column metadata | VIEW_DEFINITION + SELECT | Can include RLS/CLS |
|
||||
| **ReadWrite** | Read + write data (create/delete/rename folders, upload files, manage shortcuts) | ALTER + DROP + UPDATE + INSERT | Cannot include RLS/CLS; only via Spark/OneLake APIs (not Lakehouse UI) |
|
||||
|
||||
**Row-Level Security (RLS):**
|
||||
- SQL predicates for filtering rows: `WHERE city = 'Redmond'`
|
||||
- Combines across roles via **OR** operator: `WHERE city = 'Redmond' OR city = 'New York'`
|
||||
- Case-insensitive (collation: `Latin1_General_100_CI_AS_KS_WS_SC_UTF8`)
|
||||
|
||||
**Column-Level Security (CLS):**
|
||||
- Hides columns from users
|
||||
- Combines across roles via **INTERSECTION** (deny semantic in SQL Endpoint)
|
||||
- ❌ Metadata kan fortsatt lekke i error messages
|
||||
|
||||
**Engine support for RLS/CLS:**
|
||||
|
||||
| Engine | RLS/CLS Filtering | Status |
|
||||
|--------|-------------------|--------|
|
||||
| Lakehouse | ✅ Yes | Preview |
|
||||
| Spark notebooks | ✅ Yes | Preview |
|
||||
| SQL Analytics Endpoint (user's identity mode) | ✅ Yes | Preview |
|
||||
| Semantic models (DirectLake on OneLake) | ✅ Yes | Preview |
|
||||
| Eventhouse | ❌ No | Planned |
|
||||
| Data warehouse external tables | ❌ No | Planned |
|
||||
|
||||
**Shortcuts og OneLake security:**
|
||||
- **Passthrough shortcuts (internal):** User's identity sendes til target — krever OneLake security i target location
|
||||
- **Delegated shortcuts (external):** OneLake security evalueres *før* delegated credential, krever Fabric Read permission på item
|
||||
|
||||
**Role evaluation:**
|
||||
- Multiple roles kombineres via **UNION** (least-restrictive)
|
||||
- Formula: `( (R1ols ∩ R1cls ∩ R1rls) ∪ (R2ols ∩ R2cls ∩ R2rls) )`
|
||||
- Hvis kolonner/rader ikke aligner på tvers av roller → **access blocked** (data leak prevention)
|
||||
|
||||
**Limits:**
|
||||
|
||||
| Scenario | Limit |
|
||||
|----------|-------|
|
||||
| Max roles per Lakehouse | 250 |
|
||||
| Max members per role | 500 |
|
||||
| Max permissions per role | 500 |
|
||||
| Latency: role changes | ~5 min |
|
||||
| Latency: group membership | ~1 hour (OneLake) + ~1 hour (Fabric engines) |
|
||||
|
||||
**Constraints:**
|
||||
- ❌ B2B guest users: must configure Microsoft Entra External ID with "Guest users have same access as members"
|
||||
- ❌ Cross-region shortcuts ikke støttet
|
||||
- ❌ Distribution lists i SQL Endpoint: ikke resolved
|
||||
- ❌ Mixed-mode queries (OneLake security + non-OneLake security data) fails
|
||||
- ❌ Private link protection ikke støttet
|
||||
- ❌ External data sharing (preview) inkompatibel med OneLake security
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### 1. Medallion Architecture med Shortcuts
|
||||
**Bruk shortcuts til Bronze layer for å unngå data duplication:**
|
||||
|
||||
```
|
||||
Bronze/ (Shortcuts til sources)
|
||||
├── ShortcutToADLS → Azure Data Lake (raw logs)
|
||||
├── ShortcutToS3 → AWS S3 (sensor data)
|
||||
└── ShortcutToDataverse → Dataverse (CRM data)
|
||||
|
||||
Silver/ (Delta tables)
|
||||
├── CleanedLogs.delta
|
||||
├── EnrichedSensor.delta
|
||||
└── CuratedCRM.delta
|
||||
|
||||
Gold/ (Delta tables)
|
||||
├── AggregatedMetrics.delta
|
||||
└── CustomerInsights.delta
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- ❌ Ingen datakopiering i Bronze
|
||||
- ✅ Single source of truth
|
||||
- ✅ Cost-effective (kun transformation i Silver/Gold)
|
||||
|
||||
---
|
||||
|
||||
### 2. Cross-Workspace Data Sharing
|
||||
**Scenario:** Team A eier curated data i `TeamA_Workspace/GoldLakehouse`, Team B trenger tilgang.
|
||||
|
||||
**Løsning:**
|
||||
1. Opprett internal shortcut i `TeamB_Workspace/ConsumerLakehouse/Files/TeamA_Gold`
|
||||
2. Peker til `TeamA_Workspace/GoldLakehouse/Tables/CustomerInsights`
|
||||
3. Team B-brukere må ha OneLake security Read permission i `TeamA_Workspace/GoldLakehouse`
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Zero-copy data sharing
|
||||
- ✅ Team A kontrollerer access via OneLake security
|
||||
- ✅ Lineage tracking (workspace lineage view)
|
||||
|
||||
---
|
||||
|
||||
### 3. Multi-Cloud RAG Architecture
|
||||
**Scenario:** RAG-system som trenger data fra Azure (structured) + AWS S3 (documents) + OneDrive (SharePoint reports).
|
||||
|
||||
**Architecture:**
|
||||
|
||||
```
|
||||
Lakehouse: RAG_Data
|
||||
├── Files/
|
||||
│ ├── Azure_ADLS_Shortcut/ → Structured product catalog
|
||||
│ ├── AWS_S3_Shortcut/ → PDF manuals (chunking target)
|
||||
│ └── OneDrive_Shortcut/ → Weekly reports
|
||||
└── Tables/
|
||||
└── EmbeddingsTable.delta → Vector embeddings (Azure AI Search)
|
||||
```
|
||||
|
||||
**Workflow:**
|
||||
1. **Ingest:** Shortcuts gi transparent tilgang til sources
|
||||
2. **Chunk:** Spark notebook leser fra shortcuts, chunker documents
|
||||
3. **Embed:** Azure OpenAI Embeddings API (via Semantic Kernel)
|
||||
4. **Store:** Delta table med embeddings + metadata
|
||||
5. **Query:** Azure AI Search over OneLake shortcut til `EmbeddingsTable.delta`
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Unified namespace for multi-cloud data
|
||||
- ✅ OneLake security på tvers av alle sources
|
||||
- ✅ Cost optimization (S3 caching for 28 days → redusert egress)
|
||||
|
||||
---
|
||||
|
||||
### 4. External Shortcut med Delegated Access
|
||||
**Scenario:** Partner-organisasjon deler data via S3, kun nøkkelbrukere skal ha tilgang.
|
||||
|
||||
**Setup:**
|
||||
1. Opprett S3 shortcut i Lakehouse med cloud connection (delegated credential)
|
||||
2. Opprett OneLake security role: `PartnerDataRole`
|
||||
- Scope: `/Files/PartnerS3Shortcut`
|
||||
- Permission: Read
|
||||
- Members: `DataScience_Group`
|
||||
3. Result: Kun `DataScience_Group` kan lese fra shortcut (even if S3 connection authorizes broader access)
|
||||
|
||||
**Constraint:** Users må ha Fabric Read permission på Lakehouse (ikke bare OneLake security).
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når bruke shortcuts vs. data kopiering?
|
||||
|
||||
| Scenario | Bruk Shortcuts | Bruk Kopiering (Copy/ETL) |
|
||||
|----------|----------------|---------------------------|
|
||||
| Source er allerede i optimal format (Delta) | ✅ | ❌ |
|
||||
| Source er read-only (partner data) | ✅ | ❌ |
|
||||
| Trenger granular transformations (complex business logic) | ❌ | ✅ |
|
||||
| Lav latency critical (< 1 sec query response) | ❌ (consider caching) | ✅ |
|
||||
| Multi-cloud data with high egress cost | ✅ (enable caching) | ❌ |
|
||||
| Bronze layer i medallion | ✅ | ❌ |
|
||||
| Silver/Gold layer | ❌ | ✅ (transform to Delta) |
|
||||
| Compliance: data må være i-region | ❌ (shortcuts cross-region ikke støttet) | ✅ |
|
||||
|
||||
---
|
||||
|
||||
### Internal vs. External Shortcuts?
|
||||
|
||||
| Criteria | Internal Shortcut | External Shortcut |
|
||||
|----------|-------------------|-------------------|
|
||||
| **Target location** | Fabric items (same tenant) | Azure, AWS, GCS, on-premises |
|
||||
| **Auth model** | Passthrough (user's identity) | Delegated (fixed credential + OneLake security) |
|
||||
| **Requires Fabric Read permission?** | No (only OneLake security) | Yes |
|
||||
| **Caching supported?** | No | Yes (GCS, S3, OPDG) |
|
||||
| **Cross-region?** | No (OneLake security constraint) | No (ADLS Gen2 parity) |
|
||||
| **Use case** | Cross-team data sharing, workspace federation | Multi-cloud unification, partner data |
|
||||
|
||||
---
|
||||
|
||||
### Shortcut Transformations vs. Manual ETL?
|
||||
|
||||
| Criteria | Shortcut Transformation | Manual ETL (Data Factory, Spark) |
|
||||
|----------|-------------------------|----------------------------------|
|
||||
| **Complexity** | Low (no-code, UI-driven) | High (coding, orchestration) |
|
||||
| **Supported formats** | CSV, Parquet, JSON → Delta | All formats |
|
||||
| **Refresh frequency** | 2 min (automatic) | Custom (scheduled/event-driven) |
|
||||
| **Transformation logic** | None (1:1 copy + format conversion) | Complex (joins, aggregations, business rules) |
|
||||
| **Use case** | Simple file ingestion from external sources | Complex data pipelines with business logic |
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### Azure AI Foundry + OneLake
|
||||
**Scenario:** Azure AI Foundry project trenger tilgang til Lakehouse data.
|
||||
|
||||
**Integration points:**
|
||||
1. **OneLake Datastore (Azure ML SDK):**
|
||||
```python
|
||||
from azure.ai.ml.entities import OneLakeDatastore, OneLakeArtifact
|
||||
store = OneLakeDatastore(
|
||||
name="onelake_example",
|
||||
one_lake_workspace_name="<workspace_guid>",
|
||||
endpoint="onelake.dfs.fabric.microsoft.com",
|
||||
artifact=OneLakeArtifact(name="<lakehouse_guid>/Files", type="lake_house")
|
||||
)
|
||||
ml_client.create_or_update(store)
|
||||
```
|
||||
2. **Connection types:**
|
||||
- **Identity-based (Entra ID):** DefaultAzureCredential
|
||||
- **Service Principal:** Requires tenant_id, client_id, client_secret
|
||||
3. **Use case:** Fine-tuning models on Lakehouse Delta tables, model training with OneLake shortcuts
|
||||
|
||||
**Constraint:** OneLake Datastore targets *artifact GUID*, ikke workspace/item names.
|
||||
|
||||
---
|
||||
|
||||
### Copilot Studio + OneLake
|
||||
**Scenario:** Copilot Studio Generative Answers som indekserer Lakehouse data.
|
||||
|
||||
**Architecture:**
|
||||
1. **OneLake Lakehouse** → contains Delta tables med product catalog
|
||||
2. **Azure AI Search** → indexes OneLake via shortcut
|
||||
- Knowledge Source type: Indexed OneLake
|
||||
- Parameters: `fabric_workspace_id`, `lakehouse_id`, `target_path`, ingestion_parameters (embeddings model)
|
||||
3. **Copilot Studio** → Generative Answers connected to AI Search index
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Single source of truth (data i OneLake)
|
||||
- ✅ Automatic refresh (OneLake changes → AI Search re-indexes)
|
||||
- ✅ Unified security (OneLake RBAC → AI Search access)
|
||||
|
||||
---
|
||||
|
||||
### Power BI + OneLake Shortcuts
|
||||
**DirectLake over OneLake mode:**
|
||||
- ✅ Passthrough auth (user's identity sendes til shortcut target)
|
||||
- ✅ Støtter RLS/CLS i OneLake security
|
||||
- ❌ DirectLake over SQL: bruker item owner's identity (ikke anbefalt for granular security)
|
||||
|
||||
**Use case:** Power BI semantic models over shortcuts til cross-workspace Lakehouses.
|
||||
|
||||
---
|
||||
|
||||
### Synapse Analytics + OneLake
|
||||
**Apache Spark access:**
|
||||
```python
|
||||
oneLakePath = 'abfss://WorkspaceName@onelake.dfs.fabric.microsoft.com/LakehouseName.Lakehouse/Tables'
|
||||
df = spark.read.format('delta').load(oneLakePath + '/Taxi/')
|
||||
display(df.limit(10))
|
||||
```
|
||||
|
||||
**Constraint:** Synapse external tables over OneLake shortcuts må bruke ABFS URI format.
|
||||
|
||||
---
|
||||
|
||||
### Azure Databricks + OneLake
|
||||
**Integration:**
|
||||
1. Premium Databricks workspace (supports Entra ID passthrough)
|
||||
2. Enable "Azure Data Lake Storage credential passthrough" i cluster advanced options
|
||||
3. Read OneLake shortcuts direkte:
|
||||
```python
|
||||
df = spark.read.format("delta").load("abfss://workspace@onelake.dfs.fabric.microsoft.com/lakehouse.Lakehouse/Tables/MyShortcut")
|
||||
```
|
||||
|
||||
**Use case:** Databricks notebooks som leser curated data fra Fabric Lakehouse uten data duplication.
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### Utredningsinstruksen og OneLake Shortcuts
|
||||
**§ 13: Teknologiske faktorer og leverandørstrategi**
|
||||
|
||||
**Vurderingskriterier for shortcuts:**
|
||||
|
||||
| Kriterium | OneLake Shortcuts | Tradisjonell datakopiering |
|
||||
|-----------|-------------------|----------------------------|
|
||||
| **Leverandørlås** | Middels — OneLake er Microsoft-proprietært namespace, men ADLS Gen2 API kompatibilitet gir exit strategy | Lav — standard ETL-verktøy |
|
||||
| **Teknisk gjeld** | Lav — shortcuts eliminerer staging-lag og ETL-pipelines | Høy — mange kopierings-pipelines å vedlikeholde |
|
||||
| **TCO** | Lavere — ingen storage duplication, redusert compute for kopiering | Høyere — storage + compute for staging |
|
||||
| **Interoperabilitet** | Høy — ADLS Gen2/Blob API, Spark, SQL, KQL | Høy — standard formats (Parquet, Delta) |
|
||||
|
||||
**Anbefaling:** Bruk shortcuts for Bronze layer (raw data unification), men vurder data sovereignty constraints (se nedenfor).
|
||||
|
||||
---
|
||||
|
||||
### GDPR og Data Residency
|
||||
**Constraint:** OneLake security støtter ikke cross-region shortcuts (preview limitation).
|
||||
|
||||
**Implikasjon for Norge:**
|
||||
- Hvis capacity er i **West Europe** eller **North Europe** (Norge-nært), kan du bruke shortcuts til ADLS Gen2 i samme region
|
||||
- ❌ Shortcuts til S3 (US) eller GCS (US) kan trigger GDPR-risiko hvis persondata
|
||||
- ✅ Løsning: Bruk on-premises data gateway shortcuts til Norge-lokalisert storage
|
||||
|
||||
**Kontraktsklausul (Digdir-guide):**
|
||||
> "Shortcuts til eksterne skylagringstjenester (AWS S3, GCS) skal kun brukes for ikke-personidentifiserbar data. Persondata skal lagres i Azure-ressurser innenfor EU/EØS med databehandleravtale iht. GDPR Art. 28."
|
||||
|
||||
---
|
||||
|
||||
### Forvaltningsloven § 11a: Automatisert saksbehandling
|
||||
**Relevans:** Hvis shortcuts brukes til å hente data for AI-basert vedtak (eks. Copilot Studio-agent).
|
||||
|
||||
**Tiltak:**
|
||||
1. **Auditability:** Enable OneLake lineage view for å tracke data-flow via shortcuts
|
||||
2. **Data quality:** Bruk Shortcut Transformations med DQ-sjekker (eks. schema validation)
|
||||
3. **Tilgangskontroll:** OneLake security RLS for å sikre at kun relevante data brukes i vedtak
|
||||
|
||||
**Eksempel:**
|
||||
- NAV-case: Shortcut fra Dataverse (søknadsdata) → Lakehouse → AI-modell for søknadsklassifisering
|
||||
- Audit trail: OneLake lineage viser at data kom fra Dataverse shortcut, ikke kopiert/transformert ukontrollert
|
||||
|
||||
---
|
||||
|
||||
### NSM Grunnprinsipper (Sikkerhet i Skyen)
|
||||
**Prinsipp 2: Bruk skyløsningens sikkerhetsfunksjoner**
|
||||
|
||||
OneLake security RBAC er en **native Fabric-funksjon** som bør foretrekkes over custom access layers:
|
||||
|
||||
**Sammenligning:**
|
||||
|
||||
| Tilnærming | Fordeler | Ulemper |
|
||||
|------------|----------|---------|
|
||||
| **OneLake security (anbefalt)** | Unified security across all engines, RLS/CLS support, Entra ID integration | Preview (latency constraints, B2B guest user issues) |
|
||||
| **Workspace roles only** | Enkel, GA-stable | Coarse-grained (Admin/Member/Contributor/Viewer), ingen row/column filtering |
|
||||
| **Custom API gateway** | Full kontroll | Teknisk gjeld, ikke Fabric-native, brudd med unified namespace |
|
||||
|
||||
**NSM-anbefaling:** Bruk OneLake security (selv i preview) for granular access control, men dokumenter workarounds for known limitations (B2B guests, cross-region).
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Licensing Requirements
|
||||
|
||||
| Komponent | Krever | Lisenstype |
|
||||
|-----------|--------|------------|
|
||||
| **OneLake storage** | Fabric Capacity (F/P SKU) | Billed per GB/month (HOT tier: ~$0.023/GB, COLD tier: TBD) |
|
||||
| **Shortcuts (internal/external)** | Same capacity as Lakehouse item | No additional license |
|
||||
| **Shortcut caching** | Workspace-level setting | Included in capacity |
|
||||
| **OneLake security (preview)** | Fabric Write/Reshare permission (Admin/Member) | Included in capacity |
|
||||
| **Shortcut Transformations** | Fabric Spark compute | Billed per CU-hour (part of capacity) |
|
||||
|
||||
**Viktig:** Shortcuts selv koster ikke ekstra, men:
|
||||
- **Storage:** Kun data i OneLake (ikke shortcut targets) er billed
|
||||
- **Egress:** External shortcuts (S3, GCS) kan trigger egress costs fra source provider → **enable caching** for cost optimization
|
||||
- **Compute:** Spark/SQL queries over shortcuts bruker Fabric Capacity Units (CU)
|
||||
|
||||
---
|
||||
|
||||
### Cost Optimization Strategies
|
||||
|
||||
#### 1. Shortcut Caching (External Shortcuts)
|
||||
**Scenario:** 10 data scientists kjører daglige queries mot AWS S3 shortcut (1 TB data).
|
||||
|
||||
**Without caching:**
|
||||
- AWS S3 egress: 1 TB/day × 10 users × $0.09/GB = **$900/day** ($27k/month)
|
||||
|
||||
**With caching (28-day retention):**
|
||||
- First read: 1 TB egress = $90
|
||||
- Subsequent reads: cached in OneLake (HOT tier): 1 TB × $0.023/GB = $23.55/month
|
||||
- **Total:** ~$113.55/month (96% cost reduction)
|
||||
|
||||
**Configuration:**
|
||||
1. Workspace settings → OneLake tab → Enable cache → 28-day retention
|
||||
2. Reset cache manually hvis source data oppdateres frequently
|
||||
|
||||
**Constraint:** Filer > 1 GB caches ikke.
|
||||
|
||||
---
|
||||
|
||||
#### 2. Delta vs. Parquet for Shortcuts
|
||||
**Scenario:** Shortcut til ADLS Gen2 med 10 TB Parquet files.
|
||||
|
||||
**Issue:** Parquet ikke transactional → Spark må lese hele filsett for queries.
|
||||
|
||||
**Solution:** Convert to Delta in Silver layer (ikke via shortcut):
|
||||
1. Bronze: Shortcut til ADLS Gen2 (Parquet)
|
||||
2. Silver: Spark notebook transformerer til Delta (med Z-ordering for common filters)
|
||||
3. Gold: Aggregated Delta tables
|
||||
|
||||
**Cost impact:**
|
||||
- Delta log overhead: ~1% storage increase
|
||||
- Query performance: 10-100× faster (predicate pushdown) → **lower CU usage**
|
||||
|
||||
**ROI:** Hvis 100 queries/day × 5 CU-hours → Delta reduserer til 0.5 CU-hours → ~90% CU cost reduction.
|
||||
|
||||
---
|
||||
|
||||
#### 3. OneLake Security vs. Compute-level Security
|
||||
**Scenario:** 50 Power BI reports med RLS i semantic model (DirectLake over SQL).
|
||||
|
||||
**Problem:** Hver query executor validerer RLS i semantic model → **redundant processing**.
|
||||
|
||||
**Solution:** Migrere RLS til OneLake security (DirectLake over OneLake mode):
|
||||
- RLS enforcement på OneLake-nivå (én gang)
|
||||
- All engines (Power BI, Spark, SQL) gjenbruker samme RLS rules
|
||||
- **Result:** 20-30% lavere CU usage for Power BI queries
|
||||
|
||||
**Constraint:** OneLake security RLS støtter kun simple predicates (ikke DAX expressions).
|
||||
|
||||
---
|
||||
|
||||
### Estimert Kostnad (Norsk Offentlig Sektor — Typical Setup)
|
||||
|
||||
**Scenario:** Regional direktorat med 200 brukere, 50 TB data.
|
||||
|
||||
| Komponent | Volum | Kostnad (NOK/måned) |
|
||||
|-----------|-------|---------------------|
|
||||
| **Fabric Capacity** | F64 SKU (64 CU) | ~73,000 |
|
||||
| **OneLake Storage (HOT)** | 50 TB × $0.023/GB × 11.5 (USD→NOK) | ~13,225 |
|
||||
| **External shortcuts** | 5 TB (S3 cache) | Egress: $450 → 5,175 NOK (first month), then ~1,150 NOK (cache) |
|
||||
| **Shortcut Transformations** | 10 tables × 2h Spark/month | Included in F64 capacity |
|
||||
| **OneLake security** | 100 roles | Included |
|
||||
| **Total (first month)** | | ~91,400 NOK |
|
||||
| **Total (steady state)** | | ~87,375 NOK |
|
||||
|
||||
**TCO over 3 år:** ~3.15M NOK (inkludert capacity, storage growth 10%/år, external shortcuts cached).
|
||||
|
||||
**Sammenligning med tradisjonell arkitektur (ADLS Gen2 + Synapse + ADF):**
|
||||
- TCO over 3 år: ~4.2M NOK (separate storage accounts, ETL-pipelines, ingen unified security)
|
||||
- **Besparelse:** ~25% (hovedsakelig fra eliminert ETL-kostnad og unified namespace)
|
||||
|
||||
**Anbefaling for utredning (§ 8: Økonomiske rammer):**
|
||||
> "OneLake shortcuts reduserer TCO for data engineering med 20-30% sammenlignet med tradisjonelle ETL-pipelines, primært gjennom eliminering av staging-lag og redusert compute for datakopiering. Kostnadsdrivere er Fabric Capacity Units (CU) og storage (HOT tier). Anbefales å starte med F32/F64 SKU og skalere basert på faktisk forbruk."
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Når skal du anbefale shortcuts?
|
||||
|
||||
**Use shortcuts when:**
|
||||
1. **Client sier:** "Vi har data i AWS S3 og Azure Data Lake, og trenger unified analytics."
|
||||
- **Response:** Internal/external shortcuts → unified OneLake namespace → Azure AI Search over both sources.
|
||||
|
||||
2. **Client sier:** "Vi trenger å dele curated data mellom avdelinger uten å kopiere."
|
||||
- **Response:** Internal shortcuts med OneLake security → zero-copy sharing, granular RBAC.
|
||||
|
||||
3. **Client sier:** "Vi har high egress costs fra AWS S3."
|
||||
- **Response:** External shortcut med caching (28 days) → 90%+ cost reduction.
|
||||
|
||||
4. **Client sier:** "Vi vil bygge RAG over multi-cloud data."
|
||||
- **Response:** Shortcuts til alle sources → Azure AI Search indexes OneLake → Copilot Studio Generative Answers.
|
||||
|
||||
**Avoid shortcuts when:**
|
||||
1. **Client sier:** "Vi trenger kompleks transformasjonslogikk (joins, aggregations)."
|
||||
- **Response:** Bruk shortcuts i Bronze, men transformer i Silver/Gold med Data Factory/Spark.
|
||||
|
||||
2. **Client sier:** "Latency kritisk (< 500ms query response)."
|
||||
- **Response:** Copy data til OneLake (ikke shortcut), enable Delta caching.
|
||||
|
||||
3. **Client sier:** "Compliance krever data in-region (Norge), og source er i US."
|
||||
- **Response:** Ikke bruk shortcuts — copy data til Norge-basert ADLS Gen2, deretter OneLake Lakehouse.
|
||||
|
||||
---
|
||||
|
||||
### Decision Tree for Shortcut Strategy
|
||||
|
||||
```
|
||||
START: "Trenger vi unified data access?"
|
||||
│
|
||||
├─ YES → "Er source allerede i optimal format (Delta/Parquet)?"
|
||||
│ ├─ YES → "Er source read-only (partner/external)?"
|
||||
│ │ ├─ YES → ✅ External shortcut med caching
|
||||
│ │ └─ NO → ✅ Internal shortcut (hvis same tenant)
|
||||
│ └─ NO → "Trenger vi transformasjonslogikk?"
|
||||
│ ├─ SIMPLE (format conversion) → ✅ Shortcut Transformations
|
||||
│ └─ COMPLEX (business logic) → ❌ ETL → Silver/Gold Delta
|
||||
│
|
||||
└─ NO → "Trenger vi data isolasjon (compliance)?"
|
||||
├─ YES → ❌ Copy data til separate Lakehouse
|
||||
└─ NO → ✅ Internal shortcut (hvis multi-workspace sharing)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Common Pitfalls og Mitigations
|
||||
|
||||
| Pitfall | Symptom | Mitigation |
|
||||
|---------|---------|------------|
|
||||
| **Shortcut til non-Delta files i Tables/ folder** | Lakehouse doesn't recognize as table | Use Files/ folder or convert to Delta first |
|
||||
| **Space characters i shortcut name (Delta target)** | Table discovery fails | Rename shortcut without spaces |
|
||||
| **DirectLake over SQL med internal shortcuts** | RLS ikke enforced (owner's identity used) | Switch to DirectLake over OneLake mode |
|
||||
| **Cross-region shortcuts med OneLake security** | 404 errors | Copy data in-region or use workspace-level access (ikke OneLake security) |
|
||||
| **B2B guest users i OneLake security roles** | Access denied (distribution list ikke resolved) | Configure Entra External ID: "Guest users same access as members" |
|
||||
| **Shortcut caching ikke enabled** | High S3 egress costs | Workspace settings → OneLake → Enable cache (28 days) |
|
||||
| **Shortcut til files > 1 GB med caching** | Caching doesn't work | Split files into < 1 GB chunks or disable caching (rely on source SLA) |
|
||||
|
||||
---
|
||||
|
||||
### Shortcut Design Patterns (Cosmo's Checklist)
|
||||
|
||||
#### Pattern 1: Federated Data Mesh
|
||||
**Scenario:** 5 domains (HR, Finance, Marketing, Sales, Operations) — hver har egen Lakehouse.
|
||||
|
||||
**Architecture:**
|
||||
```
|
||||
Domain Lakehouses (per team)
|
||||
├── HR_Lakehouse
|
||||
│ └── Tables/Employees.delta
|
||||
├── Finance_Lakehouse
|
||||
│ └── Tables/Transactions.delta
|
||||
└── Marketing_Lakehouse
|
||||
└── Tables/Campaigns.delta
|
||||
|
||||
Central Analytics Lakehouse
|
||||
├── Files/
|
||||
│ ├── HR_Shortcut → HR_Lakehouse/Tables/Employees
|
||||
│ ├── Finance_Shortcut → Finance_Lakehouse/Tables/Transactions
|
||||
│ └── Marketing_Shortcut → Marketing_Lakehouse/Tables/Campaigns
|
||||
└── Tables/
|
||||
└── UnifiedCustomerView.delta (joins via Spark)
|
||||
```
|
||||
|
||||
**Governance:**
|
||||
- Domain teams kontrollerer OneLake security på egne Lakehouses
|
||||
- Central team har Read-only shortcuts
|
||||
- Lineage tracked via workspace lineage view
|
||||
|
||||
---
|
||||
|
||||
#### Pattern 2: Multi-Cloud Data Lake
|
||||
**Scenario:** Legacy data i AWS S3, new data i Azure Data Lake, reports i SharePoint.
|
||||
|
||||
**Architecture:**
|
||||
```
|
||||
Unified_Lakehouse
|
||||
├── Files/
|
||||
│ ├── AWS_S3_Shortcut/ (external, cached 28 days)
|
||||
│ ├── Azure_ADLS_Shortcut/ (external, delegated)
|
||||
│ └── SharePoint_Shortcut/ (external, OneDrive connector)
|
||||
└── Tables/
|
||||
└── ConsolidatedView.delta (Shortcut Transformation from S3 CSVs)
|
||||
```
|
||||
|
||||
**Cost optimization:**
|
||||
- S3 caching → 95% egress reduction
|
||||
- ADLS in same region (West Europe) → no egress
|
||||
- SharePoint: low volume (<10 GB) → minimal cost
|
||||
|
||||
---
|
||||
|
||||
#### Pattern 3: RAG-Optimized Data Lake
|
||||
**Scenario:** Copilot Studio Generative Answers over product manuals (PDF), support tickets (SQL), chat transcripts (Dataverse).
|
||||
|
||||
**Architecture:**
|
||||
```
|
||||
RAG_Lakehouse
|
||||
├── Files/
|
||||
│ ├── Manuals_S3_Shortcut/ (PDFs, external)
|
||||
│ ├── Tickets_SQL_Shortcut/ (internal, Warehouse)
|
||||
│ └── Chats_Dataverse_Shortcut/ (external, delegated)
|
||||
└── Tables/
|
||||
├── ChunkedDocuments.delta (Spark: chunk PDFs → 512 tokens)
|
||||
├── Embeddings.delta (Azure OpenAI text-embedding-3-large)
|
||||
└── Metadata.delta (source tracking for citation)
|
||||
```
|
||||
|
||||
**Azure AI Search:**
|
||||
- OneLake shortcut til Embeddings.delta
|
||||
- Indexed OneLake Knowledge Source
|
||||
- Copilot Studio → Generative Answers → AI Search
|
||||
|
||||
**Benefits:**
|
||||
- Single source of truth (no data duplication)
|
||||
- OneLake security → AI Search access control
|
||||
- Automatic refresh (OneLake changes → AI Search re-indexes)
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
### Microsoft Learn (offisiell dokumentasjon)
|
||||
1. **OneLake shortcuts** — https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts (fetched 2026-02-11)
|
||||
2. **OneLake security access control model** — https://learn.microsoft.com/en-us/fabric/onelake/security/data-access-control-model (fetched 2026-02-11)
|
||||
3. **OneLake shortcut security** — https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcut-security
|
||||
4. **Shortcut Transformations (File)** — https://learn.microsoft.com/en-us/fabric/onelake/shortcuts-file-transformations/transformations
|
||||
5. **Get started with OneLake security (preview)** — https://learn.microsoft.com/en-us/fabric/onelake/security/get-started-onelake-security
|
||||
6. **OneLake access with APIs** — https://learn.microsoft.com/en-us/fabric/onelake/onelake-access-api
|
||||
7. **Azure AI Search: OneLake knowledge source** — https://learn.microsoft.com/en-us/azure/search/agentic-knowledge-source-how-to-onelake
|
||||
8. **Azure Machine Learning: OneLake Datastore** — https://learn.microsoft.com/en-us/azure/machine-learning/how-to-datastore?view=azureml-api-2#create-a-onelake-datastore
|
||||
9. **Integrate Direct Lake security** — https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-security-integration
|
||||
10. **Medallion lakehouse architecture** — https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture
|
||||
11. **Query acceleration for OneLake shortcuts** — https://learn.microsoft.com/en-us/fabric/real-time-intelligence/query-acceleration-overview
|
||||
|
||||
### Code Samples (verified)
|
||||
- **Python:** OneLakeDatastore creation (azure-ai-ml SDK)
|
||||
- **TypeScript:** OneLakeShortcutClient usage (Fabric extensibility toolkit)
|
||||
- **Python:** DuckDB Iceberg REST catalog over OneLake
|
||||
- **KQL:** external_table function for shortcut queries
|
||||
|
||||
### Confidence Markers
|
||||
- **Storage tier pricing ($0.023/GB HOT):** High confidence (based on Azure Storage pricing, OneLake parity)
|
||||
- **Shortcut limits (100k per item):** High confidence (Microsoft Learn documentation)
|
||||
- **OneLake security latency (5 min role changes, 1 hour group membership):** High confidence (official docs)
|
||||
- **Cross-region shortcuts not supported:** Medium confidence (preview limitation, may change in GA)
|
||||
- **Caching cost reduction (90%+):** High confidence (based on S3 egress pricing calculator)
|
||||
|
||||
### Sist verifisert
|
||||
- 2026-02-11 (11 Microsoft Learn-kilder, 15 code samples)
|
||||
- Neste review anbefales: 2026-05 (etter Build 2026 for OneLake security GA announcements)
|
||||
|
|
@ -0,0 +1,394 @@
|
|||
# Real-Time Streaming for AI Applications
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Sanntidsdatastrømming er en fundamental byggestein for AI-applikasjoner som krever umiddelbar respons på hendelser -- fra IoT-sensorer og transaksjoner til brukeratferd og systemmetrikker. Microsoft Fabric Real-Time Intelligence kombinert med Azure Event Hubs og Apache Kafka gir en komplett plattform for inntak, transformasjon og analyse av strømmedata som mater AI-modeller med oppdatert informasjon.
|
||||
|
||||
For norsk offentlig sektor er sanntidsarkitektur særlig relevant for trafikkmonitorering (Statens vegvesen), helseovervåking, energistyring og beredskapsrespons. Evnen til å oppdage avvik i sanntid og utløse automatiserte handlinger basert på AI-prediksjoner kan redusere responstider dramatisk og forbedre tjenestekvalitet.
|
||||
|
||||
Denne referansen dekker arkitekturmønstre for å integrere Event Hubs, Kafka og Fabric Eventstream med AI-applikasjoner, inkludert Spark Structured Streaming, KQL Database for tidsserieanalyse, og mønster for hendelsesfiltrering og avledede strømmer.
|
||||
|
||||
---
|
||||
|
||||
## Eventstream Connectors and Topologies
|
||||
|
||||
### Fabric Eventstream Overview
|
||||
|
||||
Microsoft Fabric Eventstream er en fullstendig administrert hendelsesinntak- og strømmetjeneste som muliggjør sanntidsdatabehandling uten kode.
|
||||
|
||||
| Kilde-type | Eksempler | Autentisering |
|
||||
|---|---|---|
|
||||
| Microsoft-kilder | Azure Event Hubs, Azure IoT Hub, Azure Service Bus | Managed identity, SAS |
|
||||
| Database CDC | Azure SQL DB, PostgreSQL, MySQL, Cosmos DB, SQL MI | Connection string |
|
||||
| Kafka-kilder | Confluent Cloud, Apache Kafka, Amazon MSK | SASL/PLAIN, OAuth |
|
||||
| Andre skyer | Amazon Kinesis, Google Cloud Pub/Sub | IAM credentials |
|
||||
| Fabric-hendelser | Workspace item events, Blob Storage events | Built-in |
|
||||
|
||||
### Topology Patterns
|
||||
|
||||
```
|
||||
┌──────────────┐
|
||||
IoT Hub ────────>│ │────> KQL Database (tidsserier)
|
||||
│ │
|
||||
Event Hubs ─────>│ Eventstream │────> Lakehouse (Delta tables)
|
||||
│ │
|
||||
Kafka ──────────>│ (Filter + │────> Spark Notebook (ML)
|
||||
│ Transform) │
|
||||
CDC (SQL) ──────>│ │────> Derived Stream (Real-Time Hub)
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
### Konfigurere Event Hubs som kilde
|
||||
|
||||
```python
|
||||
# Eventstream configuration via Fabric UI or API
|
||||
# Event Hub connection parameters
|
||||
event_hub_config = {
|
||||
"namespace": "my-eventhub-ns.servicebus.windows.net",
|
||||
"event_hub": "ai-telemetry",
|
||||
"consumer_group": "$Default",
|
||||
"data_format": "Json",
|
||||
"authentication": "SharedAccessKey"
|
||||
}
|
||||
```
|
||||
|
||||
### Destinasjoner
|
||||
|
||||
Eventstream støtter flere destinasjoner parallelt:
|
||||
|
||||
| Destinasjon | Bruksområde | Latens |
|
||||
|---|---|---|
|
||||
| **Eventhouse (KQL Database)** | Tidsserieanalyse, ad-hoc-spørringer | Sekunder |
|
||||
| **Lakehouse** | Historisk analyse, Delta Lake lagring | Minutter |
|
||||
| **Spark Notebook** | Sanntids ML-inferens | Sekunder |
|
||||
| **Derived Stream** | Viderefordeling til andre forbrukere | Sub-sekund |
|
||||
| **Fabric Activator** | Automatiserte handlinger og varsler | Sekunder |
|
||||
| **Custom Endpoint** | Ekstern applikasjonsintegrasjon | Variabel |
|
||||
|
||||
---
|
||||
|
||||
## Structured Streaming with Spark
|
||||
|
||||
### Spark Structured Streaming i Fabric
|
||||
|
||||
Fabric Notebooks kan lese direkte fra Eventstream via Spark Structured Streaming uten manuell tilkoblingskonfigurasjon.
|
||||
|
||||
```python
|
||||
# Les strømmende data fra Eventstream i Fabric Notebook
|
||||
# Parameter-verdier settes automatisk via "Read with Spark" i UI
|
||||
|
||||
df_stream = (
|
||||
spark.readStream
|
||||
.format("fabricEventStream")
|
||||
.option("eventstream.itemid", "<auto-populated>")
|
||||
.option("eventstream.datasourceid", "<auto-populated>")
|
||||
.load()
|
||||
)
|
||||
|
||||
# Vis skjema
|
||||
df_stream.printSchema()
|
||||
```
|
||||
|
||||
### Transformasjoner på strømmende data
|
||||
|
||||
```python
|
||||
from pyspark.sql.functions import col, window, avg, count, from_json
|
||||
from pyspark.sql.types import StructType, StringType, DoubleType, TimestampType
|
||||
|
||||
# Definer skjema for innkommende JSON
|
||||
schema = StructType() \
|
||||
.add("sensorId", StringType()) \
|
||||
.add("temperature", DoubleType()) \
|
||||
.add("humidity", DoubleType()) \
|
||||
.add("timestamp", TimestampType())
|
||||
|
||||
# Parse JSON og beregn vindusaggregater
|
||||
parsed_stream = (
|
||||
df_stream
|
||||
.select(from_json(col("body").cast("string"), schema).alias("data"))
|
||||
.select("data.*")
|
||||
)
|
||||
|
||||
# 5-minutters glidende vindu med aggregater
|
||||
windowed_aggregates = (
|
||||
parsed_stream
|
||||
.withWatermark("timestamp", "10 minutes")
|
||||
.groupBy(
|
||||
window(col("timestamp"), "5 minutes", "1 minute"),
|
||||
col("sensorId")
|
||||
)
|
||||
.agg(
|
||||
avg("temperature").alias("avg_temp"),
|
||||
avg("humidity").alias("avg_humidity"),
|
||||
count("*").alias("event_count")
|
||||
)
|
||||
)
|
||||
```
|
||||
|
||||
### Skrive til Delta Lake (Lakehouse)
|
||||
|
||||
```python
|
||||
# Skriv strømmede data til Delta-tabell med optimalisering
|
||||
query = (
|
||||
windowed_aggregates
|
||||
.writeStream
|
||||
.format("delta")
|
||||
.outputMode("append")
|
||||
.option("checkpointLocation", "Tables/_checkpoints/sensor_agg")
|
||||
.trigger(processingTime="1 minute") # Batch hvert minutt
|
||||
.toTable("sensor_aggregates")
|
||||
)
|
||||
|
||||
query.awaitTermination()
|
||||
```
|
||||
|
||||
### Optimalisering av strømmeskrivinger
|
||||
|
||||
| Teknikk | Beskrivelse | Anbefalt bruk |
|
||||
|---|---|---|
|
||||
| **Trigger interval** | `processingTime="1 minute"` batches hendelser | Reduserer små filer |
|
||||
| **Optimized Write** | `spark.databricks.delta.optimizeWrite.enabled` | Automatisk filstørrelsesoptimalisering |
|
||||
| **Partitioning** | `partitionBy("date", "sensorId")` | Når filtrering på partisjonsnøkler er vanlig |
|
||||
| **Repartition** | `repartition(48)` før skriving | Parallellisering over CPU-kjerner |
|
||||
| **Coalesce** | `coalesce(4)` for lav throughput | Unngår for mange små filer |
|
||||
|
||||
---
|
||||
|
||||
## KQL Database for Time-Series Analytics
|
||||
|
||||
### Eventhouse og KQL Database
|
||||
|
||||
KQL Database i Fabric er optimalisert for tidsseriedata og gir sub-sekund spørringsrespons over milliarder av rader.
|
||||
|
||||
```kql
|
||||
// Tidsserieanalyse med KQL
|
||||
// Beregn glidende gjennomsnitt for sensortemperatur
|
||||
SensorData
|
||||
| where Timestamp > ago(24h)
|
||||
| summarize AvgTemp = avg(Temperature) by bin(Timestamp, 5m), SensorId
|
||||
| render timechart
|
||||
```
|
||||
|
||||
```kql
|
||||
// Anomalideteksjon med innebygd series_decompose_anomalies
|
||||
let min_t = ago(7d);
|
||||
let max_t = now();
|
||||
SensorData
|
||||
| make-series AvgTemp = avg(Temperature)
|
||||
on Timestamp from min_t to max_t step 1h
|
||||
by SensorId
|
||||
| extend (anomalies, score, baseline) =
|
||||
series_decompose_anomalies(AvgTemp, 1.5, -1, 'linefit')
|
||||
| mv-expand Timestamp to typeof(datetime),
|
||||
AvgTemp to typeof(double),
|
||||
anomalies to typeof(int),
|
||||
score to typeof(double),
|
||||
baseline to typeof(double)
|
||||
| where anomalies != 0
|
||||
```
|
||||
|
||||
### Sammenligning: KQL Database vs Lakehouse for strømmedata
|
||||
|
||||
| Egenskap | KQL Database | Lakehouse (Delta) |
|
||||
|---|---|---|
|
||||
| **Optimal for** | Tidsserier, logdata, IoT | Strukturert analyse, ML-trening |
|
||||
| **Spørrespråk** | KQL | SQL, PySpark |
|
||||
| **Latens** | Sub-sekund | Sekunder til minutter |
|
||||
| **Retensjon** | Konfigurerbar policy | Ubegrenset (manuell VACUUM) |
|
||||
| **Innebygd ML** | Anomalideteksjon, forecasting | Via notebooks |
|
||||
| **Format** | Proprietært (optimalisert) | Delta Lake (åpent) |
|
||||
| **One Logical Copy** | Ja, til OneLake | Native |
|
||||
|
||||
---
|
||||
|
||||
## Event Filtering and Derived Streams
|
||||
|
||||
### Filtrering i Eventstream
|
||||
|
||||
Eventstream støtter no-code transformasjoner direkte i strømmen:
|
||||
|
||||
- **Filter**: Fjern hendelser basert på betingelser
|
||||
- **Manage Fields**: Velg, omdøp, fjern felt
|
||||
- **Group By**: Aggreger over tidsvindu
|
||||
- **Union**: Kombiner flere strømmer
|
||||
- **Expand**: Flatten nestede strukturer
|
||||
|
||||
### Derived Streams (avledede strømmer)
|
||||
|
||||
```
|
||||
Eventstream (rå data)
|
||||
│
|
||||
├── Filter: temperature > 50 ──> Derived Stream: "high-temp-alerts"
|
||||
│ │
|
||||
│ ├──> Activator (varsling)
|
||||
│ └──> KQL Database
|
||||
│
|
||||
├── Group By: 5min avg ────────> Derived Stream: "sensor-aggregates"
|
||||
│ │
|
||||
│ └──> Lakehouse
|
||||
│
|
||||
└── All events ────────────────> KQL Database (rå logging)
|
||||
```
|
||||
|
||||
### Content-Based Routing
|
||||
|
||||
```python
|
||||
# Pseudo-kode for content-based routing via Spark
|
||||
from pyspark.sql.functions import col
|
||||
|
||||
# Les fra Eventstream
|
||||
raw_stream = spark.readStream.format("fabricEventStream").load()
|
||||
|
||||
# Route basert på hendelsestype
|
||||
critical_events = raw_stream.filter(col("severity") == "CRITICAL")
|
||||
info_events = raw_stream.filter(col("severity") == "INFO")
|
||||
|
||||
# Skriv til forskjellige destinasjoner
|
||||
critical_query = (
|
||||
critical_events.writeStream
|
||||
.format("delta")
|
||||
.toTable("critical_alerts")
|
||||
)
|
||||
|
||||
info_query = (
|
||||
info_events.writeStream
|
||||
.format("delta")
|
||||
.toTable("info_logs")
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Streaming SLAs and Backpressure Handling
|
||||
|
||||
### SLA-dimensjoner for strømmesystemer
|
||||
|
||||
| Dimensjon | Mål | Metric |
|
||||
|---|---|---|
|
||||
| **End-to-end latens** | < 5 sekunder for varsler | P99 latens |
|
||||
| **Throughput** | Minimum events/sek som må håndteres | Events per second |
|
||||
| **Data completeness** | Ingen tapte hendelser | Missing event rate |
|
||||
| **Processing guarantee** | At-least-once eller exactly-once | Delivery semantics |
|
||||
| **Recovery time** | Tid fra feil til normal drift | RTO |
|
||||
|
||||
### Backpressure-strategier
|
||||
|
||||
```python
|
||||
# Spark Structured Streaming med rate limiting
|
||||
query = (
|
||||
df_stream
|
||||
.writeStream
|
||||
.format("delta")
|
||||
.option("maxOffsetsPerTrigger", 10000) # Begrens per batch
|
||||
.trigger(processingTime="30 seconds")
|
||||
.toTable("processed_events")
|
||||
)
|
||||
```
|
||||
|
||||
### Event Hubs Partisjonering for skalering
|
||||
|
||||
```python
|
||||
# Event Hubs partisjonskonfigurasjon
|
||||
# Anbefalt: 4-32 partisjoner avhengig av throughput
|
||||
# Hver partisjon støtter opptil 1 MB/s inntak, 2 MB/s uttak
|
||||
|
||||
# Fabric Eventstream håndterer automatisk partisjonskonsumering
|
||||
# For manuell Kafka-tilgang:
|
||||
kafka_config = {
|
||||
"kafka.bootstrap.servers": "eventstream-xxx.servicebus.windows.net:9093",
|
||||
"subscribe": "es_topic",
|
||||
"kafka.sasl.mechanism": "PLAIN",
|
||||
"kafka.security.protocol": "SASL_SSL",
|
||||
"startingOffsets": "latest",
|
||||
"maxOffsetsPerTrigger": 50000
|
||||
}
|
||||
|
||||
df = spark.readStream.format("kafka").options(**kafka_config).load()
|
||||
```
|
||||
|
||||
### Retry Policy for Spark Job Definitions
|
||||
|
||||
For produksjonsmiljøer anbefales Spark Job Definitions over Notebooks:
|
||||
|
||||
| Parameter | Anbefalt verdi | Begrunnelse |
|
||||
|---|---|---|
|
||||
| **Retry enabled** | Ja | Automatisk gjenstart ved feil |
|
||||
| **Max retries** | Ubegrenset | For kontinuerlige strømmejobber |
|
||||
| **Retry interval** | 60 sekunder | Unngå storm of retries |
|
||||
| **Checkpoint** | Alltid konfigurert | Gjenoppta fra siste posisjon |
|
||||
|
||||
### Monitoring
|
||||
|
||||
Spark Structured Streaming UI gir innebygde metrikker:
|
||||
- Input Rate (hendelser/sekund)
|
||||
- Process Rate (hendelser/sekund)
|
||||
- Batch Duration (ms)
|
||||
- Input Rows per batch
|
||||
- Operation Duration breakdown
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmonstre for AI med sanntidsdata
|
||||
|
||||
### Lambda Architecture (hybrid batch + streaming)
|
||||
|
||||
```
|
||||
┌───────────────────┐
|
||||
│ Event Hubs / │
|
||||
│ Kafka Source │
|
||||
└─────┬────┬────────┘
|
||||
│ │
|
||||
┌───────────┘ └──────────────┐
|
||||
│ │
|
||||
┌────────▼────────┐ ┌─────────▼──────────┐
|
||||
│ Speed Layer │ │ Batch Layer │
|
||||
│ (Eventstream │ │ (Data Factory + │
|
||||
│ + KQL DB) │ │ Lakehouse) │
|
||||
└────────┬─────────┘ └─────────┬──────────┘
|
||||
│ │
|
||||
┌────────▼───────────────────────────────▼──────────┐
|
||||
│ Serving Layer │
|
||||
│ (Power BI, AI Models, REST APIs) │
|
||||
└───────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Kappa Architecture (rent strømmende)
|
||||
|
||||
Forenklet arkitektur der all data behandles som strømmer:
|
||||
|
||||
```
|
||||
Event Source ──> Eventstream ──> Spark Structured Streaming
|
||||
│
|
||||
├──> Delta Table (append-only)
|
||||
├──> ML Inference (real-time)
|
||||
└──> KQL Database (analytics)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Overview of Microsoft Fabric Eventstreams](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/overview) -- Komplett oversikt over Eventstream-kapabiliteter
|
||||
- [Query Eventstream from Notebook with Spark Structured Streaming](https://learn.microsoft.com/en-us/fabric/data-engineering/notebook-with-event-stream) -- Integrasjon mellom Notebook og Eventstream
|
||||
- [Get streaming data into Lakehouse with Spark Structured Streaming](https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-streaming-data) -- Optimalisering av Delta Lake-skrivinger
|
||||
- [What is Real-Time Intelligence?](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/overview) -- Oversikt over Real-Time Intelligence
|
||||
- [Introduction to Fabric Real-Time Hub](https://learn.microsoft.com/en-us/fabric/real-time-hub/real-time-hub-overview) -- Real-Time Hub connectors og integrasjon
|
||||
- [Get events from Azure Event Hubs into Real-Time hub](https://learn.microsoft.com/en-us/fabric/real-time-hub/add-source-azure-event-hubs) -- Event Hubs-kobling
|
||||
- [Add and manage destinations in an Eventstream](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/add-manage-eventstream-destinations) -- Alle støttede destinasjoner
|
||||
- [Get data from Azure Event Hubs](https://learn.microsoft.com/en-us/fabric/real-time-intelligence/get-data-event-hub) -- Direct ingestion til KQL Database
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren trenger sanntidsdatabehandling for AI-modeller, IoT-integrasjon, eller hendelsesdrevet arkitektur på Microsoft Fabric.
|
||||
- Anbefal **Eventstream + KQL Database** for tidsserieanalyse og anomalideteksjon med sub-sekund latens, og **Eventstream + Lakehouse** for historisk ML-trening.
|
||||
- For norsk offentlig sektor: Fremhev at Fabric Eventstream kjorer som SaaS i europeisk region (Norway East/West Europe), noe som forenkler personvernhensyn sammenlignet med selvhostede Kafka-clustere.
|
||||
- Bruk **Spark Job Definitions** (ikke Notebooks) i produksjon for strømmejobber, med retry-policy aktivert for høy tilgjengelighet.
|
||||
- Anbefal **Derived Streams** for å dele sanntidsdata mellom team uten å duplisere infrastruktur -- en enkelt Eventstream kan mate flere destinasjoner med forskjellige transformasjoner.
|
||||
|
|
@ -0,0 +1,479 @@
|
|||
# Schema Evolution and Management
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Skjemaendringer er uunngaaelige i moderne dataarkitekturer: nye kolonner legges til, datatyper endres, kolonner gis nye navn, og foreldede felt fjernes. For AI-pipelines er dette spesielt utfordrende fordi ML-modeller er trent pa spesifikke feature-skjemaer, og enhver skjemaendring kan bryte trenings- og inferens-pipelines. Delta Lake i Microsoft Fabric og Azure Databricks tilbyr robust stotte for skjemaevolusjon som gjor det mulig a haandtere disse endringene uten nedetid.
|
||||
|
||||
Schema enforcement (skjemahindring) sikrer at data som skrives til en tabell matcher forventet skjema, mens schema evolution (skjemaevolusjon) lar tabellskjemaet tilpasse seg nye datastrukturer automatisk. Kombinasjonen av disse to mekanismene gir en kontrollert tilnaerming der daarlig data avvises mens legitime strukturendringer aksepteres.
|
||||
|
||||
For norsk offentlig sektor, der datakvalitet og sporbarhet er lovpalagt, er det kritisk a ha en systematisk tilnaerming til skjemahondtering. Delta Lake sin transaksjonslogg gir full audit trail over alle skjemaendringer, noe som stotter krav i Forvaltningsloven og Arkivlova.
|
||||
|
||||
---
|
||||
|
||||
## Schema Versioning and Compatibility Levels
|
||||
|
||||
### Skjemaevolusjon i Delta Lake
|
||||
|
||||
Delta Lake stotter folgende typer skjemaendringer:
|
||||
|
||||
| Endringstype | Schema Enforcement | Schema Evolution | Kommentar |
|
||||
|-------------|-------------------|-----------------|-----------|
|
||||
| **Ny kolonne** | Blokkerer skriving | Legger til automatisk | Vanligste endring |
|
||||
| **Kolonnenavn-endring** | N/A | Via column mapping | Krever DDL |
|
||||
| **Slettet kolonne** | N/A | Via column mapping | Krever DDL |
|
||||
| **Type-utvidelse** | Blokkerer skriving | Type widening | INT -> BIGINT |
|
||||
| **Type-endring** | Blokkerer skriving | overwriteSchema | Destruktiv |
|
||||
|
||||
### Kompatibilitetsnivaaer
|
||||
|
||||
```
|
||||
+---------------------------------------------------+
|
||||
| BACKWARD COMPATIBLE (trygt) |
|
||||
| - Legge til nye nullable-kolonner |
|
||||
| - Utvide datatyper (INT -> BIGINT -> DOUBLE) |
|
||||
| |
|
||||
| FORWARD COMPATIBLE (krever koordinering) |
|
||||
| - Gi nytt navn til kolonner |
|
||||
| - Fjerne kolonner |
|
||||
| |
|
||||
| BREAKING CHANGES (krever migrasjon) |
|
||||
| - Endre datatype (STRING -> INT) |
|
||||
| - Endre nullability (nullable -> not null) |
|
||||
| - Omstrukturere nesting |
|
||||
+---------------------------------------------------+
|
||||
```
|
||||
|
||||
### Delta Lake Protocol Versions
|
||||
|
||||
Delta Lake bruker protokollversjoner for a kontrollere funksjonskompatibilitet:
|
||||
|
||||
| Feature | minReaderVersion | minWriterVersion | Beskrivelse |
|
||||
|---------|-----------------|-----------------|-------------|
|
||||
| Column Mapping | 2 | 5 | Kolonnenavn-endring og sletting |
|
||||
| Type Widening | 3 | 7 | Automatisk type-utvidelse |
|
||||
| Table Features | 3 | 7 | Granular feature-kontroll |
|
||||
| Liquid Clustering | 2 | 7 | Dynamisk clustering |
|
||||
|
||||
```sql
|
||||
-- Sjekk gjeldende protokollversjoner
|
||||
DESCRIBE DETAIL lakehouse.default.ml_features;
|
||||
|
||||
-- Oppgrader protokoll for a stotte column mapping
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
SET TBLPROPERTIES (
|
||||
'delta.minReaderVersion' = '2',
|
||||
'delta.minWriterVersion' = '5',
|
||||
'delta.columnMapping.mode' = 'name'
|
||||
);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Adding Columns with Default Values
|
||||
|
||||
### Automatisk skjemaevolusjon ved skriving
|
||||
|
||||
```python
|
||||
# Aktiver schema evolution for en skriveoperasjon
|
||||
df_with_new_column = df.withColumn("weather_score", F.lit(0.0))
|
||||
|
||||
# Med mergeSchema: Legger til ny kolonne automatisk
|
||||
df_with_new_column.write \
|
||||
.format("delta") \
|
||||
.option("mergeSchema", "true") \
|
||||
.mode("append") \
|
||||
.saveAsTable("lakehouse.default.ml_features")
|
||||
```
|
||||
|
||||
### Legge til kolonner via DDL
|
||||
|
||||
```sql
|
||||
-- Legg til ny kolonne med kommentar
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
ADD COLUMN weather_score DOUBLE
|
||||
COMMENT 'Vaerscore 0-1 for prediksjonskvalitet';
|
||||
|
||||
-- Legg til flere kolonner samtidig
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
ADD COLUMNS (
|
||||
model_version STRING COMMENT 'Versjon av ML-modellen',
|
||||
confidence_score DOUBLE COMMENT 'Konfidensintervall 0-1',
|
||||
processing_timestamp TIMESTAMP COMMENT 'Tidspunkt for prosessering'
|
||||
);
|
||||
|
||||
-- Legg til kolonne med generert verdi
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
ADD COLUMN year_month STRING
|
||||
GENERATED ALWAYS AS (DATE_FORMAT(created_date, 'yyyy-MM'));
|
||||
```
|
||||
|
||||
### Backfill av nye kolonner
|
||||
|
||||
```python
|
||||
from delta.tables import DeltaTable
|
||||
|
||||
def backfill_column(table_name, column_name, default_value=None, compute_func=None):
|
||||
"""
|
||||
Fyll ny kolonne med verdier for eksisterende rader.
|
||||
|
||||
Args:
|
||||
table_name: Tabellnavn
|
||||
column_name: Kolonnenavn
|
||||
default_value: Statisk standardverdi
|
||||
compute_func: Funksjon for a beregne verdi basert pa andre kolonner
|
||||
"""
|
||||
delta_table = DeltaTable.forName(spark, table_name)
|
||||
|
||||
if default_value is not None:
|
||||
delta_table.update(
|
||||
condition=F.col(column_name).isNull(),
|
||||
set={column_name: F.lit(default_value)}
|
||||
)
|
||||
elif compute_func is not None:
|
||||
delta_table.update(
|
||||
condition=F.col(column_name).isNull(),
|
||||
set={column_name: compute_func}
|
||||
)
|
||||
|
||||
# Eksempler
|
||||
# Statisk standardverdi
|
||||
backfill_column("lakehouse.default.ml_features", "weather_score", default_value=0.5)
|
||||
|
||||
# Beregnet verdi basert pa andre kolonner
|
||||
backfill_column(
|
||||
"lakehouse.default.ml_features",
|
||||
"confidence_score",
|
||||
compute_func=F.when(F.col("prediction_count") > 100, 0.9).otherwise(0.5)
|
||||
)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Type Promotions and Narrowing
|
||||
|
||||
### Stottede type-utvidelser (Type Widening)
|
||||
|
||||
Delta Lake stotter folgende trygge type-utvidelser:
|
||||
|
||||
| Fra | Til | Automatisk | Kommentar |
|
||||
|-----|-----|-----------|-----------|
|
||||
| BYTE | SHORT | Ja | Uten datatap |
|
||||
| SHORT | INT | Ja | Uten datatap |
|
||||
| INT | LONG | Ja | Uten datatap |
|
||||
| LONG | DECIMAL | Betinget | Desimalbredde ma vaere tilstrekkelig |
|
||||
| FLOAT | DOUBLE | Ja | Uten datatap |
|
||||
| DATE | TIMESTAMP | Ja | Legger til tid 00:00:00 |
|
||||
| DECIMAL(p,s) | DECIMAL(p',s') | Ja | Hvis p'>=p og s'>=s |
|
||||
|
||||
```sql
|
||||
-- Aktiver type widening pa tabellen
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
SET TBLPROPERTIES ('delta.enableTypeWidening' = 'true');
|
||||
|
||||
-- Na kan du skrive data med bredere typer
|
||||
-- F.eks. INT-kolonner aksepterer LONG-verdier automatisk
|
||||
```
|
||||
|
||||
### Type-utvidelse med Schema Evolution
|
||||
|
||||
```python
|
||||
# Automatisk type-utvidelse under merge
|
||||
spark.conf.set("spark.databricks.delta.schema.autoMerge.enabled", "true")
|
||||
|
||||
# Na vil en DataFrame med LONG-verdi for en INT-kolonne
|
||||
# automatisk utvide kolonnetypen
|
||||
df_new = spark.createDataFrame([
|
||||
(1, 3000000000, "test") # 3 milliarder overskrider INT
|
||||
], ["id", "large_count", "name"])
|
||||
|
||||
# Merge med schema evolution og type widening
|
||||
delta_table = DeltaTable.forName(spark, "lakehouse.default.counts")
|
||||
delta_table.alias("target").merge(
|
||||
df_new.alias("source"),
|
||||
"target.id = source.id"
|
||||
).whenMatchedUpdateAll() \
|
||||
.whenNotMatchedInsertAll() \
|
||||
.execute()
|
||||
```
|
||||
|
||||
### Type-innsnevring (farlig)
|
||||
|
||||
Type-innsnevring (f.eks. LONG -> INT) kan fore til datatap og krever full overskriving:
|
||||
|
||||
```python
|
||||
# ADVARSEL: Dette overskriver hele tabellskjemaet
|
||||
df_narrowed = spark.table("lakehouse.default.legacy_table") \
|
||||
.withColumn("count_col", F.col("count_col").cast("int"))
|
||||
|
||||
df_narrowed.write \
|
||||
.format("delta") \
|
||||
.option("overwriteSchema", "true") \
|
||||
.mode("overwrite") \
|
||||
.saveAsTable("lakehouse.default.legacy_table")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Deprecated Column Handling
|
||||
|
||||
### Column Mapping for sikker kolonnefjerning
|
||||
|
||||
```sql
|
||||
-- Aktiver column mapping (kreves for rename/drop)
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
SET TBLPROPERTIES (
|
||||
'delta.columnMapping.mode' = 'name'
|
||||
);
|
||||
|
||||
-- Gi nytt navn til en kolonne
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
RENAME COLUMN old_feature_name TO new_feature_name;
|
||||
|
||||
-- Slett en kolonne (logisk, ingen data-omskriving)
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
DROP COLUMN deprecated_feature;
|
||||
|
||||
-- Slett flere kolonner
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
DROP COLUMNS (temp_col1, temp_col2, debug_flag);
|
||||
```
|
||||
|
||||
### Soft Deprecation-moenster
|
||||
|
||||
For gradvis utfasing av kolonner i AI-pipelines:
|
||||
|
||||
```python
|
||||
# Trinn 1: Merk kolonne som deprecated via kommentar
|
||||
spark.sql("""
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
ALTER COLUMN old_score COMMENT 'DEPRECATED: Bruk new_score i stedet. Fjernes 2026-06-01.'
|
||||
""")
|
||||
|
||||
# Trinn 2: Legg til ny kolonne med forbedret logikk
|
||||
spark.sql("""
|
||||
ALTER TABLE lakehouse.default.ml_features
|
||||
ADD COLUMN new_score DOUBLE COMMENT 'Erstatter old_score med forbedret beregning'
|
||||
""")
|
||||
|
||||
# Trinn 3: Backfill ny kolonne
|
||||
delta_table = DeltaTable.forName(spark, "lakehouse.default.ml_features")
|
||||
delta_table.update(
|
||||
set={"new_score": F.col("old_score") * 1.1} # Eksempel: justert beregning
|
||||
)
|
||||
|
||||
# Trinn 4: Oppdater downstream-pipelines til a bruke new_score
|
||||
# (Gjoeres over tid, ikke alt pa en gang)
|
||||
|
||||
# Trinn 5: Etter overgangsperiode - fjern gammel kolonne
|
||||
# spark.sql("ALTER TABLE lakehouse.default.ml_features DROP COLUMN old_score")
|
||||
```
|
||||
|
||||
### Kolonneregistrering for ML Feature Store
|
||||
|
||||
```python
|
||||
# Hold styr pa hvilke kolonner som er aktive, deprecated, eller fjernet
|
||||
feature_registry = {
|
||||
"ml_features": {
|
||||
"active": [
|
||||
{"name": "traffic_volume", "type": "DOUBLE", "since": "2025-01"},
|
||||
{"name": "weather_score", "type": "DOUBLE", "since": "2025-06"},
|
||||
{"name": "road_condition_index", "type": "DOUBLE", "since": "2025-03"},
|
||||
{"name": "new_score", "type": "DOUBLE", "since": "2026-01"}
|
||||
],
|
||||
"deprecated": [
|
||||
{"name": "old_score", "type": "DOUBLE", "since": "2025-01",
|
||||
"deprecated_date": "2026-01", "removal_date": "2026-06",
|
||||
"replacement": "new_score"}
|
||||
],
|
||||
"removed": [
|
||||
{"name": "temp_debug_col", "type": "STRING",
|
||||
"removed_date": "2025-12", "reason": "Debug-kolonne, ikke lenger noedvendig"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Schema Registration and Validation
|
||||
|
||||
### Skjemavalidering i pipelines
|
||||
|
||||
```python
|
||||
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, TimestampType, LongType
|
||||
|
||||
def validate_schema(df, expected_schema: StructType, strict: bool = False):
|
||||
"""
|
||||
Valider at en DataFrame matcher forventet skjema.
|
||||
|
||||
Args:
|
||||
df: DataFrame a validere
|
||||
expected_schema: Forventet StructType
|
||||
strict: Hvis True, avvis ekstra kolonner. Hvis False, tillat ekstra.
|
||||
"""
|
||||
actual_fields = {f.name: f for f in df.schema.fields}
|
||||
expected_fields = {f.name: f for f in expected_schema.fields}
|
||||
|
||||
errors = []
|
||||
|
||||
# Sjekk at alle forventede kolonner finnes
|
||||
for name, expected_field in expected_fields.items():
|
||||
if name not in actual_fields:
|
||||
errors.append(f"Mangler kolonne: {name} ({expected_field.dataType})")
|
||||
else:
|
||||
actual_field = actual_fields[name]
|
||||
# Sjekk datatype
|
||||
if actual_field.dataType != expected_field.dataType:
|
||||
errors.append(
|
||||
f"Type-mismatch for '{name}': "
|
||||
f"forventet {expected_field.dataType}, fikk {actual_field.dataType}"
|
||||
)
|
||||
# Sjekk nullability
|
||||
if not expected_field.nullable and actual_field.nullable:
|
||||
errors.append(
|
||||
f"Nullability-mismatch for '{name}': "
|
||||
f"forventet NOT NULL, fikk NULLABLE"
|
||||
)
|
||||
|
||||
# Sjekk for uventede kolonner
|
||||
if strict:
|
||||
extra_cols = set(actual_fields.keys()) - set(expected_fields.keys())
|
||||
if extra_cols:
|
||||
errors.append(f"Uventede kolonner: {extra_cols}")
|
||||
|
||||
return {
|
||||
"valid": len(errors) == 0,
|
||||
"errors": errors,
|
||||
"actual_columns": len(actual_fields),
|
||||
"expected_columns": len(expected_fields)
|
||||
}
|
||||
|
||||
# Definer forventet skjema for ML features
|
||||
expected_feature_schema = StructType([
|
||||
StructField("entity_id", StringType(), nullable=False),
|
||||
StructField("feature_timestamp", TimestampType(), nullable=False),
|
||||
StructField("traffic_volume", DoubleType(), nullable=True),
|
||||
StructField("weather_score", DoubleType(), nullable=True),
|
||||
StructField("road_condition_index", DoubleType(), nullable=True),
|
||||
StructField("prediction_target", DoubleType(), nullable=False)
|
||||
])
|
||||
|
||||
# Valider incoming data
|
||||
result = validate_schema(incoming_df, expected_feature_schema, strict=False)
|
||||
if not result["valid"]:
|
||||
raise ValueError(f"Skjemavalidering feilet: {result['errors']}")
|
||||
```
|
||||
|
||||
### Schema evolution i Structured Streaming
|
||||
|
||||
```python
|
||||
# Auto Loader med skjemaevolusjon
|
||||
df_stream = spark.readStream \
|
||||
.format("cloudFiles") \
|
||||
.option("cloudFiles.format", "json") \
|
||||
.option("cloudFiles.schemaLocation", "/checkpoints/schema/") \
|
||||
.option("cloudFiles.schemaEvolutionMode", "addNewColumns") \
|
||||
.option("cloudFiles.schemaHints", "event_id STRING, timestamp TIMESTAMP") \
|
||||
.load("/landing/events/")
|
||||
|
||||
# Skriv med schema evolution aktivert
|
||||
df_stream.writeStream \
|
||||
.format("delta") \
|
||||
.option("checkpointLocation", "/checkpoints/events/") \
|
||||
.option("mergeSchema", "true") \
|
||||
.outputMode("append") \
|
||||
.toTable("lakehouse.default.events")
|
||||
```
|
||||
|
||||
### Schema evolution per komponent-oversikt
|
||||
|
||||
| Komponent | Nye kolonner | Rename | Drop | Type-utvidelse |
|
||||
|-----------|-------------|--------|------|---------------|
|
||||
| **Auto Loader** | Ja (restart) | Ja (restart) | Ja (soft delete) | Nei |
|
||||
| **Delta Connector** | Ja (mergeSchema) | Ja (column mapping) | Ja (column mapping) | Ja (type widening) |
|
||||
| **Streaming Tables** | Ja (auto) | Ja (auto) | Ja (soft delete) | Ja (type widening) |
|
||||
| **Materialized Views** | Full recompute | Full recompute | Full recompute | Full recompute |
|
||||
| **Delta Tables** | Ja (auto/DDL) | Ja (DDL) | Ja (DDL) | Ja (auto/DDL) |
|
||||
|
||||
### Skjemamigrasjon for ML-modeller
|
||||
|
||||
```python
|
||||
class SchemaVersionManager:
|
||||
"""
|
||||
Holder styr pa skjemaversjoner og sikrer at ML-modeller
|
||||
bruker kompatible skjemaer.
|
||||
"""
|
||||
|
||||
def __init__(self, registry_table="lakehouse.default.schema_registry"):
|
||||
self.registry_table = registry_table
|
||||
|
||||
def register_schema(self, table_name: str, version: str, schema: StructType):
|
||||
"""Registrer en ny skjemaversjon."""
|
||||
schema_json = schema.json()
|
||||
spark.sql(f"""
|
||||
INSERT INTO {self.registry_table}
|
||||
VALUES ('{table_name}', '{version}', '{schema_json}',
|
||||
current_timestamp(), true)
|
||||
""")
|
||||
|
||||
def get_schema(self, table_name: str, version: str = None) -> StructType:
|
||||
"""Hent skjema for en spesifikk versjon (eller siste)."""
|
||||
if version:
|
||||
row = spark.sql(f"""
|
||||
SELECT schema_json FROM {self.registry_table}
|
||||
WHERE table_name = '{table_name}' AND version = '{version}'
|
||||
""").first()
|
||||
else:
|
||||
row = spark.sql(f"""
|
||||
SELECT schema_json FROM {self.registry_table}
|
||||
WHERE table_name = '{table_name}' AND is_current = true
|
||||
""").first()
|
||||
|
||||
return StructType.fromJson(json.loads(row.schema_json))
|
||||
|
||||
def check_compatibility(self, table_name: str, new_schema: StructType) -> dict:
|
||||
"""Sjekk om nytt skjema er bakoverkompatibelt."""
|
||||
current = self.get_schema(table_name)
|
||||
current_fields = {f.name: f for f in current.fields}
|
||||
new_fields = {f.name: f for f in new_schema.fields}
|
||||
|
||||
added = set(new_fields.keys()) - set(current_fields.keys())
|
||||
removed = set(current_fields.keys()) - set(new_fields.keys())
|
||||
|
||||
is_backward_compatible = len(removed) == 0
|
||||
|
||||
return {
|
||||
"backward_compatible": is_backward_compatible,
|
||||
"added_columns": list(added),
|
||||
"removed_columns": list(removed),
|
||||
"recommendation": "SAFE" if is_backward_compatible else "BREAKING - koordiner med downstream"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Schema evolution in Azure Databricks](https://learn.microsoft.com/en-us/azure/databricks/data-engineering/schema-evolution) -- Komplett guide til skjemaevolusjon
|
||||
- [What is Delta Lake?](https://learn.microsoft.com/en-us/azure/synapse-analytics/spark/apache-spark-what-is-delta-lake) -- Delta Lake features inkludert schema enforcement og evolution
|
||||
- [Delta Lake feature compatibility](https://learn.microsoft.com/en-us/azure/databricks/delta/feature-compatibility) -- Protokollversjoner og table features
|
||||
- [Schema enforcement](https://learn.microsoft.com/en-us/azure/databricks/tables/schema-enforcement) -- Skjemahondtering pa skrivetidspunktet
|
||||
- [Column mapping](https://learn.microsoft.com/en-us/azure/databricks/delta/column-mapping) -- Rename og drop av kolonner
|
||||
- [Type widening](https://learn.microsoft.com/en-us/azure/databricks/delta/type-widening) -- Automatisk type-utvidelse
|
||||
- [Update Delta Lake table schema](https://learn.microsoft.com/en-us/azure/databricks/delta/update-schema) -- DDL og mergeSchema
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** naar kunder haandterer skjemaendringer i Delta Lake-tabeller, eller naar de trenger strategier for skjemaversjonering i ML-pipelines.
|
||||
- **Schema enforcement + evolution er komplementaere**: Enforcement hindrer daarlig data, evolution lar skjemaet vokse. Aktiver begge for AI-datatabeller.
|
||||
- **Column mapping er pabudt** for rename/drop-operasjoner. Aktiver det tidlig pa tabeller som vil utvikle seg over tid.
|
||||
- **Type widening er trygt for analytics**: INT -> BIGINT og FLOAT -> DOUBLE er trygge operasjoner. Type-innsnevring bor aldri gjores automatisk.
|
||||
- **For norsk offentlig sektor**: Fremhev at Delta Lake sin transaksjonslogg gir full sporbarhet over alle skjemaendringer, noe som stotter Arkivlovas krav til dokumentasjon av dataendringer.
|
||||
|
|
@ -0,0 +1,425 @@
|
|||
# Synthetic Data Generation for AI Training
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA / Preview (varies by feature)
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Syntetisk datagenerering er en stadig viktigere teknikk for AI-utvikling, spesielt i situasjoner der reelle data er begrenset, ubalansert, eller underlagt strenge personvernkrav. Ved å generere kunstige datasett som etterligner statistiske egenskaper ved reelle data, kan organisasjoner utvide treningsdata, adressere klasseimbalanser, og beskytte personvern -- uten å eksponere faktiske sensitive opplysninger.
|
||||
|
||||
For norsk offentlig sektor er syntetisk data spesielt relevant fordi tilgangen til treningsdata ofte er begrenset av GDPR, taushetsplikt og sikkerhetsklassifiseringer. Helsesektoren kan ikke dele pasientdata fritt, veisektoren har begrensninger på GPS-spor, og NAV har strenge regler for bruk av personopplysninger i maskinlæring. Syntetisk data tilbyr en lovlig vei til å bygge AI-modeller uten å bryte disse begrensningene.
|
||||
|
||||
Denne referansen dekker Azure AI Evaluation SDK sin Simulator-klasse for syntetisk datagenerering, integrasjon med Azure OpenAI for tekstsyntese, teknikker for klassebalansering, personvernbevarende syntetiske data, og validering av syntetisk datakvalitet.
|
||||
|
||||
---
|
||||
|
||||
## Synthetic Data Generation Pipelines
|
||||
|
||||
### Azure AI Evaluation SDK Simulator
|
||||
|
||||
Azure AI Evaluation SDK inneholder en `Simulator`-klasse (preview) som genererer syntetiske samtaler og oppgavebaserte interaksjoner:
|
||||
|
||||
```python
|
||||
# Installasjon
|
||||
# pip install azure-identity azure-ai-evaluation promptflow-azure
|
||||
|
||||
from azure.ai.evaluation.simulator import Simulator
|
||||
|
||||
# Konfigurer modell
|
||||
model_config = {
|
||||
"azure_endpoint": "https://<endpoint>.openai.azure.com/",
|
||||
"azure_deployment": "gpt-4o",
|
||||
"api_version": "2024-12-01-preview"
|
||||
}
|
||||
|
||||
simulator = Simulator(model_config=model_config)
|
||||
```
|
||||
|
||||
### Generer fra tekst-input
|
||||
|
||||
```python
|
||||
import wikipedia
|
||||
|
||||
# Hent kildedokument
|
||||
wiki_page = wikipedia.page("Norwegian Public Roads Administration")
|
||||
source_text = wiki_page.summary[:5000]
|
||||
|
||||
# Generer syntetiske spørsmål-svar-par
|
||||
outputs = await simulator(
|
||||
target=my_callback_function,
|
||||
text=source_text,
|
||||
num_queries=50,
|
||||
max_conversation_turns=3,
|
||||
tasks=[
|
||||
f"Svar på spørsmål basert på følgende tekst:\n{source_text}"
|
||||
]
|
||||
)
|
||||
|
||||
# Resultater i OpenAI messages-format
|
||||
for conversation in outputs:
|
||||
for message in conversation["messages"]:
|
||||
print(f"{message['role']}: {message['content'][:100]}...")
|
||||
```
|
||||
|
||||
### Microsoft Foundry Synthetic Data (Preview)
|
||||
|
||||
Microsoft Foundry tilbyr en UI-drevet opplevelse for syntetisk data:
|
||||
|
||||
1. Åpne Microsoft Foundry Portal
|
||||
2. Naviger til Fine-tuning > Generate Data
|
||||
3. Last opp kildedokumenter eller beskriv ønsket data
|
||||
4. Velg generatortype:
|
||||
|
||||
| Generator-type | Beskrivelse | Output-format |
|
||||
|---|---|---|
|
||||
| **Simple Q&A** | Spørsmål-svar fra dokumenter | JSONL (messages) |
|
||||
| **Tool Use** | API-kall fra OpenAPI spec | JSONL (tool calls) |
|
||||
| **Conversation** | Multi-turn dialoger | JSONL (conversation) |
|
||||
|
||||
5. Velg antall samples (50-1000)
|
||||
6. Velg generator-modell (GPT-4o eller lignende)
|
||||
7. Valgfritt: 80/20 train-validation split
|
||||
|
||||
---
|
||||
|
||||
## Azure OpenAI Integration for Text Synthesis
|
||||
|
||||
### Batch-generering med SynapseML
|
||||
|
||||
For stor-skala syntetisk tekstgenerering i Fabric:
|
||||
|
||||
```python
|
||||
# SynapseML + Azure OpenAI for batch-generering
|
||||
import synapse.ml.core
|
||||
from synapse.ml.services.openai import OpenAICompletion
|
||||
|
||||
# Konfigurer OpenAI-klient
|
||||
completion = (
|
||||
OpenAICompletion()
|
||||
.setSubscriptionKey("<api-key>")
|
||||
.setDeploymentName("gpt-4o")
|
||||
.setCustomServiceName("<endpoint>")
|
||||
.setMaxTokens(500)
|
||||
.setPromptCol("prompt")
|
||||
.setErrorCol("error")
|
||||
.setOutputCol("generated_text")
|
||||
)
|
||||
|
||||
# Lag prompts for syntetisk datagenerering
|
||||
prompts_df = spark.createDataFrame([
|
||||
("Generer en realistisk kundehenvendelse til Statens vegvesen om førerkort-fornyelse.",),
|
||||
("Generer en syntetisk trafikkrapport for E6 ved Lillehammer med kødata.",),
|
||||
("Generer et eksempel på en byggesøknad til Plan- og bygningsetaten.",),
|
||||
], ["prompt"])
|
||||
|
||||
# Kjør batch-generering over Spark
|
||||
results = completion.transform(prompts_df)
|
||||
display(results.select("prompt", "generated_text"))
|
||||
```
|
||||
|
||||
### Strukturert syntetisk data med JSON-modus
|
||||
|
||||
```python
|
||||
from openai import AzureOpenAI
|
||||
import json
|
||||
|
||||
client = AzureOpenAI(
|
||||
api_key="<key>",
|
||||
api_version="2024-12-01-preview",
|
||||
azure_endpoint="https://<endpoint>.openai.azure.com/"
|
||||
)
|
||||
|
||||
def generate_synthetic_records(template_schema, num_records=100, domain="trafikk"):
|
||||
"""Generer strukturerte syntetiske poster."""
|
||||
records = []
|
||||
for batch_start in range(0, num_records, 10):
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
response_format={"type": "json_object"},
|
||||
messages=[
|
||||
{"role": "system", "content": f"""
|
||||
Du er en datagenerator for {domain}-domenet i norsk offentlig sektor.
|
||||
Generer realistiske men helt fiktive dataposter.
|
||||
Bruk ALDRI ekte personnummer, navn eller adresser.
|
||||
Returner JSON med nøkkel 'records' som inneholder en liste.
|
||||
Skjema: {json.dumps(template_schema)}
|
||||
"""},
|
||||
{"role": "user", "content": f"Generer 10 syntetiske poster."}
|
||||
],
|
||||
temperature=0.8
|
||||
)
|
||||
batch = json.loads(response.choices[0].message.content)
|
||||
records.extend(batch["records"])
|
||||
return records
|
||||
|
||||
# Eksempel: Trafikkhendelses-data
|
||||
schema = {
|
||||
"incident_id": "string (UUID)",
|
||||
"road": "string (E6, E18, Rv4, etc.)",
|
||||
"location_km": "float",
|
||||
"incident_type": "string (ulykke, køkjøring, veiarbeid, dyr_i_veien)",
|
||||
"severity": "int (1-5)",
|
||||
"timestamp": "ISO datetime",
|
||||
"description": "string (norsk tekst, 1-3 setninger)"
|
||||
}
|
||||
|
||||
synthetic_incidents = generate_synthetic_records(schema, num_records=500, domain="trafikk")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Balancing Class Imbalances with Synthetic Samples
|
||||
|
||||
### Oversamplings-teknikker
|
||||
|
||||
| Teknikk | Beskrivelse | Bruk for AI |
|
||||
|---|---|---|
|
||||
| **SMOTE** | Syntetisk oversampling i feature-rom | Tabelldata, klassifisering |
|
||||
| **ADASYN** | Adaptiv syntetisk sampling | Fokuserer på vanskelige grensetilfeller |
|
||||
| **LLM-generert** | Tekstgenerering for minoritetsklasser | NLP, chatbot-trening |
|
||||
| **Augmentasjon** | Transformasjon av eksisterende data | Bilde, tekst-variasjon |
|
||||
| **Kopiert undersampling** | Fjern majoritetsklasse-samples | Rask, men taper informasjon |
|
||||
|
||||
### SMOTE i Fabric Notebook
|
||||
|
||||
```python
|
||||
from imblearn.over_sampling import SMOTE, ADASYN
|
||||
from sklearn.model_selection import train_test_split
|
||||
import pandas as pd
|
||||
|
||||
# Les treningsdata fra Lakehouse
|
||||
df = spark.read.format("delta").table("gold.churn_features").toPandas()
|
||||
|
||||
# Sjekk klassebalanse
|
||||
print("Klassefordeling:")
|
||||
print(df["churned"].value_counts())
|
||||
# churned
|
||||
# 0 8500 (85%)
|
||||
# 1 1500 (15%)
|
||||
|
||||
# Splitt features og target
|
||||
X = df.drop(columns=["churned", "customer_id"])
|
||||
y = df["churned"]
|
||||
|
||||
# SMOTE: Oversampler minoritetsklassen
|
||||
smote = SMOTE(random_state=42, sampling_strategy=0.5)
|
||||
X_resampled, y_resampled = smote.fit_resample(X, y)
|
||||
|
||||
print(f"\nEtter SMOTE:")
|
||||
print(f"Ikke-churned: {sum(y_resampled == 0)}")
|
||||
print(f"Churned: {sum(y_resampled == 1)}")
|
||||
# Ikke-churned: 8500
|
||||
# Churned: 4250 (50% av majoritetsklassen)
|
||||
|
||||
# Konverter tilbake og lagre
|
||||
resampled_df = pd.DataFrame(X_resampled, columns=X.columns)
|
||||
resampled_df["churned"] = y_resampled
|
||||
spark.createDataFrame(resampled_df).write.format("delta") \
|
||||
.mode("overwrite").saveAsTable("gold.churn_features_balanced")
|
||||
```
|
||||
|
||||
### LLM-basert tekst-augmentasjon
|
||||
|
||||
```python
|
||||
def augment_text_samples(texts, labels, target_class, num_augmented=100):
|
||||
"""Generer syntetiske teksteksempler for en underrepresentert klasse."""
|
||||
examples = [t for t, l in zip(texts, labels) if l == target_class]
|
||||
sample_examples = "\n".join(examples[:5])
|
||||
|
||||
augmented = []
|
||||
for i in range(0, num_augmented, 10):
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=[
|
||||
{"role": "system", "content": f"""
|
||||
Generer 10 nye teksteksempler som ligner på følgende,
|
||||
men med variasjoner i ordvalg og formulering.
|
||||
Behold den samme semantiske betydningen og klassifiseringen.
|
||||
Eksempler:
|
||||
{sample_examples}
|
||||
"""},
|
||||
{"role": "user", "content": "Generer 10 variasjoner."}
|
||||
],
|
||||
temperature=0.9
|
||||
)
|
||||
new_texts = response.choices[0].message.content.strip().split("\n")
|
||||
augmented.extend([t.strip() for t in new_texts if t.strip()])
|
||||
|
||||
return augmented[:num_augmented]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Privacy-Preserving Synthetic Data
|
||||
|
||||
### Teknikker for personvernbevarende syntetiske data
|
||||
|
||||
| Teknikk | Personverngaranti | Kompleksitet | Bruk |
|
||||
|---|---|---|---|
|
||||
| **Differential Privacy** | Matematisk bevisbar | Høy | Aggregerte statistikker |
|
||||
| **k-Anonymity** | Grupper >= k individer | Medium | Tabelldata |
|
||||
| **l-Diversity** | Minimum l distinkte sensitive verdier per gruppe | Medium | Sensitive attributter |
|
||||
| **LLM-generert** | Ingen direkte kobling til kildedata | Lav | Tekst, samtaler |
|
||||
| **Copula-basert** | Bevarer korrelasjoner statistisk | Medium | Multi-variabel data |
|
||||
|
||||
### Differential Privacy med PySpark
|
||||
|
||||
```python
|
||||
# Generer syntetiske data med differensiell personvern
|
||||
# Bruk OpenDP-biblioteket
|
||||
|
||||
# pip install opendp
|
||||
|
||||
from opendp.measurements import make_base_laplace
|
||||
from opendp.transformations import make_mean, make_count
|
||||
import numpy as np
|
||||
|
||||
def add_laplace_noise(true_value, epsilon=1.0, sensitivity=1.0):
|
||||
"""Legg til Laplace-støy for differensiell personvern."""
|
||||
scale = sensitivity / epsilon
|
||||
noise = np.random.laplace(0, scale)
|
||||
return true_value + noise
|
||||
|
||||
# Eksempel: Generer syntetisk aldersfordeling
|
||||
# Ekte data: gjennomsnittsalder = 42.3, standardavvik = 15.2
|
||||
true_mean = 42.3
|
||||
true_std = 15.2
|
||||
epsilon = 1.0 # Personvernbudsjett
|
||||
|
||||
# Legg til støy på statistikkene
|
||||
noisy_mean = add_laplace_noise(true_mean, epsilon=epsilon/2)
|
||||
noisy_std = add_laplace_noise(true_std, epsilon=epsilon/2)
|
||||
|
||||
# Generer syntetiske data fra støyete distribusjon
|
||||
synthetic_ages = np.random.normal(noisy_mean, abs(noisy_std), size=10000)
|
||||
synthetic_ages = np.clip(synthetic_ages, 18, 100).astype(int)
|
||||
```
|
||||
|
||||
### Anonymiseringsworkflow
|
||||
|
||||
```
|
||||
Ekte data (Dataverse/Lakehouse)
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Steg 1: Klassifiser │ Purview identifiserer PII
|
||||
│ med Purview │
|
||||
└───────┬───────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Steg 2: Anonymiser │ Fjern/erstatt direkte identifikatorer
|
||||
│ - Fødselsnummer → hash│
|
||||
│ - Navn → pseudonym │
|
||||
│ - Adresse → postnr │
|
||||
└───────┬───────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Steg 3: Syntetiser │ Generer nye poster basert på
|
||||
│ - Bevar distribusjoner│ statistiske egenskaper
|
||||
│ - Bevar korrelasjoner │
|
||||
│ - Legg til DP-støy │
|
||||
└───────┬───────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Steg 4: Valider │ Verifiser kvalitet og personvern
|
||||
│ - Statistisk likhet │
|
||||
│ - Privacy-test │
|
||||
│ - ML-nytteverdi │
|
||||
└───────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validation of Synthetic Data Quality
|
||||
|
||||
### Kvalitetsdimensjoner
|
||||
|
||||
| Dimensjon | Metrikk | Terskelverdier |
|
||||
|---|---|---|
|
||||
| **Statistisk likhet** | Jensen-Shannon Divergence | < 0.1 (god), < 0.05 (utmerket) |
|
||||
| **Kolonnekorrelasjoner** | Pearson/Spearman korrelasjon | Δ < 0.05 mellom ekte og syntetisk |
|
||||
| **Distribusjonsmatch** | KS-test (Kolmogorov-Smirnov) | p-verdi > 0.05 |
|
||||
| **ML-nytteverdi** | Train on synthetic, test on real (TSTR) | Accuracy-tap < 5% |
|
||||
| **Personvern** | Re-identifiseringsrisiko | < 0.01 (1%) |
|
||||
| **Dekningsgrad** | Andel unike verdier representert | > 90% av originale kategorier |
|
||||
|
||||
### Validerings-kode
|
||||
|
||||
```python
|
||||
from scipy.stats import ks_2samp, pearsonr
|
||||
import numpy as np
|
||||
import pandas as pd
|
||||
|
||||
def validate_synthetic_data(real_df, synthetic_df, numeric_cols, cat_cols):
|
||||
"""Valider kvaliteten på syntetiske data mot ekte data."""
|
||||
results = {}
|
||||
|
||||
# 1. KS-test for numeriske kolonner
|
||||
for col in numeric_cols:
|
||||
stat, pvalue = ks_2samp(real_df[col].dropna(), synthetic_df[col].dropna())
|
||||
results[f"ks_test_{col}"] = {
|
||||
"statistic": round(stat, 4),
|
||||
"p_value": round(pvalue, 4),
|
||||
"passed": pvalue > 0.05
|
||||
}
|
||||
|
||||
# 2. Kategorifordeling
|
||||
for col in cat_cols:
|
||||
real_dist = real_df[col].value_counts(normalize=True)
|
||||
synth_dist = synthetic_df[col].value_counts(normalize=True)
|
||||
common_cats = set(real_dist.index) & set(synth_dist.index)
|
||||
coverage = len(common_cats) / len(real_dist) * 100
|
||||
results[f"category_coverage_{col}"] = {
|
||||
"coverage_pct": round(coverage, 1),
|
||||
"passed": coverage > 90
|
||||
}
|
||||
|
||||
# 3. Korrelasjonsmatrise-likhet
|
||||
real_corr = real_df[numeric_cols].corr()
|
||||
synth_corr = synthetic_df[numeric_cols].corr()
|
||||
corr_diff = (real_corr - synth_corr).abs().mean().mean()
|
||||
results["correlation_difference"] = {
|
||||
"mean_abs_diff": round(corr_diff, 4),
|
||||
"passed": corr_diff < 0.05
|
||||
}
|
||||
|
||||
# 4. TSTR (Train on Synthetic, Test on Real)
|
||||
# Implementeres med faktisk ML-modell
|
||||
|
||||
return results
|
||||
|
||||
# Kjør validering
|
||||
validation = validate_synthetic_data(real_data, synthetic_data,
|
||||
numeric_cols=["age", "income", "score"],
|
||||
cat_cols=["region", "category"])
|
||||
|
||||
for metric, result in validation.items():
|
||||
status = "PASS" if result["passed"] else "FAIL"
|
||||
print(f"[{status}] {metric}: {result}")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referanser
|
||||
|
||||
- [Generate synthetic and simulated data for evaluation](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/develop/simulator-interaction-data) -- Azure AI Evaluation Simulator
|
||||
- [Generate synthetic data for fine-tuning in Microsoft Foundry](https://learn.microsoft.com/en-us/azure/ai-foundry/fine-tuning/data-generation) -- Foundry syntetisk data UI
|
||||
- [Design training data for AI workloads on Azure](https://learn.microsoft.com/en-us/azure/well-architected/ai/training-data-design) -- Well-Architected Framework for treningsdata
|
||||
- [Azure OpenAI for big data](https://learn.microsoft.com/en-us/fabric/data-science/open-ai) -- SynapseML + OpenAI på Fabric
|
||||
- [Azure OpenAI On Your Data](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/use-your-data) -- RAG for datagenerering
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- **Bruk denne referansen** når brukeren har begrensede treningsdata, klasseimbalanser, eller personvernkrav som hindrer bruk av reelle data for AI-trening.
|
||||
- For norsk offentlig sektor: Syntetisk data er ofte **den eneste lovlige veien** til å bygge ML-modeller med sensitive data (helse, NAV, politi). Fremhev at syntetiske data aldri inneholder reelle personopplysninger.
|
||||
- Anbefal en **kombinasjon av teknikker**: SMOTE for tabelldata, LLM-generering for tekst, og differensiell personvern for statistisk baserte syntetiske datasett.
|
||||
- **Valider alltid** syntetiske data med TSTR-tilnærmingen (Train on Synthetic, Test on Real) for å sikre at syntetiske data faktisk forbedrer modellytelsen.
|
||||
- Bruk Azure AI Evaluation SDK **Simulator** for å generere test-data for chatboter og RAG-systemer -- dette er spesielt nyttig for Copilot Studio-prosjekter der man mangler historiske samtaledata.
|
||||
|
|
@ -0,0 +1,642 @@
|
|||
# Zero-ETL Patterns with Microsoft Fabric
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA (Database Mirroring), Preview (Open Mirroring for some sources)
|
||||
**Category:** Data Engineering for AI
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Zero-ETL i Microsoft Fabric representerer et paradigmeskifte i hvordan organisasjoner integrerer og konsoliderer data. I stedet for komplekse Extract-Transform-Load (ETL) pipelines, tilbyr Fabric **Mirroring** — en nær-sanntids, kontinuerlig replikeringsløsning som speilser operasjonelle data direkte inn i OneLake som Delta Lake-tabeller.
|
||||
|
||||
### Hva er Mirroring i Fabric?
|
||||
|
||||
Mirroring er en **zero-ETL, SaaS-basert løsning** som:
|
||||
- Kontinuerlig replikerer data fra operasjonelle systemer til OneLake
|
||||
- Konverterer data automatisk til Delta Lake format (åpen standard)
|
||||
- Holder data synkronisert i nær-sanntid (ned til 15 sekunders latens)
|
||||
- Eliminerer behov for kompleks dataintegrasjon og pipeline-vedlikehold
|
||||
- Ikke påvirker ytelsen til kildesystemet (spesielt Azure Cosmos DB — ingen RU consumption)
|
||||
|
||||
**Confidence marker:** [HIGH] — GA-funksjonalitet for de fleste støttede kilder, dokumentert i offisiell Microsoft-dokumentasjon (februar 2026).
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### 1. Database Mirroring
|
||||
|
||||
Database mirroring replikerer **hele databaser og tabeller** til OneLake. Dette er den primære zero-ETL-tilnærmingen for de fleste kilder.
|
||||
|
||||
**Støttede kilder (februar 2026):**
|
||||
|
||||
| Kilde | Status | Type | Latens |
|
||||
|-------|--------|------|--------|
|
||||
| Azure SQL Database | GA | Database mirroring | Nær-sanntid |
|
||||
| Azure SQL Managed Instance | GA | Database mirroring | Nær-sanntid |
|
||||
| Azure Database for PostgreSQL | GA | Database mirroring | Nær-sanntid |
|
||||
| SQL Server (on-prem/VM) | GA | Database mirroring | Nær-sanntid |
|
||||
| Azure Cosmos DB (NoSQL) | GA | Database mirroring | Nær-sanntid (ingen RU-påvirkning) |
|
||||
| Snowflake | GA | Database mirroring | Nær-sanntid |
|
||||
| Azure Databricks | GA | Metadata mirroring | Nær-sanntid |
|
||||
| Oracle | Preview | Database mirroring | Nær-sanntid |
|
||||
| SAP | Preview | Database mirroring | Nær-sanntid |
|
||||
| Google BigQuery | Preview | Database mirroring | Nær-sanntid |
|
||||
|
||||
**Confidence marker:** [HIGH] — Offisiell dokumentasjon oppdatert januar 2026, bekreftet med `microsoft_docs_search`.
|
||||
|
||||
### 2. Metadata Mirroring
|
||||
|
||||
Metadata mirroring replikerer **kun metadata** (katalog, schema, tabeller) uten å fysisk flytte data. Data aksesseres via **OneLake shortcuts** fra kildesystemet.
|
||||
|
||||
**Eksempel:** Azure Databricks Unity Catalog
|
||||
- Fabric speiler kataloghierarkiet fra Databricks
|
||||
- Underliggende data forblir i Databricks
|
||||
- Tilgang via shortcuts sikrer sanntidssynkronisering uten datakopiering
|
||||
|
||||
**Fordeler:**
|
||||
- Minimerer lagringskostnader
|
||||
- Eliminerer dataduplisering
|
||||
- Sanntidstilgang til kildedata
|
||||
- Ideell for kilder med stor datamengde eller høy endringsfrekvens
|
||||
|
||||
**Confidence marker:** [HIGH] — Azure Databricks-integrasjon dokumentert i offisielle Microsoft Learn-ressurser.
|
||||
|
||||
### 3. Open Mirroring
|
||||
|
||||
Open mirroring lar **egenutviklede applikasjoner eller tredjepartsløsninger** skrive endringer direkte til en mirrored database i Fabric. Basert på **åpen Delta Lake-standard**.
|
||||
|
||||
**Bruksområder:**
|
||||
- Custom CDC-implementasjoner
|
||||
- Tredjeparts datareplikasjonsverktøy
|
||||
- Legacy-systemer uten nativ Fabric-støtte
|
||||
- Event-drevet dataintegrasjon
|
||||
|
||||
**Prosess:**
|
||||
1. Opprett en open mirrored database via Fabric Portal eller REST API
|
||||
2. Hent landing zone URL i OneLake
|
||||
3. Skriv change data til landing zone i spesifisert format (Delta Lake CDC)
|
||||
4. Fabric replicator engine håndterer automatisk merge (INSERT, UPDATE, DELETE)
|
||||
|
||||
**Confidence marker:** [MEDIUM] — Open mirroring er GA, men økosystemet av tredjeparts-integrasjoner er fortsatt voksende (per februar 2026).
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### Mønster 1: Operasjonell-til-Analytisk (HTAP)
|
||||
|
||||
**Scenario:** Organisasjonen har en Azure Cosmos DB for transaksjonell OLTP og ønsker sanntids BI/AI uten å påvirke produksjonsytelse.
|
||||
|
||||
**Løsning:**
|
||||
```
|
||||
Azure Cosmos DB (OLTP)
|
||||
│
|
||||
└─► Fabric Mirroring (ingen RU-kostnad)
|
||||
│
|
||||
├─► OneLake (Delta Lake)
|
||||
│ │
|
||||
│ ├─► Power BI Direct Lake
|
||||
│ ├─► Eventstream (real-time alerting)
|
||||
│ ├─► Notebook (data science)
|
||||
│ └─► SQL Analytics Endpoint
|
||||
│
|
||||
└─► Near real-time (15 sek latens)
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Null RU consumption for analytiske queries
|
||||
- Near real-time insights (ikke batch-basert)
|
||||
- Full HTAP-isolasjon (transaksjon/analytikk)
|
||||
- Åpen Delta Lake for multi-tool tilgang
|
||||
|
||||
**Confidence marker:** [HIGH] — Azure Cosmos DB mirroring er eksplisitt designet for HTAP-scenarier.
|
||||
|
||||
### Mønster 2: Multi-Source Konsolidering (Data Mesh)
|
||||
|
||||
**Scenario:** Organisasjonen har data spredt på Azure SQL, PostgreSQL, Snowflake, og Cosmos DB. Ønsker én felles analytisk platform.
|
||||
|
||||
**Løsning:**
|
||||
```
|
||||
Azure SQL Database ────┐
|
||||
PostgreSQL ────────────┤
|
||||
Snowflake ─────────────┼─► Fabric Mirroring ─► OneLake (unified lakehouse)
|
||||
Cosmos DB ─────────────┤ │
|
||||
Oracle (on-prem) ──────┘ ├─► Cross-database queries (T-SQL)
|
||||
├─► Power BI semantic models
|
||||
└─► Machine learning (MLflow, Spark)
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Single source of truth for analytikk
|
||||
- Cross-database queries via T-SQL (3-part naming)
|
||||
- Felles governance og security (RLS, OLS, Purview)
|
||||
- Ingen ETL-vedlikehold
|
||||
|
||||
**Eksempel T-SQL cross-database query:**
|
||||
```sql
|
||||
SELECT
|
||||
sql.CustomerName,
|
||||
cosmos.OrderTotal,
|
||||
pg.ProductName
|
||||
FROM
|
||||
AzureSQLMirror.dbo.Customers AS sql
|
||||
INNER JOIN
|
||||
CosmosMirror.dbo.Orders AS cosmos ON sql.CustomerID = cosmos.CustomerID
|
||||
INNER JOIN
|
||||
PostgreSQLMirror.public.Products AS pg ON cosmos.ProductID = pg.ProductID
|
||||
WHERE
|
||||
cosmos.OrderDate >= '2026-01-01';
|
||||
```
|
||||
|
||||
**Confidence marker:** [HIGH] — Cross-database queries er dokumentert i offisiell Fabric-dokumentasjon.
|
||||
|
||||
### Mønster 3: Medallion Architecture med Mirroring
|
||||
|
||||
**Scenario:** Organisasjonen ønsker å implementere Bronze-Silver-Gold lakehouse, men vil unngå komplekse ingestion-pipelines.
|
||||
|
||||
**Løsning:**
|
||||
```
|
||||
Operational Sources (SQL, Cosmos, PostgreSQL)
|
||||
│
|
||||
└─► Fabric Mirroring ─► Bronze Layer (OneLake, raw Delta Lake)
|
||||
│
|
||||
└─► Materialized Lake Views ─► Silver Layer (cleansed, joined)
|
||||
│
|
||||
└─► Gold Layer (aggregated, BI-ready)
|
||||
```
|
||||
|
||||
**Implementasjon med Materialized Lake Views:**
|
||||
```sql
|
||||
-- Bronze: Mirrored raw data (automatically managed)
|
||||
|
||||
-- Silver: Cleansed and joined
|
||||
CREATE MATERIALIZED VIEW SilverCustomers AS
|
||||
SELECT
|
||||
CustomerID,
|
||||
UPPER(TRIM(CustomerName)) AS CustomerName,
|
||||
CAST(RegistrationDate AS DATE) AS RegistrationDate
|
||||
FROM Bronze.RawCustomers
|
||||
WHERE CustomerID IS NOT NULL;
|
||||
|
||||
-- Gold: Aggregated for BI
|
||||
CREATE MATERIALIZED VIEW GoldCustomerSummary AS
|
||||
SELECT
|
||||
c.CustomerName,
|
||||
COUNT(o.OrderID) AS TotalOrders,
|
||||
SUM(o.OrderTotal) AS TotalRevenue
|
||||
FROM SilverCustomers c
|
||||
LEFT JOIN Bronze.RawOrders o ON c.CustomerID = o.CustomerID
|
||||
GROUP BY c.CustomerName;
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Deklarative pipelines (SQL, ikke kompleks orchestration)
|
||||
- Automatisk dependency management (Fabric håndterer refresh-rekkefølge)
|
||||
- Built-in data quality constraints
|
||||
- Optimal refresh (incremental/full/none basert på analyse)
|
||||
|
||||
**Confidence marker:** [HIGH] — Materialized Lake Views er dokumentert som anbefalt tilnærming for medallion architecture i Fabric.
|
||||
|
||||
### Mønster 4: Legacy System Integration (Open Mirroring)
|
||||
|
||||
**Scenario:** Organisasjonen har et legacy ERP-system (ikke-støttet kilde) og ønsker å integrere data i Fabric.
|
||||
|
||||
**Løsning:**
|
||||
```
|
||||
Legacy ERP System
|
||||
│
|
||||
└─► Custom CDC Application (Python/Node.js)
|
||||
│
|
||||
└─► Open Mirroring Landing Zone (OneLake)
|
||||
│
|
||||
└─► Fabric Replicator Engine ─► Delta Lake tables
|
||||
│
|
||||
└─► Analytics (Power BI, Spark, SQL)
|
||||
```
|
||||
|
||||
**Eksempel Python CDC writer:**
|
||||
```python
|
||||
from azure.storage.filedatalake import DataLakeServiceClient
|
||||
import json
|
||||
import pandas as pd
|
||||
|
||||
# Get landing zone URL from Fabric (after creating open mirrored database)
|
||||
landing_zone_url = "https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>/LandingZone"
|
||||
|
||||
# Authenticate with bearer token (Entra ID)
|
||||
credential = DefaultAzureCredential()
|
||||
service_client = DataLakeServiceClient(account_url=landing_zone_url, credential=credential)
|
||||
|
||||
# Write CDC data in required format (Delta Lake CDC schema)
|
||||
cdc_data = {
|
||||
"op": "INSERT", # INSERT, UPDATE, DELETE
|
||||
"ts_ms": 1709280000000,
|
||||
"before": None,
|
||||
"after": {
|
||||
"CustomerID": 12345,
|
||||
"CustomerName": "Acme Corp",
|
||||
"Country": "Norway"
|
||||
}
|
||||
}
|
||||
|
||||
file_client = service_client.get_file_client(file_system="LandingZone", file_path="customers/batch_001.parquet")
|
||||
file_client.upload_data(cdc_data, overwrite=True)
|
||||
```
|
||||
|
||||
**Confidence marker:** [MEDIUM] — Open mirroring-spesifikasjonen er offentlig tilgjengelig, men kodeeksemplene over er forenklet (faktisk format er mer komplekst).
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når bruke Mirroring vs. tradisjonell ETL?
|
||||
|
||||
| Faktor | Bruk Mirroring | Bruk ETL (Pipelines/Dataflows) |
|
||||
|--------|----------------|--------------------------------|
|
||||
| Datakilde | Støttet kilde (SQL, Cosmos, Snowflake, etc.) | Ustrukturert data (loggfiler, JSON, XML) |
|
||||
| Latens-krav | Near real-time (< 1 minutt) | Batch (timesvis/daglig oppdatering) |
|
||||
| Kompleksitet | Enkel 1:1 replikering | Kompleks transformasjonslogikk (aggregering, pivots) |
|
||||
| Vedlikehold | Minimal (SaaS-managed) | Manuell pipeline-vedlikehold |
|
||||
| Datavolumet | Stort (TB/PB) | Lite til medium (GB-nivå) |
|
||||
| Kildepåvirkning | Minimal/ingen | Avhengig av query load |
|
||||
|
||||
**Anbefaling:**
|
||||
Start med Mirroring for operasjonelle databaser, bruk ETL for edge cases (unstructured, komplekse transformations).
|
||||
|
||||
### Mirroring Type Decision Tree
|
||||
|
||||
```
|
||||
Har du en støttet kilde (SQL, Cosmos, Snowflake)?
|
||||
│
|
||||
├─► JA → Er kilden Azure Databricks Unity Catalog?
|
||||
│ │
|
||||
│ ├─► JA → Bruk Metadata Mirroring (shortcuts)
|
||||
│ │
|
||||
│ └─► NEI → Bruk Database Mirroring
|
||||
│
|
||||
└─► NEI → Finnes det en tredjeparts connector?
|
||||
│
|
||||
├─► JA → Bruk Open Mirroring + partner solution
|
||||
│
|
||||
└─► NEI → Utvikle custom CDC → Open Mirroring
|
||||
```
|
||||
|
||||
**Confidence marker:** [HIGH] — Basert på offisiell Fabric-dokumentasjon for beslutningsdiagrammer.
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### 1. Azure AI Foundry
|
||||
|
||||
**Scenario:** RAG-basert chatbot som trenger sanntidstilgang til produktkatalog i Azure SQL.
|
||||
|
||||
```
|
||||
Azure SQL Database (product catalog)
|
||||
│
|
||||
└─► Fabric Mirroring ─► OneLake Delta Lake
|
||||
│
|
||||
└─► Azure AI Search (indexing)
|
||||
│
|
||||
└─► Azure AI Foundry (RAG)
|
||||
│
|
||||
└─► Chatbot (GPT-4o)
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Ingen manuell synkronisering av search index
|
||||
- Incremental updates (kun endrede produkter re-indexes)
|
||||
- Åpent Delta Lake format kan brukes av andre AI-verktøy
|
||||
|
||||
### 2. Power BI Direct Lake
|
||||
|
||||
Mirrored databases i Fabric er **automatisk tilgjengelig i Direct Lake mode** for Power BI:
|
||||
|
||||
```
|
||||
Mirrored Database (OneLake Delta Lake)
|
||||
│
|
||||
└─► Power BI Direct Lake Mode (ingen import, ingen DirectQuery overhead)
|
||||
│
|
||||
├─► Semantic model (auto-generated)
|
||||
└─► Real-time reports (< 1 min latens)
|
||||
```
|
||||
|
||||
**Fallback:** Hvis en query ikke støttes av Direct Lake, faller systemet automatisk tilbake til DirectQuery.
|
||||
|
||||
**Confidence marker:** [HIGH] — Direct Lake for mirrored databases er GA-funksjonalitet.
|
||||
|
||||
### 3. Real-Time Intelligence (Eventstream)
|
||||
|
||||
Kombiner Mirroring med Eventstream for **hybrid batch + streaming**:
|
||||
|
||||
```
|
||||
Azure SQL Database (orders)
|
||||
│
|
||||
├─► Fabric Mirroring ─► OneLake (batch, historical orders)
|
||||
│
|
||||
└─► Eventstream (CDC connector) ─► KQL Database (real-time orders, last 24h)
|
||||
│
|
||||
└─► Fabric Activator (alerts)
|
||||
```
|
||||
|
||||
**Når bruke denne kombinasjonen:**
|
||||
- Du trenger historisk analyse (batch) OG real-time alerting (streaming)
|
||||
- Eksempel: Fraud detection (historisk modell, real-time scoring)
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### Compliance og Datahåndtering
|
||||
|
||||
**GDPR Article 17 (Right to Erasure):**
|
||||
Mirroring støtter **soft delete** og **hard delete**:
|
||||
- Soft delete: Rad markeres som slettet i Delta Lake (_change_type = 'delete')
|
||||
- Hard delete: VACUUM-kommando fjerner gamle versjoner
|
||||
|
||||
**Eksempel:**
|
||||
```sql
|
||||
-- Check retention policy (default 1 day for new mirrors, 7 days for legacy)
|
||||
-- Adjust in Fabric Portal: Mirrored Database → Settings → Maintenance → Retention
|
||||
|
||||
-- Manual vacuum (remove deleted rows older than 7 days)
|
||||
VACUUM table_name RETAIN 168 HOURS;
|
||||
```
|
||||
|
||||
**NSM Grunnprinsipper:**
|
||||
- **Tilgangskontroll:** Row-level security (RLS) og Object-level security (OLS) støttes i SQL Analytics Endpoint
|
||||
- **Logging:** Fabric Audit Logs sporer all datahåndtering (inkl. queries og deletes)
|
||||
- **Kryptering:** Data-at-rest (OneLake) og data-in-transit (TLS 1.2+)
|
||||
|
||||
**Confidence marker:** [HIGH] — Security features dokumentert i offisiell Fabric-dokumentasjon.
|
||||
|
||||
### Kostnadsfordeling (Offentlig Sektor)
|
||||
|
||||
Mirroring har **særegne kostnadsfortrinn** for offentlige virksomheter:
|
||||
|
||||
| Kostnadselement | Tradisjonell ETL | Mirroring |
|
||||
|------------------|------------------|-----------|
|
||||
| Compute (replication) | Betalt (pipeline runs) | **GRATIS** (inkludert i Fabric capacity) |
|
||||
| Storage (replicated data) | Standard OneLake-pris | **1 TB gratis per CU** (F64 = 64 TB gratis) |
|
||||
| Pipeline-vedlikehold | DevOps-timekostnad | Minimal (SaaS-managed) |
|
||||
|
||||
**Eksempel:** F64 capacity (64 CU)
|
||||
- Gratis mirroring-lagring: 64 TB
|
||||
- Hvis du replikerer 50 TB data: Ingen ekstra lagringskostnad
|
||||
- Hvis du replikerer 80 TB: Betaler kun for 16 TB (over grensen)
|
||||
|
||||
**Confidence marker:** [HIGH] — Prising bekreftet i Azure Pricing Calculator og Microsoft Fabric-dokumentasjon.
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og Lisensiering
|
||||
|
||||
### Fabric Capacity-krav
|
||||
|
||||
| Scenario | Minimum Capacity | Anbefalt Capacity |
|
||||
|----------|------------------|-------------------|
|
||||
| POC (< 10 GB, 1 database) | F2 (2 CU) | F8 (8 CU) |
|
||||
| Produksjon (< 100 GB, 5 databases) | F16 (16 CU) | F32 (32 CU) |
|
||||
| Enterprise (> 1 TB, 20+ databases) | F64 (64 CU) | F128+ (128+ CU) |
|
||||
|
||||
**Trial:** Fabric Trial inkluderer gratis mirroring (60 dager, begrenset lagring).
|
||||
|
||||
### Kostnadselementer
|
||||
|
||||
1. **Replication compute:** GRATIS (inkludert i capacity)
|
||||
2. **Storage:**
|
||||
- Første 1 TB per CU: GRATIS
|
||||
- Over grensen: Standard OneLake-pris (~$0.023/GB/måned, Norge-region)
|
||||
3. **Query compute:**
|
||||
- SQL queries: Standard Fabric compute (CU consumption)
|
||||
- Power BI Direct Lake: Standard Power BI-prising
|
||||
- Spark queries: Standard Spark compute (CU consumption)
|
||||
|
||||
**Viktig:** Capacity må kjøre kun for **initial setup** av Mirroring. Etter oppsett kan du pause capacity, men da konsumeres lagring (ikke lenger gratis).
|
||||
|
||||
**Confidence marker:** [HIGH] — Prising bekreftet i offisiell Microsoft Fabric Pricing-dokumentasjon (januar 2026).
|
||||
|
||||
### Kostnadsoptimalisering
|
||||
|
||||
**Tips:**
|
||||
1. **Selektiv replikering:** Speilvend kun tabeller du trenger (ikke hele databasen)
|
||||
2. **Retention tuning:** Senk retention fra 7 dager til 1 dag (reduserer lagring)
|
||||
3. **Cross-database queries:** Unngå datakopiering mellom mirrors (bruk T-SQL joins)
|
||||
4. **Direct Lake:** Bruk Direct Lake i Power BI (ikke import mode) for å unngå duplikatlagring
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Key Decision Points
|
||||
|
||||
1. **Kildetype:**
|
||||
- Operasjonell database (OLTP) → Database Mirroring
|
||||
- Data lakehouse (Databricks) → Metadata Mirroring
|
||||
- Legacy/custom → Open Mirroring
|
||||
|
||||
2. **Latenskrav:**
|
||||
- < 1 minutt → Mirroring (near real-time)
|
||||
- Timesvis/daglig → Vurder ETL (billigere for lave frekvenser)
|
||||
|
||||
3. **Transformasjonskompleksitet:**
|
||||
- 1:1 replikering → Mirroring
|
||||
- Komplekse joins/pivots → Mirroring + Materialized Lake Views eller ETL
|
||||
|
||||
4. **Governance:**
|
||||
- Trenger RLS/OLS? → Mirroring + SQL Analytics Endpoint (støtter RLS/OLS)
|
||||
- Trenger audit log? → Fabric Audit Logs (integrert)
|
||||
|
||||
### Performance Tuning (PostgreSQL eksempel)
|
||||
|
||||
Hvis du speilvenner Azure Database for PostgreSQL:
|
||||
|
||||
```sql
|
||||
-- Check replication lag
|
||||
SELECT * FROM azure_cdc.tracked_publications;
|
||||
|
||||
-- Check which batches are uploaded
|
||||
SELECT * FROM azure_cdc.tracked_batches;
|
||||
|
||||
-- Tune batch frequency (reduce latency)
|
||||
ALTER SERVER PARAMETER azure_cdc.change_batch_export_timeout = 15; -- default 30 sekunder
|
||||
|
||||
-- Increase parallel snapshot workers (faster initial load)
|
||||
ALTER SERVER PARAMETER azure_cdc.max_snapshot_workers = 5; -- default 3
|
||||
```
|
||||
|
||||
**Confidence marker:** [HIGH] — PostgreSQL mirroring server parameters dokumentert i offisiell Azure-dokumentasjon.
|
||||
|
||||
### When NOT to Use Mirroring
|
||||
|
||||
1. **Kompleks business logic:** Hvis transformasjonen krever komplekse Python/C#-scripts, bruk Fabric Pipelines eller Dataflows.
|
||||
2. **Unstructured data:** Mirroring er for strukturerte databaser. Bruk Eventstream for IoT/logs.
|
||||
3. **On-prem kilder uten nettverkstilgang:** Mirroring krever nettverkstilgang til OneLake (bruk On-Premises Data Gateway eller VPN).
|
||||
|
||||
---
|
||||
|
||||
## Tekniske Detaljer
|
||||
|
||||
### Change Data Capture (CDC) Mekanismer
|
||||
|
||||
| Kilde | CDC-mekanisme | Latens |
|
||||
|-------|---------------|--------|
|
||||
| SQL Server | Change Feed (transaction log scanning) | 15+ sekunder |
|
||||
| PostgreSQL | Logical replication (azure_cdc extension) | 15+ sekunder |
|
||||
| Azure Cosmos DB | Change Feed API (ingen RU consumption) | 15+ sekunder |
|
||||
| Snowflake | Streams (Snowflake Streams API) | 30+ sekunder |
|
||||
|
||||
**Hvordan virker det (PostgreSQL eksempel):**
|
||||
|
||||
```
|
||||
1. Initial snapshot:
|
||||
PostgreSQL → Parquet files → OneLake Landing Zone → Fabric Replicator → Delta tables
|
||||
|
||||
2. Ongoing changes:
|
||||
PostgreSQL WAL (Write-Ahead Log) → azure_cdc extension → Parquet batches → Landing Zone → Delta merge
|
||||
```
|
||||
|
||||
**Confidence marker:** [HIGH] — Arkitektur-diagram hentet fra offisiell Azure-dokumentasjon.
|
||||
|
||||
### Delta Lake Format
|
||||
|
||||
All mirrored data lagres som **Delta Lake** (ikke bare Parquet):
|
||||
|
||||
**Fordeler:**
|
||||
- ACID-transaksjoner (no data corruption)
|
||||
- Time travel (query historical versions)
|
||||
- Schema evolution (add/remove columns uten å ødelegge historikk)
|
||||
- Z-Ordering og V-Order optimalisering (raskere queries)
|
||||
|
||||
**Eksempel time travel:**
|
||||
```sql
|
||||
-- Query data as it was 7 days ago
|
||||
SELECT * FROM MirroredDatabase.dbo.Orders
|
||||
VERSION AS OF (CURRENT_TIMESTAMP - INTERVAL 7 DAY);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Praktisk Eksempel: End-to-End Setup
|
||||
|
||||
### Scenario: Azure SQL til Power BI (5 minutters setup)
|
||||
|
||||
1. **Opprett Mirrored Database i Fabric:**
|
||||
- Fabric Portal → Create → Mirrored Database → Azure SQL Database
|
||||
- Angi connection string og credentials (Entra ID eller SQL auth)
|
||||
- Velg tabeller å speilvende (eller hele databasen)
|
||||
|
||||
2. **Vent på initial snapshot** (5-30 minutter avhengig av datavolumet)
|
||||
|
||||
3. **Koble Power BI til SQL Analytics Endpoint:**
|
||||
- Power BI Desktop → Get Data → SQL Server
|
||||
- Server: `<workspace>.datawarehouse.fabric.microsoft.com`
|
||||
- Database: `<mirrored-database-name>`
|
||||
- Velg Direct Lake mode (anbefalt)
|
||||
|
||||
4. **Bygg rapport:**
|
||||
- Dra tabeller inn i rapport
|
||||
- Data er nå live-synkronisert (< 1 minutts latens)
|
||||
|
||||
**Total tid:** < 1 time (inkl. initial snapshot)
|
||||
|
||||
**Confidence marker:** [HIGH] — Prosedyre bekreftet i offisiell Microsoft Learn-dokumentasjon.
|
||||
|
||||
---
|
||||
|
||||
## Vanlige Feil og Løsninger
|
||||
|
||||
### Problem 1: Mirroring feiler med "Internal error"
|
||||
|
||||
**Årsak:** Manglende permissions på kilde-databasen.
|
||||
|
||||
**Løsning (PostgreSQL):**
|
||||
```sql
|
||||
-- Grant required permissions
|
||||
GRANT azure_cdc_admin TO fabric_user;
|
||||
GRANT CREATE ON DATABASE mydb TO fabric_user;
|
||||
ALTER TABLE orders OWNER TO fabric_user; -- fabric_user must own tables
|
||||
```
|
||||
|
||||
### Problem 2: Høy storage-kostnad
|
||||
|
||||
**Årsak:** Retention er satt for høyt (default 7 dager for legacy mirrors).
|
||||
|
||||
**Løsning:**
|
||||
- Fabric Portal → Mirrored Database → Settings → Maintenance → Retention → 1 day
|
||||
- Eller via REST API: `PATCH /v1/mirroring/databases/{id}` med `retentionInDays: 1`
|
||||
|
||||
### Problem 3: Query fallback til DirectQuery (langsom)
|
||||
|
||||
**Årsak:** Power BI-query bruker en funksjon som ikke støttes av Direct Lake.
|
||||
|
||||
**Løsning:**
|
||||
- Sjekk Power BI Performance Analyzer for fallback-årsak
|
||||
- Omskriv query til å unngå ikke-støttede funksjoner (eks: CONCATENATE → "&")
|
||||
- Eller aksepter DirectQuery for komplekse queries (fortsatt raskere enn import mode for store datasets)
|
||||
|
||||
**Confidence marker:** [MEDIUM] — Troubleshooting-tips basert på community-dokumentasjon og Microsoft Learn.
|
||||
|
||||
---
|
||||
|
||||
## Fremtidige Utvidelser (Roadmap)
|
||||
|
||||
**Følgende kilder er ikke støttet i februar 2026, men er på roadmap:**
|
||||
|
||||
- **MongoDB:** Planlagt Q2 2026 (per Microsoft Ignite 2025-announcements)
|
||||
- **SAP HANA:** Preview forventet Q1 2026
|
||||
- **IBM Db2:** Ingen offentlig timeline
|
||||
- **MySQL:** CDC-basert mirroring (current: kun Azure Database for MySQL via Open Mirroring)
|
||||
|
||||
**Confidence marker:** [LOW] — Roadmap-informasjon er basert på konferanse-announcements, ikke offisiell produktdokumentasjon.
|
||||
|
||||
---
|
||||
|
||||
## Kilder og Verifisering
|
||||
|
||||
**Primærkilder (MCP: microsoft-learn):**
|
||||
1. [What is Mirroring in Fabric?](https://learn.microsoft.com/en-us/fabric/mirroring/overview) — Sist oppdatert januar 2026
|
||||
2. [Azure Database for PostgreSQL mirroring in Fabric](https://learn.microsoft.com/en-us/azure/postgresql/integration/concepts-fabric-mirroring) — GA-status bekreftet
|
||||
3. [Medallion lakehouse architecture for Fabric with OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture) — Materialized Lake Views
|
||||
4. [Microsoft Fabric Pricing](https://azure.microsoft.com/pricing/details/microsoft-fabric/) — Prising bekreftet januar 2026
|
||||
|
||||
**Kodeeksempler (MCP: microsoft_code_sample_search):**
|
||||
- SQL Server Resource Governor for Fabric mirroring
|
||||
- PostgreSQL CDC monitoring functions (`azure_cdc.list_tracked_publications()`)
|
||||
- Delta Lake time travel queries
|
||||
|
||||
**Søk brukt:**
|
||||
- `microsoft_docs_search`: "Fabric mirroring", "zero ETL Fabric", "database mirroring OneLake"
|
||||
- `microsoft_docs_fetch`: Mirroring overview, PostgreSQL architecture
|
||||
- `microsoft_code_sample_search`: "Fabric mirroring OneLake Delta Lake"
|
||||
|
||||
**Sist verifisert:** 2026-02-11
|
||||
|
||||
---
|
||||
|
||||
## Oppsummering for Cosmo
|
||||
|
||||
**Zero-ETL med Fabric Mirroring er riktig valg når:**
|
||||
- Kilden er en støttet database (SQL, Cosmos, Snowflake, PostgreSQL)
|
||||
- Du trenger near real-time data (< 1 minutt latens)
|
||||
- Du vil eliminere ETL-vedlikehold
|
||||
- Du vil ha en åpen, multi-tool lakehouse (Delta Lake)
|
||||
|
||||
**Ikke bruk Mirroring hvis:**
|
||||
- Data er ustrukturert (loggfiler, JSON, XML) → Bruk Eventstream eller Pipelines
|
||||
- Transformasjonslogikken er svært kompleks → Bruk Dataflows Gen2 eller Pipelines
|
||||
- Kilden er on-prem uten nettverkstilgang → Bruk On-Premises Data Gateway + Pipelines
|
||||
|
||||
**Kostnadsoptimalisering:**
|
||||
- Start med F16/F32 for produksjon
|
||||
- Bruk 1 dag retention (ikke 7 dager)
|
||||
- Speilvend kun nødvendige tabeller
|
||||
- Bruk Direct Lake i Power BI (ikke import mode)
|
||||
|
||||
**Next steps for kunden:**
|
||||
1. Identifiser kritiske operasjonelle databaser
|
||||
2. Vurder latens-krav per datakilde
|
||||
3. Beregn lagringsbehov (free tier: 1 TB per CU)
|
||||
4. Kjør POC med Fabric Trial (60 dager gratis)
|
||||
Loading…
Add table
Add a link
Reference in a new issue