Open Interoperability: offrire libertà di scelta ai clienti

Anche se il concetto risulterà intuitivo a chi legge questo blog, cominciamo con il definire l'interoperabilità open. L'interoperabilità open è la capacità di progettare la piattaforma dati della tua organizzazione in modo da accedere in sicurezza ai dati governati attraverso interfacce open, pubbliche e basate su standard, riducendo il lock‑in proprietario e favorendo una più ampia compatibilità con l'ecosistema.

L'interoperabilità open trasforma il rapporto che le organizzazioni hanno con i propri dati. Offre loro autonomia sui dati, ovvero la libertà di scegliere l'engine e lo strumento migliore per ogni workload senza migrazioni onerose o spostamenti di dati. Questa definizione è al centro del modo in cui Snowflake offre esperienze di prim'ordine per Apache Iceberg™ e Apache Polaris™. Il risultato consente ai clienti di ospitare le proprie Iceberg Tables su Snowflake o altrove, con piena capacità di lettura e scrittura su queste tabelle, senza imporre la migrazione al nostro catalog.

Anche Databricks Unity Catalog dichiara di essere interoperabile ma, a un esame attento, si scopre che non mantiene nemmeno le promesse più elementari dell'interoperabilità open: la capacità di leggere o scrivere su qualsiasi Iceberg Table e di farlo utilizzando meccanismi di sicurezza open che evitano il lock‑in a un singolo strumento.

Leggere e scrivere su qualsiasi Iceberg Table

La scelta di un catalog per le tue tabelle è la decisione più critica della tua architettura. Determina quali operazioni puoi eseguire su queste e su altre tabelle, ampliando o limitando le tue possibilità. Ed è qui che entra in gioco la vera interoperabilità. La vera interoperabilità richiede federazione sia inbound sia outbound tramite standard open guidati dalla community. Federazione inbound significa che engine esterni al tuo catalog possono leggere e scrivere sulle tue Iceberg Tables, mentre federazione outbound significa che puoi leggere o scrivere su Iceberg Tables gestite da un catalog diverso.

Unity Catalog non supera il test dell'interoperabilità

Al momento in cui scriviamo, Unity Catalog supporta la piena interoperabilità in una sola direzione: quella inbound. Per l'accesso inbound, gli engine esterni possono connettersi agli endpoint Iceberg REST Catalog di Unity Catalog per accedere alla tabella. Per l'accesso outbound, il quadro è radicalmente diverso. Quando accede alle Iceberg Tables provenienti da catalog esterni come Snowflake Horizon, Databricks non utilizza le API Iceberg REST Catalog. Al loro posto usa lo Snowflake Catalog SDK, che ricorre a JDBC per recuperare il metadata.json path e poi accede direttamente allo storage sottostante utilizzando credenziali IAM preconfigurate (docs). Per di più, questo funziona solo per le operazioni di lettura. Le Iceberg Tables gestite da catalog esterni restano esplicitamente di sola lettura; le scritture su Iceberg Tables esterne non sono supportate (docs).

L'impatto sulla tua capacità di ottenere autonomia sui dati è innegabile. Quando ospiti i tuoi workload su Databricks e Unity Catalog, di fatto sei costretto a migrare l'intero patrimonio di dati su Unity Catalog, tradendo la promessa di base dell'interoperabilità e la stessa affermazione secondo cui Unity Catalog sarebbe il catalog più "interoperabile sul mercato".

Snowflake Horizon Catalog è tutt'altra cosa. Costruito sulle fondamenta di Apache Polaris, Snowflake Horizon Catalog offre un'implementazione end‑to‑end del protocollo Iceberg REST Catalog. Horizon è il livello di governance nativo di Snowflake, in cui classificazione, policy di accesso, lineage, qualità e gestione del catalog vengono applicati in modo coerente a tutte le Iceberg Tables gestite o consultate da Snowflake, senza limitare le operazioni di lettura o scrittura. Per di più, i team che operano sui dati provenienti da Snowflake ottengono una visione completa di dove risiedono i dati sensibili nell'intero patrimonio, e non una visione parziale limitata dalla piattaforma o dal tipo di tabella. Ciò è possibile perché Horizon Catalog si connette a catalog esterni come Unity Catalog tramite una feature chiamata Catalog Linked Databases e chiama direttamente l'endpoint Iceberg REST Catalog del catalog per ottenere l'accesso per quella specifica query. Non serve aprire un ticket con il team della piattaforma per negoziare un nuovo ruolo IAM, una credenziale a lunga durata o per gestire un nuovo meccanismo di sicurezza.

Perché la sicurezza open è determinante per l'interoperabilità

