Master Data Management (MDM) é a disciplina que garante uma versão única e confiável das entidades centrais do negócio: cliente, produto, fornecedor, colaborador. O entregável concreto é o golden record, o registro mestre que consolida as versões divergentes espalhadas por ERP, CRM e sistemas operacionais. A Databricks não vende um produto chamado MDM, e isso muda a decisão de arquitetura: no Lakehouse, MDM é uma capacidade que se constrói com os blocos oficiais da plataforma (arquitetura medalhão, expectations de qualidade nos pipelines, MERGE transacional do Delta Lake e governança do Unity Catalog) ou que se adquire via apps de parceiros nativos disponíveis no marketplace. A escolha entre construir, usar app nativo ou contratar uma plataforma MDM dedicada externa é uma decisão de perfil, não de moda, e este guia compara os três caminhos.

O problema que todo relatório consolidado denuncia

O sintoma aparece primeiro no BI. O relatório de receita por cliente mostra “João Silva ME”, “Joao Silva ME” e “J. Silva Comércio” como três clientes. O ERP tem um código de produto, o e-commerce tem outro, e o relatório de margem por SKU não fecha. O time de compras negocia com um fornecedor que aparece duplicado com CNPJs de filiais diferentes, e ninguém sabe o volume total contratado. Cada sistema está certo dentro de si. A empresa, como um todo, não sabe responder quantos clientes tem.

Depois o sintoma migra para a IA, e piora. Um agente que consulta a base responde sobre o João Silva errado. Um modelo de churn treina sobre clientes duplicados e aprende padrão que não existe. Uma análise de customer 360 promete visão única e entrega visão tripla. Dado mestre fragmentado não é problema cosmético de cadastro: é a rachadura na fundação sobre a qual BI e IA são construídos.

A tese deste guia: dado mestre não é o dado que você tem, é o acordo sobre qual versão vale. Por isso MDM nunca é só projeto técnico: as regras de sobrevivência (qual fonte ganha quando os cadastros divergem, qual endereço prevalece, qual CNPJ é o canônico) são decisões de negócio disfarçadas de configuração. A plataforma executa o acordo; a consultoria ajuda a empresa a fazê-lo. Quem compra ferramenta antes de fazer o acordo automatiza a divergência.

O que é golden record (e por que ele é a tabela ouro definitiva)

Golden record é o registro único, validado e governado de uma entidade mestre, consolidado a partir das versões existentes nos sistemas de origem. Na arquitetura medalhão que a Databricks documenta como padrão do Lakehouse, ele é o caso extremo da camada ouro: se a prata padroniza e deduplica dentro de cada fonte, o golden record resolve identidade entre fontes. “João Silva ME” do ERP, “Joao Silva” do CRM e “J. Silva Comércio” do e-commerce viram um único cliente, com um identificador mestre, atributos escolhidos pelas regras de sobrevivência e linhagem de onde cada campo veio.

Os blocos oficiais do Databricks para construir MDM

Não existir um produto “MDM” no catálogo da Databricks não significa que a capacidade não exista. Os blocos estão documentados, e o trabalho de arquitetura é combiná-los:

Entity resolution: o coração técnico (e a decisão de negócio escondida nele)

Resolver identidade entre fontes é o núcleo do MDM, e tem três abordagens que se combinam:

•     Determinística: chaves exatas batem (mesmo CNPJ, mesmo e-mail). Simples, auditável, resolve a parte fácil do problema.

•     Probabilística (fuzzy): similaridade de nome, endereço e telefone com nota de confiança. Resolve variações de grafia e cadastros incompletos, e exige limiar de decisão: acima de quanto por cento de similaridade dois registros são a mesma entidade?

•     Assistida por ML/IA: modelos treinados para reconhecer duplicidade em escala, úteis quando o volume torna a revisão manual inviável. O Lakehouse é o ambiente natural para treinar e servir esses modelos sobre o próprio dado.

A decisão de negócio escondida: o limiar e as regras de sobrevivência. Se dois cadastros têm 92% de similaridade, funde ou não funde? Quando funde, qual endereço sobrevive: o mais recente, o do sistema fiscal, o confirmado pelo cliente?

Errar para o lado da fusão agressiva junta clientes diferentes num só (e o erro contamina tudo a jusante). Errar para o lado conservador mantém duplicidades (e o relatório segue não fechando). Não existe resposta técnica universal: existe o acordo que a empresa precisa assumir, com dono e critério de revisão.

Construir, app nativo ou plataforma dedicada: o comparativo consultivo

Três caminhos levam a golden records sobre o Databricks, e cada um tem perfil ideal e limitação honesta:

