La regola dei database vecchia di 40 anni che gli agenti hanno appena infranto: come LTAP unifica i carichi di lavoro OLTP e OLAP

Jonathan Katz ha trascorso la sua carriera su entrambi i lati di un confine con cui la maggior parte del settore dei dati ha semplicemente imparato a convivere. Come collaboratore di lunga data di Postgres e ora Senior Staff Product Manager presso Databricks, ha visto i sistemi operativi e analitici funzionare come due mondi separati, uniti solo da pipeline, copie e compromessi.

In questa conversazione, Jonathan spiega perché tale separazione esisteva innanzitutto, perché gli agenti AI sono l'elemento che sta finalmente abbattendo questa barriera e come LTAP colma il divario ripensando il punto di incontro tra i due mondi: non in un singolo motore, ma in un livello di archiviazione unificato.

L'assunto che gli agenti AI hanno infranto

Per decenni il settore ha convissuto con una netta separazione tra sistemi di database operativi e analitici. Perché l'ascesa degli agenti AI autonomi sta scardinando questo modello?

Jonathan Katz: Esistono due mondi di dati. I dati operativi sono quelli con cui si interagisce quando si elabora una transazione con carta di credito o si cercano frodi: query molto brevi e veloci, che analizzano i dati riga per riga. I dati analitici sono quelli accumulati per settimane, mesi o anni e, quando vengono interrogati, l'analisi copre l'intero dataset. Entrambi cercano di restituire una risposta il più rapidamente possibile, ma lo fanno in modi completamente diversi.

Questa differenza non è arbitraria. È una questione di fisica. Se i dati vengono memorizzati in righe, è così che si ottiene una singola risposta rapida nel minor tempo possibile. Se vengono memorizzati in colonne, è così che si esegue la scansione e l'aggregazione di tutti i dati il più velocemente possibile. Inoltre, per progettazione, una query analitica può consumare l'intera gamma di risorse di un sistema massivamente parallelizzato per ottenere una risposta su un dataset molto ampio, mentre una query operativa è progettata per consumare meno risorse possibili pur restituendo rapidamente una risposta. Ciò porta a due modi molto diversi di concepire la progettazione e la gestione del sistema di dati e richiede tipi diversi di ottimizzazione.

Postgres, uno dei database più diffusi al mondo, è strutturato intorno alle righe perché è ottimizzato per i carichi di lavoro operativi. I motori analitici sono strutturati intorno alle colonne per il motivo opposto. A causa di questa fondamentale differenza fisica, i due sistemi sono sempre dovuti rimanere separati e, ogni volta che si volevano analizzare i dati operativi, era necessario trasferirli altrove.

L'ascesa degli agenti AI ha cambiato ciò di cui abbiamo bisogno dai database. È in parte il motivo per cui esiste l'architettura di Lakebase: database creati per tenere il passo con il modo in cui gli agenti lavorano effettivamente. Ad esempio, agli agenti viene affidato il compito di cercare frodi o anomalie, ed eventi di questo tipo si verificano in centinaia di millisecondi. Ma allo stesso tempo, quel sistema gestisce anche un enorme volume di scritture e letture brevi. Un singolo agente potrebbe essere abbastanza intelligente da sapere quale query deve eseguire. Un gruppo di agenti può facilmente sovraccaricare un sistema operativo se non sono previsti meccanismi di controllo.

Cos'è in realtà LTAP

Cos'è LTAP e come funziona effettivamente dietro le quinte?

Jonathan Katz: LTAP, ovvero Lake Transactional/Analytical Processing, consente di eseguire query analitiche direttamente sui dati operativi in tempo reale senza spostarli e senza sovraccaricare il sistema che gestisce le transazioni. Questo avviene unificando i dati transazionali e analitici in un unico livello di archiviazione logico, anziché forzarli attraverso sistemi separati collegati da una pipeline.

