Arquitetura de malha de dados: dados descentralizados para empresas

O data warehouse centralizado tem sido a arquitetura de dados corporativos dominante há 30 anos. Neste modelo, uma equipe central de engenharia de dados é proprietária da infraestrutura de dados da empresa – ingerindo dados de sistemas de origem, limpando-os e transformando-os, e fornecendo-os aos consumidores através de um armazém central ou data lake. As equipes de negócios solicitam novos dados, aguardam que as equipes centrais os entreguem e aceitam as decisões prioritárias tomadas por uma única equipe central para todas as necessidades de dados da organização.

Este modelo funcionou razoavelmente bem quando os volumes de dados eram gerenciáveis, as fontes de dados eram limitadas e o ritmo das mudanças nos negócios era mais lento. Ele falha gravemente em ambientes empresariais modernos caracterizados por milhares de fontes de dados, dezenas de casos de uso de análise competindo pela largura de banda da equipe central e equipes de negócios que exigem acesso a dados medido em dias, em vez de trimestres.

A malha de dados é a resposta arquitetônica e organizacional a essas limitações. Em vez de centralizar a propriedade dos dados numa equipa de plataforma, distribui a propriedade aos domínios de negócio que melhor conhecem os dados – as equipas que os produzem. Em vez de tratar os dados como um subproduto das operações, trata-os como um produto com consumidores, padrões de qualidade e níveis de serviço.

Principais conclusões

• A malha de dados distribui a propriedade dos dados para equipes de domínio, em vez de concentrá-la em uma equipe central de dados
• Os quatro princípios: propriedade de domínio, dados como produto, infraestrutura de dados de autoatendimento e governança computacional federada
• A malha de dados resolve os problemas de escalabilidade, qualidade e agilidade das arquiteturas de dados centralizadas
• A implementação requer investimento em plataforma técnica e mudanças organizacionais significativas
• A plataforma de infraestrutura de dados de autoatendimento é a base técnica — sem ela, as equipes de domínio não podem possuir dados de forma eficaz
• A governança federada garante consistência e conformidade sem recriar gargalos centrais
• A malha de dados não elimina as equipes centrais de dados — ela muda seu papel de produtor para fornecedor e facilitador de plataforma
• A maioria das organizações deve implementar a malha de dados de forma incremental, começando pelos domínios mais problemáticos

---

O problema com arquiteturas de dados centralizadas

Para entender por que a malha de dados gerou tanto interesse empresarial, você precisa entender os pontos problemáticos específicos das arquiteturas centralizadas em escala.

O gargalo da equipe central

Num modelo centralizado, a equipa de engenharia de dados possui todos os pipelines de dados. Cada nova fonte de dados requer esforço da equipe central para integração. Cada novo caso de uso de análise requer tempo de desenvolvimento da equipe central. Cada problema de qualidade de dados deve ser diagnosticado e corrigido pela equipe central.

À medida que a organização cresce e os casos de uso de dados proliferam, a equipe central se torna um gargalo. As equipes de negócios esperam de 2 a 6 meses pelas integrações de dados. Os problemas de qualidade dos dados não são corrigidos porque as equipes centrais não têm contexto de domínio para diagnosticar as causas principais. As iniciativas de análise são atrasadas por trabalhos de infraestrutura de dados que competem com outras prioridades.

A fila cresce mais rápido do que a equipe consegue crescer. Adicionar mais engenheiros de dados centrais não resolve o problema fundamental – ele retarda o gargalo temporariamente enquanto o problema arquitetônico subjacente permanece.

Lacuna de experiência no domínio

A equipe central de dados sabe como construir pipelines. Eles não conhecem a semântica comercial dos dados que estão processando. O que significa “cliente” no contexto do domínio de vendas versus domínio de serviço? O que constitui um pedido “concluído” no domínio de atendimento? Qual é a regra correta de reconhecimento de receita para vendas de produtos por assinatura?

Os especialistas do domínio — as equipes de negócios que produzem os dados — possuem esse conhecimento. A equipe central não. Essa lacuna de conhecimento produz problemas de qualidade de dados que são difíceis de diagnosticar e corrigir porque os reparadores não têm o contexto para compreender os erros.

Inconsistência e baixa confiança

À medida que diferentes equipes criam suas próprias soluções alternativas – extraindo dados diretamente dos sistemas de origem, construindo armazenamentos de dados locais, mantendo planilhas em nível de departamento – a “fonte única de verdade” central se rompe. Múltiplas versões de métricas como “receita” e “cliente ativo” proliferam entre as equipes, com diferenças pequenas, mas consequentes, na definição.

