10 — Analytics Platforms

Concevoir l'analytique et le traitement de données → entrepôts/big data (Synapse, Databricks, Fabric), ingestion (Data Factory), temps-réel (Stream Analytics) : choisir selon OLTP vs OLAP, batch vs streaming, volume et profil utilisateur.

A. Vocabulaire analytics#

A.1 OLTP vs OLAP#

🎯 Au 305 : dès qu'on dit "transactional / OLTP" → Azure SQL ou Cosmos. Dès qu'on dit "OLAP DW structuré pour BI récurrent" → Dedicated SQL pool / Fabric Warehouse.

A.2 MPP vs SMP (en 2 lignes)#

• SMP (single machine, scale vertical) = Azure SQL DB / MI / on VM.
• MPP (N nodes en parallèle, scale horizontal) = Synapse Dedicated SQL pool (le seul MPP managé Azure).

Pourquoi ça compte : 100 TB à scanner → SMP rame, MPP splitte sur 60 nodes en parallèle.

A.3 HNS (Hierarchical Namespace)#

• Sans HNS (Blob classique) : folders = préfixes (illusion). Rename /raw/2024 → /archive/2024 (1 TB) = re-copy tout.
• Avec HNS (ADLS Gen2) : vrais folders + atomic rename en ms. Hadoop/Spark exigent un vrai filesystem.

A.4 ABFS (driver ADLS Gen2)#

