Data Engineering

Data Mesh

Jeden centralny data team jako wąskie gardło — to przeszłość. Data Mesh przenosi odpowiedzialność za dane do domen które je produkują i rozumieją najlepiej.

Domain Ownership

Kluczowa zasada

Z. Dehghani

Twórca

Product

Dane jako

Federated

Governance

4 zasady Data Mesh

Data Mesh to nie technologia — to filozofia organizacyjna oparta na czterech kluczowych zasadach.

Domain Ownership

Domeny biznesowe (Sales, Marketing, Product) są właścicielami i producentami swoich danych. Eliminuje wąskie gardło centralnego data team.

Implikacja: Każda domena potrzebuje własnych data engineers i data product owners.

Data as a Product

Dane traktowane jak produkt: właściciel, SLA (freshness, quality), dokumentacja, API, versioning.

Implikacja: Data Product Owner odpowiada za jakość i dostępność danych jak PM za software.

Self-serve Data Platform

Centralna infrastruktura techniczna umożliwiająca domenowym teamom samodzielne publikowanie i konsumowanie danych.

Implikacja: Platform team buduje 'data infrastructure as a service'. Domeny nie zarządzają infrastrukturą.

Federated Governance

Globalne standardy interoperabilności ustalane centralnie, implementowane lokalnie. Autonomia z guardrails.

Implikacja: Data governance council ustala standardy. Domeny mają autonomię w implementacji.

6 atrybutów dobrego Data Product

Każdy Data Product w siatce danych powinien spełniać te sześć atrybutów aby być naprawdę użytecznym.

Discoverable

Zarejestrowany w data catalog, łatwy do znalezienia

Addressable

Stały adres (URL, endpoint) niezależny od implementacji

Trustworthy

SLA na freshness, completeness, accuracy z monitoringiem

Self-describing

Dokumentacja, schemat, ownership, lineage dostępne inline

Interoperable

Standardowe formaty (Parquet, Avro) i protokoły dostępu

Secure

Access control, audit log, compliance z data governance

Często zadawane pytania

Co to jest Data Mesh?

Data Mesh to zdecentralizowane podejście do architektury danych, gdzie odpowiedzialność za dane jest przenoszona z centralnego zespołu data engineering do domein biznesowych które te dane produkują i najlepiej rozumieją. Stworzone przez Zhamak Dehghani (Thoughtworks, 2019). Problem z centralną architekturą danych: jeden centralny data lake/warehouse → jedno wąskie gardło → data engineers nie rozumieją domeny → dane są złej jakości → business teams czekają tygodniami. Data Mesh odpowiada: Distributed ownership — każda domena (Sales, Marketing, Product) jest właścicielem swoich danych. Data as a Product — dane traktowane jak produkt z właścicielem, SLA, dokumentacją. Self-serve platform — infrastruktura danych jest shared platformą, ale łatwa w użyciu. Federated governance — globalne standardy przy lokalnej autonomii. Data Mesh to filozofia organizacyjna, nie narzędzie techniczne. Wdrożenie wymaga zmian kulturowych i organizacyjnych.

Jakie są 4 zasady Data Mesh?

4 zasady Data Mesh według Zhamak Dehghani: 1. Domain Ownership — dane należą do domeny która je produkuje. Zespół Sales jest właścicielem danych o sprzedaży. Decentralizacja odpowiedzialności eliminuje wąskie gardło centralnego data team. 2. Data as a Product — każdy zestaw danych jest produktem z: właścicielem (data product owner), dokumentacją, SLA (freshness, quality), API/interface dla konsumentów, discovery catalog. 3. Self-serve Data Platform — centralna platforma techniczna która umożliwia domenowym teamom samodzielne publikowanie i konsumowanie danych bez potrzeby centralnego wsparcia. Abstrakcje: storage, compute, lineage, catalog. 4. Federated Computational Governance — standardy interoperabilności (formaty, schemy, security) ustalane centralnie, ale implementowane lokalnie przez domeny. Bez governance: mesh staje się chaosem. Wyzwanie: balans między autonomią a standardami.

Data Mesh vs. Data Lake vs. Data Warehouse — różnice?

Porównanie: Data Warehouse — scentralizowany, historyczny, strukturyzowany, batch processing. Świetny dla raportowania i BI. Wąskie gardło: centralny ETL team. Data Lake — scentralizowany, surowe dane wszystkich formatów, cheap storage. Często staje się 'data swamp' bez governance. Data Lakehouse — hybryda warehouse i lake: ACID transakcje na raw data (Delta Lake, Apache Iceberg). Wciąż scentralizowany. Data Mesh — zdecentralizowany. Każda domena ma własne data products. Brak centralnego wąskiego gardła. Wymaga dojrzałości organizacyjnej. Kiedy Data Mesh: Duże organizacje (100+ data consumers). Wiele domen biznesowych z unikalnymi potrzebami. Centralny data team jest wąskim gardłem. Problemy z jakością danych — producenci nie czują odpowiedzialności. Kiedy Data Lake/Warehouse: Mała organizacja, jeden centralny team. Proste reporting needs. Mała liczba data sources. Brak dojrzałości inżynieryjnej w domenach.

Jak wdrożyć Data Mesh w organizacji?

Wdrożenie Data Mesh: Ocena gotowości — czy organizacja ma wystarczającą dojrzałość techniczną i kulturową? Data Mesh wymaga domain teams które mogą budować data products samodzielnie. Identyfikacja domen — zdefiniuj granice domenowe (Domain-Driven Design pomaga). Każda domena = autonomiczna jednostka z własnymi danymi. Zbudowanie Self-serve Platform — platforma musi być na tyle prosta, że domain engineers (niekoniecznie data specjaliści) mogą z niej korzystać: storage, compute, catalog, monitoring, lineage. Pilotażowa domena — zacznij od jednej dobre dojrzałej domeny. Zbuduj pierwszy data product. Naucz się i iteruj. Federated governance — zdefiniuj standardy: formaty plików (Parquet, Avro), schemat metadata, access control, data quality metrics. Stopniowe skalowanie — kolejne domeny adoptują mesh. Narzędzia wspierające: Data Catalog (Apache Atlas, DataHub, Collibra), Data Platform (Databricks, Snowflake, BigQuery), Orchestration (Airflow, dbt), Observability (Monte Carlo, Great Expectations).

Jakie są wyzwania Data Mesh?

Wyzwania wdrożenia Data Mesh: Organizacyjne (najtrudniejsze): Domeny muszą przyjąć odpowiedzialność za dane — zmiana kultury i KPI. Potrzeba data engineers w każdej domenie — duże koszty. Management musi rozumieć i wspierać decentralizację. Techniczne: Interoperabilność — dane z różnych domen muszą być łatwo łączone. Wymaga standaryzacji. Self-serve platform — zbudowanie platformy która jest użyteczna dla non-data-engineers jest trudne. Federated governance — globalnie spójne standardy przy lokalnej autonomii. Duplicate infrastructure — każda domena buduje swoje pipeline'y = redundancja. Discovery — jak znajdować dane w zdecentralizowanym środowisku? (data catalog kluczowy). Kiedy Data Mesh się nie opłaca: Małe organizacje (poniżej 50 osób w data). Brak domain ownership culture. Brak budget na platformę i domain data engineers. Zaczynasz od zera — najpierw zbuduj data warehouse, potem rozważ mesh.

Czytaj dalej