Da Iceberg all’intelligenza: il lakehouse senza confini e pronto per l’AI con Snowflake e Google Cloud

Iceberg: dal silo all’interoperabilità

Un tempo ogni database possedeva i propri dati, una soluzione valida finché le organizzazioni disponevano di un unico motore analitico. Oggi i data team combinano spesso Apache Spark™, BigQuery, Gemini Enterprise Agent Platform, Snowflake (inclusi CoCo e CoWork di Snowflake) e altri servizi a seconda del processo, spesso all’interno della stessa pipeline.

Ne è nata una dicotomia: scegliere la flessibilità o la coerenza.

• Lasciare che ogni team utilizzi il motore preferito e replicare i dati tra i sistemi, con conseguente ridondanza, incoerenza e rischio.
• Costringere tutti a un unico motore, sacrificando la specializzazione e l’autonomia offerte dalle architetture multi-motore.

Il settore aveva bisogno di una terza opzione, emersa da un principio fondamentale noto come Data Locality: spostare una piccola porzione di codice eseguibile dove risiedono già i dati è più rapido, economico e sicuro rispetto a trasferire volumi ingenti di dati attraverso una rete.

Queste idee convergono verso un unico modello: anziché copiare i dati su ogni motore, si porta la capacità di calcolo di ciascun motore ai dati. Tutti i dati risiedono nello storage bucket del cliente e tutti i motori concordano sulla loro disposizione fisica, così ciascuno può leggere e scrivere direttamente sulla stessa tabella.

Questo richiede un formato tabellare open condiviso: un linguaggio comune compreso da tutti i motori.

Il settore ha scelto Apache Iceberg™ come formato di riferimento. Sviluppato da Netflix per la gestione di tabelle su scala petabyte e successivamente donato alla Apache Software Foundation, Iceberg è supportato da Spark, Trino, Flink, BigQuery, Snowflake e decine di altri motori. Con Iceberg come linguaggio condiviso, ogni motore partecipa senza bisogno di adattatori proprietari.

Catalogo: da Iceberg al lakehouse

Un formato open risolve in gran parte l’interoperabilità, ma solleva una nuova domanda: chi è al comando? Quando più motori possono leggere e scrivere gli stessi file, qualcuno deve gestire i metadati delle tabelle, applicare le policy di accesso, coordinare i writer concorrenti e garantire che nessun motore visualizzi uno stato obsoleto o incoerente. Questo ruolo spetta al catalogo, che funge da layer di governance del lakehouse. È l’unica autorità che sa quali tabelle esistono, come sono strutturati i loro schemi, chi può accedervi e dove risiedono fisicamente i file di dati. Senza un catalogo, i dati open sono dati privi di governance.

Il catalogo controlla anche l’accesso allo storage tramite credenziali fornite su richiesta. Quando un motore richiede i dati di una tabella, il catalogo restituisce token di storage temporanei e con ambito ristretto, anziché credenziali permanenti del bucket, così i motori non ottengono un accesso persistente al layer di storage sottostante.

Perché questo modello funzioni tra motori sviluppati da vendor diversi, i cataloghi necessitano di un protocollo di integrazione standardizzato. In sua assenza, ogni motore richiederebbe un’integrazione personalizzata con ciascun catalogo. L'Iceberg REST Catalog (IRC) è la specifica API open che risolve questo problema: definisce come i client individuano i namespace, caricano i metadati delle tabelle e ne inviano gli aggiornamenti. Ogni catalogo espone un endpoint IRC e ogni motore si connette come client.

Questa combinazione di credenziali fornite su richiesta e di un protocollo standard rende pratico per i motori superare i confini tra cataloghi, ciò che il settore chiama federazione. Quando una query Snowflake raggiunge il catalogo Lakehouse di Google Cloud, o un processo BigQuery legge da Snowflake Horizon, ciascun catalogo emette solo i token ristretti e a tempo limitato di cui il motore richiedente ha effettivamente bisogno, così la governance viene applicata indipendentemente dal motore che avvia la richiesta. Una vera interoperabilità richiede tutto questo in entrambe le direzioni: la federazione inbound, in cui i motori esterni al tuo catalogo possono leggere e scrivere le tue Iceberg Tables, e la federazione outbound, in cui la tua capacità di calcolo può leggere e scrivere Iceberg Tables gestite da un catalogo diverso.

