Guia de arquitetura de dados

Guia Data Mesh

O time de dados central é um gargalo. Cada domínio quer dados, mas os pedidos se acumulam. O data mesh inverte o modelo: domínios são donos dos dados como produtos e um time de plataforma habilita o self-service.

25 min de leituraPara líderes de dados e plataformaPadrões de implementação incluídos

1. O que é data mesh?

Data mesh é uma abordagem sociotécnica que descentraliza a propriedade dos dados para times de domínio. Criado por Zhamak Dehghani (ThoughtWorks) em 2019, resolve os desafios de escala das plataformas centralizadas.

O problema que resolve

Times centrais viram gargalo. Sem contexto de domínio, constroem coisas erradas. Domínios esperam meses. O data lake monolítico vira um data swamp. Parece familiar?

Arquitetura centralizada vs data mesh

❌ Centralizada (tradicional)

  • • Um time de dados possui tudo
  • • Domínios jogam dados “por cima do muro”
  • • Time central sem contexto de domínio
  • • Data lake monolítico
  • • Filas longas para novas demandas
  • • Time de dados = gargalo

✓ Data mesh

  • • Domínios são donos dos seus data products
  • • Dados tratados como produto com SLA
  • • Especialistas de domínio constroem seus dados
  • • Data products federados e interoperáveis
  • • Plataforma self-service habilita autonomia
  • • Escala junto com a organização

Topologia data mesh

Domínio A

Pedidos

Data Product

Domínio B

Clientes

Data Product

Domínio C

Inventário

Data Product

Plataforma de dados self-service

Infraestrutura • Ferramentas • Governance as Code

Governança computacional federada

Políticas globais • Padrões de interoperabilidade

Domínios possuem data products, a plataforma habilita, a governança garante interoperabilidade

Insight-chave

Data mesh não é só tecnologia: é mudança organizacional. Você redistribui propriedade, responsabilidade e habilidades. Se tratar apenas como projeto técnico, vai falhar.

2. Os quatro princípios do data mesh

Data mesh se apoia em quatro pilares. Falte um e tudo desaba. Eles funcionam como sistema único.

1. Ownership orientado a domínio

Os times que geram e entendem os dados são donos deles. Marketing cuida dos dados de marketing, Vendas dos de vendas. Especialistas de domínio viram owners de data product.

O que muda: Data engineers ficam dentro dos times de domínio. Domínios respondem por qualidade e disponibilidade. O time central vira time de plataforma.

2. Dados como produto

Trate dados como produto com consumidores. Tem SLA, documentação, versionamento e um product owner. Qualidade é responsabilidade do domínio, não algo para corrigir depois pelo time central.

O que muda: Dados têm descobribilidade, SLO, esquemas e docs. Os domínios pensam “quem vai usar?” em vez de “joga em algum lugar”.

3. Plataforma de dados self-service

Um time de plataforma constrói a infraestrutura que os domínios usam com autonomia. Eles não deveriam entender Kubernetes ou Spark – apenas criar data products.

O que muda: O time central vira time de plataforma. Cria ferramentas, templates e automações. Reduz a carga cognitiva.

4. Governança computacional federada

Políticas globais (segurança, compliance, interoperabilidade) são definidas centralmente, mas aplicadas localmente por automação. Governança é código, não reunião.

O que muda: Políticas codificadas na plataforma. Checagens automáticas de conformidade. Domínios com autonomia dentro de guardrails.
PrincípioResponsávelResultado chave
Ownership de domínioTimes de domínioContexto, iteração rápida
Dados como produtoOwners de data productQualidade, descobribilidade, confiança
Plataforma self-serviceTime de plataformaAutonomia, menos atrito
Governança federadaGovernança + plataformaCompliance, interoperabilidade

3. Data products em detalhe

Um data product não é só uma tabela. É uma unidade autônoma com dados, código, infraestrutura e metadados — tudo para entregar valor aos consumidores.

As oito características de um data product

Descobrível

Listada em um catálogo. Consumidores encontram sem pedir ajuda.

Endereçável

Endereço único e estável (URI). Acesso programático.

