Data Mesh: Dekentralizacja Właściwości Danych Bez Stracenia Zarządzania Organizacyjnego

Problem, dla którego data mesh został zaprojektowany

Architektura centralezowanych jeziernych lub magazynów danych, która dominowała w latach 2015-2020, ma znany problem z dokumentowanymi błądami, gdy organizacja przekracza pewną skalę: pojedynczy centralny zespół inżynierii danych staje się bramą dla każdego dziedziny firmy, która chce, aby jej dane były przekształcane, czyszczone i dostępne do analiz. Dane wydajności kampanii marketingowej, śledzenia przesyłek z działu logistycznego oraz danych rozpoznawania przychodów finansowych z działu finansowego wszyscy kierują przez mały zespół platformowy, którzy nie mają głębokiej specjalizacji w żadnej z tych dziedzin i są zawsze załadowani na backluke żądań przekształcenia ze względu na brak skalowalności liczebności zespołu centralnego. Wynikiem jest jezioro danych, które staje się brzozą danych: ogromne ilości niewykorzystanych i połowy przekształconych danych, których nikt nie zaufuje, dokumentowane przez ludzi, którzy nie rozumieją, co oznaczają pola, a zarządzane przez zespół, który ma żadny interes w tym, czy tabela kampanii marketingowej jest rzeczywiście poprawna.

Propozycja Zhamaka Dehghani, zaprezentowana po raz pierwszy w 2019 roku, odświeża problem, przekładając go bezpośrednio na lekcje mikroservisów i projektowania zdomenionego w architekturze oprogramowania: podobnie jak monolityczne aplikacje były rozkładane na usługi własnościowe, które są zarządzane przez zespoły najbliżej dziedziny biznesowej, data mesh zaproponowuje rozkładanie monolitycznego centralnego platformy danych na produkty danych własnościowe, każdy zarządzany przez zespół, który rzeczywiście generuje i rozumie te dane, z podłączonym wspólnym platformą samodzielnej obsługi i warstwą federacyjnej gospodarki, która łączy całość. Kluczowa myśl polega na tym, że najlepsi ludzie, którzy rozumieją dane śledzenia przesyłek, to inżynierzy logistyczni, którzy budują systemy generujące te dane, a nie centralny zespół danych kilka warstw organizacyjnych oddalony — i że dobry architektura powinna umieszczać własność tam, gdzie już istnieje specjalizacja, a nie próbować centralizować specjalizację, która w rzeczywistości się nie centralizuje.

Właściwość dziedziny i dane jako produkt

Pierwsza zasada, właściwość dziedziny, oznacza, że każda dziedzina biznesowa — logistyka, marketing, finanse, niezależnie od naturalnych granic organizacji — ma własność danych analizowych, podobnie jak operacyjnych systemów i baz danych generujących te dane. Jest to autentyczna przemianę w strukturze organizacyjnej, a nie tylko techniczna: wymaga zdobywania przez zespoły dziedziny umiejętności inżynierii danych do budowania i utrzymywania łańcuchów pracy, zamiast traktować transformację danych jako pracę przekazaną dalej. Krytycy modelu Data Mesh poprawnie podkreślają, że to jest kosztem — oznacza wstawianie inżynierów danych do każdego zespołu dziedziny zamiast skupiać je centralnie — i tylko po tym, jak organizacja będzie duża, aby koszt koordynacji punktu przepływu centralnego rzeczywiście przewyższał koszt powtarzalnej inżynierii danych rozproszonych.

Druga zasada, dane jako produkt, jest tym, z czym Data Mesh przechodzi po prostu „daj każdemu zespołowi zarządzanie swoimi danymi” i zaczyna przypominać autentyczne dyscypliny. Dane jako produkt oznacza, że zespół dziedziny jest odpowiedzialny za wyjście danych ze względu na to samo co zespół oprogramowania za API: z gwarancjami jakości (dokumentowany schemat, SLA dotyczące świeżości danych, zobowiązanie do dokładności), dostępności (zbiorcza rejestracja zestawu danych z jasną własnością i dokumentacją, aby inne dziedziny mogły znaleźć i zrozumieć je bez pytań) oraz autentycznego interfejsu dla konsumentów w przeciwieństwie do rzucającego na pulpit raw tables. Produkt danych logistycznych odslaniający „wydarzenia dostawy przesyłek” powinien mieć takie same oczekiwania na wiarygodność jak API logistyka odslaniające te samo informacje — z wersjonowanym schematem, gwarancjami kompatybilności odwrotnej i nazwanym właścicielem, który jest poinformowany w przypadku awarii łańcucha pracy — co dokładnie jest dyscypliną, której zwykle brakowało centralnym zbiornikom danych, ponieważ nikogo nie obchodziło wiarygodność tabel kampanii marketingowej.

Platforma samodzielna: uczynienie de-centralizacji dość ekonomicznej, aby działać