Insieme, il catalogo e le credenziali fornite su richiesta offrono un layer di governance a singola autorità che applica la sicurezza, controlla gli accessi e centralizza gli audit. I clienti possono ora accedere in modo bidirezionale alle Iceberg Tables tra cataloghi diversi, abilitando un’architettura zero-copy tra i motori compatibili con Iceberg.

La domanda architetturale chiave diventa quindi: chi gestisce il catalogo? I clienti possono implementare un catalogo self-managed di tipo DIY oppure, più probabilmente, utilizzare un Iceberg REST Catalog gestito.

Le aziende che preferiscono l’approccio DIY possono implementare Apache Polaris™, una diffusa implementazione IRC open source, originariamente co-creata da Snowflake e Dremio e donata alla Apache Software Foundation. Questo offre a tali organizzazioni il pieno controllo, ma trasferisce anche l’intera responsabilità operativa (infrastruttura, scaling, patching e disponibilità) al team del cliente. A differenza delle soluzioni gestite, i cataloghi DIY non sono serverless e non scalano a zero quando non sono in uso, generando un costo operativo continuo.

In pratica, la maggior parte delle organizzazioni sceglie un IRC gestito per potersi concentrare sui dati anziché sulle operazioni del catalogo. Quando entrano in gioco sia Snowflake sia Google Cloud, ciascuno offre una soluzione naturale:

• Lakehouse runtime catalog (il catalogo Iceberg gestito di Google Cloud, parte di Lakehouse for Apache Iceberg) è un metastore serverless e scalabile che funge da fonte unica di verità per il tuo data lakehouse. Consente a più motori (BigQuery, Spark gestito da Google, Apache Spark, Trino, Snowflake) di accedere alla stessa copia dei dati tramite formati open come Apache Iceberg. La federazione consente ad agenti e motori in Google Cloud di accedere ai dati oltre i confini dei cataloghi in Snowflake, Databricks e AWS Glue.
• Snowflake Horizon Catalog integra Apache Polaris e incorpora endpoint IRC conformi agli standard in ogni account Snowflake, senza configurazioni aggiuntive. Oltre alle operazioni di base del catalogo, Horizon aggiunge la governance enterprise: RBAC, mascheramento a livello di colonna, policy di accesso righe, data lineage e audit logging. Consente ai motori conformi a Iceberg, come Trino, BigQuery, Apache Flink e molti altri, di leggere e scrivere sulle Iceberg Tables gestite da Snowflake.

Federazione: dal lakehouse all’open lakehouse

Lakehouse runtime catalog, Snowflake Horizon Catalog e le altre opzioni di catalogo gestito non si escludono a vicenda. Possono coesistere nella stessa organizzazione tramite la federazione dei cataloghi, permettendo alle organizzazioni di partire da un unico catalogo e federarsi in modo incrementale con l’evolvere delle esigenze.

Ogni catalogo gestisce le proprie tabelle, mentre tutti i motori vi accedono tramite IRC.

Quando Google Cloud gestisce il catalogo tramite Lakehouse runtime catalog, Snowflake si connette attraverso un Catalog-Linked Database (CLD) che individua e sincronizza automaticamente le tabelle dai suoi endpoint IRC. Gli utenti Snowflake interagiscono con queste Iceberg Tables del Lakehouse di Google Cloud utilizzando SQL standard (SELECT, INSERT, UPDATE, DELETE) oppure tramite CoCo o CoWork di Snowflake, come se fossero tabelle native, con la governance Snowflake (RBAC, mascheramento, lineage) applicata al di sopra.

Allo stesso modo, quando Snowflake gestisce il catalogo tramite Horizon, i servizi Google Cloud raggiungono quelle tabelle tramite la federazione dei cataloghi Lakehouse: BigQuery, Managed Service for Apache Spark e altri motori compatibili con Iceberg in Google Cloud si connettono all’endpoint IRC di Horizon e leggono/scrivono direttamente sulle Iceberg Tables gestite da Snowflake.

