GX & Data Quality: Criando suítes de teste unitários para grande volumes de dados
Eu já escrevi alguns posts sobre o Great Expectations e sobre data quality no passado, caso você queira entender o conceito da ferramenta e ter uma introdução ao assunto de data quality, ainda vale muito a pena revisitar esses posts, que eu vou deixar o link aqui:
- Great expectations: Descubra como aplicar conceitos de qualidade de dados na prática.
- Testes unitários em grandes volumes de dados com Great Expectations e Spark
O foco desse post será mais voltado para as principais evoluções que aconteceram na ferramenta e é claro, terá uma abordagem mais prática. Mesmo assim, é importante frisar que precisamos entender alguns estágios pra poder compreender o que estamos fazendo. Que vai ser:
Então, como vamos fazer?
Eu estou realizando esse lab no Jupyter. A primeira coisa a fazer é bastante obvia, vamos iniciar a sessão spark e realizar a leitura dos dados.
Para montar a suíte do GX, vou usar um dataset de vendas de produtos da Amazon 2023 que encontrei no kaggle. Esse dataset tem um pouco mais de meio milhão de linhas, essa é a lista das colunas :
E esse é um print do preview dos dados:
Decidi colocar o print das duas ultimas imagens acima porque elas serão de muita ajuda na construção da suíte de testes, uma dica pra montar uma boa suíte de testes é conhecer bem o seu conjunto de dados e entender o que é esperado acontecer com ele nas etapas do seu pipeline.
O próximo passo é instalar e importar o GX para poder utiliza-lo.
Agora é só criar o “Context”(contexto), pois é ele que irá gerenciar as configurações e metadados do projeto GX(Great Expectations) ele vai também funcionar como uma interface de comunicação para a a API GX Python.
No nosso caso, estamos usando um contexto de dados efêmeros, ou seja, ele existe na memória e não persiste além da sessão Python atual. Há outras formas de realizar a persistência e você pode entender mais sobre elas aqui. Se tudo deu certo ao criar o contexto, você deverá ver o projeto com diversas pastas e arquivos no diretório que foi passado como “context_root_dir”.
No GX o “datasource” é um objeto que possui várias configurações a respeito da fonte de dados original, e ele não contém os dados, são os “data assets” que irão corresponder diretamente aos conteúdos de tabelas ou arquivos de origem. Enquanto um datasource informa ao GX como se conectar aos dados de origem, data assets informam ao GX como organizar esses dados. E esses dados são carregados pelos “batch request”.
Como os dados que vamos nos conectar já foram importados em um dataframe spark iremos criar nosso datasource e depois usar o o método “add_dataframe_asset” para trazer os dados do dataframe spark para o datasource do GX.
Chegou o momento de criar a nossa suíte de testes, ela será composta pelas expectativas que temos a respeito do nosso conjunto de dados. Para poder executar a suíte de testes precisamos instanciar o principal componente funcional do GX, o “Validator”. Com ele podemos reaproveitar uma série de métodos desenvolvidos pela comunidade do GX e utilizar esses métodos para montar nossas suítes de teste.
No jupyter faremos desta forma:
Na imagem acima eu estou usando apenas 2 métodos (expectations): o primeiro verifica se existe valores nulos em uma determinada coluna e o segundo procura por um conjunto de caractere em uma string utilizando regex. Eu recomendo bastante realizar uma exploração nas expectations já disponibilizadas, você pode explora-las aqui. Outra dica, verifique antes se a expectation que você vai utilizar está disponível para a origem do seu dado, pela minha experiência com o GX posso afirmar que a maioria das expectations estão disponíveis para datasources Pandas.
Quando você executa uma célula do jupyter que possui uma expectation, no console já é possível verificar o resultado desta execução. Aqui eu vou criar uma expectation que deve falhar, vou usar a coluna “_c0” que é uma coluna index incremental no dataframe, a causa da falha é porque a coluna possui valores maiores que o valor passado como parâmetro no “max_value”:
O que eu mais gosto no GX é a maneira como ele consegue nos dar insights sobre o problema que aconteceu em nosso dataframe, e qual a dimensão do nosso problema, no print da imagem acima já conseguimos observar:
- A expectativa falhou, os valores contidos na coluna “_c0” estão fora do intervalo esperado;
- Mais de 400.000 registros estão fora desse intervalo, o que corresponde a pouco mais de 80% dos conjunto de dados;
- Apresenta uma lista com os valores que não estão de acordo com o que esperamos, que neste caso são valores menores que 0 ou maiores que 1000.
Os últimos passos para completar a nossa suíte de teste são: Criar o checkpoint e gerar o data docs.
O checkpoint é o componente do GX que agrupa um ou vários “validator” de uma “Expectation suite”. Eles são responsáveis também por salvar e atualizar as configurações da suíte na forma de arquivos YML no “context_root_dir”. Um dos recursos mais poderosos dos Checkpoints é que eles podem ser configurados para executar ações, as “Action” que podem executar algum processo com base nos reultados de um Checkpoint. Os usos mais comuns são: envio de e-mail, notificações para apps, atualização dos “Data Docs” ou qualquer coisa que você seja capaz de programar em Python. Os Data Docs organizam as saídas das “Expectation” da suíte em uma documentação em forma de um site HTML.
Vamos criar o checkpoint e configurar as actions de “UpdateDataDocsAction” e “build_data_docs” para salvar o resultado do nosso checkpoint e atualizar os nossos data docs.
Como resultado de saída da ultima linha da imagem acima conseguimos ver a pagina inicial do site que é gerado automaticamente pelo GX e que pode ser utilizado para acompanhamento e analise das execuções de todas as suítes construídas. Na página inicial, temos todas as execuções que aconteceram ordenadas por data da execução, e também nos é permitido filtrar as execuções.
Se você selecionar o nome de uma suíte, você consegue ter um overview dela, de todas as colunas que ela abrange bem como as “Expectation” a cerca destas colunas.
E, se voltarmos para a pagina inicial e selecionarmos uma execução conseguimos ver os mesmos detalhes que conseguiríamos no console do Jupyter, sendo que aqui a visualização é apresentada de forma mais agradável, e organizada de uma forma bem similar a um documento de caso de testes que geralmente vemos em desenvolvimento de softwares.
Eu fico muito feliz em ver como o GX está evoluindo e melhorando a cada versão, é uma ferramenta que tem muito potencial e que pode ajudar bastante a melhorar a qualidade na entrega dos dados e o melhor de tudo é Open Source. Espero que esse post consiga te ajudar em por onde começar a utilizar essa ferramenta e facilitar a adoção de um processo de data quality em suas pipelines!
Referências:
