Data Product

O modelo padrão de dados em organizações é centralizado: um time de dados recebe requisições de múltiplas áreas de negócio, processa os dados, entrega análises ou datasets. O gargalo é estrutural. Quanto mais a empresa cresce, mais a demanda por dados supera a capacidade do time central. A solução convencional — contratar mais engenheiros de dados — posterga o problema sem resolvê-lo, porque o modelo centralizado escala linearmente enquanto a demanda de dados cresce exponencialmente com a organização.

Data Product é um dataset, API, modelo ou conjunto de dados gerenciado como produto — com interface definida, contratos de qualidade, SLAs de atualização, documentação, versionamento e proprietário responsável pelo ciclo de vida. A diferença fundamental entre dados como subproduto e dados como produto: um dataset produzido para uma análise pontual existe enquanto a análise existir; um data product é projetado para ser consumido de forma confiável por múltiplos consumidores ao longo do tempo, com a mesma disciplina que um produto de software.

O conceito ganhou tração com o paradigma de Data Mesh, onde domínios de negócio publicam data products para consumo por outros domínios. Mas data product pode ser implementado independentemente de Data Mesh — é uma mudança de postura sobre como dados são criados e mantidos, aplicável em qualquer arquitetura.

Não todo dataset é um data product. Um data product tem atributos específicos que o tornam confiável para consumo externo.

Descoberto: consumidores precisam encontrar o data product. Exige catálogo de dados onde o produto está listado, com descrição, proprietário, schema e casos de uso documentados. Um data product invisível não existe para quem poderia usá-lo.

Endereçável: o data product tem um endpoint estável — um caminho, uma tabela, uma API — que não muda quando a implementação interna muda. Consumidores apontam para o endpoint; como os dados são produzidos é detalhe de implementação do time produtor.

Autodescrição: o data product carrega seus próprios metadados — schema, definições de campos, período coberto, granularidade, limitações conhecidas, exemplos de uso. Um consumidor deve conseguir entender o que o produto contém sem precisar perguntar ao produtor.

Confiável e com SLA: o data product tem SLAs documentados de atualização (atualizado diariamente até 6h, por exemplo), disponibilidade e qualidade. O produtor é responsável por cumprir e alertar quando SLA for violado. Sem SLA, o consumidor não sabe quando pode depender dos dados.

Interoperável: o data product usa formatos e padrões que permitem integração com outros produtos — formatos abertos (parquet, avro), convenções de nomenclatura padronizadas, tipos de dados consistentes. Dados proprietários em formatos fechados criam dependência de ferramentas específicas.

Com controle de acesso: o data product define quem pode acessar quais dados, com granularidade. Não é "aberto para todos" nem "fechado exceto para pedido manual ao DBA". O controle é gerenciado pelo data product como parte do produto.

Dataset analítico: o tipo mais comum. Uma tabela ou conjunto de tabelas que encapsula um domínio de dados — orders_fact, customer_360, product_catalog. Consumidores fazem queries diretamente. Exemplo: o domínio de Pedidos publica um data product com todas as transações enriquecidas com status, cliente, produto e canal.

API de dados: um endpoint REST ou GraphQL que retorna dados sob demanda. Útil para dados que mudam frequentemente ou quando o consumidor precisa de um subconjunto específico por request. Exemplo: API que retorna o perfil atualizado de um cliente dado o ID.

Modelo de ML empacotado: um modelo treinado exposto como endpoint de inferência — o consumidor envia inputs, recebe previsões. O modelo é o data product; o time de ML é responsável por manter a acurácia e versionar o modelo.

Dashboard / relatório gerenciado: um painel ou relatório produzido por um domínio e consumido por outros. Menos flexível que datasets, mas adequado para consumidores que precisam de visualização pronta, não de acesso aos dados brutos.

Evento: um stream de eventos (Kafka, Kinesis) que consumidores podem assinar. O domínio de Pedidos publica eventos order_placed, order_shipped, order_cancelled que outros domínios consomem para reagir em tempo real.

No Data Mesh, cada domínio de negócio é responsável por seus próprios data products. O domínio de Marketing produz e mantém os data products de aquisição e campanha. O domínio de Vendas produz os data products de oportunidades e receita. Um time central de plataforma fornece a infraestrutura (object storage, catálogo, ferramentas de qualidade) mas não produz os dados de domínio.

Essa distribuição de responsabilidade resolve o gargalo do modelo centralizado: cada domínio gerencia seus dados com autonomia, usando a plataforma central. A governança é federada — há padrões globais (formatos, SLAs mínimos, classificação de dados), mas a implementação é do domínio.

O trade-off: cada domínio precisa de capacidade de engenharia de dados. O modelo funciona em organizações com times de domínio suficientemente maduros. Em organizações pequenas com um time de dados central, a separação em data products pode ser feita sem descentralizar completamente a produção — o time de dados central produz produtos distintos para cada domínio, com interfaces claras.

A distinção é de postura, não de tecnologia:

Tabela: uma estrutura de dados num banco. Não tem proprietário claro, documentação, SLA, ou garantia de estabilidade. Existe para uma finalidade técnica específica.

Dataset: uma coleção de dados para uma análise ou finalidade. Pode ser bem ou mal documentado. Geralmente ad hoc, sem compromisso com manutenção futura.

Data product: um ativo gerenciado. Tem proprietário, interface estável, documentação completa, SLA, versionamento, monitoramento. É construído para ser consumido por outros, não apenas para uso interno imediato. A decisão de criar um data product implica um compromisso com manutenção.

O custo de criar um data product é maior que criar uma tabela. Esse custo é justificado quando múltiplos consumidores vão depender dos dados ao longo do tempo.

Freshness: os dados estão dentro do SLA de atualização? Monitorar o timestamp da última atualização e alertar quando ultrapassar o threshold.

Completude: o volume de registros esperado chegou? Se normalmente chegam 10.000 pedidos por dia e hoje chegaram 500, o data product tem problema.

Unicidade e validade: registros duplicados, valores fora de range, nulos em campos obrigatórios. Monitorados por testes automáticos (dbt tests, Great Expectations) executados após cada atualização.

Uso: quantos consumidores estão usando o data product? Quais queries são mais frequentes? Dados de uso informam priorização de manutenção e identificam data products que ninguém usa — candidatos a deprecação.

SLA compliance: qual percentual das atualizações foi entregue dentro do SLA? Histórico de conformidade mostra a confiabilidade do produto ao longo do tempo.

Data product não é um conceito técnico — é uma mudança de accountability. A diferença entre "jogamos os dados num schema e avisamos o time de BI" e "somos responsáveis por esses dados chegarem com qualidade, no prazo e documentados" é a diferença entre dados como subproduto e dados como produto. Essa mudança de postura tem mais impacto na confiabilidade dos dados do que qualquer ferramenta.

Para PMEs com times pequenos de dados, implementar data products não significa adotar Data Mesh completo. Significa aplicar a disciplina de produto aos datasets mais críticos — os que mais analistas dependem, os que alimentam decisões mais importantes. Começar com dois ou três datasets tratados como produtos reais (com documentação, SLA, monitoramento e proprietário identificado) entrega mais valor do que tentar cobrir todo o catálogo de dados simultaneamente.

A pergunta certa não é "quantos data products temos?" — é "nossos consumidores internos de dados conseguem depender do que publicamos, sem precisar perguntar ao time de dados se o dado está correto?" Quando a resposta for sim, os dados estão sendo tratados como produto.