Il risultato è una piattaforma dati completamente open e interoperabile: tutti i motori leggono e scrivono direttamente dal Cloud Storage Bucket dei clienti, senza ETL tra i sistemi, e ogni team sceglie lo strumento più adatto al processo in base alle specifiche esigenze e preferenze del team. Nel frattempo, il layer del catalogo applica una governance unificata su tutti loro.

Contesto semantico: dall’open lakehouse alla predisposizione per l’AI

Un lakehouse ben progettato risolve in gran parte l’interoperabilità dei dati, ma l’interoperabilità da sola non rende i dati utili all’AI. Tra “i dati sono accessibili” e “l’AI produce risposte e azioni accurate e affidabili” esistono tre lacune:

• Accesso programmatico
• Grounding semantico
• Intelligenza contestuale

Accesso programmatico
Gli analisti umani interrogano le tabelle tramite il motore preferito, ma gli agenti AI necessitano di canali propri. Snowflake espone server model context protocol (MCP) che consentono a qualsiasi client compatibile con MCP di individuare, interrogare e ragionare sui dati del lakehouse. MCP è uno standard open che offre un’interfaccia universale tra applicazioni AI e fonti di dati: Gemini Enterprise, gli assistenti di codice e i framework di agenti personalizzati si connettono tutti tramite lo stesso protocollo, senza richiedere integrazioni su misura. Allo stesso modo, anche BigQuery offre un server MCP accessibile sia da agenti AI first-party sia third-party, abilitando l’accesso programmatico agli asset del lakehouse per i workflow agentici in ambienti Google Cloud e multi-cloud.

Per le app che richiedono un controllo programmatico diretto, come framework di orchestrazione, pipeline personalizzate o analytics integrati, anche i Cortex Agents e gli agenti Gemini Enterprise sono accessibili tramite REST API. Insieme, MCP e REST offrono agli agenti AI lo stesso accesso governato e autenticato alle Iceberg Tables di cui dispongono gli analisti umani, indipendentemente dal catalogo che le gestisce.

Grounding semantico
I sistemi AI generano allucinazioni quando non comprendono ciò che i dati rappresentano. I modelli semantici colmano questa lacuna definendo la logica di business al di sopra delle tabelle fisiche: metriche con regole di calcolo, dimensioni con gerarchie, relazioni tra entità e pattern di query verificati che codificano il patrimonio di conoscenza aziendale. L’insight cruciale è che la logica di business appartiene al data layer, non ai prompt dell’AI. Quando le definizioni risiedono in un modello semantico sopra i dati, ogni sistema AI eredita la stessa logica corretta, riducendo deviazioni, incoerenze e supposizioni.

Semantic View Autopilot, parte di Horizon Context, rende tutto questo sostenibile su larga scala. Anziché richiedere agli analisti di definire manualmente centinaia di modelli semantici, Autopilot li individua e li mantiene automaticamente, apprendendo da pattern di query, comportamento degli utenti, relazioni tra tabelle, integrazioni con strumenti di BI e utilizzo dei report. Per i team che preferiscono creare e perfezionare i modelli in linguaggio naturale, l’assistente CoCo integrato in Semantic Studio (in private preview) affianca un editor visivo e YAML con integrazione Git, così le definizioni semantiche possono essere gestite tramite controllo delle versioni e revisione come qualsiasi altro asset di codice. Con l’evolvere dei dati, i modelli semantici restano aggiornati, così l’accuratezza dell’AI non si degrada nel tempo. Il risultato è un minor numero di allucinazioni, una maggiore accuratezza e una logica di business ancorata ai dati reali. Allo stesso modo, è possibile sfruttare l’Universal Semantic Layer di Google Cloud, valorizzando il nuovo supporto di Looker per gli in-database analytics models, che includono la nuova integrazione con BigQuery Graph e Snowflake Semantic Views, portando la potenza dei modelli a grafo agli utenti aziendali nei principali percorsi agentici.

