Guia prático do DBT: Orquestrando o projeto.

Uma jornada em 3 etapas para dominar a ferramenta de transformação de dados — DBT — Parte 3 de 3.

11 min readOct 29, 2023

Este é o terceiro de uma série de artigos com o objetivo de guiar e proporcionar mais informações sobre o DBT, uma ferramenta muito usada no mercado atual para transformação de dados. Neste artigo, discutiremos como orquestrar seu ambiente com o uso do DBT Cloud. Se você deseja começar a ler o guia desde o início, basta acessar o link: Desvendando a arquitetura e configuração inicial. E se você deseja se aprofundar ainda mais ou até considerar a contratação da solução, é recomendável dar uma olhada no site oficial do produto: Product — DBT Cloud.

>>> DBT Cloud

O dbt Cloud é uma plataforma baseada na nuvem desenvolvida para simplificar o desenvolvimento, execução e agendamento de modelos de transformação de dados usando o dbt. É um produto de assinatura oferecido pela empresa oficial, DBT Labs.

Com o dbt Cloud, é possível orquestrar, desenvolver, controlar e monitorar seu ambiente de produção de maneira altamente eficiente. Atualmente, existem três planos disponíveis:

Developer: Essa é a versão gratuita oferecida pela DBT Labs, ideal para iniciantes que desejam explorar e dar os primeiros passos no desenvolvimento dentro do ambiente. Pode ser utilizado por um único desenvolvedor.
Team: O plano intermediário da solução é amplamente adotado no mercado. Atualmente, ele tem um custo de $100 por mês por usuário desenvolvedor e oferece recursos adicionais, como acesso à API e a capacidade de criar usuários com permissões de leitura.
Enterprise: Este é o plano personalizado, que permite dimensionar o ambiente de acordo com as necessidades específicas da sua empresa. Para obter informações sobre preços e negociações, é necessário entrar em contato diretamente com a equipe de vendas da DBT Labs. Esse plano oferece um atendimento avançado e personalizado, mas também implica em custos mais elevados, que variam de acordo com a utilização do seu negócio.

Os planos estão sujeitos a alterações constantes de preço e funcionalidades, o que nos levou a reavaliar a melhor maneira de orquestrar nosso projeto. Atualmente, estamos utilizando o plano Team, que atende bem às nossas necessidades, especialmente em relação ao agendamento e monitoramento do ambiente. No entanto, estamos considerando alternativas no mercado, como a migração para o Airflow ou a exploração de ferramentas da AWS com suporte do Fargate.

Para obter mais detalhes e acompanhar as mudanças nos planos, recomendo o site oficial da ferramenta: Pricing.

>>> Project

Inicialmente, é necessário criar um projeto onde as etapas subsequentes serão desenvolvidas. Dividido em quatro partes, o processo de configuração é responsável por estabelecer a conexão entre o repositório e o Data Warehouse. Nessa etapa, você fornecerá as credenciais de conexão principais.

Se este é o seu primeiro acesso, o sistema o conduzirá automaticamente por esse processo. No entanto, após criar o projeto, você poderá retornar a essas configurações seguindo o caminho: Settings > Acconts Settings.

>>> Environment

Com o projeto criado, agora vamos explorar o environment. Para isso, siga o caminho: Deploy > Environments > Create Environment. Nele, você definirá algumas configurações base divididas em três partes:

General settings: Nessa primeira parte, você escolherá um nome para o environment, indicará se é um ambiente de desenvolvimento ou deploy e selecionará a versão padrão do dbt a ser utilizada.
É importante manter-se atualizado sobre as mudanças nas versões para aproveitar melhorias e garantir que você não esteja usando uma versão sem suporte. Para acompanhar as datas de lançamento, recomendamos consultar a documentação oficial do dbt: About dbt Core versions.
Deployment credentials: Na segunda parte, você irá configurar as credenciais necessárias para se conectar ao banco de dados e executar as tarefas programadas nesse environment. Além disso, você definirá o schema no qual as modelagens serão geradas. Em nosso caso, usamos a chave “dbt_prod” para o ambiente de deploy.
Extended attributes: A terceira parte é opcional e permite que você adicione atributos adicionais, normalmente usados no arquivo “profiles.yml”, para definir diferentes tipos de conexões. Isso inclui configurações como tempo limite de conexão, região, uso de nodes, entre outros:

connect_timeout: 600
ra3_node: true
region: us-east-1

>>> Job

O Job no dbt Cloud representa uma tarefa na qual você pode programar uma sequência de comandos a serem executados sempre que ele for acionado, seja manualmente, por meio de agendamento ou em resposta a um pull-request.

Todas as informações referentes aos processos executados são registradas na plataforma, permitindo que você acompanhe os Jobs existentes, os períodos de atualização, o tempo gasto em cada etapa/modelagem e os comandos executados pela plataforma em seu Data Warehouse, entre outros detalhes.

Os Jobs são divididos em dois tipos:

Deploy jobs