Os líderes empresariais deixam de confiar nos dados, recorrem à intuição e resistem à tomada de decisões baseada em dados – não porque rejeitem o conceito, mas porque os dados não são fiáveis.

---

Os quatro princípios da malha de dados

Zhamak Dehghani, que cunhou o termo “malha de dados” em 2019 enquanto estava na ThoughtWorks, definiu-o através de quatro princípios.

Princípio 1: Propriedade de dados do domínio

Na malha de dados, os domínios de negócios possuem seus dados – produção, qualidade e publicação. O domínio de vendas possui dados de vendas. O domínio da cadeia de suprimentos possui dados de estoque e atendimento. O domínio do cliente possui o perfil do cliente e os dados de engajamento.

Propriedade do domínio significa: a equipe do domínio é responsável pela qualidade dos dados que publica, pela infraestrutura de pipeline que os produz e pelos níveis de serviço com os quais se compromete para os consumidores. Quando os dados estão errados, a equipe do domínio os corrige – eles têm a responsabilidade e o conhecimento do domínio para fazer isso.

Isso não significa que toda equipe de domínio se torne uma equipe de engenharia de dados. A plataforma de infraestrutura de dados de autoatendimento (Princípio 3) fornece as ferramentas que tornam prática a propriedade de domínios sem exigir profundo conhecimento em engenharia de dados em todos os domínios.

Princípio 2: Dados como produto

Na malha de dados, os dados são tratados como um produto – com consumidores, padrões de qualidade, documentação e níveis de serviço, como qualquer outro produto.

Um produto de dados é um ativo de dados limitado que:

• Tem propriedade clara (a equipe do domínio)
• É detectável (os consumidores podem encontrá-lo através de um catálogo de dados)
• Está documentado (os consumidores entendem o que contém e como usá-lo)
• Possui padrões de qualidade (precisão, integridade e pontualidade são medidas e mantidas)
• Possui níveis de serviço definidos (atualidade, disponibilidade, latência de acesso)
• Possui uma interface claramente definida (os consumidores acessam os dados por meio de APIs ou interfaces de consulta definidas, e não acessando os sistemas de origem)

A mentalidade do “produto” muda a forma como as equipes de domínio pensam sobre os dados que publicam. Um pipeline de dados é um detalhe de implementação; um produto de dados é algo que atende aos consumidores e deve ser mantido. Essa mudança no enquadramento gera comportamentos diferentes em relação à qualidade e confiabilidade.

Princípio 3: Infraestrutura de dados de autoatendimento

A propriedade de dados de domínio só é prática se os domínios tiverem ferramentas que tornem acessíveis o desenvolvimento de pipeline de dados, o monitoramento de qualidade e a publicação de produtos de dados, sem exigir conhecimentos especializados em engenharia de dados.

A plataforma de infraestrutura de dados de autoatendimento oferece:

• Ferramentas de pipeline de dados: desenvolvimento de pipeline com baixo código ou orientado por configuração que os engenheiros de domínio podem usar sem profundo conhecimento em engenharia de dados
• Estruturas de qualidade de dados: testes de qualidade automatizados, detecção de anomalias e painéis de índice de qualidade que os domínios podem configurar e monitorar
• Integração do catálogo de dados: registro automático de novos produtos de dados no catálogo de dados corporativos com extração de metadados
• Controle de acesso: gerenciamento de acesso baseado em políticas que os domínios podem configurar sem envolvimento de TI
• Interfaces de consumo: interfaces de consulta padronizadas (SQL, API) que os consumidores podem usar independentemente do domínio que produziu os dados
• Monitoramento e observabilidade: monitoramento da integridade do pipeline, painéis de atualização de dados e alertas de que as equipes de domínio podem operar

Construir esta plataforma é o principal investimento técnico em malha de dados. Sem ela, a malha de dados descentraliza a responsabilidade sem capacitar a capacidade – uma receita para o caos em vez de capacitação.

Princípio 4: Governança Computacional Federada

Descentralizar a propriedade dos dados não significa abandonar a governação. A malha de dados usa governança federada – padrões definidos centralmente que os domínios aplicam localmente.

A função de governança central define: padrões de qualidade de dados, políticas de segurança e privacidade, padrões de interoperabilidade (formatos de dados comuns, padrões de identificação), requisitos de conformidade regulatória e o esquema do catálogo de dados ao qual todos os produtos de dados devem estar em conformidade.

