ARTIGO 03 · DADOS E ARQUITETURA

Data Mesh e Data Fabric: conceitos que mais confundem candidatos

Domínios, produtos de dados, metadados e governança explicados com um caso de aplicação e exercícios comentados.

Olá, querido(a) aluno(a)!

Uma área de fiscalização precisa cruzar contratos, pagamentos e entregas. Os dados existem, mas ninguém consegue explicar com segurança qual cadastro está atualizado, quem corrige uma inconsistência ou por que dois relatórios apresentam valores diferentes. Comprar outro banco de dados não resolve, por si só, esse conjunto de problemas.

Data Mesh e Data Fabric aparecem nas discussões sobre esse desafio. Os nomes se aproximam, mas suas ênfases são diferentes. O primeiro discute principalmente como distribuir responsabilidades e oferecer dados como produtos. O segundo enfatiza uma arquitetura de integração e gestão orientada por metadados. A distinção interessa a analistas, arquitetos, auditores e candidatos que precisam interpretar cenários, e não apenas decorar traduções.

Neste artigo, vamos separar organização, tecnologia e armazenamento, examinar os pontos de contato e construir uma solução hipotética para um órgão público. Os exemplos são didáticos: não representam exigências de uma norma nem relatos de implantação real.

1. O que são Data Mesh e Data Fabric?

Data Mesh é uma abordagem sociotécnica: trata simultaneamente de pessoas, responsabilidades e arquitetura. Na formulação de Zhamak Dehghani, seus quatro princípios são propriedade orientada a domínios, dados como produto, infraestrutura de autosserviço e governança computacional federada. A proposta foi desenvolvida para lidar com a complexidade do uso analítico de dados em escala. Fonte: formulação original de Dehghani.

Data Fabric é uma abordagem arquitetural para integrar descoberta, acesso e gestão de dados distribuídos. Metadados ajudam a contextualizar ativos e podem alimentar mecanismos de automação. A arquitetura pode abranger ambientes locais e serviços em nuvem, sem exigir que todos os dados sejam fisicamente transferidos para um único repositório. Fonte: documentação conceitual da IBM.

Não existe uma edição normativa única, como ocorre com uma norma técnica identificada por número e ano. Documentações e implementações evoluem; por isso, uma questão que atribui características a um fabricante deve ser analisada segundo essa referência. Também é necessário separar o conceito Data Fabric do produto Microsoft Fabric. Um nome comercial não define sozinho toda a categoria arquitetural.

Para começar a análise de um enunciado, faça duas perguntas: o problema descrito é a concentração de responsabilidade em uma equipe ou a dificuldade de conectar e governar ativos heterogêneos? A primeira pergunta aproxima a discussão de Mesh; a segunda, de Fabric. Elas servem como orientação inicial, não como uma classificação rígida de projetos reais.

2. Para que essas abordagens servem?

O objetivo organizacional não deve ser “ter uma arquitetura moderna”. Deve ser resolver uma dificuldade observável: localizar uma informação, interpretar corretamente uma medida, autorizar seu uso, manter sua qualidade ou reduzir a dependência de conhecimento informal. Antes de escolher termos, descreva a decisão que o consumidor precisa tomar.

Os benefícios dependem da execução. Distribuir responsabilidades sem orçamento, pessoas e critérios de aceitação pode apenas distribuir o problema. Integrar fontes sem esclarecer conceitos pode produzir uma visão unificada tecnicamente correta e administrativamente enganosa. Uma coluna chamada “valor” não explica se representa preço contratado, pagamento realizado ou saldo disponível.

3. Data Mesh e Data Fabric em comparação

A documentação da IBM apresenta as abordagens como complementares: capacidades de Fabric podem apoiar a criação e o consumo de produtos organizados segundo Mesh. Isso não significa que toda implantação de Mesh dependa de uma plataforma vendida como Fabric, nem que toda organização com Fabric tenha adotado Mesh. Fonte: comparação técnica da IBM.

