Le architetture dati aziendali sono ormai distribuite per scelta: database relazionali per il transazionale, warehouse per l’analytics, object store per il non strutturato, SaaS per funzioni specifiche. Il problema oggi non è consolidare ma rendere interoperabili questi sistemi, perché gli agenti AI — a differenza dei tool di analytics tradizionali — richiedono accesso unificato, governato e in tempo reale a tutti i dati rilevanti, ovunque risiedano.
Questo primo articolo della serie AWS propone un approccio catalog-first: se i data product hanno già un metadata catalog ben definito, si unifica il catalogo e si costruisce sopra un context layer da cui gli agenti scoprono tutto il contesto. Le fonti prive di catalogo vengono esposte tramite MCP server collegati direttamente al context layer. Per chi lavora con data stack, il valore sta nelle scelte architetturali motivate, non in un semplice annuncio.
Federazione o ingestion: il trade-off centrale
L’architettura si appoggia ad Apache Iceberg come open table format e a Lake Formation per la governance fine-grained. AWS distingue tre modalità di accesso: catalog federation (Iceberg REST, per Databricks, Snowflake e cataloghi Iceberg-compatibili), query federation (per fonti non-Iceberg come BigQuery o SQL Server, senza replica) e ingestion (Zero-ETL, Glue, EMR) quando servono bassa latenza, time travel e ottimizzazione delle performance. La federazione offre freschezza in tempo reale ma costi per query e latenza più variabili; l’ingestion ha costo iniziale più alto ma query più economiche e piena portabilità.
Le insidie di produzione
La parte più utile riguarda i problemi reali. Il metadata drift (catalogo federato disallineato rispetto allo schema sorgente) va contrastato con refresh schedulati e validazione dello schema prima della query. La latenza della query federation è non deterministica: servono timeout espliciti e caching dei risultati. AWS segnala anche il limite di 5 minuti di AgentCore Gateway, per cui i job di data processing vanno su AgentCore Runtime. Infine, tre zone di rischio hallucination (generazione SQL, sintesi cross-source, memoria) da mitigare con un framework di validazione: verifica della fonte, controllo di ragionevolezza e cross-validation eseguendo la stessa query in Athena.
- Iceberg + Lake Formation danno interoperabilità e governance unica su fonti AWS e non-AWS, senza migrazioni forzate.
- La scelta tra federazione e ingestion è per caso d’uso: freschezza contro costo, latenza e AI-readiness.
- In produzione contano le guardrail: metadata drift, timeout, loop dei tool call e validazione anti-hallucination.
Fonte: Multi-cloud lakehouse architecture on AWS for Agentic AI, Part 1 — https://aws.amazon.com/blogs/big-data/multi-cloud-lakehouse-architecture-on-aws-for-agentic-ai-part-1-architecture-and-best-practices/
Hai qualcosa da aggiungere? Unisciti alla discussione.