L'Iceberg REST Catalog definisce il modo in cui i catalog dovrebbero comunicare tra loro in sicurezza. La feature si chiama vended credentials. Le credenziali vending sono token a breve durata delegati dal catalog di origine per operazioni specifiche. Offrono un meccanismo che rende il tuo catalog la fonte di verità per le tue tabelle e per il tuo profilo di sicurezza. Tuttavia, sebbene sia previsto dalla specifica dell'Iceberg REST Catalog, nulla obbliga i catalog a implementarlo. L'alternativa alle vended credentials è un accesso su base ampia tramite ruoli IAM e credenziali a lunga durata come le access key. Questi approcci aggiungono complessità e potenziale rischio al tuo profilo di sicurezza. In primo luogo, non sono limitati alla specifica query o, in pratica, a una tabella specifica. In secondo luogo, le policy devono essere duplicate nel catalog di origine e nel livello IAM, vanificando le fondamenta di un'open interoperabilità sicura come raccomandato nella specifica Iceberg REST.

Snowflake Horizon Catalog implementa pienamente le credenziali vending per la federazione sia inbound sia outbound, offrendoti un unico punto di controllo per gestire le tue Iceberg Tables e le policy di accesso per qualsiasi engine che accede alle tue Iceberg Tables gestite da Snowflake. In pratica, questo significa che puoi definire le policy di accesso in Horizon Catalog e vederle applicate nell'engine che preferisci senza lavoro aggiuntivo. Se finora questo funzionava a livello di oggetto (catalog, namespace e tabelle), la nuova Scan Plan API, in private preview, estende la governance a controlli di accesso granulari a livello di riga e di colonna per gli engine compatibili. Al momento in cui scriviamo, Unity Catalog non rispetta le policy di accesso del tuo catalog di origine perché non utilizza le credenziali emesse dai catalog esterni.

Analisi completa: il catalog più interoperabile? Decidi tu

Puoi comunque usare Databricks, ma senza Unity Catalog

Sebbene le limitazioni descritte riguardino Unity Catalog, il compute di Databricks può comunque ottenere piene capacità di lettura/scrittura con catalog esterni che supportano le API Iceberg REST (IRC), come Snowflake Horizon. I clienti possono ottenerlo configurando un cluster Databricks Spark senza Unity Catalog abilitato. In questa configurazione, il cluster mantiene pieno accesso in lettura/scrittura a qualsiasi catalog conforme a IRC e ogni query rispetta le policy di accesso. Tuttavia, abilitando Unity Catalog sul cluster questa funzionalità viene limitata, a conferma del fatto che si tratta di una limitazione specifica di Unity Catalog e non della piattaforma Databricks nel suo complesso. L'uso delle variabili di sessione Spark per connettersi a Iceberg è supportato da Spark open source. Tieni presente che, adottando questo metodo, operi al di fuori del modello di integrazione di Unity Catalog.

Il percorso verso una vera autonomia sui dati

Una vera autonomia sui dati si fonda sulla libertà di scelta: la libertà di scegliere gli engine e gli strumenti migliori per i tuoi workload specifici, senza il prezzo di migrazioni forzate o di modelli di sicurezza a silos. L'interoperabilità è molto più di una specifica tecnica: è un impegno verso un'architettura che mette il cliente al primo posto.

Nella scelta di un catalog, la differenza sta nell'implementazione degli standard open. Un catalog che riduce l'interoperabilità alla sola connettività inbound ti costringe a scegliere tra il compute engine che preferisci e il modello di governance che desideri. Al contrario, un'implementazione end‑to‑end del protocollo Iceberg REST Catalog — come quella che abbiamo integrato in Snowflake Horizon — abilita un accesso bidirezionale che rispetta il tuo profilo di sicurezza, indipendentemente dall'engine che scegli.

Per i data leader l'obiettivo è chiaro: fai in modo che le tue decisioni architetturali amplino le opzioni future anziché restringerle. Ti invitiamo a dare priorità ai catalog che considerano la sicurezza open e l'interoperabilità bidirezionale elementi di prim'ordine. Adottando un approccio realmente open, garantisci che i tuoi dati restino un asset strategico sotto il tuo controllo, e non una dipendenza vincolata a un unico provider.

Questo post fa riferimento a feature in Public Preview e soggette a modifica. Le feature in preview potrebbero non essere adatte all'uso in produzione. Consulta la documentazione Snowflake per conoscere la disponibilità attuale delle feature.

• Federazione inbound e outbound tramite credenziali vending
• Supporto in scrittura per le tabelle gestite esternamente

Apache Iceberg e Apache Polaris sono marchi della Apache Software Foundation

1. “Credential vending on Foreign Iceberg tables is not supported.” docs.databricks.com/aws/en/external-access/iceberg
2. “External federated Hive metastore and all foreign tables accessed through Lakehouse Federation are read-only.” docs.databricks.com/aws/en/tables/foreign
3. “With cross-engine attribute-based access controls (ABAC) now in Beta, Unity Catalog extends attribute-based access control to Iceberg clients using the Iceberg REST Catalog Scan APIs.” databricks.com/blog/unity-catalog-and-next-era-apache-icebergtm
4. “Tables with row filters or column masks and ABAC-tagged resources are flagged as failed to replicate in the system table, and these failures hold up RPO until you remove the resource from the failover group's scope.” docs.databricks.com/aws/en/admin/managed-disaster-recovery (aggiornato il 19.06.2026)