• ABFS (abfss://) = driver Hadoop pour ADLS Gen2 → code Spark/Hive marche tel quel.
• Remplace l'ancien WASB (Blob classique).
• 🎯 Migration Hadoop on-prem → Azure : ADLS Gen2 + ABFS.

A.5 POSIX ACLs vs RBAC#

• RBAC = accès gros grain (Storage Account / container niveau).
• POSIX ACLs (HNS) = granularité dossier/fichier.
• Best practice : RBAC pour le large + ACLs pour le métier fin par dossier.

A.6 HTAP (Hybrid Transactional/Analytical)#

Idée : faire de l'analyse sur tes données OLTP en quasi-temps réel, sans ralentir l'OLTP.

Le problème : tu as Cosmos DB qui prend les commandes (OLTP, ultra-rapide). Si tu lances une grosse query d'analytics dessus pour faire un dashboard, ça ralentit les écritures clients. La solution HTAP : Azure recopie en arrière-plan tes data OLTP vers une copie analytique séparée (~5 min de latence). Tu queries cette copie sans impacter l'OLTP.

Services Azure qui font du HTAP : Synapse Link (legacy) et Fabric Mirroring (moderne).

A.7 Data Governance : Microsoft Purview vs Unity Catalog#

Le problème : dans une boîte, tu as 50 sources de data (SQL on-prem, Azure SQL, Cosmos, Databricks, fichiers SharePoint, AWS RDS, etc.). Comment savoir qui possède quoi, qui peut accéder à quoi, où vivent les PII ?

🎯 "Gouvernance sur tout l'estate (au-delà de Databricks)" → Purview. "Gouvernance interne Databricks" → Unity Catalog.

A.8 Concepts à connaître en awareness (sans deep-dive)#

Tu n'as pas besoin de maîtriser ces concepts en profondeur pour le 305, mais tu dois reconnaître les mots-clés si une question les utilise.

Medallion architecture (Bronze / Silver / Gold)#

Façon d'organiser un data lake en 3 couches : bronze (data brute), silver (nettoyée), gold (agrégée prête pour BI). C'est juste une convention d'organisation des dossiers.

Delta Lake#

Format de fichier moderne au-dessus de Parquet (format compressé pour analytics). Ajoute des features transactions ACID + rollback temporel que Parquet pur n'a pas. Utilisé par défaut par Databricks et Fabric.

Lakehouse pattern#

Idée moderne de combiner data lake (stockage cheap) + data warehouse (queries rapides) dans une seule plateforme au lieu de les avoir séparés. Poussé par Databricks (Delta Lake) et Microsoft Fabric (OneLake).

Unités pricing#

Tu n'as pas à connaître les détails, juste savoir qu'elles existent :

• DWU = unité Synapse Dedicated SQL pool
• DBU = unité Databricks
• vCore = unité générique Azure SQL / Synapse Serverless

B. ADLS Gen2 — fondation du data lake#

B.1 C'est quoi#

Storage Account + HNS activé → vrais folders, ACLs POSIX, optimisé big data. Fondation data lake Azure compatible Hadoop/Spark/Databricks/Synapse.

B.2 Caractéristiques#

• Built sur Blob → tiers (Hot/Cool/Cold/Archive), lifecycle, encryption marchent
• Multi-protocol : Blob API + ADLS driver (abfss://) + NFSv3
• Compatible natif : Hadoop, Spark, Databricks, Synapse
• Organisation type :

/raw       → brut ingéré (immutable, partitionné par date)
/cleansed  → nettoyé (silver)
/curated   → prêt analytics (gold)

B.3 Tiers / SKU#

• Performance : Standard / Premium (low-latency)
• Redundancy : LRS / ZRS / GRS / RA-GRS / GZRS
• Access tiers Blob : Hot / Cool / Cold / Archive (lifecycle policies)

B.4 Quand l'utiliser#

• Workload big data / analytics nécessitant vrai filesystem (Spark, Hadoop).
• Besoin granularité ACLs POSIX dossier/fichier (vs RBAC SA-level).
• Migration Hadoop on-prem → cloud (avec ABFS driver).
• Medallion architecture (bronze/silver/gold).

B.5 Pièges 305#

• 🚨 HNS = irréversible → cocher à la création (sinon SA = Blob classique).
• 🚨 WASB driver legacy → utiliser ABFS (abfss://) pour ADLS Gen2.
• 🚨 Tier Archive incompatible avec lecture Spark directe (rehydrate avant).

C. Synapse Analytics — la plateforme unifiée#

C.1 C'est quoi#

Plateforme unifiée : DW + big data + integration + viz dans un seul Workspace. Couvre OLAP MPP, query data lake serverless, Spark, KQL, pipelines.

C.2 Les composants du Workspace#

Synapse n'est pas UN service mais un container qui héberge plusieurs "pools" + features. Tu choisis le bon outil selon ton besoin :

C.3 Quel composant pour quel scénario — LE tableau exam#

C.4 Charger data du lake → Dedicated SQL pool (vue d'ensemble)#

Tu n'as pas à connaître les commandes T-SQL, juste savoir qu'il y a 3 façons :

🎯 Au 305 : si la question dit "load data du lake vers le Dedicated SQL pool en 2026" → COPY statement.

C.5 Synapse Link — les 4 variantes (awareness)#

Synapse Link = HTAP : réplique data OLTP vers Synapse pour analytics, sans impacter l'OLTP.

⚠️ 2026 : MS pousse Fabric Mirroring pour nouveaux projets (GA pour Azure SQL DB / Snowflake / SQL MI / PostgreSQL flex ; Cosmos DB Mirroring = Preview, NoSQL uniquement). Synapse Link for Cosmos DB = « no longer supported for new projects » (ne plus l'utiliser en greenfield) — mais Synapse Link reste un concept d'objectif AZ-305.

C.6 Pièges 305#

• 🚨 Dedicated SQL pool ≠ Azure SQL DB. MPP analytics ≠ SMP OLTP.
• 🚨 Serverless SQL pool = query files sans provisioning (différent de Dedicated qui est provisionné).
• 🚨 PolyBase legacy, COPY moderne → MS recommande COPY pour nouveaux projets.
• 🚨 Synapse Pipelines = ADF sous le capot, juste intégré dans le workspace.

💡 Détail DP-203 (hors scope AZ-305) : Dedicated SQL pool exige un choix de distribution table par table (Hash / Round-robin / Replicate) pour perf. À savoir que ça existe au 305, pas à choisir.

D. Azure Databricks#

D.1 C'est quoi#

Plateforme Spark managée par Databricks (partner MS). Référence pour ML / data science avancé + Delta Lake + Unity Catalog governance.

D.2 Architecture rapide#

D.3 Tiers / SKU#

Pricing : DBU + VMs Azure sous-jacentes (double facturation).

D.4 Quand l'utiliser#

• ML / Data Science avancé (MLflow natif excellent vs Synapse Spark).
• Delta Lake medallion architecture (ACID, time-travel, MERGE).
• Streaming massif / complex events / fraud detection ML scoring.
• Migration Hadoop on-prem (alternative à Synapse Spark).

D.5 Synapse Spark pool vs Databricks#

🎯 Question 305 : "ML avancé / Delta Lake medallion / Unity Catalog" → Databricks. "Plateforme unifiée Azure sans ML poussé" → Synapse.

D.6 Pièges 305#

• 🚨 Standard tier ≠ prod : pas d'Unity Catalog, RBAC, SSO, audit → toujours Premium en prod.
• 🚨 Photon = activé par défaut sur DBR 9.1 LTS+ (dépend du runtime/compute, pas du tier). Les vrais différenciateurs Premium = Unity Catalog, RBAC, SSO, audit.
• 🚨 Pricing double : DBU et VMs Azure (penser au TCO).
• 🚨 All-purpose cluster oublié allumé = facture explose → préférer Job clusters auto-terminate.

E. Azure Data Factory (ADF)#

E.1 C'est quoi#

ETL/ELT orchestration drag-and-drop + code. Pipeline d'activités pour ingérer, transformer, charger data multi-sources vers Azure.

E.2 Architecture rapide#

E.3 Les 3 Integration Runtimes#

E.4 Triggers types#

E.5 Pricing#

Pas de tier ADF — pricing par :

• Pipeline orchestration (per activity run)
• Data movement (per DIU/hour)
• Data Flow (per vCore-hour cluster Spark sous le capot)

E.6 ADF vs Synapse Pipelines#

Même engine sous le capot. Différence :

• ADF standalone : service séparé, simple, intégration avec n'importe quel target.
• Synapse Pipelines : ADF intégré dans le workspace Synapse → orchestration unifiée Spark/SQL pool + UI partagée.

🎯 "Multi-sources vers data lake, projet greenfield" → ADF ou Synapse Pipelines (les 2 OK). Si Synapse déjà en place → Pipelines pour cohérence.

E.7 Pièges 305#

• 🚨 Self-hosted IR obligatoire pour accès on-prem (outbound only).
• 🚨 Data Flow = Spark sous le capot → coûte plus cher que Copy Activity simple.
• 🚨 Tumbling Window ≠ Schedule : Tumbling = incrémental avec watermark, Schedule = cron.
• 🚨 Azure-SSIS IR = pour lift-and-shift SSIS legacy, pas pour nouveaux ETL.

🚨 ADF — Schema Drift detection : Quand le schema source change (colonne ajoutée/renommée) → Mapping Data Flow le détecte automatiquement via l'option "Allow schema drift" (à activer dans Source + Sink settings). Use case : ingestion CSV partenaires dont structure évolue sans préavis → schema drift accepte les colonnes nouvelles, les propage en sortie sans casser le pipeline. ⚠️ Distractor exam : "détecter colonnes ajoutées dans CSV source automatiquement" → ADF Mapping Data Flow + Allow schema drift (pas pipeline Copy Activity manuel, pas Synapse pipeline qui n'a pas cette feature aussi développée).

F. Stream Analytics (awareness 305)#

F.1 C'est quoi#

Service managé de stream processing. SQL-like queries (T-SQL extensions) sur des flux en quasi-temps réel. No-code/low-code.

F.2 Quand l'utiliser#

• IoT telemetry → filter + aggregate → dashboard / alertes.
• Détection simple d'événements (seuil dépassé, count par fenêtre).
• ETL streaming léger sans code.

F.3 Stream Analytics vs Databricks Streaming#

🎯 Question 305 : "Streaming simple SQL-like no-code" → Stream Analytics. "Streaming complex events + ML" → Databricks Streaming.

F.4 Sources / cibles supportées#

• Inputs : Event Hubs, IoT Hub, Blob/ADLS
• Outputs : Power BI (live dashboard), Cosmos DB, Azure SQL, Blob/ADLS, Event Hubs, Functions

G. Microsoft Fabric (awareness 305)#

Plateforme analytics unifiée moderne lancée par MS en 2023. MS pousse Fabric comme l'évolution de Synapse + Power BI + ADF dans une seule expérience SaaS.

G.1 Composants Fabric (vue 305)#

G.2 Quand le mentionner au 305#

• "Plateforme analytics unifiée moderne all-in-one" → Microsoft Fabric (réponse 2025+).
• "Replica near-real-time OLTP pour analytics, projet nouveau" → Fabric Mirroring (Synapse Link sunset progressivement).
• 🎯 Au 305 : awareness suffisant. Pas de deep dive sur la config.

G.3 Pièges 305#

• 🚨 Synapse encore objectif d'exam AZ-305 actuel — Fabric mentionné en awareness "futur direction".
• 🚨 Fabric ≠ Synapse. Fabric inclut Synapse-like features mais c'est une nouvelle plateforme SaaS avec OneLake comme storage unifié.

H. Architectures types AZ-305#

Modern DW (le grand classique)#

[Sources] → [ADF / Synapse Pipelines] → [ADLS Gen2 raw→cleansed→curated]
                                                ↓
                          [Synapse Spark / Databricks] (transform)
                                                ↓
                          [Synapse Dedicated SQL pool] → [Power BI]

Real-time (streaming + batch combinés)#

[Sources] → [Event Hub / Kafka]
   ├─ [Stream Analytics / Databricks Streaming] → Cosmos/SQL real-time
   └─ [ADF + Databricks/Synapse] → ADLS → DW → Power BI

HTAP (Synapse Link)#

[Cosmos OLTP] → [Synapse Link] → [Synapse Spark/SQL] (analytics SANS impact OLTP)
[Azure SQL OLTP] → [Synapse Link] → [Synapse]

Lakehouse moderne (Databricks ou Fabric)#

[Sources] → [ADF/Spark] → [ADLS Gen2 / OneLake + Delta Lake]
                              ├─ /bronze (raw)
                              ├─ /silver (cleansed)
                              └─ /gold (BI-ready)
                              ↓
                          [Databricks SQL / Fabric Warehouse / Power BI]

Serverless data lake query#

[ADLS Gen2 avec CSV/Parquet] ←──── OPENROWSET ──── [Synapse Serverless SQL pool]
                                                    pay-per-TB scanné, zéro provisioning

I. Decision tree analytics#

Par source de data#

D'où vient ta data ?
├─ Data lake (fichiers CSV/Parquet/JSON sur ADLS) ?
│   ├─ Query ad-hoc / ponctuel, zéro provisioning  → Synapse Serverless SQL pool 
│   ├─ DW structuré récurrent pour BI              → Synapse Dedicated SQL pool (load depuis lake)
│   ├─ Transformation big data / ML                → Databricks (recommandé) ou Synapse Spark
│   └─ Plateforme moderne unifiée (greenfield)     → Microsoft Fabric (Lakehouse + Warehouse)
│
├─ Base OLTP (Cosmos / Azure SQL / SQL Server) ?
│   ├─ Besoin analytics quasi-live sans impacter   → Synapse Link / Fabric Mirroring (HTAP)
│   └─ Analytics offline batch                     → ADF/Spark → ADLS → DW
│
├─ Streaming (Event Hub / Kafka / IoT) ?
│   ├─ Simple aggregations SQL-like, no-code       → Stream Analytics
│   └─ Complex events / ML scoring temps-réel      → Databricks Streaming
│
├─ Source on-prem (SQL Server, Oracle, files) ?
│   └─ Ingestion vers Azure                        → ADF + Self-hosted IR
│
└─ Multi-sources SaaS (Salesforce, SAP, etc.) ?
    └─ Orchestration ETL                           → ADF (70+ connectors)

Par besoin business#

Quel est ton objectif ?
├─ BI / Power BI dashboards récurrents             → Dedicated SQL pool / Fabric Warehouse
├─ Data Science / ML avec MLflow                   → Databricks Premium 
├─ Exploration ad-hoc data lake (1× par mois)      → Serverless SQL pool
├─ Lift-and-shift DW SQL Server / Teradata         → Dedicated SQL pool (+ ADLS staging + ADF transport)
├─ Lift-and-shift SSIS packages                    → ADF + Azure-SSIS IR
├─ Time-series / logs analytics KQL                → Azure Data Explorer (ou Synapse Data Explorer pool)
├─ Dashboard temps-réel IoT/devices                → Event Hub → Stream Analytics → Power BI
├─ Détection fraude streaming + ML                 → Event Hub → Databricks Streaming
├─ Gouvernance data multi-source (catalogue, PII)  → Microsoft Purview 
├─ Gouvernance interne Databricks                  → Unity Catalog
└─ Migration Hadoop on-prem complète               → Databricks (ou Synapse Spark) + ADLS Gen2 + ABFS

K. Scénarios 305 → outil#

🏢 Scénarios d'entreprise (CAF/WAF)#

Scénario 1 : Distribution (retail) — Modern Data Warehouse batch nocturne#

Contexte business : Enseigne de distribution, système financier on-prem (1 TB, +5%/an), batch nocturne qui doit finir avant 3h. Besoin : reporting analytique + self-service pour le management, base future pour la data science. Données company confidential. Choix architectural : pipeline ELT par batch ADF → ADLS Gen2 (couches medallion) → Dedicated SQL pool → Power BI, dans une Landing Zone hub-and-spoke. Le Dedicated SQL pool (MPP) traite gros volumes pour du BI récurrent. Architecture / pattern :

• Ingestion : ADF + Self-hosted IR (pour lire la source on-prem), Tumbling Window + watermark pour l'incrémental
• Stockage : ADLS Gen2 (HNS), couches bronze/silver/gold, chiffré at-rest + in-transit
• Transform : Databricks (ou Synapse Spark) silver→gold ; chargement vers le Dedicated SQL pool via COPY statement
• Serving : Power BI ; gouvernance Purview (classification PII, lineage) Trade-offs assumés :
• Gain : MPP scalable pour le BI, pause/resume du pool hors fenêtres = coût maîtrisé, fenêtre bout-en-bout < 90 min tenable
• Perte : données en J+1 (pas de temps réel) ; le Dedicated SQL pool coûte même à faible charge (atténué par le pause) Pièges à éviter :
• Charger les gros volumes via bcp/SqlBulkCopy (lent) → utiliser COPY statement
• Oublier le Self-hosted IR pour la source on-prem (l'Azure IR ne voit pas le on-prem)
• HNS est irréversible : l'activer dès la création du Storage Account 📐 Réf. Architecture Center — ADF baseline en Azure Landing Zone (medallion lakehouse) : architecture de référence avec hub-and-spoke, landing zones CAF, sécurité confidentielle, fenêtre < 90 min. Lien

Scénario 2 : Mobilité (IoT) — Streaming temps réel vers dashboard#

Contexte business : Opérateur de flotte, 10 000 véhicules envoyant de la télémétrie (position, vitesse, alertes). Besoin : dashboard live + alertes, latence minimale, sans équipe streaming dédiée. Choix architectural : Event Hubs → Stream Analytics → Power BI, avec capture vers ADLS pour pouvoir rejouer. Stream Analytics choisi car il filtre/agrège en SQL-like, sans code. Architecture / pattern :

• Ingest : Event Hubs (partitionné par véhicule/zone) ; Event Hubs Capture → ADLS Gen2 (replay/recovery)
• Process : Stream Analytics (fenêtres temporelles, agrégations) ; sortie directe Power BI (dataset streaming)
• Archivage froid : sortie parallèle Blob/ADLS pour un batch ultérieur Trade-offs assumés :
• Gain : la plus faible latence event→Power BI sur Azure ; aucun code ; déployable en minutes
• Perte : pas de ML complexe inline ; Stream Analytics peu rentable si le débit est faible / pas vraiment temps réel Pièges à éviter :
• Power BI ne gère pas le partitionnement de sortie → aligner les clés en amont
• SU > 80% = signal pour scale-out ; throttling Event Hubs = quota dépassé
• Pour du scoring ML temps réel (anti-fraude), passer à Databricks Structured Streaming (autre scénario) 📐 Réf. Architecture Center — Stream processing with Azure Stream Analytics : pattern de référence streaming, considérations Cost (tarif par SU) et Operational Excellence (monitoring SU/Event Hubs). Lien

Scénario 3 : Industrie multi-domaines — BI self-service unifiée (greenfield Fabric)#

Contexte business : Groupe industriel avec plusieurs domaines data (production, ventes, supply), équipes métier autonomes voulant du self-service BI sans dupliquer la donnée, gouvernance à l'échelle du tenant. Projet neuf 2026. Choix architectural : Microsoft Fabric (OneLake + Lakehouse + Warehouse + Power BI Direct Lake), gouverné par Purview, dans des Data Management Landing Zones CAF. Fabric choisi car OneLake stocke la donnée une seule fois pour tous les moteurs. Architecture / pattern :

• Stockage unique : OneLake (format Delta) → pas de copies entre domaines
• Ingest/transform : Data Pipelines + Notebooks Fabric (medallion par domaine)
• Serving : Warehouse (T-SQL) + Power BI Direct Lake (lecture directe du Delta, sans import)
• Temps réel optionnel : Mirroring (Azure SQL DB / Snowflake en GA ; Cosmos DB NoSQL en preview)
• Gouvernance : Purview dans une Data Management Landing Zone (1 par tenant Entra) ; capacité Fabric par domaine Trade-offs assumés :
• Gain : une seule copie de donnée pour tous les moteurs, Direct Lake = pas de refresh d'import, pause de capacité = coût flexible
• Perte : plateforme SaaS récente (moins mature que Synapse+Databricks séparés) ; le sizing de capacité impacte pipelines ET requêtes en même temps Pièges à éviter :
• Cosmos DB mirroring encore en Preview (NoSQL only) → pas en prod ; Synapse Link Cosmos « non supporté pour les nouveaux projets »
• Fabric ≠ Synapse : nouvelle plateforme, OneLake comme storage unifié (ne pas confondre les composants)
• Dimensionner la capacité Fabric selon la maturité/prévisibilité du domaine (partagée vs dédiée) 📐 Réf. CAF — Azure architecture for a unified data platform (Data Management Landing Zones) : place Purview + capacité Fabric en DMLZ, gouvernance tenant-wide, séparation domaines/plateforme. Lien

DEMO#

Demo Portail — Créer un Data Factory#

1. Data factories > + Create
2. Onglet Basics : sub, RG, name (globalement unique), region
3. Onglet Git configuration : optionnel (Azure DevOps / GitHub pour versionning)
4. Onglet Networking : Public / Private (Managed VNet)
5. Review + Create
6. Une fois créé : Open Azure Data Factory Studio (UI séparée)

Demo Portail — Synapse workspace + SQL pool + Spark pool#

1. Créer le workspace#

1. Azure Synapse Analytics > + Create
2. Onglet Basics : RG, Workspace name, Region
3. Select Data Lake Storage Gen2 : Storage Account avec HNS + File system name raw
4. Onglet Security : SQL admin login + password + (recommandé) Entra admin
5. Onglet Networking : Managed virtual network : Enable, Public access : Disabled (prod)
6. Review + Create (5-10 min)
7. Ouvrir : Open Synapse Studio

2. Dedicated SQL pool#

1. mysynapse > Analytics pools > SQL pools > + New
2. Name mydw, Performance level DW100c
3. Review + Create → Pause/Resume via la blade pour économiser

3. Apache Spark pool#

1. mysynapse > Analytics pools > Apache Spark pools > + New
2. Name myspark, Node size Medium, Autoscale 3-10 nodes
3. Automatic pausing : Enabled (15 min idle), Spark version 3.4
4. Review + Create

📝 Pour Serverless SQL pool : il est créé automatiquement à la création du workspace (built-in, pas à provisionner).

Demo Portail — Créer un Databricks workspace#

1. Azure Databricks > + Create
2. Onglet Basics : RG, Workspace name, Region, Pricing Tier : Premium
3. Onglet Networking : VNet injection si isolation
4. Review + Create → Launch Workspace
5. Dans Databricks UI :
   • Compute > + Create cluster (autoscale, runtime, Photon enabled)
   • Workspace > Create > Notebook (Python/SQL/Scala)
   • Jobs > + Create Job pour scheduler
   • Catalog (Unity Catalog) : metastore + catalogs + schemas

Demo Portail — ADLS Gen2 + POSIX ACL#

1. Storage accounts > + Create
2. Onglet Basics : RG, Name (globalement unique), Performance Standard, Redundancy LRS/ZRS/GRS
3. Onglet Advanced : Hierarchical namespace : Enabled (irréversible)
4. Review + Create
5. Créer container : Storage Account > Containers > + Container → name raw
6. Créer folders : raw > + Add Directory → year=2026, month=01
7. POSIX ACL : naviguer vers le folder > ⋯ > Manage ACL
   • Access : Add principal (user/group/SP) + Read/Write/Execute
   • Default : ACL héritée par nouveaux fichiers du folder
   • Save

⚠️ HNS = irréversible, à cocher impérativement à la création pour tout workload analytics.

Demo Portail — ADF pipeline simple (Blob → SQL DB)#

Concept-level (pas step-by-step Data Flow).

1. Studio ADF > Manage > Linked services > + New :
   • Azure Blob Storage (auth via Managed Identity)
   • Azure SQL Database (auth MI + rôle db_datawriter)
2. Author > Datasets > + New :
   • Source : Blob > DelimitedText (CSV)
   • Sink : SQL DB > Table cible
3. Author > Pipelines > + New :
   • Drag Copy data activity → configurer Source + Sink + Mapping
   • (Optionnel) Data Flow : Filter → Derived Column → Aggregate → Sink
4. Author > Triggers > + New :
   • Schedule (cron) ou Event-based (blob créé) ou Tumbling Window (incrémental watermark)
5. Debug dans le designer → Publish all pour activer

Demo Portail — ADF Self-hosted IR (accès on-prem)#

1. Studio ADF > Manage > Integration runtimes > + New > Self-Hosted
2. Donner un name → générer 2 auth keys (sauvegarder)
3. Télécharger l'Integration Runtime agent (Windows)
4. Installer sur VM on-prem (ou Azure VM faisant proxy)
5. Entrer l'auth key → register → status Running dans ADF
6. Linked Services peuvent pointer SQL Server on-prem, file shares, etc.