Architettura LTAP

Lake Transactional/Analytical Processing (LTAP) è un'architettura dati che serve sia carichi di lavoro transazionali (OLTP) che analitici (OLAP) da uno strato unificato di archiviazione dati nel lago, sotto un unico modello di governance, così da non dover mantenere sistemi transazionali e analitici separati sincronizzati. Rimuove le pipeline di acquisizione dei dati di cambiamento (CDC), replica e trasformazione che i team tradizionalmente mantengono per copiare i dati operativi in un sistema analitico separato. Azure Databricks costruisce LTAP sull'architettura di archiviazione Lakebase. Per l'annuncio, vedi Databricks launches LTAP: la prima architettura di elaborazione transazionale/analitica di Lake.

LTAP è un'architettura, non una singola caratteristica. Azure Databricks lo esegue tramite un insieme di funzionalità Lakebase che sono attivamente sviluppate ed espanse. Le funzionalità a tua disposizione dipendono dal tuo cloud. Questa pagina spiega l'architettura. Per le funzionalità che puoi utilizzare oggi sul tuo cloud, consulta Funzionalità che implementano LTAP.

Il costo di mantenere due stack sincronizzati

Le applicazioni suddividono il lavoro sui dati in due tipi di carichi di lavoro. I carichi di lavoro transazionali (OLTP) agiscono su poche righe alla volta e necessitano rapidamente di completare il contenuto completo di tali righe, come l'elaborazione di un pagamento o la restituzione di un risultato API. I carichi di lavoro analitici (OLAP) cercano insight su grandi dataset, spesso aggregando e unendo molte righe, come la previsione delle vendite o la rilevazione di frodi. Questi pattern tirano in direzioni opposte: OLTP necessita di letture e scritture costanti a bassa latenza su singole righe, mentre OLAP deve scansionare e aggregare su grandi volumi di dati. Per decenni, la risposta è stata due sistemi separati: un database transazionale per l'applicazione e un data warehouse o un lakehouse per l'analisi.

Fare da ponte tra quei due stack è la parte più costosa. Mantenerli sincronizzati significa eseguire la rilevazione dei dati di cambiamento (CDC), pipeline di streaming e repliche di lettura il cui unico compito è copiare dati da un sistema all'altro. Quell'infrastruttura è fragile, aggiunge latenza tra la scrittura dei dati e la loro analisi, e compete per le risorse con il database transazionale primario. Poiché applicazioni e agenti AI hanno sempre più bisogno di analisi sui dati transazionali più recenti, questo divario rallenta i team. Copiare dati tra due sistemi crea anche un rischio di governance: la linea di discendenza può interrompersi con il movimento dei dati, rendendo più difficile soddisfare obblighi come le richieste di rimozione GDPR.

Come unifica i dati LTAP al livello di archiviazione

Invece di creare una pipeline migliore tra due stack, LTAP elimina del tutto la necessità di una pipeline. Lo fa ripensando il database a partire dall'archiviazione.

Lakebase separa già il componente di calcolo Postgres stateless da un livello di archiviazione durevole composto da safekeepers, pageserver e object storage nel cloud. Una transazione viene confermata una volta che un quorum di safekeeper registra in modo duraturo il proprio write-ahead log, e i pageserver materializzano poi asincronamente tali modifiche nell’object storage cloud, così i dati non restano più confinati all’interno di un singolo motore di database.

LTAP aggiunge un passaggio a quel livello di archiviazione. Man mano che lo storage Lakebase materializza i dati in oggetti di archiviazione, essa transcodifica i dati Postgres orientati a righe nella disposizione colonnare di Parquet mentre i dati atterrano nel lago, dove sono leggibili tramite formati di tabelle aperte come Delta e Iceberg. Questa transcodifica permette a una singola copia dei dati di servire sia carichi di lavoro OLTP che OLAP. È progettato in modo che la copia colonnastica rimanga una rappresentazione fedele ed efficiente dell'originale di Postgres:

• La semantica viene preservata. Lo storage Lakebase transcodifica ogni valore nella sua forma colonnale mantenendo la rappresentazione originale di Postgres, così che qualsiasi motore compatibile con Postgres possa reinterpretare i dati senza perdere informazioni. I tipi che non si mappano in modo pulito su Parquet, come NaN, NUMERIC overflow o i tipi di estensione come vector, array, geography e JSON, vengono conservati in un campo overflow che contiene la rappresentazione canonica di Postgres.
• Le versioni a fila sono conservate. La transcodifica mantiene le versioni intermedie delle righe, quindi la copia colonnare contiene le stesse informazioni di versione dei dati riga.
• I dati in formato colonnare si comprimono bene. La disposizione a colonne è fortemente compressa, il che riduce l'ingombro di memoria e la quantità di dati spostati da e verso l'archiviazione degli oggetti.

La transcodifica gira interamente nel livello di storage, isolata dall'istanza primaria di Postgres, quindi non influisce sul tuo carico di lavoro di servizio transazionale. Si basa su qualcosa che Lakebase già fa: scaricare dati compromettiti verso uno storage cloud di oggetti. LTAP aggiunge semplicemente il formato colonnare allo stesso flush. Non c'è alcuna pipeline da costruire, né alcun processo esterno da eseguire che interroghi il tuo database.

