Databricks upraszcza orkiestrację agentów AI, ale ryzyko spoczywa teraz na Postgresie

Databricks upraszcza orkiestrację agentów AI dzięki architekturze produkcyjnej, która zastępuje kilka wyspecjalizowanych usług jedną bazą danych Lakebase Postgres. Wydanie z 22 lipca opisuje aplikację audytową zbudowaną z CLA, która przetwarza dokumenty w ciągu minut zamiast godzin. To poprawa zgłoszona przez firmę, lecz większe znaczenie ma zmiana architektoniczna.

System wykorzystuje Postgres do obsługi kolejek zadań, ponowień, harmonogramowania, przypisywania kosztów i aktualizacji statusu na żywo. Databricks twierdzi, że CLA nie potrzebuje już zewnętrznych brokerów, takich jak Kafka czy Redis, oddzielnych harmonogramów, takich jak Airflow czy Temporal, ani dedykowanej pamięci podręcznej.

Ta konsolidacja tworzy wyraźne napięcie. Wyspecjalizowane systemy orkiestracji rozdzielają odpowiedzialności i absorbują złożone awarie. Databricks przenosi więcej tych odpowiedzialności do znajomej bazy danych, ograniczając infrastrukturę, ale czyniąc projekt bazy centralnym elementem niezawodności agentów.

Databricks upraszcza stos wokół długo działających agentów

Bezpośrednią zmianą nie jest nowy model ani framework agentów. To wzorzec produkcyjny, który traktuje Lakebase jako centrum sterowania pracą agentów.

Databricks i firma usług profesjonalnych CLA stworzyły ten system na potrzeby audytów wspomaganych przez agentów. Audyty często wymagają od pracowników przejrzenia umów, faktur, sprawozdań finansowych i dokumentów uzupełniających przed wyodrębnieniem ustrukturyzowanych informacji.

Aplikacja przyjmuje pliki PDF przez interfejs FastAPI działający w Databricks Apps. Przechowuje te pliki w Unity Catalog Volumes i zapisuje każde żądanie ekstrakcji w Lakebase.

Lakebase to zarządzana usługa Postgres firmy Databricks. Jej dokumentacja Postgres opisuje automatyczne skalowanie, rozgałęzianie baz danych, repliki do odczytu, natychmiastowe przywracanie i integrację z Unity Catalog.

Dwie tabele relacyjne tworzą operacyjny rdzeń systemu. Tabela tasks rejestruje każde logiczne zadanie, w tym status, priorytet, informacje o dzierżawie, przypisanie agenta i wynik końcowy. Tabela task_attempts rejestruje poszczególne wykonania, w tym identyfikatory zadań, identyfikatory śledzenia i metadane kosztowe.

Lakeflow Jobs wykonują pracę nad dokumentami. Każde zadanie odczytuje zapisany plik PDF, wywołuje komponenty i modele do przetwarzania dokumentów, a następnie zapisuje wynik z powrotem w Lakebase. MLflow przechwytuje wywołania modeli, wykorzystanie tokenów, opóźnienia i informacje o kosztach.

Architektura rozdziela zatem odpowiedzialności bez wprowadzania kolejnej warstwy infrastruktury. Lakeflow wykonuje pracę, podczas gdy Lakebase rejestruje, co powinno zostać uruchomione, co jest uruchomione i co zostało zakończone.

Databricks twierdzi, że ten projekt skrócił proces ekstrakcji CLA z godzin do minut bez obniżenia jakości. Firma nie opublikowała niezależnego benchmarku, rozkładu obciążeń ani zmierzonego wskaźnika błędów potwierdzającego to stwierdzenie.

Mimo to wydanie wykracza poza luźny diagram referencyjny. Databricks wskazuje wzorce współbieżności, odzyskiwania, ograniczania przepustowości, wywołań zwrotnych, obserwowalności i rozliczeń potrzebne do obsługi tej architektury.

Ten poziom szczegółowości ma znaczenie, ponieważ tabela w bazie danych nie staje się automatycznie bezpieczną kolejką zadań. Proste zapytanie może wybrać oczekującą pracę, ale wielu workerów może wybrać ten sam wiersz, zanim którykolwiek z nich zaktualizuje jego status.