Os domínios implementam esses padrões em seus produtos de dados. A função de governança verifica a conformidade por meio da aplicação automatizada de políticas, em vez de revisão manual.

Governança “computacional” significa que as políticas de governança são aplicadas automaticamente por meio de código, e não por meio de processos de aprovação manuais. Os controles de acesso são aplicados pela plataforma; os padrões de qualidade dos dados são verificados por testes automatizados; as políticas de segurança são aplicadas pela infraestrutura. Isso torna a governança escalonável — não exige que uma equipe central revise manualmente cada produto de dados.

---

Arquitetura de malha de dados na prática

Design de domínio de dados

Projetar domínios de dados é o primeiro desafio prático. Os limites do domínio devem estar alinhados com os limites do domínio de negócios – unidades organizacionais com responsabilidade clara pelos dados e propriedade do contexto de negócios.

Padrões de design de domínio comuns:

Domínios operacionais: Combine unidades de negócios existentes — Vendas, Marketing, Finanças, Operações, RH, Cadeia de Suprimentos. Cada domínio possui os dados produzidos por seus sistemas operacionais.

Domínio do cliente: os dados agregados do perfil do cliente, geralmente pertencentes a uma equipe dedicada de dados do cliente, são um domínio transversal comum.

Domínios de análise: algumas organizações criam domínios analíticos dedicados que agregam dados de vários domínios operacionais para fins analíticos específicos — um domínio de análise financeira que combina dados de vendas, operações e finanças.

Os limites do domínio devem ser traçados para minimizar as dependências entre domínios — quando uma parte significativa dos dados de um domínio provém de outro domínio, os limites podem precisar ser redesenhados.

Anatomia do produto de dados

Um produto de dados em uma implementação de malha de dados normalmente inclui:

Dados de entrada: dados de origem de sistemas operacionais, consumidos por meio de fluxos de eventos (Kafka), chamadas de API ou replicação de banco de dados.

Código de transformação: a lógica do pipeline que transforma os dados brutos de origem no produto de dados publicado. Normalmente gerenciado como código no controle de versão com implantação de CI/CD.

Interface de saída: a forma na qual os dados são fornecidos aos consumidores — tabelas em uma camada de consulta compartilhada, endpoints de API, fluxos de eventos ou visualizações materializadas.

Contratos de qualidade: Padrões de qualidade definidos e testados — taxas nulas, requisitos de atualização, verificações de integridade referencial, validações de regras de negócios.

Metadados: definições de esquema, dicionários de dados, informações de linhagem e documentação operacional — registrados automaticamente no catálogo de dados.

Observabilidade: monitoramento da integridade do pipeline, painéis de atualização e rastreamento do índice de qualidade.

Escolhas de plataforma técnica

A pilha de implementação da malha de dados varia significativamente de acordo com a organização, plataforma de nuvem e ferramentas existentes:

Catálogo de dados: Atlan, Collibra, Alation, DataHub (código aberto), Google Dataplex, AWS Glue Data Catalog. Fornece a camada de descoberta para produtos de dados.

Qualidade dos dados: Grandes Esperanças (código aberto), Monte Carlo, Soda, Anomalo. Testes automatizados de qualidade de dados e detecção de anomalias.

Orquestração de pipeline: dbt (transformação de dados), Apache Airflow, Prefect, Dagster. Os domínios usam ferramentas de transformação de dados e orquestração de pipeline para construir seus pipelines.

Camada de consulta: Catálogo do Databricks Unity, Snowflake, BigQuery, Amazon Redshift. A camada de consulta analítica compartilhada que os consumidores usam para consultar produtos de dados de vários domínios.

Gerenciamento de acesso: Apache Ranger, AWS Lake Formation, Databricks Unity Catalog. Controle de acesso baseado em políticas entre domínios.

Streaming de eventos: Apache Kafka, AWS Kinesis, Google Pub/Sub. Interfaces de produtos de dados em tempo real para consumidores de streaming.

---

Integração com Analytics e Power BI

As arquiteturas de malha de dados fornecem a base de dados de propriedade do domínio que as equipes de análise consomem. A interface entre a malha de dados e as ferramentas analíticas é crítica.

Malha de dados + Power BI

