Architektura Data Mesh, czyli dane w sieci domen.
Data Mesh to kolejny buzzword w świecie data – weźmy go więc na warsztat, aby przekonać się co wnosi w obszar danych oraz jakich zmian wymaga jego wdrożenie.
Obecnie wiele systemów gromadzenia i konsumowania danych skonstruowanych jest w formie big data platform, której zadaniem jest scentralizowane:
Wytwarzanie, zbieranie danych (ingestion layer)
Czyszczenie, wzbogacanie i transformacja danych (processing layer)
Dostarczanie danych o wartości biznesowej dla różnych typów zastosowań np.: raportowanie, ML (serving layer)
W świecie monolitycznych i monstrualnie rozrośniętych platform big data właścicielstwo danych (data ownership) jest scentralizowane i niepowiązane z żadną domeną biznesową organizacji. Model ten ma swoje słabości zwłaszcza w przypadku dużych organizacji, gdy liczba źródeł danych staje się trudno policzalna, a także gdy korzystają z nich grupy o zróżnicowanych potrzebach (konsumenci danych).
W takich organizacjach źródła danych mają zwyczaj rozrastać się w tempie niewspółmiernie szybkim w relacji do możliwości scentralizowanej platformy danych. Ponieważ zastosowanie danych jest bardzo zróżnicowane, liczba transformacji, które trzeba wykonać na zbiorach danych, rośnie nieustannie. Poszczególne grupy konsumentów coraz dłużej czekają na zrealizowanie ich potrzeb analizy danych. Podstawowe elementy procesu dostarczania danych (zbieranie, przetwarzanie i udostępnianie danych) są od siebie ściśle zależne, a w związku z tym zazwyczaj muszą odbywać się w określonej kolejności, co wydłuża czas wdrożenia zmian. Dodatkowo elementy te muszą być ze sobą zsynchronizowane i podlegać wspólnemu cyklowi wdrożeń (release management). Dopiero wprowadzane łącznie dostarczają potrzebną funkcjonalność i wartość biznesową. Nad dostarczaniem danych pracuje wąska grupa wysoko wyspecjalizowanych inżynierów. Stanowią oni zespół oddzielny od reszty organizacji, co sprawia, że trudno im pozyskać wiedzę biznesową.
Alternatywą na te bolączki może być architektura Data Mesh, której koncepcję można określić w trzech punktach:
Product thinking – myślenie w kategoriach danych jako produktu,
Rozproszona architektura danych powiązana z poszczególnymi domenami biznesowymi,
Platforma self-service do eksploracji dostępnych zbiorów danych.
W tym modelu właścicielstwo danych jest po stronie poszczególnych domen biznesowych.
Domeny przechowują i dostarczają dane (choć fizycznie dane mogą znajdować się w centralnej infrastrukturze chmurowej) oraz są odpowiedzialne za ich jakość
Format dostarczanych danych odpowiada ich charakterowi (np.: silnik rekomendacyjny może dostarczać dane w postaci grafowej bazy danych lub też dane sprzedażowe mogą być udostępniane w postaci uporządkowanej chronologicznie.
Z kolei z danych domeny może korzystać wiele innych domen.
Niektóre z domen koncentrują się wokół źródła danych (np. aplikacja CRM), inne bardziej wokół zastosowań (konsumowania) danych domenowych. Stąd można zarysować podział na domeny źródłowe oraz domeny konsumenckie.
Wyobraźmy sobie organizację, która zapewnia komunikację w lotnictwie zarówno na poziomie urządzeń jak i osób: personelu i pasażerów. Domeny źródłowe mogą pobierać dane z urządzeń technicznych umieszczonych na pokładach samolotów i korelując je z danymi z systemów CRM (gdzie rejestrowane są linie lotnicze i ich flota) dostarczają wyczyszczone i uspójnionie zbiory danych, które mogą następnie być użyte przez kolejne domeny, na przykład w celu wygenerowania rekomendacji dotyczącej zapotrzebowania na wolumen danych przy określonych rejsach.
Domeny źródłowe reprezentują fakty biznesowe, np.: sprzedaż, dane z urządzeń technicznych, etc.
Domena może dostarczać dane z kilku powiązanych ze sobą „wewnętrznych” systemów źródłowych (internal systems versus domain aligned datasets). Aby stworzyć zbiór danych o wartości biznesowej dane te muszą być wzajemnie wzbogacone i uspójnionie.
Domeny mogą dostarczać kilka docelowych zbiorów danych, np.:
dane detaliczne na poziomie zdarzeń biznesowych (log zdarzeń oznaczonych znacznikiem czasu (timestamp)
historyczne snapshoty danych w postaci danych zagregowanych np.: stan danych na poziomie dnia lub miesiąca.
Domeny konsumenckie:
Ich zadaniem może być na przykład udostępnianie zbiorów danych zawierających rekomendacje lub też raportów wspomagających podejmowanie decyzji.
Przetwarzają dane dostarczane przez domeny źródłowe do postaci zagregowanych struktur o formacie najbardziej odpowiednim dla danych (dla silnika rekomendacji może być to na przykład struktura grafowa danych).
Dostarczane przez nie dane również mogą być użyteczne dla innych domen.
Wszystkie fazy przetwarzania danych (pobieranie, przetwarzanie, dostarczanie) odbywają się w ramach poszczególnych domen.
Tak uzyskane dane domenowe stanowią produkt, który powinien charakteryzować się następującymi właściwościami:
Discoverable – każdy zbiór danych musi być zarejestrowany i odpowiednio udokumentowany w katalogu danych. Katalog zawiera między innymi metadane, informacje o właścicielu zbioru danych, informacje o źródłach oraz przykładowe dane. Ma umożliwić sprawne znalezienie odpowiedniego zbioru danych oraz zorientowanie się, czy zaspokaja on określone potrzeby biznesowe.
Addressable – jest to unikalny adres wewnętrzny zbioru danych w ramach organizacji na podstawie przyjętych konwencji nazewniczych, a także w zależności od infrastruktury przechowującej dane i formatu danych.
Trustworthy – niezbędna jest dbałość o jakość danych na poziomie organizacji: wdrożenie czyszczenia danych, automatycznego sprawdzania ich spójności czy też zachowanie data lineage (informacji o ścieżce przepływu danych). Zbiory danych mogą też z założenia charakteryzować się odmiennymi wskaźnikami poprawności, na przykład:
- Dane near-real time charakteryzujące się niższym stopniem uporządkowania. Dopuszczalny jest określony odsetek brakujących lub zduplikowanych eventów.
- Dane dostarczane z większym opóźnieniem ale o wyższym stopniu dokładności i spójności
Self-describing – dobrze opisane znaczenie i struktura danych
Interoperable – zapewniona możliwość połączenia ze sobą danych z różnych domen. Dlatego dane, ich format, a w szczególności kluczowe dla firmy definicje, powinny być poddane zarządzaniu na poziomie globalnym (global governance). Na przykład pojęcie sesji internetowej w różnych domenach może mieć de facto zróżnicowane znaczenie. Aby znaleźć zależności pomiędzy danymi z odrębnych domen potrzebna jest jedna wspólna „tożsamość” sesji internetowej.
Secure - przypisywanie dostępów do zbiorów danych jest zarządzane centralnie. Zespoły otrzymują dostęp dopiero, gdy zgłaszają potrzebę korzystania z danego zbioru danych. Właściwość ta wymaga przemyślenia, jak zorganizować różne poziomy dostępności informacji dla poszczególnych odbiorców np.: udostępnianie danych zagregowanych, row-level security, ograniczenie dostępu do danych wrażliwych.
Kluczowym warunkiem udanego wdrożenia architektury data mesh wydaje się więc być wysiłek na poziomie globalnym organizacji: wprowadzenie standardów, konwencji nazewniczych, skrzętne dokumentowanie oraz regularny pomiar jakości produktu jaki stanowią dane. Potencjalnie, przetwarzanie danych w obrębie osobnych jednostek biznesowych daje dużą swobodę manewru co do wyboru narzędzi, sposobu implementacji przepływów danych, ale rolą centralnego szczebla organizacji jest tu ujarzmienie organizacyjnej inercji.
Architektura data mesh wymaga także nowej roli w organizacji. Data product owner ma za zadanie przejąć stery zarządzania domenowym zbiorem danych: definiuje wizję oraz cele dotyczące danych dostarczanych przez domenę np.: mierniki ich jakości oraz zaspokajane potrzeby organizacji. Jest również odpowiedzialny za zarzadzanie cyklem życia zbioru danych, a także współdecyduje, które funkcjonalności - spośród konkurujących ze sobą potrzeb konsumentów - zostaną zaimplementowane. Definiuje i monitoruje KPI dla produktu. Jego zadaniem jest również zapewnienie automatyzacji testów i wdrożeń.
Natomiast co do roli inżyniera danych, ten zestaw umiejętności będzie jeszcze bardziej pożądany niż dotychczas, ponieważ każda domena będzie przetwarzać i dostarczać dane we własnym zakresie. Trudniejsze będą również optymalizacje wykorzystania tych kluczowych umiejętności, skoro inżynierowie danych obsługują konkretną domenę, a nie, jak to w przypadku big data platform, szereg zróżnicowanych systemów i przepływów. Receptą może być przygotowanie ścieżek rozwoju z data generalist do data engineer i idąca za tym demokratyzacja tej specjalizacji w ramach organizacji.
Kluczowe jest również scentralizowane dostarczanie infrastruktury danych wykonywane przez osobny zespół ds. infrastruktury. Jest on właścicielem rozwiązań technologicznych dostarczanych domenom do tworzenia, przetwarzania i przechowywania zbiorów danych. Infrastruktura ta ma być przeźroczysta pod kątem zastosowania biznesowego oraz łatwa w użyciu poprzez self-service. Idąc dalej można również wprowadzać dodatkowe usprawnienia, np.: zautomatyzować tworzenie szkieletu zbiorów danych domenowych oraz auto-rejestrację produktu w katalogu danych.
Podsumujmy więc podstawowe właściwości architektury data mesh w porównaniu ze scentralizowaną architekturą hurtowni danych.
Scentralizowana hurtownia danych | Data Mesh |
|---|---|
Ekstrakcja, przetwarzanie i dostarczanie danych dla różnych obszarów biznesowych odbywa się w ramach scentralizowanych procesów i narzędzi. | Ekstrakcja, przetwarzanie i dostarczanie danych odbywa się w obrębie domen biznesowych. |
Centralne rozwiązanie jest wąskim gardłem w pozyskiwaniu informacji z danych (coraz więcej danych, transformacji oraz użytkowników). Rośnie złożoność rozwiązania oraz czas implementacji zmian. | Przetwarzanie i dostarczanie danych jest zdecentralizowane. Pożądane zmiany w zbiorach danych są uzgadniane z właścicielem danych domenowych. |
Dane są dostarczane przez wysoko wyspecjalizowanych inżynierów danych. Nie mają oni natomiast wiedzy biznesowej (domenowej) co do implementowanych rozwiązań. | Dane dostarczane są przez inżynierów danych pracujących w obrębie danej domeny biznesowej. Zapotrzebowanie na inżynierów danych zwiększy się z uwagi na decentralizację Organizacja powinna więc zapewnić odpowiednie ścieżki rozwoju w kierunku inżynierii danych. |
Globalny model danych. Uspójnienie i wzbogacanie danych na poziomie centralnego rozwiązania. | Dążenie do zrównoważenia autonomii domeny i potrzeby dostosowania do standardów organizacji. Celem jest uwspólnienie warstwy semantycznej danych oraz wzajemna synergia danych domenowych. |
Narzędzia technologiczne wykorzystywane do dostarczania danych znajdują się w obrębie scentralizowanej hurtowni i jeziora danych. | Domeny używająplatformy self-service w celu dostarczania własnych zbiorów danych oraz korzystania z danych innych domen. |
Poziomy zabezpieczeń, infrastruktura oraz narzędzia są definiowane i implementowane w ramach centralnego rozwiązania. | Platforma self-service zawiera szereg automatyzacji pozwalających na efektywne dostarczanie w jej obrębie zbiorów danych domenowych (np.: rejestracja zbioru danych, generowanie metadanych, dostarczanie infrastruktury i narzędzi, predefiniowane poziomy zabezpieczeń zbioru danych) |
Centralna definicja, implementacja i monitorowanie jakości danych. | Centralne ustalenie i monitorowanie metryk jakości danych oraz ich dostosowanie do poszczególnych zbiorów danych domeny w zależności od charakteru danych. Właściciel danych domenowych jest odpowiedzialny za utrzymanie jakości danych. |
Jak widać powyżej, architektura data mesh wymaga niemałego wysiłku na poziomie centralnym organizacji (jednocześnie pozostawiając pewien zakres decyzji oraz dbałości o jakość danych na poziomie domeny). Ale skoro coraz więcej firm szczyci się mianem data-driven company, to taka architektura zdaje się być odpowiedzią na stale rosnące znaczenie danych.
Beata Boraca
Data Engineer
Artykuł napisany na podstawie:
How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (martinfowler.com)