DATA ENGINEERING

Estruturando um ambiente de Self-Service BI com DBT — Parte 2

Como estamos estruturando-o aqui na Afya

Leandro Carnevali

Published in

afya

7 min readMar 8, 2023

Se ainda não leu a parte 1, recomendo iniciar por lá e depois voltar aqui =)

Neste texto, vamos esclarecer o motivo pelo qual optamos por utilizar o DBT como a principal ferramenta para transformação de dados para o Self-Service BI aqui na Afya. Além disso, como estamos organizando o nosso ambiente de desenvolvimento e produção.

DBT

Para aqueles que ainda não conhecem o DBT, tentarei explicar brevemente como funciona esta ferramenta. Em seu site ela é descrita como uma ferramenta de transformação de dados que permite que analistas e engenheiros de dados transformem, testem e documentem seus datasets com mais eficiência, além de oferecer uma integração nativa aos principais provedores de nuvem.

É possível perceber pela arquitetura de um Data Lake, mostrada na figura abaixo, que o DBT atua basicamente na camada Modeled onde são feitas as transformações dos dados. O que o diferencia perante outras ferramentas de transformação é a capacidade de escalar o processo de desenvolvimento de modelos através do deploy contínuo, além de uma interface muito intuitiva, e a utilização de duas linguagens muito acessíveis como Jinja e SQL. Recentemente passou também a utilizar a linguagem Python.

Além da facilidade em se criar modelos, as questões de Governança de Dados, que como mencionado no artigo anterior, é pré-requisito para um ambiente de Self-Service BI. A ferramenta apresenta excelentes recursos relacionadas à linhagem e catálogo de dados, tornando todo o processos de análise muito mais simples para quem está desenvolvendo. Para quem deseja personalizar os metadados, também há a opção de fazer isso através de pacotes disponíveis no DBT Hub.

Atualmente existem duas versão do DBT:

DBT Core: Plataforma Open Source no qual é possível fazer o desenvolvimento e as transformações localmente no computador.

DBT Cloud: Ambiente hospedado na nuvem pela Dbt Labs, responsável pela orquestração dos jobs do DBT e consulta das documentações.

Caso tenha ficado interessado em se aprofundar mais nesta ótima ferramenta, recomendo acessar a sua página de cursos que é gratuito. Os treinamentos estão em inglês com legendas no mesmo idioma.

Após essa contextualização sobre o DBT, chegamos à parte mais técnica (e divertida!) do texto. Explicarei como estruturamos os nossos ambientes de desenvolvimento e produção aqui na Afya.

Como dito, o DBT tem as duas versões, a Core e a Cloud. Na Afya usamos a versão Core para desenvolvimento, que fica instalada em um contêiner para manter o ambiente de desenvolvimento igual para todos. Apesar de estarmos caminhando para uma imagem docker já pronta, mostrarei o passo a passo de como fazemos para criar o nosso ambiente de desenvolvimento.

1. Instalação dos softwares

Fazer o download e instalação do Visual Studio Code;
Fazer o download e instalação do Docker Desktop (computadores Windows precisam do WSL instalado).

2. Preparação do ambiente

Criamos uma pasta dbt-config e copiamos um diretório que já contém o Dockerfile pronto e o diretório oculto .dbt com o arquivo profiles.yml pré-preenchido.

Dockerfile

FROM ubuntu:20.04

COPY ./.dbt /root/.dbt

RUN apt update && apt upgrade -y
RUN apt install telnet -y
RUN apt install vim -y
RUN apt install git -y
RUN apt install python3 -y
RUN apt install python3-pip -y
RUN pip install dbt-core==1.2.2 dbt-redshift==1.2.1

profiles.yml

config:
  partial_parse: false

pebmed: 
 target: dev 
 outputs: 
   dev: 
       type: redshift 
       host: endereço_do_banco
       user: seu_usuario_redshift 
       pass: sua_senha_redshift 
       port: porta 
       dbname: banco_de_dados 
       schema: dbt_eng 
       threads: 4 
       keepalives_idle: 0 # default 0, indicating the system default 
       # search_path: public # optional, not recommended
   prod: 
       type: redshift 
       host: endereço_do_banco
       pass: seu_usuario_redshift 
       port: porta 
       dbname: banco_de_dados 
       schema: dbt_prod 
       threads: 4

Substituímos as informações no arquivo profiles.yml para incluir os dados do Data Warehouse (DW), que no nosso caso está no AWS Redshift, assim como, os nossos dados de acesso.

Esta configuração difere do padrão do DBT para evitarmos criar schemas no DW baseados no usuário, os nossos schemas são baseados no perfil e ambiente que está utilizando. Hoje temos os seguintes schemas:

dbt_eng: Ambiente de desenvolvimento e testes da engenharia de dados.
dbt_analise: Ambiente de desenvolvimento e testes da análise de dados.
dbt_prod: Ambiente de produção utilizado pelo DBT Cloud.

3. Criação e configuração do contêiner

