Data Mesh: infraestrutura e planos

Especificação do Data Product - Apresentação

Boas-vindas ao curso de Data Mesh: infraestrutura e planos! Meu nome é João Miranda e serei seus instrutor nessa jornada.

João é um homem branco de olhos e cabelos castanhos escuros, e barba rente ao rosto. Seus cabelos são de comprimento médio, presos em um rabo de cavalo, com as laterais raspadas. Veste uma camiseta cinza com a logo da Alura. Ao fundo, há uma parede com iluminação esverdeada, parte de uma estante de livros e um objeto escrito "MBA USP ESALQ".

Neste curso de arquitetura de data mesh, focaremos nas especificações dos datas products. Para melhor aproveitá-lo, é interessante que você tenha passado pelos cursos de Data Mesh: uma abordagem distribuída para dados e Data Mesh: dados como produtos.

Sabemos que os datas products possuem diversos recursos por causa da plataforma de data mesh, então conseguimos entender como esses recursos se conectam uns aos outros, o que nos permite, agora, desmembrar esta plataforma e vê-la em diferentes planos, além de nomear as seções visando um melhor entendimento dos times que trabalham em cada parte da plataforma.

Falaremos sobre as especificações do data product, política, divisão em planos do data mesh e os papéis dos times. Vamos lá?

Especificação do Data Product - Limpeza

Ao longo desse curso, utilizaremos diversos exemplos, o primeiro deles será sobre uma operadora de plano de saúde.

Imagine que temos um sistema transacional com informações pessoais dos clientes do plano de saúde, como data de nascimento, endereço, número de telefone, senhas, etc. De acordo com esses dados, precisamos criar um relatório analítico de BI, utilizando a data de nascimento para estimar a idade, por exemplo.

Para isso, vamos nos ater a alguns questionamentos:

• Como podemos ter certeza que encontraremos a data de nascimento de todos os clientes?
• Esta informação foi preenchida? Se sim, está correta?
• Como podemos fazer a limpeza dos dados faltantes, nulos ou inconsistentes?

A limpeza de dados é muito comum e ocorre com frequência em projetos de ciência de dados, então faz sentido que, antes do dado chegar ao output, passe pelo processo de limpeza. Mas o data product que retorna o dado como output é capaz de realizar a limpeza durante o processo?

Na teoria do data mesh, os datas products, alinhados às fontes de dados, devem realizar os serviços para satisfazer os clientes. Mas esses clientes, por sua vez, também são espécies de datas products, portanto, o produto que gera os dados deve saber sobre as necessidades do data product que utiliza esses dados.

A limpeza deve ser feita o mais cedo possível para que os dados cheguem de maneira padronizada e apropriada, e sejam de qualidade. Dessa forma, o responsável pela qualidade dos dados é o time que desenvolveu o data product. Tendo isso em vista, podemos nos questionar sobre a melhor forma de limpá-los.

A qualidade e forma de preencher ou disponibilizar os dados deve variar de acordo com o cenário. Para ter certeza de como devem ser disponibilizados, é possível utilizar as especificações do data product, que podem requerer, por exemplo, que os campos nulos sejam tratados de forma específica nas output ports (portas de saída).

Essas determinações, por sua vez, podem ser construídas através das especificações de portas de entrada dos outros data products, que também devem conter o tipo e formato de dados necessários, o que as tornam muito importantes. Além do mais, elas contêm desde política de alto nível até especificações de baixo nível para as portas de entrada e saída de dados. É possível, ainda, utilizar múltiplos arquivos para organizá-las, elas influenciam no processo como um todo, além do relacionamento entre os data products.

A seguir, veremos alguns exemplos de limpezas de dados aplicados à plataforma de data mesh.

Especificação do Data Product - Fuso horário

Ainda sobre o processo de limpeza na arquitetura de data mesh, vamos retomar o exemplo da operadora de plano de saúde.

Vamos imaginar que ela adquiriu uma empresa que presta o mesmo tipo de serviço, possuindo, agora, dois sistemas de cobrança, e nós precisamos de um relatório que agregue as informações de ambos. Esses sistemas são alinhados às fontes de dados, o que permite a disponibilidade dos dados o mais cedo possível.

O problema é que o sistema de cobrança original não tem informação de timezone (fuso horário), mas o novo, sim. Neste caso, em que não há uma padronização dos dados em sistemas diferentes, devemos aplicar um tratamento. Vamos a um exemplo.

Poderíamos adicionar um fuso horário fixo na porta de saída do data product. Nos casos em que a região ou país possui um único fuso horário, esta solução não gera nenhum problema. No entanto, quando há diferentes fusos, a situação fica mais complexa, pois além das diversas timezones, teríamos que saber se os dados foram armazenados no horário do servidor ou do cliente. Temos soluções para alguns desses empecilhos, mas, na maioria dos casos, podemos criar uma regra para definir o fuso horário de acordo com outra informação presente no dado.

Outro possível cenário diz respeito a uma empresa que possui dois sistemas de vendas de livros que contêm dados referentes ao ISBN - um código único para cada livro. Um desses sistemas vende livros novos, e outro, usados.

Neste caso, também precisamos de um relatório que deve agregar as informações acerca das vendas. Nos sistemas, há livros repetidos e em diferentes formatos, como edições distintas, por exemplo, e o tratamento de agrupá-los como diferentes ou iguais dependerá de como esses dados serão utilizados posteriormente. Dessa forma, poderíamos levar em consideração, nas agregações, as diferentes edições ou formatos de um mesmo livro.

Este processo de agregação de dados de diferentes sistemas e de análise dos itens como iguais ou diferentes, pode receber o auxílio da plataforma com as especificações da porta de entrada do data product.

Esses são alguns exemplos que ilustram como esse processo de limpeza e tratamento de dados pode receber auxílio da implementação de recursos na especificação do data product.

Sobre o curso Data Mesh: infraestrutura e planos

O curso Data Mesh: infraestrutura e planos possui 36 minutos de vídeos, em um total de 23 atividades. Gostou? Conheça nossos outros cursos de Data Science em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Especificação do Data Product
• Política
• Planos do Data Mesh
• Time