Open laura-l-amaral opened 8 months ago
Temos os seguintes campos para preenchimento do metadado Quality Check:
Existe a possibilidade de implementar um fluxo no prefect para ler e completar os metadados dos testes aplicados?
O uso dbt e prefect não facilita capturar os resultados e metadados de cada teste, o que torna o processo trabalho demais se o objetivo é só saber quais bases a gente passou quality-checks.
Gostaria de não complicar muito o processo de capturar esse dado.
Uma alternativa que me parece boa:
create_yaml.py
incluiria de maneira padronizada todos os testes dentro do campo de descrição Passed = False
Gosto dessa opção pq dessa maneira, resolvemos o problema de maneira relativamente rápida, sem aumentar o trabalho dos analistas, ao mesmo tempo que deixamos as coisas bem padronizadas e que facilitam mudanças futuras. Tendo esse metadado preenchido conseguimos acompanhar quais são bases com datachecks direto dentro do metabase!
Outros passos dentro dessa alternativa:
Passed=True
@rdahis o que acha?
Primeiro, estou adorando essas descrições longas facilitando o trabalho assíncrono aqui. 👍
Pensamentos:
quality_check
no intuito de termos metadados individualizados de checks. A visão era eventualmente ter um dashboard alimentado disso ficando público como nosso 'observatório de qualidade de dados e metadados'. Mas essa modelagem foi da minha cabeça, e não está conectada a ferramentas padrão (tipo Great Expectations ou sei lá). A vantagem é que é bem flexível e adaptada exatamente ao nosso banco.quality_check
é que ela permite certos checks serem manuais e outros automáticos via pipeline. Estaríamos sempre registrando quando foi rodado o último check. Isso nos daria uma visão da evolução do que passou, de quando quebrou, etc.quality_checks
de has_description
para todas as colunas, uma vez por dia. A pipeline pode criar novas linhas de quality_check
ou pode editar o que já existe (supondo que aí o Django mantém o histórico).quality_checks
os resultados.run_quality_check
e parâmetros de qual teste rodar. Esses parâmetros já podem estar guardados no próprio banco de dados! Exemplo: quality_check="has_description", object="table", code="table.description is not None"
.create_yaml.py
faz, então não entendi 100% o que seria o fluxo alternativo proposto. Meu receio é que botar os resultados em description
vai inviabilizar desaguar tudo num dashboard, que é o principal objetivo.@d116626 tem alguma opinião também? Tem alguma ferramenta out-of-the-box capaz de entregar toda essa flexibilidade que gostaríamos, sem ter que reinventar a roda aqui?
Vou numerar os pontos para responder mais diretamente
O que eu tinha imaginado nesse indicador é acompanhar quantas bases a gente parou para passar quality checks mas pensando nos dados, não nos metadados. Se nesse indicador incluirem checks para metadados acho que número de bases é um indicador ruim, pq como as coisas são bem generalizaveis a gente consegue ver para todas bases de uma vez só.
Entendo que a construção de um painel que traga a qualidade dos metadados também é muito relevante, só que é uma outra tarefa. Sugiro que nesse momento eu foque em achar uma maneira de acompanhar o número de bases que passaram por quality checks na parte de dados e pegar a tarefa de montar o painel de qualidade dos metadados assim que terminar de compilar os demais indicadores da equipe dados desse semestre.
Se vc concordar com isso nesse primeiro momento eu só faria o ponto "Rodar os testes DBT e guardar em quality_checks os resultados."
Se der tempo desenvolvo esse processo como uma pipeline, mas tem alguns pontos que me fazem pensar que não é algo ideal:
Não vejo a necessidade da construção dessa pipeline para o objetivo dessa issue. Mas podemos avaliar depois de conseguir o objetivo 1 que é ter um painel com os indicadores de dados
Fluxo alternativo
O create_yaml.py é um script que a gente fez para montar o arquivo schema.yaml e .sql a partir da arquitetura. Para facilitar a vida de todo mundo o script também já inclui 3 testes a partir das informações da arquitetura: não nulidade de nenhuma coluna, chaves únicas e conexão com diretórios.
A proposta seria colocar todos esses testes no description, pq o objetivo final dessa issue seria ter documentado os testes que cada base passou antes do final de janeiro e essa é a maneira que consigo visualizar como viável e adequada.
Separar cada teste DBT:
Proposta Minha proposta seria a gente focar no objetivo de ter documentado os testes que cada base passou antes do final de janeiro, separar um tempo determinado pra eu gastar nessa tarefa, tipo 2 semanas e ir mais o longe que der nesse tempo. Se der tempo de separar os testes e fazer uma pipeline ótimo! Se não, a gente coloca como backlog e reavalia no final do mês.
Legal. Sempre bom dividir melhor os passos!
Mais alguns pontos:
quality_check
é um teste separado. Suponha que a tabela tenha passado por 2 checks já (ex: nenhuma coluna nula, chaves únicas). Criaríamos manualmente dois quality_checks
separados no banco. Um se chama tipo no_null_columns
, o outro all_foreign_keys_are_keys
. Cada quality_check
tem uma data de criação no banco. Essa data é de quando o teste foi registrado, não de quando foi feito. Então é isso, nessa primeira vez criaremos na mão "atrasados relativo a quando foi rodado". No futuro criamos as pipelines para rodar testes periódicos (pode ser intervalo regular, pode ser só quando os dados mudarem, etc).quality_checks
registrados, já é fácil hoje exibirmos um metabase com o que passou em qual teste quando. O metabase já está conectado ao banco de produção. É só popular os quality_checks
. Também não seria difícil pedir pro Lessa exibir na página de tabela essas informações (tudo se conectaria via table_id
no GraphQL). Sou contra botar essas informações na description
da tabela direto.O que acha? Fazendo assim dá tranquilo para documentar todas as tabelas que passaram por testes de qualidade.
Criei um quality_check
como exemplo. Vê no GraphQL:
query getQualityChecks {
allQualitycheck {
edges {
node {
name
description
createdAt
table {
slug
dataset {
slug
}
}
}
}
}
}
Faz sentido!
Então @rdahis atualizações aqui!
Chamei o @arthurfg pra me ajudar nessa parte de quality checks e ele encontrou um pacote excelente para o que a gente quer fazer.
O pacote se chama elementary e é capaz de gerar reports automátizados e bem completos com os resultados de todos os testes que foram rodados no dbt. Ele organiza os artifacts, que é basicamente o registro de tudo que acontece no DBT, em um conjunto no BigQuery e a partir disso gera um relatório em formato html. o art até fez um gif para vc conseguir ver como que fica o resultado:
Acredito que o ideal seria a gente ter acesso a esse html para monitorar a qualidade dos dados em produção o fluxo seria bem simples, mas basicamente:
o próximo passo seria descobrir o caminho para exportar esse relatório (a principio nao parece ser dificil e o @vncsna tem ajudado a gente com as coisas mais complicadas)
Num próximo momento podemos pegar as informações que estão no BQ nesse conjunto elementary para montar os metadados do django e pensarmos em como colocar isso no front end para nossos usuários.
O que acha?
Aa adendo importante, vamos acompanhar o crescimento de custos no BQ para avaliar se rodar os testes toda atualização em prod está sendo muito caro ou não
Para registrar, conversamos no Discord e dei o ok para implementarmos esse caminho e testar como fica.