Confiável

Métricas de qualidade, SLO e data contracts. Expectativa clara.

Autoexplicativo

Schema, lineage e documentação embutidos. Sem conhecimento tribal.

Interoperável

Segue padrões globais de formatos, identificadores e semântica.

Seguro

Controle de acesso, criptografia, trilhas de auditoria. Conforme por padrão.

Acesso nativo

Vários modos: SQL, API, arquivos. Encontre o consumidor onde ele está.

Valor autônomo

Entrega valor de negócio sozinha. Não é tabela de staging.

Anatomia de um data product

Dados

  • • Dados de origem
  • • Dados transformados
  • • Snapshots históricos

Código

  • • Lógica de transformação
  • • Testes de qualidade
  • • Definições de pipeline

Metadados

  • • Definições de schema
  • • Data contracts
  • • Informações de lineage

Exemplo: manifesto de 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

Comece por data products orientados ao consumidor

Não publique apenas tabelas de origem. Pense no que o consumidor precisa. Um data product “Pedidos” pode combinar pedidos, pagamentos e fulfillment em uma visão denormalizada fácil de analisar.

4. Plataforma de dados self-service

A plataforma torna viável o ownership por domínio. Sem ela, cada domínio reinventaria infraestrutura e o caos seria certo. A plataforma oferece abstrações opinadas que reduzem a carga cognitiva.

Capacidades da plataforma

Infraestrutura de dados

Storage (S3, Delta Lake), compute (Spark, dbt), orquestração (Airflow, Dagster). Domínios usam, plataforma opera.

Templates de data product

Templates cookiecutter para novos data products. CI/CD pré-configurado, checagens de qualidade, registro no catálogo. Pronto em minutos.

Catálogo e discovery

Catálogo central (DataHub, Atlan, Collibra) onde todos os data products são registrados. Buscar, navegar, entender lineage.

Controle de acesso e segurança

Identidade centralizada, RBAC, criptografia. Domínios definem quem acessa; a plataforma aplica.

Observabilidade e monitoramento

Monitoramento de pipelines, dashboards de qualidade, tracking de SLO. Domínios veem sua saúde; plataforma agrega.

ComponentePlataforma forneceDomínio faz
StorageBuckets S3, tabelas Delta, políticasEscreve dados nos caminhos fornecidos
ComputeClusters Spark, ambientes dbtExecuta transformações
PipelinesInfra Airflow/DagsterDefine DAGs e agendas
QualidadeFramework de testes, dashboardsEscreve testes, define limites
CatálogoInstância DataHub/AtlanRegistra produtos, adiciona docs

Plataforma ≠ time central 2.0

O time de plataforma constrói infraestrutura e tooling — não data products. Se ainda produz dados de domínio, não houve descentralização. Ele habilita, não executa.

5. Governança computacional federada

Descentralização sem governança vira caos. Governança federada entrega padrões globais com autonomia local. Políticas são definidas centralmente e aplicadas automaticamente via código.

O que é governado globalmente

Padrões de interoperabilidade

  • • Convenções de nomes (snake_case, prefixos)
  • • Identificadores globais (formato customer_id)
  • • Formatos de data/hora (UTC, ISO 8601)
  • • Regras de evolução de schema

Segurança e compliance

  • • Tratamento de PII (mascaramento, criptografia)
  • • Padrões de controle de acesso
  • • Políticas de retenção
  • • Exigências de trilhas de auditoria

Padrões de qualidade

  • • SLO mínimo
  • • Checagens de qualidade obrigatórias
  • • Padrões de documentação
  • • Formato de data contracts

O que os domínios decidem

  • • Design do data product
  • • Lógica de negócio
  • • Frequência de atualização (acima do SLO)
  • • Grants específicos para consumidores

“Computacional” = governança como código

Exemplo: 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

Governança no CI/CD, não em comitês

Todo PR de data product passa por checagens de policy. Não está conforme? O build falha. Nada de comitês. A plataforma aplica automaticamente; pessoas revisam exceções, não conformidade rotineira.

6. Roteiro de implementação