Data warehouse, data lake e lakehouse respondem a perguntas diferentes, relacionadas à organização, ao armazenamento e ao processamento. Um órgão pode manter um data warehouse e melhorar responsabilidades por domínio. Também pode integrar um data lake a mecanismos de catálogo e controle. Não há uma sequência universal na qual um desses termos obrigatoriamente substitui o anterior.

Outra confusão é equiparar descentralização a isolamento. Um domínio que publica arquivos sem contrato, sem documentação e sem interlocutor não cria automaticamente um produto confiável. A autonomia precisa funcionar dentro de condições que permitam o consumo por outras equipes.

4. Como funciona o raciocínio de implantação?

O roteiro a seguir é uma proposta didática de análise. Ele não é uma metodologia obrigatória atribuída às fontes. Seu propósito é mostrar como transformar uma discussão abstrata em decisões verificáveis.

4.1 Definir um caso de consumo

Registre quem utilizará os dados e qual decisão pretende apoiar. No exemplo, a auditoria deseja identificar pagamentos sem entrega registrada. O resultado esperado dessa etapa é uma pergunta operacional, com limites explícitos. “Melhorar todos os dados do órgão” não permite avaliar o primeiro resultado.

4.2 Identificar significados e responsáveis

Converse com os responsáveis pelos processos antes de desenhar integrações. Uma entrega parcial pode ser válida; um pagamento pode estar associado a uma medição e não ao contrato inteiro. O resultado é um vocabulário mínimo e uma lista de responsáveis por esclarecer divergências.

4.3 Desenhar o produto e sua interface

Defina campos, periodicidade, histórico, critérios de qualidade e modo de acesso. Uma interface de programação de aplicações, ou API, é uma opção. Uma tabela autorizada ou um arquivo controlado também pode atender. A escolha deve refletir necessidade, custo e capacidade operacional.

4.4 Aplicar regras comuns

Estabeleça quais informações de identificação, acesso e rastreabilidade devem acompanhar qualquer produto. Uma regra pode exigir a indicação da data de atualização e do responsável. Outra pode impedir a publicação de determinados campos sem classificação prévia. O resultado é uma base comum que permite autonomia sem improvisação.

4.5 Operar, observar e corrigir

Depois da publicação, acompanhe falhas, dúvidas dos consumidores e alterações de significado. A entrega não termina quando a primeira consulta funciona. Um produto que muda silenciosamente pode quebrar relatórios e comprometer decisões, mesmo sem ocorrer indisponibilidade técnica.

5. Elementos essenciais e o que eles não significam

A documentação de arquitetura do Google Cloud distingue produtos de dados, recursos físicos e atributos. Também descreve serviços centrais e interfaces pelas quais os domínios expõem produtos. A utilidade didática dessa separação é evitar a identificação automática entre produto e arquivo: o produto é uma unidade lógica de oferta, não apenas um objeto de armazenamento. Fonte: arquitetura de Data Mesh do Google Cloud.

Uma forma simples de testar a qualidade de uma oferta é entregá-la a alguém que não participou de sua construção. Essa pessoa consegue saber a que período se refere, quais exclusões foram realizadas e como registrar um problema? Se depende de uma conversa privada com o autor para cada uso, ainda existe conhecimento essencial fora do produto.

Metadados ativos são utilizados para orientar ações, e não somente armazenados para consulta humana. Em um exemplo hipotético, a alteração de classificação de um campo poderia acionar uma revisão de acesso. Essa automação precisa de regras confiáveis e tratamento de exceções. A simples presença de um catálogo não demonstra que esse comportamento foi implementado.

6. Decisões de arquitetura e seus limites

Centralizar ou distribuir armazenamento é uma decisão diferente de centralizar ou distribuir responsabilidade. Uma equipe de domínio pode manter seu produto em infraestrutura compartilhada. Da mesma maneira, bancos fisicamente distribuídos podem continuar dependentes de uma única equipe para toda mudança.

A AWS descreve a adoção de Mesh como evolução que envolve domínios, responsáveis, produtos, padrões comuns e mudança organizacional. Sua orientação admite começar com um subconjunto de domínios. Isso ajuda a compreender por que instalar uma ferramenta, sem modificar a operação, não estabelece o modelo completo. Fonte: visão de Data Mesh da AWS.