Non tutto è transcodificato. Gli indici Postgres rimangono nella loro rappresentazione originale nel livello di storage durevole, invece di essere convertiti in colonne, quindi le letture e le ricerche dei punti transazionali restano veloci mentre la copia columnare serve le analisi.

Poiché i dati vivono in archiviazione esternalizzata e versionata, creare un branch o ripristinare a un certo punto temporale è un'operazione di metadati piuttosto che una copia fisica. Puoi ramificare un grande database di produzione in pochi secondi, eseguire un esperimento o una migrazione rischiosa contro il branch e scartarlo, senza duplicare i dati sottostanti.

Questo approccio a livello di archiviazione è ciò che distingue LTAP dalla change data capture (CDC). CDC replica i dati dal tuo storage OLTP in un livello di analisi separato utilizzando un processo esterno che interroga continuamente il database principale e una pipeline che trasforma i cambiamenti di riga in dati colonnari. Quella pipeline consuma risorse sul tuo database transazionale principale, ti fa gestire tu stesso le modifiche di schema e i casi limite, e scambia la freschezza dei dati con il costo della pipeline, il tutto aggiungendo punti di guasto. LTAP adotta invece un approccio a livello di storage: lo storage Lakebase trascodifica i dati nel lago come parte del normale funzionamento dello storage, senza alcun processo esterno che competa con il tuo carico di lavoro e senza pipeline da costruire o mantenere.

I tre pilastri di LTAP

Unificare i dati a livello di storage conferisce a LTAP tre proprietà distintive.

• Governo universale. Unity Catalog regola l'accesso analitico a una copia logica dei tuoi dati su entrambi i carichi di lavoro.
• Motori appositamente progettati. Postgres si occupa delle transazioni e il Lakehouse di analytics, e nessuno dei due compromette l'altro.
• Una singola copia logica in archiviazione aperta. Entrambi i motori leggono una copia dei tuoi dati in formati aperti, senza repliche o pipeline da mantenere sincronizzate.

Governo universale

Unity Catalog regola l'accesso analitico ai tuoi dati su entrambi i carichi di lavoro. Dopo aver registrato un database Lakebase, Unity Catalog applica autorizzazioni, lineage e audit alle risorse di calcolo esterne che lo leggono.

Motori appositamente costruiti

Postgres serve il tuo carico di lavoro transazionale e il Lakehouse serve l'analisi, ognuno con i punti di forza per cui è stato creato. Un errore comune è che unificare i due faccia sì che i dati operativi diventino dati freddi rimasti in un iceberg. Non è così. Lakebase rimane lo standard Postgres. L'indicizzazione, la creazione di rami, il ripristino a un punto nel tempo, le estensioni e le letture e scritture puntuali a bassa latenza continuano a funzionare esattamente come avviene oggi.

Le letture analitiche non competono con il tuo carico di lavoro transazionale perché sono isolate dall'istanza primaria di Postgres. Quando un motore analitico come Lakehouse//RT interroga dati Lakebase in tempo reale, restituisce un risultato fresco e transazionalmente coerente senza copiare i dati:

• Il motore legge la maggior parte dei dati dalla copia a colonne nell'object storage, non da Postgres.
• Per ottenere una vista transazionalmente consistente, richiede a Postgres solo il numero di sequenza del log corrente (LSN), un singolo valore che indica una posizione nel log di pre-scrittura. Questa è una ricerca economica sui metadati.
• Per il piccolo insieme di cambiamenti molto recenti che non si sono ancora materializzati nel lago, li legge dal pageserver e li fusiona sopra.

Postgres non fornisce alcun traffico di lettura analitico oltre a restituire quel singolo LSN, e la transcodifica viene eseguita nel livello di storage, non sull'istanza Postgres che serve la tua applicazione. Il tuo carico di lavoro operativo continua a funzionare come previsto.

Una singola copia logica in archiviazione aperta

Poiché i dati risiedono nel data lake in formato Parquet colonnare, leggibile tramite formati di tabella aperti come Delta e Iceberg, Lakebase (OLTP) e il Lakehouse (OLAP) condividono la stessa base di archiviazione. Si mantiene una copia logica dei dati su entrambi i carichi di lavoro, invece di riconciliare un database transazionale con una copia analitica separata.

Ogni motore può memorizzare in cache o rappresentare quei dati in un formato fisico diverso per le prestazioni. Lakebase utilizza le pagine Postgres per letture puntuali OLTP rapide, mentre i motori analitici leggono il Parquet in formato colonnare. Continui a lavorare con un unico dataset logico, invece di mantenere copie transazionali e analitiche separate e tenerle sincronizzate.

Ogni tavolo ha un singolo scrittore, sia Lakebase che la casa del lago. Entrambi i motori leggono quella copia logica, quindi gli stessi dati sono disponibili per le tue applicazioni e per l'analytics senza una seconda copia.