No diretório dbt-config na máquina local, executamos o comando abaixo. Para máquinas Windows usamos o Powershell e no Mac o Terminal.

 docker build -t ubuntu:20.04 .

Uma vez com a imagem pronta, agora é só subir o contêiner.

docker run --name dbt_local -it ubuntu:20.04

Agora que temos o contêiner pronto, entramos na pasta root e fazemos o git clone do repositório. Ele é o mesmo que você cadastrou no DBT Cloud, para mais informações acesse este link.

cd root
git clone https://<seu-repositorio-do-dbt>

4. Configuração final do DBT Core

Agora com o DBT Core instalado e o arquivo profile.yml preenchido, instalaremos os pacotes contidos no arquivo packages.yml, no meu caso está instalando o pacote calogica/dbt_expectations através do comando abaixo:

dbt deps

Para verificar se tudo está funcionando vamos executar o comando dbt seed.

5. Configurando o VS Code

Considerando que o VS Code já foi instalado na máquina, instalaremos as extensões necessárias para podermos conectar diretamente no contêiner. A extensão WSL somente é necessária para as máquinas Windows.

Após as instalações, agora é só conectar o contêiner pelo VS Code.

Por fim, abrimos um terminal e executamos os comandos abaixo para instalar as extensões que utilizamos para desenvolver no DBT através do VS Code, lembrando que agora estamos dentro do contêiner.

code --install-extension bastienboutonnet.vscode-dbt && 
code --install-extension donjayamanne.githistory && 
code --install-extension dorzey.vscode-dbt-language && 
code --install-extension eamodio.gitlens 

code --install-extension foldager.dbt-shortcuts &&
code --install-extension innoverio.vscode-dbt-power-user && 
code --install-extension samuelcolvin.jinjahtml && 
code --install-extension mhutchie.git-graph && 
code --install-extension PKief.material-icon-theme

Agora estamos com o nosso ambiente de desenvolvimento totalmente configurado e pronto para uso!

6. Ajustando o ambiente

Com as extensões do VS Code já instaladas, vamos para a etapa final de preparação do nosso ambiente de desenvolvimento, modificando algumas configurações de usuário. Apertando o comando Ctrl+Shift+P (Command+Shift+P) no VS Code, selecionaremos a opção Preferences: Open User Settings (JSON).

Um vez aberto o arquivo settings.json, fazemos as alterações conforme abaixo.

{ 
    "workbench.iconTheme": "material-icon-theme", 
    "workbench.colorTheme": "Bluloco Dark", 
    "editor.minimap.enabled": false, 
    "launch": { 
        "configurations": [], 
        "compounds": [] 
    }, "files.associations": { 
        "*.sql": "jinja-sql" 
    }, 
    "editor.rulers": [ 
    110 
    ], 
    "editor.tabSize": 2 
}

Mas e o ambiente de produção???

O ambiente de produção nada mais é que o nosso DBT Cloud. Que está configurado para rodar com o schema dbt_prod, no qual somente o usuário do DBT tem permissão para modificações, justamente porque precisa ser o owner das tabelas e depois configuramos no nosso projeto uma macro que faz as liberações de acesso às tabelas.

O DBT Cloud está apto a rodar basicamente todos os scripts que estão habilitados na branch Master no nosso repositório do Gitlab. E falando do repositório, depois de muitas discussões, organizamos o mesmo com a seguinte estrutura.

Que de forma resumida, o repositório se divide em 3 grandes categorias:

staging: Tabelas com corte temporal para apoio em cargas incrementais.
sources: Modelagens fontes no qual fazemos a higienização dos dados e os estruturamos, são de responsabilidade da Engenharia.
marts: Modelagens analíticas, onde fazemos os dados virarem informações, são de responsabilidade do time de Análise/Ciência de Dados.

Dessa maneira, o nosso Data Warehouse está estruturado de tal forma que facilita a gestão dos dados.

Espero que tenham gostado do material e caso tenham alguma sugestão, peço que entrem em contato comigo pelo LinkedIn. Se você deseja fazer parte do maior ecossistema médico do país, com as mais avançadas tecnologias de dados e em um ambiente propício à inovação, vem pra Afya!

Aproveito para divulgar que, neste exato momento em que escrevo, temos duas vagas para engenheiros de dados disponíveis. Se despertou o interesse, então basta acessar o link e enviar a sua candidatura. =)

Não posso terminar sem fazer uma homenagem ao meu time de engenharia de dados, pois sem eles nada disto teria sido possível e no qual todo o material original foi gerado por eles. Muito obrigado, Alice, John, Ana Oliveira (Aninha), Ana Xavier (Anita) e Felipe, isso é resultado do trabalho de vocês!!! Obrigado mestre Bruno por me dar a oportunidade de fazer parte deste time!!!

No próximo artigo trarei como fazemos o tracking das nossas aplicações através do Snowplow, no qual só ele é responsável por gerar aproximadamente 150 milhões de registros por mês no nosso Lake!!!