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.
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.
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.
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.
| Princípio | Responsável | Resultado chave |
|---|---|---|
| Ownership de domínio | Times de domínio | Contexto, iteração rápida |
| Dados como produto | Owners de data product | Qualidade, descobribilidade, confiança |
| Plataforma self-service | Time de plataforma | Autonomia, menos atrito |
| Governança federada | Governança + plataforma | Compliance, 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.
| Componente | Plataforma fornece | Domínio faz |
|---|---|---|
| Storage | Buckets S3, tabelas Delta, políticas | Escreve dados nos caminhos fornecidos |
| Compute | Clusters Spark, ambientes dbt | Executa transformações |
| Pipelines | Infra Airflow/Dagster | Define DAGs e agendas |
| Qualidade | Framework de testes, dashboards | Escreve testes, define limites |
| Catálogo | Instância DataHub/Atlan | Registra 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.
Guias relacionados
Medallion Architecture
Camadas Bronze, Silver, Gold nos seus data products
Modelagem dimensional
Projetar data products que os analistas adoram
Data contracts
Definir interfaces e garantias dos data products
Boas práticas de qualidade de dados
Colocar qualidade no coração dos data products
Boas práticas de data lineage
Rastrear fluxos de dados entre domínios e produtos