LTAP-arkitektur

Lake Transactional/Analytical Processing (LTAP) är en dataarkitektur som hanterar både transaktionella (OLTP) och analytiska (OLAP) arbetsbelastningar från ett enhetligt datalagringslager i sjön, under en och samma styrningsmodell, så att du inte behöver hålla separata transaktionella och analytiska system synkroniserade. Det tar bort de förändringsdatainfångningar (CDC), replikerings- och transformationspipelines som team traditionellt underhåller för att kopiera operativ data till ett separat analytiskt system. Azure Databricks bygger LTAP på Lakebase-lagringsarkitekturen. För tillkännagivandet, se Databricks lanserar LTAP: den första Lake Transactional/Analytical Processing-arkitekturen.

LTAP är en arkitektur, inte en enskild funktion. Azure Databricks levererar det genom en uppsättning Lakebase-funktioner som aktivt utvecklas och utökas. De möjligheter som finns tillgängliga för dig beror på ditt moln. Den här sidan förklarar arkitekturen. För de funktioner du kan använda idag i ditt moln, se Kapabiliteter som implementerar LTAP.

Kostnaden för att hålla två stackar synkroniserade

Applikationer delar upp sitt dataarbete i två typer av arbetsbelastning. Transaktionella (OLTP) arbetsbelastningar agerar på några rader åt gången och behöver snabbt hela innehållet i dessa rader, såsom att hantera en betalning eller returnera ett API-resultat. Analytiska (OLAP) arbetsbelastningar söker insikter över stora datamängder, ofta genom att aggregera och sammanfoga många rader, såsom att prognostisera försäljning eller upptäcka bedrägerier. Dessa mönster drar i motsatta riktningar: OLTP kräver konstanta läsningar och skrivningar med låg latens på enskilda rader, medan OLAP behöver skanna och aggregera över stora datamängder. I årtionden var svaret två separata system: en transaktionsdatabas för applikationen och ett datalager eller lakehouse för analys.

Att överbrygga de två stackarna är den dyra delen. Att hålla dem synkroniserade innebär att köra ändringsdatainsamling (CDC), strömmande datapipelines och läsrepliker vars enda uppgift är att kopiera data från ett system till ett annat. Den infrastrukturen är skör, den lägger till latens mellan när data skrivs och när den kan analyseras, och den konkurrerar om resurser med den primära transaktionsdatabasen. Eftersom applikationer och AI-agenter i allt högre grad behöver analys av den färskaste transaktionsdatan, saktar detta gap ner teamen. Att kopiera data mellan två system skapar också styrningsrisk: härstamning kan brytas när data flyttas, vilket gör skyldigheter som GDPR-borttagningsförfrågningar svårare att uppfylla.

Hur LTAP förenar data på lagringslagret

Istället för att bygga en bättre pipeline mellan två stackar, eliminerar LTAP behovet av en pipeline helt. Det gör den genom att tänka om databasen från lagring och uppåt.

Lakebase separerar redan tillståndslös Postgres-beräkning från ett hållbart lagringslager av safekeepers, sidservrar och molnobjektlagring. En transaktion bekräftas när ett kvorum av safekeepers varaktigt lagrar sin write-ahead-logg, och sidservrarna materialiserar sedan asynkront dessa ändringar i molnets objektlagring, så att data inte längre är inlåsta i en enda databasmotor.

LTAP lägger till ett steg till det lagringslagret. När Lakebase-lagringen materialiserar data i objektlagret omkodar den radorienterade Postgres-data till Parquets kolumnbaserade format när data skrivs till datasjön, där de kan läsas via öppna tabellformat som Delta och Iceberg. Denna transkodning är det som gör att en enda kopia av data kan hantera både OLTP- och OLAP-arbetsbelastningar. Den är utformad så att kolumnkopian förblir en trogen och effektiv återgivning av Postgres-originalet:

• Semantiken bevaras. Lakebase-lagring transkodar varje värde till dess kolumnform samtidigt som den ursprungliga Postgres-representationen behålls, så att vilken Postgres-kompatibel motor som helst kan tolka om datan utan att förlora information. Typer som inte kan mappas direkt till Parquet, till exempel NaN, NUMERIC-spill eller tilläggstyper som vektor, matris, geografi och JSON, lagras i ett spillfält som innehåller den kanoniska representationen i Postgres.
• Versioner av rader bevaras. Transkodningen behåller mellanliggande radversioner, så kolumnkopian bär samma versionsinformation som raddatan.
• Kolumnbaserade data komprimeras väl. Den kolumnformade layouten är starkt komprimerad, vilket minskar lagringsutrymmet och mängden data som flyttas till och från objektlagring.

Transkodning körs helt i lagringslagret, isolerat från den primära Postgres-instansen, så det påverkar inte din transaktionella serveringsarbetsbelastning. Det bygger vidare på något som Lakebase redan gör: att skriva ut bekräftade data till molnbaserad objektlagring. LTAP lägger helt enkelt till kolumnformatet i samma flush. Det finns ingen pipeline för dig att bygga, och ingen extern process som pollar din databas.

Allt är inte transkodat. Postgres-index behåller sin ursprungliga representation i det beständiga lagringslagret i stället för att konverteras till kolumner, så att transaktionella punktläsningar och uppslagningar förblir snabba medan den kolumnorienterade kopian används för analys.

Eftersom datan finns i externaliserad, versionsbaserad lagring är skapandet av en gren eller återställning till en tidpunkt en metadataoperation snarare än en fysisk kopia. Du kan grena en stor produktionsdatabas på några sekunder, köra ett experiment eller en riskfylld migrering mot grenen och kassera den, utan att duplicera den underliggande datan.

Detta lagringsnivå-tillvägagångssätt är det som skiljer LTAP från change data capture (CDC). CDC replikerar data från din OLTP-lagring till ett separat analyslager med hjälp av en extern process som kontinuerligt pollar primärdatabasen och en pipeline som omvandlar radändringar till kolumndata. Den här pipelinen förbrukar resurser i din primära transaktionsdatabas, tvingar dig att själv hantera schemaändringar och specialfall, och tvingar dig att balansera datans aktualitet mot kostnaden för pipelinen, samtidigt som den introducerar fler felkällor. LTAP använder istället en lagringsnivå-metod: Lakebase-lagring transkodar data till laken som en del av normal lagringsdrift, utan någon extern process som konkurrerar med din arbetsbelastning och utan någon pipeline för dig att bygga eller underhålla.

LTAP:s tre pelare

Att ena data i lagringslagret ger LTAP tre utmärkande egenskaper.

• Övergripande styrning Unity Catalog styr analytisk åtkomst till en logisk kopia av din data över båda arbetsbelastningarna.
• Specialbyggda motorer. Postgres hanterar transaktioner och Lakehouse tillhandahåller analys, och ingen av dem kompromissar med den andra.
• En enda logisk kopia i öppet lagringsutrymme. Båda motorerna läser en enda kopia av dina data i öppna format, utan repliker eller datapipelines som måste hållas synkroniserade.

Universell styrning

Unity Catalog styr analytisk åtkomst till dina data över båda arbetsbelastningarna. Efter att du har registrerat en Lakebase-databas tillämpar Unity Catalog behörigheter, härstamning och revision på den externa beräkningen som läser den.

Specialbyggda motorer

Postgres tjänar din transaktionsarbetsbelastning och Lakehouse levererar analys, var och en med de styrkor den är byggd för. En vanlig missuppfattning är att om man sammanför de två, blir dina operativa data kalla data som hamnar i Iceberg. Så är det inte. Lakebase är fortfarande standard Postgres. Indexering, förgrening, punkt-i-tid-återhämtning, tillägg och punktläsningar och skrivningar med låg latens fortsätter alla att fungera exakt som idag.

Analytiska läsningar konkurrerar inte med din transaktionella arbetsbelastning eftersom de är isolerade från den primära Postgres-instansen. När en analytisk motor som Lakehouse//RT frågar live Lakebase-data returnerar den ett nytt, transaktionsmässigt konsekvent resultat utan att kopiera data:

• Motorn läser huvuddelen av datan från kolumnkopian i objektlagringen, inte från Postgres.
• För att få en transaktionsmässigt konsistent vy ber den Postgres endast om det aktuella loggsekvensnumret (LSN), ett enda värde som markerar en position i write-ahead loggen. Detta är en billig metadata-sökning.
• För den lilla uppsättningen mycket nyligen genomförda förändringar som ännu inte materialiserats i sjön, läser den dem från sidplattformen och slår ihop dem ovanpå.

Postgres hanterar ingen av den analytiska lästrafiken utöver att returnera det enskilda LSN:et, och transkodning körs i lagringslagret, inte på Postgres-instansen som betjänar din applikation. Din operativa arbetsbelastning fortsätter som förväntat.

En enda logisk kopia i öppen lagring

Eftersom datan finns i sjön som kolumnformad Parquet, läsbar via öppna tabellformat som Delta och Iceberg, delar Lakebase (OLTP) och Lakehouse (OLAP) samma lagringsgrund. Du underhåller en logisk kopia av data över båda arbetsbelastningarna, istället för att stämma av en transaktionsdatabas mot en separat analytisk kopia.

Varje motor kan cacha eller representera den datan i ett annat fysiskt format för prestanda. Lakebase använder Postgres-sidor för snabba punktläsningar i OLTP, och analytiska motorer läser kolumnorienterad Parquet. Du arbetar fortfarande med en enda logisk datamängd, istället för att underhålla separata transaktionella och analytiska kopior och hålla dem synkroniserade.

Varje bord har en enda författare, antingen Lakebase eller lakehouse. Båda motorerna läser den logiska kopian, så samma data är tillgänglig för dina applikationer och för analys utan en andra kopia.

Behöver du ändra hur du använder Lakebase?

No. Att införa LTAP-funktioner kräver ingen datamigrering eller en förändring i hur dina applikationer ansluter till Lakebase. Lakebase förblir standard Postgres: dina befintliga tillägg, index, förfrågningar och applikationskod fortsätter att fungera oförändrade. Var och en av LTAP-funktionerna är oberoende, så du kan använda vilken som helst av dem när en arbetsbelastning behöver det.

Kapabiliteter som implementerar LTAP

Du sätter LTAP-arkitekturen i praktiken genom en uppsättning Lakebase-funktioner. Var och en bygger vidare på den gemensamma lagringsgrunden som beskrivits ovan, och tillsammans täcker de de vägar som data tar genom LTAP:

• Styr och registrera: för in data från Lakebase i Unity Catalog.
• Gör lakehouse-data tillgängliga i Lakebase: synkroniserade tabeller, med acceleration från LTAP Direct Writes.
• Sök i live Lakebase-data: Lakehouse//RT för analys, Lakebase Change Data Feed för förändringsströmmar.

Följande diagram visar hur dessa funktioner skriver till och läser från en kopia av din data, styrd av Unity Catalog.

Lakehouse//RT och Lakebase Change Data Feed läser båda samma underliggande data men representerar den olika. Lakehouse//RT läser det aktuella läget för livedata från Postgres för analys. Change Data Feed levererar en ström av radnivåändringar för nedströms pipelines och revision. Det gäller inte heller den externa CDC som LTAP eliminerar: båda arbetar mot en enda datakopia.

Följande tabell listar varje LTAP-funktion och vad den gör, samt dess releasestatus på ditt moln. Tillgängligheten varierar mellan moln, så en funktion som inte erbjuds i ditt moln markeras som inte tillgänglig.

Hur man närmar sig implementeringen

Nu när du känner till funktionerna, är frågan vilka av dem din arbetslast behöver. Du implementerar LTAP genom att kombinera de funktioner som matchar hur data flödar genom din arkitektur.

Det avgörande beslutet är riktning: för varje dataset, vilket system äger skrivningen? Varje tabell har en enda skrivare, och det avgör vilka funktioner du använder.

• Lakebase har skrivrättigheten. Din applikation skriver till Postgres, och du vill ha den operativa datan tillgänglig för analys utan att kopiera ut den. Till exempel skriver en försäljningsapplikation order och betalningar till Lakebase i realtid. Använd Lakehouse//RT för en intäktsdashboard i realtid baserad på dessa beställningar, eller Lakebase Change Data Feed för att strömma varje ändring i en beställning till en nedströms-pipeline eller en revisionslogg.
• Sjöhuset äger skrivet. Dina data produceras eller underhålls i ett lakehouse, och du vill ha OLTP-läsningar med låg latens av dessa från din applikation. Till exempel beräknar ett nattligt jobb i ett sjöhus produktrekommendationer eller en pristabell. Använd synkade tabeller för att leverera den datan till Lakebase så att din applikation kan läsa den med låg latens, och aktivera LTAP Direct Writes för att påskynda den initiala belastningen av en stor tabell.

Mappa varje dataset till en av dessa riktningar, registrera databasen i Unity Catalog för styrning, och följ sedan kapabilitetsdokumenten för att implementera varje stig. En enda applikation använder ofta båda riktningarna: förser Postgres med referensdata från lakehouset, samtidigt som den gör sina egna transaktionsdata tillgängliga för analysmiljön. Tillgängligheten varierar beroende på moln, så kontrollera kapacitetstabellen ovan för att bekräfta vad som erbjuds i ditt moln.

Nästa steg

• Lakebase-arkitektur: Förstå hur Lakebase separerar tillståndslös beräkning från hållbar lagring. Se Lakebase-arkitektur.
• Registrera en databas i Unity Catalog: Hantera Lakebase-data och fråga efter den från lakehouse-miljön. Se Registrera en Lakebase-databas i Unity Catalog.
• Servera data med synkroniserade tabeller: Synka Unity Catalog-tabelldata till Lakebase för läsningar med låg latens och accelerera stora laster med LTAP Direct Writes. Se Hantera lakehouse-data med synkroniserade tabeller.

• Lakebase Change Data Feed: Förändringar av vattenradsnivåer i sjöhuset för pipelines och revision. Mer information finns i Ändra dataflöde för Lakebase.

Learn more

• Tillkännagivande: Databricks lanserar LTAP: den första Lake Transactional/Analytical Processing-arkitekturen
• Ingenjörsblogg:Från monolit till Lakebase till LTAP: att ompröva databasen från lagring och uppåt
• Demo: LTAP: Den första Lake Transactional/Analytical Processing-arkitekturen