Fundamentos da Qualidade de Dados: os componentes de um sistema confiável

Nota: Este é o primeiro post de uma série de estudos sobre o livro Fundamentos da Qualidade de Dados (O’Reilly), de Barr Moses, Lior Gavish e Molly Vorwerck. Aqui trago um resumo do Capítulo 2, com os conceitos que considero mais importantes para quem trabalha com dados.

Iniciando o primeiro post

Este é o primeiro post do blog, e nada melhor do que começar por um tema que está no centro de qualquer trabalho com dados: a confiabilidade. De nada adianta construir pipelines sofisticados, dashboards bonitos ou modelos avançados se os dados que os alimentam não são confiáveis.

Ao longo dos meus 5 anos de experiência na área de dados, atuando entre engenharia, análise e ciência de dados, aprendi na prática que a confiabilidade não é um detalhe — é a base de tudo. Já vi projetos inteiros perderem valor por causa de dados errados, duplicados ou fora do prazo. Foi essa vivência que me levou a estudar a fundo o tema e a querer compartilhar o que aprendi.

Foi pensando nisso que escolhi o livro Fundamentos da Qualidade de Dados como ponto de partida. No Capítulo 2, os autores apresentam os componentes essenciais de um sistema de dados confiável e explicam duas distinções fundamentais que todo profissional de dados precisa dominar: a diferença entre dados operacionais e analíticos, e a diferença entre data warehouses e data lakes.

Ao longo deste post, vou destrinchar esses conceitos de forma simples e direta, para que você possa aplicar essas ideias no seu dia a dia — seja você engenheiro, analista ou cientista de dados.

Reunindo os componentes essenciais de um sistema confiável de dados

Quando falamos em qualidade de dados, é comum pensar apenas em “consertar” problemas depois que eles aparecem. Mas a verdade é que boa parte do chamado data downtime (os períodos em que os dados estão ausentes, imprecisos ou errados) pode ser evitada com os sistemas e processos certos desde o início.

Assim como um software, os dados passam por várias etapas ao longo de um pipeline — e cada uma delas pode ser influenciada por fatores operacionais, de código ou até mesmo pelos próprios dados. Uma simples mudança de esquema ou um push de código pode gerar um relatório confuso lá na frente.

Para construir pipelines mais confiáveis, a solução costuma se apoiar em três componentes principais:

• Processo: as práticas e fluxos que definem como os dados são tratados.
• Tecnologias: as ferramentas e a infraestrutura que sustentam o pipeline.
• Pessoas: as equipes e responsabilidades envolvidas em cada etapa.

Neste capítulo, o foco está no componente tecnológico: mapear as partes do pipeline de dados e entender o que é necessário para medir, corrigir e prevenir o tempo de inatividade de dados em cada etapa.

Os sistemas de dados são naturalmente complexos — são muitas etapas contribuindo para o que pode parecer um caos generalizado. E, à medida que as empresas investem cada vez mais em dados e analytics, cresce também a pressão para escalar, fazendo com que a qualidade seja considerada antes mesmo de os dados entrarem no pipeline.

É aqui que entram os componentes essenciais impulsionados por metadados — desde catálogos de dados até data warehouses e data lakes. São eles que ajudam a garantir que a infraestrutura esteja preparada para manter alta qualidade de dados em cada etapa do caminho.

Entendendo a diferença entre dados operacionais e dados analíticos

Uma das distinções mais importantes em qualquer arquitetura de dados é a que separa os dados operacionais dos dados analíticos. Embora ambos sejam “dados”, eles nascem com propósitos, ritmos e públicos bem diferentes.

Em resumo, dá para dizer que:

• Os dados operacionais registram o que acontece nos processos reais de um negócio — são o reflexo das operações do dia a dia.
• Os dados analíticos são usados para análises mais robustas e eficientes, apoiando decisões e o entendimento do negócio como um todo.

Uma forma interessante de enxergar essa diferença é pensar no papel de cada um:

• Os dados operacionais operacionalizam o negócio: eles fazem o negócio funcionar no dia a dia.
• Os dados analíticos gerenciam o negócio: eles ajudam a entender, medir e decidir sobre o negócio.

O que diferencia esses dados?

A imagem abaixo, retirada do livro, resume bem as principais diferenças entre os dois mundos:

O que separa os dados operacionais dos analíticos vai muito além do nome. São diferenças de propósito, forma e uso:

• Quem usa: os dados operacionais são consumidos principalmente por sistemas e pessoas que executam o dia a dia do negócio. Já os dados analíticos são voltados para quem precisa entender o negócio — analistas, cientistas de dados e tomadores de decisão.
• Como são estruturados: os dados operacionais costumam ser organizados para atender a uma operação específica (uma venda, um pedido, um cadastro), muitas vezes em formato normalizado. Os dados analíticos são modelados para facilitar consultas e agregações, geralmente em formatos desnormalizados ou em colunas.
• Ritmo de atualização: dados operacionais são atualizados constantemente, em tempo real ou quase, conforme as operações acontecem. Dados analíticos costumam ser carregados em lotes (batches) ou em janelas de tempo, refletindo um estado consolidado.
• Volume e histórico: enquanto o operacional lida com o estado atual e recente, o analítico acumula histórico — é isso que permite comparar períodos, identificar tendências e responder perguntas mais amplas.

Em uma frase: os dados operacionais respondem “o que está acontecendo agora?”, enquanto os dados analíticos respondem “o que aconteceu e o que isso significa?”.

Data Warehouses versus Data Lakes

Quando o assunto é armazenar e organizar dados para análise, dois nomes aparecem o tempo todo: data warehouse e data lake. Embora ambos sirvam de “casa” para os dados analíticos, eles nasceram com filosofias bem diferentes.

Data Warehouse: ordem e consistência

O data warehouse é o ambiente mais tradicional. Ele recebe dados já processados, limpos e modelados, organizados em estruturas bem definidas (geralmente esquemas em estrela ou floco, com tabelas de fatos e dimensões).

Suas principais características:

• Dados estruturados e curados: antes de entrar, os dados passam por transformações e validações. O que chega ao warehouse é confiável e pronto para consulta.
• Modelagem rígida: o esquema é definido com antecedência (schema-on-write), o que garante consistência, mas exige planejamento.
• Performance para BI: é otimizado para consultas rápidas, agregações e dashboards. Ferramentas de BI se conectam facilmente.
• Custo maior: por ser curado e otimizado, costuma ser mais caro para armazenar e processar.

Data Lake: flexibilidade e volume

O data lake surgiu para lidar com a explosão de dados e a necessidade de guardar tudo — estruturado ou não — sem se preocupar tanto com a modelagem na entrada.

Suas principais características:

• Dados brutos e variados: aceita dados estruturados, semiestruturados (JSON, Parquet) e não estruturados (texto, imagens, logs), no formato original.
• Modelagem flexível: o esquema é definido na leitura (schema-on-read), ou seja, você decide como interpretar os dados quando for usá-los.
• Baixo custo de armazenamento: por guardar dados brutos em formatos baratos, é mais econômico para grandes volumes.
• Mais trabalho para usar: como os dados não são curados na entrada, exige mais esforço de engenharia para transformá-los em algo útil e confiável.

A escolha não precisa ser “ou um, ou outro”

Na prática, as arquiteturas modernas costumam combinar os dois. Uma abordagem comum é o lakehouse, que une a flexibilidade e o baixo custo do data lake com a confiabilidade e o desempenho do data warehouse.

A ideia central é: o data lake guarda os dados brutos como fonte da verdade, e o data warehouse (ou camadas curadas do lakehouse) entrega versões limpas e modeladas para análise. Assim, você tem a flexibilidade de explorar dados novos e, ao mesmo tempo, a consistência necessária para relatórios e decisões confiáveis.

Em resumo: o warehouse prioriza ordem e confiabilidade para responder perguntas conhecidas; o data lake prioriza flexibilidade e volume para explorar o desconhecido. Entender essa diferença é essencial para desenhar um sistema de dados que realmente atenda às necessidades do negócio.

Quer se aprofundar?

Este post é um resumo do Capítulo 2 do livro Fundamentos da Qualidade de Dados, de Barr Moses, Lior Gavish e Molly Vorwerck (Editora Alta Books). Se você quer entender na prática como construir pipelines de dados confiáveis e evitar o famoso data downtime, vale muito a pena ler o livro completo.

Fundamentos da Qualidade de Dados

Guia prático para criar pipelines de dados confiáveis — Barr Moses, Lior Gavish e Molly Vorwerck.

Comprar na Alta Books →