Il lakehouse non basta: perché dati operativi e dati analitici vanno trattati in modo diverso

La promessa del lakehouse

Il data lakehouse doveva chiudere il dibattito tra data warehouse e data lake. Un'unica piattaforma, transazioni ACID, schema enforcement e la scalabilità dell'object storage. Apache Iceberg, Delta Lake e Apache Hudi l'hanno resa tecnicamente possibile. Per i carichi analitici funziona.

Il problema è che quasi tutte le data platform aziendali servono due padroni: i consumatori analitici (dashboard, report, training di modelli ML) e quelli operativi (applicazioni, API, motori decisionali in tempo reale). Hanno requisiti profondamente diversi, e fingere che un'unica architettura li serva entrambi è il punto in cui la maggior parte dei progetti lakehouse accumula debito tecnico.

Dove il modello si rompe

I carichi operativi richiedono lookup puntuali sotto il secondo, contratti di schema rigorosi tra chi produce e chi consuma i dati e garanzie transazionali a livello di riga. Un lakehouse basato su file Parquet in object storage può offrire ACID a livello di tabella, ma non può eguagliare le prestazioni delle query puntuali di PostgreSQL né il rispetto dei contratti di schema di un'API ben governata.

L'evoluzione dello schema è un'altra linea di frattura. I consumatori analitici tollerano, anzi si aspettano, la flessibilità dello schema-on-read. Quelli operativi si rompono appena cambia il nome di un campo. Far passare entrambi per lo stesso modello di governance porta o a un'eccessiva rigidità (che uccide l'agilità analitica) o a un'eccessiva flessibilità (che rompe le API in produzione).

L'architettura a due livelli

In produzione separiamo le responsabilità:

• Livello operativo: PostgreSQL o uno store OLTP equivalente, che serve applicazioni e API con contratti di schema rigorosi, transazioni a livello di riga e letture sotto il millisecondo.
• Livello analitico: Apache Iceberg su object storage (MinIO nei deployment on-premise), che serve dashboard, pipeline ML e analisi ad hoc con schema-on-read e funzioni di time travel.
• Meccanismo di sincronizzazione: change data capture (CDC) o export continuo in stile Synapse Link dal livello operativo a quello analitico. Quasi in tempo reale, a consistenza eventuale e disaccoppiato.

Il problema dei dati di training per l'AI

La diffusione dell'AI in azienda introduce un terzo consumatore per cui né il lakehouse né lo store operativo sono stati progettati: le pipeline di training e inferenza ML. I carichi AI hanno bisogno di grandi volumi di dati storici (analitici), ma li vogliono in formati specifici (suddivisi in chunk, trasformati in embedding, deduplicati e versionati) che né i file Parquet né le tabelle PostgreSQL offrono in modo naturale.

I vector database come Weaviate stanno del tutto fuori da entrambi i livelli. Consumano dati dal livello analitico (per gli embedding su scala di corpus) e dal livello operativo (per l'iniezione di contesto in tempo reale nelle pipeline RAG). Trattare il vector store come un terzo livello, con la sua pipeline di ingestione, la sua governance dello schema e le sue garanzie di aggiornamento, è più onesto che fingere che il lakehouse possa coprire questo ruolo.

Nei deployment di Nexus MDS Core realizziamo un'architettura a tre livelli: PostgreSQL per i dati operativi, MinIO con Apache Iceberg per i carichi analitici e Weaviate per lo storage vettoriale dedicato all'AI. Ogni livello ha la sua pipeline CDC, il suo modello di governance e il suo SLA di aggiornamento. La complessità è esplicita invece che nascosta, e una complessità esplicita è una complessità gestibile.

Implicazioni per la governance

La data governance in un'architettura a più livelli è profondamente diversa da quella in un modello a store unico. Ogni livello ha pattern di accesso diversi, profili di sensibilità diversi e requisiti normativi diversi.

Il livello operativo contiene dati personali vivi (cartelle dei pazienti, informazioni sui clienti, dettagli delle transazioni) soggetti ai controlli di accesso del GDPR, alle policy di conservazione e al diritto alla cancellazione. Il livello analitico contiene dati trasformati, spesso aggregati, dove la governance a livello individuale è meno granulare ma il tracciamento della lineage è fondamentale. Il livello AI contiene embedding che possono costituire o meno dati personali ai sensi del GDPR (una questione su cui le autorità non si sono ancora pronunciate in modo definitivo).

Un modello di governance unificato che tratta i tre livelli allo stesso modo sarà o troppo restrittivo per i carichi analitici e AI (e uccide la produttività) o troppo permissivo per i dati operativi (e crea rischio di compliance). L'approccio pragmatico sono policy di governance specifiche per livello, collegate da un data catalogue condiviso che traccia la lineage su tutti e tre i livelli.

Implicazioni pratiche

Non è un rifiuto del pattern lakehouse, è un suo affinamento. Il lakehouse è eccellente per ciò per cui è nato: uno storage analitico unificato con garanzie ACID. Ma usarlo come unica fonte di verità sia per i carichi operativi sia per quelli analitici crea fragilità. Separa i livelli, collegali con il CDC e lascia che ciascuno faccia ciò che sa fare meglio.

Per le organizzazioni che costruiscono capacità AI sopra l'infrastruttura dati esistente, il consiglio pratico è: non cercare di forzare il lakehouse a servire ogni consumatore. Accetta che carichi operativi, analitici e AI abbiano requisiti profondamente diversi. Progetta l'architettura per servirli bene tutti, con contratti sui dati chiari e pipeline CDC tra un livello e l'altro.

Il risultato ha più parti in movimento, ma ciascuna è più semplice, più prevedibile e più facile da governare di un'unica piattaforma spinta oltre i limiti per cui è stata progettata. Nei settori regolati, dove la data governance non è negoziabile, questa separazione esplicita non è over-engineering. È l'architettura minima indispensabile. Per vedere come la realizziamo in pratica, guarda il nostro servizio di data platform moderne o esplora l'architettura di Nexus MDS Core.