Projekt musi także odzyskiwać pracę po awarii procesu. Musi zapobiegać generowaniu zduplikowanych wyników przez zduplikowane wywołania zwrotne. Musi utrzymywać żądania do modeli w granicach zewnętrznych limitów i umożliwiać pilnym dokumentom pomijanie pracy zbiorczej.

Projekt orkiestracji rozwiązuje te problemy za pomocą transakcji i sprawdzonych funkcji Postgres. Nowością nie jest to, że Postgres może przechowywać stan agentów. Deweloperzy robią to od lat.

Mocniejsze twierdzenie brzmi, że zarządzany Postgres może stać się fundamentem orkiestracji dla produkcyjowego obciążenia agentowego bez Kafka, Redis, Temporal, Airflow ani innego harmonogramu.

Rzeczywista presja spada na wyspecjalizowaną infrastrukturę

Databricks podważa założenie, że każda produkcyjna aplikacja agentowa potrzebuje oddzielnego brokera, harmonogramu, pamięci podręcznej i stosu obserwowalności.

Demonstracje agentów często realizują jedno żądanie od początku do końca w pojedynczym procesie. Systemy produkcyjne działają inaczej, ponieważ użytkownicy równocześnie zgłaszają pracę, wywołania modeli zawodzą, a poszczególne zadania mają nieprzewidywalny czas trwania.

Databricks ilustruje tę zmienność za pomocą dwóch typów dokumentów. Dwustronicowa faktura może zostać ukończona w ciągu kilku sekund, podczas gdy 200-stronicowa umowa może wymagać kilku minut. Worker nie może zakładać, że zadania zostaną ukończone w kolejności zgłoszenia.

Limity modeli dodają kolejne ograniczenie. Endpoint może ograniczać liczbę żądań na sekundę, tokenów na minutę albo oba te parametry. Wysłanie setek dokumentów jednocześnie może wywołać ograniczanie przepustowości i powtarzające się ponowienia.

Aplikacja musi także odpowiadać na pytania operacyjne. Zespoły muszą wiedzieć, które zadanie zakończyło się niepowodzeniem, które wywołanie modelu zużyło tokeny, ile kosztowała każda próba i czy porzucone zadanie powinno zostać uruchomione ponownie.

Tradycyjne architektury często przypisują te kwestie oddzielnym produktom. Broker wiadomości transportuje zadania. Silnik workflow zarządza trwałym wykonaniem. Pamięć podręczna zapewnia szybki dostęp do stanu. Platforma monitoringu agreguje status, opóźnienia i koszty.

Taki podział może wspierać złożone workflow i duże organizacje. Wprowadza jednak dodatkowe poświadczenia, procesy wdrożeniowe, dashboardy, tryby awarii i kod integracyjny.

Databricks argumentuje, że ten narzut jest nieproporcjonalny w przypadku długo działających zadań, które są od siebie niezależne. Ekstrakcja dokumentów pasuje do tego opisu, ponieważ jedna umowa zazwyczaj nie zależy od wyniku innej umowy.

Lakebase zmienia tę kalkulację, umieszczając stan transakcyjny obok pozostałej części aplikacji Databricks. Ta sama platforma zapewnia interfejs, pliki, zadania, ślady modeli, mechanizmy zarządzania i rejestry rozliczeniowe.

To podejście wywiera presję na dwie grupy. Zespoły platformowe muszą uzasadniać każdą dodatkową wprowadzaną usługę, podczas gdy dostawcy narzędzi orkiestracji muszą pokazać, dlaczego ich wyspecjalizowane gwarancje przewyższają dobrze zaprojektowaną kolejkę w bazie danych.

Nie czyni to dedykowanych systemów przestarzałymi. Amazon na przykład pozycjonuje AgentCore Runtime jako zarządzane środowisko z izolacją sesji, skalowaniem, tożsamością i obsługą długo działających agentów.

Takie podejście wymaga od zespołów przyjęcia środowiska wykonawczego przeznaczonego dla agentów. Databricks zaczyna natomiast od operacyjnej bazy danych i łączy ją z usługami już używanymi do obciążeń danych i uczenia maszynowego.