Também é necessário escolher entre copiar dados, consultar fontes remotamente ou combinar estratégias. Uma cópia pode facilitar desempenho e preservação histórica, mas exige atualização e controle de versões. Uma consulta remota reduz algumas duplicações, porém cria dependência da disponibilidade e da capacidade da origem. Nenhuma dessas escolhas é sempre superior.

A arquitetura de referência da IBM para Fabric organiza capacidades como importação e enriquecimento de metadados, catalogação, transformação e consumo. Trata-se de uma referência de implementação, e não de uma lista de requisitos universalmente obrigatória para qualquer solução. Fonte: arquitetura de referência da IBM.

Em uma prova discursiva, apresente o critério antes da ferramenta. Por exemplo: “A necessidade de rastrear alterações históricas justifica manter versões controladas do conjunto”. Essa construção mostra raciocínio. Escrever apenas o nome de um serviço de nuvem não explica por que a solução atende ao problema.

7. Exemplo completo: acompanhamento de contratos

Considere uma autarquia fictícia com três unidades: contratações, financeiro e fiscalização. A auditoria recebe mensalmente três planilhas. O número de contrato tem formatos diferentes, alguns registros de entrega chegam depois do fechamento e os pagamentos incluem ajustes. A equipe técnica central passa dias esclarecendo regras que pertencem às áreas de negócio.

O primeiro passo é limitar a pergunta: identificar pagamentos de contratos de manutenção cuja entrega correspondente não tenha sido localizada no período analisado. A equipe não pretende classificar automaticamente o pagamento como irregular. A ausência de correspondência será um sinal para exame humano.

Contratações fica responsável por um produto com identificador estável, unidade contratante e vigência. Financeiro mantém um produto de pagamentos, com data, valor, natureza e referência ao contrato. Fiscalização publica medições e entregas. A área de auditoria mantém um produto derivado que relaciona essas ofertas e registra os critérios de seleção.

Essa distribuição exemplifica o raciocínio de Mesh: quem conhece o significado responde pela oferta correspondente. Não significa que cada setor precisará contratar uma equipe completa de infraestrutura. Uma plataforma compartilhada poderá fornecer publicação, controle de acesso e registro de execução.

Para integrar o conjunto, a equipe estabelece um catálogo comum. Cada produto informa responsável, periodicidade e interpretação dos campos. Os metadados registram que uma medição pode abranger diversas entregas. O mecanismo de integração usa esses registros e mantém a origem dos valores calculados. Essas capacidades ilustram como uma arquitetura de Fabric pode apoiar o cenário.

A equipe encontra um problema semântico: “data da entrega” significa data física para uma unidade e data de aceite para outra. A decisão é publicar campos separados, com descrições distintas. Não se tenta corrigir a diferença apenas renomeando colunas em uma consulta. A solução exige acordo entre pessoas que compreendem o processo.

Um segundo problema envolve atualização. O financeiro publica diariamente, mas a fiscalização consolida semanalmente. Um cruzamento diário poderia gerar muitos alertas prematuros. O produto de auditoria passa a informar o período de cobertura de cada fonte e a classificar resultados ainda incompletos como pendentes de consolidação.

Um terceiro problema aparece quando uma fonte deixa de atualizar. A última carga bem-sucedida continua disponível, acompanhada de aviso sobre sua defasagem. Dependendo da finalidade, o consumo automatizado pode ser interrompido. Essa escolha deve ser explícita: apresentar silenciosamente dados antigos como atuais seria uma falha de comunicação do produto.

O resultado esperado é uma análise reproduzível, com menos esclarecimentos informais e responsabilidade identificável. O risco remanescente é que uma entrega tenha sido registrada incorretamente na origem. Rastreabilidade ajuda a investigar, mas não transforma um registro incorreto em verdadeiro.

8. Aplicação em pequenas organizações

