Baza operacyjna i lakehouse: dwie pamięci systemu AI-native

Asystent od zamówienia do zapłaty wchodzi na produkcję. Odpowiada na pytania o otwarte zamówienia, limity kredytowe i przeterminowane faktury, a czyta je prosto z produkcyjnej bazy ERP, bo tam jest prawda. Po miesiącu zespół baz danych dławi jego zapytania, asystent czyta z repliki spóźnionej o dwadzieścia minut, a klient pyta, dlaczego podano mu limit zmieniony w zeszły wtorek. Nikt nie potrafi powiedzieć, co asystent wtedy widział, bo tabela, z której czytał, już tak nie wygląda.

Nic w tej historii nie jest problemem modelu. System dostał jedną pamięć i kazano mu wykonywać pracę dwóch.

Dlaczego jedna pamięć nie wystarcza

Baza operacyjna pod ERP, CRM, WMS czy MES jest systemem zapisu. Została zbudowana, żeby trzymać bieżący stan firmy i bezpiecznie go zmieniać: jedno zamówienie, jedna blokada, jedna transakcja, indeksy dobrane pod szybkie znalezienie jednego wiersza. Dokładnie tym powinna być i nic w tym tekście nie proponuje jej zastępować.

System AI-native zadaje tym samym danym inne pytania, a każde z nich obciąża system zapisu w inny sposób.

Skala odczytu. Agent przygotowujący decyzję kredytową czyta tysiące wierszy z zamówień, faktur i płatności. Model oceniający ryzyko dostawy czyta miliony. Odczyty analityczne tej wielkości konkurują z transakcjami, które baza ma chronić, i dlatego pierwszą reakcją zespołu baz danych jest zawsze dławienie.

Historia. Baza trzyma to, co jest prawdą teraz. Większość pytań do agenta dotyczy zmiany: jaki był limit, gdy przyjmowano zamówienie, od kiedy ten dostawca się spóźnia, czy marża na tym kliencie spada od trzech kwartałów. System zapisu nadpisuje; druga pamięć musi zachowywać wersje.

Więcej niż jeden system. Zamówienie żyje w ERP, reklamacja w CRM, paleta w WMS, postój maszyny w MES. Pytanie „dlaczego ten klient jest niezadowolony” przechodzi przez wszystkie cztery i żadna pojedyncza baza produkcyjna nie odpowie na nie, nie stając się warstwą integracji, do której nigdy nie była projektowana.

Dane, które nie są wierszami. Umowy, rysunki, zdjęcia z kontroli, maile. System wyszukiwania po dokumentach potrzebuje ich obok rekordów, których dotyczą, z tymi samymi identyfikatorami i tymi samymi regułami dostępu.

Co widział agent. Gdy odpowiedź zostaje zakwestionowana, przez klienta, audytora albo regulatora, pytanie brzmi nie tylko „czy odpowiedź była poprawna”, ale „czy była poprawna wobec danych z tamtej chwili”. To wymaga migawki danych takich, jakie były, a nadpisana tabela jej nie odda.

Replika raportowa rozwiązuje pierwszy punkt i żaden z pozostałych. Hurtownia w zamkniętym formacie vendora rozwiązuje kilka, za cenę drugiej kopii prawdy, którą czyta tylko jeden silnik. Drugą pamięcią, której potrzebuje system AI-native, jest lakehouse: tabele w otwartych formatach na magazynie obiektowym, z transakcjami, historią i schematem, czytelne dla każdego silnika, który ma ich dotknąć.

Z czego składa się druga pamięć

Lakehouse to trzy decyzje, i są to decyzje osobne.

Format pliku rozstrzyga, jak jeden plik układa bajty, a więc ile kosztuje odczyt. Parquet jest kolumnowy i w nim lądują dane analityczne; Avro jest wierszowy, niesie własny schemat i tak wyglądają zdarzenia, gdy wędrują między systemami. Oba zwykle występują razem, jeden przed tabelą, drugi w niej. Porównanie jest w tekście Parquet czy Avro: kontrakt między systemami i koszt odpowiedzi.

Format tabeli rozstrzyga, które pliki składają się na tabelę w danej chwili, jaki ma schemat i partycje oraz jak kilku pisarzy zmienia ją bez uszkodzenia. Delta Lake, Apache Iceberg, Apache Hudi i Apache Paimon robią to nad niezmiennymi plikami Parquet, trzymając obok nich wersjonowane metadane; różnią się sposobem ich prowadzenia oraz tym, które silniki i platformy czytają je natywnie. To ta decyzja daje lakehouse transakcje, podróż w czasie, DELETE na żądanie osoby, której dane dotyczą, i zmiany schematu bez przepisywania danych. Jak wybierać, opisuje Delta Lake, Iceberg czy Hudi: wybierajcie po katalogu, nie po liście funkcji.

