Ten wpis otwiera serię poświęconą zagadnieniu wystarczająco interesującemu, żeby poświęcić mu kilka wpisów, a zarazem wystarczająco niszowemu, żeby nadawało się na bloga xpil.eu.
W odróżnieniu od poprzednich serii, które pisałem od przypadku do przypadku i od kaprysu do kaprysu, tym razem planuję solidnie przyłożyć się do zagadnienia i stworzyć coś od deski do deski, porządnie i bez "iścia" na łatwiznę. Nie gwarantuję, że się uda, ani że będzie ciekawie lub mądrze. Ale postaram się postarać 🙂
Łączna liczba wpisów w tej serii jeszcze nie jest mi do końca znana. Prawdopodobnie około dwunastu, plus minus dwa, ale to tylko strzał w ciemno. Może uda mi się zamknąć w pięciu, a może rozrośnie mi się do dwudziestu, albo wręcz zrobię z tego jakąś stałą serię bez wyraźnego zakończenia.
Nie będę się spieszyć. Zacznę od tempa jednego odcinka na tydzień, a potem się zobaczy. Pośpiech jest wskazany przy łapaniu pcheł. Nie wisi nade mną żaden termin, nie marudzi mi wydawca-kat-oprawca, a moja rodzina nie zgłodnieje, jak sobie zrobię miesiąc przerwy.
Ponadto dopuszczam do siebie myśl, że seria będzie ewoluować pod wpływem interakcji z Czytelnikami. Wszelkie uwagi, opinie, pomysły i podpowiedzi będą uczciwie brane pod uwagę. Przypuszczam, że wystartuję od wersji "minimalnej", a więc takiej, która pokrywa najważniejsze kwestie, nie będąc jednocześnie opasłą, nudną encyklopedią.
Najważniejsze jednak - nie zamierzam udawać, że opisywane przeze mnie rozwiązanie jest najlepszym z możliwych. Dobór właściwego narzędzia jest ważniejszy od jakości samego narzędzia. Przypuszczam więc, że grupa docelowa tej serii będzie raczej wąska.
Zapraszam do lektury.
***
Hurtownia danych to zwierzę o wielu twarzach. Nie ma jednej, porządnej definicji. Nie ma z góry ustalonych zasad ani przepisów. Albo raczej: jest ich zbyt wiele. Krótko mówiąc, ile różnych faktycznych implementacji hurtowni danych, tyle metodologii, architektur i definicji.
Jedno jest - lub przynajmniej powinno być - wspólne dla każdej hurtowni danych. Powinna ona umożliwiać spójne raportowanie, używając niejednolitych, rozproszonych, być może niekompatybilnych ze sobą źródeł danych, w celu wspierania podejmowania decyzji na różnych poziomach korporacyjnej hierarchii. Źródła danych mogą być obarczone różnymi stopniami zaufania i jakości, mogą mieć dane mniej lub bardziej aktualne, mogą być dostępne stale lub tylko w określonych porach dnia, miesiąca, roku. I tak dalej.
Komu hurtownia danych jest potrzebna?
Zamiast "hurtownia danych" będę od teraz używał określenia DW - z angielskiego Data Warehouse. Czasami używa się skrótu EDW: Enterprise Data Warehouse, ale w naszym przypadku DW jest lepsze. Dlaczego? Żeby nam się skróty nie pogryzły - proszę czytać dalej, wszystko się wyjaśni.
DW przydaje się w dużych przedsiębiorstwach. Przy czym chodzi tu nie o wielkość fizyczną, tylko o stopień złożoności informacyjnej firmy. Warzywniak pana Janka z DW nie skorzysta, bo to biznes prosty i przejrzysty. Pan Janek doskonale wie, o co w nim chodzi i ma w głowie pełen obraz wszystkich "procesów biznesowych", jakie w nim zachodzą. Ale już na przykład średniej wielkości bank może potrzebować DW, bo ma dział kadr, dział obsługi klientów indywidualnych, korporacyjnych, kredyty, lokaty, rachunkowość, marketing, administrację, kantynę, pana Rysia od BHP, pana Władzia od audytów, pana Stasia od kibelków, panią Krysię od parzenia kawy i tak dalej, i tak dalej. Ma oddziały w różnych lokalizacjach, województwach, państwach. Przepisy bankowe, podatkowe, kadrowe i Bill jeden wie jakie różnią się w poszczególnych regionach między sobą. Ilość wewnętrznych procesów i zależności robi się niepokojąco duża. Szefowie poszczególnych działów niechętnie dzielą się informacją z kolegami, bo co rok walczą o większy kawałek budżetu dla swojego działu. Każdy buduje na swoim podwórku "systemy" do "raportowania" (na ogół w Excelu), szefostwo banku ma jakieś tam pojęcie o tym, co się w firmie dzieje, ale nie ma "porządnego", całościowego wglądu w całość. Albo mają, ale dopiero po tym, jak hektar audytorów lub sekretarek pozbiera owe raporty w Excelu do kupy i jakoś tam je scali w jedną, lekko chwiejącą się całość, który to proces zajmie tyle czasu, że jak już jest gotowy, szefostwo widzi obraz sprzed trzech miesięcy. I apiat' trzeba powtarzać, ku rosnącej frustracji różnych wyżej lub niżej postawionych ludzi.
Tymczasem DW umożliwia - o ile się ją prawidłowo wdroży rzecz jasna - wgląd we wszystkie procesy biznesowe na bieżąco, bez opóźnień (lub z niewielkimi, dobrze zdefiniowanymi i akceptowalnymi opóźnieniami rzędu pojedynczych dni), dzięki czemu wszyscy zainteresowani mają klarowny obraz sytuacji i mogą podejmować lepsze decyzje w krótszym czasie, ku chwale Korporacji.
Jest jeszcze jeden ważny aspekt DW: z punktu widzenia projektów IT prowadzonych w firmie, projekt DW w zasadzie nie kończy się. To nie jest system księgowy, który się wdraża i się go potem używa bez wprowadzania dalszych zmian (z wyjątkiem, być może, zmian wynikających z nowych przepisów). To nie jest arkusz kalkulacyjny, który można zrobić a potem sprzedawać firmom. To nie jest odtwarzacz MP3, żelazko ani krzesło, które raz zaprojektowane będą służyć w tysiącu kopii użytkownikom do końca dni swoich.
Nie.
DW to proces. Stale rozwijający się, doskonalony i rozbudowywany proces, który rośnie wraz ze wzrostem przedsiębiorstwa. Prowadzony porządnie może dać doskonałe efekty stosunkowo niewielkim kosztem. Prowadzony bałaganiarsko prawie na pewno pochłonie mnóstwo kasy, a na koniec sponsorzy będą wiedzieć mniej, niż na początku...
Ta seria wpisów ma za zadanie pokazać, jak - od strony technicznej - powinien wyglądać porządnie wykonany projekt hurtowni danych. Skupimy się głównie na logice i organizacji danych, ale otrzemy się również o inne zagadnienia (w tym także nietechniczne).
Ponieważ - jak napisałem na samym początku - nie istnieje jeden "złoty" sposób implementowania DW, skupię się w tej serii na jednym, bardzo konkretnym wariancie, który znam od podszewki. Co więcej, pochwalę się, że pracowałem w co najmniej dwóch dużych firmach, w których projekt DW był tą metodologią wdrożony i odniósł bezapelacyjny sukces (co niestety nie zdarza się zbyt często - widziałem w życiu więcej nieudanych projektów DW, niż udanych). W obydwu przypadkach brałem udział w implementacji DW od początku do końca ("końca" rozumianego tu jako zakończenie wszystkich kluczowych modułów DW oraz pozostawienie projektu w stanie umożliwiającym dalszy stabilny rozwój).
Za tydzień omówimy sobie kilka podstawowych pojęć, które (mam nadzieję) przydadzą się w dalszej części serii.
Nie wiem czy dobrze zrozumiałem. Ale dam przykład. Aktywacja modemu przez aplikacje c spire. Ja podaje numer kl do c spire natomiast c spire wysyła zapytanie do dw kto to jest ten 16947571 a dw odsyła że to Anicenta Klocek posiadająca Internet 250mb/s i wtedy c spire aktywuje modem z ww prędkością. A do DW mogą wysłać zapytanie inne aplikacje lub użytkównicy.
Nie do końca, ale blisko. DW nie jest systemem transakcyjnym tylko (pi x oko) “przed-raportującym”. Dane w DW prawie zawsze płyną w jednym kierunku (od systemów źródłowych do warstwy raportującej). Celem DW nie jest zwracanie danych o pojedynczych klientach czy transakcjach do innych, zautomatyzowanych systemów, tylko zbieranie danych z różnych systemów źródłowych, a następnie przygotowywanie ich do spójnej, łatwej do “konsumpcji” przez człowieka (lub przez docelowy system raportujący) postaci.
O! Będę czytać!
Czasem pewnie nawet więcej, niż raz, jak za pierwszym nie dotrze 😀
Czeszę się niezmiernie. Temat jest naprawdę wielki, a moja seria jak na razie pokrywa tylko najgłębsze podstawy, ale jeżeli będzie zainteresowanie, może się rozrośnie do czegoś większego. Pożyjemy – zobaczymy!