Em uma arquitetura de malha de dados, o Power BI se conecta a produtos de dados de domínio por meio da camada de consulta compartilhada — normalmente um lakehouse (Databricks, Azure Synapse, Microsoft Fabric) ou um data warehouse (Snowflake, BigQuery, Redshift).

Os produtos de dados de domínio são publicados como tabelas ou visualizações na camada de consulta. Os modelos semânticos (conjuntos de dados) do Power BI são criados com base nesses produtos de dados de domínio. Os consumidores de dados (analistas, usuários empresariais) criam relatórios sobre os modelos semânticos sem precisar entender qual domínio produziu os dados subjacentes.

O OneLake do Microsoft Fabric é particularmente adequado para arquiteturas de malha de dados – ele fornece uma camada de armazenamento unificada onde as equipes de domínio podem publicar seus produtos de dados, com uma camada de consulta compartilhada que o Power BI e outras ferramentas analíticas consomem. Os espaços de trabalho em nível de domínio no Microsoft Fabric alinham-se naturalmente com os limites do domínio da malha de dados.

Linhagem de dados para análise

Um dos recursos mais valiosos em uma malha de dados madura é a linhagem de dados ponta a ponta – rastreando a origem de cada número em um relatório analítico por meio de produtos de dados, transformações e sistemas de origem.

Quando um relatório do Power BI mostra um número de receita inesperado, a linhagem de dados permite um diagnóstico rápido: de qual produto de dados vem a métrica de receita? Qual domínio o possui? Que lógica de transformação o produziu? Qual sistema de origem foi a origem final?

Ferramentas de catálogo de dados com recursos de linhagem (Atlan, Collibra, DataHub) fornecem essa visibilidade de linhagem, tornando a solução de problemas analíticos muito mais rápida e eficaz.

---

Transformação Organizacional

A malha de dados é tanto uma transformação organizacional quanto técnica. A arquitetura técnica pode ser construída de forma relativamente rápida; a transformação organizacional leva muito mais tempo.

Mudanças de função

Engenheiros de dados em equipes centrais: a função muda da construção de pipelines de dados de produção para a construção e manutenção da plataforma de infraestrutura de dados de autoatendimento. Do produtor ao construtor de plataformas. Esta é uma transição de carreira significativa que requer uma gestão cuidadosa.

Engenheiros de dados em equipes de domínio: nova função: engenheiros de dados de domínio integrados em unidades de negócios, criando e mantendo produtos de dados de domínio. Eles precisam de habilidades de engenharia de dados e conhecimento de negócios no domínio.

Analistas de dados: a função se torna mais poderosa: com produtos de dados de domínio detectáveis ​​e de alta qualidade, os analistas gastam menos tempo na aquisição e limpeza de dados e mais tempo na análise. Isto requer o desenvolvimento de competências analíticas mais fortes, juntamente com competências em dados.

Proprietários de produtos de dados: Nova função: membros da equipe de domínio que possuem o roteiro de produtos de dados, gerenciam relacionamentos com consumidores e são responsáveis ​​pelos compromissos de qualidade de dados. Semelhante a uma função de gerente de produto, aplicada aos dados.

Equipe central de governança de dados: A função muda da correção da qualidade dos dados para a definição e aplicação de padrões de governança. De solucionador de problemas a formulador de políticas.

Considerações sobre gerenciamento de mudanças

A propriedade dos dados de domínio é uma responsabilidade que as equipes de domínio nem sempre desejam. "Nós produzimos os dados; por que deveríamos ser responsáveis ​​pela engenharia de dados?" é uma reação comum. A resposta exige demonstrar que a propriedade do domínio dá às equipes controle sobre o próprio destino dos dados — iteração mais rápida, melhor qualidade e dependência reduzida de filas centrais — ao mesmo tempo que fornece ferramentas de autoatendimento que os tornam praticamente gerenciáveis.

O alinhamento da liderança sênior é essencial. A malha de dados exige que os líderes de domínio aceitem a responsabilidade pela qualidade dos dados juntamente com suas responsabilidades operacionais. Sem este compromisso ao nível da liderança, as equipas de domínio resistirão à responsabilidade mesmo que queiram o controlo.

---

Perguntas frequentes

A malha de dados é adequada para pequenas e médias empresas ou apenas para grandes organizações?

