LTAP-architectuur

Lake Transactional/Analytical Processing (LTAP) is een dataarchitectuur die zowel transactionele (OLTP) als analytische (OLAP) workloads bedient vanuit een uniforme dataopslaglaag in het meer, onder één governancemodel, zodat je geen aparte transactionele en analytische systemen synchroon hoeft te houden. Het verwijdert de change data capture (CDC), replicatie en transformatiepijplijnen die teams traditioneel onderhouden om operationele data te kopiëren naar een apart analysesysteem. Azure Databricks bouwt LTAP op de Lakebase storage architecture. Voor de aankondiging, zie Databricks lanceert LTAP: de eerste Lake Transactional/Analytical Processing-architectuur.

LTAP is een architectuur, geen enkel kenmerk. Azure Databricks levert dit via een reeks Lakebase-mogelijkheden die actief worden ontwikkeld en uitgebreid. De mogelijkheden die je tot je beschikking hebt, hangen af van je cloud. Deze pagina legt de architectuur uit. Voor de mogelijkheden die je vandaag in je cloud kunt gebruiken, zie Capabilities die LTAP implementeren.

Important

Voordat je deze pagina leest, lees Lakebase-architectuur om de Lakebase-architectuur en de componenten ervan te begrijpen: stateless Postgres-compute, safekeepers, pageservers en cloud-objectopslag. LTAP bouwt direct voort op hoe Lakebase compute scheidt van storage, en de rest van deze pagina gaat uit van die basis.

De kosten van het synchroon houden van twee stacks

Applicaties verdelen hun datawerk in twee soorten werklast. Transactionele (OLTP) workloads werken op een paar rijen tegelijk en hebben snel de volledige inhoud van die rijen nodig, zoals het verwerken van een betaling of het teruggeven van een API-resultaat. Analytische (OLAP) workloads zoeken naar inzichten over grote datasets, waarbij vaak meerdere rijen worden geaggregeerd en samengevoegd, zoals het voorspellen van verkopen of het opsporen van fraude. Deze patronen trekken in tegengestelde richtingen: OLTP heeft constante lees- en schrijfacties met lage latentie nodig op individuele rijen, terwijl OLAP grote hoeveelheden data moet scannen en aggregeren. Decennialang was het antwoord twee aparte systemen: een transactionele database voor de applicatie en een datawarehouse of lakehouse voor analyse.

Het overbruggen van die twee stacks is het dure deel. Ze synchroon houden houdt in dat je change data capture (CDC), streaming pipelines en read replica's draait, wier enige taak het is data van het ene systeem naar het andere te kopiëren. Die infrastructuur is kwetsbaar, het voegt vertraging toe tussen het schrijven van data en het moment waarop het geanalyseerd kan worden, en het concurreert om middelen met de primaire transactionele database. Naarmate applicaties en AI-agenten steeds meer analyses nodig hebben op de meest recente transactiedata, vertraagt deze kloof teams. Het kopiëren van data tussen twee systemen creëert ook governance-risico: afstamming kan breken als data wordt verplaatst, waardoor verplichtingen zoals GDPR-verwijderverzoeken moeilijker te vervullen zijn.

Hoe LTAP data op de opslaglaag verenigt

In plaats van een betere pijplijn tussen twee stacks te bouwen, haalt LTAP de noodzaak voor een pijplijn helemaal weg. Het doet dit door de database opnieuw te doordenken vanuit de opslaglaag.

Lakebase scheidt toestandsloze Postgres-rekenlaag al van een duurzame opslaglaag van safekeepers, pageservers en cloud-objectopslag. Een transactie wordt vastgelegd zodra een quorum van safekeepers zijn write-ahead log duurzaam registreert, en pageservers materialiseren die wijzigingen vervolgens asynchroon naar cloudobjectopslag, zodat de data niet langer in één enkele database-engine zit.

Note

Voor hoe Lakebase compute en opslag scheidt, zie Lakebase-architectuur.

LTAP voegt één stap toe aan die opslaglaag. Terwijl Lakebase-opslag data materialiseert in objectopslag, transcodeert het de rijgeoriënteerde Postgres-data naar Parquets kolomstructuur zodra de data in het meer landt, waar ze leesbaar zijn via open tabelformaten zoals Delta en Iceberg. Deze transcoding maakt het mogelijk om met één enkele kopie van data zowel OLTP- als OLAP-workloads te bedienen. Het is zo ontworpen dat de kolomtekst een getrouwe, efficiënte weergave blijft van het originele Postgres-origineel:

