# 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

### Microsoft Foundry

**Pattern:** Data Factory → Microsoft 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å.
