Sbloccare la portabilità dei dati: prevenire il lock-in del catalogo con le API REGISTER e UNREGISTER

Mentre le organizzazioni adottano l'architettura lakehouse, i dati si stanno spostando dai data warehouse proprietari a formati di archiviazione e tabelle aperti, dove è possibile accedervi da più motori, come Spark e Trino, senza duplicazioni.

Tuttavia, i formati aperti sono solo una parte dell'equazione dell'apertura. La vera apertura richiede anche interoperabilità e flessibilità nel modo in cui i dati vengono gestiti e governati. Affinché un lakehouse mantenga appieno la sua promessa, le organizzazioni hanno bisogno della libertà di scegliere e spostarsi tra i cataloghi man mano che la loro architettura si evolve.

Per supportare questa portabilità, gli endpoint REGISTER e UNREGISTER consentono agli utenti di trasferire una tabella tra cataloghi senza riscrivere, esportare o copiare un singolo file. REGISTER collega una tabella esistente a qualsiasi catalogo IRC. Quando si sposta una tabella, non è possibile semplicemente eseguirne il DROP dal vecchio catalogo, perché ciò eliminerebbe i dati e i metadati sottostanti. Abbiamo aggiunto l'endpoint UNREGISTER alla specifica del catalogo Apache Iceberg™ REST in modo da poter indicare al vecchio catalogo di ignorare la tabella e restituire il puntatore esatto necessario al catalogo successivo per subentrare.

In questo post vedremo più da vicino come si sta evolvendo l'ecosistema dei formati di tabella aperti, le sfide chiave affrontate da queste aggiunte e come funzionano effettivamente REGISTER e il nuovo comando UNREGISTER.

Contesto: il ruolo del catalogo

Quando un motore interroga una tabella, chiede prima al catalogo di caricare la tabella per assicurarsi che disponga dello stato più recente. Il catalogo restituisce i metadati correnti della tabella, inclusa la posizione dei dati della tabella nell'object storage. Da lì, il motore utilizza tali metadati per trovare lo schema e legge il file Parquet direttamente dall'object storage.

Questa coordinazione è essenziale per i formati di tabella aperti perché tutti i metadati importanti (schema, cronologia, statistiche) e i dati stessi risiedono nell'archiviazione, completamente disaccoppiati dal calcolo. Fungendo da autorità centrale per lo stato più recente, il catalogo coordina i commit e garantisce che due writer non possano mai sovrascriversi a vicenda in modo silenzioso.

Figura 1: il percorso di lettura

1. Il motore chiede al catalogo di caricare la tabella.
2. Il catalogo restituisce i metadati correnti della tabella e la sua posizione nell'object storage.
3. Il motore legge i metadati e i file di dati direttamente dal tuo bucket.

Come funziona l'endpoint REGISTER

Collegare una tabella esistente a un catalogo è semplicemente una questione di trasferire la posizione dei metadati dal caricamento della tabella. Questo è esattamente ciò che fa REGISTER attraverso l'endpoint già definito nella specifica Iceberg REST.

Figura 2: l'operazione REGISTER

• Un client invia una richiesta POST con il nome della tabella desiderato e l'URI della sua posizione dei metadati esistente.
• Dopo una convalida di base, il catalogo scrive un singolo record che collega il nome della tabella al file metadata.json esistente. Nessun file di dati viene copiato, spostato o modificato.

L'inconveniente è che REGISTER da solo creerebbe uno scenario "split-brain", in cui due cataloghi pensano di possedere la tabella e coordineranno i commit. Poiché i cataloghi Iceberg sono indipendenti e non comunicano, REGISTER da solo aggiunge una voce al nuovo catalogo lasciando quello vecchio completamente attivo. Se entrambi i cataloghi credono di essere l'unico proprietario della tabella, nessuno dei due genererà un errore, ma la prima operazione di scrittura creerà una ramificazione (fork) della tabella, portando a risultati di query incoerenti e perdita silenziosa di dati.

Figura 3: lo scenario split-brain

• Una scrittura effettuata tramite il Catalogo A sarà completamente invisibile al Catalogo B, distruggendo in modo permanente la tua singola fonte di verità.

Il tassello mancante era UNREGISTER

Storicamente, l'ecosistema era privo di un modo standard per terminare in modo pulito la gestione di una tabella da parte di un catalogo. L'esecuzione di DROP TABLE non funziona perché elimina i dati e i metadati della tabella! Senza UNREGISTER, all'equazione di trasferimento per REGISTER mancava la seconda metà. Abbiamo contribuito con UNREGISTER alla specifica del catalogo Apache Iceberg™ REST per rimuovere la voce della tabella dal catalogo di gestione senza toccare un singolo file di dati sottostante.

In modo cruciale, restituisce la posizione dei metadati più recente della tabella, ovvero il puntatore esatto di cui il catalogo successivo ha bisogno per assumere la coordinazione dei commit. Garantendo che il catalogo originale ceda esplicitamente il controllo, si elimina il rischio di uno scenario split-brain.

La richiesta è una POST vuota alla risorsa della tabella:

POST <uc-iceberg-rest-base>/v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister

La risposta è il puntatore di cui ha bisogno il catalogo successivo:

Figura 4: il processo di trasferimento

1. UNREGISTER rimuove la voce della tabella dal Catalogo A (i file rimangono esattamente dove sono).
2. La risposta restituisce la posizione dei metadati più recente della tabella.
3. Il Catalogo B recupera il puntatore utilizzando l'endpoint REGISTER. Il Catalogo B è ora l'unico catalogo di gestione della tabella.

Combinando questi tre passaggi (annullamento della registrazione, ricezione della posizione e registrazione), il trasferimento garantisce che la tabella abbia sempre esattamente un solo catalogo di gestione. (Nota: una migrazione in produzione comporta ancora passaggi operativi, come l'arresto sicuro dei writer e il reindirizzamento dei job, di cui parleremo in un post successivo).

Per iniziare

Con REGISTER e UNREGISTER, ora hai la libertà di spostare le tue tabelle in altri cataloghi. Stiamo aggiungendo questa funzionalità perché la portabilità open source è fondamentale per i nostri clienti. Unity Catalog rimane il lakehouse più aperto per la gestione dei tuoi dati, fornendo la governance unificata richiesta dall'era agentica. Fornisce il livello di contesto per la tua ontologia, offre controllo degli accessi e osservabilità leader del settore per dati e agenti, e offre flessibilità tra cloud, aree geografiche e risorse di calcolo.

Per provare REGISTER e UNREGISTER su Unity Catalog in private preview, contatta il tuo account team.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale