Aprenda a criar fontes de dados e executá-las no DBT.
- INTRODUÇÃO
- SOURCE: CONFIGURANDO AS FONTES DE DADOS
- MODELS: EXECUTANDO O PROJETO
- CONCLUSÃO
- NEWSLETTER
- REDES SOCIAIS
INTRODUÇÃO
DBT é uma ferrementa open-source que vem ganhando muito espaço, tanto na área de analytics, quanto data engineer. Tendo uma forte base na linguagem SQL, a ferramenta se posiciona como uma camada de transformação de dados no destino.
Muito útil para processos de ELT, DBT é capaz de criar modelos robustos, performáticos e seguros.
Continuando o post sobre o DBT, hoje trago para vocês as operações básicas dentro da ferramenta e como criar as primeiras cargas para o seu Data Warehouse.
Sabendo que DBT opera sobre pastas e subpastas com templates apontando o quê, quando e onde executar os arquivos. Além disso, a ferramenta também precisa que sejam apontados as fontes e o destino.
Assim sendo, vamos ver o básico deste processo para entender como organizar um bom projeto de ELT e Analytics Engineer.
Neste artigo, veja como criar suas primeiras fontes e executar um modelo em seu banco de dados.
SOURCE: CONFIGURANDO AS FONTES DE DADOS
Quando pensamos em modelo relacional e sua estrutura, logo nos vem na mente o schema, a estrutura que “concentra” as tabelas e facilita a construção de queries.
NOTA: em alguns bancos, a denotação para schema pode ser diferente, como no Oracle. Como estou utilizando SQL Server, vou me basear na forma que ele estrutura o schema.
Quando vamos trabalhar com o DBT, a fonte de dados é um pouco diferente e as transformações que criamos não buscam diretamente uma tabela, mas o documento que contém o apontamento para as fontes.
As sources do DBT são sustentadas por um arquivo no formato YML, que tem base no JSON, já que se vale do par “Key – Value”.
Como ele é uma camada de processamento de dados, ele não consulta diretamente o banco, ele consulta sua fonte:
Veja que na query acima, não informamos o schema.nometabela diretamente.
Para passar as tabelas, crie a chave table:
Para entender melhor:
- Source → é a fonte de dados; é uma classe do DBT.
- Country_continent_src → é o nome da fonte que armazena as tabelas que o modelo irá consultar.
- Salesterritory → é a tabela propriamente dita.
Veja a imagem abaixo.
- Amarelo → o nome da fonte de dados que será informado para a classe source;
- Vermelho → o nome do banco de dados;
- Branco → o schema base das tabelas;
- Verde → nome das tabelas (stateprovince);
- Rosa → colunas da tabela stateprovince.
Podemos perceber que a ferramenta trabalha com um arquivo pré-configurado que serve de entrada para as diversas funções que o DBT possui.
Ainda sobre a imagem anterior, podemos aplicar testes de qualidade de dados quando estamos rodando um modelo. Enquadrado em rosa, realizei dois testes de checagem para as colunas identificadoras nas tabelas fonte.
Uma vez que elas são PK no ambiente OLTP, posso testar a integridade dos dados para não inserir valores faltantes, comprometendo o DW.
Dependendo do seu projeto, é possível ter um único schema para todo o modelo desenvolvido. Porém, se for dividido em sub pastas, cada uma deverá ter a sua Source.
As sources para uso no DBT ficam dentro da pasta Model. É o recomendado.
Na source podemos especificar os schemas, tabelas, colunas, alguns testes, se a fonte é válida ou não, mensagens de erro e etc.
Assim como em queries dentro do banco de dados, não necessariamente somos obrigados a nos limitar apenas em uma fonte. Se entenderam bem, dentro do meu modelo, utilizei duas fontes para extrair os dados.
Veja que para cada uma das fontes, há um conjunto de tabelas que posso selecionar. Embora a imagem esteja reduzida, temos a percepção.
Se não especificar quais colunas a tabela deve ter, todas estarão disponíveis.
Inclusive, é um ponto positivo para a segurança, já que limita os acessos indevidos aos dados sensíveis ou confidenciais.
Em outro artigo, irei aprofundar mais sobre as Sources de um projeto do DBT. Como ainda estou entendendo, vou estudar melhor sobre o assunto.
MODELS: EXECUTANDO O PROJETO
Quando criamos o projeto com o comando:
dbt init "nome_projeto”
ele cria uma série de pastas com arquivos e dentre um deles, a pasta Models.
A pasta contém os arquivos SQL com as queries desenvolvidas para rodar o projeto e entregar as análises.
Todo o projeto roda na pasta Models e para cada pasta, um arquivo .SQL com sua fonte.
E como o DBT sabe que tem de executar os arquivos desta pasta?
No arquivo Project.yml, que é criado quando o projeto é iniciado, há o PATH para configurar como o modelo deve se comportar de acordo com a opção Models.
Caso passe um subdiretório para o DBT, ele irá executar somente os arquivos que ali estão.
Na configuração acima, somente os arquivos da pasta Customer serão executados.
Na imagem anterior, a pasta Models possui diversas outras pastas com transformações, porém, irei executar apenas a pasta Customer, para o exemplo.
Como podem ver, ele encontrou apenas 1 arquivo e criou apenas uma View no meu banco de dados.
Ao final, ele cria uma View no banco de dados com as colunas selecionadas.
Porém, se quisermos criar uma tabela utilizando o DBT, precisamos informar no modelo utilizando a seguinte estrutura.
Ao chamarmos a função config, passando os valores para os parâmetros, estamos alterando o comportamento final da query. Ao invés dele criar uma View, teremos uma tabela.
Se olharmos para o log de execução, veremos que ele não criou uma View, mas uma tabela.
Consultando no banco de dados:
Agora temos uma tabela física no banco de dados, resultando em um processo de ELT.
Existe a possibilidade de configurar no arquivo Project.yml, criado no início do projeto. Porém, quando utilizamos o método acima, o que ocorre é uma sobrescrita.
Na configuração, temos uma View declarada, porém, criamos a tabela.
Declarar a base de dados e o schema ajuda a fixar o destino, evitando erros ou comportamentos indesejados.
No entanto, mesmo que haja alguma troca ou qualquer outro problema, o que irá contar no final é o schema do Profile – contanto que tenha declarado.
Mesmo que o schema declarado no Profile não exista, a ferramenta criará para armazenar a tabela no banco.
Se não sabe como criar um Profile, acesse aqui.
Veja abaixo no banco de dados:
Isso nos mostra que o DBT é totalmente orientado por schemas e que não irá executar as funções corretamente se não houver um declarado. Respeitando as regras dos modelos relacionais e dimensionais.
CONCLUSÃO
Quando se trata de versatilidade com a linguagem SQL, DBT é uma das melhores ferramentas para se trabalhar.
Totalmente orientado por templates, o que torna o manuseio mais fácil e menos propenso a erro, é bem simples para especificar os projetos e começar a criar modelos de dados para análise.
As fontes de dados são um dos pilares do DBT. Mesmo que no início consumam um pouco de tempo, para especificar corretamente, o ganho é maior quando o projeto já está funcionando. Justamente por funcionar como um template.
Tenha um arquivo de fonte para cada transformação.
Cuidado com as configurações do modelo, saiba que são facilmente sobrescrita, quando temos uma declaração explícita.
Declare sempre o schema correto durante as transformações no DBT.
Ao nomear os arquivos .SQL, nomeie-os com os nomes das tabelas. A ferramenta grava no banco o nome do arquivo.
NEWSLETTER
Se chegou até aqui ou gostou desse artigo sobre o DBT, se inscreva na newsletter e fique atualizado do que sai no nosso blog.
ManageBI 