• Semantiek wordt behouden. Lakebase-opslag transcodeert elke waarde naar zijn kolomvorm, terwijl de oorspronkelijke Postgres-representatie behouden blijft, zodat elke Postgres-compatibele engine de data kan herinterpreteren zonder informatie te verliezen. Typen die niet zuiver naar Parquet passen, zoals NaN, NUMERIC overflow, of uitbreidingstypen zoals vector, array, geografie en JSON, worden behouden in een overflowveld dat de canonieke Postgres-representatie bevat.
• Rijversies zijn bewaard gebleven. De transcoding behoudt tussenliggende rijversies, zodat de kolomkopie dezelfde versie-informatie draagt als de rijgegevens.
• Columnar data laat zich goed comprimeren. De kolomvormige indeling is sterk gecomprimeerd, wat de opslagruimte en de hoeveelheid data die van en naar objectopslag wordt verplaatst, vermindert.

Transcoding draait volledig in de opslaglaag, geïsoleerd van de primaire Postgres-instantie, dus het beïnvloedt je transactionele serveringswerklast niet. Dit bouwt voort op iets wat Lakebase al doet: vastgelegde gegevens wegschrijven naar cloud-objectopslag. LTAP voegt simpelweg het kolomformaat toe aan diezelfde flush. Er is geen pipeline die je kunt bouwen, en geen extern proces dat je database pollt.

Niet alles wordt getranscodeerd. Postgres-indexen blijven in hun oorspronkelijke weergave in de duurzame opslaglaag, in plaats van omgezet te worden naar kolommen, zodat transactionele puntlezingen en -opzoekingen snel blijven terwijl de kolomkopie analytics bedient.

Omdat de data zich bevindt in externaliseerde, versiegefilterde opslag, is het aanmaken van een branch of het herstellen naar een bepaald moment een metadata-operatie in plaats van een fysieke kopie. Je kunt een grote productiedatabase binnen enkele seconden vertakken, een experiment of een risicovolle migratie tegen de branch uitvoeren en deze weggooien, zonder de onderliggende data te dupliceren.

Note

Een Lakebase-branch is een copy-on-write-kloon van de opslag van je database: deze deelt de bestaande data van de ouder en slaat alleen op wat verandert, zodat er vooraf geen data wordt gedupliceerd. Point-in-time-herstel gebruikt dezelfde opslag met versiebeheer om een database terug te zetten naar een eerder tijdstip binnen het herstelvenster. Voor meer informatie, zie Database-vertakkingen en Point-in-time herstel.

Deze opslagniveaubenadering onderscheidt LTAP van change data capture (CDC). CDC repliceert data uit je OLTP-opslag naar een aparte analyselaag met behulp van een extern proces dat continu de primaire database pollt en een pijplijn die rijwijzigingen omzet in kolomgegevens. Die pijplijn verbruikt middelen van je primaire transactionele database, laat je schemawijzigingen en randgevallen zelf afhandelen, en weegt datavernieuwing in tegen de kosten van de pijplijn, terwijl je ook faalpunten toevoegt. LTAP hanteert in plaats daarvan een opslagniveau-aanpak: Lakebase Storage transcodeert data in het meer als onderdeel van normale opslagoperatie, zonder extern proces dat concurreert met je workload en zonder pipeline om te bouwen of te onderhouden.

De drie pijlers van LTAP

Het unificeren van data op de opslaglaag geeft LTAP drie bepalende eigenschappen.

• Universeel bestuur. Unity Catalog regelt de analytische toegang tot één logische kopie van je data over beide workloads.
• Doelgericht ontwikkelde motoren. Postgres bedient transacties en het Lakehouse biedt analytics, en geen van beide compromitteert de ander.
• Een enkele logische kopie in open opslag. Beide engines lezen één kopie van je data in open formaten, zonder replica's of pipelines om synchroon te houden.

Universeel bestuur

Unity Catalog regelt de analytische toegang tot uw data over beide workloads heen. Nadat je een Lakebase-database hebt geregistreerd, past Unity Catalog rechten, afstamming en audit toe op de externe compute die deze leest.

Note

Unity Catalog governance is tegenwoordig van toepassing op analytische toegang: de externe rekenkracht, zoals Lakehouse//RT en Change Data Feed, die je geregistreerde Lakebase-gegevens leest. Het beheert nog niet direct individuele Postgres-tabellen. Toegang via het transactionele pad, wat betekent dat applicaties en clients die verbinding maken met Postgres, nog steeds wordt beheerd door standaard Postgres-privileges (GRANT en REVOKE), niet door Unity Catalog. In de praktijk beheert Unity Catalog de analytische en lakehouse-toegang, terwijl Postgres-rollen en privileges transactionele toegang regelen.