A malha de dados é mais benéfica para organizações onde os gargalos da arquitetura central de dados estão causando problemas reais aos negócios — normalmente organizações com mais de 10 domínios significativos de produção de dados, casos de uso de análise substanciais e uma equipe central de dados que não consegue acompanhar a demanda. Para organizações menores com menos fontes de dados e necessidades analíticas mais simples, um data warehouse centralizado e bem estruturado pode ser mais apropriado. A malha de dados acrescenta complexidade organizacional e arquitetônica que só é justificada quando os problemas que ela resolve limitam genuinamente os resultados dos negócios.

Quanto tempo leva uma implementação de malha de dados?

Um cronograma realista de implementação de malha de dados para uma grande empresa: 6 a 12 meses para a construção da plataforma de infraestrutura de dados de autoatendimento, 12 a 18 meses para que os primeiros 3 a 5 produtos de dados de domínio estejam operacionais, 24 a 36 meses para o programa cobrir a maioria dos domínios principais. A organização deve avaliar realisticamente quanto tempo leva a construção de capacidades da equipe de domínio – incorporando engenheiros de dados em equipes de domínio, treinando proprietários de produtos de domínio e mudando a cultura da equipe de domínio em torno da propriedade de dados. A transformação organizacional completa para práticas de malha de dados normalmente leva de 3 a 5 anos, com valor significativo entregue no primeiro ano a partir das implementações iniciais do domínio.

Qual é a diferença entre data lake, data warehouse, data lakehouse e data mesh?

Um data lake é um repositório de armazenamento que armazena dados brutos em seu formato nativo. Um data warehouse é um armazenamento de dados estruturado e integrado, otimizado para consultas analíticas. Um data lakehouse combina a economia de armazenamento de um data lake com o desempenho de consulta e a governança de um data warehouse. A malha de dados é uma abordagem arquitetônica e organizacional, não uma tecnologia de armazenamento — ela descreve como os dados são propriedade, produzidos e governados. A malha de dados pode ser implementada em uma base tecnológica de data lake, warehouse ou lakehouse. A maioria das implementações modernas de malha de dados usa um data lakehouse (Databricks, Microsoft Fabric, Snowflake) como camada de consulta compartilhada.

Como a malha de dados se relaciona com a arquitetura de microsserviços?

A malha de dados aplica princípios arquitetônicos de microsserviços ao gerenciamento de dados — especificamente as ideias de propriedade de domínio, contexto limitado e capacidade de implantação independente. Assim como os microsserviços decompõem uma aplicação monolítica em serviços de propriedade do domínio, a malha de dados decompõe uma plataforma central de dados em produtos de dados de propriedade do domínio. A analogia se estende à estrutura organizacional: assim como os microsserviços pertencem a equipes multifuncionais que incluem desenvolvedores, operações e gerenciamento de produtos, os produtos de dados devem pertencer a equipes de domínio multifuncionais que incluem engenheiros de dados, especialistas de domínio e proprietários de produtos de dados.

Quais são as falhas mais comuns na implementação da malha de dados?

Os padrões de falha mais comuns: construir a plataforma de autoatendimento sem investimento suficiente (os domínios recebem responsabilidade sem ferramentas, criando o caos); não conseguir obter a adesão da liderança do domínio antes de prosseguir (as equipes do domínio resistem à propriedade sem o comprometimento organizacional da liderança); tratar a malha de dados como uma iniciativa puramente tecnológica (negligenciando a gestão da mudança organizacional que torna sustentável a propriedade do domínio); e tentar implementar a malha de dados em todos os domínios simultaneamente (a complexidade da mudança simultânea em toda a organização normalmente resulta em implementações fracassadas – começando com 2 a 3 domínios de grande dificuldade e provando o modelo antes que o dimensionamento seja consistentemente mais bem-sucedido).

---

Próximas etapas

A malha de dados representa um repensar fundamental da arquitetura de dados corporativos que aborda as limitações de escala, qualidade e agilidade dos modelos centralizados. Para organizações que enfrentam gargalos de dados, ele oferece um caminho para a propriedade de dados escalonável e apropriada ao domínio.

Os Power BI e serviços analíticos da ECOSIRE ajudam as organizações a projetar e implementar a camada analítica que fica no topo das arquiteturas de malha de dados – conectando produtos de dados de domínio a ferramentas de business intelligence que fornecem insights aos tomadores de decisão. Nossa equipe pode aconselhar tanto sobre a estratégia de arquitetura de dados quanto sobre a implementação de análises que fazem com que o investimento em malha de dados se traduza em valor comercial.

Entre em contato com nossa equipe de análise e arquitetura de dados para discutir se a malha de dados é a abordagem certa para os desafios de dados da sua organização.