Architektura LTAP

Lake Transactional/Analytical Processing (LTAP) to architektura danych, która obsługuje zarówno obciążenia transakcyjne (OLTP), jak i analityczne (OLAP) z jednolitej warstwy magazynowania danych w jeziorze, w ramach jednego modelu zarządzania, dzięki czemu nie musisz utrzymywać oddzielnych systemów transakcyjnych i analitycznych w synchronizacji. Usuwa potoki przechwytywania danych zmian (CDC), replikacji i transformacji, które zespoły tradycyjnie utrzymują do kopiowania danych operacyjnych do osobnego systemu analitycznego. Azure Databricks buduje LTAP na architekturze pamięci Lakebase. Ogłoszenie znajduje się w artykule Databricks uruchamia LTAP: pierwszą architekturę transakcyjno-analitycznego przetwarzania danych w jeziorze danych.

LTAP to architektura, a nie pojedyncza funkcja. Azure Databricks dostarcza to za pośrednictwem zestawu funkcji Lakebase, które są aktywnie rozwijane i rozszerzane. Dostępne możliwości zależą od Twojej chmury. Ta strona wyjaśnia architekturę. Aby dowiedzieć się, jakie możliwości możesz dziś wykorzystać w swojej chmurze, zobacz Możliwości implementujące LTAP.

Ważna

Zanim przeczytasz tę stronę, przeczytaj architekturę Lakebase , aby zrozumieć architekturę Lakebase i jej komponenty: bezstanowe obliczenia Postgres, safekeepery, pageservery oraz chmurowe przechowywanie obiektów. LTAP bazuje bezpośrednio na sposobie, w jaki Lakebase oddziela obliczenia od pamięci masowej, a pozostała część tej strony opiera się na tym założeniu.

Koszt utrzymania dwóch stosów technologicznych zsynchronizowanych

Aplikacje dzielą swoją pracę z danymi na dwa rodzaje obciążeń. Obciążenia transakcyjne (OLTP) działają na kilku wierszach naraz i wymagają szybkiego wypełnienia pełnych tych wierszy, na przykład przetwarzania płatności lub zwracania wyniku API. Obciążenia analityczne (OLAP) służą do uzyskiwania informacji z dużych zbiorów danych, często poprzez agregowanie i łączenie wielu wierszy, na przykład przy prognozowaniu sprzedaży lub wykrywaniu oszustw. Te wzorce działają w przeciwnych kierunkach: OLTP wymaga stałych odczytów i zapisów o niskich opóźnieniach w pojedynczych wierszach, podczas gdy OLAP musi skanować i agregować duże ilości danych. Przez dziesięciolecia odpowiedzią były dwa oddzielne systemy: transakcyjna baza danych dla aplikacji oraz hurtownia danych lub domek nad jeziorem do analizy.

Połączenie tych dwóch stosów technologicznych to najdroższy element. Utrzymywanie ich w synchronizacji oznacza uruchamianie mechanizmów przechwytywania zmian danych (CDC), potoków strumieniowych oraz replik do odczytu, których jedynym zadaniem jest kopiowanie danych z jednego systemu do drugiego. Ta infrastruktura jest krucha, zwiększa opóźnienia między zapisem danych a momentem ich analizy, i konkuruje o zasoby z główną bazą transakcyjną. Ponieważ aplikacje i agenci AI coraz częściej potrzebują analityki na najświeższych danych transakcyjnych, ta luka spowalnia działania zespołów. Kopiowanie danych między dwoma systemami stwarza również ryzyko dla zarządzania: linia może się zerwać wraz z przemieszczaniem się danych, co utrudnia spełnienie takich zobowiązań jak żądania usunięcia treści wynikających z RODO.

Jak LTAP unifikuje dane na warstwie pamięci masowej

Zamiast budować lepszy kanał między dwoma stosami technologicznymi, LTAP całkowicie eliminuje potrzebę jego stosowania. Osiąga to dzięki przeprojektowaniu bazy danych od warstwy pamięci masowej wzwyż.

Lakebase już oddziela bezstanową warstwę obliczeniową Postgresa od trwałej warstwy pamięci masowej obejmującej safekeepers, pageservery i chmurową pamięć obiektową. Transakcja zostaje zatwierdzona, gdy kworum węzłów Safekeeper trwale zapisze jej dziennik wyprzedzający, a serwery stron następnie asynchronicznie odtwarzają te zmiany w chmurowej pamięci obiektowej, dzięki czemu dane nie pozostają już zamknięte w obrębie jednego silnika bazy danych.

Note

Aby dowiedzieć się, jak Lakebase rozdziela obliczenia i przechowywanie, zobacz architekturę Lakebase.

LTAP dodaje jeszcze jeden etap do tej warstwy pamięci masowej. W miarę jak Lakebase storage materializuje dane do pamięci obiektowej, transkoduje wierszowe dane Postgres do kolumnowego układu Parquet, gdy dane lądują w jeziorze, gdzie są czytelne w otwartych formatach tabel, takich jak Delta i Iceberg. To transkodowanie pozwala jednej kopii danych obsługiwać zarówno obciążenia OLTP, jak i OLAP. Zaprojektowano go tak, aby kopia kolumnowa pozostała wiernym i wydajnym odwzorowaniem oryginału w Postgresie:

• Semantyka jest zachowana. Przechowywanie w Lakebase transkoduje każdą wartość na kolumnową formę, zachowując oryginalną reprezentację Postgresa, dzięki czemu każdy silnik kompatybilny z Postgresem może reinterpretować dane bez utraty informacji. Typy, które nie mapują się jednoznacznie do formatu Parquet, takie jak NaN, NUMERIC overflow lub typy rozszerzeń, takie jak vector, array, geography i JSON, są przechowywane w polu overflow, które zawiera kanoniczną reprezentację PostgreSQL.
• Wersje rzędowe zostały zachowane. Transkodowanie zachowuje pośrednie wersje wierszy, więc kopia kolumnowa zawiera te same informacje o wersjach co dane wierszowe.
• Dane kolumnowe dobrze się kompresują. Układ kolumnowy jest silnie skompresowany, co zmniejsza zużycie danych oraz ilość danych przenoszonych do i z pamięci obiektowej.

Transkodowanie działa całkowicie na warstwie pamięci, odizolowanej od głównej instancji Postgres, więc nie wpływa na obciążenie obsługi transakcyjnej. Bazuje to na czymś, co Lakebase już robi: zapisywaniu zatwierdzonych danych w chmurowej pamięci obiektowej. LTAP po prostu dodaje format kolumnowy do tego samego opróżniania. Nie ma pipeline do zbudowania ani zewnętrznego procesu pollującego twoją bazę danych.

Nie wszystko jest transkodowane. Indeksy Postgres pozostają w oryginalnej reprezentacji w warstwie trwałej pamięci, zamiast być konwertowane na kolumny, więc odczyty i wyszukiwania punktów transakcyjnych pozostają szybkie, podczas gdy kolumnowa kopia obsługuje analizę.

Ponieważ dane znajdują się w zewnętrznym, wersjonalnym przechowywaniu, tworzenie gałęzi lub przywracanie do określonego momentu jest operacją metadanych, a nie kopią fizyczną. Możesz rozgałęzić dużą bazę produkcyjną w kilka sekund, przeprowadzić eksperyment lub ryzykowną migrację względem gałęzi i ją odrzucić, nie duplikując danych bazowych.

Note

Gałąź Lakebase to klon pamięci masowej Twojej bazy danych działający na zasadzie copy-on-write: współdzieli istniejące dane gałęzi nadrzędnej i zapisuje tylko wprowadzone zmiany, dzięki czemu na początku nie duplikuje żadnych danych. Przywracanie do określonego punktu w czasie wykorzystuje to samo wersjonowane magazynowanie, aby przywrócić bazę danych do wcześniejszego momentu w ramach okna przywracania. Aby dowiedzieć się więcej, zobacz gałęzie baz danych oraz przywracanie do punktu w czasie.

To podejście na poziomie warstwy pamięci masowej odróżnia LTAP od wychwytywania zmian danych (CDC). CDC replikuje dane z twojej pamięci masowej OLTP do oddzielnej warstwy analitycznej za pomocą zewnętrznego procesu, który nieustannie odpytuje główną bazę danych, oraz potoku danych, który przekształca zmiany w wierszach w dane kolumnowe. Ten pipeline zużywa zasoby w Twojej głównej bazie transakcyjnej, zmusza do samodzielnego zarządzania zmianami schematów i przypadkami brzegowymi oraz wymienia świeżość danych kosztem pipeline'u, a jednocześnie dodaje punkty awarii. LTAP zamiast tego stosuje podejście na poziomie warstwy pamięci masowej: magazyn Lakebase transkoduje dane i zapisuje je w jeziorze danych w ramach standardowych operacji pamięci masowej, bez zewnętrznego procesu rywalizującego o zasoby z Twoimi obciążeniami i bez potoku danych, który trzeba tworzyć lub utrzymywać.

Trzy filary LTAP

Ujednolicenie danych w warstwie pamięci masowej nadaje LTAP trzy cechy definiujące.

• Uniwersalne rządy. Unity Catalog zarządza analitycznym dostępem do jednej logicznej kopii danych w obu obciążeniach.
• Silniki zaprojektowane do konkretnych zastosowań. Postgres obsługuje transakcje, a Lakehouse analitykę, i żadna z tych opcji nie kompromituje drugiej.
• Jedna logiczna kopia w otwartej pamięci. Oba silniki odczytują jedną kopię Twoich danych w otwartych formatach, bez replik czy potoków do synchronizacji.

Rządy uniwersalne

Unity Catalog zarządza analitycznym dostępem do Twoich danych w obu tych obciążeniach. Po zarejestrowaniu bazy danych Lakebase, Unity Catalog stosuje uprawnienia, linię i audyt do zewnętrznego procesora, który ją odczytuje.

Note

Mechanizmy zarządzania w Unity Catalog obowiązują dziś w przypadku dostępu analitycznego: zewnętrznych zasobów obliczeniowych, takich jak Lakehouse//RT i Change Data Feed, które odczytują zarejestrowane dane Lakebase. Nie zarządza jeszcze bezpośrednio poszczególnymi tabelami Postgres. Dostęp przez ścieżkę transakcyjną, czyli aplikacje i klienci łączący się z Postgresem, nadal jest kontrolowany przez standardowe uprawnienia Postgresa (GRANT i REVOKE), a nie przez Unity Catalog. W praktyce Unity Catalog zarządza dostępem analitycznym i dostępem do środowiska lakehouse, podczas gdy role i uprawnienia w Postgres określają dostęp transakcyjny.

Silniki specjalnie zbudowane

Postgres obsługuje obciążenia transakcyjne, a Lakehouse — analitykę, przy czym każde z nich wykorzystuje mocne strony, z myślą o których zostało stworzone. Powszechnym błędnym przekonaniem jest to, że połączenie tych dwóch rzeczy oznacza, że dane operacyjne stają się zimnymi danymi przechowywanymi w Icebergu. To jednak nieprawda. Lakebase pozostaje standardowym Postgresem. Indeksowanie, tworzenie gałęzi, odzyskiwanie do punktu w czasie, rozszerzenia oraz punktowe operacje odczytu i zapisu o niskim opóźnieniu nadal działają dokładnie tak jak obecnie.

Odczyty analityczne nie konkurują z Twoim obciążeniem transakcyjnym, ponieważ są odizolowane od głównej instancji Postgres. Gdy silnik analityczny, taki jak Lakehouse//RT, odpytuje dane Lakebase na żywo, zwraca aktualny, transakcyjnie spójny wynik bez kopiowania danych:

• Silnik odczytuje większość danych z kolumnowej kopii w pamięci obiektowej, a nie z Postgres.
• Aby uzyskać transakcyjnie spójny widok, odpytuje Postgresa jedynie o bieżący numer sekwencji dziennika (LSN), czyli pojedynczą wartość wskazującą pozycję w dzienniku write-ahead log. To tanie wyszukiwanie metadanych.
• Dla niewielkiego zestawu bardzo świeżych zmian, które jeszcze nie zostały zmaterializowane w jeziorze, czyta je z pageservera i łączy na górze.

