Unity Catalog, Databricks porta REGISTER e UNREGISTER nello spec Iceberg

Databricks dichiara che Unity Catalog è il primo catalogo a supportare REGISTER e UNREGISTER dello spec REST di Apache Iceberg, così le tabelle possono passare tra cataloghi senza copiare dati¹.

REGISTER e UNREGISTER fanno entrare o uscire una tabella dal catalogo. I file restano nello storage dell’utente, non si spostano. Databricks afferma di aver contribuito UNREGISTER allo spec, ora parte dello standard REST di Iceberg. Unity Catalog implementa entrambe le operazioni¹.

Il punto, per Databricks, è l’apertura del lakehouse. Un catalogo è “aperto” se rispetta tre requisiti: i dati restano nello storage di proprietà dell’utente, le funzionalità del catalogo operano su quello storage, le tabelle si muovono tra cataloghi senza migrazioni dei file. Molte piattaforme supportano formati aperti, ma Databricks lega l’apertura vera alla portabilità tra cataloghi, non alla sola compatibilità di formato¹.

Portabilità qui significa cambiare la gestione, non la posizione dei file. La tabella entra o esce dal catalogo con REGISTER o UNREGISTER. I percorsi dei dati non cambiano. Databricks sostiene che questo principio, centrale per l’open lakehouse, spesso non trova attuazione in altri cataloghi¹.

Unity Catalog applica questa idea in modo standard. Le tabelle Iceberg già esistenti possono essere registrate o rimosse dal catalogo senza ricopiare i dataset. Il beneficio è immediato: si evita il lock-in operativo legato a migrazioni fisiche dei dati, pur restando nello spazio di archiviazione del cliente¹.

La mossa punta anche alla convergenza sugli standard. Con il contributo a UNREGISTER nello spec REST, Databricks lega la portabilità a un meccanismo codificato e comune. Non serve un’integrazione ad hoc per ogni piattaforma. Serve rispettare lo spec. Unity Catalog si allinea e offre l’insieme completo delle operazioni previste, REGISTER e UNREGISTER¹.

Nel post Databricks riassume l’architettura che ne discende: storage di proprietà dell’utente, motori esterni che leggono e scrivono, catalogo che aggiunge governance e funzionalità senza spostare i dati. In questo quadro, la portabilità tra cataloghi resta il criterio discriminante. Se una tabella può passare da un catalogo all’altro senza muovere file, il sistema si definisce aperto. Se non può, la compatibilità di formato non basta¹.

Chiusura pratica dal post: Databricks annuncia un confronto sulle conseguenze per una stessa tabella Iceberg su piattaforme diverse. L’obiettivo è mostrare come l’implementazione del catalogo cambi la vita della tabella. Per chi gestisce dati, l’esito atteso è verificare sul campo la portabilità promessa da REGISTER e UNREGISTER nello spec REST di Iceberg¹.