Analityka danych & big data.

Trudno sobie dzisiaj wyobrazić bloga o technologii, na którym nie byłoby choć jednego artykułu na temat dużych zbiorów danych (big data). Dlatego już na samym początku swojej przygody z pisaniem, zdecydowałem się "zahaczyć" właśnie o ten temat. Wypadałoby być może zacząć od jakichś definicji, ale tych z Was którzy właśnie tego poszukują niestety będę musiał rozczarować. W tym artykule opiszę architekturę, jaka często wykorzystywana jest w środowiskach do analityki danych w wielu organizacjach. Opowiem również jak ta architektura się zmienia w kontekście dużych zbiorów danych. Daj proszę znać, czy mi się to udało.

Dlaczego patrzymy w kierunku wykorzystania dużych zbiorów danych?

Powodów jest wiele i pewnie każda organizacja będzie miała w tym zakresie swoje własne priorytety. Ważne moim zdaniem, aby przy wdrażaniu tego typu projektów robić to w odpowiedzi na konkretne wymagania biznesowe, a nie dlatego, aby móc się pochwalić rozwiązaniem big data w swoim środowisku, dla którego później "być może znajdziemy jakieś zastosowanie".

W takim razie, jakie są te biznesowe cele i wymagania? One w zasadzie nie zmieniają się od lat. Zmienia się natomiast technologia i co za tym idzie, możliwości z jakich możemy korzystać, aby te cele zrealizować. Już od dłuższego czasu mówi się między innymi o: 

• powiększaniu przychodów poprzez lepsze zrozumienie, czy nawet przewidywanie zachowań klientów, korzystając przy tym z tzw. analityki predykcyjnej ("co się wydarzy?") oraz analityki preskryptywnej ("co powinniśmy zrobić?"),
• monetyzowaniu posiadanych w organizacji danych przechowywanych w wielu różnych źródłach, łączenie tych danych i dostarczanie nowych perspektyw, bardziej precyzyjnych informacji oraz szerszego kontekstu,
• zwiększanie efektywności operacyjnej, poprzez przewidywanie cyberataków, oszustw finansowych, awarii sprzętu (tutaj wkraczamy dodatkowo w świat IoT), ale również poprzez redukcję kosztów utrzymania np. hurtowni danych,
• poprawianie poziomu zadowolenia klientów np. poprzez stosowanie automatycznych rekomendacji, gdzie znowu z pomocą przychodzi analityka preskryptywna

Przykład: wdrażamy robota-doradcę.

Wyobraź sobie, że w naszym przykładowym przedsiębiorstwie powstała biznesowa inicjatywa wdrożenia robota-doradcy w zakresie oferowania usług i produktów klientom firmy. Przy czym, pisząc robota, mam tutaj na myśli zautomatyzowane oprogramowanie, które potrafi doradzać, korzystając z:

• analityki opisowej (np.: tradycyjne historyczne raporty i analiza 360^o naszego klienta)
• analityki predykcyjnej (np.: przewidywanie trendów i zachowania rynku)
• analityki preskryptywnej (np.: silnik rekomendacji)

Abyśmy takie moduły analityczne mogli uruchomić w ramach naszego projektu robota-doradcy i aby spełniały one swoje zadanie, musimy najpierw dostarczyć odpowiednich danych do analizy i upewnić się, że dane te będą zawsze gotowe na czas. Dlatego, realizując taki projekt, najprawdopodobniej będziemy musieli:

• zbudować tzw. "jezioro danych" (data lake), w którym dane będą przechowywane i przetwarzane,
• zagwarantować mechanizmy, które pozwolą na wzbogacanie danych wpływających i wypływających z tego "jeziora" w sposób strumieniowy,
• dostarczyć technologię, pozwalającą na eksplorację dużych zbiorów danych, które są bardzo dynamiczne i zmieniają się bardzo szybko,
• umożliwić budowanie tematycznych mini hurtowni danych (data mart) i ich dostarczanie na żądanie naszym interesariuszom (np. liniom biznesowym wewnątrz naszego przedsiębiorstwa).

To oczywiście na koniec oznacza dla nas konieczność zaimplementowania konkretnych rozwiązań i produktów oraz wdrożenia konkretnych technologii, o których tutaj jednak nie będę pisał, bo nie taki jest cel tego artykułu. Warto przy tym pamiętać również o uwzględnieniu wszystkich potrzebnych źródeł danych - systemów, z których będziemy czerpać dane do ich dalszej analizy (dane o klientach, dane finansowe, dane marketingowe, dane z portali społecznościowych i prawdopodobnie wiele innych).

