olivlawolivlaw

Din cărți

Lecția 7 · Data mesh mută proprietatea datelor la domeniul care le produce; platforma și regulile rămân comune.

Zhamak Dehghani · Data Mesh Principles and Logical Architecture · 2020 · Data Mesh Principles and Logical Architecture, martinfowler.com (2020) — cele patru principii, în ordinea din articol2 minute de citit
„Proprietate și arhitectură descentralizate ale datelor, orientate pe domenii. Datele ca produs. Infrastructura de date self-serve ca platformă. Guvernanță computațională federată.”Zhamak Dehghani · Data Mesh Principles and Logical Architecture · 2020 · Data Mesh Principles and Logical Architecture, martinfowler.com (2020) — cele patru principii, în ordinea din articol

Un produs de date are proprietar, schemă, SLA și o adresă — altfel e doar un tabel.

Problema pe care o rezolvă data mesh-ul e organizațională: echipa centrală de date devine gât de sticlă și nu cunoaște semantica a douăzeci de domenii; când comanda „a fost anulată” înseamnă altceva în logistică decât în facturare, echipa centrală află ultima. Primul principiu mută proprietatea la domeniu. Al doilea cere ca ce publică domeniul să fie un produs: set de date cu schemă, proprietar, SLA, documentație, adresă de acces — descoperibil, de încredere, interoperabil. Al treilea, platforma self-serve, e ce face primele două posibile: echipele publică fără să-și construiască fiecare propria infrastructură. Al patrulea, guvernanța federată computațională, spune că regulile comune — ce e PII, ce formate, ce identificatori — sunt cod verificat automat, nu un comitet. Capcana: mesh fără platformă înseamnă douăsprezece depozite incompatibile cu un nume nou. Și scara contează: pentru o firmă cu o singură echipă de date, un depozit central bine modelat e răspunsul corect, nu o versiune diminuată de mesh.

Cardul spune cine devine proprietar. Pasul următor e de ce: proprietatea nu e doar o sarcină, ci o cunoaștere. Cine produce datele înțelege ce înseamnă ele cu adevărat. Când comanda „a fost anulată” înseamnă altceva în logistică decât în facturare, nimeni dintr-o echipă centrală nu poate ghici asta corect. E ca și cum ai cere unei traduceri să traducă un contract juridic fără să fi văzut vreodată unul. Mutarea proprietății la domeniu mută decizia semantică acolo unde trăiește sensul. Echipa centrală nu dispare; încetează doar să mai fie gâtul prin care trec toate întrebările despre semnificație. Dar odată ce fiecare domeniu deține sensul propriu, apare o întrebare nouă: ce anume publică el, ca ceilalți să poată avea încredere?

Pasajul 1 s-a oprit la întrebarea încrederii. Răspunsul lui Dehghani e că domeniul nu publică un set de date, ci un produs. Un produs are un utilizator, o promisiune și un responsabil. O schemă, documentație, o adresă de acces și o înțelegere despre cât de proaspete sunt datele. Gândește-te la un apartament închiriat: nu-ți dă cheia și atât, ci un contract, un proprietar de contactat, o descriere exactă. Fără acestea, fiecare echipă consumatoare trebuie să sune la cineva și să întrebe ce înseamnă fiecare coloană. Asta reface gâtul de sticlă pe altă ușă. Tratând datele ca produs, echipa de logistică nu mai răspunde la telefoane; răspunde cu un catalog clar. Dar un produs bun are nevoie de un raft pe care să-l așezi. De unde vine acel raft comun?

De ce contează Cele mai multe eșecuri de „mesh” sunt eșecuri de platformă: s-a descentralizat proprietatea înainte să existe ceva comun pe care să se publice.

DomeniiproprietareDate caprodusPlatformăself-serve
Guvernanța federată e ce ține cele trei cercuri suprapuse, nu doar alăturate.
Deschide pe YouTube ↗

← Vezi tot fluxul