Postgres nie obsługuje żadnego ruchu analitycznego odczytu poza zwracaniem tego jednego LSN, a transkodowanie działa na warstwie pamięci, a nie na instancji Postgres obsługującej twoją aplikację. Twoje obciążenie operacyjne działa zgodnie z oczekiwaniami.

Pojedyncza logična kopia w otwartej pamięci

Ponieważ dane znajdują się w jeziorze jako kolumnowy parket, czytelny za pomocą otwartych formatów tabelowych, takich jak Delta i Iceberg, Lakebase (OLTP) i Lakehouse (OLAP) mają tę samą podstawę przechowywania. Utrzymujesz jedną logiczną kopię danych na obu obciążeniach, zamiast uzgadniać bazę danych transakcyjną z osobną kopią analityczną.

Każdy silnik może buforować lub reprezentować te dane w innym formacie fizycznym dla wydajności. Lakebase wykorzystuje strony Postgresa do szybkich punktowych odczytów OLTP, a silniki analityczne odczytują kolumnowy format Parquet. Nadal pracujesz z jednym logicznym zbiorem danych, zamiast utrzymywać oddzielne kopie transakcyjne i analityczne oraz utrzymywać ich synchronizację.

Każda tabela ma tylko jeden podmiot zapisujący: albo Lakebase, albo lakehouse. Oba silniki odczytują tę jedną logiczną kopię, więc te same dane są dostępne dla twoich aplikacji i analityki bez drugiej kopii.

Czy musisz zmienić sposób korzystania z Lakebase

No. Wdrożenie możliwości LTAP nie wymaga migracji danych ani zmiany sposobu łączenia aplikacji z Lakebase. Lakebase pozostaje standardowym Postgresem: Twoje istniejące rozszerzenia, indeksy, zapytania i kod aplikacji działają bez zmian. Każda z funkcji LTAP jest niezależna, więc możesz ją zaadaptować, gdy wymaga tego obciążenie.

Możliwości implementujące LTAP

Wprowadzasz architekturę LTAP w praktykę poprzez zestaw funkcji Lakebase. Każdy z nich opiera się na wspólnym nośniku opisanym powyżej i razem obejmują ścieżki, którymi dane przechodzą przez LTAP:

• Zarządzaj i rejestruj się: przenieś dane Lakebase do katalogu Unity.
• Udostępniaj dane lakehouse w Lakebase: zsynchronizowane tabele, przyspieszone dzięki LTAP Direct Writes.
• Zapytaj dane na żywo z Lakebase: Lakehouse//RT dla analityki, Lakebase Change Data Feed dla strumieni zmian.

Poniższy diagram pokazuje, jak te możliwości zapisują się i odczytują z jednej kopii Twoich danych, zarządzanych przez Unity Catalog.

Lakehouse//RT i Lakebase Change Data Feed odczytują te same dane bazowe, ale reprezentują je inaczej. Lakehouse//RT odczytuje aktualny stan danych PostgreSQL na żywo na potrzeby analityki. Change Data Feed dostarcza strumień zmian na poziomie wierszy dla potoków przetwarzania downstream i na potrzeby audytu. To nie jest też zewnętrzne CDC, które LTAP eliminuje: oba działają na pojedynczej kopii danych.

Poniższa tabela zawiera wszystkie funkcje LTAP oraz informacje o ich działaniu i statusie udostępnienia w twojej chmurze. Dostępność zależy od chmury, więc funkcja, która nie jest dostępna w Twojej chmurze, jest oznaczana jako niedostępna.

Capability	Status	Description
Zarejestruj Lakebase w katalogu Unity	ogólna dostępność	Zarządzaj analitycznym dostępem do danych Lakebase i uruchamiaj zapytania międzyźródłowe z Lakehouse.
Udostępnianie danych z zsynchronizowanymi tabelami	ogólna dostępność	Obsługuj dane tabelowe z katalogu Unity w Lakebase dla odczytów OLTP o niskich opóźnieniach. LTAP Direct Writes (Beta) przyspiesza początkowe ładowanie w każdym trybie synchronizacji, a także pełne odświeżanie.
Lakehouse//RT zapytuje Lakebase	Beta	Uruchamiaj transakcyjnie spójne zapytania OLAP na danych PostgreSQL w czasie rzeczywistym, bez wpływu na wydajność transakcji OLTP w Lakebase.
Zestawienie danych zmian w usłudze Lakebase	Podgląd publiczny	Przechowuj zmiany na poziomie wierszy z tabel Lakebase Postgres jako tabele Delta w Unity Catalog na potrzeby dalszych potoków przetwarzania i audytu.

