Fundamenty zwinnej architektury dla danych

Data: 2019-08-04
Autor: Sebastian Konkol
Fundamenty zwinnej architektury dla danych

Rewolucja inteligencji obliczeniowej (Machine Learning, Deep Learning) trwa i w końcu zmieni wszystko. Zapewne potrwa to jeszcze kilka lat lub dekad, ale w końcu kod programu zostanie zastąpiony przez dane. Wartość z danych można jednak masowo wydobywać już teraz, bez uciekania się do tych najpotężniejszych narzędzi. Kluczowym terminem jest tu zwinność, której osiągnięcie zapewnia te możliwości. Wymaga to jednak wprowadzenia zmian w stanie posiadania i sposobie użytkowania parku maszynowego technologii informatycznych.

Jak już wiemy, zwinność architektury to zapewnienie zdolności jej poprawnego i skutecznego działania w nowych scenariuszach nieznanych podczas tworzenia rozwiązań opartych o tę architekturę, bez wprowadzania zmian w tych rozwiązaniach. Metoda na uzyskanie zwinności w architekturze wykracza poza zwinność w projektach. Tą metodą jest spojrzenie na technologię i jej użytkownika jak na system złożony ze zdolnością adaptacji (CAS), w którym użytkownicy (ludzie) mają zapewniać zdolność dopasowania sposobu użytkowania technologii do nowych warunków, a systemy informatyczne mają tworzyć środowisko umożliwiające prowadzenie działań w zmienionych warunkach. To trochę tak, jak z klockami LEGO – zbiór rodzajów klocków nie jest duży, ale przestrzeń możliwości tego, co z nich powstaje jest ograniczony wyłącznie wyobraźnią budowniczego. Podobnie, jak klocki LEGO, budowanie domów (różne składanie cegieł), czy muzyka (różne składanie dźwięków) to właśnie przykłady pokazujące właściwe wzorce. Im bardziej specjalizowane klocki, tym węższe możliwości ich użycia, a najszersze możliwości użycia dają najprostsze konstrukcje. Takie wzorce musimy uzyskać w sferze danych, aby ich używanie zaczęło być powszechne i zróżnicowane – prostota formy i dostępność do ponownego użycia.

Warunki początkowe dla realizacji takiego procesu są znane. O adaptacyjność ludzi musimy się troszczyć, ale to sprawa tworzenia zespołów, ich motywacji oraz tworzenia i organizacji środowiska pracy. O tym jak zbudować architekturę tworzącą środowisko dla zwinności – o tym poniżej.

Architektura zdarzeniowa

Jeszcze dekadę temu można było wierzyć, że rozwiązania informatyczne muszą realizować ściśle zdefiniowane procesy i że dzięki temu da się sprawować kontrolę nad działaniem organizacji. Dzisiaj nie jest to obowiązującym paradygmatem. Zmienność otoczenia firmy coraz częściej sprowadza firmę do pozycji reagowania na zdarzenia. I nie ma w tym nic złego – łatwiej wdrożyć proste reakcje na zachodzące zdarzenia, niż zmieniać procesy, aby „nauczyć je” obsługi tych nowych zdarzeń. Skoro uruchomienie odpowiednich działań w odpowiedzi na określone zdarzenie to zdolność adaptacji człowieka, zwinność uzyskamy dzięki zdolności spójnego identyfikowania zachodzących zdarzeń.

Architektura zdarzeniowa opiera się na bardzo prostych podstawach. Zdarzenia mogą być rozgłaszane przez systemy dziedzinowe (transakcyjne) w wyniku operacji realizowanych w nich przez ich użytkowników. Zdarzenia mogą być także identyfikowane na podstawie korelacji zmian rejestrowanych w danych z różnych źródeł, czy w oparciu o brak oczekiwanej korelacji w określonym czasie. W każdym przypadku na podstawie obserwacji stanu danych wnioskujemy o zajściu pewnej sytuacji biznesowej, której znaczenie (czasami prawdopodobieństwo) możemy określić. Wzorzec architektury dla takich rozwiązań to EDA (Event-Driven Architecture), a w roli rozwiązań najczęściej występuje trójka: ODS (Operational Data Store) realizujący zadania konsolidacji danych z wielu źródeł, CEP (Complex Event Processing) wykonujący zadania obserwowania danych, ich korelacji i identyfikacji zdarzeń oraz Event Bus zapewniający dystrybucję zdarzeń ze wszystkich źródeł do każdego z zainteresowanych użytkowników.

Zdarzenia stają się rodzajem danych o coraz większym znaczeniu biznesowym. Tak samo, jak dekadę temu rutynowo wykorzystywane były platformy klasy BPM / BRM / BAM, dzisiaj konieczne jest oparcie skuteczności działań biznesowych na zdarzeniach i rutynowej ich obsłudze.

Lambda Architecture

Skojarzenia z masowym przetwarzaniem danych? Zapewne w większości przypadków „hurtownia danych”, a chwilę później – „BigData”. Hurtownie danych zawsze miały „pod górkę”, bo zawsze wiązały się ze znacznymi kosztami i wieloletnimi projektami, a do tego obrywały rykoszetem wojen religijnych prowadzonych między guru od hurtowni (tych od Inmona i tych od Kimbala). A później świat przyspieszył i hurtownie musiały być coraz szybsze – niektórzy wręcz próbowali traktować hurtownie danych – i budowane na nich narzędzia analityczne (sic!) – jak systemy do aktualizacji nie tyle cyklicznej (raz na dobę), co ciągłej. Ten nonsens zapewne trwałby nadal, gdyby nie uznano, że nie ma jednego rozmiaru pasującego do wszystkiego. W dzisiejszych warunkach jest kilka, bez wątpienia równoprawnych architektur przetwarzania danych na skalę masową – każda z nich służy jednak czemuś innemu. Hurtownie danych i rozwiązania klasy Business Intelligence, o ile nie będą „na siłę” wdrażane w niewłaściwy sposób, dostarczają skutecznie i efektywnie wymiernej wartości biznesowej. Dzięki takim rozwiązaniom potrafimy odpowiadać na pytania o powody i trendy. Mamy jednak co najmniej dwie inne architektury masowego przetwarzania danych: przetwarzanie danych operacyjnych (szybkozmiennych) oraz przetwarzanie danych dużych wolumenów. Pierwsza z nich, oparta o repozytoria danych szybkozmiennych (ODS) ma za zadanie konsolidować dane w trybie on-line, łącząc je w sposób spójny znaczeniowo i czasowo, i dostarczać w celu podejmowania bieżących, operacyjnych decyzji biznesowych. Druga z nich, oparta o stos technologiczny BigData, służy okiełznaniu danych o wolumenach zbliżonych do absurdalnych i ma zapewniać zdolność wydobywania wiedzy biznesowej z danych o znacznie surowszym charakterze i znacznie mniej wiarygodnych strukturach.

Architektura Lambda ma zapewnić łączenie wyników masowego przetwarzania danych pochodzących z tak różnych procesów. Jej postawą jest sprawowanie kontroli nad spójnością definicji danych przetwarzanych w różnych „strumieniach”, a jej esencją jest wtłaczanie wyników przetwarzania do wspólnej warstwy wizualizacji danych. Koncepcyjnie niezwykle proste – trudność w implementacji wynika raczej z animozji pomiędzy grupami sympatyków poszczególnych „strumieni” – wojen religijnych między hurtownikami, bigdejtowcami i operacyjnymi. To prawda, że większość potrzeb biznesowych dałoby się prawdopodobnie obsłużyć w każdym z tych strumieni, ale „chęć dominacji” słabo wygląda w liście kryteriów oceny wyboru strumienia realizacji wymagań. Wojny religijne należy porzucić na rzecz zapewnienia dostępu do danych o tej samej definicji (np. o Kliencie) w każdym z nich. Wtedy okazuje się, że każdy z tych strumieni dostarcza komplementarnej wiedzy biznesowej dotyczącej danego pojęcia – w sferze trendów, bieżących cech i szerszej charakterystyki uzupełniającej.

Takie spojrzenie oparte o kilka perspektyw obiektywizuje zrozumienie stanu biznesu, zapewniając spójną formułę korzystania z danych pochodzących z równolegle i wspólnie działających strumieni przetwarzania danych (DWH/BI, ODS/CEP i BigData), a użytkownicy skupiają się wreszcie na ich biznesowym znaczeniu, nie zaś na ograniczeniach ich wykorzystywania.

Data as a Service