O critério de desempate costuma ser o mesmo do resto do cluster: a frequência de mudança das regras e a maturidade do time. Regra estável e time enxuto favorecem app; regra volátil e engenharia forte favorecem construir; processo de stewardship corporativo já maduro em suite dedicada pode justificar mantê-la, com a ressalva do custo de governança dupla.

Por que MDM virou pré-requisito de IA (e não projeto de cadastro)

Durante anos, MDM foi tratado como projeto de qualidade de cadastro, importante mas adiável. A IA mudou o cálculo. Um agente que responde sobre clientes precisa de uma versão de cada cliente. Um modelo preditivo treinado sobre entidades duplicadas aprende ruído. Uma análise 360 sobre dado fragmentado entrega visão múltipla com aparência de única, que é o pior dos cenários: erro com autoridade.

A conexão com o resto da arquitetura: o golden record governado pelo Unity Catalog é o que o modelo semântico do Power BI consome para o relatório fechar, o que o pipeline de curadoria entrega como ouro definitivo, e o que agentes e modelos usam como fonte de identidade. MDM não é mais um silo paralelo de cadastro: no Lakehouse, é a camada de identidade do mesmo pipeline que serve BI e IA. É por isso que a consultoria que desenha o MDM precisa entender o pipeline inteiro, não só a ferramenta de matching.

Quando MDM completo é exagero

•     Fonte única dominante. Se um sistema é a origem inquestionável do cadastro (e os demais só o consomem), o problema é integração, não MDM. Golden record de fonte única é a própria fonte.

•     Volume pequeno e estável. Algumas centenas de clientes com baixa rotatividade se resolvem com rotina de revisão e regras simples de deduplicação. MDM estruturado se paga quando volume e velocidade tornam a revisão manual inviável.

•     Antes do acordo de negócio. Se as áreas ainda não concordam sobre qual fonte vale para cada atributo, nenhuma ferramenta resolve. A primeira entrega de um projeto de MDM é o acordo de sobrevivência assinado, não o pipeline rodando.

Perguntas frequentes

O Databricks tem um produto de MDM?

Não como produto de catálogo. A capacidade de MDM no Databricks se constrói com os blocos oficiais da plataforma (arquitetura medalhão, expectations de qualidade nos pipelines, MERGE do Delta Lake, Unity Catalog) ou se adquire via apps de parceiros nativos disponíveis no marketplace, que entregam o golden record como tabela Delta dentro do próprio Lakehouse.

O que é um golden record?

É o registro único, validado e governado de uma entidade mestre (cliente, produto, fornecedor), consolidado a partir das versões divergentes dos sistemas de origem por regras de resolução de identidade e de sobrevivência de atributos. Na arquitetura medalhão, é o caso definitivo da camada ouro: a versão que vale para BI, operação e IA.

MDM no Lakehouse substitui uma suite MDM tradicional?

Depende do perfil. Para empresas cujo centro de gravidade de dados já é o Databricks, construir ou usar app nativo evita mover dado entre plataformas e duplicar governança. Suites dedicadas seguem fazendo sentido quando há processo maduro de stewardship multidomínio que a empresa não quer refazer. O comparativo é de perfil e custo total, não de qual abordagem é moderna.

Por onde começar um projeto de MDM?

Pelo domínio com dor mais cara e escopo mais claro, tipicamente cliente ou produto, e pelo acordo de negócio antes do pipeline: qual fonte vale para cada atributo, qual o limiar de fusão, quem é o dono da regra. Com o acordo assinado, a construção técnica no Lakehouse segue o percurso medalhão com regras de qualidade nos pipelines.

Próximo passo

Se o seu relatório consolidado não fecha, se o mesmo cliente aparece três vezes, ou se a iniciativa de IA esbarra em identidade duplicada, o problema tem nome e tem método. Solicite um diagnóstico de dados mestres com a CSP Tech e receba o mapa do seu caso: quais domínios doem mais, qual dos três caminhos cabe no seu perfil, e qual acordo de negócio precisa existir antes de qualquer pipeline.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. Revisão técnica por especialistas de dados da CSP Tech (parceira Databricks, Microsoft Gold Partner, Atlassian Gold Partner, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).

Fontes (oficiais, acesso jul/2026): Databricks Documentation, “What is the medallion lakehouse architecture?” (docs.databricks.com/lakehouse/medallion); Databricks Documentation, expectations de qualidade em pipelines Lakeflow/Delta Live Tables e MERGE/upsert no Delta Lake (docs.databricks.com); Databricks Documentation, Unity Catalog (docs.databricks.com/data-governance/unity-catalog); Databricks Marketplace (marketplace.databricks.com); LakeFusion, MDM nativo em Databricks, citado como exemplo de app parceiro com listing público (lakefusion.ai; AWS Marketplace; blog de parceiro na comunidade oficial Databricks, mar/2025).