Katalog rozstrzyga, jakie tabele istnieją, gdzie leżą ich aktualne metadane i kto może je czytać. Tu siedzą Unity Catalog, Apache Polaris, Lakekeeper, AWS Glue albo katalog Fabric. Otwarte pliki pod zamkniętym katalogiem nadal w połowie należą do platformy, a uprawnienia są tą częścią projektu, której otwarte formaty za was nie niosą.

Infografika

Dwie pamięci, jeden system

1. 01Agenci i aplikacjeCzytają drugą pamięć; na pierwszą działają wyłącznie przez jej własne interfejsy.
2. 02Warstwa semantyczna i ontologiaNazwy, relacje i definicje, na które zgadza się cała firma.
3. 03Tabele lakehouseOtwarte formaty tabel nad Parquet: historia, transakcje, schemat, podróż w czasie.
4. 04Przechwytywanie zmian i kontrakty zdarzeńCDC z bazy, zdarzenia między systemami, schematy z wersjami.
5. 05System zapisuBaza operacyjna pod ERP, CRM, WMS, MES. Bieżący stan, chroniony.

Jak dane trafiają z bazy do lakehouse

Droga z systemu zapisu do drugiej pamięci jest miejscem, w którym mieszka większość inżynierii.

Przechwytywanie zmian (CDC) czyta własny log transakcji bazy, Debezium albo odpowiednikiem platformy, i publikuje każdy insert, update i delete jako zdarzenie. Zdarzenia wędrują przez Kafkę albo porównywalny log, każde ze schematem zarejestrowanym i wersjonowanym, do czego służy Avro. Zadanie przetwarzające, we Flinku albo Sparku, osadza je w formacie tabeli na Parquet, gdzie stają się wersjonowaną historią, której baza nigdy nie prowadziła.

Pytaniem do rozstrzygnięcia, zanim cokolwiek z tego powstanie, jest opóźnienie, i należy je rozstrzygać per decyzja, nie dla całej platformy. Trzy poziomy pokrywają prawie każdy przypadek.

Noc. Raportowanie zarządcze, trenowanie modeli, zamknięcia miesiąca. Dzienne ładowanie jest tanie w utrzymaniu, łatwe do testowania i łatwe do naprawy.

Minuty. Limity kredytowe, obietnice stanu magazynowego, status zamówienia dla serwisu. Przechwytywanie zmian do formatu tabeli, z kompaktowaniem w tle, to zwykły projekt.

Sekundy. Nadużycia, alarmy maszyn, agent, który ma działać, gdy klient jest na linii. Ten poziom jest drogi w małych plikach i mocy obliczeniowej i należy do nielicznych decyzji, które naprawdę zmieniają się w ciągu minuty. Jak radzą sobie z nim formaty zbudowane pod strumień, opisuje Stan, na którym działają agenci.

Platforma zaprojektowana pod poziom sekund wszędzie kosztuje jak poziom sekund wszędzie. Większość firm odkrywa, że potrzebują go jedna lub dwie decyzje.

Gdzie agenci czytają, a gdzie wolno im pisać

Reguła, według której projektujemy, jest krótka. Agenci czytają z drugiej pamięci, przez warstwę semantyczną, w takiej skali, jakiej wymaga pytanie. Na pierwszą pamięć działają wyłącznie przez interfejsy, które system zapisu już udostępnia ludziom: API zamówień, przepływ pracy, księgowanie, z tą samą walidacją i tymi samymi uprawnieniami.

Ta reguła ma trzy konsekwencje. Baza produkcyjna nigdy nie widzi analitycznego obciążenia od agenta. Każde działanie, które agent proponuje, przechodzi przez kontrole, którym firma już ufa, i jest rejestrowane pod tożsamością, którą da się audytować. A własne decyzje agenta, o co go zapytano, co przeczytał, co zaproponował, kto zatwierdził, stają się tabelą w lakehouse jak każda inna, z historią, tak że pytanie „co widział agent” ma odpowiedź rok później.

AI SDLC dla warstwy danych

Potoki danych są oprogramowaniem, a w systemie AI-native większość ich kodu będą szkicować agenci kodujący. To zmienia sposób pisania kodu i nie zmienia sposobu jego odbioru.