Jak to wyglądało kiedyś i jak wygląda dzisiaj jeszcze w wielu przedsiębiorstwach i organizacjach?

Architektura, którą można zobaczyć w zasadzie w większości organizacji, bazuje i ogranicza się do typowych i tradycyjnych źródeł, z których dane poddawane są analizie biznesowej. Są to z reguły transakcyjne systemy biznesowe (różne w zależności od rodzaju prowadzonego biznesu), systemy CRM, ERP, systemy finansowe, systemy kadrowe i wiele, wiele innych. W procesie analizy danych przetwarzanych i przechowywanych w tych systemach, wykorzystywane są hurtownie danych. Dlaczego? Przede wszystkim, ponieważ:

• nikt nie będzie ryzykował kariery, aby analizować te dane bezpośrednio w transakcyjnych systemach produkcyjnych przedsiębiorstwa (w systemach typu OLTP),
• chcemy, aby analiza ta była efektywna i wydajna oraz aby przyniosła pożądane rezultaty i dlatego musimy wykonać pewnego rodzaju transformacje modelu danych z "transakcyjnego" do "analitycznego". Najprościej mówiąc, chcemy, aby dane nadawały się do zapisania w schemacie, wykorzystywanym w hurtowni danych (w systemie typu OLAP).

Ponadto zapytania naszych użytkowników biznesowych, dla których analiza jest wykonywana, często wymagają zebrania danych z wielu różnych źródeł i systemów, dlatego ma sens zapisanie ich w centralnym repozytorium, jakim jest nasza hurtownia danych. Przy czym warto pamiętać, że centralne repozytorium nie oznacza tutaj utrzymywania tylko jednej hurtowni danych. Organizacje zazwyczaj mają takich hurtowni wiele.

To co widzisz na powyższym rysunku, to logiczny schemat takiej architektury. Mamy tutaj przykładowe systemy transakcyjne (CRM, ERP, HR), z których ładujemy dane do hurtowni danych (EDW - Enterprise Data Warehouse). W procesie tym wykorzystujemy narzędzie ETL (Extract Transform Load), które właśnie m.in. pozwala wykonać opisaną wcześniej transformację danych. Jest to również narzędzie wykorzystywane do integracji danych oraz do tworzenia tematycznych hurtowni danych (DM - Data Mart). W nich przechowujemy już tylko ograniczone zbiory danych, potrzebne na przykład określonym liniom biznesowym lub departamentom. Tak przygotowane dane mogą być dalej analizowane za pomocą narzędzi BI (Business Intelligence), które są wykorzystywane bezpośrednio przez użytkowników biznesowych lub przez IT na żądanie tych użytkowników. Z kolei odpowiedzi na pytania, które zadają Ci użytkownicy biznesowi, dostarczane są w tych narzędziach zazwyczaj w postaci raportów, wizualizacji lub paneli informacyjnych (dashboard).

Co się jednak stanie, gdy użytkownik biznesowy będzie chciał zadać pytanie spoza zdefiniowanej wcześniej listy? Cały proces przygotowania danych, aby dostarczyć żądaną treść i odpowiedź na to nowe zapytanie jest bardzo czasochłonny. Z różnych obserwacji wynika, że przygotowanie danych do analizy biznesowej stanowi aż 80% czasu całego procesu. Jest to na pewno jedno z poważniejszych wyzwań i wpływa na ostateczne koszty rozwiązania. Jest to również jeden z wielu powodów, dla których powyższa architektura w wielu organizacjach ewoluuje, albo już wyewoluowała w kierunku opisanym poniżej.

Kierunek zmian.

Ewolucja ta spowodowana jest również pojawianiem się nowych źródeł danych. Mowa tutaj o systemach, w których przechowywane są dane niestrukturalne lub semi-strukturalne, takie jak pliki, logi, audio, video, posty w portalach społecznościowych. Jest to zupełnie inny rodzaj danych, niż te, z którymi mamy do czynienia w przypadku systemów transakcyjnych. Tam przechowujemy dane strukturalne, czyli dane uporządkowane w tabelach, wierszach i kolumnach.

Ale dlaczego nie wykorzystać posiadanej już hurtowni danych i za pomocą wspomnianych wcześniej narzędzi integracji danych ETL nie uzupełnić jej danymi z nowych źródeł? Niestety tradycyjne hurtownie danych nie są przystosowane do przechowywania danych niestrukturalnych. W związku z tym taka integracja często jest albo w ogóle niemożliwa, albo bardzo kosztowa. Dlatego w przypadku nowych źródeł danych wykorzystywane są nieco inne narzędzia i mechanizmy, natomiast logika działania jak widzisz na poniższym rysunku jest bardzo podobna. A podobieństwo to wynika z tego, że niezależnie od rodzaju danych i źródeł, z których one pochodzą, użytkownik biznesowy "na koniec dnia" chce otrzymać ten sam rezultat, czyli odpowiedzi na swoje zapytania w postaci na przykład raportów, wizualizacji lub paneli informacyjnych (dashboard).