Dietro le quinte, LTAP è possibile solo grazie a come è strutturato lo stesso Lakebase: elaborazione stateless ed effimera completamente disaccoppiata dall'archiviazione nel lake. Questa separazione, ereditata da Neon, significa che il livello di archiviazione durevole può gestire scritture ad alta velocità e scaricarle periodicamente nell'object storage per la persistenza, indipendentemente dall'elaborazione in esecuzione in un dato momento. Poiché i dati erano già ottimizzati per l'archiviazione cloud, perché non rappresentarli nello stesso formato colonnare già utilizzato dal Lakehouse, in modo che motori come Apache Spark e SQL possano leggerli direttamente e ottenere letture analitiche ad alte prestazioni senza una seconda copia?

La parte più difficile è stata assicurarsi che nulla andasse perso durante il processo. Postgres ha i propri tipi di dati e codifiche, e i formati aperti come Iceberg e Delta hanno i loro. Abbiamo dovuto scrivere i dati in modo da preservare l'esatta rappresentazione fisica dei dati Postgres originali, senza modificare un singolo bit, e inserirli in un file Parquet. Questo è l'elemento che ci ha permesso di fondere in un'unica soluzione le rappresentazioni operative e analitiche degli stessi dati. In pratica, il livello di archiviazione funziona su due livelli: un livello "hot" (più rapido) che conserva i dati in formato riga per un accesso operativo veloce, e un livello "cold" (più freddo) che li conserva in formato colonnare per le letture analitiche, in modo che ciascuna parte possa ottenere ciò di cui ha bisogno in modo efficiente.

Perché LTAP ha successo dove HTAP si è bloccato

L'HTAP ha cercato di risolvere l'analisi in tempo reale anni fa, ma si è bloccato. Perché l'approccio a livello di archiviazione del lakehouse ha successo dove l'HTAP tradizionale ha fallito?

Jonathan Katz: È possibile far funzionare i sistemi HTAP, ma sono costosi. Sono complessi, difficili da gestire e generalmente non aperti. La novità del modello LTAP è che l'elaborazione operativa serverless e l'elaborazione analitica serverless sono due cose separate. È possibile calibrare esattamente la quantità di elaborazione da utilizzare per ciascun carico di lavoro in modo indipendente, anziché pagare per un unico sistema che cerca di svolgere entrambi i compiti contemporaneamente. L'archiviazione è la parte economica di qualsiasi sistema di dati. L'elaborazione è la parte costosa.

Questo è il motivo principale a favore dell'unificazione del livello di archiviazione anziché del motore: consente di mantenere il motore specializzato ed efficiente per ogni attività e di pagare per l'elaborazione solo dove è effettivamente necessario, invece di gestire un unico sistema costoso che cerca di fare tutto bene contemporaneamente.

Cosa non funziona quando gli agenti agiscono su dati non aggiornati

Ci descrive un flusso di lavoro specifico basato su agenti che oggi si interrompe o subisce un peggioramento delle prestazioni perché legge e agisce su dati non aggiornati? Cosa va storto esattamente?

Jonathan Katz: Il rilevamento delle frodi è l'esempio più chiaro. Le transazioni con carta di credito vengono autorizzate in poche centinaia di millisecondi o meno. Se l'agente responsabile dell'individuazione delle frodi lavora su una copia batch dei dati vecchia di minuti o ore, è semplicemente troppo lento per intercettare qualcosa prima che la transazione sia già stata completata. Di conseguenza, è preferibile che l'agente lavori direttamente sul sistema operativo.

Tuttavia, il sistema operativo gestisce un flusso costante di scritture e letture brevi e non è stato progettato per assorbire anche pesanti query analitiche. Se l'agente esegue una query che analizza l'intera cronologia degli acquisti di un cliente per verificare la presenza di anomalie, si tratta di una query onerosa da eseguire su un sistema ottimizzato per il tipo di carico di lavoro opposto. Ciò può compromettere le prestazioni di tutte le altre transazioni che cercano di essere autorizzate nello stesso momento. Inoltre, un'architettura moderna ha solitamente bisogno dei dati sia della parte operativa che di quella analitica per prendere una buona decisione, quindi l'agente deve attingere da entrambe. Un singolo agente potrebbe gestire la situazione in modo responsabile. Una flotta di agenti che eseguono query simili contemporaneamente può sovraccaricare rapidamente il sistema operativo se non c'è nulla che regoli il carico che possono esercitare su di esso.

