W kolejnym odcinku podcastu DEVision przedstawiamy temat hurtowni danych. Naszym rozmówcą jest Damian Baran, który hurtowniami danych zajmuje się już kilka lat. W swojej karierze poznał każdy etap pracy jako programista baz danych, od analizy biznesowej, po raportowanie. W tym odcinku przedstawi Wam:
👉 co to są hurtownie danych i jaka jest ich wartość dla biznesu
👉 jak wygląda proces tworzenia hurtowni danych i z jakich etapów się składa
👉 jakie wyzwania ma programista hurtowni danych
👉 jak może wyglądać ścieżka kariery w tym sektorze dla programisty
Nikodem: Cześć! Witam w kolejnym odcinku podcastu DEVision. Dzisiaj jest ze mną Damian, z którym będę rozmawiał o hurtowniach danych. Czy mógłbyś nam powiedzieć parę słów o sobie?
Damian: Cześć. Hurtowniami danych zajmuję się już ponad 9 lat. Skończyłem studia informatyczne na Politechnice, więc to były studia typowo techniczne – od tego zacząłem moją przygodę programisty. W miarę upływu czasu i pozyskiwania wiedzy przeszedłem w stronę analityka hurtowni, więc teraz łączę te dwa światy i dzisiaj przybliżę Wam tematykę hurtowni danych.
Czym są hurtownie danych?
To takie bazy, które przechowują bardzo duże ilości danych.
Czy różnią się jakoś od zwykłej bazy danych?
Tak. Na przykład, zwykła baza danych, która jest podpięta do aplikacji lub innego systemu, który możesz sobie wyobrazić, jest bardziej transakcyjną bazą danych – wszystko, co zostanie wprowadzone przez użytkownika czy powiedziane przez mikrofon – wpada transakcyjnie do bazy danych i jest zapisywane z datą. Natomiast hurtownia danych to zbiór danych z różnych systemów, które można ze sobą integrować. Czyli jak np. mamy aplikację “jak dojadę” to są tam wszystkie trasy, godziny kursów, itd. Przy tym można np. zbierać ilości pasażerów, które mogą być później podawane, i to ze sobą scalać. Możesz nawet mieć bazę motorniczych, którzy jeżdżą poszczególnymi tramwajami na jakichś trasach. I taki zestaw danych np. z trzech różnych baz łączysz. Mapujesz sobie odpowiednio klucze czy identyfikatory tramwajów, motorniczych i tras. Później z tego możemy robić raporty, w zależności od tego, jakie one mają być – np. operacyjne, żeby zobaczyć na których trasach tracimy lub mamy za małe obłożenie kursów. Następnie dostajemy aktualizację rozkładów jazdy – zmieniane są one na wakacje, okres szkolny, itd. To wszystko dzięki hurtowni danych i analizie tych danych.
Tych informacji nie mógłbym wyciągnąć po prostu ze zwykłych baz danych. Tak jak wspomniałeś, mamy powiedzmy jedną bazę danych, która odpowiada za rozkład jazdy i motorniczych. Nie da się takiej informacji wyciągać ze zwykłych baz?
Nie da, ale jeśli chcesz to zestawić np. z danymi finansowymi to raczej już ich nie posiadasz w tej samej bazie danych. Jest to inny system system – księgowo rozliczeniowy. Z takiego systemu znowu masz informację o pracownikach i ile każdemu z nich płacisz. Czyli możesz powiązać to z identyfikatorem np. motorniczego i zobaczyć jakie są koszty na poszczególnych trasach, utrzymanie, itd. Dlatego hurtownia danych to nie jest jeden system, tylko kilka. Jeśli weźmiemy pod uwagę w tym momencie to, co rozważamy, czyli MPK krakowskie, to oprócz tego, gdzie mamy tych pracowników: są systemy finansowe; HR-owe, gdzie są zatrudniani ludzie; są jakieś pewnie systemy utrzymaniowe; magazyny. To wszystko możemy ze sobą łączyć i robić zestawienia ogólne – dla firmy, dla zarządu. I to jest hurtownia danych.
Ja rozumiem że ty jesteś taką osobą która się zajmuje tymi hurtowniami, tak? Tworzysz dla klienta taką bazę z motorniczymi, przejazdami, itd.
W dużym uproszczeniu tak to wygląda.
Ile trwa tworzenie takiej hurtowni?
Wszystko zależy od tego jakie są zapotrzebowania biznesowe, ile ich jest, jaki jest zakres systemów do zmigrowania do hurtowni. Nie ma tak naprawdę dobrego czasu. Czasami hurtownie nie przestają żyć, funkcjonować. Powiedzmy, że zbudujesz sobie taki core – to zajmuje minimum od trzech miesięcy do półtora roku, w zależności od skomplikowania. Później utrzymanie plus dalszy rozwój, bo nigdy nie jest tak, że biznes się zatrzymuje. Więc jeśli tworzymy sobie jakąś aplikację, która nam coś obsługuje, to ona pewnie działa przez kolejne 3-4 lata. Natomiast jeśli dochodzi coś nowego, to wtedy my musimy reagować – dorzucać te dane i z nowu z nich raportować. Więc tak naprawdę budowa hurtowni, moim zdaniem, się nie kończy. Może w pewnym momencie przystopować, bo spełnia oczekiwania na ten moment.
No właśnie chodzi mi o taki etap od momentu, kiedy nie ma bazy danych. Kiedy np. klient mówi: “Potrzebujemy sprawdzić, które trasy są najdroższe, które najtańsze. Tutaj są wszystkie nasze bazy danych.”. I ty mówisz: “OK – to ja na to potrzebuję…”?
Jeśli mówimy o takich skomplikowanych systemach to na początek musimy mieć odpowiedni zespół, bo praktycznie nigdy nie zrobisz tego sam.
No co Ty, Ty nie dasz rady? 😉 Taki zespół z ilu osób się przeważnie składa?
Ja dam. 😉 Różnie, przeważnie od czterech do czterdziestu. Może być nawet 100. Tak naprawdę to zależy od tego w jakiej firmie to robisz. Jeśli jest to sektor bankowy, to dochodzi nawet do 200-300 osób na hurtownię. Każdy odpowiada za bardzo mały kawałek. Jest to robione zazwyczaj w Scrumie albo Kanbanie, więc to jest podzielone też na zespoły. Każdy zespół dostaje odpowiednią część i to później jest scalane. Czyli jest team zarządzający tym wszystkim i sprawdzający czy to się ze sobą spina. Jest też team testerów i administratorów systemów, bo tu już mówimy o bardzo dużych ilościach danych.
Bazy danych to jest treść zapisana na jednej kartce A4. Tych kartek A4 mam 10 i przychodzi mi pytanie od biznesu, że wyciągniemy wnioski z tego, co mamy zapisane w tych 10 kartkach. I przychodzi taki programista baz danych jak Ty i mówi: “Ściągam w takim razie informacje z tych kartek, zapisuję to na jednej wielkiej i dzięki temu łatwiej jest odczytać te informacje.” Czy tak można to porównać czy nie bardzo?
Można, ale gdyby “to” nazywać hurtownią danych to było za mało, bo w tym przypadku mamy jeden system. Hurtownie danych nie służą do tego, żeby robić raportowanie z jednego systemu – to można zrobić w ramach tej jednej bazy. Tak naprawdę wartością hurtowni danych jest to, że ustalamy różne informacje i na ich podstawie dopiero dokonujemy analiz szerokich, nie wąskich. Tak jak bierzemy jeden system i analizujemy tylko jego – tylko bardzo szeroki, więc nie ma to zastosowania przy prostych aplikacjach czy małych firmach, które mają tylko dwa sektory – finansowy i sprzedaż. Jeśli jest sprzedaż, jest też sektor finansowy, zatrudniają kogoś, później jest magazyn, jakaś logistyka, itd. Wtedy to ma sens, ponieważ wszystkie te światy ze sobą scalamy i dokonujemy dość zaawansowanych analiz na podstawie tego, co posiadamy.
Czy mógłbyś nam opisać proces? Jak powstaje taka hurtownia danych?
Na początku jest analiza biznesowa – określenie wymagań biznesowych, które muszą zostać spełnione w ramach tej hurtowni danych – czyli jakie wartości dla biznesu zostaną osiągnięte. Później, w takiej analizie biznesowej powstaje jakiś dokument, który zawiera spis systemów, z których będziemy korzystać przy budowie hurtowni danych. Spis tych wymagań biznesowych, które muszą być spełnione, dzieli się na wymagania funkcjonalne i niefunkcjonalne. Niefunkcjonalne to te, które muszą być spełnione żeby zbudować tę hurtownię, czyli wszystkie systemy, oprogramowania, serwery i ludzie. Natomiast funkcjonalne to te, które chcemy osiągnąć – czyli to co, ma później być raportowane.
Czyli to są po prostu takie cele długodystansowe?
Tak; tylko czasami są podzielone na etapy. Pierwszy etap powiedzmy trwa od 3 miesięcy do roku – zbudowanie core’a takiej hurtowni i zaraportowanie pierwszej części wymagań funkcjonalnych, które są najbardziej potrzebne. Później są kolejne etapy. I to jest właśnie planowane na początku. Oczywiście może to ulec zmianie, rozszerzeniu lub obcięciu. To wszystko później zależy od tego, jakie są budżety, i jakie są nowe wymagania, bo biznes cały czas się zmienia. Czasami te hurtownie umierają, a czasami po prostu ewoluują w zupełnie coś innego.
Masz na myśli to, że projekt zostaje przerwany? Przykładowo: zaczęliśmy coś tworzyć, a biznes stwierdza: “Taki sposób nam się nie podoba”.
Tak, albo nawet “W ogóle nie mamy tego, co chcieliśmy mieć”. Nie wiedzieliśmy, że tego nie mamy, ponieważ analiza biznesowa to jest jedno, ale po takiej analizy biznesowej – spisaniu harmonogramu jak to ma wyglądać, kiedy ma być dowieziony –.powstaje też dokument systemowy, czyli wtedy taki analityk systemowy dostaje wymagania biznesowe i on je odnajduje we wszystkich systemach, które zostały wskazane. Wtedy jest etap sprawdzania czy my te informacje, o których mówi biznes w ogóle mamy. Bo bardzo często jest tak, że ten biznes nie wie, że czegoś nie ma i pomyśli, że ma. Analiza systemowa pokazuje nam co możemy z tych systemów wyciągnąć, co możemy z nich osiągnąć w strefie raportowej – i to urealnia nam wszystkie wymagania. Oczywiście tutaj kontakt z klientem musi być cały czas i potwierdzanie tego. Nie możemy sobie sami założyć, że coś zrobimy, bo później może nikt z tego nie korzystać. Bardzo często się tak dzieje, że to co zrobimy nie jest wykorzystywane. Dlatego, między innymi, do hurtowni danych dodaje się też taki system monitorowania, jakimi są zapytania najczęściej wykorzystywane. I czasami robi się je przy dużych systemach. Hit mapy, czyli dane, które są rzadko wykorzystywane, wrzuca się na wolniejsze systemy odczytu danych, jakieś taśmy, itd. Szybsze na dyski SSD, a takie “gorące” dane, które są bardzo często odczytywane są trzymane w ramie bezpośrednio np. na maszynach, żeby był bardzo szybki dostęp – chyba to jest teraz takie najszybsze. Po takiej analizie systemowej wychodzi architekt danych czy hurtowni danych.
Czy ty jesteś takim architektem?
Poniekąd. Modeluję również hurtownię danych. Jest kilka typów modeli: model Data Vault, Kimballowy. One spełniają te same funkcje, natomiast inne połączenie pomiędzy już fizycznymi tabelami w bazie danych czy to w Oraclu, SQL Serwerze, czy w Postgresie – tutaj dowolne DBMy możemy sobie podciągnąć i tam te tabele tworzyć – wszystko w zależności od tego, co będzie chciał klient, bo on definiuje również technologię, której chce używać. Architekt rozpisuje sobie to wszystko na poszczególne obiekty. W obiektach mogą być na przykład – tak jak rozmawialiśmy – tramwaj; osoba, ale wtedy jako o typie, że to jest pracownik; i dopiero stanowisko osoby – motorniczy. W taki sposób się to opisuje, a nie że to jest po prostu motorniczy. Raczej nie robimy takich szczegółowych obiektów, tylko uogólniamy. Później możemy dodać atrybuty opisujące ten obiekt. Człowieka możemy opisać na wiele sposobów: jaki ma koloru oczu, włosów, jego wzrost, waga, i tak dalej. I tak samo z każdym obiektem, który sobie możesz wyobrazić, które istnieje, robimy to samo.
Później, gdy tworzony jest taki model, są obiekty opisujące, ale są też obiekty, które zawierają informacje – i te dzielimy na wymiary i fakty. Wymiar to jest obiekt opisujący coś, tak jak kamerę, mikrofon, człowieka. Natomiast fakt to jest coś, co zawiera wszystkie zaistniałe sytuacje, np. idziesz do sklepu i wydajesz 50 zł na jakieś zakupy. I w tym momencie mamy informację o tym, że zrobiłeś zakupy za 50 zł i mamy np. obiekt z produktami – i możemy sobie podpiąć, że te 10 zł to było za to, a 40 zł za coś innego. I takie fakty opisywane są właśnie przez te obiekty. Fakty zawierają informacje ilościowe albo jakościowe. Najczęściej są to ilościowe; jakościowe bardzo rzadko się zdarzają, bo to są jakieś opisówki, np. do ankiet. Czyli jeśli ktoś wypełnia ankietę to w niej mamy 20 pytań zamkniętych a b c d – to wpada, ale są też opisówki – i taka miara jakościowa to już jest opis tego człowieka, odpowiedź na pytanie. Taki zestaw tabel może nam opisywać jeden system. I może to być np. zarządzanie ruchem tramwajów w Krakowie, może to być magazyn części.
I teraz to wszystko trzeba ze sobą połączyć. Wykonuje się pewnego rodzaju mapowanie pomiędzy tymi systemami, bo w systemie A pan Nikodem będzie pod identyfikatorem A, a w systemie B będzie pod identyfikatorem B. I teraz musimy mieć jakąś informację, tabelę łączącą, żeby to ze sobą współgrało – czyli jest wskazanie, że pan Nikodem z tej bazy to ten sam pan Nikodem z tamtej bazy. I wtedy możemy porównywać te dwa światy – jako “motorniczy z tramwajem” i “magazyn, który obsługuje ten tramwaj”. I to jest etap architektury, gdzie człowiek lub cały team, w zależności od stopnia skomplikowania i ilości osób zaangażowanych w projekt, modeluje to. I to zostaje później przekazane do programistów jako sam model, ale również wymagania systemowe, które zostały zebrane wcześniej.
A jak wygląda praca takiego developera?
To też w zależności od skomplikowania projektu i czy to jest podzielone na teamy, czy po prostu jest jeden team programistów, czteroosobowy powiedzmy, który to wszystko obsługuje. Jeśli są duże teamy, to raczej dostaje po prostu jakieś skrawki do wykonania, np. ma stworzyć zasilanie jednej tabeli lub ma stworzyć tę tabelę albo ją zweryfikować. Wszystko zależy od tego, czy jestem backendowym programistą czy frontendowym. Może głupio to zabrzmi, ale są takie podziały w większych projektach, gdzie jeden tak naprawdę programuje całość, a drugi to sprawdza. Zazwyczaj jest to w firmach bankowych, gdzie potrzeba dużej ilości strat, rekoncyliacji, itd. Tam jest dwukrotnie tworzona ta sama praca, żeby się upewnić, że wszystko jest w porządku.
Zasada czterech oczu. 😉 Weźmy przykład mojego zespołu. Jest 4 programistów i powiedzmy, że te poprzednie etapy zostały przeprocesowane i teraz dostajecie pierwsze swoje zadanie. Jak ono może wyglądać i jak będzie wyglądać Wasza praca?
Pierwszym zadaniem na pewno będzie stworzenie wszystkich obiektów hurtowni danych, czyli to, co zostało zaprojektowane przez architektów. Są po prostu tworzone puste obiekty, w których będą umieszczane dane na podstawie wszystkich wymagań – to jest pierwsza praca, którą należy wykonać. Później trzeba ustanowić połączenia do wszystkich zewnętrznych baz, z których będą pobierane informacje do hurtowni danych – i w tym momencie jest tworzony proces transformacji danych. Proces tzw. ETL, dzięki któremu wszystkie dane są przenoszone do hurtowni danych i jest tworzony cykliczny proces aktualizacji tych danych.
Tutaj dużo wspominamy o ETL-u, a może byś nam rozwinął czym jest jest sam proces i skąd pochodzi skrót?
Extraction, transformation, loading – czyli wyciągnij dane z systemu, przerób je w taki sposób, w jaki Ci się podoba do hurtowni danych – żeby pasowały do modelu, ale przy tym nie utrać żadnych informacji – i załaduj.
Populujemy nasz model przeciągając te dane z pozostałych baz danych i nasz model jest tam ustawiany. Czy już wtedy mogę dokonywać jakichś analiz, czy jest za wcześnie?
Tak, na pewno są zawsze robione pierwsze sprawdzenia z analitykami systemowymi. Jeśli już posiadamy jakiekolwiek dane na hurtowni, to musimy sprawdzić integralność tych danych, bo zakłada się klucze główne i obce do tabel. Zazwyczaj do wymiarów są główne, czasami obce – jeśli łączą się do innego wymiaru. Natomiast przy faktach są to zazwyczaj klucze jedynie obce, czyli te opisujące, do wymiarów bezpośrednio.
Co się dzieje, kiedy zostaje zatrudniany nowy pracownik? Powiedzmy, że przyszedł nam nowy motorniczy. Co trzeba zrobić żeby znalazł się w naszej hurtowni?
To był ten krok drugi u programisty – stworzenie tego procesu ETL. To jest proces cykliczny i tak naprawdę jego cykliczność możemy określić sami. Gdy są ustawiane procesy ETL-owe, to dane są dostarczane w czasie rzeczywistym. Hurtownie danych zazwyczaj są odświeżane raz dziennie. Czasami zdarza się, że z niektórych systemów potrzebujemy danych zagregowanych i zaciągamy ich na przykład raz w tygodniu, raz w miesiącu. Ale już sam widok, który nam wyrzuca te dane, jest zbudowany tak, żeby to był agregat. Później taki agregat sobie przechowujemy w hurtowni danych, prosto do celów raportowych.
A co się dzieje, kiedy wyjściowe bazy danych ulegną zmianie? Powiedzmy, że do przetwarzania bieżących danych potrzebujemy dostawić nowe kolumny albo jakąś usunąć, albo coś podmienić. Jak to afektuje hurtownię?
Cały proces powinien być ustawiony tak, że jeśli ucieka nam jakaś kolumna to najpierw taki zespół, który zarządza tą zewnętrzną bazą danych, powinien nas o tym poinformować, bo my nie jesteśmy w stanie przewidzieć, że nie ma kolumny. Możemy oczywiście robić zabezpieczenia, że na dany dzień zniknęła nam kolumna z tabeli lub cała tabela, i stworzyć mechanizm, który będzie wycinał poszczególne kawałki z procesu ETL. To też da się zrobić, ale musi być też informacja zwrotna, że coś takiego nastąpiło, bo biznes może oczekiwać np. informacji dość istotnej, która wyciekła z systemu. My, jako hurtownia danych i team który, buduje całą hurtownię, nie odpowiadamy za to, co możemy dostać, a czego nie możemy.
To jest zrozumiałe, bo trudno jest “jechać na samochodzie bez paliwa”.
Dokładnie. Częściej zdarza się, że po prostu ten proces ETL nie przejdzie – te dane się nie odświeżą w nocy czy w ciągu dnia. I ta sytuacja występuje bardzo często i to jest normalnie raportowane na każdej hurtowni danych.
Czy to jest tak, że przerywacie cały proces, czy po prostu jednego jakiegoś fragmentu nie wykonacie?
Zależy to od tego, czy jest to kluczowy proces do późniejszego oparcia o to raportów. Powiedzmy, że masz firmę, która sprzedaje produkty i te produkty ci się nie zasilą – to już nic się nie dowiesz dalej. Więc wtedy proces powinien być przerywany i wstecznie zasilany ten dzień, który się nie zasilił. Są też mechanizmy, które odświeżają daną datę raportową lub dane z danej daty – a to jest później różnie robione i tak naprawdę jest wiele do tego podejść, ale nie będę się zagłębiał. W każdym bądź razie, musi istnieć proces, który będzie w stanie odświeżyć jakiś zakres danych.
Hurtownie danych – od dawna ten temat jest wałkowany?
Tak naprawdę zaczęło się to w okolicach roku 90. Wtedy powstała pierwsza wersja języka SQL – SQL 92 – najbardziej popularny, na podstawie którego później zostały budowane rozszerzenia. Wtedy też powstał pierwszy model przechowywania danych, zaproponowany przez Inmona. On zakładał, że całość wiedzy o firmie, o przedsiębiorstwie, o świecie jest znana na początku – czyli wszystko wiemy na początku i to modelujemy. Okazało się to bardzo szybko błędnym założeniem, więc powstał model Kimballowy, który pozwalał na rozszerzanie i nie miał takiego podejścia. Później to ewoluowało i powstawały kolejne rodzaje modeli hurtowni danych.
Technologia, o której cały czas rozmawiamy jest już dosyć stara, bo mamy tam lata 90. Jaka jest przyszłość dla tej technologii? Czy to nie jest już coś starego, co pasowałoby zastąpić czymś nowym?
Myślę, że to się nie stanie, ponieważ już była taka próba. Oracle w swoim rozwiązaniu zaproponował odejście od języka SQL i zastąpienia go Javą, żeby zamiast tabel tworzyć klasy. Niestety się nie przyjęło, z racji tego, że już jest tak szerokie grono ludzi posługujących się tym językiem, że ciężko byłoby to wszystko zmienić. Jest cała infrastruktura oparta na tym. Dużo firm zainwestowało bardzo duże pieniądze, żeby można było w tym pisać. Oczywiście są jakieś ewolucje w chmurze, np. HQL. To cały czas ewoluuje, w zależności od tego, co mamy pod spodem. Natomiast większość rzeczy opiera się na tej samej logice – bo tak naprawdę operacje na zbiorach to algebra – więc tu tego nie zmienimy. W każdym aspekcie produkcyjnym życia, w tym co nas otacza, możemy zastosować hurtownię danych. Ostatnio coraz bardziej popularne stają się zegarki, które mierzą ci tętno, czas snu, itd. Teraz bardzo dużo firm nastawia się na to, że to będzie główne źródło ich dochodu. I tam dopiero będzie mnóstwo informacji pod analizę, zarówno zachowania ludzi, co później może się przełożyć np. na organizację miast, ale również pod względem medycznym – co już też jest wykorzystywane. Dla przykładu, starsi ludzie dostają takie zegarki, żeby monitorować ich tętno, stan zdrowia, itd. To wszystko spływa gdzieś na serwery i jest analizowane. Więc jeśli chodzi o przyszłość, to myślę, że w tym momencie celowałbym w takie rozwiązania.
Powiedzmy, że dostajesz jakiś projekt i klient mówi ci tylko, jaki chciałby mieć efekt końcowy. Jak wygląda dobór narzędzi? Czy w trakcie swojej pracy albo w trakcie istnienia produktu możesz je zmieniać?
Jeśli byłbym klientem to mógłbym dobierać. Tak naprawdę to nie zależy ode mnie. Ja dobieram projekt, gdzie jest taka technologia, w której czuję się najlepiej lub w której pracowałem. Doborem oprogramowania, na którym w danym projekcie się pracuje jest raczej klient. Czyli on sobie dobiera to dowolnie i później szuka wykonawców.
A czy w obrębie jednej dużej hurtowni wykorzystuje się różne technologie? Czy to jest przeważnie tak, że decydujemy się na jednego dostawcę technologii?
Mogą być różne. Na przykład, pracowałem nie tak dawno w projekcie, w którym były wykorzystywane dwie technologie. Pierwsza to był Hadoop i on przetwarzał masę danych. To było ponad 10 lat informacji. Proces ETL trwał około 12-14 godzin. To było na plikach rozproszonych, więc to jest zupełnie inne inne ładowanie. Natomiast później, po tym procesie, startował proces na Oraclu, który przetwarzał ostatni rok. I tak naprawdę dopiero ten ostatni rok był do biznesu – czyli jeśli biznes by powiedział OK, ale potrzebujemy danych z dwóch lat, no to my ich dokładaliśmy. Ten proces ETL był zmieniany. Dzieliło się to na dwa narzędzia: pierwszy Hadoop i drugi, postawiony na tym Oraclu. Natomiast gdzieś to się tam zaczęło zacierać i w pewnym momencie nie wszystkie dane zaczęły lądować na Hadoopie, część od razu na Oraclu. Ale to już są typowo decyzje biznesowe, na które ty, jako programista analityk biznesowy systemowy, nie masz kompletnie żadnego wpływu.
Czyli gdybyś był taką osobą decyzyjną to nie zdecydowałbyś się na dobór różnych technologii?
Ja nie. Ja zawsze lubiłem pracować w jednym. Jeśli zaczynamy projekt np. w Oracle i budujemy na tym hurtownię danych, to tam zostańmy. Natomiast jeśli chodzi o warstwę późniejszą, raportową, o której jeszcze nie mówiliśmy – to tutaj jest już dowolność, bo warstwy raportowe mają sterowniki do wielu systemów hurtownianych.
To w sumie jestem teraz tym zainteresowany i zaintrygowany, bo tak naprawdę jedna tabela z danymi niewiele mi mówi. Ja jeżeli mam takie suche dane to raczej tak niewiele bym z tego wyciągnął i przydałaby się jakaś wizualizacja, jakiś sposób przedstawiania tych danych. Czy to też należy do waszych obowiązków?
Moich tak. Można powiedzieć, że jestem osobą, która może wyjść od analizy biznesowej, poprzez systemową – zaprogramowanie, stworzenie warstwy raportowej i oddanie tego do biznesu z szeregiem szkoleń jak tego używać. Więc przeszedłem w swojej ścieżce kariery przez wszystkie te procesy, również z modelowaniem architektonicznym. Natomiast warstwa raportowa obowiązuje nas jako programistów hurtowni danych i musimy przynajmniej stworzyć proste raporty w Excelu, żeby sobie te dane zweryfikować. Później ktoś się specjalizuje już w samym raportowaniu, tworzeniu wizualizacji, dashboardów, raportów do zarządu – to ma być ładne, kolorowe, responsywne.
Czy jest też ten podział, o którym wcześniej wspomniałeś? Tzw. programista backendowy i frontendowy?
Jeśli chodzi o takich programistów to są oni obecni raczej w dużych projektach, na dwie pary oczu. Natomiast jeśli chodzi o takie luźniejsze stwierdzenie, to tak – można powiedzieć, że ten backendowy tworzy wszystkie obiekty, ładuje tam dane i robi prostą analizę, np. czy to, co dostał ze źródła, ma na hurtowni danych, bądź czy suma przychodu w danym roku mu się zgadza, czy wszystko przeszło, itd. I to robi sobie powiedzmy w Excelu lub w innym narzędziu, które lubi. Później taka osoba, czyli programista, który korzysta z tej warstwy hurtownianej i tworzy na jej podstawie raporty, musi także potrafić stworzyć zapytania. Musi znać tę hurtownie, cykliczność jej zasilania, wiedzieć gdzie lądują poszczególne dane, itd. I dopiero wtedy zaciąga sobie odpowiedni set danych, który raportuje. Tutaj następuje duża konsolidacja – taka osoba, która raportuje, powinna posiadać też wiedzę analityka biznesowego, który był na początku, ponieważ raportowo również przedstawiamy już typowo informacje biznesowe.
To rozumiem, że musi wiedzieć co ma przedstawić klientowi – jaki ma być z tego efekt końcowy.
Tak, a najważniejsze jest to, żeby klient wiedział co chce. 😉
Z tym są czasami problemy. 😀 Jakie wyzwania spotykasz w swojej pracy?
W hurtowni danych największym wyzwaniem była praca na bardzo dużej ilości danych, wierszy. “Duża” ilość danych to są miliardy, bo miliony to się łatwo obsługuje. To były kwestie optymalizacyjne, gdzie mieliśmy ponad 800 mld wierszy transakcyjnych i musieliśmy z tego wyciągnąć jakąś informację. Proces ich przetwarzania na maszynach, które były dostępne, trwał od 18 do 24 godzin – samego przetwarzania. Jeśli popełniłeś błąd analityczny na samym początku (czyli jak coś sobie źle wymyśliłeś lub źle zaprogramowałeś), a potem go puściłeś, to straciłeś od 18 do 24 godzin na to, żeby się to przeliczyło i dopiero po tym czasie widziałeś, że ten drobny błąd się tam znajduje.
Rozumiem Twój ból, bo czasami jak jest coś irytującego, co muszę zmienić i chciałbym już sprawdzić czy to działa, to wolę zamiast tego zmienić jakąś małą rzecz. Puścić, sprawdzić czy się wywaliło lub gdzie się wywaliło, dodać sobie jakieś logi. Rozumiem, że w Twoim przypadku to by nie działało?
Nie, bo nie mogłem sobie na małej próbce danych sprawdzić czy wartość mi się zgadza.
Czy w waszej pracy jest miejsce na testy?
Tak, oczywiście, że jest miejsce na testy. 😉 Testy są robione na hurtowni danych i na raportach. To jest nieodłączny element każdego systemu informatycznego i tutaj również są robione.
Wspomniałeś o niektórych procesach, które potrafią trwać paręnaście godzin. Jak wygląda wtedy długość tych testów i czy jest ich jakiś podział? Np. na testy jednostkowe, kiedy testujesz bardzo małą funkcjonalność; integracyjne, podczas których łączysz bazy z innymi bazami, itd.
Jednostkowe wykonuje się dość rzadko, bo tu jednak pracuje się na danych, których nie sprawdzasz. Można robić oczywiście code review programisty, żeby zobaczyć, czy zebrał odpowiednie dane, czy ten kod jest optymalny, itd. Natomiast jeśli chodzi o testy hurtowni danych, to jest raczej ten proces ETL, który sprawdza, czy wszystkie dane przeszły, bo to jest bardzo istotne, żeby mieć cały zestaw danych. Później sprawdza, czy w tym zestawie danych nie ma luk, bądź czy nie wpadają nam jakieś wartości niechciane. Czyli sprawdzamy proces wytwórczy programisty, ale to już, powiedzmy, na grubych klockach.
A czy też występuje tzw. “mockup’owanie”? Powiedzmy, że nie chcesz tak naprawdę podłączać się do jakiejś konkretnej bazy danych, bo tam są dane wrażliwe – wtedy nie połączysz się bezpośrednio?
To jest tak, że my czasami musimy mieć strukturę, czy jakieś informacje z takich baz danych i one są anoninimizowane.
A testy end-to-end też wykonujecie?
Tak, to są takie testery rekoncyliacyjne, ale one już są robione typowo w instytucjach finansowych.
Damian, wpadam jutro do Ciebie na interview. Co powinienem umieć, żebyś mnie zatrudnił?
Powinieneś się w jakiś sposób posługiwać bazami danych – wiedzieć jak je tworzyć, znać jakiś język do tworzenia baz danych. SQL jest jeden, ale są różne odmiany w zależności od dostawcy oprogramowania. Oracle różni się od SQL-a. Powinieneś mieć jakiś zakres wiedzy odnośnie raportowania takich danych oraz w jakim narzędziu możesz to zrobić – fajnie by było, jakbyś znał Excela, ale to prawie każdy zna. To jest chyba najbardziej popularny system, gdzie możesz coś zrobić z danymi. No i chęć do dalszej nauki, bo tak naprawdę jeśli byś aplikował na stanowisko typowo programisty, to to wystarcza.
A jeśli bym chciał się dalej rozwijać w tym zakresie? Czego będę się uczył w nowej pracy?
Jeśli byś się chciał rozwijać to samo programowanie baz danych będziesz lepiej ogarniał, więcej tego robił, poznawał nowe technologie, metody, modele, itd. Więc tutaj jest pole do popisu na tej technicznej ścieżce. Później możesz rozwijać to dalej i zostać leadem technicznym i wspomagać wszystkich tych programistów w budowaniu procesu i baz. Natomiast jest jeszcze alternatywna ścieżka – biznesowa. Oprócz tego, że jesteś techniczny i potrafisz coś zrobić, to jednak ustawiasz się frontem do klienta, czyli poznajesz jego biznes, uczysz się go, zaczynasz rozumieć te dane, które przechowujemy w hurtowni. Próbujesz robić analizy biznesowe, pomagasz klientowi w formułowaniu jego wymagań, itd. Więc tu można się rozdzielić. Wiadomo, w biznesowej jest więcej kontaktu z ludźmi, ale nie odcina Cię całościowo od programowania – to zawsze gdzieś tam zostaje i tę wiedzę musisz posiadać. Więc zaczyna się typowo technicznie pracę – od tego żeby, poznać te wszystkie podstawy – a później możesz to rozszerzać o wiedzę biznesową, w zależności od tego jaki to jest biznes, bo wiadomo – jest tego mnóstwo.
A czy będę w stanie być dobrym programistą bez dobrej znajomości biznesu?
Jeśli ktoś dostarczy Ci odpowiednie wymagania to tak, będziesz dobrym programistą – po prostu wykonasz tę pracę, która zostanie Ci zlecona, sprawdzisz sobie np. na grubych liczbach, czy Ci się zgadza, czy zasilanie zostało wykonane i czy raport został poprawnie zbudowany – tak, dasz radę. Jednak, żeby bardziej rozumieć i wychodzić z propozycją dla klienta o tym, co może być dla niego atrakcyjne w takiej hurtowni danych i co może mu pomóc rosnąć na rynku, to tutaj wiedza biznesowa jest niezwykle potrzebna.
Mam wrażenie, że jest jeszcze wiele informacji, z którymi mógłbyś się tutaj z nami podzielić, dlatego mam nadzieję, że zgodzisz się kiedyś nas jeszcze odwiedzić i opowiedzieć nam coś więcej na temat hurtowni danych.
Oczywiście, możemy się spotkać i wejść w temat bardziej szczegółowo.
Dziękuję widzom za oglądanie. Zachęcam Was do subskrypcji i oglądania kolejnych odcinków!
______________________________________________________________
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉 💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK 🌏
Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox
Obserwuj nas na social media: 🚀
LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ
