In Microsoft Fabric ogni workload scrive e legge su OneLake, il data lake logico unico del tenant. Il problema pratico del data engineer è portare dentro OneLake dati che vivono altrove — in storage cloud di terze parti o in database transazionali — senza costruire pipeline ETL fragili. Fabric offre due strategie complementari per farlo: gli shortcuts (virtualizzazione, ovvero riferimento ai dati) e il mirroring (replica gestita in near-real-time). Sapere quale scegliere, e perché, è il cuore di questa unità.

Shortcuts: virtualizzare senza copiare

Uno shortcut è un puntatore che rende visibile in OneLake un dato che risiede fisicamente altrove, senza duplicarlo. Il dato non viene spostato né copiato: Fabric lo espone come se fosse nativo, e i motori (Spark, SQL analytics endpoint, Power BI in Direct Lake) lo interrogano al momento della lettura.

Le sorgenti supportate includono:

  • ADLS Gen2 e Azure Blob Storage
  • Amazon S3 (e S3-compatible)
  • Google Cloud Storage
  • Dataverse
  • altri lakehouse o KQL database nello stesso tenant Fabric

Gli shortcuts sono ideali quando il dato è già in formato tabellare/file (tipicamente Delta o Parquet) e vuoi evitarne la ridondanza. Un caso classico: un data lake aziendale esistente su ADLS Gen2 che diversi team già alimentano — crei uno shortcut invece di ricopiare terabyte in OneLake. Attenzione però: la lettura attraversa la rete verso la sorgente, quindi latenza e costi di egress (soprattutto cross-cloud, es. S3) sono un fattore, ed eventuali shortcut cache aiutano solo in parte.

Mirroring: replica CDC gestita

Il mirroring risolve un problema diverso: portare in OneLake dati che vivono in un database transazionale, mantenendoli continuamente aggiornati. Fabric replica il database sorgente in OneLake in formato Delta, applicando in modo incrementale le variazioni via Change Data Capture (CDC). Il risultato è una copia analitica near-real-time, senza scrivere una sola pipeline.

Le sorgenti mirrorabili includono:

  • Azure SQL Database e Azure SQL Managed Instance
  • Azure Cosmos DB
  • Snowflake
  • Azure Database for PostgreSQL e altre sorgenti in espansione

Punto chiave d’esame: per i database supportati lo storage della replica non genera costo aggiuntivo (è incluso, entro le soglie legate alla capacity Fabric) e l’aggiornamento è continuo. Elimina il classico pattern “copy activity schedulata ogni notte” con tutte le sue finestre di staleness e i suoi fallimenti.

Quando virtualizzare e quando replicare

La scelta architetturale segue la natura della sorgente e del carico:

  • Shortcut (virtualizzazione) quando il dato è già in un object storage in formato file/Delta, quando vuoi evitare duplicazione e governare un’unica copia, o quando la sorgente è un altro artefatto Fabric.
  • Mirroring (replica) quando la sorgente è un database operativo (OLTP), quando ti serve freschezza continua senza gestire ETL, e quando vuoi eseguire analytics pesante senza impattare il carico transazionale del database di origine.

In sintesi: shortcut = riferimento a file esistenti; mirroring = copia viva di un database. Non sono alternative sullo stesso dato, ma risposte a due scenari distinti. Entrambi convergono nell’obiettivo di Fabric: un solo posto (OneLake), formato aperto (Delta), zero silos.

Trappole tipiche d’esame

  • Scenario: devi analizzare in Fabric i dati di un Azure SQL Database in produzione mantenendoli sempre aggiornati, senza costruire pipeline ETL. → Risposta giusta: mirroring (CDC near-real-time, nessun costo storage aggiuntivo, nessun impatto sull’OLTP), non uno shortcut.
  • Scenario: un data lake su Amazon S3 già popolato deve essere interrogato da Fabric senza copiarne i file. → Risposta giusta: shortcut S3, non una copy pipeline né il mirroring (il mirroring è per database, non per object storage).
  • Scenario: il team teme la duplicazione e vuole un’unica copia governata di file Delta già presenti in ADLS Gen2. → Risposta giusta: shortcut (virtualizzazione, nessuna copia fisica), non un’ingestion con Data Factory.
  • Scenario: devi replicare Snowflake o Cosmos DB in OneLake in formato analitico aperto senza scrivere codice di trasformazione. → Risposta giusta: mirroring (sorgenti supportate), che materializza automaticamente in Delta.
  • Trappola sui costi: affermare che il mirroring “raddoppia i costi di storage” è falso per i database supportati — la replica mirrored non ha costo storage aggiuntivo; il consumo rilevante è quello di compute/capacity in lettura.