Szymon Warda: Cześć. Słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io/36. I dzisiaj odcinek trochę specjalny, bo zaprosiliśmy Pawła Potasińskiego, żeby porozmawiać i zrobić przegląd sobie analityki, rozwiązań od analityki dla ludzi od aplikacji. Pawła znam już bardzo od dawna. Dla mnie to taki trochę pradziadek analityki w naszym kraju, udziela się w community i innych rzeczach. Ostatnio zmienił rolę i pojawił się w Microsofcie. I witamy Cię Pawle. Jakbyś mógł coś dodać, rozszerzyć. Co teraz robisz? Czym się zajmujesz?

Paweł Potasiński Bardzo przede wszystkim dziękuję, że mnie zaprosiliście do super pomysłu podcastu Patoarchitekci. Jest mi niezmiernie miło. Myślę, że to było jedno z moich marzeń trochę wystąpić u Was, więc fajnie. I co mogę dodać? Tak jak wspomniałeś, jestem, świeżutko powróciłem do Microsoftu. Mija właśnie pierwszy miesiąc mojej pracy. Zajmuję się tam, można powiedzieć marketingiem Azure’a, ale to nie do końca prawda. Pewnie będzie więcej czasu na to, żeby o tym opowiedzieć. Może jeszcze kiedyś przy okazji. I tak jak wspomniałeś, udzielam się w społeczności. W zasadzie mój początek to są wczesne lata 2000 z haczykiem. W 2007 założyłem polską grupę SQL Server. Wtedy jeszcze nikt o cloudzie poważnie nie myślał, a potem ewolucja przykryła nas radośnie chmurami. I dzisiaj w zasadzie 100% mojego czasu to jest focus na rozwiązaniach chmurowych. Trochę uprzedzając pewnie też dyskusje, w którą stronę będziemy zmierzać.

Łukasz Kałużny: Dobra, Pawle, jako że zaczynamy zwykle linkami, jak już też miałeś okazję słuchać. Czy coś wybrałeś, żeby podzielić się ze słuchaczami? Może być ciekawa książka, link, artykuł.

Paweł Potasiński Tak, myślę, że pozostając w tym temacie analityki i danych, dobrym linkiem dzisiaj jest link do blogu Jamesa Serry. James jest architektem w Microsoft. Natomiast on pisze, myślę, że dość mądre i takie powiedziałbym bardzo niezależne teksty związane z głównie tematyką analityki i hurtowniami danych, data lake’ami. Więc jeśli ktoś rozgląda się za takim powiedzmy kompleksowym, mądrym podejściem do tematu i ciekawymi dyskusjami, myślę, że to jest to nawet o wiele ważniejsze niż same teksty Jamesa, to zapraszam na blok Jamesa Serry. Więc adresik nie jest bardzo skomplikowany. Tak że myślę, że tam sobie wszyscy go sczytają z opisu i linków do naszego podcastu.

Szymon Warda: Ja mogę potwierdzić jako człowiek nie od analityki, że faktycznie bardzo dobry wpis przeglądowy od góry do dołu można powiedzieć, ale długi.

Łukasz Kałużny: Tak, ten ostatni o data meshu był dość taki szeroki od niego.

Paweł Potasiński Przede wszystkim w to, że wpisy Jamesa są wartościowe to najlepiej udowadniają nazwiska, które się często pojawiają w tych dyskusjach. Jak sobie spojrzymy, to pojawiają się prekursorzy niektórych kierunków. Na przykład ostatnio głos zabrał chociażby Dan Linstedt, znany ze stworzenia konceptu Data Vault, więc warto to czytać.

Szymon Warda: Fajnie. Łukaszu, co u Ciebie?

Łukasz Kałużny: A ja niestety też w kwestii Microsoftu, ale mi się trafiło, ale niech już będzie. Wyszedł Dapr, czyli runtime Microsoftu do tworzenia, ja to określam bardzo ładnie, korporacyjnych mikroserwisów. O tak. I po 14 release’ach, które były wydawane od inicjalnego projektu w 2019, Dapr doleciał teraz do fazy GA. I to, co jest, to jest po prostu framework runtime, który daje nam warstwę abstrakcji nad usługami i rzeczami, które chcemy odpalać tak naprawdę tworząc mikroserwisy, zaczynając od całych Secret Store, czyli miejsca do trzymania poświadczeń, komunikacji mTLS-owej, jakichś acli, State Store w postaci SQL i NosQL i warstwy abstrakcji nad service discovery czy nad różnego rodzaju kolejkami. Więc to ma w teorii nam uprościć tworzenie, ja zawsze będę mówił na to, właśnie takich enterprise’owych mikroserwisów. I co ważne, to nie jest zamknięte wokół .Neta, ale ma tak naprawdę pod spodem, możemy się z tym runtimem komunikować przez gRPC albo HTTP. Jest tam, wspiera to dla Javy, .Net, Pythona, Golanga, JavaScriptu, więc tego jest naprawdę sporo. I dużo rozwiązań on premowych jak i cloudowych różnych dostawców jest pod spodem jako taki model plugabel, czyli Kafki, rabbity z on prema mogą być, czy Google’owy Pub/Sub, AWS-owe kolejki czy microsoftowe bazy. To wszystko można spiąć w jakąś jedną logiczną całość. Więc dość ciekawie buduje taką platformę do odpalania, taką nakładkę do odpalania mikroserwisów.

Szymon Warda: Mnie bardzo cieszy to, że Dapr się dalej rozwija, że to nie jest projekt, który umarł i faktycznie tam się dzieją rzeczy. To jest też dobre. Dobry news.

Łukasz Kałużny: Zobaczymy, sporo się dzieje. Patrzyłem właśnie dzisiaj, 11 tysięcy gwiazdek na GitHubie, sporo kontrybutorów w ogóle niezależnych od Microsoftu, więc jest takie światełko w tunelu, że będzie to rozwijane dalej i będzie zjadliwe. Zobaczymy, czy zostanie oddany do CNCFU czy nie na koniec dnia. A Ty Szymonie, co znalazłeś?