Posiadanie domeny wydaje się atrakcyjne, dopóki nie zastanawiasz się nad tym, że większość zespołów domen nie chce stać się specjalistami w konfigurowaniu klastrów Kafka, zarządzaniu orkestracją zadań Spark czy ustawianiu zasad dostępu — a wymaganie od każdego zespołu domeny budowania tej wiedzy od podstaw powróciłoby do centralnego bottlenecku na poziomie infrastruktury, zamiast na poziomie transformacji. Trzecia zasada — samodzielna platforma danych — jest elementem, który uczynił de-centralizację rzeczywistej wartości a nie tylko marzeniem: nadal istnieje centralny zespół platformowy, ale jego zadaniem jest zmiana od budowania i zarządzania przepływami danych na rzecz budowania ogólnodostępnej infrastruktury samodzielnej — narzędzia do provisioningu, szablonów generycznych przepływów danych, abstrakcji magazynu i obliczeń, ram dostępu —, która zespoły domen mogą wykorzystać do budowania i zarządzania własnymi produktami danych bez potrzeby głębokiej wiedzy na temat infrastruktury.

Ten sam przesunął się zaszaoładował również w infrastrukturze aplikacji, dzięki powstaniu Kubernetes i inżynierii platformy: zamiast zespołu operacyjnego konfigurować każdą aplikację na rzecz każdego zespołu produktów, ten zespół buduje platformę samodzielnej orkestracji i zespoły produktów wdrażają swoje usługi na niej. Prawidłowe osiągnięcie tego jest naprawdę trudne i to, gdzie wielu rzeczywistych implementacji_mesha danych ma problemy, ponieważ budowanie platformy samodzielnej dość dobrych, że zespoły domen bez specjalistycznej wiedzy mogą ją wykorzystać productywnie, jest znaczącym i ciągłym inżynieryjnym zainwestowaniem. Organizacje, które przypuszczają finansowanie warstwy platformowej, kończą z zespołami domen blokowanymi czekając na nowe funkcje platformy lub tworząc niezgodne i niewłaściwie utrzymywane przepływy danych na ad hoc infrastrukturze, co powtarza problem brzmienia danych na poziomie zespołu domen zamiast centralnym.

Gospodarka federacyjna: zasada zachowująca mesh przed chaosem

Czwarta zasada jest najczęściej pomijana podczas wcześniejszych adoptacji maszyn danych, a jej brak jest najczęsciej występującą przyczyną niepowodzeń w inicjatywach mesh. Gdy każda dziedzina pełni całkowitą samodzielnosć nad swoim produktowym danymi, definiując własny schemat, nazewnictwo, standardy jakości i politykę dostępu, organizacja kończy się z setkami wewnętrznie zgodnych, ale nawzajem niekompatybilnych produktów danych: identyfikator klienta jednej dziedziny może być identyfikatorem klienta inniej dziedziny o inny format, jedna dziedzina stosuje maskowanie pola GDPR, a druga tego nie robi, a analizy przekrojowe — które to jest często exactly powodem, dla którego organizacja chciała unifikować platformę danych w pierwszej kolejności — stają się tak trudne jak były, gdy dane żyły w dziesiątkach oddzielnych baz operacyjnych, z dodatkową skomplikowana architekturą dystrybuowaną na szczycie.

Gospodarka federacyjna rozwiązuje to poprzez ustalenie małej serii globalnych standardów, które są zgodnie przyjęte i przestrzegane przez wszystkie dziedziny, jednocześnie pozostawiając resztę decyzji dziedzinom samodzielnemu zarządzaniu: wspólny taxonomia dla podstawowych współdzielonych entitetów, takich jak identyfikatory klienta i produktów, zgodny podejście do klasyfikacji danych i kontroli dostępu do danych regulowanych (PII, finansowe dane), standardy interoperacyjności dotyczące sposobu ekspozycji schematów i metadanych przez produkty danych, aby pozwalanie na przekroczenia i połączenia nadmiarowe nadal było możliwe, a także podstawowe wymagania jakościowe i obserwacyjne organizacji. To zazwyczaj realizuje się poprzez grupę gospodarczą z reprezentantami z każdej dziedziny oraz zespołu platformowego, którzy zgadzają się na i ewoluują małą serię wymaganych globalnych zasad, a także poprzez automatyczną przestrzeganie polityk wbudowane w samodzielne narzędzie platformowe — kontrola dostępu i maskowanie PII są przestrzegane jako domyślne ustawienia platformy, a nie pozostawiane na dyspozycję decyzji dziedzin, co sprawia, że wymagane standardy są strukturalnie trudne do pominięcia zamiast tylko dokumentowane i oczekiwane. Wymagania etyczne tutaj są naprawdę najtrudniejszym elementem maszyny danych w praktyce: decyzja, co musi być globalne, a co można pozostawić dziedzinie samodzielnemu zarządzaniu, jest wyborzem z brakiem universalnej prawidłowej odpowiedzi, a nieporządana równowaga w obu kierunkach — zbyt duża kontrola centralna powtarza oryginalny przeszkodę, za mała produkuje niestosowny układ szmatowy — jest najczęsciej występującą przyczyną organizacji adoptujących pierwsze trzy zasady ze ścisłym entuzjazmem kończących się nieszczęśliwie z wynikami.

Często zadawane pytania

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz Data Mesh Domain Explorer i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.