Então na Arquitetura acima temos as seguintes tecnologias:

• Toda Stack em Containers.
• Apache Hop Para ingestão dos dados.
• DBT para Transformação e validação dos dados.
• Postgres para DW.
• Jenkins como CI/CD e Orquestração.

Agora imagine o seguinte cenário: seu gerente prefere uma solução em nuvem. Em vez de armazenar os dados no PostgreSQL, você os coloca no armazenamento da cloud escolhida.

Se for Google Cloud, usamos o Hop para gravar no Cloud Storage e o dbt atua sobre o BigQuery.

Se for AWS, gravamos no S3 e podemos usar Athena ou Redshift.

Se for Snowflake ou Databricks, a stack continua a mesma — já que ambas se integram nativamente com os storages das três principais clouds.

Todo o restante da Stack não mudaria.

Exemplo prático com AWS

Para começar, usamos o Apache Hop para ler dados de um banco PostgreSQL e gravá-los no S3, em formato Parquet.

Cada tabela possui sua respectiva pasta e arquivos:

Com os dados no S3, agora já conseguimos consultá-los usando o Athena, que é um serviço serverless da AWS que permite consultas SQL diretamente sobre arquivos no S3.

Tanto Athena quanto Redshift possuem integração nativa com dbt.

Veja abaixo os dados sendo consultados no Athena:

Conclusão

Em vez de utilizar o PostgreSQL, conseguimos criar um Data Lake na AWS, mantendo exatamente a mesma stack do Data Speed.

A grande vantagem é que nos preocupamos apenas com o processamento. O armazenamento e a consulta são administrados pela AWS.

E o que mais encarece um projeto na nuvem geralmente é o processamento contínuo. Neste caso, você só paga pelo que rodar — e se estiver usando máquinas locais, nem esse custo terá.

Muito Obrigado.

Rafael Arruda

Na pasta models, podemos inserir todos os arquivos diretamente nela ou organizá-los em subpastas. Independentemente da estrutura adotada, é possível criar um arquivo .yml de documentação para cada subpasta, facilitando a separação por domínio ou área. Caso prefira, também é válido manter um único arquivo .yml na raiz da pasta models, centralizando a documentação de todos os modelos.

Após essa organização, ao editar o arquivo .yml, podemos indicar os modelos presentes no projeto, referindo-nos diretamente a cada arquivo .sql da pasta models. Em seguida, é possível documentar o nome das tabelas, suas colunas e, quando necessário, definir testes de integridade como not_null, unique, accepted_values e relationships.

Como podemos ver na imagem acima, primeiro definimos o nome da tabela — que deve ser o mesmo nome do arquivo .sql (sem a extensão) — e em seguida adicionamos a descrição da tabela. Essa descrição já serve como documentação e pode indicar, por exemplo, a área de negócio à qual ela pertence (como Financeiro, RH, Logística, etc.), os tipos de dados que ela armazena e outras informações relevantes sobre seu uso.

Logo abaixo, passamos a descrever as colunas da tabela, preenchendo uma a uma. Para cada coluna, também é possível adicionar uma descrição e definir testes automatizados. Entre os testes mais comuns estão:

• not_null: garante que a coluna não contenha valores nulos
• Unique: assegura que os valores sejam únicos na coluna
• accepted_values: restringe os valores possíveis a uma lista predefinida: values: [‘PF’, ‘PJ’]
• Relationship: verifica se a coluna está relacionada corretamente a outra tabela, como uma chave estrangeira: to: ref(‘dim_loja’) field: id_loja

A opção not_null faz com que o dbt verifique se existe algum valor nulo em uma coluna que deve conter obrigatoriamente dados, ajudando a garantir a integridade da informação.

A opção unique garante que todos os valores da coluna sejam únicos, ou seja, que não haja repetições — algo essencial em colunas que representam chaves primárias, por exemplo.

A opção accepted_values permite definir uma lista de valores válidos para a coluna, o que é especialmente útil para capturar possíveis erros de entrada vindos da fonte de dados, como valores inesperados ou fora do padrão.

A opção relationships é utilizada quando um modelo faz referência a outro modelo. Com ela, o dbt verifica se todos os valores da coluna referenciada realmente existem no modelo de destino, funcionando como uma verificação de integridade referencial — semelhante a uma chave estrangeira em bancos de dados relacionais.

Depois de definir os testes em seus modelos, você pode executá-los com o comando: dbt test –select silver.ft_venda, você também pode executar os testes de toda uma pasta ao usar apenas o nome da pasta: (dbt test –select silver) Isso irá rodar todos os testes definidos dentro dos modelos presentes na pasta silver.

Com isso, podemos verificar que os testes de dados foram aplicados corretamente.

Após configurar todas essas etapas — que já contribuem significativamente para a documentação do projeto — podemos executar o comando dbt docs generate. Esse comando irá gerar um arquivo .json contendo todas as informações de modelos, colunas, descrições e testes definidos.

Em seguida, para visualizar essa documentação de forma interativa em um navegador, basta executar dbt docs serve –port 9000.

O parâmetro –port é opcional; se não for especificado, o dbt utilizará a porta padrão 8080. Após iniciar o servidor local, você poderá acessar a documentação do projeto diretamente pelo navegador.

