Data Mesh: gerenciando controle e dependências

Testando o Data Product - Apresentação

Bem-vindos ao curso de Data Mesh: controle e dependências! Meu nome é João Vitor e serei seu instrutor nessa jornada.

João é um homem branco de olhos e cabelos castanhos escuros. Usa barba e bigode curtos, e os 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, veremos alguns problemas que podem surgir ao desenvolver data products, além da plataforma de data mesh. Nossos data products terão dependências de outros data products, o que nos leva a alguns questionamentos:

• o que acontece se essas dependências ainda não tiverem sido desenvolvidas?
• e se as fontes de dados ainda não foram integradas na plataforma de data mesh?
• como podemos testar os data products e criar testes automatizados para eles?

Veremos algumas abordagens tradicionais para realizar essas atividades na arquitetura do data mesh, além de focar no controle e entendimento do comportamento dos data products através do estudo de métricas. Vamos lá?

Testando o Data Product - Dependências

Vamos utilizar um exemplo para entender o conceito de dependências de um data product.

Imaginemos uma empresa que oferece serviço de assinatura, como Netflix, Spotify ou a própria Alura, por exemplo. O nosso data product será uma ferramenta que determina o score (pontuação) do cliente, analisando se o assinante deixará de assinar o serviço agora ou futuramente. Esse data product coleta informações de diversas fontes de dados, ou seja, tem dependência de outras fontes de dados.

O primeiro sistema que tem como dependência o score do cliente é o player, por exemplo, se estivermos falando de uma empresa como a Spotify. O usuário escuta músicas e o player coleta diversas informações no momento em que a música é reproduzida.

Outro exemplo de dependência seria o navegador de catálogo, em caso de empresas como a Netflix, por exemplo. Através deste navegador de catálogo podemos coletar informações como o tempo que o usuário fica em determinada página, quais filmes se interessou e clicou, quais páginas navegou, entre outros.

A API de reviews (opiniões) é outra fonte de dados que podemos ter para o nosso data products. Ela coleta as informações acerca do ponto de vista das pessoas que assistiram ao filme, como notas e comentários, por exemplo. Por fim, outra dependência é o sistema de pagamentos, que possui informações como período de pagamento (mensalmente, anualmente etc), se deixou de pagar, entre outros.

Após a coleta, o score do cliente é entregue para uma API que deve utilizar as informações no momento final. Na plataforma de data mesh, como os times e data products são independentes, pode acontecer de uma das dependências não estar completa. Neste caso, como seria possível testar o data product se o sistema de pagamentos, por exemplo, ainda não estiver concluído?

Supondo que não seja conveniente aguardar a conclusão do sistema de pagamentos para testar o data product, temos a opção de construir um protótipo, um sistema falso ou uma falsa dependência, que agirá como se fosse o sistema de pagamentos (embora não o seja propriamente), permitindo a testagem do data product. A seguir, veremos algumas abordagens para a construção desse protótipo.

Testando o Data Product - Stubs

Tivemos a ideia de criar uma falsa dependência que simula o sistema de pagamentos. Dessa forma, quando o data product do score do cliente solicitar ao sistema de pagamento as informações acerca do cliente de id número 15, por exemplo, deve ser retornado quais pagamentos foram feitos ao longo do último ano.

Uma das possibilidades de simular esse comportamento é criar um teste para que, toda vez que o data product invoque o sistema de pagamento, seja retornada a informação necessária. Se esta informação for retornada através de uma API, podemos utilizar Mountebank, uma biblioteca que permite simular as requisições e as respostas do sistema. Sendo assim, o sistema falso é quem deve retornar a informação desejada, por isso precisamos ensiná-lo sobre o tipo de dado e a programação a ser executada. A isso, damos o nome de stubs.

Segundo a seção de stubs, do site da Mountebanck, eles definem-se como uma categoria de dublês de teste, onde substituímos um objeto de produção para fins de teste. Ainda segundo esta definição, os stubs são objetos que fornecem respostam prontas em uma requisição. Portanto, quando o invocamos durante o teste, não retornam nada além do que estão programados para executar.

Vamos nos ater ao exemplo da documentação. Note que sempre que é utilizado o método POST e o caminho /customers/123, retorna-se nas respostas uma localização Location e, no corpo (body), o e-mail do cliente. Se fizermos novamente esta solicitação, deve ser retornado um statusCode de 400 e, no body (corpo), a informação de que o e-mail já existe. Caso seja feita uma requisição diferente das mostradas, retorna-se o statusCode de 404, ou seja, um erro.

No caso exemplificado, solicita-se o e-mail de um cliente e, se houver uma requisição determinada, o stub sempre deve retornar a mesma resposta.

Já sabemos que o stub pode ser uma solução ao construir uma resposta para auxiliar no teste do data product. No entanto, temos um problema: como essa verificação é feita pela própria equipe do data product, e não pela equipe do verdadeiro sistema de pagamento, o teste criado com o stub não conseguirá capturar os exemplos na base de dados, podendo gerar um erro, já que o código stub é diferente do que o real sistema de pagamento gera.

Neste caso, a plataforma de self service pode nos ajudar se a configurarmos para conhecer as portas de entrada das dependências, contendo metadados que informam para a plataforma de data mesh quais os outputs (resultado) da plataforma de pagamentos e como deve ocorrer a comunicação.

Se existem argumentos que devem ser passados para o sistema de pagamentos, o data product de score do cliente deve saber quais são graças à plataforma de self service. Dessa forma, a plataforma de self service ajuda a realizar os testes de data product de maneira apropriada, já que viabiliza a criação de stubs de acordo com as configurações que estarão no sistema final, e não de forma genérica.

Sobre o curso Data Mesh: gerenciando controle e dependências

O curso Data Mesh: gerenciando controle e dependências possui 50 minutos de vídeos, em um total de 41 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:

• Testando o Data Product
• Criando dados sintéticos
• Usando portas de controle
• Controle e qualidade
• Arquitetura de dados quantum