Powyżej widzisz logiczny schemat architektury, w której rolę "hurtowni danych" pełni Hadoop i/lub baza danych NO SQL (Not Only SQL). Narzędzia te są znakomicie przystosowane do przechowywania i przetwarzania dużych zbiorów danych niestrukturalnych. Analogicznie jak na poprzednim rysunku, w tematycznych hurtowniach danych (ADB - Analytical DB) przechowywane są zbiory danych przygotowywane do analizy na przykład dla określonego klienta biznesowego.

A czy nie byłoby idealnie, gdybyśmy byli w stanie połączyć te dwa światy? Problemem mogą być tutaj stosowane narzędzia do integracji danych (ETL) oraz systemy do analityki (BI). Nie wszystkie umożliwiają pracę w tak szerokim zakresie. Istnieją oczywiście wyjątki, które pozwalają na wdrożenie takiej architektury, jak ta zaprezentowana na rysunku poniżej.

A na koniec.

Chcę zostawić Cię z kilkoma przemyśleniami i wyzwaniami, na które moim zdaniem warto zwrócić uwagę:

• Jakie narzędzia wykorzystać do ładowania danych do Hadoopa? Ekosystem tych narzędzi jest bardzo duży i bardzo szybko się zmienia.
• Jakiego mechanizmu ETL użyć do połączenia tych dwóch światów? Chcemy analizować jednocześnie dane strukturalne z hurtowni danych jak i dane niestrukturalne przechowywane i przetwarzane w Hadoopie.
• Jak optymalnie wykorzystać samego Hadoopa? Nie jest to łatwe środowisko i wymaga dużych umiejętności programistycznych. Z kolei programowanie wymaga czasu, a dla biznesu czas wdrożenia rozwiązania oznacza często, czy zdążymy z danym produktem lub usługą przed naszą konkurencją.
• Jak odpowiedzieć na wymagania biznesu, który nie chce kolejnego narzędzia BI lub co więcej wymaga, aby analitykę taką realizować wewnątrz aplikacji biznesowej? Musimy pomyśleć jak zintegrować moduł do analityki biznesowej z naszą aplikacją i czy dane narzędzie w ogóle na to pozwoli.
• Jak sprostać wymaganiom użytkownika biznesowego w zakresie czasu oczekiwania na wynik analizy szczególnie w kontekście responsywności Hadoopa? I tutaj znowu wyzwaniem jest mnogość narzędzi i częstotliwość zmian w ekosystemie Hadoopa. Chcemy wybrać takie rozwiązanie, które sprawi, aby zapytania spoza wcześniej zdefiniowanej listy obsługiwane były w akceptowalnym czasie. Aby ominąć ograniczenia, czasami stosuje się podejście, w którym tworzy się dodatkowe zbiory danych, przechowywane wewnątrz pamięci bezpośrednio w rozwiązaniach analitycznych. Pytanie, czy rozwiązując w ten sposób jeden problem, nie tworzymy przypadkiem kolejnego, związanego z brakiem kontroli nad danymi, ryzykiem utraty ich spójności oraz dodatkowymi trudnościami w zarządzaniu.

Podstawowe pytania jakie nasuwają się często w momencie, gdy zaczniemy myśleć o wdrożeniu tego typu architektury dla naszego systemu analityki biznesowej, to:

• Czy mamy umiejętności do zrealizowania projektu (szczególnie w kontekście Hadoopa), czy mamy je wewnątrz organizacji, gdzie je znaleźć?
• W jakim czasie osiągniemy pożądaną wartość, szczególnie jeżeli będziemy musieli sporo tego czasu przeznaczyć na programowanie komponentów rozwiązania?
• Jak zbudować środowisko do analizy danych niestrukturalnych, które będzie bardziej elastyczne niż to, do czego jesteśmy przyzwyczajeni w przypadku tradycyjnych hurtowni danych (o mocnym ukierunkowaniu na znalezienie odpowiedzi na konkretne rodzaje zapytań i wykonywanie konkretnych, zdefiniowanych wcześniej zadań analitycznych). Generalnie wolelibyśmy nie "zamykać się" w ten sam sposób w przypadku analizowania danych niestrukturalnych.