Szymon Warda: Ja trochę temat powiązany z tym, o czym będziemy dzisiaj rozmawiali, trochę właśnie o data, ale generalnie o pojęciu engineering dependability serwisów. I to jest taki ogólny przegląd przez zależności między serwisami czy availability, throughput, forterrance i tak dalej i z gwiazdką. To jest z bloga produktowego, więc tam jest trochę takich wstawek: my robimy tak, co jest interesujące, bo widzimy realne użycie, ale to też bywa takie wciskanie produktu. Ale to jest fajne, bo nie kończy się to tylko na serwisach stateless, ale też jest o depentability i availability całych danych tak naprawdę. Czyli jak sobie radzić z klastrowaniem, jak sobie radzić z multi regionami, jak sobie radzić właśnie z tym, żeby serwis, który padł, żeby nowy serwis ładnie od tego samego punktu danych zaczął działanie. Co jest realnie tym trudniejszym kawałkiem. Wiadomo, że pokazywanie czegokolwiek co jest stateless zawsze działa pięknie i full tolerance jest idealny. Ale świat taki nie jest generalnie, dane zawsze gdzieś istnieją.

Łukasz Kałużny: Mnie się spodobało, tak zacząłem, że jest nawet rysunek od algorytmu hasharingu zrobione, więc jest dobrze zobrazowany ten wpis, dobrze pokazuje.

Szymon Warda: Dobra przeglądówka. Tak, zdecydowanie. Dobra, to lecimy chyba z tematem głównym w takim razie.

Łukasz Kałużny: Czyli co, pierwsze pytanie, Szymonie, może do Pawła? Od czego zaczniemy?

Szymon Warda: Pierwsze, to generalnie trendy w danych. Jak Ty w ogóle to widzisz?

Paweł Potasiński W ogóle widzę. Trendy w danych, dobre pytanie. To ja Wam powiem jakie są trendy. Trendy w zasadzie, dzisiaj myślę, że tak, po pierwsze, jeśli chodzi o temat, jakby podzieliłbym na dwie części. Pierwszy temat, to jest temat danych, które muszą być jako powiedzmy przechowywanie danych do obsługi aplikacji, czyli taki typowy wątek aplikacyjny. Tutaj powiem szczerze, troszkę już zgubiłem tracking, ponieważ od ponad dekady w zasadzie nie zajmuję się tym tematem. Niemniej jednak problemy dalej są te same. Czyli dalej świat myśli o tym, jak to zrobić, żeby z baz danych SQL-owych, bo jeszcze ciągle to większość baz danych, zrobić jakiś może serwer aplikacyjny, może jakieś systemy rozproszone, może coś, co się będzie bardziej nadawało dla zastosowań multitenancy, czyli stare problemy. Właściwie można powiedzieć, że od czasów, kiedy ja się zajmowałem optymalizacją baz danych, jeszcze w czasach SQL Servera głębokiego, dalej świat stoi instalacjami i pojedynczoserwerowymi, typowymi jakimiś skalowanymi w górę boksami. Mało jest takich rozwiązań, które gdzieś tam wychodzą poza tą kanwę. Gdzieś w kuluarach naszego dzisiejszego spotkania Łukasz zapodał temat newSQL. Przyznam, że jak rzuciłeś to hasło Łukaszu, to aż musiałem zajrzeć do Wikipedii i zobaczyć, które to bazy pod ten koncept podpadają. Powiem szczerze, czy newSQL jest takim trendem? Nie wiem i szczerze mówiąc nie sądzę. Dlaczego? Dlatego, że ten wątek newSQL pojawia się w jakiś sposób już od ponad dekady. Właściwie tam pierwsze ślady jakichś tam systemów, które się ocierały o newSQL, to jest chyba nawet sprzed 15 lat, wątki. Więc jeśli nie przebiły się przez tak długi czas, to być może nie jest to droga, którą świat będzie podążał. Z drugiej strony to, co ja widzę teraz, to jest, ja bym powiedział, zadaniowość platform. Ludzie troszkę wychodzą z takiego, bym powiedział, czasem zgubnego założenia, że wszystko musi być trzymane w jednym wielkim worku, w jednej wielkiej bazie. I to nie mówię tego tylko przez pryzmat analityki, ale również przez pryzmat baz transakcyjnych. Więc być może gdzieniegdzie te koncepty newSQL-a, czyli rozproszoność, odporność na awarie, wykorzystanie potencjału In Memory są do zastosowania. Natomiast ja bardziej w życiu widziałem to punktowo w wybranych miejscach, gdzie wybrani dostawcy stosowali w swoich systemach tylko i wyłącznie wybrane grupy funkcjonalności newSQL z różnym skutkiem. Tu warto przytoczyć, że jest też wiele porażek na koncie choćby Microsoftu. Przypomnijmy sobie In Memory w SQL Server’ze jako jeden z godnych zapomnienia feature’ów.

Szymon Warda: Pawle, a nie masz takiego wrażenia, że newSQL to jest ładne ubranie dobrze zrobionego generalnie SQL Servera i z powrotem ubranie, że jednak bazy relacyjne są dobre, jak już wszyscy otłukli się i stwierdzili, że te noSQL-owe tak: może niekoniecznie?

Paweł Potasiński Słuchajcie, większość dyskusji dzisiaj, jeżeli chodzi o to jaką bazę wybrać, moim zdaniem sprowadza się nie tylko do tego, jak dobra jest technologia, tylko bardziej do tego, jakie masz kompetencje w swojej firmie, w swoim zespole. Bo jeżeli masz samych SQL-owców, to trudno się będzie wepchnąć w świat, nie wiem, noSQL-a, albo czegoś jeszcze innego. To samo dotyczy budowania rozwiązań BI. Jeśli na pokładzie nie ma MDX-owca, to trudno spodziewać się, żebym zrobił dobre kostki i tak dalej. Więc tu jest to taka dyskusja. Mi się wydaje, że newSQL jest faktycznie taką wizją, jak powinien wyglądać dobrze zrobiona platforma baz danych. Czyli platforma, w której faktycznie przestaje się martwić o to, że nie wiem, nie wyskaluje mi się któraś warstwa tego systemu bazodanowego. Na dzień dzisiejszy myślę, że tak szczerze, trochę myślę, że ten nurt się nie przebił, dlatego że większość vendorów dalej dostarcza po prostu tradycyjne, rozdzielone na dwa wątki bazy SQL-owe, czyli relacyjne i noSQL-owe, czyli dokumentowe albo z innymi API.