Uma pequena equipe não precisa criar vários domínios artificiais para demonstrar maturidade. Pode começar com um conjunto crítico, um responsável e uma descrição acessível. O primeiro ganho pode ser tão concreto quanto eliminar dúvidas sobre qual relatório deve ser utilizado no fechamento.

Imagine uma escola técnica com registros de matrícula e conclusão. Duas pessoas mantêm os sistemas. Antes de contratar uma plataforma complexa, elas podem documentar a diferença entre estudante matriculado, ativo e concluinte, definir quem valida cada informação e estabelecer um arquivo de entrega com período e versão.

Um repositório controlado pode guardar dicionário de dados, procedimento de atualização e registro de mudanças. Consultas automatizadas simples podem verificar identificadores ausentes. A autorização de acesso continua necessária. Essa iniciativa aproveita princípios de responsabilidade e qualidade sem afirmar que implementou integralmente Mesh ou Fabric.

O critério de evolução é a necessidade observada. Se a equipe passa a administrar muitas fontes e consumidores, capacidades de descoberta e automação podem se tornar justificáveis. Se o problema permanece restrito a uma definição ambígua, uma conversa formalizada pode ser mais útil que uma nova ferramenta.

9. Como interpretar questões de concurso

Não há, neste artigo, uma estatística de frequência de cobrança. A proposta é preparar a análise dos conceitos quando constarem do conteúdo programático. Leia especialmente os qualificadores: “exclusivamente”, “obrigatoriamente”, “sempre” e “dispensa” podem transformar uma descrição razoável em afirmação incorreta.

Primeiro, identifique a unidade de análise: organização, arquitetura ou repositório. Depois, verifique se o enunciado atribui a uma abordagem uma exclusividade que ela não possui. Por fim, procure o problema de governança: quem decide, quem executa e quem responde quando há uma falha.

9.1 Exercício discursivo: justifique uma escolha

Considere esta situação autoral: um tribunal mantém dados processuais em sistemas de gerações diferentes. A equipe de estatística solicita um indicador mensal, mas as unidades divergem sobre o significado de “processo encerrado”. O gestor propõe adquirir uma ferramenta de integração para resolver a divergência. A questão pede uma avaliação e duas providências.

Uma resposta adequada começa reconhecendo que a ferramenta pode ajudar no acesso e na transformação, mas não decide sozinha qual significado administrativo deve ser adotado. É necessário estabelecer a definição do indicador com os responsáveis e registrar situações que exigem tratamento específico. Depois, a equipe poderá implementar a integração correspondente e tornar o cálculo rastreável.

Como primeira providência, o candidato pode propor a definição de um responsável pelo produto estatístico e de interlocutores nas unidades produtoras. Como segunda, pode indicar documentação do cálculo, origem, periodicidade e verificações de consistência. A resposta não precisa afirmar que o tribunal deve implantar integralmente uma das duas abordagens. Ela pode usar seus princípios para justificar medidas proporcionais.

Observe como essa construção evita duas simplificações: a ideia de que tecnologia é irrelevante e a ideia de que tecnologia resolve significado. Também evita transformar um problema delimitado em um programa de reorganização de todo o órgão sem conhecer custos e restrições.

9.2 Exercício de auditoria: o que pedir como evidência?

Imagine que uma organização afirme possuir produtos de dados governados. Um catálogo apresenta nomes, descrições e responsáveis, mas não há registro de atualização dos últimos meses. Como auditor, você não deve concluir automaticamente que os produtos são inadequados. Pode começar verificando a periodicidade prometida e a evidência de sua execução.

Se a oferta é mensal, solicite registros de publicação, identificação da versão utilizada por consumidores e tratamento de falhas. Se existe compromisso de qualidade, examine como foi medido. Se determinado campo é restrito, verifique uma amostra de concessões e revogações de acesso. O objetivo é comparar declaração e operação, sem exigir uma tecnologia específica que não faça parte do critério da auditoria.

Uma evidência adicional pode ser um histórico de mudança. Quando o significado de uma categoria foi alterado, houve comunicação? O consumidor conseguiu identificar a data a partir da qual o novo conceito passou a valer? Essas perguntas avaliam a continuidade do entendimento, além da disponibilidade do serviço.