Rywalizacja dotyczy zatem granic infrastruktury. Czy wykonanie agentów powinno działać w wyspecjalizowanym środowisku wykonawczym, czy baza danych powinna koordynować zwykłe zadania za pośrednictwem trwałego stanu relacyjnego?

Databricks ma strukturalną przewagę wśród obecnych klientów. Zespoły już korzystające z Lakeflow, MLflow, Unity Catalog i Databricks Apps mogą skonsolidować rozwiązanie bez wprowadzania kolejnego dostawcy lub modelu bezpieczeństwa.

Ta sama przewaga tworzy zależność od platformy. Firma wybierająca pełny wzorzec wiąże wykonanie zadań, przechowywanie, obserwowalność, zarządzanie i raportowanie kosztów z usługami Databricks.

Dla kupujących „prościej” nie może oznaczać wyłącznie mniejszej liczby nazw produktów. Musi oznaczać mniej zadań operacyjnych, jaśniejszą odpowiedzialność za awarie, akceptowalne zachowanie podczas odzyskiwania i możliwą do utrzymania strategię wyjścia.

Cztery wzorce Postgres uwiarygadniają kolejkę

Architektura działa, ponieważ przekształca znane prymitywy bazodanowe w jawne gwarancje dotyczące współbieżności, odzyskiwania, ograniczania przepustowości i ponowień.

Pierwszym wzorcem jest bezpieczne pod względem współbieżności zdejmowanie zadań z kolejki. Worker wybiera kwalifikujące się wiersze za pomocą FOR UPDATE SKIP LOCKED, co blokuje wybrane wiersze, jednocześnie pozwalając innym workerom je pominąć.

PostgreSQL dokumentuje SKIP LOCKED jako przydatne do unikania kontencji, gdy wielu konsumentów uzyskuje dostęp do tabeli przypominającej kolejkę. Ostrzega również, że ta opcja przedstawia niespójny widok, przez co nie nadaje się do zapytań ogólnego przeznaczenia.

To rozróżnienie oddaje siłę tego projektu. Tabela zadań nie jest używana do arbitralnego raportowania podczas zdejmowania zadań z kolejki. Workery potrzebują wyłącznych roszczeń do dostępnych zadań bez czekania na blokadę innego workera.

Zapytanie porządkuje pracę według malejącego priorytetu i czasu utworzenia. Zadania o wyższym priorytecie uruchamiają się jako pierwsze, a zadania o tym samym priorytecie zachowują kolejność pierwsze weszło, pierwsze wyszło.

Drugi wzorzec wykorzystuje wygasające dzierżawy. Gdy worker przejmuje zadanie, rejestruje czas wygaśnięcia dzierżawy zamiast przypisywać własność na zawsze.

Okresowy proces czyszczący zwraca wygasłe zadania do kolejki. Jeśli worker zniknie z powodu eksmisji, wdrożenia, błędu pamięci lub awarii procesu, inny worker może odzyskać jego zadanie w ciągu kilku minut.

Dzierżawy rozwiązują problem porzuconej pracy, ale wprowadzają też wymaganie. Aplikacja musi wybierać okresy wygaśnięcia przekraczające normalny czas trwania zadań albo odnawiać dzierżawy, gdy praca trwa.

Dzierżawa wygasająca zbyt wcześnie może sprawić, że zdrowo wykonywana praca zostanie uznana za porzuconą. Dzierżawa trwająca zbyt długo wydłuża czas odzyskiwania po rzeczywistej awarii.

Trzeci wzorzec kontroluje wykorzystanie modelu przed wysłaniem zadania. Orkiestrator obsługuje limit współbieżnych zadań, prognozowany budżet tokenów albo połączenie obu tych mechanizmów.

Limit współbieżności zlicza wiersze obecnie oznaczone jako przetwarzane. Ponieważ baza danych przechowuje tę liczbę, ograniczenie pozostaje widoczne po restartach workerów i w wielu replikach orkiestratora.

