Databricks

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 1 z 15. Przez lata firmy płaciły dwa razy za przechowywanie dokładnie tych samych danych, tylko po to, by zadowolić zarówno swoich inżynierów machine learningu, jak i analityków biznesowych. Przechowywanie surowych danych w jednym systemie i kopiowanie ich do drugiego tworzy niekończące się problemy z synchronizacją. Databricks rozwiązuje ten problem, wprowadzając ujednolicone podejście zwane Data Lakehouse. Historycznie organizacje dzieliły swoją architekturę danych na dwie oddzielne ścieżki. Najpierw budowały Data Lakes. To tanie, wysoce skalowalne systemy cloud storage, idealne do wrzucania ogromnych ilości nieustrukturyzowanych danych. Data scientists uwielbiają je do trenowania modeli machine learningowych. Ale Data Lakes są fatalne do szybkich i niezawodnych zapytań SQL. Aby to rozwiązać, firmy wprowadziły Data Warehouses dla swoich zespołów Business Intelligence. To tworzy ogromne obciążenie operacyjne. Weźmy na przykład rozwijający się startup. Ich data engineers wrzucają surowe event logi do bucketa w cloud storage. Odpalają tam swoje skrypty w Pythonie. Ale zespół finansowy potrzebuje dashboardów. Więc inżynierowie muszą budować skomplikowane pipeline'y, żeby wyciągnąć te dane, przetransformować je i załadować do oddzielnego Data Warehouse. Firma płaci za storage dwa razy. Płaci za compute potrzebny do przeniesienia danych. A w momencie, gdy dane trafiają do Data Warehouse, są już nieaktualne. Databricks całkowicie eliminuje ten pipeline dzięki architekturze Data Lakehouse. Lakehouse łączy tani i elastyczny storage Data Lake'a z niezawodnością i wydajnością Data Warehouse. Trzyma twoje dane w jednym, otwartym formacie bezpośrednio w twoim cloud storage. Nie kopiujesz ich do zamkniętej bazy danych. Zamiast tego, Databricks dodaje warstwę transakcyjną bezpośrednio na twoim istniejącym Data Lake'u. Oto kluczowa kwestia. Twoje dane zostają w jednym miejscu, ale różni specjaliści pracują z nimi dokładnie tak, jak tego potrzebują. Data scientists mogą pisać w Pythonie lub Scali, żeby trenować modele bezpośrednio na surowych plikach. Jednocześnie analitycy biznesowi mogą odpalać wysokowydajne zapytania SQL na dokładnie tych samych danych, żeby zasilać swoje narzędzia do raportowania. Ludzie często błędnie myślą, że Databricks to po prostu kolejna baza danych SQL albo zwykły zarządzany wrapper na Apache Spark. Nie jest ani jednym, ani drugim. To kompleksowa Data Intelligence Platform. Łącząc Lake i Warehouse, łączysz również bezpieczeństwo i governance. W starym modelu musiałeś zarządzać uprawnieniami dostępu w cloud storage dla inżynierów i osobno w Data Warehouse dla analityków. W Databricks ujednolicona warstwa governance obsługuje kontrolę dostępu do każdej tabeli, pliku i modelu machine learningowego. Definiujesz politykę dostępu do danych raz i obowiązuje ona wszędzie, niezależnie od języka czy narzędzia użytego do ich odpytania. Prawdziwa siła architektury Lakehouse to nie tylko oszczędzanie pieniędzy na nadmiarowych pipeline'ach storage'owych; chodzi o to, że twoje modele AI i twoje finansowe dashboardy w końcu patrzą na dokładnie te same liczby w dokładnie tym samym czasie. Jeśli chcesz pomóc utrzymać ten podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 2 z 15. Jeśli twoja firma korzysta z wielu workspace'ów do przetwarzania danych, prawdopodobnie masz wiele miejsc, w których zarządzasz uprawnieniami bezpieczeństwa. Ta fragmentacja to ogromne ryzyko compliance, ponieważ synchronizacja polityk w rozłączonych środowiskach opiera się wyłącznie na ręcznych aktualizacjach. Unity Catalog eliminuje to ryzyko, fundamentalnie zmieniając sposób, w jaki działa data governance w Databricks. Zanim przejdziemy do mechaniki, musimy rozwiać bardzo powszechne nieporozumienie. Unity Catalog nie jest pasywnym data dictionary. To nie tylko lista tabel, gdzie użytkownicy wchodzą, żeby poczytać opisy. To centralny policy engine, który aktywnie egzekwuje reguły bezpieczeństwa w całej twojej architekturze. Unity Catalog rozwiązuje odwieczny problem dokładnej wiedzy o tym, kto ma do czego dostęp. Zapewnia ujednolicony model bezpieczeństwa oparty na standardowym ANSI SQL. Zamiast oddzielnie konfigurować role cloud identity, uprawnienia na poziomie workspace'u i kontrolę dostępu na poziomie klastra, używasz znanych poleceń, takich jak grant i revoke, bezpośrednio na swoich danych i zasobach AI. Ponieważ Unity Catalog działa na poziomie konta, a nie jest przypisany do pojedynczego workspace'u, definiujesz regułę bezpieczeństwa dokładnie raz. Ta reguła jest następnie natychmiast i globalnie egzekwowana w każdym workspace'u podpiętym do tego katalogu. Wyobraź sobie sytuację, w której audytor prosi CTO o dokładne udowodnienie, kto w zeszły wtorek odpytał konkretną tabelę zawierającą numery kart kredytowych, oraz o zidentyfikowanie każdego downstreamowego raportu, który aktualnie używa tych numerów. Historycznie, odpowiedź na to oznaczała parsowanie rozłącznych logów systemowych w różnych narzędziach, ręczne czytanie zaplanowanych jobów transformacyjnych i nadzieję, że nie pominięto żadnych kroków pośrednich. Unity Catalog obsługuje to natywnie poprzez swoje dwa kolejne filary: wbudowany audyt i zautomatyzowany lineage. Po pierwsze, rejestruje szczegółowe logi audytowe na poziomie użytkownika out of the box. Za każdym razem, gdy użytkownik lub service principal uzyskuje dostęp do danych, katalog loguje to zdarzenie. I tu jest kluczowa sprawa. Unity Catalog nie tylko śledzi, kto odpytał tabelę; śledzi też, co dzieje się z danymi dalej, poprzez zautomatyzowany lineage. Kiedy twoje zaplanowane pipeline'y działają, system na bieżąco czyta execution plany i buduje mapę przepływu danych. Śledzi, które tabele źródłowe zasilają które pośrednie datasety, aż do końcowych dashboardów. Śledzi to zarówno na poziomie tabeli, jak i kolumny. Kiedy audytor pyta o dane kart kredytowych, nie musisz zgadywać. Odpalasz graf lineage i natychmiast widzisz każdy krok transformacji oraz każdy punkt dostępu. Ostatnim głównym filarem jest bezpieczny data sharing. Organizacje często muszą udostępniać datasety zewnętrznym vendorom lub oddzielnym jednostkom biznesowym. Zamiast eksportować flat files lub duplikować dane do oddzielnych bucketów w cloud storage, Unity Catalog integruje protokół o nazwie Delta Sharing. Pozwala ci to przyznać zewnętrznym podmiotom kontrolowany dostęp do danych live bez ich kopiowania. Zewnętrzny konsument czyta dane in place, a jego dostęp jest logowany i kontrolowany przez dokładnie ten sam centralny mózg. Prawdziwą wartością Unity Catalog jest to, że całkowicie usuwa niebezpieczną lukę między spisaniem polityki bezpieczeństwa na papierze a jej faktycznym egzekwowaniem w odizolowanych silosach danych. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 3 z 15. Najprostszym sposobem na przepalenie budżetu chmurowego jest zostawienie potężnego serwera, żeby chodził na pusto przez cały weekend. Chcesz mieć moc obliczeniową dokładnie wtedy, kiedy jej potrzebujesz, i zerowe rachunki, kiedy jej nie używasz. Właśnie o tym porozmawiamy dzisiaj w części Nawigacja po Workspace i Compute. Twoim punktem wejścia do Databricks jest Workspace. Pomyśl o Workspace jako o zunifikowanym środowisku, w którym twój zespół organizuje wszystkie swoje zasoby Databricks. Zapewnia interfejs webowy do zarządzania twoimi notebookami, obiektami danych, eksperymentami machine learning i podległymi zasobami compute. Workspace gromadzi wszystkie narzędzia do kolaboracji w jednym, uporządkowanym widoku, dzięki czemu różne zespoły mogą pracować na tych samych danych bez wchodzenia sobie w drogę. Pod maską Databricks opiera się na architekturze decoupled. Twoje dane żyją na stałe w cloud object storage, podczas gdy compute używany do ich przetwarzania jest odpalany całkowicie osobno. To separation of concerns dyktuje to, jak jesteś rozliczany. Ponieważ compute jest odizolowany od storage'u, provisionujesz i płacisz za instancje serwerów tylko wtedy, gdy aktywnie odpalasz kod. Kiedy praca jest skończona, compute się wyłącza, ale twoje dane pozostają bezpiecznie zapisane i dostępne. Aby zarządzać tym compute, Databricks oferuje różne typy zasobów compute dostosowane do konkretnych workflowów. Pierwszy z nich to klaster All-Purpose. Używasz go do interaktywnej pracy ad-hoc. Powiedzmy, że analityk danych potrzebuje bardzo wydajnego środowiska, żeby zrobić query na miliardzie wierszy we wtorkowe popołudnie. Odpala klaster All-Purpose, podpina swój notebook i zaczyna eksplorację. Aby zapobiec weekendowym niespodziankom na rachunku, te klastry polegają na auto-termination. Jeśli analityk idzie do domu o piątej i zostawia otwarty notebook, klaster sam monitoruje swoją nieaktywność i automatycznie się wyłącza po określonym limicie czasu. A oto kluczowa rzecz dotycząca automatyzacji. Częstym błędem popełnianym przez zespoły jest planowanie zautomatyzowanych produkcyjnych pipeline'ów tak, aby działały na tych interaktywnych klastrach All-Purpose. Unikaj tego. Klastry All-Purpose wiążą się z wyższymi kosztami użycia, a odpalanie wielu różnych workflowów na współdzielonym, interaktywnym klastrze może wprowadzić konflikty bibliotek albo resource contention. Zamiast tego, produkcyjne pipeline'y powinny używać klastrów Job. Klaster Job jest całkowicie efemeryczny. Kiedy zautomatyzowany pipeline zostaje odpalony, job scheduler Databricks provisionuje dedykowany klaster Job ściśle pod ten workload. Odpala on kod, a w ułamku sekundy po zakończeniu joba, klaster sam się terminuje. To gwarantuje ścisłą izolację zasobów dla twojego pipeline'u i zapewnia, że płacisz najniższą możliwą stawkę za compute dla zautomatyzowanych tasków. Na koniec, jeśli twój workload jest czysto analityczny, możesz użyć SQL warehouse. Jest to zasób compute zoptymalizowany specjalnie pod odpalanie komend SQL i query do dashboardów. Jeśli używasz Serverless SQL warehouses, Databricks automatycznie zarządza podległym compute. Skaluje się w górę natychmiast, gdy uderza fala queries, i skaluje w dół, gdy kolejka pustoszeje, całkowicie eliminując potrzebę samodzielnego konfigurowania infrastruktury. Dopasowanie odpowiedniego typu compute do dokładnej natury twojego taska to najskuteczniejszy sposób, aby zagwarantować, że twoja infrastruktura chmurowa pozostanie potężna w godzinach szczytu i wysoce opłacalna po zakończeniu pracy. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 4 z 15. Budujesz data lake, ale po kilku miesiącach nikt nie wie, gdzie są dane produkcyjne, kto jest ich właścicielem, ani czy na konkretnej tabeli można bezpiecznie wykonać query. Różnica między czystym data lake a niemożliwym do opanowania data swamp sprowadza się dokładnie do trzech poziomów. Dzisiaj przyjrzymy się organizacji danych: omówimy Object Model. Unity Catalog wprowadza porządek w twoich danych dzięki ścisłej, przewidywalnej hierarchii. Absolutnie najwyższym kontenerem jest metastore, który przechowuje metadane twojej organizacji. Ale twoje codzienne interakcje opierają się na podstawowym, trzypoziomowym namespace. Każde query, które piszesz, odwołuje się do zasobu w formacie catalog kropka schema kropka object. Pierwszy poziom to catalog. Zapewnia on szerokie granice dla zasobów danych. Zazwyczaj używasz catalogów do logicznego oddzielenia środowisk, na przykład mając jeden catalog dla produkcji i całkowicie osobny dla developmentu. Drugi poziom to schema, nazywana również bazą danych. Schemy żyją wewnątrz catalogów i organizują powiązane ze sobą zbiory danych. Możesz utworzyć jedną schemę dla surowych, pobranych eventów, a drugą dla przetworzonej analityki. Trzeci poziom to sam object. To jest twoja właściwa tabela, view lub volume przechowujący pliki nietabelaryczne. Wymuszając tę trzyczęściową konwencję nazewnictwa, Unity Catalog nadaje każdemu elementowi danych jasny, jednoznaczny adres. Kiedy analityk wykonuje query na production kropka sales kropka customers, lokalizacja, etap cyklu życia i cel tych danych stają się natychmiast oczywiste. Oto kluczowa sprawa. Kiedy dotrzesz do poziomu tabeli, musisz zrozumieć, jak Unity Catalog wchodzi w interakcję z twoim faktycznym storagem. Istnieją dwa główne typy tabel: managed tables i external tables. Managed tables są domyślne. Kiedy tworzysz managed table, Unity Catalog jest właścicielem zarówno metadanych, jak i samych danych. Odpowiada za układ plików i zarządza całym cyklem życia danych. Rzeczywiste pliki są zapisywane w wyznaczonym miejscu w storage'u, które konfigurujesz na poziomie metastore, catalog lub schema. External tables działają inaczej. Używasz external table, gdy masz już pliki znajdujące się w cloud storage bucket i chcesz je zostawić dokładnie tam, gdzie są. W przypadku external table, Unity Catalog rejestruje strukturę i zarządza dostępem, ale jest właścicielem tylko metadanych. Ty zachowujesz pełną kontrolę nad fizycznymi plikami. To rozróżnienie staje się krytyczne podczas operacji destrukcyjnych. Wyobraź sobie scenariusz, w którym data engineer przypadkowo wykonuje komendę drop table. Jeśli usunie managed table, Unity Catalog usuwa tabelę z metastore i automatycznie kasuje pliki bazowe z twojego cloud storage. Dane zostają zniszczone. Jeśli usunie external table, Unity Catalog po prostu usuwa link do metadanych. Tabela znika z interfejsu twojego workspace, ale surowe pliki w twoim cloud storage pozostają całkowicie nienaruszone i nietknięte. Zawsze używaj managed tables, gdy chcesz, aby catalog optymalizował i zarządzał całym cyklem życia storage'u, i rezerwuj external tables dla danych, które musisz chronić przed przypadkowym usunięciem lub udostępniać bezpośrednio innym zewnętrznym systemom. Dzięki za wspólnie spędzony czas. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 5 z 15. Możesz łatwo ograniczyć to, kto widzi kolumnę w relacyjnej bazie danych, ale jak wymusić kontrolę dostępu do bucketa w cloud storage, pełnego tysięcy surowych PDF-ów? Odpowiedź to: okiełznanie nieustrukturyzowanych danych za pomocą Volumes. Zanim przejdziemy do tego, jak działają, wyjaśnijmy częste nieporozumienie. Volumes służą wyłącznie do path-based dostępu do plików. Nie służą do danych tabelarycznych. Jeśli odpytujesz wiersze i kolumny za pomocą SQL-a, używasz tabeli. Jeśli czytasz obrazy, dokumenty tekstowe lub pliki audio, używasz Volume. Volume to obiekt w Unity Catalog. Reprezentuje logiczny storage w twoim środowisku chmurowym. Tworząc Volume, obejmujesz nieustrukturyzowane dane dokładnie tym samym parasolem bezpieczeństwa, co twoje ustrukturyzowane tabele. Zamiast zarządzać identity policies w AWS albo role assignments w Azure tylko po to, żeby odczytać plik, kontrolujesz dostęp za pomocą standardowych uprawnień bezpośrednio w Databricks. Wyobraź sobie szpital, który trenuje model machine learning do wykrywania anomalii na zdjęciach rentgenowskich. Nie mogą wrzucić tysięcy obrazów w wysokiej rozdzielczości do tabeli w bazie danych. Muszą je przechowywać jako raw files w cloud object storage. Ponieważ są to bardzo wrażliwe pliki pacjentów, ścisły governance jest kluczowy. Umieszczając zdjęcia rentgenowskie w Databricks Volume, zespół inżynierów może dokładnie zarządzać tym, którzy data scientists mają prawo odczytywać ten konkretny directory. Istnieją dwa typy Volumes: managed i external. Managed Volume jest w całości obsługiwany przez Databricks. Kiedy go tworzysz, nie podajesz storage path. Databricks po prostu wydziela miejsce w domyślnym storage location przypisanym do twojego obecnego schema. Uploadujesz pliki bezpośrednio do niego. Jeśli kiedykolwiek dropniesz managed Volume, Databricks usunie również underlying files. To sprawia, że są idealne dla tymczasowych plików workspace'a lub danych generowanych w całości wewnątrz twoich Databricks pipelines. External Volume wskazuje na istniejący cloud storage directory, który już posiadasz. Najpierw rejestrujesz cloud storage path jako external location w Unity Catalog. Następnie tworzysz na nim Volume. Daje ci to ścisły governance nad danymi wyprodukowanymi przez inne systemy. Jeśli osobna aplikacja zapisuje log files w buckecie Azure Data Lake, external Volume pozwala użytkownikom Databricks na bezpieczny odczyt tych plików. Jeśli dropniesz external Volume, metadata zostanie usunięte, ale underlying files w twoim cloud buckecie pozostaną całkowicie nietknięte. To podejście path-based jest dokładnie tym, czego wymaga nowoczesne AI. Open-source'owe biblioteki machine learning zazwyczaj oczekują odczytu danych z lokalnego file systemu. Nie wiedzą, jak się autentykować w zamkniętych interfejsach cloud storage. Volumes rozwiązują ten problem, wystawiając directory path, który wygląda i zachowuje się jak standardowy lokalny folder. Twój skrypt trenujący model po prostu otwiera file path. Unity Catalog przechwytuje ten request i płynnie weryfikuje user permissions. Oto kluczowy wniosek. Volumes eliminują rozdźwięk między tym, jak zarządzasz swoimi ustrukturyzowanymi bazami danych, a tym, jak zabezpieczasz swoje raw files, pozwalając ci uruchamiać workloady machine learning na nieustrukturyzowanych danych bez omijania enterprise security. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 6 z 15. Jeśli twoi inżynierowie danych nadal wklejają cloud access keys bezpośrednio do swoich skryptów, twoja firma jest o jeden błąd od potężnego wycieku danych. Rozwiązaniem, które pozwala bezpiecznie połączyć twój workspace z cloud storage bez ujawniania sekretów, jest Bulletproof Cloud Security: External Locations. Kiedy użytkownik loguje się do Databricks, używa identity tokena. Ten token potwierdza jego tożsamość dla workspace'u. Ale ta tożsamość nie znaczy absolutnie nic dla twojego cloud providera, niezależnie czy jest to AWS, Azure, czy Google Cloud. Żeby odczytać plik z bucketa, sam workspace musi się uwierzytelnić w infrastrukturze chmurowej. Historycznie developerzy obchodzili ten problem, hardkodując klucze IAM bezpośrednio w swoich notebookach lub zmiennych środowiskowych. Tworzy to poważną lukę bezpieczeństwa, ponieważ każdy, kto ma read access do kodu, może ukraść te klucze. Unity Catalog rozwiązuje ten problem poprzez ścisłą, dwuczęściową abstrakcję. Pierwszą częścią jest Storage Credential. Storage Credential reprezentuje mechanizm uwierzytelniania i autoryzacji bezpośrednio powiązany z twoim cloud providerem. Mapuje się on na rolę IAM w AWS, Managed Identity w Azure lub Service Account w Google Cloud. Zamiast przekazywać developerowi surowe klucze do chmury, twój cloud administrator przyznaje uprawnienia dostępu do tego Storage Credential. Unity Catalog ma uprawnienia do przejęcia tej roli, trzymając właściwy credential całkowicie poza zasięgiem użytkowników workspace'u. Jednak sam Storage Credential daje zbyt szeroki dostęp. Ta rola IAM może mieć uprawnienia dostępu do dziesiątek różnych bucketów w twoim środowisku chmurowym. Tu właśnie pojawia się druga część. External Location łączy Storage Credential z konkretną ścieżką w cloud storage, taką jak URI bucketa S3 lub ścieżka kontenera Azure Data Lake Storage. Definiuje dokładnie, gdzie ten credential może operować. Możesz o tym myśleć jak o geograficznej granicy dla twoich cloud credentials. Weźmy konkretny scenariusz. Developer musi przeanalizować logi systemowe przechowywane w wysoce zabezpieczonym buckecie S3. W legacy setupie, admin wygenerowałby klucze dostępu AWS i wysłał je developerowi, mając nadzieję, że ten nie zacommituje ich przypadkowo do publicznego repozytorium kodu. Z Unity Catalog ten workflow zmienia się całkowicie. Admin tworzy Storage Credential skonfigurowany z rolą IAM, która może odczytać docelowy bucket. Następnie admin tworzy External Location wskazujący ściśle na ścieżkę S3 zawierającą logi systemowe i podpina pod niego ten Storage Credential. Na koniec, używając standardowego SQL-a, admin nadaje developerowi uprawnienia do odczytu plików wyłącznie w tym External Location. Kiedy developer puszcza query do logów, Unity Catalog wkracza do akcji i transparentnie obsługuje cloud authentication w jego imieniu. Developer nigdy nie widzi klucza AWS. Nie zarządza sekretami ani nie konfiguruje cloud profili. Po prostu odpytuje dozwoloną ścieżkę. Później możesz budować external tables lub external volumes bezpośrednio na tej lokalizacji, żeby jeszcze lepiej uporządkować dane. Jeśli developer przejdzie do innego zespołu, admin po prostu cofa mu granta do External Location wewnątrz Databricks. Bazowa konfiguracja cloud IAM pozostaje całkowicie nietknięta. Oto kluczowy wniosek. External Locations oddzielają bezpieczeństwo infrastruktury chmurowej od codziennego zarządzania dostępem do danych. Trzymając role IAM z dala od kodu użytkownika i przypinając je do konkretnych ścieżek, gwarantujesz, że każdy data request jest audytowany, bezpieczny i ograniczony wyłącznie do danych, które zamierzasz udostępnić. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 7 z 15. Inżynierowie danych spędzają niewiarygodnie dużo czasu, próbując po prostu utrzymać przy życiu kruche skrypty do ingestion z API. Gdy endpoint zmienia logikę pagination albo rate limit spada, twój pipeline się wywala, a ty spędzasz popołudnie na debugowaniu JSON-a zamiast budować modele danych. Rozwiązaniem tego konkretnego bólu głowy jest Lakeflow Connect. Zanim przyjrzymy się, jak to działa, wyjaśnijmy częste zamieszanie z nazewnictwem. Databricks ma Lakeflow Jobs i Lakeflow Connect. Lakeflow Jobs zajmuje się orchestration, co oznacza, że uruchamia taski w określonej kolejności. Lakeflow Connect to stricte ingestion. To mechanizm do ściągania surowych danych z systemów zewnętrznych do twojego środowiska Databricks. W swojej istocie Lakeflow Connect dostarcza Managed Connectors. Są to natywne, dedykowane integracje dla aplikacji enterprise i baz danych. Zazwyczaj, gdy musisz zaciągnąć dane z zewnętrznych systemów, piszesz customowy kod w Pythonie. Ten kod musi zarządzać authentication, obsługiwać retries, gdy serwer zerwie połączenie, śledzić, które rekordy trafiły już do ingestion, i parsować złożoną pagination. Managed Connectors eliminują całą tę warstwę customowej infrastruktury. Databricks bierze na siebie warstwę compute, interakcje z API oraz śledzenie stanu wymagane do incremental reads. Ponieważ Lakeflow Connect działa na serverless compute, nie musisz konfigurować ani zarządzać klastrami tylko po to, żeby zaciągać dane. Usługa skaluje się automatycznie w zależności od wolumenu przychodzących danych. Integruje się też bezpośrednio z Unity Catalog, co oznacza, że dane z ingestion są natychmiast objęte governance i dostępne do query. Weźmy pod uwagę standardowe wymaganie. Twój zespół marketingu potrzebuje aktualnych danych z Salesforce w waszym lakehouse. Jeśli zbudujesz to od zera, możesz spędzić tydzień na pisaniu customowego skryptu, który robi query do API Salesforce. Musisz napisać logikę, żeby zmieścić się w restrykcyjnych limitach API, zarządzać odświeżaniem tokenów i mergować update'y do istniejących tabel Delta bez duplikowania rekordów. Dzięki Managed Connector w Lakeflow Connect całkowicie omijasz pisanie customowego kodu. Podajesz credentials do połączenia, wybierasz konkretne obiekty Salesforce, które chcesz śledzić, i ustawiasz docelowy catalog oraz schema. Setup zajmuje kilka minut. Databricks przejmuje wykonanie. Pobiera początkowy, historyczny snapshot danych, a następnie przechodzi do ciągłego przechwytywania incremental changes na bieżąco. I tu jest kluczowa sprawa. Przenosząc workload związany z ingestion na Managed Connector, przestajesz utrzymywać skrypty do pollingu. Gdy specyfikacja zewnętrznego API się zmienia, Databricks aktualizuje connector w tle. Twój pipeline po prostu działa dalej. Dzięki temu możesz skupić się na właściwej logice biznesowej, takiej jak transformowanie surowych danych w tabele agregatów albo trenowanie modeli machine learning, zamiast niańczyć zepsuty skrypt do ekstrakcji. Prawdziwą wartością Lakeflow Connect jest nie tylko szybki setup, ale też permanentne usunięcie customowego kodu do ingestion z twojego backlogu utrzymaniowego. Jeśli chcesz pomóc nam tworzyć ten podcast, możesz wyszukać DevStoriesEU na Patreon i wesprzeć nas tam. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 8 z 15. Masz złożony pipeline ETL, w którym jedna tabela aktualizuje się co godzinę, inna w sposób ciągły, a orkiestracja zależności wymaga setek linijek kodu do state-managementu. A co, gdybyś mógł po prostu zadeklarować docelowe tabele i pozwolić silnikowi zbudować infrastrukturę, która utrzyma je w aktualności? To jest właśnie założenie zautomatyzowanego ETL z wykorzystaniem Declarative Pipelines. W tradycyjnym, imperatywnym pipelinie mówisz systemowi dokładnie, jak ma wykonać swoje zadanie. Piszesz kod do zarządzania checkpointami, obsługi retry'ów, mapowania zależności i provisionowania klastrów. Deklaratywne pipeline'y odwracają ten model. Po prostu określasz, jak powinna wyglądać docelowa tabela, zazwyczaj za pomocą standardowego zapytania SQL lub funkcji w Pythonie. Silnik pod spodem buduje graf wykonania, zarządza infrastrukturą i automatycznie obsługuje przejścia stanów. Aby to działało, Databricks opiera się na dwóch konkretnych typach tabel. Częstym błędem jest traktowanie ich jako zamienników. Wcale nimi nie są. Musisz wyraźnie oddzielić swoje dane eventowe typu append-only od złożonych agregacji. Pierwszy typ to Streaming Table. Streaming Tables są zaprojektowane ściśle do przyrostowego przetwarzania typu append-only. Czytają dane ze źródła w sposób ciągły lub w batchach, przetwarzają tylko nowe rekordy i appendują je do celu. Wyobraź sobie przetwarzanie ogromnego streamu kliknięć ze strony, pochodzących z Kafki. Piszesz zapytanie, żeby zasilić Streaming Table z tego topicu na Kafce. Nie piszesz kodu do śledzenia offsetów ani zapamiętywania, które wiadomości zostały już przeczytane. Pipeline wewnętrznie utrzymuje stan, gwarantując, że każde kliknięcie zostanie przetworzone dokładnie raz, nawet jeśli system się zrestartuje. A teraz druga część tej układanki. Kiedy masz już bezpiecznie zapisane surowe eventy, zazwyczaj musisz je przetransformować. Tutaj do gry wchodzą Materialized Views. Podczas gdy Streaming Tables obsługują początkowy ingest nowych danych, Materialized Views są stworzone do złożonych agregacji, joinów i rekordów, które z czasem są aktualizowane lub usuwane. Wracając do naszych kliknięć na stronie, potrzebujesz codziennego dashboardu dla zarządu, pokazującego łączną liczbę kliknięć pogrupowanych według regionu. Definiujesz Materialized View, który robi selecta z twojej Streaming Table i odpala agregację. Kiedy pipeline rusza, silnik ewaluuje Materialized View. Określa najwydajniejszy sposób na zaktualizowanie tego widoku. Jeśli może policzyć zmiany przyrostowo, to tak zrobi. Jeśli konieczny jest pełny recompute, ogarnie to automatycznie. Nigdy nie piszesz logiki dyktującej, kiedy zrobić refresh albo jak zmergować nowe agregacje. I tu jest kluczowa sprawa. Ponieważ definiujesz deklaratywnie zarówno Streaming Tables, jak i Materialized Views, silnik Databricks rozumie całe lineage twoich danych. Wie, że Materialized View zależy od Streaming Table. Łączy je w jeden zunifikowany graf pipeline'u. Jeśli compute node padnie w trakcie przetwarzania, pipeline polega na tym grafie, żeby zapauzować, zrobić retry i wznowić działanie bez duplikowania rekordów czy uszkodzenia końcowego dashboardu. Twój codebase nie jest już zaśmiecony operacyjnym rusztowaniem. Zawiera tylko czystą logikę biznesową, definiującą jak dane płyną od źródła do celu. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 9 z 15. Jeśli twoje nocne przetwarzanie danych opiera się na chainie niezależnych harmonogramów cron, w zasadzie liczysz na to, że poprzedni krok zakończył się na czas. Lecisz w ciemno. Aby zapobiec silent failures i zagwarantować kolejność wykonywania, potrzebujesz Master Orchestration z Lakeflow Jobs. Na początek krótkie rozróżnienie. Lakeflow Pipelines obsługują zależności danych na poziomie tabeli. Lakeflow Jobs, na których się teraz skupiamy, orkiestrują taski na poziomie makro. Wyobraź sobie pipelines przenoszące dane wewnątrz hurtowni, podczas gdy jobs łączą notebooki, skrypty Pythona i modele machine learning w większy workflow. Job w Databricks to nadrzędny kontener dla twojej orkiestracji. W tym kontenerze definiujesz wiele tasków. Task to pojedyncza, izolowana jednostka pracy. Może to być wykonanie notebooka Databricks, zsubmitowanie aplikacji Spark, uruchomienie projektu dbt lub odpalenie zapytania SQL. Łącząc te taski ze sobą, budujesz graf wykonania, w którym jeden task rozpoczyna się dopiero, gdy jego konkretne zależności zakończą się sukcesem. Przejdźmy przez praktyczny scenariusz, aby zobaczyć, jak control flow dba o niezawodność. Masz codzienny proces, który ingestuje surowe dane, sprawdza ich jakość, transformuje je i alertuje zespół, jeśli coś pójdzie nie tak. Zaczynasz od zdefiniowania taska ingestii. Następnie podpinasz task data quality, który uruchamia się dokładnie po zakończeniu ingestii. I tu jest kluczowa kwestia. Zamiast pisać customowy error handling w kodzie Pythona, żeby decydować, co stanie się dalej, używasz natywnego job control flow. Dodajesz task z warunkiem if-else bezpośrednio po sprawdzeniu jakości. Warunek ewaluuje zmienną zwróconą przez twój data check task. Jeśli dane są czyste, job idzie w if-branch i triggeruje twój downstreamowy task transformacji. Jeśli dane są uszkodzone, job idzie w else-branch i triggeruje task webhooka, który pinguje kanał na Slacku. Zarządzasz również stanem za pomocą warunków taska run-if. Możesz skonfigurować task alertujący tak, aby wykonał się tylko wtedy, gdy poprzedni task całkowicie sfailuje, podczas gdy reszta pipeline'u bezpiecznie się zatrzyma. Zapobiega to klasycznej kaskadzie silent failures, w której zepsuty krok ingestii po cichu triggeruje model machine learning do trenowania na całkowicie pustych tabelach. Aby zainicjować ten workflow, dodajesz trigger. Jobs mogą działać on-demand, w tradycyjnych zaplanowanych interwałach lub w sposób ciągły. Mogą się również wykonywać na podstawie eventu, takiego jak pojawienie się nowego pliku w zewnętrznym buckecie cloud storage. Po ztriggerowaniu, Databricks zapewnia wbudowane observability. Nie musisz zgadywać, gdzie wystąpił błąd. Platforma rejestruje pełną historię runów z matrix view, pokazując dokładnie, który task zakończył się sukcesem, który utknął i ile czasu zajął każdy krok. Możesz skonfigurować powiadomienia na poziomie joba lub taska, aby wysyłać automatyczne maile lub webhooki w momencie zmiany execution state. Prawdziwą wartością tego modelu orkiestracji jest przeniesienie failure handling z twoich pojedynczych skryptów do infrastruktury platformy, co gwarantuje, że twój system dokładnie wie, jak routować wykonanie, gdy coś nieuchronnie się zepsuje. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 10 z 15. Przenoszenie danych z twojego data lake tylko po to, żeby twój zespół Business Intelligence mógł na nich uruchamiać queries, jest powolne, drogie i całkowicie zbędne. W efekcie utrzymujesz niestabilne pipelines tylko po to, żeby kopiować dane z jednego systemu do drugiego, co wprowadza opóźnienia i duplikuje koszty storage'u. Właśnie ten problem rozwiązuje Databricks SQL. Panuje powszechne, błędne przekonanie, że Databricks jest przeznaczony wyłącznie dla data engineers i data scientists piszących w Pythonie lub Scali. Databricks SQL obala ten mit. To dedykowany workspace zbudowany w całości dla specjalistów od SQL-a. Wyobraź sobie zespół Business Intelligence, który migruje z legacy data warehouse. Historycznie, musieli czekać, aż inżynierowie odpalą nocne extraction jobs, żeby załadować dane z data lake do data warehouse. Dopiero wtedy mogli zacząć budować raporty. Databricks SQL eliminuje całą tę warstwę ekstrakcji. Pozwala analitykom uruchamiać standardowe queries ANSI-SQL bezpośrednio na data lake. Zyskujesz ogromną skalę otwartego lake storage, ale wchodzisz z nim w interakcję używając znajomego, szybkiego interfejsu tradycyjnego relational warehouse. Silnikiem napędzającym te queries jest Serverless SQL Warehouse. SQL warehouse to po prostu zasób compute skonfigurowany specjalnie pod SQL workloads. W starszych architekturach musiałeś ręcznie provisionować klastry, konfigurować reguły skalowania i czekać kilka minut na zbootowanie virtual machines przed uruchomieniem query. I tu pojawia się kluczowa kwestia. Ponieważ te SQL warehouses są serverless, warstwa compute startuje niemal natychmiast. Skaluje się automatycznie, gdy twoi analitycy odpalają ciężkie concurrent workloads, i sama się terminuje, gdy queries się zakończą. Zarządzanie infrastrukturą jest całkowicie wyabstrahowane, pozwalając analitykom skupić się wyłącznie na ich danych. Aby pisać i wykonywać te queries, platforma udostępnia wbudowany SQL editor. To główny interfejs do eksploracji danych. Wewnątrz edytora użytkownicy mogą pisać standardowy SQL, przeglądać data catalogs, analizować table schemas i sprawdzać historię wykonania. Kiedy query zwraca dane, analityk nie musi ich eksportować, żeby je zrozumieć. Mogą budować wizualizacje bezpośrednio w edytorze i układać je w customowe dashboardy, które aktualizują się automatycznie. Platforma zawiera również funkcję alertów. Analitycy mogą napisać query, które sprawdza konkretną metrykę, i skonfigurować system tak, żeby wysyłał maila lub web notification, jeśli ta metryka przekroczy zdefiniowany próg. Wiele organizacji ma już ugruntowane narzędzia do wizualizacji. Databricks SQL integruje się bezpośrednio ze standardowymi narzędziami third-party, takimi jak Power BI i Tableau. Te zewnętrzne aplikacje łączą się z Serverless SQL Warehouse i traktują data lake dokładnie tak, jakby było wysokowydajną bazą danych. W tej zmianie chodzi przede wszystkim o bliskość do twoich danych. Przenosząc compute klasy warehouse i standardowy SQL bezpośrednio do data lake, przestajesz kopiować dane i zaczynasz analizować swoje single source of truth w momencie, gdy tylko się tam znajdą. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 11 z 15. Jeśli trzy różne działy budują trzy różne dashboardy do śledzenia przychodów i przynoszą trzy różne liczby na spotkanie zarządu, to nie masz problemu z data pipeline'em. Masz problem z warstwą semantyczną. Rozwiązaniem jest ustanowienie warstwy semantycznej jako single source of truth, a w Databricks SQL zrobisz to za pomocą Metric Views. Surowe dane rzadko są ustrukturyzowane tak, jak myślą użytkownicy biznesowi. Tabele w bazie danych zawierają niezrozumiałe nazwy kolumn, skomplikowane joiny i surowe logi transakcji. Warstwa semantyczna wypełnia tę lukę, tłumacząc dane źródłowe na znane pojęcia biznesowe. Spójrzmy na klasyczny scenariusz, w którym to się sypie. Twój zespół marketingu i zespół finansów raportują metrykę Monthly Active Users. Marketing pisze query w swoim dashboardzie, które zlicza każdego, kto otworzył aplikację. Finanse piszą inne query w osobnym narzędziu, które zlicza tylko tych użytkowników, którzy sfinalizowali transakcję. Oba zespoły nazywają swoją metrykę Monthly Active Users. Kiedy liczby się nie zgadzają, zaufanie organizacji do danych drastycznie spada. Zdefiniowanie Monthly Active Users jako Metric View w Unity Catalog rozwiązuje ten problem na zawsze. Aby zrozumieć dlaczego, musimy wyjaśnić, czym właściwie jest ta funkcja. Metric View to nie to samo, co standardowy SQL View. Standardowy SQL View po prostu zapisuje query, które zwraca surowe wiersze i kolumny, pozostawiając użytkownikowi końcowemu decyzję o tym, jak później zsumować, uśrednić lub pogrupować te dane. Metric View jest znacznie bardziej rygorystyczny. Wymusza konkretne obliczenia agregacji i wymiarowość bezpośrednio na poziomie catalogu. Tworząc Metric View, ustalasz na sztywno dokładną logikę biznesową. Definiujesz miarę, taką jak distinct count dla ID użytkowników na podstawie określonych kryteriów transakcji. Definiujesz również dopuszczalne wymiary. Oznacza to, że jawnie narzucasz, że ta metryka może być dzielona tylko po konkretnych atrybutach, takich jak data transakcji, region użytkownika czy typ urządzenia. I tu leży sedno. Kiedy ten Metric View zostanie opublikowany w Unity Catalog, staje się jedyną, autorytatywną definicją Monthly Active Users dla całej firmy. Kiedy analitycy łączą się z Databricks SQL, nie piszą własnej logiki do agregacji danych. Nie joinują tabel ani nie piszą klauzul WHERE, żeby filtrować aktywne stany. Po prostu odpytują Metric View. To całkowicie oddziela definicję metryki od warstwy prezentacji. Nie ma znaczenia, czy marketing używa Tableau, finanse Power BI, a zespół produktowy natywnych dashboardów Databricks. Narzędzie Business Intelligence po prostu prosi o metrykę, a Databricks wykonuje predefiniowane obliczenia po stronie serwera. Ponieważ logika żyje centralnie w Unity Catalog, to niemożliwe, żeby różne działy przypadkowo wymyśliły własną matematykę. Wszystkie pobierają dokładnie tę samą liczbę, zapewniając idealną spójność w całej organizacji. Prawdziwą siłą warstwy semantycznej nie jest wydajność techniczna; to wyciągnięcie logiki biznesowej z rozłącznych narzędzi downstreamowych i wbudowanie jej bezpośrednio w fundament samej platformy danych. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 12 z 15. A co, gdyby twój dyrektor sprzedaży mógł po prostu napisać do twojego data warehouse, żeby uzyskać natychmiastowe insighty biznesowe, bez konieczności zakładania ticketu do zespołu danych? Ad-hocowe requesty o dane nieustannie zakłócają inżynieryjny workflow, a użytkownicy biznesowi nienawidzą czekać całymi dniami na proste query. Rozwiązaniem tego bottlenecku jest feature Databricks o nazwie Genie Spaces, który jest częścią ich szerszej oferty AI/BI. AI/BI to produkt business intelligence zbudowany na tak zwanym compound AI system. Został zaprojektowany tak, aby rozumieć specyficzną semantykę twoich danych. Genie Spaces służą jako interfejs konwersacyjny dla tego systemu. Genie Space wygląda i działa jak standardowa aplikacja typu chat, ale jest podpięta bezpośrednio pod twój data warehouse. Użytkownicy biznesowi wpisują pytania w plain English, a Genie odpowiada, zwracając rzeczywiste dane, wizualizacje i odpowiedzi. Kiedy ludzie słyszą o AI robiącym query do danych, od razu martwią się o halucynacje. Zakładają, że model będzie zgadywał nazwy kolumn, wymyślał metryki albo z pełnym przekonaniem zwracał błędne odpowiedzi. Genie zapobiega temu, opierając się wyłącznie na governed metadata przechowywanych w twoim Unity Catalog. Nie wysyła w ciemno promptu do generycznego modelu językowego. AI jest osadzone w twoim rzeczywistym schema, typach danych, relacjach foreign key i predefiniowanych metrykach, które ustalił twój zespół. Żeby to zadziałało, analityk najpierw tworzy i konfiguruje Genie Space. Wybiera odpowiednie datasety z Unity Catalog i dostarcza zestaw instrukcji. Może dodać przykładowe queries, zdefiniować specyficzną terminologię biznesową i wyjaśnić niejednoznaczne pojęcia. Na przykład, może powiedzieć systemowi, że kiedy użytkownik mówi „aktywny klient”, oznacza to konkretnie klienta, który dokonał zakupu w ciągu ostatnich dziewięćdziesięciu dni. Ten początkowy setup zawęża scope AI do dobrze zdefiniowanej domeny. Kiedy pada pytanie, system orkiestruje wiele kroków. Odczytuje prompt w języku naturalnym i sprawdza dostarczony kontekst. Dopasowuje intencję użytkownika do konkretnych tabel i kolumn w catalogu. Następnie generuje precyzyjne query SQL, uruchamia to query na compute engine Databricks SQL i formatuje wyniki. Wyobraź sobie nietechnicznego menedżera sprzedaży, który używa przygotowanego Genie Space. Wpisuje: „Pokaż sprzedaż w Europie według produktów za ostatni kwartał”. System parsuje request na podstawie swojego treningu. Rozpoznaje „Europę” jako region dimension, lokalizuje tabele produktów i tłumaczy „ostatni kwartał” na precyzyjny filtr daty. W ciągu kilku sekund AI generuje SQL, wykonuje go i zwraca interaktywny wykres pokazujący rozbicie. Jeśli menedżer odpisze: „Teraz wyklucz Niemcy”, Genie modyfikuje underlying query i natychmiast aktualizuje wykres, zachowując kontekst konwersacji. Ten workflow fundamentalnie zmienia sposób obsługi ad-hocowych requestów. Inżynierowie danych i analitycy spędzają ogromną część tygodnia na pisaniu jednorazowych queries SQL dla stakeholderów. Przeniesienie tej eksploracji do Genie Spaces daje biznesowym stakeholderom natychmiastowe odpowiedzi, jednocześnie zwalniając czas inżynierów na złożone taski. Co więcej, cały proces pozostaje w pełni governed. Genie ściśle przestrzega wszystkich row and column-level access controls zdefiniowanych w Unity Catalog. Jeśli użytkownik zadający pytanie nie ma uprawnień, żeby zobaczyć wrażliwe dane finansowe, AI po prostu nie zrobi do nich query. Oto kluczowy insight. Skuteczność konwersacyjnej eksploracji danych zależy od jakości twojego underlying data model i metadata, a nie tylko od inteligencji modelu językowego. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 13 z 15. Trenowanie modelu machine learning to ta fajna część, ale jego deploy jako wysoce dostępne, bezpieczne REST API to moment, w którym większość projektów data science po prostu umiera. Przejście od eksperymentu w notebooku do gotowego na produkcję endpointu wymaga skonfigurowania skalowania, load balancingu i ścisłego governance. Żeby to rozwiązać, używasz Mosaic AI Model Serving. Ta funkcja zapewnia zunifikowany interfejs do deployu, governance'u i odpytywania modeli AI. Częstym błędem jest myślenie, że Databricks Model Serving służy tylko do modeli, które trenujesz samodzielnie wewnątrz Databricks. To nieprawda. Tak naprawdę działa to jako centralny AI Gateway. Obsługuje trzy różne typy modeli: customowe modele, foundation models i zewnętrzne modele. Po pierwsze, customowe modele. To modele, które budujesz, logujesz w MLflow i rejestrujesz w Unity Catalog. Model Serving stawia serverlessowy kontener, ładuje zależności twojego modelu i wystawia model jako REST API. Nie zarządzasz infrastrukturą. Skaluje się w górę przy skokach ruchu i skaluje w dół do zera, kiedy jest idle. Po drugie, foundation models hostowane przez Databricks. Są to duże modele open-source, które Databricks hostuje na zoptymalizowanym compute. Dostajesz natychmiastowy dostęp do najnowocześniejszych architektur bez martwienia się o prowizjonowanie GPU. Po trzecie, zewnętrzne modele. To tutaj konfigurujesz endpointy, które wskazują na usługi firm trzecich. Po co routować zewnętrzny ruch przez Databricks, zamiast uderzać bezpośrednio do zewnętrznych providerów? Pomyśl o governance i kontroli kosztów. Załóżmy, że twoja firma chce użyć GPT-4 do wewnętrznej aplikacji. Jeśli każdy developer zahardkoduje API key w swoim skrypcie, tracisz widoczność. Nie możesz ściśle monitorować kosztów, zarządzać rate limitami ani nakładać filtrów, żeby powstrzymać pracowników przed wysyłaniem wrażliwych danych klientów do zewnętrznego providera. Routując wszystkie requesty przez Mosaic AI Model Serving, przepuszczasz ten ruch przez jeden, bezpieczny gateway. Zarządzasz jednym zestawem credentials. Nakładasz kontrolę dostępu przez Unity Catalog, dyktując dokładnie, kto lub co może odpytywać model. Dostajesz też scentralizowane śledzenie użycia, błędów i latency. Flow logiki jest prosty. Definiujesz serving endpoint w Databricks. Dla customowego modelu kierujesz endpoint na zarejestrowany model w MLflow i definiujesz rozmiar compute'a oraz limity skalowania. Databricks automatycznie ogarnia konteneryzację. Dla zewnętrznego modelu podajesz nazwę zewnętrznego providera i bezpiecznie przechowany API key. Kiedy endpoint jest aktywny, twoje aplikacje downstreamowe wysyłają standardowy payload JSON przez request HTTP na URL endpointu. Odpowiedź wraca w spójnym formacie, niezależnie od tego, czy model działa na serverlessowym compute w Databricks, czy siedzi w zewnętrznym data center. I tu jest kluczowa sprawa. Mosaic AI Model Serving usuwa tarcie przy deployu, jednocześnie wymuszając bezpieczeństwo. Standaryzuje twoją warstwę aplikacji, więc twój kod kliencki gada tylko z jednym endpointem Databricks, całkowicie wyabstrahowanym od tego, gdzie i jak hostowany jest model pod spodem. Tak przy okazji, jeśli chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 14 z 15. Masz dziesięć tysięcy surowych logów z supportu w tabeli w bazie danych, a biznes potrzebuje ich podsumowania i skategoryzowania według sentymentu do końca dnia. Zazwyczaj wyciągnięcie tego rodzaju informacji wymaga skomplikowanego pipeline'u w Pythonie, ostrożnego zarządzania kluczami API i własnej logiki batchowania, żeby przekazać tekst do Large Language Model. A co, gdybyś mógł wykonać cały ten workload za pomocą prostej komendy w bazie danych? To dokładnie ten problem, który rozwiązują AI Functions, osadzające modele LLM bezpośrednio w twoich zapytaniach SQL. AI Functions zasypują przepaść między najnowocześniejszym Generative AI a codzienną analityką danych. Biorą możliwości, które zazwyczaj wymagają specjalistycznej inżynierii Machine Learning, i oddają je w ręce każdego, kto potrafi pisać w SQL-u. Zamiast budować osobną infrastrukturę do ekstrakcji danych, wysyłania ich do modelu i zapisywania predykcji z powrotem, AI Functions przynoszą model bezpośrednio tam, gdzie te dane już żyją. Głównym narzędziem do tego jest wbudowana komenda o nazwie AI query. Używasz jej dokładnie tak samo, jak standardowej funkcji do przetwarzania tekstu wewnątrz instrukcji select. Podajesz nazwę endpointu modelu, którego chcesz użyć, a następnie przekazujesz prompt. Wracając do tych dziesięciu tysięcy logów z supportu, twój workflow staje się banalnie prosty. Piszesz zapytanie, robiąc select na customer ID i tekst logu. Następnie dodajesz nową kolumnę, używając funkcji AI query. Twój prompt każe modelowi przeczytać tekst, wyciągnąć główną skargę i określić, czy sentyment jest pozytywny, neutralny, czy negatywny. Do tego promptu przekazujesz kolumnę zawierającą surowy tekst logu. Kiedy odpalasz zapytanie, silnik bazy danych automatycznie dystrybuuje to żądanie. Przetwarza każdy pojedynczy wiersz przez wskazany Large Language Model. Model ocenia tekst i zwraca podsumowanie oraz sentyment. Ponieważ wszystko to dzieje się w SQL-u, output wraca w postaci standardowych, ustrukturyzowanych kolumn. Możesz natychmiast przefiltrować wyniki, żeby pokazać tylko negatywny sentyment, zrobić join tych wyników z tabelą rozliczeń klientów i zagregować dane, żeby dowiedzieć się, który produkt powoduje najwięcej frustracji. Oto kluczowa kwestia. Mógłbyś założyć, że danie analitykom danych dostępu do Large Language Models oznacza dystrybucję wrażliwych kluczy API po całej organizacji. Wcale tak nie jest. AI Functions są ściśle zintegrowane z Databricks Model Serving. Właściwe połączenia z zewnętrznymi modelami, albo modelami open-source typu self-hosted, są konfigurowane przez administratorów na poziomie platformy. Analityk danych nigdy nie widzi klucza API, tokena ani secreta. W swoim zapytaniu odwołuje się jedynie do wstępnie skonfigurowanej nazwy endpointu. Cała operacja pozostaje całkowicie bezpieczna. Każde zapytanie jest logowane, a wszystkie kontrole dostępu nałożone na dane i modele są ściśle egzekwowane przez framework governance platformy. Usuwając narzut infrastrukturalny i zarządzanie credentialsami, zmieniasz naturę eksploracji danych. Przekształcasz skomplikowaną analizę nieustrukturyzowanego tekstu w prostą operację filtrowania, natychmiast podnosząc analityczną moc całego twojego zespołu. Dzięki za wysłuchanie. Trzymajcie się wszyscy.