Para concluir o exercício, escreva uma observação objetiva: “Não foi localizada evidência de atualização conforme a periodicidade declarada para os períodos examinados”. Essa redação é mais precisa do que afirmar que a organização “não tem Data Mesh”. O primeiro texto identifica uma condição verificável; o segundo transforma uma deficiência específica em uma conclusão arquitetural ampla demais.

Nos dois exercícios, os nomes das abordagens funcionam como repertório. O desempenho do candidato depende de identificar o problema, relacionar conceitos ao cenário e demonstrar os limites da solução. Essa habilidade é transferível para questões sobre governança, qualidade, arquitetura corporativa e auditoria de sistemas.

10. Roteiro de revisão

Feche o texto e explique a diferença entre as abordagens em quatro frases. Depois, desenhe três caixas: origem, produto e consumidor. Escreva acima delas os responsáveis e abaixo os controles. Se você conseguir explicar por que a infraestrutura pode ser compartilhada mesmo com responsabilidade distribuída, terá superado uma confusão importante.

Em seguida, crie um exemplo no qual o catálogo está correto, mas os dados estão desatualizados. Esse exercício separa descoberta, qualidade e operação. Por fim, descreva uma mudança de campo que exija aviso aos consumidores. A intenção é transformar definições em critérios de julgamento.

11. Perguntas frequentes

Qual é a principal diferença entre Data Mesh e Data Fabric?

Mesh enfatiza a organização de responsabilidades por domínio e a oferta de produtos de dados. Fabric enfatiza capacidades integradas para descobrir, conectar e administrar dados, apoiadas por metadados. A distinção é de ênfase, não uma divisão absoluta entre pessoas e tecnologia.

Data Mesh elimina a equipe central de dados?

Não necessariamente. Uma equipe central pode manter capacidades de plataforma e apoiar padrões compartilhados. O ponto é evitar que ela seja a única responsável por compreender e implementar todas as regras de todos os domínios.

Data Fabric obriga a copiar todos os dados?

Não. A arquitetura pode combinar formas de integração e acesso. A estratégia de movimentação depende dos requisitos de atualização, desempenho, segurança e custo do caso concreto.

Um data lake é incompatível com Data Mesh?

Não. O repositório pode integrar a infraestrutura de produtos de dados. A existência do lake, por si só, não demonstra nem impede o modelo organizacional.

Existe certificação obrigatória de Data Mesh ou Data Fabric?

Não há uma certificação normativa universal inerente aos conceitos. Cursos e credenciais comerciais devem ser distinguidos de uma exigência de conformidade definida por norma ou contrato.

Qual abordagem é melhor para um órgão pequeno?

A resposta depende do problema. Começar por responsáveis, definições e qualidade pode ser suficiente. A complexidade de uma arquitetura deve ser justificada por necessidades de integração, autonomia e escala.

Ao revisar seu próprio exemplo, procure uma decisão de responsabilidade e outra de integração. Essa separação torna sua explicação mais precisa e reduz o uso de rótulos como substitutos da análise.

12. Conclusão

Compreender Data Mesh e Data Fabric exige separar responsabilidades, capacidades de integração e escolhas de armazenamento. Para concursos, essa separação permite rejeitar falsas exclusividades e explicar cenários com precisão. Para a prática, ajuda a escolher intervenções proporcionais: esclarecer significado, oferecer um produto confiável, integrar fontes e acompanhar o uso. O nome da arquitetura só tem valor quando essas decisões melhoram a informação disponível ao consumidor.

Referências

• Zhamak Dehghani. Data Mesh Principles and Logical Architecture.
• IBM. What is a Data Fabric?
• IBM. Data Fabric e Data Mesh.
• IBM. Data and Analytics Data Fabric.
• Google Cloud. Architecture and functions in a data mesh.
• AWS. What is a Data Mesh?

Revisão editorial: 21/10/2026. Exemplos e questões elaborados para fins didáticos. Consulte a bibliografia indicada no edital do seu concurso.