ADLS Gen2 non è un servizio a sé: è Blob Storage con l’hierarchical namespace

Azure Data Lake Storage Gen2 (ADLS Gen2) non è un prodotto separato da Blob Storage: è un general-purpose v2 storage account su cui è stato attivato l’hierarchical namespace (HNS). Questa singola opzione, scelta alla creazione dell’account (checkbox “Enable hierarchical namespace”), trasforma il modello di storage e abilita le capacità che l’esame associa al data lake.

Flat namespace vs hierarchical namespace

Nel Blob Storage classico il namespace è flat: i “path” con gli slash (raw/2026/07/file.parquet) sono solo prefissi nel nome del blob, non vere directory. Rinominare o spostare una “cartella” significa copiare e ricreare ogni singolo blob, un’operazione O(n) non atomica.

Con l’HNS le directory sono oggetti first-class nel file system:

  • Operazioni atomiche su directory — rename e move di una cartella sono metadata operation istantanee, non copie ricorsive. Fondamentale per i pattern write-to-temp-then-rename di Spark, Hive e i job idempotenti.
  • POSIX-style ACL — oltre all’RBAC di Azure a livello di container, HNS abilita ACL granulari su file e directory con permessi read/write/execute per security principal (utenti/gruppi/service principal Entra ID). RBAC e ACL sono complementari: RBAC concede i ruoli grossolani (es. Storage Blob Data Contributor), le ACL rifiniscono l’accesso alla singola cartella.
  • Blob File System driver (abfs/abfss) — l’endpoint dfs.core.windows.net (distinto dal blob.core.windows.net) è quello che Spark usa via schema abfss://.

Trap concettuale: l’HNS si abilita solo alla creazione dell’account e non è reversibile a caldo. Un account senza HNS resta Blob Storage puro, non un data lake.

Access tier: hot, cool, cold, archive

I dati raramente accessi costano meno se archiviati nel tier giusto. Le tre variabili sono storage cost, access cost e minimum retention period:

  • Hot — dati acceduti di frequente. Storage alto, accesso basso. Landing zone e dataset “caldi”.
  • Cool — accesso infrequente, retention minima 30 giorni. Backup, dataset mensili.
  • Cold — retention minima 90 giorni, ancora più economico di cool, ma online (accesso immediato).
  • Archive — costo storage minimo, ma offline: il blob non è leggibile finché non viene reidratato. Retention minima 180 giorni. Solo a livello di blob, non impostabile come default dell’account.

Lifecycle management policy

La transizione non va fatta a mano: si definisce una lifecycle management policy (regole JSON) che sposta o elimina i blob in base a daysAfterModificationGreaterThan o daysAfterLastAccessTimeGreaterThan (quest’ultimo richiede il last access time tracking abilitato). Tipico: hot → cool a 30 giorni, cool → archive a 180, delete a 2555.

ADLS Gen2 come landing zone e integrazioni

ADLS Gen2 è la landing zone canonica di un’architettura medallion (bronze/silver/gold). Ingest via Azure Data Factory o Synapse pipelines, poi:

  • Azure Synapse Analytics — Serverless SQL pool interroga direttamente Parquet/CSV via OPENROWSET senza spostare i dati; Spark pool legge/scrive con abfss://. Autenticazione consigliata: managed identity dell’workspace con ruolo Storage Blob Data Contributor.
  • Azure Databricks — accesso via Unity Catalog con external location + storage credential (managed identity), pattern moderno rispetto al vecchio mount con service principal.
  • Microsoft Fabric — OneLake è costruito sopra ADLS Gen2 e vi si integra via shortcut, senza duplicare i dati.

Trappole tipiche d’esame

  • Scenario: serve un data lake con ACL POSIX e rename atomici di cartelle. Risposta: general-purpose v2 con hierarchical namespace abilitato (= ADLS Gen2), non un account Blob standard.
  • Scenario: un job segnala che i dati non si leggono perché il blob è “not accessible” nel tier archive. Risposta: reidratare da archive a hot/cool (latenza fino a circa 15 ore in standard priority); l’archive è offline, non interrogabile direttamente.
  • Scenario: minimizzare i costi di dati storici acceduti raramente ma senza gestione manuale. Risposta: lifecycle management policy con transizione automatica a cool/cold/archive, non spostamento manuale.
  • Scenario: dopo aver spostato in cool, il team elimina i blob dopo 10 giorni e la bolletta aumenta. Risposta: è l’early deletion charge — cancellare prima del minimo (cool 30 gg, cold 90, archive 180) fa pagare i giorni residui.
  • Scenario: Spark su Synapse/Databricks deve autenticarsi allo storage. Risposta: managed identity + ruolo Storage Blob Data Contributor, non chiavi dell’account o SAS statiche.