Łukasz Kałużny: Jak wygląda teraz analityka? Bo może nawet idąc, jak czują się te klasyczne, relacyjne hurtownie danych? Bo tak jak powiedziałeś o tym trendzie, że nadal się spotykasz z tym, że skalujemy się w górę tylko większą maszyną, większymi zasobami, to jak w ogóle wygląda teraz u Ciebie ten?

Paweł Potasiński Ale chcielibyśmy, ale chcielibyśmy, ale chcielibyśmy.

Łukasz Kałużny: Właśnie, jak u Ciebie wygląda ten trend, z Twojej perspektywy, właśnie ten trend tego, co się dzieje w ogóle teraz w analityce? Bo mamy dużo różnych buzzwordów, o które będę chciał Cię jeszcze dopytać, ale co Ty ogólnie widzisz?

Paweł Potasiński Dobra, w analityce jest troszeczkę inaczej. W analityce jest troszkę inaczej. W analityce widzę, że już troszeczkę dojrzeliśmy do momentu, w którym trzeba sobie powiedzieć, że rozdzielność warstw takich jak storage, metadane i warstwa obliczeniowa to jest coś fajnego. Zresztą jakby koncepcja nie jest w niczym nowa, bo wszelkiej maści rozwiązania big data od Hdoopa począwszy, to już jest właśnie wyjście w kierunku tego, żebyśmy mieli niezależny magazyn danych, on top tego prowadzili sobie obliczenia, tworząc jakieś klastry obliczeniowe i tak dalej. Więc to jest coś co dzisiaj myślę, że jest commodity w analityce i większość dostawców zmierza do takiego, powiedzmy, rozdzielenia lepszego, lepiej lub gorzej implementowanego rozdzielenia warstw, a często nawet spowodowania, że ludzie przestaną o tych warstwach myśleć i zaczną stosować rozwiązanie dla biznesu i modelowania danych, a nie po to, żeby się tam bawić w tuning. Natomiast jeżeli pytasz mnie o klasyczne hurtownie? One się mają świetnie moim zdaniem. Jedyne co, to doczekały się oczywiście pewnych nowych paradygmatów i implementacji. Przykład, musieliśmy uciec z ETL-a na ELT, bo tego wymaga chmura, bo dane lądują najczęściej, jako pierwszy styk z chmurą mają storage. Czasem jest to podejście wymuszone przez vendora, czasem jest to po prostu najlepsza praktyka. I mamy coraz liczniejsze implementacje takich powiedzmy hybryd, czyli połączenia data lake’a z hurtownią danych. To jest to, co widzę dzisiaj.

Szymon Warda: Ja tu jestem tym, który pilnuje rozwijania skrótów. Także rozwińmy skrót.

Łukasz Kałużny: Chodziło o ten ETL, ELT.

Paweł Potasiński Dobra, to rozwijając skrót, ETL - Extract, Transform, Load. Rzecz polega na tym, że w klasycznym podejściu, które znamy powiedzmy z on premises, dane są najpierw wypakowywane, później w locie transformowane, a później trafiają do pierwszej warstwy hurtowni danych. A teraz mamy paradygmat ELT, czyli Extract, Load, Transform, który troszkę wynika z faktu, że właśnie chmury preferują taki powiedzmy landing point czy landing zone w postaci taniego, skalowanego magazynu danych, storage’u, najczęściej opartego o klasykę, czyli HDFS czy Web HDFS. I tu najpierw dane trzeba załadować. Ten staging, który typowo był, znajdował się w relacyjnej bazie danych w tradycyjnej hurtowni też bardzo często przesuwa się w kierunku data lake’a i wykorzystujemy troszkę inne mechanizmy. Zamiast klasycznego SQL-a do transformowania danych, coraz częściej używane są rozwiązania typu Spark na przykład.

Łukasz Kałużny: To wiesz co Pawle, to ja jeszcze mam takie pytanie. Czyli patrząc się na to, bo wprowadziłeś pojęcie jeszcze data lake’u, czyli tego jeziora danych, takiego pierwszego miejsca, żeby je zrzucać, gromadzić w organizacji. I pytanie, czy to właśnie, czyli ten stary podział przez tą chmurę tak naprawdę i te rozwiązania big data’owe i te całe nowe paradygmaty, on zmienia swoją rację bytu aktualnie, jeżeli można tak to podsumować?

Paweł Potasiński Znaczy powiedziałbym, że pamiętajmy, że mamy do czynienia z dwoma światami. Mamy do czynienia ze światem takiego klasycznego podejścia big data, czyli rzuć jakiekolwiek dane i przeprowadź na nich analitykę. Nie zawsze mamy do czynienia z danymi, które daje się w prosty sposób stabelaryzować. Nie zawsze musimy mieć bardzo mocny kontrakt na spójność i na schemat danych. I wtedy, jeżeli tego kontraktu nie ma, to data lake może być po prostu rozwiązaniem szybszym, prostszym i umożliwiającym taką analitykę ad hoc, jakiej dzisiaj spodziewa się bardzo często biznes. Natomiast hurtownia danych dalej ma rację bytu. Bo jeżeli spodziewamy się dobrze obwarowanych, dobrze zdefiniowanych i objętych pewnymi politykami danych ubranych w tabelę, to dalej mamy hurtownię danych. Natomiast oczekiwanie jest takie, że dzisiejsze silniki hurtowniane czy platformy hurtowniane będą umożliwiały wykorzystanie obu tych wątków jednocześnie. Czyli zarówno zbudowania relacyjnej bazy tam powiedzmy zdemoralizowanej czy ujętej w model Kimballa czy Data Vaulta oraz dostęp łatwy do data lake’a, czyli do jeziora danych do systemu plikowego i wykonywania tam często zapytań za pomocą tradycyjnych dialektów, takich jak SQL.

Łukasz Kałużny: Ok, czyli to się, że tak powiem, ten cały świat się miesza, tak patrząc na to i że nie ma żadnej teraz skutecznej drogi.

Paweł Potasiński Tak. I co ciekawe, zobaczcie, że dzisiaj to rozwiązanie, czyli połączenie takiej tradycyjnej bazy SQL-owej hurtowni danych, jaką znamy z dawnych czasów, z data lake’iem, z tym storage’em i często nawet z silnikami sparkowymi, prezentują wszyscy wiodący dostawcy rozwiązań hurtownianych. Czyli, nie wiem, przytaczając przykłady, w Azure jest to Synaps, w Google BigQuery, na AWS-ie Red Shift czy third parties typu Snowflake. To wszystko działa w oparciu o ten schemat, gdzie mamy dane lądujące w storage lub data lake, a później konsumowane przez silnik relacyjny.

