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.

Importante

Prima di leggere questa pagina, leggi l'architettura Lakebase per comprendere l'architettura Lakebase e i suoi componenti: computazione Postgres senza stato, safekeeper, page server e cloud object storage. LTAP si basa direttamente su come Lakebase separa il calcolo dallo storage, e il resto di questa pagina assume questa base.

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.

Collegare 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 costruire una pipeline migliore tra due stack, LTAP elimina completamente la necessità di una pipeline. Lo fa ripensando al database dalla memoria verso l'alto.

Lakebase già separa il computo Postgres senza stato da uno strato di storage duraturo composto da safekeeper, pageserver e storage cloud di oggetti. Una transazione si impegna una volta che il quorum dei custodi registra duraturamente il suo registro anticipato, e i pageserver materializzano asincronamente tali modifiche all'archiviazione cloud degli oggetti, così i dati non sono più bloccati all'interno di un unico motore di database.

Note

Per come Lakebase separa calcolo e storage, vedi architettura Lakebase.

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 corrispondono pulitamente a Parquet, come NaN, NUMERIC overflow, o tipi di estensione come vettoriale, array, geografia e JSON, sono preservati in un campo di 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 columnari 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 semplicemente aggiunge il formato columnar a quello stesso flush. Non c'è una pipeline da costruire, né un processo esterno 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.

Note

Un branch Lakebase è un clone copy-on-write dello storage del tuo database: condivide i dati esistenti del padre e memorizza solo ciò che cambia, quindi non duplica dati all'inizio. Il ripristino in un momento utile utilizza lo stesso archiviamento versionato per riportare un database a un momento precedente all'interno della finestra di ripristino. Per saperne di più, consulta Rami del database e ripristino in un momento in tempo.

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 permessi, lineage e audit al calcolo esterno che lo legge.

Note

La governance del Catalogo Unity si applica oggi all'accesso analitico : il calcolo esterno, come Lakehouse//RT e Change Data Feed, che legge i tuoi dati Lakebase registrati. Non governa ancora direttamente le singole tabelle di Postgres. L'accesso tramite il percorso transazionale , cioè applicazioni e client che si collegano a Postgres, è comunque controllato dai privilegi standard di Postgres (GRANT e REVOKE), non dal Catalogo Unity. In pratica, Unity Catalog regola l'accesso analitico e l'accesso a lakehouse, mentre i ruoli e i privilegi di Postgres regolano l'accesso transazionale.

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. Indicizzazione, ramificazione, recupero puntuale, estensioni e letture e scritture puntuali a bassa latenza continuano tutti a funzionare esattamente come 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 visuale transazionalmente coerente, chiede a Postgres solo il numero di sequenza log corrente (LSN), un singolo valore che segna una posizione nel log write-anticip. 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 vivono nel lago come Parquet columnari, leggibili tramite formati di tabelle aperte come Delta e Iceberg, Lakebase (OLTP) e 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 rapide dei punti OLTP, mentre i motori analitici leggono il Parquet a colonna. Lavori comunque con un unico dataset logico , invece di mantenere copie separate di transazioni e analisi 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.
• Serve i dati lakehouse in Lakebase: tabelle sincronizzate, accelerate da 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 una serie di modifiche a livello di riga per pipeline a valle e audit. Neanche il CDC esterno che LTAP rimuove: entrambi operano sulla singola 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.

Capability	Condizione	Description
Registra Lakebase nel Catalogo Unity	GA	Regolare l'accesso analitico ai dati di Lakebase ed eseguire query cross-source dalla casa del lago.
Gestire i dati con tabelle sincronizzate	GA	Serve i dati della tabella Unity Catalog in Lakebase per letture OLTP a bassa latenza. La modalità snapshot e le sincronizzazioni full-refresh possono utilizzare LTAP Direct Writes (Beta) per caricare direttamente nello storage in parallelo con Spark.
Lakehouse//RT interroga Lakebase	Versione Beta	Esegui query OLAP transazionalmente coerenti sui dati Postgres in tempo reale, senza compromettere le prestazioni OLTP di Lakebase.
Feed di dati delle modifiche di Lakebase	Public Preview	Memorizza le modifiche a livello di riga dalle tabelle Postgres di Lakebase come tabelle Delta del Catalogo Unity per pipeline downstream e audit.

Come approcciare l'implementazione

Ora che conosci le capacità, la domanda è quali di cui hai bisogno al 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 prodotti o mantenuti nel lakehouse, e vuoi letture OLTP a bassa latenza 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.

Mappare ogni dataset in una di queste direzioni, registra il database nel Catalogo Unity per la governance, poi segue la documentazione delle capacità per implementare ogni percorso. Una singola applicazione spesso utilizza entrambe le direzioni: inviando dati di riferimento dalla casa del lago a Postgres, esponendo le proprie scritture transazionali all'analisi. 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 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 dati di cambiamento Lakebase: Modifiche a livello di riga al lago per oleodotte 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