Guida architettura dati

Guida Data Mesh

Il team dati centrale è un collo di bottiglia. Ogni dominio vuole dati ma le richieste si accumulano. Il data mesh ribalta il modello: i domini possiedono i loro dati come prodotti, mentre un team piattaforma abilita il self-service.

25 min di letturaPer leader dati e piattaformaPattern di implementazione inclusi

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.

Cosa cambia: i data engineer si inseriscono nei team di dominio. I domini sono responsabili di qualità e disponibilità. Il team centrale diventa team piattaforma.

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.

Cosa cambia: Dati con scopribilità, SLO, schemi e docs. I domini pensano “chi lo userà?” non “buttiamolo da qualche parte”.

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.

Cosa cambia: Il team centrale diventa piattaforma. Costruisce tool, template e automazioni. Riduce il carico cognitivo.

4. Governance computazionale federata

Le politiche globali (sicurezza, compliance, interoperabilità) sono definite centralmente ma applicate localmente tramite automazione. La governance è codice, non riunioni.

Cosa cambia: Le policy vivono nella piattaforma. Controlli di conformità automatici. I domini hanno autonomia entro guardrail.
PrincipioResponsabileRisultato chiave
Ownership di dominioTeam di dominioCompetenza contestuale, iterazione rapida
Dati come prodottoData product ownerQualità, scopribilità, fiducia
Piattaforma self-serviceTeam piattaformaAutonomia dei domini, meno attrito
Governance federataGovernance + piattaformaCompliance, 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.

ComponenteFornito dalla piattaformaCosa fa il dominio
StorageBucket S3, tabelle Delta, policyScrive dati nei percorsi forniti
ComputeCluster Spark, ambienti dbtEsegue le trasformazioni
PipelineInfrastruttura Airflow/DagsterDefinisce DAG e schedule
QualitàFramework di test, dashboardScrive test, imposta soglie
CatalogoIstanza DataHub/AtlanRegistra 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.