Data mesh é uma jornada de vários anos. Não tente abraçar tudo. Comece pequeno, prove valor, expanda.

Fase 1: Fundação (meses 1-3)

Conseguir apoio executivo. Escolher 1-2 domínios piloto. Definir padrões mínimos de governança.

  • • Selecionar domínios piloto motivados
  • • Documentar estado atual e dores
  • • Definir o que “data product” significa para sua organização
  • • Formar o time de plataforma (ou contratar)

Fase 2: Primeiros data products (meses 3-6)

Domínios piloto constroem seus primeiros data products. A plataforma fornece a infraestrutura mínima viável.

  • • Construir 2-3 data products por domínio piloto
  • • Lançar um catálogo básico (mesmo uma planilha)
  • • Criar um template de data product
  • • Documentar aprendizados e iterar

Fase 3: Maturidade de plataforma (meses 6-12)

Time de plataforma productiza aprendizados. Capacidades self-service surgem. Mais domínios entram.

  • • Implementar um catálogo de dados de verdade
  • • Construir CI/CD de data product
  • • Automatizar checagens de governança
  • • Onboard de 3-5 domínios adicionais

Fase 4: Escala (ano 2+)

Adoção em toda a organização. Plataforma madura. Foco em otimização e capacidades avançadas.

  • • Todos os domínios produzindo data products
  • • Surgem data products entre domínios
  • • Marketplace de data products
  • • Melhoria contínua da plataforma

Da prática

Maior erro que vejo: começar pela plataforma. Não construa uma plataforma self-service linda para depois buscar usuários. Comece com domínios criando data products manualmente. A dor deles define os requisitos da plataforma.

7. Anti-padrões a evitar

Tratar mesh como projeto de tecnologia

Comprar ferramentas sem mudar a organização. Mesh é sociotécnico — mudança organizacional vem primeiro, a tecnologia suporta.

Time central ainda constrói dados de domínio

Chamar engenheiros alocados de “time de domínio” mas reportando ao central. Ownership real torna o domínio responsável.

Sem plataforma, só descentralização

Dizer aos domínios “agora são donos dos dados” sem dar ferramentas. Resultado: duplicação, caos, burnout.

Governança por comitê

Reuniões mensais em vez de checagens automáticas. Políticas em documentos, não em código.

Toda tabela vira data product

Publicar tabelas de staging e chamar de produto. Data product deve entregar valor de negócio, não apenas expor dados.

Ignorar gestão de mudança

Esperar ownership sem treinamento, incentivos e carreira em dados.

Reality check

Data mesh é para você?

Talvez não seja a resposta se: menos de 50 pessoas, um único produto/domínio, time central funcionando, pouca maturidade de engenharia para self-service ou liderança que não apoia mudança. É solução para desafios de escala — sem esses desafios, um bom time central pode bastar.

8. FAQ

O que é data mesh?

Data mesh é uma arquitetura de dados descentralizada que trata dados como produto de propriedade dos times de domínio, não de um time central. Quatro princípios: ownership de domínio, dados como produto, plataforma self-service, governança computacional federada. Criado por Zhamak Dehghani.

Diferença entre data mesh e data fabric?

Data mesh: enfoque organizacional/arquitetural com descentralização e ownership de domínio. Data fabric: enfoque tecnológico com metadados e IA para camada unificada. Mesh muda o trabalho; fabric trata de ferramentas e automação. Podem coexistir.

O que é um data product no mesh?

Um data product é uma unidade autônoma, descobrível, endereçável, confiável, autoexplicativa, interoperável e segura. Inclui dados, metadados, código de transformação, infraestrutura e documentação. Times de domínio operam como microserviços.

Quando não usar data mesh?

Pode não fazer sentido se: organização com menos de 50 pessoas, um domínio único, time central saudável, baixa maturidade para self-service ou liderança sem apoio. É transformação organizacional, não só técnica.

Visualize sua arquitetura data mesh

Mapeie domínios, data products e componentes de plataforma. Crie diagramas claros que comuniquem sua visão de data mesh para stakeholders e times.