Jak podejść do wdrożenia

Teraz, gdy znasz te możliwości, pytanie brzmi, których wymaga Twój zakres pracy. Implementujesz LTAP, łącząc możliwości odpowiadające przepływowi danych przez twoją architekturę.

Kluczową decyzją jest kierunek: dla każdego zbioru danych, który system jest właścicielem zapisu? Każda tabela ma jednego autora, który decyduje o tym, jakich funkcji używasz.

• Lakebase ma prawo zapisu. Twoja aplikacja zapisuje dane w Postgresie i chcesz, aby te dane operacyjne były dostępne na potrzeby analiz bez konieczności ich kopiowania. Na przykład aplikacja sprzedażowa zapisuje zamówienia i płatności do Lakebase na bieżąco, w miarę jak się pojawiają. Użyj Lakehouse//RT do uruchomienia na żywo pulpitu przychodów dla tych zamówień lub Lakebase Change Data Feed, aby przesyłać każdą zmianę zamówienia do pipeline'u downstream lub dziennika audytu.
• Lakehouse odpowiada za zapis. Twoje dane są tworzone lub utrzymywane w lakehouse, a chcesz, aby Twoja aplikacja wykonywała na nich odczyty OLTP o niskich opóźnieniach. Na przykład nocna praca przy jeziorze oblicza rekomendacje produktów lub tabelę cen. Używaj zsynchronizowanych tabel, aby dostarczać te dane do Lakebase, aby aplikacja mogła je odczytać z niskim opóźnieniem, oraz włącz LTAP Direct Writes, aby przyspieszyć początkowe obciążenie dużej tabeli.

Przypisz każdy zbiór danych do jednego z tych kierunków, zarejestruj bazę danych w Unity Catalog do zarządzania, a następnie postępuj zgodnie z dokumentacją dotyczącą możliwości, aby zaimplementować każdą ścieżkę. Jedna aplikacja często korzysta z obu kierunków: dostarcza dane referencyjne z domku nad jeziorem do Postgres, jednocześnie udostępniając własne zapisy transakcyjne analityce. Dostępność różni się w zależności od chmury, więc sprawdź powyższą tabelę możliwości, aby potwierdzić, co oferuje twoja chmura.

Następne kroki

• Architektura Lakebase: Zrozum, jak Lakebase odróżnia obliczenia stanowe od trwałej pamięci. Zobacz architekturę Lakebase.
• Zarejestruj bazę danych w Unity Catalog: Zarządzaj danymi Lakebase i zapytuj je z domku nad jeziorem. Zobacz Jak zarejestrować bazę danych Lakebase w Unity Catalog.
• Dostarczaj dane za pomocą zsynchronizowanych tabel: Synchronizuj dane z tabel katalogu Unity do Lakebase dla odczytów o niskich opóźnieniach i przyspieszaj duże obciążenia za pomocą LTAP Direct Writes. Zobacz Udostępnianie danych Lakehouse poprzez zsynchronizowane tabele.

• Strumień danych zmian Lakebase: Przesyłaj strumieniowo zmiany na poziomie wierszy do lakehouse na potrzeby potoków danych i audytu. Zobacz Zestawienie danych zmian w usłudze Lakebase.

Learn more

• Ogłoszenie: Databricks uruchamia LTAP: pierwszą architekturę przetwarzania transakcyjno-analitycznego w Lake
• Blog inżynierski: Od monolitu do Lakebase do LTAP: przemyślenie bazy danych od pamięci masowej w górę
• Demo: LTAP: pierwsza architektura transakcyjno-analitycznego przetwarzania danych w data lake