Data mesh: cztery zasady i kiedy ma sens w polskiej firmie
Data mesh to podejście do architektury i organizacji danych analitycznych, w którym odpowiedzialność za dane przechodzi z centralnego zespołu do domen biznesowych. Artykuł opisuje cztery zasady według Zhamak Dehghani, warunki, w których podejście ma sens, przeliczony przykład kolejki zgłoszeń i typowe błędy wdrożeń.
Dominik Dębski · Lemur Media · · czas czytania: 4 min
Sprawdził: Dominik Dębski, 1.11.2026
Czym jest data mesh?
Data mesh to zdecentralizowane podejście do danych analitycznych, w którym zespoły domen biznesowych odpowiadają za swoje dane i udostępniają je innym jako produkty. Pojęcie wprowadziła Zhamak Dehghani, wówczas konsultantka Thoughtworks, w artykule „How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh” (2019). W 2020 roku opisała cztery zasady podejścia w artykule „Data Mesh Principles and Logical Architecture”. Data mesh jest odpowiedzią na wąskie gardło centralnego zespołu danych, który obsługuje wszystkie domeny firmy i nie zna dobrze żadnej z nich.
Domeną jest obszar biznesu z własnym zespołem, procesami i systemami, np. sprzedaż, logistyka, płatności czy obsługa klienta. Produkt danych to zbiór danych analitycznych przygotowany przez domenę dla innych odbiorców, z opisem, właścicielem, gwarantowaną aktualnością i miernikami jakości. Data mesh dotyczy danych analitycznych. Systemy transakcyjne domen działają tak jak wcześniej.
Jakie są cztery zasady data mesh?
| Zasada | Znaczenie | Warunek wdrożenia |
|---|---|---|
| Domenowa własność danych (domain ownership) | Dane analityczne należą do zespołów biznesowych najbliżej ich źródła | Domeny mają kompetencje analityczne i czas |
| Dane jako produkt (data as a product) | Domena dba o jakość, opis i dostępność danych dla odbiorców | Każdy produkt danych ma właściciela i mierniki jakości |
| Samoobsługowa platforma danych (self-serve data platform) | Platforma ukrywa złożoność infrastruktury, aby domeny mogły same budować produkty danych | Zespół platformowy i budżet na narzędzia |
| Sfederowany ład obliczeniowy (federated computational governance) | Przedstawiciele domen i platformy ustalają wspólne standardy, a platforma egzekwuje je automatycznie | Wspólne standardy identyfikatorów, formatów i bezpieczeństwa |
Czym data mesh różni się od podejścia scentralizowanego?
Różnica dotyczy przede wszystkim tego, kto odpowiada za dane analityczne i kto ustala standardy. Technologia może być w obu podejściach podobna: hurtownia danych lub jezioro danych w chmurze, narzędzia do transformacji i katalog.
| Wymiar | Podejście scentralizowane | Data mesh |
|---|---|---|
| Odpowiedzialność za dane analityczne | Centralny zespół danych | Zespoły domen biznesowych |
| Kto przygotowuje zbiory danych | Inżynierowie danych w zespole centralnym | Inżynierowie danych w domenach, wspierani przez platformę |
| Standardy | Ustalane i stosowane przez zespół centralny | Ustalane wspólnie przez domeny i platformę, egzekwowane automatycznie |
| Wąskie gardło | Przepustowość zespołu centralnego | Kompetencje i zaangażowanie domen |
| Koszt | Niższy przy małej liczbie domen | Wyższy koszt startowy platformy i kompetencji w domenach |
Kiedy data mesh ma sens?
Data mesh ma sens wtedy, gdy liczba domen i zapotrzebowanie na dane przekraczają możliwości centralnego zespołu, a domeny mają zasoby, by przejąć odpowiedzialność. Prosty test to bilans kolejki zgłoszeń do zespołu danych.
| Wskaźnik kwartalny | Wartość |
|---|---|
| Nowe zgłoszenia od domen | 120 |
| Przepustowość centralnego zespołu (4 osoby) | 70 |
| Przyrost zaległości | 120 − 70 = 50 |
| Zaległości po 4 kwartałach przy stałym tempie | 4 × 50 = 200 |
| Czas obsługi zaległości bez nowych zgłoszeń | 200 ÷ 70 ≈ 2,9 kwartału |
Zaległość rośnie o 50 zgłoszeń na kwartał. Zwiększenie zespołu o 3 osoby przy tej samej wydajności (17,5 zgłoszenia na osobę) daje przepustowość 122,5 i zatrzymuje przyrost. Jeśli zgłoszenia pochodzą głównie z dwóch lub trzech domen, tańsza bywa decentralizacja tylko tych domen. W firmach zatrudniających 50–249 osób centralny zespół z dobrą warstwą semantyczną zwykle wystarcza. Data mesh częściej uzasadnia się w organizacjach 1000+ osób z wieloma liniami biznesowymi. Przed decyzją warto sprawdzić, jaka część zgłoszeń wynika z braku wspólnych definicji metryk: takie zgłoszenia znikają po wdrożeniu warstwy semantycznej, bez zmiany modelu organizacyjnego.
Jak zacząć wdrożenie?
- Wybór jednej domeny z dojrzałym zespołem i wyraźnymi odbiorcami danych.
- Zdefiniowanie pierwszego produktu danych: zawartość, właściciel, odbiorcy, mierniki jakości i aktualności.
- Minimalna platforma: szablon potoku danych, katalog, zarządzanie dostępem.
- Wspólne standardy: identyfikatory klienta i produktu, nazewnictwo, klasyfikacja danych osobowych.
- Przegląd po dwóch kwartałach i decyzja o kolejnej domenie.
Jakie są typowe błędy?
- Zmiana nazw zespołów bez przekazania im odpowiedzialności i budżetu.
- Decentralizacja bez platformy: każda domena buduje własną infrastrukturę.
- Brak wspólnych identyfikatorów, przez co produkty danych z różnych domen nie dają się połączyć.
- Wdrożenie w firmie, której głównym problemem jest jakość danych źródłowych, przy wystarczającej przepustowości zespołu danych.