Najpierw specyfikacja i kontrakt. Zanim powstanie potok, istnieje kontrakt danych: schemat źródłowego zdarzenia lub tabeli, schemat celu, reguły ewolucji, świeżość obiecana odbiorcy, właściciel po każdej stronie. Agent, który dostaje kontrakt, wytwarza użyteczny potok; agent, którego proszą o „wczytanie zamówień”, wytwarza potok prawdopodobny.

Odbiór przez testy na prawdziwych próbkach. Wygenerowane potoki odbiera się jak każdy kod: testy na próbce danych produkcyjnych, liczby wierszy i uzgodnienia ze źródłem, kontrole schematu i zestaw ewaluacyjny dla odpowiedzi, które daje system niżej. Potok, który przechodzi na próbce vendora i pada na waszej, nigdy nie został odebrany.

Wersjonowanie razem. Schemat, kod transformacji, prompt, wersja modelu i migawka danych, która dała odpowiedź, są wersjonowane jako zestaw. Podróż w czasie w formacie tabeli sprawia, że część dotycząca danych jest odtwarzalna, i to pozwala zespołowi cofnąć odpowiedź, a nie tylko kod.

Wycofanie zaplanowane przed zmianą. Każda ewolucja schematu, każda zmiana reguły scalania, każde nowe źródło wchodzi razem z krokiem, który je cofa. W formacie tabeli tym krokiem jest zwykle przywrócenie poprzedniej wersji, które jest tanie, pod warunkiem że ktoś je przetestował.

AI w inżynierii danych: co delegować, a co zatrzymać

Ci sami agenci, którzy piszą kod aplikacji, są dziś użyteczni wewnątrz platformy danych, a granica między tym, co robią dobrze, a tym, o czym nie wolno im decydować, jest wyraźniejsza, niż sugeruje marketing.

Agenci dobrze szkicują potok z kontraktu, proponują ewolucję schematu, gdy źródło dodaje pole, tłumaczą, dlaczego ładowanie padło, czytając log i lineage, planują okna kompaktowania i czyszczenia ze statystyk tabeli oraz piszą opisane wyżej testy. Robią to szybciej od ludzi i z mniejszą liczbą potknięć, a przy dokumentacji są niezmordowani.

Inżynierowie i właściciele zatrzymują decyzje, które wiążą firmę: czy kontrakt może się zmienić i kto płaci za odbiorców, których to zepsuje; retencję i usuwanie, zwłaszcza danych osobowych; który format tabeli i który katalog firma wybiera na lata; którego poziomu opóźnienia dana decyzja naprawdę potrzebuje; oraz czy proponowana przez agenta poprawka jest poprawką, czy obejściem, które ukrywa problem w źródle. Agent, który proponuje, jest zasobem. Agent, który o drugiej w nocy po cichu zmienia kontrakt, jest incydentem.

Jak wygląda dobry wynik

System zapisu jest cichszy niż wcześniej, bo nic analitycznego z niego nie czyta. Jedna tabela w lakehouse jest uzgodnioną historią każdego obiektu biznesowego i każdy silnik używany w firmie czyta ją bez kopii. Pytanie o odpowiedź, której asystent udzielił w marcu, da się odtworzyć na danych z marca. Każdy potok ma kontrakt, właściciela, zestaw testów i procedurę wycofania, a większość jego kodu naszkicował agent i odebrał człowiek. Liczba kopii tych samych danych w firmie spada, a pierwsza opublikowana liczba o świeżości jest zwykle gorsza, niż ktokolwiek zakładał, i to jest moment, w którym zmienia się rozmowa o budżecie, jak opisuje tekst Budżet na dane dostaje się za odpowiedzi.

Mapa serii

Ten tekst jest wejściem do serii o warstwie danych systemów AI-native klasy enterprise. Porównania: Parquet czy Avro, Delta Lake, Iceberg czy Hudi, stan, na którym działają agenci: Paimon, jedna kopia danych, trzy formaty: XTable i UniForm. Profile: Apache Avro, Apache Parquet, Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon.

Nasza część

W inżynierii aplikacji AI-native budujemy system wokół dwóch pamięci: agentów i aplikacje, które czytają lakehouse przez warstwę semantyczną i działają na systemie zapisu przez jego własne interfejsy, z kontraktami, testami i rejestrem decyzji, które czynią całość audytowalną. Nie odsprzedajemy platform. Więcej o predictes na stronie głównej.