Governance, apertura e il caso d'uso aziendale

In che modo Databricks implementa specificamente LTAP oggi e come lo descriverebbe a chi già comprende i limiti di HTAP?

Jonathan Katz: Oltre ai meccanismi di archiviazione, l'altro elemento fondamentale è il catalogo. Una delle vere innovazioni del Lakehouse è stata quella di offrire alle organizzazioni una vista centralizzata e unificata di tutti i loro dati: chi ha accesso a cosa, policy coerenti su tutto, in modo che nessuno possa leggere informazioni sensibili come un codice fiscale a meno che non faccia parte di un gruppo privilegiato. Questo non si applicava ai sistemi operativi, perché questi ultimi sono stati concepiti fin dall'inizio come silos di dati. In passato, la relazione tra dati operativi e analitici era la seguente: si creava una pipeline, si trasferivano i dati e poi... buona fortuna. Nessuno era responsabile di ciò che accadeva a valle. LTAP ribalta questa situazione. Tutti i dati sono riuniti in un unico modello di archiviazione unificato, sotto un unico catalogo. Non ci si deve più preoccupare che i dati operativi escano dai confini della governance solo perché qualcuno ha avuto bisogno di analizzarli.

C'è anche un motivo per cui questo sistema deve essere basato su fondamenta aperte. Postgres si sta avvicinando a essere il terzo database più apprezzato nelle classifiche di DB-Engines. Questo non è necessariamente un indicatore di adozione, ma è un forte segnale della direzione in cui stanno andando le cose e dimostra il valore della flessibilità e della scelta. L'open source alimenta alcuni dei sistemi più importanti al mondo da decenni. LTAP estende questo stesso principio. Anche all'interno di Postgres, i dati sono portabili tra sistemi Postgres, ma si rimane comunque vincolati a Postgres. Con il livello di archiviazione unificato di LTAP, non è più necessario spostare i dati per associarvi il motore corretto. Si porta il motore direttamente ai dati.

La svolta fondamentale: l'archiviazione unificata

Se dovesse descrivere in una sola frase la svolta fondamentale rappresentata da LTAP, in qualunque modo volesse formularla, come la definirebbe?

Jonathan Katz: La versione estremamente semplificata è lo storage unificato. Dillo a chi si occupa di analytics e lo capirà quasi immediatamente. Dillo a chi si occupa della parte operativa e potrebbe chiederti cosa intendi. Ma una volta che riesci a unire le rappresentazioni operative e analitiche degli stessi dati senza spostare nulla, senza che nessun bit cambi, si risolve all'istante una serie di problemi che prima sembravano inevitabili. Non ho più bisogno di eseguire pipeline solo per portare i dati in un layer bronze o silver. Posso iniziare ad analizzarli nel momento stesso in cui vengono scritti. La vedrei anche al contrario: non si tratta tanto di inventare qualcosa di nuovo, quanto di riunire due mondi che non avrebbero mai dovuto essere separati. I dati sono semplicemente dati. Più riusciamo a trattarli in questo modo, più diventa facile per le persone, e ora per gli agenti, lavorarci senza che tutti debbano prima negoziare attraverso una pipeline.

Riunire i due mondi

Per quarant'anni, il confine tra dati operativi e analitici ha retto perché la fisica dello storage lo richiedeva. Gli agenti sono il primo workload che non può tollerare il ritardo creato da quel confine. LTAP non cerca di cancellare la differenza tra una transazione e una query analitica. Elimina il sovraccarico che un tempo derivava dall'eseguire entrambe sullo stesso dato. Per un Data Architect che si trova a valutare se un workload agentico abbia effettivamente bisogno di questo pattern, il test descritto da Jonathan è molto utile: se la prossima decisione di un agente dipende da dati che si stanno ancora stabilizzando, su un sistema progettato per mantenere quei dati vicini e protetti, il vecchio modello pipeline-e-copia non sarà abbastanza veloce. Questo è il problema specifico che LTAP è stato creato per risolvere.

Per saperne di più su LTAP, leggi Dal monolite a Lakebase a LTAP: ripensare il database a partire dallo storage.

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