Szymon Warda: To właśnie ruszyłeś teraz z tematem, który też jest dla mnie dość ciekawy. A jak się rozkłada obecnie ciężar analityki pomiędzy chmurą a on premem? Jak to wygląda?

Paweł Potasiński Ja jestem skrzywiony, nie powiem Wam prawdy. Na pewno większa część instalacji dalej jest na on premises. To tutaj nie ma dwóch zdań. Pamiętajmy, że adopcja chmury w Polsce to nawet powiedziałbym, że jest jeszcze niższa niż w Europie. Ale jeśli spojrzymy, porównamy sobie Stany Zjednoczone z Europą, to generalnie jest to przepaść. Z tego też powodu Stany Zjednoczone są na pewno bardziej atrakcyjnym rynkiem dla wszystkich dostawców, bo tam po prostu firmy cloud, jako jako podstawę pod analitykę, wykorzystują jako coś po prostu na porządku dziennym. Tutaj w Europie ta adopcja jest znacznie niższa. Nie potrafię powiedzieć, jak to się rozkłada względem analityki. Natomiast jeżeli chodzi o w ogóle rozwiązania informatyczne, to jesteśmy na poziomie w Polsce 20-parę%, w Europie 36%, jeśli chodzi o organizacje. Więc to pokazuje, że jest jeszcze bardzo duża baza klientów, którzy po prostu mają czy w swoim datacenter, czy w jakiejś kolokacji, hostingu trzymają po prostu dane i to niekoniecznie zniknie, bo są pewne branże, które są mocniej regulowane, które mają jakieś swoje powody, żeby natychmiast w chmurę nie uciekać. A często po prostu nie ma takiego powodu, bo nie ma aż tak dużych danych i powiedzmy ten serwer czy serwery kupione kilka lat temu dają radę i sobie może to działać. Więc to nie jest tak, że dla wszystkich jest chmura. Aczkolwiek jeżeli miałbym mówić, na czym budować dzisiaj platformę na przykład, nie wiem, od podłogi, czyli wyobraźmy sobie sytuację, że firma po prostu chce gruntownie zmienić podejście do pracy z danymi, to tylko i wyłącznie chmura. Bo po prostu skala, szybkość tworzenia rozwiązań jest nieporównywalnie większa.

Szymon Warda: Greenfield zawsze jest łatwiejsze. A jeżeli miałbyś już istniejący system analityczny, to jak byś przeprowadzał migrację? Wszystko na raz? Jakieś hybrydowe?

Paweł Potasiński Case by case. Wiesz co, teraz są w ogóle, już teraz wiadomo dostawcy też polują na konkurencję, więc są rozwiązania czy to własne, dostarczane przez firmy typu Microsoft chociażby czy firmy trzecie, które umożliwiają takie migracje z on premises do clouda. Co więcej, dostawcy, którzy nie mają swoich rozwiązań chmurowych, na przykład Teradata, już też dostrzegają, że warto mieć swoje rozwiązania idące w kierunku software as a service, które są serwowane na major clouds po to, żeby móc swoich własnych klientów migrować do chmury jeśli padnie hasło chmura i nie oddać tego poletka tym newbies, na przykład chociażby Snowflake’owi, który wiadomo, że jest bardzo, bardzo szybko rosnącą firmą i też udziały w rynku, jeśli chodzi o data warehousing, bardzo, bardzo mu ostatnio podskoczyły.

Szymon Warda: Spodziewasz się, że tym głównym elementem, który będzie tym punktem zapalnym generalnie, żeby jednak przeprowadzić migrację, to właśnie będą feature’y czy to jednak będzie kwestia skalowania i tak dalej?

Paweł Potasiński Moim zdaniem będzie kwestia szybkości adaptacji do potrzeb biznesowych. I to wymieniałbym jako pierwszy powód. Po drugie, ucieczka mimo wszystko z CAPEX-u w OPEX i to, że dzisiaj systemy coraz mocniej schodzą z [niesłyszalne 00:21:49] rozliczeń, zwłaszcza mocy obliczeniowej. I to są powody, dla których ludzie będą patrzyli na chmurę jako na bardzo atrakcyjne medium dla analityki. Jeszcze raz, wydaje mi się, że zwłaszcza to agility jest tutaj kluczowe. Oczywiście skala jak najbardziej. Jeżeli ktoś mówi dzisiaj big data, to zazwyczaj określa tym mianem dwa problemy występujące jednocześnie. Jeden, to jest sporo danych albo sporo danych kreowanych przez struktury, które sobie tworzymy na przykład w hurtowni danych. A drugi problem, to jest duża współbieżność i potrzeba tego, co jakiś czas temu nazywaliśmy self-service BI na przykład.

Łukasz Kałużny: Właśnie, mam do Ciebie pytanie, w sumie to dwa, bo dwa wątki, poleciałeś z dwoma wątkami, które chciałem poruszyć. Ale zacznę od pierwszego. Tak naprawdę te wszystkie, ja to trochę real time bullshitem nazywam, czyli wszystkie te potrzeby danych na już i raportowania real time’owego i odrzucę teraz tutaj scenariusze IoT, bo tam jest, one rządzą się, analityka tam rządzi się swoimi prawami, jest zupełnie inna. Ale mówię w tym podejściu biznesowym, o tak, kiedy mamy te realne podejście biznesowe, jak to jest w Twojej opinii? Czy to jest często realne wymaganie, często potrzebne? Albo kiedy te dane są, faktycznie muszą się pojawić w tych rozwiązaniach i jak bardzo to komplikuje świat wtedy?

Paweł Potasiński Myślę, że odpowiem jak rasowy konsultant. Politycznie to zależy. Zależy głównie pewnie od tego, jak mamy zdefiniowany real time. Co to jest real time dla firmy? Dla niektórych firm real time oznacza to co powiedziałeś, czyli IoT, reakcja w ułamku sekund. I to są scenariusze, ja bym powiedział, bardziej takiej analityki preskryptywnej, gdzie musimy zareagować na zaistnienie sytuacji, w której jakiś wskaźnik przekracza zdefiniowany poziom, nie wiem, pomiary temperaturowe, cokolwiek. I to jest ta część IoT, która jest oczywista, że ona, jeżeli już jest ten wątek IoT i robimy analitykę danych przychodzących strumieniowo, powiedzmy określających pewne istniejące warunki brzegowe, to musimy tam reagować szybko. I to jest faktycznie coś bliskiego czasowi rzeczywistemu. Natomiast w pozostałych scenariuszach widzę przynajmniej kilka takich sytuacji, w których to musi być zrobione. Jednym z nich jest chociażby wykorzystanie analityki predykcyjnej, czyli typowego machine learningu, modeli machine learningowych w wątkach aplikacyjnych. Bo na przykład, nie wiem, w aplikacji sprzedażowej czy w sklepie internetowym rzeczy typu analiza koszykowa czy powiedzmy next best offer powinny się odbywać dość szybko. Więc w tym momencie też powinniśmy bazować na danych w miarę świeżych, żeby przypadkiem nie popełnić gafy i nie zaoferować klientowi czegoś, co kupił w poprzednim zamówieniu. To są scenariusze, które wydaje mi się najbardziej pasują do real time’u. Natomiast z doświadczenia wiem, że firmy też dążą do tego, żeby niekoniecznie robić totalny real time, tylko zejść z dokładnością danych na przykład, nie wiem, performance’u, sprzedaży czy danych finansowych z tych typowych scenariuszy z day -1 do, powiedzmy, opóźnienia na poziomie godziny, 15 minut. I to są rzeczy, które już też wymagają totalnie przeprojektowania często architektury i innego podejścia do tworzenia.

Szymon Warda: Ruszyłeś jeden temat, mianowicie właśnie generalnie całego machine learningu. Był swego czasu taki bardzo mocny ruch w kierunku właśnie wzbogacania danych, czyli właśnie mamy strumień danych i do tego dopinamy właśnie jakieś usługi kognitywne, AI-owe i wzbogacamy na przykład, czyli wyszukujemy adresy, uzupełniamy dane, których nam brakowało, albo dodajemy danych, których po prostu nie mamy. I na ile ten nurt jeszcze istnieje i na ile on już stał się taki popularny i można powiedzieć zwyczajowy?

Paweł Potasiński Powiedziałbym, że on wcale nie stał się zwyczajowy. To znaczy wszyscy to chcą robić, ale platformowo dopiero teraz dostajemy takie możliwości. Tu przytoczę przykłady Synapsa i BigQuery, czyli też platform, powiedzmy warehousingowo-lejkowych, gdzie w zasadzie w obu przypadkach dopiero od stosunkowo niedawna mamy takie możliwości jak wykorzystanie istniejących danych czy to tabel sparkowych, czy tabel rezydujących w warehousie, żeby na nich odpalić na przykład trenowanie nowego modelu czy wykorzystanie modelu istniejącego, serwowanego przez jakąś zewnętrzną usługę. Do tego dochodzi oczywiście możliwość zawołania predykcji na takich modelach za pomocą składni czy funkcji SQL-owych.

Szymon Warda: Czyli jednak tam trochę adopcja tego zajmuje. Ok.

Paweł Potasiński Jest adopcja tego. Ale trzeba powiedzieć, że większym problemem dla machine learningu nie jest to, jak z niego skorzystać w przypadku ubogacenia danych analitycznych. Za to dużo większe wyzwanie. Firmy mają z kilkoma rzeczami, jeżeli chodzi o taki typowy machine learning. Pierwsza rzecz to w jaki sposób ustrukturalizować i zbudować zespół. To jest duża zagadka często. Czyli data scientist to nie jest coś, co łatwo zdefiniować. Często w takim zestawieniu zespołu data science musi się znaleźć nie tylko osoba od algorytmów, ale też osoba od technologii i osoba, która jest ekspertem dziedzinowym i często nie jest to jedna osoba. Mogą być to oczywiście współdzielone kompetencje, ale rzadko kiedy są w jednych rękach. I druga rzecz, która też myślę ważna, a właściwie dwie następne rzeczy. Druga to to jak zrobić proces operacjonalizacji, nie tylko uczenia, ale też zarządzania zmianą modelu, czyli taki proces MLOps’owy typowo. Tu pewnie podejrzewam, że data scientist’ci mogliby się sporo od programistów nauczyć w tym względzie. I trzecia zagadka, która często powstaje w organizacji i też nierzadko mi się zdarzało brać udział w takich dyskusjach, to w jaki sbosób kreować zapotrzebowanie na zastosowanie tych platform machine learningowych, bo to wcale nie jest takie oczywiste. Czyli jak budować case’y tak, żeby się nie spalić i żeby biznes dostawał jednak wartość z tych platform, a nie tylko eksperymenty i jakieś przypadkowe dane.

Łukasz Kałużny: Oj, Paweł, będę Ciebie cytował, że tak powiem po tym, bo tak, bardzo się zgadzam z tym, co teraz powiedziałeś.

Paweł Potasiński Ostatnie dwa lata robiliśmy, robiłem, jeśli w ogóle pojawiał się temat machine learningu, to głównie pojawiały się te trzy wątki: struktura zespołu, MLOps-y i jak podejść do biznesowego kreowania.

Łukasz Kałużny: Tak, to powiedziałeś o kompetencjach, że nie wszyscy chcą to zrozumieć, że te kompetencje inżynierskie, technologiczne muszą się bardzo znaleźć w tych zespołach. To tak jak ja widzę i mam okazję rozmawiać i pomagać. A słuchaj, moje takie kolejne pytanie, które było tym drugim wątkiem, to co się stało z tym self-service BI? Bo był taki trend wokół tego wszystkiego i w ogóle gdzie dąży ta warstwa, nazwijmy to, ta ostatnia warstwa wizualizacyjna, raportowa w tych wszystkich i niby ta demokratyzacja korporacyjnych danych wewnątrz organizacji?