Budżet tokenów szacuje zużycie dla każdego zadania w locie. Orkiestrator wysyła kolejne zadanie tylko wtedy, gdy jego prognozowana liczba tokenów mieści się w skonfigurowanym limicie.

Gdy oba mechanizmy są włączone, obowiązuje bardziej restrykcyjne ograniczenie. Umożliwia to obsługę obciążeń, które przechodzą między wieloma małymi fakturami a kilkoma umowami zużywającymi dużo tokenów.

Czwarty wzorzec sprawia, że wywołania zwrotne są idempotentne. Idempotencja oznacza, że powtórzenie tego samego żądania daje ten sam rzeczywisty rezultat zamiast dwukrotnego zastosowania zmiany.

Przerwy w sieci i proxy mogą spowodować, że wywołanie zwrotne dotrze więcej niż raz. Databricks akceptuje wywołania zwrotne dla zadań przetwarzanych lub ponownie umieszczonych w kolejce, traktując jednocześnie stany już ukończone jako operacje bez efektu.

Takie zachowanie zmniejsza ryzyko zduplikowanego przetwarzania lub naliczania opłat. Zależy jednak od stabilnych tożsamości zadań, starannie zaprojektowanych przejść stanów oraz granicy transakcji obejmującej aktualizację wyniku.

Łącznie te cztery wzorce tworzą wiarygodną kolejkę. Transakcje zapobiegają równoczesnym przejęciom, dzierżawy odzyskują porzuconą pracę, budżety ograniczają wysyłanie zadań, a idempotentne wywołania zwrotne tolerują ponowne dostarczanie.

W ten sposób Databricks upraszcza kolejkę zadań agentów, nie twierdząc, że sama para tabel jest wystarczająca. Kod aplikacji nadal realizuje politykę regulującą każde przejście.

Mechanizm ten nadaje się do zadań o stosunkowo prostych strukturach zależności. Staje się mniej atrakcyjny, gdy praca wymaga zagnieżdżonych workflow, działań kompensacyjnych, zatwierdzeń przez ludzi lub długich łańcuchów zdarzeń czasowych.

Dedykowany silnik workflow często bezpośrednio reprezentuje takie relacje. W przypadku kolejki bazodanowej deweloperzy muszą modelować je jako tabele, przejścia stanów i logikę aplikacji.

Ten kompromis powinien kształtować wdrożenie. Zespoły powinny wybierać ten wzorzec dlatego, że ich workflow jest wystarczająco prosty, a nie dlatego, że Postgres może teoretycznie reprezentować każdy możliwy workflow.

Jedna baza danych łączy stan, widoczność i koszt

Najbardziej charakterystyczną częścią projektu nie jest kolejkowanie. To decyzja o wyprowadzaniu widoczności operacyjnej i przypisywania kosztów z tych samych rekordów zadań.

Operatorzy potrzebują czegoś więcej niż etykiety „ukończono” lub „niepowodzenie”. Panel CLA pokazuje liczbę zadań umieszczonych w kolejce, przetwarzanych, ukończonych, nieudanych i anulowanych.

Wyświetla także liczbę tokenów wejściowych i wyjściowych, koszty modeli, koszty obliczeń, medianę czasu odpowiedzi oraz poziom ufności dla każdego dokumentu. Filtry obejmują zakresy czasu, stany zadań i poszczególnych agentów.

Mediana opóźnienia jest użytecznym wyborem dla tego typu obciążenia. Backoff ponawiania prób i nasycenie kolejki mogą powodować skrajne opóźnienia, które zniekształcają prostą średnią.

Postgres LISTEN/NOTIFY zapewnia mechanizm aktualizacji na żywo. Wyzwalacz bazy danych publikuje zdarzenie przy zmianie stanu zadania, a backend aplikacji utrzymuje jedno nasłuchujące połączenie.

Backend rozsyła te zdarzenia do przeglądarek za pośrednictwem Server-Sent Events. SSE to jednokierunkowy strumień HTTP, który pozwala serwerowi wysyłać aktualizacje przez trwałe połączenie z przeglądarką.