Além disso, ao acessar a documentação gerada pelo dbt, podemos clicar no botão azul no canto inferior direito da tela para visualizar a linhagem dos dados (data lineage). Essa funcionalidade permite entender, de forma gráfica e interativa, como os modelos se conectam entre si — desde as fontes até as tabelas finais — facilitando o rastreamento de dependências e o entendimento do fluxo de dados no projeto.

Agora, nosso projeto conta com testes automatizados para validação dos dados, está totalmente documentado e ainda oferece a possibilidade de disponibilizar essa documentação de forma acessível a todos, diretamente pelo navegador.

Se quiser ter acesso a um conteúdo mais detalhado combinando DBT com outras ferramentas como Apache Hop, Jenkins, Git e Postgres, se inscreva no evento.

E com certeza os seus projetos irão mudar de patamar após este rico conteúdo.

Link Evento

Muito Obrigado.

E até o próximo artigo.

Ao utilizarmos uma infraestrutura de dados moderna, é comum realizarmos diversas transformações por meio de SQL, aproveitando a alta performance dos bancos de dados mencionados. No entanto, à medida que o projeto cresce, torna-se difícil manter o controle dos scripts, mesmo com os recursos nativos dessas plataformas. Além disso, a documentação dessas transformações tende a ser negligenciada ou difícil de manter, o que pode comprometer a governança e a escalabilidade do projeto.

Ao iniciarmos um projeto no dbt, temos a pasta models, onde podemos criar várias subpastas para organizar nossos modelos SQL. Essa estrutura modular facilita a manutenção e leitura do código, especialmente em projetos maiores com múltiplas áreas de negócio ou etapas de transformação.

Após termos nosso modelo desenvolvido, podemos começar a realizar a documentação do mesmo, e a melhor parte? A documentação fica na mesma pasta do model, em um arquivo .yml, no exemplo acima, fica no arquivo de dw.yml.

Como podemos ver neste arquivo, estou definindo o nome e a descrição da tabela, além de documentar o nome e a descrição de cada coluna. Também estou adicionando alguns testes de dados — como, por exemplo, na coluna id_venda — para garantir que os dados tenham o tipo e o retorno esperados durante a transformação.

Além disso, o dbt permite configurar múltiplas conexões no arquivo profiles.yml, conhecidas como targets. Isso significa que, com a adição de uma simples flag no comando de execução, é possível alternar o ambiente onde o script será executado, como entre produção, homologação ou desenvolvimento.

Se alterarmos o comando de execução de dbt run para dbt run –target dw_prod, o dbt utilizará a nova conexão definida no profiles.yml, criando automaticamente o schema correspondente (caso ainda não exista) e executando as transformações, incluindo a criação das tabelas no novo destino.

Isso nos permite separar ambientes como dev, homologação e produção, garantindo maior controle e segurança durante o ciclo de desenvolvimento. Além disso, como o dbt organiza as transformações em arquivos SQL dentro de um projeto estruturado, podemos versioná-lo em plataformas como GitHub ou GitLab.

Isso facilita o trabalho colaborativo entre desenvolvedores, promovendo revisões de código, controle de mudanças e aumento significativo da produtividade da equipe.

Ao finalizar o ciclo de desenvolvimento, podemos rodar o comando dbt docs generate, onde o dbt vai gerar a documentação do projeto com base nas nossas configurações. Logo depois, podemos usar o comando dbt docs serve, onde essa documentação vai ficar disponível pela porta 8080 (padrão) do navegador, podendo alterar a porta com o comando –port para não ter conflito com demais aplicações.

Também podemos ver a linhagem dos dados, para saber quais tabelas foram utilizadas para gerar a de destino como mostra na imagem abaixo.

Dessa forma, temos um projeto documentado e colaborativo.

Muito Obrigado.

Time Arruda Consulting

Nesse último sábado começou o nosso novo Treinamento: AirDBT – Modern Data Engineer.

Nesse Treinamento o foco é criarmos uma Modern Data Stack, seria muito mais fácil fornecemos uma imagem de um Servidor pronto e totalmente configurado, mas e após os curso, como os alunos irão conseguir replicar no projeto atual deles.

Temas abordados no 1º dia:

• O que é uma Stack Moderna de Dados.
• Criação da conta na Google Cloud Plataform.
• Criação de um servidor Linux na nuvem.
• Instalação do Docker.
• Subimos um Postgres no Docker, que será nossa fonte de dados no curso.
• Subimos o Airbyte, que será o responsável pela ingestão dos dados.
• Carregamos 70 tabelas no Bigquery, dados brutos.
• E claro sempre com hand-ons, se o aluno tem dúvida compartilhamos a tela e assim avançamos todos juntos.

Tudo isso num único dia? Isso mesmo pois além de termos conhecimento no dia a dia por conta dos diversos clientes que atendemos, temos uma didática já conhecida e referência no mercado de dados.

Quer conhecer maiores informações, sobre o Treinamento, só acessar o link abaixo:

https://airdbt.arrudaconsulting.com.br/

Próximo sábado tem mais 8 horas, com os dados carregados no Data Lake, iremos criar o DW com o DBT e no final iremos realizar a orquestração dos pipelines utilizando Apache Airflow.

E assim finalizamos a Arquitetura do projeto do zero.

Muito Obrigado.

Time Arruda Consulting.