Você pode configurar uma série de comandos para atualizar os modelos e processos do seu projeto DBT. Você pode invocá-los manualmente ou programar sua execução. Abaixo, descrevo as 4 etapas para configurar um novo job. Para chegar a essa configuração, siga o seguinte caminho: Deploy > Jobs > Create job > Deploy Job.

Job settings: Aqui, você definirá um nome para o seu job, uma descrição e o environment. Por padrão, o environment em que o job está sendo criado já estará marcado.

Execution settings: Na seção “Commands”, você incluirá os comandos a serem executados. Cada linha de comando funciona como uma etapa, e se uma delas falhar, as etapas subsequentes não serão executadas. Ao executar uma pasta de modelagens, não é necessário se preocupar com as dependências, pois a plataforma já identifica o fluxo de linhagem.
Além disso, você pode organizar os comandos com a ajuda do arquivo “selector.yml” apresentado na etapa 2 deste guia. Em vez de executar um modelo ou pasta diretamente, você pode executar um grupo de seleção definido no projeto.
Nas opções de seleção, você encontrará “Generate docs on run”, que, quando ativada, gera um arquivo de documentação toda vez que o job é executado, com base no preenchimento do “schema.yml”. E há a opção “Run source freshness”, que, quando ativada, permite controlar a data da última atualização dos modelos de acordo com as regras definidas no “sources.yml”.

Schedule: Se habilitada, você pode definir o agendamento de execução do job. Você pode escolher entre os tipos: Cron schedule, Hours of the day e Exact intervals.

Advanced settings: Na última etapa, você pode personalizar algumas funções opcionais. A opção “target” permite personalizar processos e filtros importantes dentro do projeto, conforme exemplificado na segunda parte do guia. Quanto às “threads”, elas determinam quantos modelos podem ser executados simultaneamente. Por padrão, são 4 threads, mas você pode personalizá-las de acordo com a capacidade do seu data warehouse.
Aumentar o número de threads pode acelerar o processamento do job, mas se o banco não tiver capacidade suficiente para suportar o volume, pode gerar filas de execução que prejudicam o desempenho desejado. Portanto, é importante equilibrar essa configuração de acordo com a capacidade disponível.

Continuous integration jobs

Você pode utilizar esta ferramenta para executar um job sempre que um novo pull request (PR) for criado em seu repositório Git. No entanto, para habilitar essa função, é necessário estabelecer uma conexão nativa entre o Cloud e o repositório. Se o seu repositório for do tipo self-hosted e você estiver usando o plano Team no Cloud, essa função não estará disponível.

Uma vez conectado, o sistema executará e testará apenas os modelos que foram modificados ou afetados pela alteração. Para acessar essa configuração, siga o caminho: Deploy > Jobs > Create job > Continuous integration job.

A configuração é dividida em três partes: Job settings, Execution settings e Advanced settings. As principais diferenças em relação a um job do tipo Deploy são as seguintes:

Na etapa 1, é importante habilitar a opção “Triggered by pull requests”.
Na etapa 2, existem duas diferenças significativas.
Os comandos usados aqui são: “dbt seed --select state:modified+” e “dbt run--select state:modified+”.
E em “Compare changes against an environment”, é fundamental apontar um job de referência. Nesse caso, selecionamos o nosso job diário de modelos analíticos.

Uma vez que a configuração esteja concluída e habilitada, você pode tornar esse processo uma etapa de aprovação obrigatória antes do Merge. Em que o DBT Cloud e um parceiro devem aprovar as alterações antes que o Merge seja permitido, como demonstrado no exemplo a seguir.

Além disso, para quem trabalha com bancos de dados volumosos, como este, é aconselhável incluir um limite de carga para o target de CI durante a criação dos modelos. Isso evita que o processo fique preso ao executar uma carga completa durante os testes. Por exemplo:

{% if target.name == 'ci' %}
  LIMIT 1
{% elif is_incremental() %}
  WHERE tstamp_column ::DATE >= DATEADD(DAY, -{{var('filter_days')}}, CURRENT_DATE)
{% endif %}

>>> Documentação

Com o schema.yml dos modelos devidamente preenchido e a função “Generate docs on run” ativada no job, você pode definir esse job como ponto de referência para o projeto e, em seguida, visualizá-lo por meio de uma aplicação web.

Para fazer isso, siga estas etapas: Settings > Account Settings > Projects > Artifacts > Documentation e selecione o job com a função ativada.

Após concluído esse processo, você poderá acessar as informações detalhadas e consolidadas de todos os modelos do seu projeto, incluindo códigos, documentação, linhagens e muito mais, por meio das guias principais em Documentation > Open Docs.

>>> Usuários

Os tipos e a quantidade de licenças dependem do plano contratado, mas, em geral, existem três tipos de licenças:

