Criar um modelo
Criar um modelo no DBT é muito fácil, pois um modelo não é mais do que uma declaração SQL.
Após criá-lo, só poderá executar esse modelo usando o comando DBT run, como exemplificado abaixo:
dbt run –model stg_actors
Figure 1. DBT Lineage
Mas isso está errado.
Com a sintaxe usada, está a:
- Perder a lineage do modelo, o DBT não conseguirá referir-se ao modelo que está a utilizar, e assim perderá uma das vantagens significativas do DBT.
- Não está a usar um bloco de configuração.
Embora seja possível definir a configuração do modelo no seu dbt_project.yml (um arquivo que existe sempre em projetos DBT ), este é mais adequado para configurações globais. Pode fazer configurações específicas do modelo no ficheiro .sql ou no ficheiro .yml, onde pode adicionar especificidades do modelo, o que é mais aproximado.
- Está a tornar o código mais confuso
No exemplo apresentado, o código é simples, mas com queries complexas, tente dividi-las em blocos de código mais simples que se possam conectar e completar uns aos outros (CTEs). Comece com um ou mais CTEs que recolhem os dados da fonte de dados, em seguida prossiga com a transformação dos dados e, por fim, exponha o conjunto de dados obtido.
Agora está correto:
Figure 2. Data Lineage 2
Obter dependências do modelo
Ao utilizar as palavras-chave ref e source nos modelos DBT (conforme recomendado), é fácil obter todas as dependências de um modelo (tanto upstream como downstream) usando a linha de comando:
dbt ls –select +dim_actors
Figure 3. Dependências Upstream
dbt ls –select dim_actors+
Figure 4. Dependências Downstream
É possível combinar ambas as dependências, incluir uma limitação ao número de parents, obter os parents de children do modelo selecionado e assim por diante. Isto permite obter a lineage dos seus modelos, mas permite também executar um modelo, juntamente com a sua lineage , na ordem correta, usando dbt run em vez de dbt ls.
Gerar a lineage no dbt
Num nível mais elevado, um sistema de lineage de dados fornece, normalmente, às equipes de dados e aos consumidores, um ou ambos dos recursos abaixo:
- Um gráfico visual (DAG) de workflows sequenciais ao nível do data set ou da coluna
- Um catálogo de dados, com informações sobre a origem, proprietários, definições e políticas dos recursos dos dados.
O DBT é capaz de gerar ambos, usando dbt docs generate, que compila informações relevantes sobre o seu projeto e warehouse DBT em ficheiros manifest.json e catalog.json, respetivamente.
Depois disso, pode publicá-los num website estático (juntamente com index.html) ou executar o comando dbt docs serve para preencher um website local.
Figure 5. Lineage do Projeto
Também pode importar manifest.json e catalog.json para analisar a lineage noutras ferramentas que disponibilizam opções diferentes, como lineage ao nível de campo: Atlan, Collibra, Monte Carlo, etc
Criar e exportar documentação
Com DBT, a documentação fica próxima do seu código (onde faz sentido) e já mencionamos como gerá-la (da mesma forma que para a lineage): dbt docs generate
Esta ação irá gerar manifest.json e catalog.json (juntamente com a lineage), e pode publicá-los e visualizá-los num website local ou num website remoto:
Figure 6. Documentação com Lineage
Testar os seus dados
Com DBT, pode escrever o seu código e criar os testes na mesma solução, o que torna os testes mais abrangentes na sua solução. É fácil de identificar quais os testes usados e em que módulo (são documentados automaticamente) e é mais fácil geri-los (ao contrário da abordagem não holística normalmente usada com testes em outras soluções).
No DBT, define os testes no mesmo arquivo em que incluiu a documentação do seu modelo, como se segue:
Figure 7. Testes definidos ao longo da documentação
O DBT vem com quatro testes genéricos que pode aplicar aos seus dados desde o início:
- unique
Para verificar se não existem duplicados na coluna.
- not_null
Para verificar se a coluna não é nula
- accepted_values
Uma lista de valores que são aceitáveis para a coluna
- relationships
Fazer corresponder os valores da coluna com os valores de outros modelos
Pode também definir testes personalizados, tanto testes únicos específicos para um modelo como testes genéricos com consultas parametrizadas. Testes no DBT não são mais do que declarações SQL aplicadas aos seus modelos que retornam erros de validação. Se nenhum erro for retornado, o teste passou.
Figure 8. Teste Genérico
Figure 9. Teste usado no modelo
Também é possível incluir pacotes de testes no DBT que alargam o tipo de testes que podem ser realizados.
Neste caso, usaremos o pacote DBT-expectations e o teste expect_table_columns_to_contain_set para aumentar o número de testes que temos disponíveis (sem precisar de codificá-los):
Figure 10. Testes definidos ao longo da documentação
Usar macros
As Macros no DBT são criadas em Jinja e são elementos de código que podem ser reutilizados várias vezes. São extremamente úteis quando é necessário repetir código em vários modelos. As Macros são definidas em ficheiros .sql, normalmente localizados no diretório de macros na solução DBT .
Nada melhor do que analisar uma macro que faz algo interessante:
Figure 11. Macro para limitar o tamanho dos dados do ambiente de desenvolvimento
Depois, pode ser aplicado onde quer que seja necessário:
Figure 12. Utilização
Figure 13. Código Compilado
Utilizar pacotes
Existem vários pacotes que podem ser utilizados para aumentar a funcionalidade do DBT. Por exemplo, o pacote dbt_utils inclui testes adicionais que podem ser realizados no DBT (além dos quatro testes genéricos já incluídos), macros que permitem não ter que reinventar a roda vezes sem conta, como generate_series que implementa um mecanismo de banco de dados cruzado para gerar uma lista arbitrariamente longa de números, uma macro para realizar um pivot de linhas para colunas e muito mais. Pode até usar macros que executam algumas transformações Python, para que não fique limitado ao SQL.
Para poder utilizar um pacote no DBT, basta incluí-lo no ficheiro pacotes.yml e em seguida execute dbt deps:
Figure 14. packages.yml
E assim pode ser aplicado onde for necessário.