Speciaal gebouwde motoren

Postgres bedient je transactionele werklast en Lakehouse levert analytics, elk met de sterke punten waarvoor het is gebouwd. Een veelvoorkomend misverstand is dat het samenvoegen van de twee betekent dat je operationele data koude data wordt die in Iceberg blijft liggen. Dat is niet het geval. Lakebase blijft standaard Postgres. Indexeren, vertakkingen, herstel naar een specifiek tijdstip, extensies en gerichte lees- en schrijfbewerkingen met lage latentie blijven allemaal precies werken zoals ze dat nu doen.

Analytische leesbewerkingen concurreren niet met je transactionele werklast, omdat ze geïsoleerd zijn van de primaire Postgres-instantie. Wanneer een analytische engine zoals Lakehouse//RT live Lakebase-data zoekt, geeft deze een verse, transactioneel consistente uitslag zonder data te kopiëren:

• De engine leest het grootste deel van de data uit de kolomkopie in het objectgeheugen, niet uit Postgres.
• Om een transactioneel consistente weergave te krijgen, vraagt het Postgres alleen om het huidige logsequentienummer (LSN), een enkele waarde die een positie in het write-ahead log markeert. Dit is een goedkope metadata-zoekopdracht.
• Voor de kleine hoeveelheid zeer recente wijzigingen die nog niet in de data lake zijn terechtgekomen, worden deze uit de pageserver gelezen en er bovenop samengevoegd.

Postgres bedient geen van het analytische leesverkeer behalve het teruggeven van dat ene LSN, en transcoding draait in de opslaglaag, niet op de Postgres-instantie die jouw applicatie bedient. Je operationele werklast blijft verlopen zoals verwacht.

Een enkele logische kopie in open opslag

Omdat de data in het meer ligt als kolomvormige Parquet, leesbaar via open tafelformaten zoals Delta en Iceberg, delen Lakebase (OLTP) en Lakehouse (OLAP) dezelfde opslagbasis. Je onderhoudt één logische kopie van data over beide workloads, in plaats van een transactionele database te vergelijken met een aparte analytische kopie.

Elke engine kan die data in een ander fysiek formaat cachen of representeren voor prestaties. Lakebase gebruikt Postgres-pagina's voor snelle OLTP-puntlezingen, en analytische engines lezen kolomvormige Parquet. Je werkt nog steeds met één logische dataset, in plaats van aparte transactionele en analytische kopieën te onderhouden en synchroon te houden.

Elke tafel heeft één schrijver, ofwel Lakebase of het lakehouse. Beide engines lezen die ene logische kopie, dus dezelfde data is beschikbaar voor je applicaties en voor analytics zonder een tweede kopie.

Moet je veranderen hoe je Lakebase gebruikt?

No. Het adopteren van LTAP-mogelijkheden vereist geen datamigratie of een wijziging in hoe je applicaties verbinding maken met Lakebase. Lakebase blijft standaard Postgres: je bestaande extensies, indexen, queries en applicatiecode blijven ongewijzigd werken. Elke LTAP-functionaliteit is onafhankelijk, dus je kunt ze elke keer adopteren wanneer een workload dat nodig heeft.

Mogelijkheden die LTAP implementeren

Je brengt de LTAP-architectuur in de praktijk via een set Lakebase-mogelijkheden. Elk bouwt voort op de hierboven beschreven shared storage-basis en samen behandelen ze de paden die data via LTAP neemt:

• Bestuur en registreer: breng Lakebase-data onder de Unity Catalog.
• Serveer lakehouse-data in Lakebase: gesynchroniseerde tabellen, versneld door LTAP Direct Writes.
• Live Lakebase-gegevens opvragen: Lakehouse//RT voor analyses, Lakebase Change Data Feed voor wijzigingsstromen.

Het volgende diagram laat zien hoe deze mogelijkheden schrijven naar en lezen uit één kopie van uw data, beheerd door Unity Catalog.

Lakehouse//RT en Lakebase Change Data Feed lezen beide dezelfde onderliggende data, maar vertegenwoordigen deze op verschillende manier. Lakehouse//RT leest de huidige stand van de live Postgres-data voor analyse. Change Data Feed levert een stroom van wijzigingen op rijniveau voor downstream-pipelines en auditing. Dat geldt ook niet voor de externe CDC die LTAP elimineert: beide werken op één kopie van de gegevens.