Devi cambiare il modo in cui usi Lakebase

No. Adottare funzionalità LTAP non richiede una migrazione dei dati o un cambiamento nel modo in cui le tue applicazioni si connettono a Lakebase. Lakebase rimane lo standard Postgres: le tue estensioni, indici, query e codice applicativo esistenti continuano a funzionare invariati. Ciascuna delle funzionalità LTAP è indipendente, quindi puoi adottarne qualsiasi quando un carico di lavoro ne ha bisogno.

Capacità che implementano LTAP

Si mette in pratica l'architettura LTAP attraverso un insieme di funzionalità di Lakebase. Ognuno si basa sulla base di storage condiviso descritta sopra e insieme copre i percorsi che i dati percorrono tramite LTAP:

• Governa e registra: porta i dati di Lakebase sotto Unity Catalog.
• Distribuisci i dati del lakehouse in Lakebase: tabelle sincronizzate, accelerate dalle scritture dirette LTAP.
• Consulta dati Lakebase in tempo reale: Lakehouse//RT per l'analisi, Lakebase Change Data Feed per i flussi di cambiamento.

Il diagramma seguente mostra come queste capacità scrivono e leggono da una copia dei tuoi dati, regolata da Unity Catalog.

Lakehouse//RT e Lakebase Change Data Feed leggono entrambi gli stessi dati sottostanti ma li rappresentano in modo diverso. Lakehouse//RT legge lo stato attuale dei dati Postgres in tempo reale per l'analisi. Change Data Feed fornisce un flusso di modifiche a livello di riga per pipeline downstream e attività di audit. Né lo è il CDC esterno che LTAP elimina: entrambi operano su un'unica copia dei dati.

La tabella seguente elenca ogni capacità LTAP e cosa fa, insieme allo stato di rilascio sul tuo cloud. La disponibilità varia a seconda del cloud, quindi una funzionalità non offerta sul tuo cloud viene contrassegnata come non disponibile.

Come approcciare l'implementazione

Ora che conosci le funzionalità, la domanda è di quali ha bisogno il tuo carico di lavoro. Implementi LTAP combinando le funzionalità che corrispondono al flusso dei dati nella tua architettura.

La decisione chiave è la direzione: per ogni dataset, quale sistema possiede la scrittura? Ogni tabella ha un singolo scrittore, e questo determina quali funzionalità utilizzi.

• Lakebase si occupa della scrittura. La tua applicazione scrive su Postgres, e vuoi che quei dati operativi siano disponibili per l'analisi senza doverli copiare. Ad esempio, un'applicazione di vendita scrive ordini e pagamenti a Lakebase man mano che avvengono. Usa Lakehouse//RT per gestire una dashboard di ricavi in tempo reale su quegli ordini, oppure Lakebase Change Data Feed per trasmettere ogni modifica d'ordine in una pipeline a valle o in un registro di audit.
• La casa sul lago possiede la scrittura. I tuoi dati vengono generati o gestiti nel lakehouse e vuoi eseguire letture OLTP a bassa latenza di tali dati dalla tua applicazione. Ad esempio, un lavoro serale a una casa sul lago elabora raccomandazioni di prodotti o una tabella di prezzi. Usa tabelle sincronizzate per inserire quei dati in Lakebase così la tua applicazione può leggerli con bassa latenza, e abilita le scritture dirette LTAP per accelerare il carico iniziale di una tabella grande.

Mappate ogni set di dati a uno di questi percorsi, registrate il database in Unity Catalog ai fini della governance, quindi seguite la documentazione relativa alle funzionalità per implementare ciascun percorso. Una singola applicazione utilizza spesso entrambe le direzioni: fornendo dati di riferimento dal lakehouse a Postgres, mentre espone a fini analitici le proprie scritture transazionali. La disponibilità varia a seconda del cloud, quindi controlla la tabella delle capacità sopra per confermare cosa è offerto sul tuo cloud.

Passaggi successivi

• Architettura Lakebase: Capisci come Lakebase separa il calcolo senza stato dallo storage durabile. Vedi l'architettura Lakebase.
• Registra un database nel Catalogo Unity: Governa i dati di Lakebase e consultali dalla casa del lago. Vedi Registrare un database Lakebase in Unity Catalog.
• Serve i dati con tabelle sincronizzate: sincronizza i dati delle tabelle Unity Catalog in Lakebase per letture a bassa latenza e accelera carichi grandi con LTAP Direct Writes. Vedere Servire i dati lakehouse con tabelle sincronizzate.

• Flusso delle modifiche ai dati di Lakebase: Trasmetti le modifiche a livello di riga al lakehouse per pipeline e audit. Vedere Feed di dati delle modifiche di Lakebase.

Ulteriori informazioni

• Annuncio: Databricks lancia LTAP: la prima architettura di elaborazione transazionale/analitica di Lake
• Blog di ingegneria: Da monolite a Lakebase fino a LTAP: ripensare il database dall'archiviazione verso l'alto
• Demo: LTAP: La prima architettura di elaborazione transazionale/analitica di Lake