Intelligenza contestuale
Il contesto è la conoscenza circostante che indica a un sistema AI non solo cosa siano i dati, ma anche come interpretarli correttamente. Snowflake Horizon Context crea e applica questo layer contestuale: descrizioni di tabelle e colonne in termini di business, segnali sulla qualità dei dati (freschezza, completezza, avvertenze), pattern di utilizzo (quali tabelle sono autorevoli per quali domande) e relazioni di dominio nel lakehouse. Poiché questo contesto risiede in Horizon, eredita la stessa governance dei dati stessi, così agenti e utenti ricevono sempre e solo il contesto e le risposte che sono autorizzati a visualizzare. Allo stesso modo, Google Cloud Lakehouse fornisce contesto affidabile tramite Knowledge Catalog, offrendo insight basati su Gemini per le tabelle del lakehouse che aiutano a mitigare le allucinazioni negli agenti AI e permettono agli utenti di trasformare gli insight in azioni. Questo contesto si applica a qualsiasi tabella Iceberg, sia essa nativa Snowflake, collegata tramite CLD o federata da Google Cloud. L’AI riceve i dati insieme al contesto necessario per interpretarli correttamente: è questo che distingue una risposta generica di un LLM (“il fatturato potrebbe essere…”) da una risposta fondata sui dati (“il fatturato del Q4 è stato di 47,2 milioni di dollari, tratto dalla tabella autorevole finance.revenue e filtrato secondo la definizione di trimestre fiscale”).

Agentic AI: dai dati all’azione

Grazie al contesto aziendale e alle viste semantiche, gli agenti AI operano su dati strutturati e non strutturati con elevata accuratezza. Snowflake CoWork è un agente di lavoro personale per ogni knowledge worker: ragiona in profondità, automatizza i task di routine e accelera il percorso dalle idee alle decisioni fino all’azione. Anziché attendere istruzioni, CoWork lavora in modo proattivo, facendo emergere insight, eseguendo analisi in background e fornendo risposte governate e tracciabili, fondate sul modo in cui la tua azienda definisce realmente i propri dati.

Snowflake CoCo estende tutto questo al workflow di sviluppo, agendo come coding agent data-native lungo tutto il ciclo di vita dei dati aziendali: sviluppa e gestisce pipeline, crea Cortex Agents e app Streamlit e genera SQL e Python validati sulla base dei metadati effettivi del catalogo. Sia i knowledge worker sia i data engineer beneficiano dello stesso grounding semantico e operano con governance e osservabilità su tutte le azioni, umane e degli agenti AI.

La stessa data foundation federata rende disponibili in modo nativo anche le funzionalità di intelligenza artificiale di Google Cloud. Poiché il lakehouse è in esecuzione su Google Cloud, Gemini è disponibile in modo nativo lungo tutto lo stack. La comprensione multimodale di Gemini (testo, immagini, video e codice in un unico contesto) fa sì che i dati del lakehouse non si limitino alle tabelle strutturate: documenti in GCS, immagini e contenuti non strutturati partecipano tutti al workflow AI. Le sue ampie finestre di contesto acquisiscono contemporaneamente schemi estesi, definizioni di modelli semantici e cronologie delle query, migliorando l’accuratezza nelle domande analitiche complesse.

Gemini Enterprise si connette al lakehouse tramite MCP (attraverso i server MCP di Snowflake o il server MCP di BigQuery) con Lakehouse for Apache Iceberg. I dipendenti che utilizzano Gemini Enterprise pongono domande in linguaggio naturale che ricevono risposte basate su dati governati provenienti da Iceberg Tables, mentre le loro query passano attraverso Cortex Agents e modelli semantici per garantire risposte fondate sui dati. Che l’utente interagisca tramite CoWork, Cortex Code, Gemini Enterprise o un agente REST personalizzato, valgono sempre lo stesso layer semantico, lo stesso contesto e la stessa governance.

Il risultato non è soltanto un open lakehouse, ma un open lakehouse pronto per l’AI, in cui i dati sono interoperabili, governati, semanticamente ricchi e accessibili sia alle persone sia agli agenti AI tramite protocolli standardizzati.

Continua a imparare

• Scopri gli ultimi miglioramenti di prodotto per costruire un lakehouse interoperabile in Snowflake
• Cross-Cloud Lakehouse con Snowflake e Google Cloud
• Scopri di più su Snowflake su Google Cloud

Nota: Apache Iceberg, Apache Polaris e Apache Spark sono marchi registrati della Apache Software Foundation.