Paweł Potasiński Dobra, właśnie otworzyłeś puszkę Pandory, bo niestety tak często się kończy uwolnienie self-service BI, że doszliśmy do takiej planszy, w której po pierwsze, narzędzia do analityki tej wierzchniej, do wizualizacji danych, do samodzielnego modelowania stały się commodity, patrz Power BI, który kosztuje grosze, albo może być wręcz użyty za darmo. I gdybym miał Ci odpowiedzieć na pytanie, co się stało z self-service BI? To powiedziałbym jest i ma się dobrze. Tylko pytanie jak do niego podejdzie firma czy organizacja? Ja bym powiedział, że po nowemu to nazywamy, to się nie nazywa self-service BI, tylko manage self-service BI, a przynajmniej wszędzie tam, gdzie to się może udać. Bo organizacje generalnie szybko, takie firmy, z którymi pracowałem, które są firmami dużymi, globalnymi, bardzo szybko dochodzą do wniosku, że taki self-service bez jakiegokolwiek nadzoru to jest po prostu wplątanie się w nowe piekiełko excelowe, przeniesienie tego Excela na nowy wymiar i chyba nawet znacznie trudniejszy do ogarnięcia.

Szymon Warda: Większy zbiór danych.

Paweł Potasiński Więc tak, na większym zbiorze, z większą ilością przypadkowości i z większą ilością nadmiarowości modeli, z większą ilością połączeń do systemów źródłowych i tak dalej. Stąd self-service owszem, ale wyłącznie w ramach dedykowanych do tego celu fragmentach platform analitycznych, jakieś sandboxy, nadzorowane foldery dedykowane pod self-service, predefiniowane modele danych i stały monitoring kogoś, kto to ogarnia centralnie. Czyli ja bym powiedział, że ok, niech sobie ten self-service będzie, tylko wiedzmy co się w nim dzieje, niech to ktoś kontroluje. Ja to często widzę, zwłaszcza w takich dużych, globalnych firmach to to, że centralny zespół to jest jedno, a lokalnie kształci się takich ekspertów dziedzinowych, którzy są, powiedzmy, takimi liderami platformy analitycznej, którzy odpowiadają nie tylko za skilling, ale też za to, żeby trzymać pieczę nad takimi, nie chcę nazywać tego silosami, ale często to są silosy. Tylko z tych silosów można uzyskać bardzo dużą wartość. Po pierwsze, szybkość, czyli szybka odpowiedź na biznes. Po drugie, można zmusić, doprowadzić do sytuacji, żeby te silosy jednak były silosami analitycznymi, raportowymi, a nie silosami danych. Bo najgorzej to jest, najgorsza jest sytuacja, kiedy stworzymy silosy danych, kiedy wszyscy używają innych danych i każdy uważa, że te dane są najlepsze. Więc tutaj wiele zależy od dojrzałości organizacji. Jak jest zbudowana kultura pracy z danymi, na przykład czy jest wykształcona kultura, nie wiem, procesów przepływów danych, czy jest to spisane, udokumentowane? Czy istnieje coś takiego jak słownik definicji biznesowych, podstawowych miar, dane podstawowe? Czy dane mają swoich właścicieli? To są typowe pytania, które jeśli nie zostaną zadane, self-service będzie…

Łukasz Kałużny: Mnie zawsze przerażały miary, bo widziałem przypadki, że na tą samą miarę było pięć sposobów wyliczenia i pięć się rozjeżdżało diametralnie. To zawsze mnie w tym podejściu przerażało.

Paweł Potasiński To jest dyskusja Łukasz, czy każda firma powinna mieć CDO.

Łukasz Kałużny: Tak, jeszcze cięższa. Dobra, kontynuując, trochę już zmieniając wątek, bo powiedzieliśmy sobie, mamy to gro rozwiązań i tyle z tych rzeczy. Jak teraz wygląda w ogóle tematyka? Bo możemy sobie wziąć zrobić trzy, cztery grupy produktów, jak popatrzymy sobie, typów rozwiązań. To możemy wziąć rozwiązanie do analityki patrząc, już nie mówiąc nawet o raportach, ale o całej analityce, to mamy cały świat open sourceowych rozwiązań, open sourceowych, na której bazie powstają komercyjne produkty. Takich typowo komercyjnych w postaci albo gotowych SAS-ów, albo produktów hybrydowych. Czyli można częściowo zrobić to lokalnie, częściowo w cloudzie. I jak to z Twojej perspektywy wygląda? Bo zresztą Spark, który się przejawia już ileś razy w dzisiejszej rozmowie właśnie, jak to wygląda, w którym kierunku dostawcy i świat idzie, jak na to popatrzymy?

Paweł Potasiński To powiem tak, może nie politycznie, ale wiecie, OpenSource jest super sexi tematem dla dostawców, dlatego, że większość, czy powiedzmy nie większość, ale spora część konceptów jest konceptami sprawdzonymi i zaadoptowanymi. Jest spora baza użytkowników, spora baza kontrybutorów, tak, chociażby wspomniany przez Ciebie Spark czy w ogóle ekosystem Apache. To jest wdzięczny temat, który jeśli doczeka się implementacji własnej czy zaadoptowania przez dostawcę, to jest bardzo fajny kierunek. Wydaje mi się, że trochę ten świat się rozmył. To znaczy dzisiaj już nie wiem, czy ktoś zwraca uwagę, czy nie wiem, czy to co dostawca serwuje jest faktycznie open sourcem. Chociaż oczywiście są momenty, gdzie ta zgodność z oryginałem jest bardzo istotna, tak, nie zawsze można te rozwiązania, na przykład Apache w 100% u siebie zaimplementować. Tu patrz na przykład chociażby case Microsoftu i Event Hubs, gdzie jest oczywiście zgodność z Kafką, ale tylko częściowa. A to wynika oczywiście z tematów licencyjnych i tyle. Więc po prostu Microsoft nie był w stanie zaimplementować pełnej Kafki we własnej usłudze PaaS-owej i tyle. I to jest serwowane gdzieś tam przez, nie wiem, mamy opcję postawienia sobie klastra i [niesłyszalne 00:35:08] albo własnych klastrów, które działają w trybie Kafki. Więc przykładów na pewno jest dużo. Ja bym podał kilka. Po pierwsze, zobaczmy, jak się przyjął koncept HDFS-owy, który też pochodzi ze świata Hadoop lub też ze świata open source. W zasadzie dzisiaj każdy storage, który mamy i który mamy w cloudach, w major clouds i który jest centralną częścią analityki, a często również centralną częścią zupełnie innych rozwiązań, to jest zaadaptowany koncept HDFS. Po drugie, Spark, o którym wspomnieliśmy. Tutaj mamy liczne jego hybrydy i modyfikacje. Databricks jest pewnie najbardziej znaną. Czyli mamy ludzi, którzy bardzo mocno kontrybuowali Sparka, założyli swoją własną firmę i dopisują do tego Sparka swoje rozszerzenia głównie w zakątkach typu performance czy zarządzanie zmianą dużych zbiorów, patrz format Delta, tak. Mamy implementacje własne vendorów tych sparków, chociażby nowość dla Microsoftu w Signup’sie też obok tradycyjnej hurtownimamy też silnik sparkowy jako jeden z możliwych do powołania. On to w tych samych danych, tak. Oczywiście inni dostawcy mają swoje odpowiedniki Dataproc z Google czy IM, WARF w AWS-ie. Ja widziałem sporo zastosowań w globalnych firmach, na przykład takich silników jak Presto, czyli rozproszony silnik SQL-owy On Top Data Lake, tak. Jakby się przyjrzeć na przykład też rozwiązaniom SAS owym, dzisiaj dość ciekawym, ale które może niekoniecznie są popularne w Europie, to tutaj już Łukasz rozmawialiśmy sobie kiedyś o Dremio, więc przytaczam przykład jeszcze raz. Dremio, które zostało w ostatnim czasie unicornem, czyli wartość rynkowa firmy została mocno, mocno, mocno wyceniona, korzysta pod spodem z również konceptów Apache z Arrowa, czyli z technologii In-Memory i z Apache Iceberg, wspomnianego przeze mnie formatu tabelarycznego. Więc są te wynalazki powstałe w świecie open source świetnie adaptowane. Ja bym wspomniał jeszcze o jednym takim wynalazku, już nie ze świata Apache, nie wiem, czy słyszeliście o takiej technologii w środowisku developerskim DBT.

