--- title: "Baza operacyjna i lakehouse: dwie pamięci systemu AI-native" url: "https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native" description: "Baza ERP wie, co jest prawdą teraz. Agenci, modele i audyt muszą wiedzieć, jak do tego doszło. Dlaczego system AI-native potrzebuje lakehouse obok bazy SQL." --- # Baza operacyjna i lakehouse: dwie pamięci systemu AI-native 21 października 2026·6 min czytania·predictes 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](https://predictes.com/pl/blog/parquet-czy-avro-kontrakt-miedzy-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](https://predictes.com/pl/blog/delta-lake-iceberg-czy-hudi-wybierajcie-po-katalogu-nie-po-liscie-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ą. 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. Czerwona warstwa to ta, której większość systemów enterprise jeszcze nie ma, a od której zależy wszystko powyżej. ## 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](https://predictes.com/pl/blog/stan-na-ktorym-dzialaja-agenci-paimon-miedzy-baza-a-raportem). 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](https://predictes.com/pl/blog/budzet-na-dane-dostaje-sie-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](https://predictes.com/pl/blog/parquet-czy-avro-kontrakt-miedzy-systemami-i-koszt-odpowiedzi), [Delta Lake, Iceberg czy Hudi](https://predictes.com/pl/blog/delta-lake-iceberg-czy-hudi-wybierajcie-po-katalogu-nie-po-liscie-funkcji), [stan, na którym działają agenci: Paimon](https://predictes.com/pl/blog/stan-na-ktorym-dzialaja-agenci-paimon-miedzy-baza-a-raportem), [jedna kopia danych, trzy formaty: XTable i UniForm](https://predictes.com/pl/blog/jedna-kopia-danych-trzy-formaty-co-xtable-i-uniform-zmieniaja-w-planie-testow). Profile: [Apache Avro](https://predictes.com/pl/blog/apache-avro-schemat-jest-umowa-ktora-podpisuja-wasze-systemy), [Apache Parquet](https://predictes.com/pl/blog/apache-parquet-dlaczego-rachunek-za-analityke-zalezy-od-ukladu-pliku), [Delta Lake](https://predictes.com/pl/blog/delta-lake-log-transakcji-pod-fabric-i-databricks-i-co-nadal-jest-wasze), [Apache Iceberg](https://predictes.com/pl/blog/apache-iceberg-format-tabeli-na-ktorym-mozna-oprzec-plan-wyjscia), [Apache Hudi](https://predictes.com/pl/blog/apache-hudi-gdy-lakehouse-ma-nadazac-za-baza), [Apache Paimon](https://predictes.com/pl/blog/apache-paimon-jedna-tabela-dla-strumienia-i-raportu). ## Nasza część W [inżynierii aplikacji AI-native](https://predictes.com/pl/services/ai-native-apps-engineering) 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](https://predictes.com/pl). - lakehouse - system zapisu - AI SDLC - inżynieria danych ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Drugi rok transformacji AI: co zwykle się rozpada](https://predictes.com/pl/blog/drugi-rok-transformacji-ai-co-zwykle-sie-rozpada)