Developer: Os usuários com essa licença têm acesso completo à plataforma, incluindo funcionalidades de desenvolvimento e deploy. Com ela, é possível gerenciar a conta, criar jobs, acessar a API e muito mais. No plano Team que utilizamos, temos direito a apenas uma conta de desenvolvedor. No entanto, como só usamos para gerenciar o agendamento dos Jobs, isso não interfere em nossas atividades diárias.
Read-Only: Usuários com acesso de leitura têm uma visão mais restrita na plataforma, incluindo uma visualização mais superficial do histórico de execuções, com acesso limitado aos detalhes. Ainda assim, eles conseguem visualizar toda a documentação e receber notificações dos Jobs. Atualmente, temos acesso a cinco contas com esse tipo de licença no plano Team.
IT: Recentemente, foi lançada a licença IT, que não utilizamos. Nesse tipo de licença, o usuário tem acesso apenas para gerenciar usuários, grupos e licenças, além de receber notificações dos Jobs. Ela está disponível apenas nos planos Team e Enterprise.

Para gerenciar os usuários, acesse: Settings > Account Settings > Users.

>>> Notificação

Você pode configurar o DBT Cloud para receber notificações via email ou canal no Slack sempre que um job for concluído com sucesso, falhar ou for cancelado.

Email: Para configurar notificações por email, acesse Settings > Notification Settings > Email Notifications. Escolha o endereço de email do usuário para o qual você deseja enviar notificações e, em seguida, defina o tipo de alerta desejado para cada job.

Slack: Se preferir notificações via Slack, siga estas etapas: Settings> Profile Settings > Personal Profile > Linked Accounts > Slack. Lembre-se de que é necessário ter uma conta de administrador no Slack para realizar essa primeira operação.
Após vincular sua conta, vá para Notification Settings > Slack Notifications e selecione o canal e os alertas que deseja receber. É importante observar que você pode usar apenas um canal do Slack para todas as notificações.
Aqui está um exemplo de alerta gerado:

>>> API

Para os planos Team e Enterprise, o DBT Cloud oferece o acesso a uma API, que permite extrair dados históricos de execução, documentação e muito mais. Além disso, você pode administrar seu ambiente, configurar Jobs, iniciar e cancelar execuções, entre outras funções. Para explorar as possibilidades de uso com mais detalhes, recomendo consultar o site oficial deles: dbt Cloud Administrative API.

Nós utilizávamos a API para criar uma conexão entre diferentes pipelines dependentes. No entanto, atualmente, a utilizamos principalmente para aprimorar a governança em nosso ambiente. Graças à coleta do arquivo “manifest.json”, conseguimos criar um catálogo e rastreamento de nossos modelos no DBT e vinculá-los às tabelas catálogo disponíveis no Redshift. Em breve, compartilharei materiais relacionados ao nosso progresso nesse projeto.

Mas antes de iniciar o trabalho com a API administrativa, será necessário criar um token dentro da plataforma, seguindo o caminho: Settings > Account Settings > Service Tokens > New Token.

>>> IDE

A funcionalidade de Integrated Development Environment (IDE) é uma interface web que permite a construção, teste e versionamento de projetos DBT dentro da plataforma do DBT Cloud. Trata-se de uma ferramenta abrangente e altamente eficaz para o desenvolvimento de modelagens, embora seja importante notar que requer licenças do tipo Developer. Dependendo do número de usuários que necessitam dessa licença, os custos da ferramenta podem aumentar consideravelmente.

Como demonstrado na primeira etapa deste guia, nós desenvolvemos os modelos localmente e utilizamos o DBT Cloud principalmente para a orquestração de projetos. No entanto, para aqueles que desejam explorar mais a fundo o uso da IDE, recomendo que conheçam melhor essa funcionalidade.

Como ponto de partida, sugiro consultar a documentação oficial do DBT, que é bastante abrangente: About the dbt Cloud IDE.

Na primeira parte deste guia, forneci uma visão geral da ferramenta e expliquei como configurá-la, conforme detalhado em “Desvendando a Arquitetura e Configuração Inicial”.

Na segunda parte, explorei de forma mais aprofundada as pastas e os principais arquivos necessários para a construção de um projeto no DBT, conforme apresentado em “Organizando as Pastas do Projeto”.

Nesta terceira e última parte, abordo o DBT Cloud, o orquestrador atual do nosso projeto. É uma ferramenta notável e completa, que tem evoluído rapidamente nos últimos meses. Embora estejamos considerando a possibilidade de migrar para outra ferramenta como forma de unificar nossos ambientes, recomendo que todos conheçam um pouco mais sobre as funcionalidades do DBT Cloud. Durante esses primeiros anos de utilização do DBT, ele desempenhou um papel fundamental para nosso time.

Por fim, espero que tenha sido útil para aqueles que têm interesse em uma solução governada de transformação de dados ou para aqueles que desejam aprimorar seus conhecimentos nesta ferramenta. O DBT é uma ferramenta incrível que transformou a interação diária entre nossa equipe de dados e trouxe maior governança aos conjuntos de dados criados. Se tiver alguma dúvida ou sugestão, não hesite em entrar em contato comigo pelo Linkedin.

English version: https://medium.com/@alice_thomaz/8ed22cc2e492