Cześć, tu Alex z DEV STORIES DOT EU. Databricks, odcinek 15 z 15. Twój standardowy chatbot jest uprzejmy, merytoryczny i całkowicie pasywny. Może ci podpowiedzieć, jak naprawić zepsuty pipeline na podstawie manuala, ale tak naprawdę nie naprawi tego pipeline'u za ciebie. Przejście od AI, które tylko z tobą rozmawia, do AI, które aktywnie wykonuje taski, wymaga fundamentalnej zmiany w architekturze. Tą zmianą jest AI Agent Framework. Od razu wyjaśnijmy pewne powszechne nieporozumienie. Ludzie często mylą proste aplikacje Retrieval-Augmented Generation z prawdziwymi agentami. Aplikacja RAG to w zasadzie wyszukiwarka z nałożonym na nią modelem językowym. Pobiera dokumenty i je podsumowuje. Ona tylko czyta. Prawdziwy agent AI ma narzędzia. Potrafi pisać. Może odpalać zapytania SQL, triggerować joby i wywoływać zewnętrzne API. Zmienia stan twoich systemów. Databricks Agent Framework zapewnia infrastrukturę do budowania, ewaluacji i deployowania tych autonomicznych agentów w bezpieczny sposób wewnątrz Lakehouse'a. Głównym mechanizmem jest tutaj tool calling w połączeniu z multi-step reasoning. Zamiast po prostu generować odpowiedź w jednym przebiegu, model językowy działa jak reasoning engine. Dajesz mu cel i zestaw narzędzi, które są w zasadzie zdefiniowanymi przez ciebie funkcjami. Agent decyduje, którego narzędzia użyć, czeka na wynik, a następnie decyduje, co zrobić dalej. Pomyśl o agencie zaprojektowanym do monitorowania data pipeline'ów. Kiedy wystąpi błąd, agent nie siedzi bezczynnie, czekając na prompt od użytkownika. Framework pozwala mu striggerować workflow. Najpierw agent potrzebuje kontekstu. Używa customowego narzędzia, które mu dostarczyłeś, żeby odpalić zapytanie SQL na twoich logach systemowych w Databricks. Framework wykonuje to zapytanie i przekazuje wynik z powrotem do agenta. I tu leży sedno. Agent ewaluuje te logi, identyfikuje root cause awarii, a następnie przechodzi do kolejnego kroku. Zdaje sobie sprawę, że zespół inżynierów musi o tym wiedzieć. Wybiera więc kolejne narzędzie – integrację API z twoim firmowym czatem. Wykonuje tool call, żeby przygotować i wysłać wiadomość ze szczegółowym opisem błędu i proponowanym fixem. To jest multi-step reasoning w akcji. Agent zaplanował sekwencję, wykonał kod, zaobserwował wynik i przekazał go dalej – wszystko to w pełni autonomicznie. Danie modelowi językowemu możliwości odpalania zapytań i triggerowania API to ogromne ryzyko bezpieczeństwa, jeśli zostanie to źle zrobione. Właśnie dlatego podejście Databricks ściśle łączy Agent Framework z Unity Catalog. Kiedy deployujesz agenta za pomocą Databricks Model Serving, nie dajesz mu całkowitego dostępu do swojej infrastruktury. Rejestrujesz swoje narzędzia jako konkretne funkcje w Unity Catalog. Unity Catalog wymusza ścisłe reguły governance nad tym, co te funkcje mogą robić. Jeśli dasz agentowi narzędzie do odpytywania tabel z logami, Unity Catalog upewni się, że może on czytać tylko te konkretne tabele. Jeśli model językowy zacznie halucynować i spróbuje użyć narzędzia SQL, żeby zdropować produkcyjną bazę danych, framework go zatrzyma, ponieważ pod spodem funkcja nie ma do tego uprawnień. Agent jest ściśle ograniczony przez reguły governance twojego Lakehouse'a. Ta możliwość zmienia Lakehouse z pasywnej warstwy storage'u w aktywne, zautomatyzowane środowisko. Kończąc tę serię, zachęcam cię do sprawdzenia oficjalnej dokumentacji i samodzielnego zbudowania prostego agenta wykorzystującego tool calling. Jeśli chcesz zaproponować tematy do naszej kolejnej serii, wpadnij na devstories dot eu. Przejście od chatbotów do agentów to decydująca zmiana w sposobie, w jaki budujemy dzisiaj aplikacje AI. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórzcie dalej!