Łukasz Kałużny: Nie.

Paweł Potasiński Data build tool.

Łukasz Kałużny: Pierwszy raz słyszę.

Paweł Potasiński To warto zobaczyć, bo to jest ciekawa rzecz. To jest taki mix. To jest platforma developerska, środowisko do zarządzania procesami inżynierii danych i budowania takich rozwiązań jak hurtownie danych, gdzie rzecz polega na tym, żeby ustawić to w sensowny proces i automatyzować do granic możliwości za pomocą znanych dialektów czy formatów plików. Jest to w zasadzie można powiedzieć, miks SQL-ela z YAML-em. Bardzo ciekawa rzecz.

Łukasz Kałużny: Ok, czyli…

Szymon Warda: Ja muszę to zobaczyć.

Paweł Potasiński Dokładnie te dwie technologie są wykorzystywane. Polecam. Jeżeli ktoś nie oglądał sobie tego narzędzia, to warto zobaczyć. Jedyną wadą tego rozwiązania jest to, że transformacje szeroko rozumiane trzeba prowadzić już w innym jakimś środowisku. Natomiast do samego procesu twórczego i nadzorowania takich rzeczy jak kontrola wersji, jakieś tam budowanie środowisk, testowanie i tak dalej, uważam, że narzędzie jest bardzo ciekawe.

Łukasz Kałużny: Chciałem zażartować, że data, ten, świat data zazdrościł YAML-i Kubernetesowych aplikacyjnego.

Paweł Potasiński Tak, słuchajcie, generalnie są też wątki takie cięższe. Na przykład, nie wiem, kostki OLAP-owe. Ktoś z was pamięta takie rzeczy jak kostki OLAP-owe? Dzisiaj w microsoftowych technologiach przeszliśmy na model tabelaryczny. Power BI działa na tym słynnym silniku xVelocity, ale firmy mają cały czas kostki OLAP-owe i działające jakieś tam na zapytaniach MDX-owych rzeczy. To tutaj również świat doczekał się implementacji takich, powiedziałbym może bardziej zmierzających w kierunku rozproszonych rozwiązań czy rozwiązań, które bardziej idą w kierunku clouda. Przykłady tutaj już pewnie niewiele powiedzą, ale na świecie istnieją rozwiązania, które na przykład wykorzystują takie silniki jak Apache Kylin. Tutaj jest taka firma, która się nazywa Kyligence, która robi swojego OLAP-a rozproszonego, czy na przykład rozwiązanie EdScale albo Kayvos. To są platformy, które dzisiaj robią takie, powiedzmy już zmierzając w kierunku software as a service i serwują takie rozproszone rozwiązania OLAP-owe. I jeszcze z takich opensource’owych ciekawostek, to też warto wspomnieć, że na przykład nówka sztuka Azure Purview wykorzystuje pod spodem API Apache Atlasa do operowania na metadanych. Więc tutaj z niespodzianek, Microsoft dawno temu już wyzwolił się z tego bycia odkrywaczem koła na nowo.

Szymon Warda: Raczej mam ogólnie wrażenie, że właśnie to co dał open source przede wszystkim, to jest ustandaryzowanie danych i wprowadzenie standardu nie tylko na API, ale też na przechowywanie i na wszystkie pozostałe, że dużo łatwiej świat się analityki dogaduje. Kiedyś każde zarządzanie było zupełnie inne od siebie, a teraz nareszcie możemy to budować z klocków i to faktycznie ładnie pipe’ować zastosowanie.

Paweł Potasiński Słuchajcie, gdybym miał Wam powiedzieć, gdzie się [niesłyszalne 00:40:28] i podpierając się cyferkami, że open source ma się świetnie, to to weźcie pod uwagę, że podobno 80% firm z grupy Fortune100 używa Kafki.

Szymon Warda: Absolutnie mnie to wcale nie dziwi.

Paweł Potasiński To chyba kończy dyskusję, gdzie jesteśmy z open sourcem.

Łukasz Kałużny: Zabrakło mi tak naprawdę w tym jeszcze chyba jednej firmy, bo ze wszystkich technologii, których wymieniłeś, tak naprawdę gdzieś tam jeszcze z tyłu Cloudera ze swoją platformą wykorzystuje i kontrybuuje.

Paweł Potasiński Mówiąc Hadoop pewnie miałem na myśli dawny twór pod tytułem Hortonworks, a teraz już Cloudera, tak. Oczywiście Cloudera cały czas jest bardzo popularnym silnikiem. Z rzeczy, które jeszcze mi się gdzieś tam pojawiały na agendzie był na przykład Apache Superset, czyli wizualizacje danych i Apache Druid, czyli taka baza time series’owa i time’owa. To są rzeczy, które gdzieś tam…