Databricks podaje, że zmiany w panelu zwykle pojawiają się w ciągu około jednej sekundy. Ten projekt nie wymaga Redis, serwera WebSocket ani magistrali komunikatów dla tej ścieżki.

System zachowuje odpytywanie jako stały mechanizm awaryjny. Gdy strumieniowanie staje się niedostępne, przeglądarki żądają świeżych danych co dziesięć sekund.

To zabezpieczenie jest ważne, ponieważ proxy wejściowe w chmurze mogą przerwać strumień bez wygenerowania czytelnego błędu w przeglądarce. Panel opierający się wyłącznie na zdarzeniach push może po cichu stać się nieaktualny.

Panel łączy informacje o różnej częstotliwości odświeżania. Stan w Postgres jest natychmiastowy, podczas gdy dane śledzenia MLflow docierają — według Databricks — w czasie krótszym niż sekunda.

Zapytania rozliczeniowe mogą trwać dziesiątki sekund. Dlatego aplikacja wykonuje szybkie zapytania o stan podczas zwykłych odświeżeń, a wolniejsze zapytania rozliczeniowe rezerwuje dla działań użytkownika.

Przypisywanie kosztów wymaga kolejnej warstwy filtrowania. Tabele rozliczeniowe Databricks obejmują aktywność całego konta, więc surowe zapytanie łączyłoby wydatki z niepowiązanych zadań i aplikacji.

Orkiestrator rejestruje konkretne uruchomienia Databricks Job przypisane do swoich zadań. Zapytania rozliczeniowe filtrują następnie aktywność konta według tych identyfikatorów.

Pozwala to jednemu SQL warehouse obsługiwać kilka aplikacji, podczas gdy każdy panel pokazuje wyłącznie własne obciążenie. Operatorzy mogą dodatkowo zawężać wyniki według statusu, agenta lub daty.

Projekt wspiera praktyczne pytania, które ogólne monitorowanie często zaciera. Zespół może sprawdzić koszt nieudanych zadań w okresie siedmiu dni albo porównać medianę wydatków między agentami.

To połączenie tożsamości zadania z kosztem ma znaczenie wykraczające poza audyt. Aplikacje AI często tracą relację między żądaniem użytkownika, próbami, które ono uruchomiło, a wynikową fakturą za model.

Trwały rekord zadania zapewnia zespołom stabilny klucz łączenia. Łączy intencję biznesową, historię wykonania, ślady modelu, aktywność obliczeniową i końcowy wynik.

Zespoły intensywnie wykorzystujące wiedzę stają przed pokrewnym problemem po zakończeniu wykonania. Muszą zachować dokumenty, decyzje i wyniki otaczające zautomatyzowaną pracę w przeszukiwalnym kontekście.

Ustrukturyzowana baza wiedzy inżynierskiej może uzupełniać ślady środowiska uruchomieniowego, zachowując ludzki kontekst stojący za incydentami i decyzjami projektowymi.

Wartość wzorca Lakebase wykracza zatem poza mniejszą liczbę usług. Tworzy jedną operacyjną narrację dla każdego zadania — od zgłoszenia, przez ponawianie prób, po koszt i rezultat.

Prostsza infrastruktura przenosi ryzyko do projektu bazy danych

Databricks ogranicza nakład integracyjny, ale nie eliminuje złożoności systemów rozproszonych. Przenosi ją do schematów, transakcji, dzierżaw i kodu aplikacji.

Sformułowanie „brak zewnętrznej infrastruktury” wymaga uważnej interpretacji. Aplikacja nadal zależy od kilku usług Databricks, w tym Apps, Lakeflow Jobs, MLflow, Unity Catalog Volumes i Lakebase.

Uproszczenie zachodzi w ramach jednej zarządzanej platformy. Nie redukuje architektury do jednego procesu ani jednej usługi.

To rozróżnienie ma znaczenie podczas awarii. Kolejka Lakebase może pozostać trwała, gdy usługa zadań jest niedostępna, ale aplikacja nadal potrzebuje przetestowanego zachowania dla opóźnionego wysyłania i odzyskiwania.