De volgende tabel geeft een overzicht van elke LTAP-capaciteit en wat deze doet, samen met de releasestatus ervan in uw cloud. De beschikbaarheid verschilt per cloud, dus een mogelijkheid die niet in jouw cloud wordt aangeboden, wordt als niet beschikbaar gemarkeerd.

Capability	Status	Description
Registreer Lakebase in Unity Catalog	GA	Beheer de analytische toegang tot Lakebase-data en voer cross-source queries uit vanuit het lakehouse.
Gegevens leveren met gesynchroniseerde tabellen	GA	Stel Unity Catalog-tabelgegevens beschikbaar in Lakebase voor OLTP-leesbewerkingen met lage latentie. LTAP Direct Writes (Beta) versnelt de initiële belasting in elke synchronisatiemodus, plus volledige verversingen.
Lakehouse//RT zoekt Lakebase op	Bèta	Voer transactioneel consistente OLAP-queries uit op live Postgres-data, zonder de prestaties van Lakebase OLTP te beïnvloeden.
Lakebase-gegevensfeed wijzigen	Public Preview	Sla rijniveauwijzigingen op uit Lakebase Postgres-tabellen op als Unity Catalog Delta-tabellen voor downstream pipelines en audit.

Hoe de implementatie aan te pakken

Nu je de mogelijkheden kent, is de vraag welke je workload nodig heeft. Je implementeert LTAP door de mogelijkheden te combineren die aansluiten bij de datastroming door je architectuur.

De belangrijkste beslissing is de richting: voor elke dataset, welk systeem heeft de schrijfrechten? Elke tabel heeft één schrijver, en dat bepaalt welke mogelijkheden je gebruikt.

• Lakebase beheert de schrijfbewerkingen. Je applicatie schrijft naar Postgres, en je wilt die operationele data beschikbaar hebben voor analyses zonder het uit te kopiëren. Een verkoopapplicatie schrijft bijvoorbeeld bestellingen en betalingen naar Lakebase zodra ze plaatsvinden. Gebruik Lakehouse//RT om een live revenue dashboard op die orders te draaien, of Lakebase Change Data Feed om elke orderwijziging te streamen naar een downstream pipeline of auditlog.
• Het lakehouse is eigenaar van de write. Je gegevens worden gegenereerd of beheerd in het lakehouse en je wilt vanuit je applicatie OLTP-leesbewerkingen met lage latentie op die gegevens uitvoeren. Bijvoorbeeld, een nachtelijke klus in een huis aan het meer berekent productaanbevelingen of een prijstabel. Gebruik gesynchroniseerde tabellen om die data in Lakebase te leveren zodat je applicatie het met lage latentie kan lezen, en schakel LTAP Direct Writes in om de initiële belasting van een grote tabel te versnellen.

Koppel elke dataset aan een van deze richtingen, registreer de database in Unity Catalog voor governance en volg vervolgens de capability-documentatie om elk pad te implementeren. Eén applicatie gebruikt vaak beide richtingen: referentiegegevens vanuit het lakehouse naar Postgres leveren, terwijl ze haar eigen transactionele schrijfacties weer beschikbaar stelt aan analytics. De beschikbaarheid verschilt per cloud, dus bekijk de capaciteitstabel hierboven om te bevestigen wat er in jouw cloud wordt aangeboden.

Volgende stappen 

• Lakebase-architectuur: Begrijp hoe Lakebase stateless compute scheidt van duurzame opslag. Zie Lakebase-architectuur.
• Registreer een database in de Unity Catalog: Bestuur Lakebase-data en zoek deze op vanuit het lakehouse. Zie Een Lakebase-database registreren in Unity Catalog.
• Serveer data met gesynchroniseerde tabellen: Synchroniseer Unity Catalog-tabelgegevens in Lakebase voor reads met lage latentie, en versnel grote belastingen met LTAP Direct Writes. Zie Lakehouse-gegevens serveren met gesynchroniseerde tabellen.

• Lakebase Change Data Feed: Wijzigingen op het waterpeil van de beek in het lakehouse voor pijpleidingen en audit. Zie Lakebase Change Data Feed.

Meer informatie

• Aankondiging: Databricks lanceert LTAP: de eerste Lake Transactional/Analytical Processing-architectuur
• Engineeringblog: Van monoliet tot Lakebase tot LTAP: de database opnieuw doordenken, vanuit de opslag
• Demo: LTAP: De eerste Lake Transactional/Analytical Processing-architectuur