Szymon Warda: Tutaj nawet mówiliśmy swego czasu.

Paweł Potasiński Gdzieś tam mi się pojawiały na agendzie, ale przyznaję, że Superset tylko przetestowałem tak na własne potrzeby, a Druida nie dotykałem, więc nie chcę się wypowiadać jak to wygląda.

Szymon Warda: Tak powoli, powoli czuję, że zaczynamy przytłaczać słuchaczy ilością haseł. Więc tak…

Paweł Potasiński Mogę Wam linki dorzucić jak chcecie.

Szymon Warda: Tak, jedna rzecz. Gdzie ten biedny architekt generalnie, jak chciałbyś odświeżyć z poziomu analityki, na co, jaki nurt, jaki temat rzucasz generalnie, że jest taki must have w ciągu najbliższego czasu, żeby znać.

Paweł Potasiński Wiecie co, to ja Wam powiem troszeczkę więcej, ale to nie będzie elaborat. Powiem Wam raz, dwa, trzy, cztery rzeczy Wam powiem.

Szymon Warda: Przeżyjemy.

Paweł Potasiński Pierwsza rzecz to niezależnie od tego, czy robisz aplikację, czy nie, warto jest dzisiaj choć trochę liznąć inżynierii danych. Czyli modelowania, czyli tego, w jaki sposób operować na danych, w jaki sposób robić trochę ich keyrating, bo dane pod aplikacjami będą się pojawiały. Spark i Python, jeśli miałbym mówić o kierunkach. Tak szczerze, może to ciężka bułka i może nie warto się pakować od razu w nie wiem, 100 tysięcy rozszerzających bibliotek Sparka, ale przynajmniej jakieś podstawy, jak tam wygląda ta praca rozproszona, podstawy działania na jakichś DataFrame’ach i tym podobnych rzeczach. Naprawdę to się może przydać. Po drugie, jest duży trend moim zdaniem na aplikacyjnego BI rozumianego jako opakowywanie analiz czy raportowania własnymi aplikacjami. Firmy robią to, ponieważ to, co dostarczają rozwiązania rynkowe, często gdzieś tam nie spełnia wszystkich wymogów. Nawet Power BI czasami opakowany we własną aplikację i to widziałem w paru przypadkach u firm, robi zupełnie inne wrażenie. Pozwala na zupełnie inną pracę z raportami, na inny rodzaj śledzenia przede wszystkim, co ludzie robią z tymi raportami. Więc tu warto dotknąć metod wizualizacji danych i zagadnień embedded analytics, polecam. To też jest myślę, że dobry sposób na uatrakcyjnienie aplikacji. Jeżeli to jest aplikacja jakaś powiedzmy operacyjna, transakcyjna, a my do tego dodamy analitykę jako osobny moduł, to jest zawsze jakiś wątek nowego modelu biznesowego. Trzecim punktem jest wykorzystanie, moim zdaniem to jest oczywistość, wykorzystanie zaawansowanej analityki, czyli modeli produkcyjnych w budowaniu aplikacji biznesowych. Można zacząć od czegoś bardzo prostego. Nawet nie wiem cognitive services sobie wykorzystać, jakieś tam proste API i coś w miarę innowacyjnego do tej aplikacji dołożyć. Powiem, że zaskakująco dobrze cognitive services sprawdziły się w wielu scenariuszach biznesowych. Ostatnim jaki widziałem było wykorzystanie form recognizera i rozpoznawanie tekstu na listach przewozowych czy tam dokumentach celnych po to, żeby to zestawić z faktycznym stanem od towaru do cła. I to rzeczywiście działało, nawet na językach, na których nikt się tego nie spodziewał, włącznie z chińskim. Więc absolutnie polecam to. I czwarta rzecz to jest analityka, taka, powiedziałbym, zdarzeniowa czy czasu rzeczywistego. Mam tu na myśli wszelką analitykę, taką opartą o strumienie logów czy zdarzeń szybko przybywających. Bo to też powinno być, powiedziałbym, commodity, zwłaszcza jeżeli używacie aplikacji chmurowych. Tutaj szczególnie piję do takich tworów jak chociażby KQL w Azure, czyli język wykorzystywany między innymi przez Data Explorera, ale też przez Log Explorera. Wydaje mi się, że tam jest możliwość czytania tych eventów. W ten sposób pracuje m.in. grupa produktowa Azure, która w logach, które są przepastne, jak sobie można wyobrazić, znajduje bardzo szybko zdarzenia namierzając delikwenta po, nie wiem, ID subskrypcji czy jakimś tam ID zasobu. Ja na żywo oglądałem jak ten człowiek szukał problemu z moim Power BI-em. Dwie minuty grzebania i już. Więc naprawdę polecam. Natomiast jakby też odwracając tę narrację, zachęcam developerów i twórców aplikacji, żeby nie bali się wychodzić z pomysłami do ludzi od analityki. Dlatego, że ludzie od analityki mogliby się na pewno nauczyć kilku rzeczy od Was. Taką rzeczą, którą na pewno możecie ich nauczyć, dwie rzeczy, które widzę, to jest wszelkiego rodzaju coś-OPS, czyli DevOps, DataOps, w przypadku ludzi od date’y. Czyli myślenie o tym, jak planować rzeczy związane z zarządzaniem, zmianą tego typu rzeczy. I continuous integration, continuous development, wszystkie rzeczy wokół toolingu, Azure DevOps i GitHub, jeżeli chodzi o microsoftowe poletko, ale pewnie tego jest znacznie więcej. Tutaj myślę, że ludzie od date’y i od analityki to mogliby strumieniami czerpać od developerów.

Łukasz Kałużny: Dobra, to bardzo ciekawe podsumowanie Pawle. W takim razie pozostaje nam podziękować Ci za dzisiejszą rozmowę.

Paweł Potasiński Ja dziękuję za zaproszenie. I mam nadzieję, że ta wiedza do czegoś się słuchaczom przyda.

Szymon Warda: Dzięki wielkie.

Paweł Potasiński Dzięki serdeczne. Do zobaczenia! Hej!

Łukasz Kałużny: Na razie.