Zespoły muszą również ustalić, co dzieje się, gdy callback powiedzie się, ale otaczająca go operacja zawiedzie. Idempotencja chroni przed wielokrotnym dostarczeniem tylko wtedy, gdy każdy efekt uboczny wykorzystuje spójne identyfikatory i granice.

Kontrola limitów szybkości również zawiera element niepewności. Prognozowany budżet tokenów zależy od oszacowania zużycia przez dokument, zanim model go przetworzy.

Szacunki mogą niedoszacować złożone dokumenty lub przeszacować proste. Niedoszacowanie może wywołać ograniczanie po stronie dostawcy, a przeszacowanie może pozostawić niewykorzystaną dostępną przepustowość modelu.

Opublikowany projekt nie przedstawia wyników przepustowości, limitów głębokości kolejki, wskaźników awarii, obciążenia bazy danych ani porównawczych danych operacyjnych. Nie porównuje też implementacji bezpośrednio z dedykowanym silnikiem workflow.

Databricks podaje, że czas ekstrakcji spadł z godzin do minut. Nie ujawnia jednak próbki dokumentów, procesu weryfikacji przez ludzi, miary dokładności, konfiguracji modelu ani bazowego workflow.

Czytelnicy powinni traktować ten wynik jako relację klienta produkcyjnego, a nie kontrolowany benchmark. Architektura może być użyteczna nawet bez udowodnienia uniwersalnych wzrostów wydajności.

Sam Postgres może stać się punktem spornym. Częste pobieranie z kolejki, aktualizacje statusu, obliczenia budżetu tokenów, odczyty panelu i łączenia rozliczeniowe wywodzą się z powiązanych rekordów operacyjnych.

Lakebase oferuje automatycznie skalowane zasoby obliczeniowe i niezależne trwałe przechowywanie danych. Te funkcje mogą ograniczyć planowanie pojemności, lecz automatyczne skalowanie nie eliminuje nieefektywnych zapytań ani sporów o blokady.

Tabele kolejek rosną również inaczej niż zwykłe tabele aplikacyjne. Historia prób się kumuluje, ukończone rekordy pozostają wartościowe dla audytów, a indeksy muszą wspierać zarówno bieżące harmonogramowanie, jak i analizę historyczną.

Zasady retencji i archiwizacji są zatem częścią projektu kolejki. Bez nich zapytania operacyjne mogą stopniowo konkurować z obciążeniami raportowymi.

Bezpieczeństwo zasługuje na równie dużą uwagę. Tabela zadań może zawierać lokalizacje dokumentów, wyodrębnione wyniki, oceny ufności, przypisania agentów i identyfikatory wykonania.

Databricks podaje, że Unity Catalog zapewnia wspólną tożsamość i uprawnienia. Zespoły nadal muszą egzekwować dostęp zgodny z zasadą najmniejszych uprawnień, chronić endpointy webhooków i zdecydować, którzy operatorzy mogą przeglądać wrażliwe wyniki.

Rozgałęzianie bazy danych może pomóc odtworzyć defekty w odizolowanym środowisku. Może również kopiować wrażliwe dane operacyjne, co wymaga maskowania i kontroli dostępu odpowiednich dla obciążenia audytowego.

Szersza kwestia konkurencyjna pozostaje nierozstrzygnięta. Google AlloyDB AI również pozycjonuje infrastrukturę zgodną z PostgreSQL jako podstawę dla aplikacji AI, w tym wyszukiwań wektorowych i hybrydowych.

AWS wybiera bardziej specyficzną dla agentów drogę, oferując zarządzane usługi środowiska uruchomieniowego, pamięci, tożsamości i orkiestracji. Dedykowane systemy workflow nadal koncentrują się na trwałym wykonywaniu w złożonych grafach procesów.

Databricks pokazał, że Postgres może pokryć istotny obszar pośredni. Nie wykazał jednak, że orkiestracja skoncentrowana na bazie danych powinna zastąpić te systemy we wszystkich obciążeniach agentowych.

Najmocniejszy przypadek wdrożeniowy obejmuje niezależne, długotrwałe zadania na istniejącej platformie Databricks. Najsłabszy dotyczy workflow między systemami o złożonych zależnościach i rygorystycznych wymaganiach dotyczących przenośności.

