1. Cos'è il data mesh?
Il data mesh è un approccio sociotecnico che decentralizza la proprietà dei dati verso i team di dominio. Creato da Zhamak Dehghani (ThoughtWorks) nel 2019, risolve i limiti di scala delle piattaforme dati centralizzate.
Il problema che risolve
I team dati centrali diventano colli di bottiglia. Mancano di contesto di dominio e costruiscono cose sbagliate. I domini aspettano mesi. Il data lake monolitico diventa uno swamp. Succede anche da te?
Architettura centralizzata vs data mesh
❌ Centralizzata (tradizionale)
- • Un solo team possiede tutti i dati
- • I domini lanciano i dati "oltre il muro"
- • Il team centrale non ha contesto di dominio
- • Data lake monolitico
- • Code lunghe per nuove richieste
- • Il team dati è il collo di bottiglia
✓ Data mesh
- • I domini possiedono i propri data product
- • I dati sono gestiti come prodotto con SLA
- • Gli esperti di dominio costruiscono i dati del proprio dominio
- • Data product federati e interoperabili
- • Piattaforma self-service per l'autonomia
- • Scala con l'organizzazione
Topologia data mesh
Dominio A
Ordini
Data Product
Dominio B
Clienti
Data Product
Dominio C
Inventario
Data Product
Piattaforma dati self-service
Infrastruttura • Tooling • Governance as Code
Governance computazionale federata
Politiche globali • Standard di interoperabilità
I domini possiedono i data product, la piattaforma abilita, la governance garantisce l'interoperabilità
Idea chiave
Il data mesh non è solo tecnologia: è cambiamento organizzativo. Ridistribuisci ownership, responsabilità e competenze. Trattarlo solo come progetto tecnico porta al fallimento.
2. I quattro principi del data mesh
Il data mesh poggia su quattro pilastri. Se ne manca uno, tutto crolla. Funzionano come un sistema.
1. Ownership orientata al dominio
I team che generano e conoscono i dati li possiedono. Marketing possiede i dati marketing, Sales quelli di vendita. Gli esperti di dominio diventano data product owner.
2. Dati come prodotto
Tratta i dati come un prodotto con consumatori. Hanno SLA, documentazione, versioning e un product owner. La qualità è responsabilità del dominio, non un problema da correggere più tardi dal centrale.
3. Piattaforma dati self-service
Un team piattaforma costruisce infrastruttura che i domini usano in autonomia. I domini non dovrebbero capire Kubernetes o Spark: costruiscono data product.
4. Governance computazionale federata
Le politiche globali (sicurezza, compliance, interoperabilità) sono definite centralmente ma applicate localmente tramite automazione. La governance è codice, non riunioni.
| Principio | Responsabile | Risultato chiave |
|---|---|---|
| Ownership di dominio | Team di dominio | Competenza contestuale, iterazione rapida |
| Dati come prodotto | Data product owner | Qualità, scopribilità, fiducia |
| Piattaforma self-service | Team piattaforma | Autonomia dei domini, meno attrito |
| Governance federata | Governance + piattaforma | Compliance, interoperabilità |
3. Focus sui data product
Un data product non è solo una tabella. È un’unità autonoma che include dati, codice, infrastruttura e metadati: tutto ciò che serve per fornire valore ai consumatori.
Le otto caratteristiche di un data product
Scopribile
Presente in un catalogo dati. I consumatori lo trovano senza chiedere.
Indirizzabile
Indirizzo univoco e stabile (URI). Accesso programmabile.
Affidabile
Metriche di qualità, SLO e data contract. I consumatori sanno cosa aspettarsi.
Auto-descrittivo
Schema, lineage e documentazione integrati. Zero conoscenza tribale.
Interoperabile
Rispetta standard globali di formati, identificatori e semantica.
Sicuro
Controllo accessi, cifratura, audit log. Conforme by default.
Accesso nativo
Più modalità: SQL, API, file. Incontra i consumatori dove sono.
Valore autonomo
Offre valore di business da solo. Non è una staging table.
Anatomia di un data product
Dati
- • Dati sorgente
- • Dati trasformati
- • Snapshot storici
Codice
- • Logica di trasformazione
- • Test di qualità
- • Definizioni di pipeline
Metadati
- • Definizioni di schema
- • Data contract
- • Informazioni di lineage
Esempio: manifesto di data product (YAML)
# orders-data-product/manifest.yaml name: orders domain: commerce owner: [email protected] version: 2.1.0 description: | Order transactions from all sales channels. Includes order items, totals, and fulfillment status. slo: freshness: 1h # Data no older than 1 hour availability: 99.9% # Uptime SLA quality_score: 95% # % of quality checks passing schema: type: delta location: s3://data-products/commerce/orders/ access: - sql: "SELECT * FROM commerce.orders" - api: "https://data.company.com/commerce/orders" lineage: sources: - system: shopify table: orders - system: pos table: transactions data_contract: primary_key: order_id not_null: [order_id, customer_id, order_date, total] quality_checks: - unique(order_id) - not_null(customer_id) - total >= 0 - order_date <= current_date()
Pro Tip
Parti da data product allineati ai consumatori
Non pubblicare solo tabelle sorgenti. Pensa a cosa serve ai consumatori. Un data product “Ordini” può combinare ordini, pagamenti e fulfillment in una vista denormalizzata facile da analizzare.
4. Piattaforma dati self-service
La piattaforma rende l’ownership di dominio praticabile. Senza, ogni dominio reinventerebbe l’infrastruttura generando caos. La piattaforma fornisce astrazioni opinionate che riducono il carico cognitivo.
Capacità della piattaforma
Infrastruttura dati
Storage (S3, Delta Lake), compute (Spark, dbt), orchestrazione (Airflow, Dagster). I domini usano, la piattaforma gestisce.
Template di data product
Template cookiecutter per nuovi data product. CI/CD pre-cablato, controlli qualità, registrazione a catalogo. Pronti in minuti.
Catalogo & discovery
Catalogo centrale (DataHub, Atlan, Collibra) dove sono registrati tutti i data product. Search, browse, lineage.
Controllo accessi e sicurezza
Identità centralizzata, RBAC, cifratura. I domini definiscono chi accede; la piattaforma applica.
Osservabilità e monitoraggio
Monitoraggio pipeline, dashboard di qualità, tracking SLO. I domini vedono la salute; la piattaforma aggrega.
| Componente | Fornito dalla piattaforma | Cosa fa il dominio |
|---|---|---|
| Storage | Bucket S3, tabelle Delta, policy | Scrive dati nei percorsi forniti |
| Compute | Cluster Spark, ambienti dbt | Esegue le trasformazioni |
| Pipeline | Infrastruttura Airflow/Dagster | Definisce DAG e schedule |
| Qualità | Framework di test, dashboard | Scrive test, imposta soglie |
| Catalogo | Istanza DataHub/Atlan | Registra prodotti, aggiunge documentazione |
La piattaforma non è un team dati centrale 2.0
Il team piattaforma costruisce infrastruttura e tooling, non data product. Se costruisce ancora dati di dominio, non hai decentralizzato. Abilita, non esegue.
5. Governance computazionale federata
La decentralizzazione senza governance porta al caos. La governance federata offre standard globali con autonomia locale. Le policy sono definite al centro ma applicate automaticamente tramite codice.
Cosa viene governato globalmente
Standard di interoperabilità
- • Convenzioni di naming (snake_case, prefissi)
- • Identificatori globali (formato customer_id)
- • Formati data/ora (UTC, ISO 8601)
- • Regole di evoluzione dello schema
Sicurezza e compliance
- • Gestione PII (masking, cifratura)
- • Pattern di controllo accessi
- • Policy di retention
- • Requisiti di audit log
Standard di qualità
- • Requisiti minimi di SLO
- • Test di qualità obbligatori
- • Standard di documentazione
- • Formato dei data contract
Cosa decide il dominio
- • Design del data product
- • Logica di business
- • Frequenza di aggiornamento (sopra lo SLO)
- • Grant di accesso specifici per i consumatori
“Computazionale” = governance as code
Esempio: policy as code (OPA/Rego)
# governance/policies/data_product.rego
package dataproduct
# All data products must have an owner
deny[msg] {
not input.manifest.owner
msg := "Data product must have an owner defined"
}
# PII columns must be tagged
deny[msg] {
column := input.schema.columns[_]
column.pii == true
not column.tags["pii"]
msg := sprintf("PII column %v must be tagged", [column.name])
}
# SLO freshness must be defined
deny[msg] {
not input.manifest.slo.freshness
msg := "Data product must define freshness SLO"
}
# Minimum documentation required
deny[msg] {
count(input.manifest.description) < 50
msg := "Data product description must be at least 50 characters"
}Pro Tip
Governance in CI/CD, non in riunione
Ogni PR di un data product passa per controlli di policy. Non conforme? Il build fallisce. Niente comitati di approvazione. La piattaforma applica automaticamente; le persone gestiscono solo le eccezioni.
6. Roadmap di implementazione
Il data mesh è un percorso pluriennale. Non far bollire l’oceano. Parti in piccolo, dimostra valore, poi espandi.
Fase 1: Fondazione (mesi 1-3)
Ottenere sponsorship executive. Identificare 1-2 domini pilota. Definire gli standard minimi di governance.
- • Scegliere domini pilota motivati
- • Documentare stato attuale e pain point
- • Definire cosa significa “data product” nella tua azienda
- • Identificare il team piattaforma (o assumerlo)
Fase 2: Primi data product (mesi 3-6)
I domini pilota costruiscono i primi data product. La piattaforma fornisce l’infrastruttura minima.
- • Costruire 2-3 data product per dominio pilota
- • Deploy di un catalogo base (anche un foglio di calcolo)
- • Stabilire un template di data product
- • Documentare le lesson learned e iterare
Fase 3: Maturità della piattaforma (mesi 6-12)
Il team piattaforma productizza le lesson learned. Emergono capacità self-service. Altri domini salgono a bordo.
- • Implementare un vero data catalog
- • Costruire la CI/CD per i data product
- • Automatizzare i controlli di governance
- • Onboard di 3-5 domini aggiuntivi
Fase 4: Scala (anno 2+)
Adozione enterprise. La piattaforma è matura. Focus su ottimizzazione e capacità avanzate.
- • Tutti i domini producono data product
- • Emergono data product cross-dominio
- • Marketplace di data product
- • Miglioramento continuo della piattaforma
Dal campo
L’errore più comune: iniziare dalla piattaforma. Non costruire una bellissima piattaforma self-service e poi cercare utenti. Parti da domini che creano data product manualmente. Il loro dolore definisce i requisiti della piattaforma.
7. Anti-pattern da evitare
Trattare il mesh come progetto tecnico
Comprare tool senza cambiare l’organizzazione. Il mesh è sociotecnico: il cambiamento organizzativo viene prima, la tecnologia lo supporta.
Il team centrale costruisce ancora dati di dominio
Chiamare “team di dominio” ingegneri embedded ma che riportano al centrale. La vera ownership rende il dominio accountable.
Solo decentralizzazione, niente piattaforma
Dire ai domini “ora possedete i vostri dati” senza fornire strumenti. Risultato: duplicazione, caos, burnout.
Governance a colpi di comitato
Riunioni mensili invece di controlli automatici. Policy sui documenti, non nel codice.
Ogni tabella è un data product
Pubblicare tabelle di staging chiamandole prodotti. Un data product deve fornire valore di business, non solo esporre dati.
Ignorare il change management
Aspettarsi ownership dai domini senza formazione, incentivi e percorsi di carriera.
Reality check
Il data mesh è per te?
Il data mesh potrebbe non essere la risposta se: hai meno di 50 persone, un solo prodotto/dominio, un team centrale che funziona, o leadership che non supporta il cambiamento. È una soluzione a problemi di scala; senza problemi di scala, un buon team centrale può bastare.
8. FAQ
Che cos’è il data mesh?
Il data mesh è un’architettura dati decentralizzata che tratta i dati come un prodotto posseduto dai team di dominio, non da un team centrale. Quattro principi: ownership di dominio, dati come prodotto, piattaforma dati self-service, governance computazionale federata. Creato da Zhamak Dehghani.
Differenza tra data mesh e data fabric?
Data mesh: approccio organizzativo/architetturale con decentralizzazione e ownership di dominio. Data fabric: approccio tecnologico basato su metadati e AI per un layer unificato. Il mesh cambia il modo di lavorare; il fabric riguarda strumenti e automazione. Possono coesistere.
Che cos’è un data product nel mesh?
Un data product è un’unità autonoma, scopribile, indirizzabile, affidabile, auto-descrittiva, interoperabile e sicura. Include dati, metadati, codice di trasformazione, infrastruttura e documentazione. I team di dominio lo gestiscono come un microservizio.
Quando evitare il data mesh?
Non è ideale se: l’organizzazione ha meno di 50 persone, hai un solo dominio o prodotto, il team centrale funziona, manca maturità ingegneristica per il self-service, o la leadership non supporta il cambiamento. È una trasformazione organizzativa, non solo tecnica.
Visualizza la tua architettura data mesh
Mappa domini, data product e componenti di piattaforma. Crea diagrammi chiari che comunichino la tua visione di data mesh a stakeholder e team.
Guide correlate
Medallion architecture
Layer Bronze, Silver, Gold nei tuoi data product
Modellazione dimensionale
Progettare data product che gli analyst adorano
Data contract
Definire interfacce e garanzie dei data product
Best practice di qualità dati
Portare la qualità dentro i data product
Best practice di data lineage
Tracciare i flussi dati tra domini e prodotti