Jak nowe potrzeby biznesowe wpływają na transformację architektur Big Data

Jaka jest rola architektury systemowej w projektach Big Data? Jak dokonać jej transformacji w odpowiedzi na pojawiające się nowe potrzeby biznesowe? Na te i wiele innych pytań odpowiemy w tej części naszego cyklu.

W poprzednich artykułach z serii „Odczarowując Big Data” pisaliśmy m.in. o tym, w jaki sposób wdrożyć zaawansowaną analitykę, co jest miarą sukcesu prognozowania, dlaczego technologia Apache Hadoop zmieniła krajobraz Data Management w wielu organizacjach oraz w jaki sposób architektura Data Lake umożliwia gromadzenia i przetwarzanie dużych zbiorów danych przy zachowaniu odpowiednich standardów bezpieczeństwa i zarządzania danymi.

Data Lake, czyli idziemy w kierunku Data-Driven Business

Obserwujemy obecnie jak decyzje odnośnie budowy Data Lake – podjęte w ciągu ostatnich paru lat w wielu organizacjach – wpływają na zmianę ich modelu biznesowego w kierunku Data-Driven Business. Oznacza to zmianę kultury organizacyjnej, w kierunku tej polegającej na mocnym zorientowaniu na efektywne wykorzystanie danych w procesach biznesowych, ale nie tylko. Widoczne jest to także na poziomie parametrów ilościowych. Coraz więcej osób podejmuje decyzje w warunkach wiedzy, w oparciu o dane. Stąd także większa liczba osób, które – na potrzeby wsparcia decyzji – muszą te dane przekształcać w informacje. Technologia dojrzała, a więc pojawiły się mechanizmy umożliwiające nadanie dostępu szerszemu gronu odbiorców.

Na poziomie technicznym jeziora danych wypełniane są coraz większą ilością informacji i konieczna jest jego rozbudowa o nowe węzły. Dane są wykorzystywane produkcyjnie, co powoduje potrzebę budowy dodatkowych środowisk, z jednej strony na potrzeby procesu DTAP, z drugiej jako Data Recovery dla zapewnienia ciągłości działania na wypadek awarii całego data center. Data Lake rozrasta się więc w każdym kierunku.

Warto zauważyć, że ekosystem Apache Hadoop – który na ogół jest wykorzystywany jako platforma technologiczna do budowy jeziora danych – ewoluował w kierunku umożliwiającym realizację aplikacji w architekturze lambda, tzn. z wydzielonymi warstwami Speed, Batch i Serving. Ten podział był widoczny w doborze komponentów wchodzących w skład ekosystemu – od klasycznego Map Reduce (z wszystkimi warstwami abstrakcji jak Cascading, czy Hive w początkowej implementacji) realizującego postulat przetwarzania danych w sposób batch’owy, przez komponenty pozwalające na strumieniowanie danych online, jak Storm i Spark Streaming, do NoSQL’owych baz danych, np. HBase.

Wpisanie procesów biznesowych w sztywne ramy architektury lambda

Podział ten początkowo zarysowany był bardzo mocno. Brakowało mechanizmów integracji procesów przechodzących przez więcej niż jedną warstwę, bezpieczeństwo i zarządzanie metadanymi realizowane było punktowo, a nie w skali całego ekosystemu. Ograniczenia te rodziły szereg niedogodności i znacznie utrudniały implementację zaawansowanych aplikacji ze względu na fakt, że przetwarzanie danych o różnym charakterze było od siebie odseparowane.

Wspólna warstwa dostępowa do danych batcho’wych i strumieniowych także nie zawsze była regułą. Powodowało to konieczność wykorzystywania różnych narzędzi do integracji danych w ramach ekosystemu, co z kolei skutkowało potrzebą budowy bardzo szerokiego wachlarza kompetencji przez osoby zajmujące się tworzeniem wdrażaniem aplikacji Big Data. Kompetencje te z pewnością procentują w różnych obszarach, niemniej jednak ich pozyskanie i utrzymanie w świecie niezwykle dynamicznie rozwijających się technologii open-source było i nadal jest bardzo kosztowne.

W miarę upływu czasu wyzwania związane z szeroką adopcją ekosystemu w przedsiębiorstwach zostały zaadresowane kompleksowo i w najnowszych dystrybucjach ekosystemu Hadoop (np. Hortonworks Data Platform 2.6) możemy już korzystać z udogodnień w postaci m.in. zunifikowanego zarządzania uprawnieniami i audytowania dostępu czy też spójnej warstwy definiowania i wyszukiwania metadanych opisujących zbiory danych gromadzone w ramach ekosystemu. Nadal jednak – jako twórcy zaawansowanych systemów, w skład których wchodzą procesy przetwarzające dane o skrajnie różnych charakterystykach – w wielu sytuacjach spotykamy się z architektonicznym wyzwaniem, jakim jest wpisanie procesów biznesowych w sztywne ramy architektury lambda.

Wszystko płynie, czyli przetwarzanie strumieniowe

Problem uporządkowania przetwarzania danych o różnym charakterze został częściowo zaadresowany przez koncepcję architektury kappa, w której warstwa batch’owa została całkowicie wyeliminowana na rzecz przetwarzania strumieniowego. Założenie, że wszystko jest strumieniem danych, jest jednak trudne do wdrożenia w aplikacjach, w których wykorzystanie danych batch’owych dominuje ze względu na charakterystykę procesu biznesowego. Przykładem takiej sytuacji są procesy, w których logika biznesowa musi operować na kompletnym zbiorze danych z danego okresu, a dodatkowo zbiór jest uzupełniany danymi niezależnie, z wielu źródeł i wymaga rekoncyliacji przy zamknięciu okresu.

Trend technologiczny, spowodowany koniecznością wykorzystywania w procesach biznesowych danych strumieniowych, był jednak na tyle istotny, że powstało co najmniej kilka niezależnych rozwiązań, m.in. Spark Streaming i Apache Storm. O ile cel był podobny – obsłużyć dane strumieniowe w czasie zbliżonym do rzeczywistego – o tyle implementacja różniła się w sposób znaczący. Spark Streaming był ewolucją klasycznego Sparka, który miał za zadanie zastąpić Map Reduce skracając czas obliczeń poprzez wykorzystanie mechanizmów in-memory (Map Reduce zapisuje kroki pośrednie na dysku) oraz wsparcie dla algorytmów iteracyjnych. Z tego powodu Spark Streaming przetwarzał zdarzenia w ramach strumienia nie indywidualnie, ale jako tzw. micro-batch’e, w z góry zdefiniowanych interwałach czasowych, np. co 500 ms. Powoduje to szereg ograniczeń biznesowych – np. dla zastosowań typu Fraud Prevention, gdzie w naturalny sposób konieczne jest przetwarzanie zdarzeń indywidualnie, aby móc w czasie rzeczywistym zablokować podejrzaną transakcję. Natomiast Apache Storm pozwala na budowę topologii przetwarzania pojedynczych zdarzeń. Jego wydajność jest bardzo mocno uzależniona od wagi każdego z nich.

Rozważania na temat ograniczeń specyficznych dla poszczególnych frameworków dodatkowo należałoby uzupełnić jeszcze o dwie kwestie, niezależne od implementacji. Są to windowing, a więc odpowiedni dobór interwału czasowego w jakim na podstawie zdarzeń strumieniowych uaktualniane są agregaty czasowe. Jest to także obsługa tzw. late data, a więc danych, które – ze względu na np. problemy techniczne po stronie systemów źródłowych – spływają po zamknięciu okresu. Obydwa te zjawiska, nie dość, że generują dodatkowe wymagania wydajnościowe wobec platformy, na której Data Lake jest implementowany, to jeszcze mają zasadniczy wpływ na biznesową interpretacją wyników przetwarzania danych. Posługując się przykładem z sektora handlowego – można sobie wyobrazić jakie konsekwencje – dla wyniku finansowego przedsiębiorstwa – może mieć niepojawienie się (lub błędna agregacja) danych sprzedażowych za ostatnią godzinę na dashboardzie. Na jego podstawie podejmowane są decyzje o wprowadzeniu promocji ad-hoc na daną grupę produktową w sieci sklepów.

Aplikacje ciągłe, czyli nowa koncepcja architektoniczna

Odpowiedzią na wyzwania związane z niejednorodnymi implementacjami frameworków pozwalających na realizację przetwarzania strumieniowego jest koncepcja architektoniczna, która polega na implementacji tzw. aplikacji ciągłych (continuous applications). Możliwości takie pojawiły się już w 2016 roku w Apache Spark 2.0. W kolejnych wersjach są one sukcesywnie uzupełniane o nowe funkcjonalności w ramach modułu Structured Streaming. Koncepcja ta polega na wykorzystaniu spójnego API dla obsługi wszystkich danych, niezależnie od ich charakteru. Umożliwia to analizowanie danych spływających na bieżąco w zderzeniu z danymi historycznymi w zastosowaniach operacyjnych i analitycznych.

Wykorzystanie danych batchowych w procesie obsługi indywidualnych zdarzeń strumieniowych jest odpowiedzią na pojawiające się potrzeby biznesowe. Dobrym przykładem takich wymagań mogą być systemy prescoringowe działające na spływających danych prospektów, a więc potencjalnych klientów instytucji finansowych. Wymaganie ofertowania just-in-time w celu budowania przewagi konkurencyjnej – dotarcia do klienta w momencie zaistnienia potrzeby skorzystania z produktu np. kredytu, w zderzeniu z regulacjami prawnymi nakładającymi obowiązek wyliczenia zdolności. Powodują one, że instytucja, która pragnie taki model biznesowy zaimplementować musi być przygotowana technologicznie na wykorzystanie danych batchowych podczas obsługi strumienia.

Model Structured Streaming – który może być postrzegany jako kolejny krok w ewolucji architektur Big Data – wprowadza szereg korzyści i usprawnień. Na poziomie budowy kompetencji zapewnia płaską krzywą uczenia, ze względu na spójną składnię dla danych strumieniowych i batch’owych, do tego wprowadzając wsparcie dla kilku języków programowania. Budowanie aplikacji w tym modelu pozwala na rejestrację wspólnego lineage’u, eliminując konieczność niezależnej obsługi danych o różnej charakterystyce. Takie podejście ułatwia ewentualną analizę wpływu w przypadku zmian modeli danych przetwarzanych w systemie.

Opisane powyżej cechy oznaczają krótszy time-to-market i szybszą możliwość weryfikacji biznesowych korzyści wynikających z uruchomienia rozwiązania klasy Big Data. Dokładając do tego silne wsparcie ze strony społeczności zrzeszonej wokół projektu Apache Spark można śmiało stwierdzić, że wczesna adopcja modelu tworzenia aplikacji ciągłych może stanowić kluczową przewagę technologiczną dla przedsiębiorstw chcących budować innowacje produktowe dzięki możliwościom, jakie daje wykorzystanie danych strumieniowych w zderzeniu z danymi historycznymi, na ogół przetwarzanymi batch’owo.

Kamil Folkert jest członkiem zarządu w 3Soft S.A. oraz Big Data Expert w SILMINE