Trzy sygnały sprawdzą zasadność orkiestracji Lakebase

Kolejnym testem będzie to, czy architektura CLA stanie się powtarzalnym wzorcem produkcyjnym, a nie starannie zaprojektowaną implementacją klienta.

Pierwszym sygnałem jest wdrożenie wykraczające poza ekstrakcję dokumentów. Databricks powinien opublikować przykłady obejmujące agentów programistycznych, operacje obsługi klienta, naprawę danych lub workflow badawcze.

Takie obciążenia przetestowałyby różne rozmiary zadań, struktury zależności, uprawnienia narzędzi i wymagania dotyczące zatwierdzania przez człowieka. Podobne wyniki wzmocniłyby twierdzenie, że Lakebase jest ogólnym magazynem stanu agentów.

Jeśli przyszłe przykłady pozostaną ograniczone do niezależnych zadań dokumentowych, projekt nadal będzie użyteczny. Jego praktyczny zakres będzie po prostu węższy, niż sugeruje szerszy język dotyczący orkiestracji.

Drugim sygnałem są porównawcze dane operacyjne. Zespoły potrzebują informacji o przepustowości kolejki, czasach odzyskiwania, wykorzystaniu bazy danych, wskaźnikach awarii i opóźnieniu wysyłania przy utrzymującym się obciążeniu.

Szczególnie użyteczne byłoby porównanie z workerami opartymi na Redis lub trwałym silnikiem workflow. Mogłoby ono pokazać, kiedy ograniczenie pracy integracyjnej przeważa nad dodatkową logiką maszyny stanów wewnątrz aplikacji.

Przejrzyste dane wzmocniłyby argument Databricks za uproszczeniem. Brak takich danych pozostawiłby nabywców zależnych od opisów architektury i wyników zgłaszanych przez klientów.

Trzecim sygnałem jest produktizacja. Dzisiejszy wzorzec opiera się na kodzie aplikacji implementującym blokowanie, dzierżawy, ograniczanie przepustowości, callbacki, strumieniowanie panelu i przypisywanie kosztów.

Databricks mógłby przekształcić części tego projektu w szablony, zarządzane komponenty, biblioteki referencyjne lub wbudowane możliwości Lakebase. Ograniczyłoby to ilość kodu krytycznego dla poprawności, który utrzymuje każdy klient.

Produktizacja ujawniłaby także, jak Databricks definiuje granicę między funkcjami bazy danych a funkcjami workflow. Większa warstwa zarządzana konkurowałaby bardziej bezpośrednio ze środowiskami uruchomieniowymi agentów i platformami orkiestracji.

Zespoły oceniające ten wzorzec powinny zacząć od kształtu swojego workflow. Niezależne zadania z jasno określonymi stanami końcowymi dobrze pasują do projektu CLA.

Następnie powinny przetestować zachowanie przy awariach, zanim zaczną optymalizować przepustowość. Zatrzymujcie workery, opóźniajcie callbacki, duplikujcie żądania, wyczerpujcie limity modeli i przerywajcie strumienie panelu.

Na koniec porównajcie obciążenie operacyjne z jedną wyspecjalizowaną alternatywą. Policzcie usunięte usługi, ale także dodane niestandardowe przejścia, reguły odzyskiwania, testy i podręczniki operacyjne.

Databricks upraszcza widoczną infrastrukturę wokół orkiestracji agentów, a Lakebase zapewnia temu projektowi wiarygodny rdzeń transakcyjny. Otwarte pozostaje pytanie, czy wasza aplikacja jest wystarczająco prosta, aby taka konsolidacja pozostała prosta.

Jeśli tak, kolejka skoncentrowana na bazie danych może skrócić drogę od prototypu do obserwowalnego systemu produkcyjnego. Jeśli nie, brakujący broker lub silnik workflow pojawi się ponownie jako kod aplikacji. Właściwym kolejnym krokiem jest pilotaż skoncentrowany na awariach, wykorzystujący rzeczywiste rozmiary zadań, rzeczywiste limity i rzeczywiste cele odzyskiwania.