dbt: Princípios e primeiros passos com o framewok!
Como falamos no post anterior, o dbt se trata de um framework, o qual utiliza de SQL como base de sintaxe, para processamento/transformação de dados analíticos. Ou seja, tem como foco a etapa de Transformação (T) do ETL (Extraction, Transformation and Load).
Uma vez entendido o que é o framework, como instalá-lo e configurá-lo, agora vamos entender as features fundamentais para iniciar os primeiros passos no desenvolvimento de pipelines utilizando desse framework tão incrível!
Como crio meus processos de transformação?
Primeiro conceito importante é que, o conhecido job (uma etapa de um desenho completo de transformação) de ETL se trata de um modelo no dbt. Os modelos são arquivos .sql, nos quais são feitos os desenvolvimentos efetivamente.
Os modelos criados se tornam objetos no repositório de dados analítico quando executados. Existem quatro tipos de materializações:
- View (default): quando executado o pipeline, uma view será criada no banco de dados a partir desse modelo, com base no SQL do modelo.
- Table: quando executado o pipeline, uma tabela será criada no banco de dados e terá carga de dados realizadas com base no SQL do modelo. Toda vez que o modelo for executado, os registros serão excluídos e nova carga de dados realizada.
- Incremental: uma tabela precisa ser previamente criada no banco de dados para receber a carga de dados, que a cada execução inserirá novas linhas de registros (caso os dados sejam novos) ou irá atualizá-las (caso se trate de dados existentes). O processo será realizado considerando de uma chave pré-estabelecida no modelo para validação do merge de dados.
- Ephemeral: Nenhum objeto é criado no banco de dados quando executado o pipeline, mas esse tipo de modelo trabalha como source para modelos dependentes como expressões de tabela comuns.
Bacana! E como são criadas as dags?
Lembra-se que no post anterior expliquei que o framework possibilita a criação de todo um workflow, criando dags? Pois é! Isso se dá através da utilização do comando ref. Esse comando é utilizado para referenciar em um modelo B, determinado modelo A como source para desenvolvimento.
Dessa forma, a dag começa a ser composta, sendo: Modelo A ligado a Modelo B como predecessora através de referência.
No exemplo acima, podemos ver um workflow, o qual foi composto através das referências de modelos. Sendo que, o modelo final analytics_transactions(4) foi criado referenciando o modelo stg_transactions_offers(3), que por sua vez, referenciou o modelo stg_transactions(2), que por sua vez, referenciou a tabela transactions(1), a qual foi configurada em arquivo source.
Abaixo podemos ver o conteúdo do código do modelo analytics_transactions para exemplificar a referência que deve ser aplicada utilizando o comando ref.
Além do comando ref, existe também o comando source, o qual você deverá utilizar para referenciar uma tabela definida no arquivo de source (falaremos em breve sobre ele). Esse comando identifica a tabela origem a ser utilizada. O comando deve ser composto considerando a seguinte sintaxe:
source(‘schema_name’, ‘table_name’)Abaixo podemos ver o conteúdo do código do modelo analytics_transactions para exemplificar a referência utilizando o comando source.
Como definir as sources de dados?
Uma vez que o processo de Extração (E do ETL) deverá ser feito por outra ferramenta / framework, é importante ter configuradas todas as sources de dados, de forma que seja possível o desenvolvimento do primeiro modelo a ser trabalhado.
Sendo assim, a best practice é criar o arquivo de source.yml, o qual sugiro ser criado com o nome da aplicação de origem do dado raw, exatamente para facilitar o entendimento e manutenção de códigos, visto a semântica transparente!
O objetivo desse arquivo é que contenha o nome do bancos de dados, nome do schema, nomes de tabelas e seus descritivos, além de suas colunas e dicionários de dados!
Esse material é absolutamente relevante e importante em termos de documentação, para apoiar os desenvolvedores na leitura e manutenção dos códigos!
Legal! E posso trabalhar com um arquivo sample de dados?
Caso você queira fazer um teste utilizando de um sample de dados, o dbt contém um comando chamado seed, o qual fará a ingestão de arquivos com extensão .csv. Para isso, é necessário disponibilizar o arquivo na pasta /data.
Ao executar a ingestão através do comando descrito abaixo, uma nova tabela será criada no repositório analítico, a qual terá uma carga de dados efetuada nesse repositório.
dbt seedImportante: Caso seja realizada uma nova execução desse comando, novos dados serão inseridos. E com isso, será gerada duplicidade na base de dados.
Como executo meu pipeline?
O pipeline inteiro pode ser executado através do comando:
dbt runTambém é possível executar somente determinado modelo de dados através do comando:
dbt run — models nome_modelo_a_executarPosso aplicar testes no meu pipeline?
Uma feature muito importante e realmente muito necessária é relacionada aos testes dos pipelines! Aliás, eu, particularmente, acho essa feature maravilhosa e realmente muito bem sacada pelos fundadores! Realmente nos ajuda muito para garantia de qualidade dos dados! 💃 🎉
Para utilização dela, é necessário que crie um arquivo test.yml ou utilize do pŕoprio arquivo source.yml definido. No arquivo, é necessário descrever os testes que deverão ser aplicados posteriormente à execução dos jobs, tais como, validação de duplicidade de registros, validações quanto aos domínios de dados, registros nulos, entre outros.
Como pode ver no arquivo de source.yml como exemplo acima, foram definidas algumas validações de teste. Por exemplo:
- Validação de que a column_name da tabela table_name1 deve conter registros únicos (sem duplicidade)
- Validação de que devem conter registros para todas as linhas. Ou seja, não podem conter registros nulos na coluna column_name da tabela table_name1.
Se em algum momento, as regras descritas acima forem violadas, então, o dbt retornará erro relacionado a regra determinada.
O processo de validação pode ser realizado através da execução dos seguintes comandos descritos abaixo.
Para executar testes em todos os arquivos de tests e sources:
dbt testPara executar testes específicos:
# Executa teste no schema (estrutura) e de dados
dbt test# Executa teste apenas de schema (estrutura)
dbt test — schema# Executa teste apenas de dados
dbt test — data
Como deve imaginar, existem várias features no dbt, as quais compartilharei por aqui em momentos futuros! O objetivo aqui era compartilhar conhecimento necessário para que entenda os principios do DBT e com isso, inicie os primeiros passos na criação de pipelines utilizando desse framework incrível!
Aliás, no próximo post irei compartilhar e explicar um pipeline criado utilizando de um case como referência! Ficou interessado(a) em saber mais?Fique atento e nos vemos em breve! 😉
Até lá! ❤
