# bases com datachecks

[laura-l-amaral]

• [ ] Explorar como estão atualmente os metadados de checks e entender se seria possível utiliza-los de maneira simples pra documentar os checks que fazemos

[laura-l-amaral]

Temos os seguintes campos para preenchimento do metadado Quality Check:

• Name
• Description
• Passed (bool)
• Pipeline
• Objeto relacionado ao quality check (dataset, tabela, coluna, raw data source, etc)

Existe a possibilidade de implementar um fluxo no prefect para ler e completar os metadados dos testes aplicados?

• Embora seja viável, parece envolver uma quantidade considerável de etapas e interações entre diversos sistemas, demandando um tempo aproximado de duas semanas para sua execução.

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:

• Ter um "quality_check" por tabela com todos os testes realizados descritos no campo de descrição
• Esse metadado seria criado a partir do script create_yaml.py (que já automatiza a inclusão de testes no schema.yaml).
• O script create_yaml.py incluiria de maneira padronizada todos os testes dentro do campo de descrição
• O "quality_check" subiria inicialmente com o campo Passed = False
• Após os analistas validarem todos testes vão lá e marcam 'Passed = True`

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:

• Preencher algumas informações sobre os testes, como por exemplo % de colunas conectaveis aos diretórios
• Incluir um "test dbt model" no tabble_approve que, após rodar sem erros, muda o metadado do teste Passed=True

@rdahis o que acha?

[rdahis]

Primeiro, estou adorando essas descrições longas facilitando o trabalho assíncrono aqui. 👍

Pensamentos:

• Eu modelei esse 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.
• Uma das vantagens dessa modelagem de 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.
• Se o trabalho de escrever pipelines para rodar alguns primeiros checks for tipo 2 semanas, eu acho que vale a pena. Exemplos, para começar:
  • Ter uma pipeline que roda 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).
  • Mesma coisa para testar qualquer coisa sobre metadados.
  • Pipeline que rode os testes DBT e guarde em quality_checks os resultados.
• Precisaríamos de uma pipeline geral 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".
• Não sei o que o 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?

[laura-l-amaral]

Vou numerar os pontos para responder mais diretamente

1. ok
2. ok
3. Acho que a gente precisa primeiro alinhar o objetivo da discussão aqui.

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:

• rodar todos os testes DBT de tempos em tempos seria algo bem caro
• se o dado não mudou, não vejo vantagem em rodar testes novamente
• faz mais sentido rodar os testes quando sobem dados novos

4. 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

5. 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:

• Demoraria muito mais do que só colocar todas as informações em description
  • Não tenho muito claro quais caminhos preciso seguir pra conseguir separar os testes, então não me surpreenderia se tomasse tipo um mês ou mais pra conseguir subir isso.
• Tornaria o processo de consultar os resultados dos testes mais dificil e demorado.
• Não tem ganho claro a não ser ficar mais organizado para talvez no futuro a gente fazer alguma coisa com isso,
  • Padronizando a maneira como ficam as descrições, caso a gente queira fazer essa separação no futuro seria viável implementar um código que separa os testes sem muita dificuldade.

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.

[rdahis]

Legal. Sempre bom dividir melhor os passos!

Mais alguns pontos:

• Topo focarmos em testes sobre dados (e não metadados agora).
• Note que cada 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).
• Tendo esses 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.

[rdahis]

Criei um quality_check como exemplo. Vê no GraphQL:

query getQualityChecks {
  allQualitycheck {
    edges {
      node {
        name
        description
        createdAt
        table {
          slug
          dataset {
            slug
          }
        }
      }
    }
  }
}

[laura-l-amaral]

Faz sentido!

[laura-l-amaral]

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:

• continuariamos rodando os testes em dev, mas sem registrar os resultados
• ao rodar qualquer modelo dbt em produção rodariamos também os testes, registrando os resultados com o elementary
• 1 ou 2 vezes por dia poderiamos gerar o report do elementary, pra equipe dados poder acompanhar como que está a qualidade dos dados e corrigir erros importantes. Algumas coisas podem aparecer como erros, mas serem coisas que nao necessáriamente nós vamos corrigir (como algumas tabelas terem id municípios que não existem e por isso não batem 100% com a tabela de diretórios)

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?

[laura-l-amaral]

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

[rdahis]

Para registrar, conversamos no Discord e dei o ok para implementarmos esse caminho e testar como fica.