Jeśli dostęp do informacji stał się fundamentem skuteczności działania biznesowego, musi być uczyniony tak łatwym i powszechnym, jak to tylko możliwe. Z tego powodu do listy cokolwiek-jako-usługa dołączyły także dane. To trochę tak, jakbyśmy budowali Wikipedię dla danych organizacji, przez którą dostępne byłyby wszystkie istotne jej dane, od listy klientów, przez historię sprzedaży, aż po dane zagregowane i trendy.

Dlaczego w taki sposób? Z powodów wyrażonych dwoma podstawowymi scenariuszami użycia. Po pierwsze chcemy, aby wszelkie wymagania budowania zestawień, raportów i kokpitów menedżerskich mogły być realizowane na bazie tych samych środowisk i danych. Ma to zapewnić spójność zrozumienia kluczowych dla firmy informacji o biznesie dzięki zestawianiu ich ad-hoc w dowolny sposób, zawsze w tych samych narzędziach. Temu celowi mogą służyć rozwiązania wizualizacji danych osadzone w architekturze lambda oraz platformy wirtualizacji danych. Po drugie chcemy, aby wszelkie te dane miały szanse być automatycznie udostępniane w najprostszej możliwej formie. To tak, jakby każdy zbiór danych, jaki możemy sobie wyobrazić w postaci tabelki (np. katalog klientów, katalog zamówień, zagregowane w czasie dane o liczebności obsługiwanych spraw klientów poszczególnych rodzajów) były dostępne za pośrednictwem okienka przeglądarki. Data as a Service to koncepcja promująca dane do pozycji samodzielnej, niezależnie postrzeganej wartości biznesowej. W obu powyższych zastosowaniach chodzi o obniżenie bariery wejścia dla korzystania z danych (m.in. wielości źródeł, zróżnicowania definicji, wachlarza technologii wymaganych do dostępu do danych). Już w tak podstawowej, surowej wręcz formie wiele zadań, jakie dotychczas wymagały wysiłku „zebrania danych”, znacząco się upraszcza (np. udzielenie kompletnej odpowiedzi na zapytanie klienta w biurze obsługi).

W tym obszarze można jednak pójść dalej, wykorzystując dwie dodatkowe, zaawansowane koncepcje technologiczne: Semantic Web i SOA w jej właściwym ujęciu. Dzięki wdrożeniu koncepcji sieci semantycznych i użyciu stosu technologii ich obsługi zapewniamy „systemową” zdolność łączenia danych pochodzących z różnych źródeł na podstawie definicji ich znaczenia (semantyki). W tym ujęciu, jeśli w danych faktury występuje identyfikator klienta, to po prostu jest rozumiany jako referencja do właściwych danych w kartotece klientów – bez względu na to, skąd pochodzą dane faktur i klientów. Powiązanie zbiorów danych wymaga więc jedynie zdefiniowania ich znaczenia, a reszta dzieje się „automagicznie”. SOA – „odchudzone” do najprostszych mechanizmów „read-only” opartych o lekkie protokoły komunikacyjne (REST) – ma zapewniać unifikację dostępu do wszystkich danych, realizując przy tym organizację i ochronę dostępu wyrażone w kategoriach kontraktów usług. Kontrakty takie, obejmujące zarówno określenie uprawnień dostępu do danych jak i dostępną wydajność, opisywane są dla każdej z usług i automatycznie egzekwowane w czasie wykonania. Stanowią więc pojedynczy punkt wyrażania i egzekwowania uprawnień dostępu do danych, zamiast niezależnego określania takich uprawnień w tak wielu miejscach, że i tak nikt nad tym nie panuje.

Rutynowe udostępnianie wszelkich danych w ich najprostszej formie, rutynowe posługiwanie się zdarzeniami, czy rutynowe łączenie prezentacji danych o diametralnie innych cyklach i reżimach przetwarzania to minimalny zbiór narzędzi tworzących w sferze danych fundamenty dla zwinności danych. Nie jest przy tym wymagane oddawanie się w moc AI, na łaskę lub niełaskę ML. Zwinność angażuje zdolność do adaptacji, a – póki co – w „wykazywaniu inwencji” nic nie pokona człowieka. Trzeba tylko dać ludziom możliwości i pomóc je wykorzystać. Efekty przyjdą same.

Pozostaw komentarz