Una delle competenze più valutate nel DP-600 è saper decidere quando NON copiare i dati. OneLake è il data lake unico e logico del tenant Fabric: ogni lakehouse, warehouse ed eventhouse vi scrive dentro, in formato Delta Lake su file Parquet. Gli shortcut sono i puntatori che rendono visibile in un lakehouse dati che risiedono altrove, senza duplicarli e senza pipeline.
Quando lo shortcut sostituisce una copia
Lo scenario tipico d’esame è: “i dati esistono già in ADLS Gen2 / Amazon S3 / in un altro workspace Fabric e devono comparire nel lakehouse con il minimo sforzo amministrativo e senza duplicazione”. La risposta è quasi sempre lo shortcut.
| Requisito nello scenario | Soluzione corretta |
|---|---|
| Dati già in ADLS Gen2, servono in un lakehouse, no ETL | Shortcut esterno su ADLS Gen2 |
| Tabella Delta di un altro workspace da riusare in un semantic model | Shortcut interno OneLake |
| Serve trasformazione, pulizia o cambio di formato | Pipeline / Dataflow Gen2 / notebook (non shortcut) |
| Serve una copia storicizzata e indipendente dall’origine | Copy activity o Mirroring |
| Origine è un database operativo (SQL, Cosmos DB, Snowflake) | Mirroring, non shortcut |
Il discrimine è netto: lo shortcut virtualizza, non trasforma. Se lo scenario chiede aggregazioni, deduplica o conversioni di schema, lo shortcut da solo non basta.
Shortcut interni vs esterni
Shortcut interni (OneLake) puntano a un altro elemento Fabric: lakehouse, warehouse, KQL database, nello stesso workspace o in un altro. Non richiedono credenziali: l’accesso è valutato sull’origine. Chi legge lo shortcut deve avere i permessi sull’elemento di destinazione; se non li ha, la cartella appare ma la lettura fallisce. Concedere il ruolo Viewer sul lakehouse che ospita lo shortcut non basta.
Shortcut esterni puntano a storage fuori da Fabric: ADLS Gen2, Amazon S3 e S3-compatible, Google Cloud Storage, Dataverse. Richiedono una connessione con credenziali dedicate (service principal, organizational account, SAS, account key, workload identity a seconda dell’origine). Qui la delega cade: tutti gli utenti che leggono lo shortcut usano l’identità della connessione, quindi il controllo accessi va gestito con i permessi Fabric e con la OneLake data access role sul lakehouse, non contando sui permessi dello storage.
Tables e Files: la distinzione che fa perdere punti
Un lakehouse ha due aree. In Files puoi mettere shortcut a qualsiasi cosa: CSV, JSON, immagini, cartelle miste. In Tables uno shortcut viene riconosciuto come tabella solo se punta a una cartella Delta valida, cioè contenente la sottocartella _delta_log. Se punti a una cartella di Parquet nudi o di CSV, la voce finisce fra le tabelle non identificate e il SQL analytics endpoint non la espone.
Corollario operativo: il SQL analytics endpoint e Direct Lake funzionano solo su Delta. Dati non-Delta raggiunti via shortcut vanno letti con Spark e materializzati come tabella Delta (o gestiti con OPENROWSET/viste lato warehouse) prima di essere interrogati in T-SQL o usati in un semantic model Direct Lake.
Governance, latenza e costi
Gli shortcut non spostano il dato, quindi non lo sottraggono ai controlli dell’origine, ma il perimetro di governance cambia: le etichette di sensibilità di Microsoft Purview e la lineage in Fabric seguono l’elemento, e per le origini esterne va documentato chi possiede la connessione. Per S3 e GCS ogni lettura genera traffico di egress fatturato dal cloud di origine e latenza cross-cloud: abilita la shortcut cache di OneLake (retention configurabile) quando lo stesso dato viene letto ripetutamente.
Trappole tipiche d’esame
- “Un utente vede lo shortcut nel lakehouse ma la query restituisce errore di accesso” → è uno shortcut interno: i permessi si valutano sull’elemento di origine. Va concesso l’accesso al lakehouse/warehouse target, non solo a quello che ospita lo shortcut.
- “Lo shortcut in Tables non appare nel SQL analytics endpoint” → la cartella puntata non è una tabella Delta valida (manca
_delta_log). Sposta lo shortcut in Files, oppure converti l’origine in Delta. - “Serve minimizzare i costi di egress su dati in Amazon S3 letti più volte al giorno” → NON creare una copia con una pipeline come prima risposta: abilita la cache dello shortcut. La copia si giustifica solo se serve anche trasformazione o isolamento dall’origine.
- “Un team ha creato uno shortcut che punta a un altro shortcut” → soluzione errata da correggere: le catene di shortcut complicano lineage e troubleshooting, si rompono se il target intermedio viene rimosso e non sono ammessi riferimenti circolari. Punta direttamente alla sorgente.
- “I dati devono restare in ADLS Gen2 ma comparire in un semantic model Direct Lake” → shortcut in Tables su cartelle Delta, poi semantic model in Direct Lake. Import mode e copie fisiche sono distrattori.