Simplificando a Transformação de Dados no Redshift: Uma Abordagem com DBT e Airflow

Vamos transformar e modelar dados armazenados no Redshift com uma abordagem simples e eficaz através do uso do dbt e Airflow. Para que complicar se podemos simplificar?

Neste artigo iremos trabalhar com o seguinte cenário:

Existem dados armazenados em um Data Warehouse (DW) que se encontra no Amazon Redshift.
Os dados são sobre vendas de produtos de um e-commerce e nos diz muito sobre o comportamento dos clientes dessa loja.
O DW ainda não está modelado para uma aplicação analítica, existe apenas uma cópia de como eles vieram da origem.

Precisamos transformar os dados e modelar o DW para que análises de negócio sejam realizadas.

Os dados utilizados para este artigo são abertos, se tratam de vendas no site da Amazon e podem ser encontrados no Kaggle, neste link.

O código completo deste projeto também pode ser encontrado no meu GitHub:

GitHub - cicerojmm/dataTransformationDbtAirflow: Transformação e Modelagem de Dados com DBT…

Um pouco sobre a solução

Para resolver o problema apresentado, temos o seguinte desenho de arquitetura com as tecnologias e ferramentas que serão utilizadas:

Para quem não está familiarizado com as ferramentas que serão utilizadas, vou deixar uma breve explicação sobre elas a seguir.

Caso já tenha conhecimento, recomendo ir para o próximo tópico: Modelagem dos Dados.

Sobre o dbt

O dbt (Data Build Tool) é uma ferramenta moderna para a transformação de dados dentro do cenário de DW ou Lakehouse. Ele permite que engenheiros, cientistas e analistas de dados manipulem os dados apenas com a linguagem SQL.

O dbt possui duas versões:

• dbt-core: é a versão open-source, mantida pela comunidade e pode ser utilizada livremente.
• dbt-cloud: é a versão paga e gerenciada em formato SaaS, que pode ser utilizada em cloud com uma assinatura mensal.

Sobre o Airflow e Cosmos

O Airflow é a ferramenta para orquestração de workflows de dados mais utilizada e conhecida. Ele permite a construção de pipelines com agendamentos e monitoramento de forma eficiente.

E aproveitamento que estamos falando de Airflow, vamos falar sobre o Cosmos.

O Cosmos é uma biblioteca para o Airflow construída pela Astronomer, possui o objetivo de simplificar a execução de projetos dbt com o Airflow.

Com o Cosmos é possível executar um projeto dbt através de um grupo de tasks do Airflow, que são reconhecidas de forma automática. Cada modelo dbt se transforma em uma tarefa/grupo do Airflow, executando as transformações e testes.

Amazon Redshift

O Redshift é um serviço de DW gerenciado em nuvem. Ele é projetado para análise de dados e consultas em grandes volumes de informações.

Hoje em dia o Redshift possui uma versão gerenciada e outra serverless.

É uma ferramenta que vem se transformando em uma grande plataforma de dados.

Modelagem dos Dados

Para melhor entendimento da solução que iremos adotar neste artigo, o desenho a seguir possui o diagrama de modelagem dos dados para a construção do DW.

Como mencionado anteriormente, existe uma tabela onde os dados estão armazenados sem transformação (raw data), que é a sales.

A tabela sales também servirá de staging area para processamento dos dados e criação das demais tabelas.

Na modelagem do DW, existem três tabelas de dimensão:

• dim_product: irá conter os dados dos produtos da loja.
• dim_user: contém dados dos usuários que são clientes da loja.
• dim_rating: contém todas as avaliações dos produtos feitas pelos clientes da loja.

E duas tabelas fatos:

• fact_product_rating: contém os dados para extrair métricas de avaliação dos produtos por usuário, ex: quais são os top produtos mais bem avaliados.
• fact_sales_category: contém os dados para extrair métricas das vendas por categorias dos produtos, ex: quais são as top categorias com mais lucro para a loja.

Obs: lembrando que o cenário do artigo é hipotético, não quer dizer que é a melhor modelagem para os dados, é apenas para fins didáticos 😉

Agora é Show Code

A seguir é o momento de explorar na prática a construção do projeto dbt, a DAG no Airflow e os resultados das transformações dos dados no Redshift.

1. Projeto com o dbt

Nesta seção o foco é na estrutura, configuração e códigos SQL das transformações dos dados que fazem parte do projeto.

Para iniciar um projeto dbt é necessário instalar o pacote Python e utilizar a CLI.

• Para instalar o pacote do dbt:

$ pip install dbt-core==1.4.9

• Para iniciar um projeto:

$ dbt init <nome_projeto>

Um projeto dbt por padrão já possui algumas pastas e configurações.

A seguir temos a estrutura com todas as pastas e arquivos criados para o nosso cenário aqui:

-- dbt_project/
  |______ dbt_project.yml
  |______ analyses/
  |______ macros/
  |______ models/
  |   |   |______ dimensions/
  |   |   |      |______ dim_product.sql
  |   |   |      |______ dim_rating.sql
  |   |   |      |______ dim_user.sql
  |   |   |______ facts/
  |   |   |      |______ fact_product_rating.sql
  |   |   |      |______ fact_sales_category.sql
  |   |   |______ staging/
  |   |   |      |______ stg_sales_eph.sql
  |   |   |      |______ staging.yml
  |______ seeds/
  |______ snapshots/
  |______ tests/

O trabalho basicamente será feito dentro da pasta models.

O próximo passo é analisar cada código SQL de transformação.

Tabela de Staging

Como mencionado anteriormente, a tabela de staging é a própria tabela sales que já existe no DW, basicamente é carregar toda a tabela em memória.

Gostaria de destacar três pontos:

• No dbt existem duas formas de materializar tabelas: ephemeral que é uma tabela “virtual” carregada apenas em memória, não será persistida no banco de dados e a table, que é um tabela que será persistida no DW.
• O segundo ponto é sobre processamento, todo ele é realizado no banco de origem, neste caso no Redshift, assim quando falo que a tabela será carregada em memória, se trata da memória do Redshift.
• As tabelas, sejam elas ephemeral ou table, são criadas com o nome do arquivo SQL.

Tabelas de Dimensões

O momento agora é de analisar o código SQL das três dimensões que serão criadas. As três serão materializadas como table.

A primeira é a dim_product, que contém os dados dos produtos da loja com base na tabela sales.

A segunda é a dim_rating , que contém as avaliações dos produtos pelos compradores.

A terceira e última é a dim_user, que contém os dados dos compradores da loja.

Com o código das dimensões finalizado, agora é o momento das tabelas fatos.

Tabelas de Fatos

As duas tabelas fatos já são um pouco mais complexas, pois possuem métricas do negócio, contendo agregações e relacionamento com as dimensões.

A seguir o código da fato fact_product_rating, que faz relacionamento com as dimensões de produtos e avaliações, calculando as médias das notas de avaliações agrupadas por produtos.

A segunda fato é a fact_sales_category, que faz o agrupamento das categorias dos produtos e calcula o faturamento total. Os relacionamentos são com as dimensões de usuário e categoria.

Com a modelagem dos dados pronta, é o momento de finalizar o projeto, fazendo tudo isso executar com o Airflow.

2. Construção da DAG no Airflow

Conforme mencionado anteriormente, para este projeto, iremos utilizar a biblioteca Cosmos, que traz uma integração muito legal para projetos com o dbt e Airflow.

Para isso iremos seguir alguns passos:

1. Instalar as dependências necessárias no ambiente do Airflow para executar o projeto.
2. Configurar uma conexão do Airflow (connection) para o Redshift. Isso é uma coisa interessante do Cosmos, não precisamos configurar a conexão com o banco no projeto dbt, pode-se passar como parâmetro através do Airflow.
3. E por fim, construir as tasks com o DbtTaskGroup do Cosmos.

Conforme os passos mencionados, a seguir o arquivo requirements.txt com as dependências necessárias que devem ser instaladas no servidor do Airflow:

dbt-core==1.4.9
dbt-redshift==1.4.0
astronomer-cosmos==1.0.5

A configuração da conexão na UI do Airflow para o Redshift ficará da seguinte forma:

É agora o código completo da DAG:

Gostaria de destacar o trecho do código a seguir e analisá-lo posteriormente:

transform_data = DbtTaskGroup(
        group_id="transform_data",
        project_config=ProjectConfig(DBT_PROJECT_PATH),
        profile_config=profile_config,
        default_args={"retries": 2},
    )

• O DbtTaskGroup irá ler o diretório onde se encontra o projeto dbt. No código anterior, o caminho é indicado pela variável DBT_PROJECT_PATH, após isso ele constrói as tasks do Airflow conforme os modelos criados no dbt, que no nosso caso são: a staging, dimensões e tabelas fatos.

ROOT_PATH = '/opt/airflow/dags/dbt'
DBT_PROJECT_PATH = f"{ROOT_PATH}/sales_dw"

Obs: importante destacar, que neste caso o projeto dbt precisa estar no mesmo servidor do Airflow, conforme o caminho definido acima.

• O ProfileConfig é o objeto que configura a conexão. Basicamente é a connection do Airflow e alguns parâmetros que podem ser passados, como o schema do banco de dados.

CONNECTION_ID = "redshift_default"
DB_NAME = "amazon_sales"
SCHEMA_NAME = "public"

profile_config = ProfileConfig(
    profile_name="sales_dw",
    target_name="dev",
    profile_mapping=RedshiftUserPasswordProfileMapping(
        conn_id=CONNECTION_ID,
        profile_args={"schema": SCHEMA_NAME},
    )
)

A construção da DAG é apenas isso, muito simples, não é mesmo?!

A seguir temos a imagem de como ficará as tasks que são construídas automaticamente pelo Cosmos na UI do Airflow:

Podemos ver na imagem a seguir as dependências que existem para a construção da fact_product_rating, que são definidas pelos SQL dos modelos.

Também em destaque a seguir, as dependências da construção da fact_sales_category:

3. Por fim… Resultados no Redshift

Ao executar a DAG e construir os modelos configurados no dbt, alcançamos o seguinte resultado no Redshift:

Observamos que existe a tabela sales, que são os dados raw, utilizados como staging e as tabelas de dimensões e fatos materializadas.

Realizando uma consulta na tabela fact_sales_category, teremos o seguinte resultado:

Conclusão

O dbt é uma ótima ferramenta para realizar processamento e modelagem dos dados, fornece praticidade e agilidade em projetos de dados.

Um dos pontos fortes é criar automaticamente as dependências entre os modelos, o que nos faz ter produtividade, pois precisamos “apenas” escrever as nossas transformações, que possui uma grande vantagem de ser em SQL.

A biblioteca Cosmos da Astronomer também é uma grande aliada em fazer essa orquestração do dbt com o Airflow, simplifica e agiliza muito, dando uma visibilidade sobre os modelos do dbt e suas execuções.

Airflow + dbt + Cosmos = Combinação Perfeita ❤

Se você procura uma stack simples, eficiente e com baixo custo, a solução apresentada neste artigo pode ser eficiente e ideal para o seu cenário.

Logo irei escrever mais artigos sobre o dbt, fique ligado!

Você ainda quer ler sobre um outro cenário de utilização do dbt? Se liga neste artigo: Transformação de dados com DBT e AWS Athena

Também siga-me aqui e nas outras redes sociais:

LinkedIn: https://www.linkedin.com/in/cicero-moura/
Github: https://github.com/cicerojmm
Mais conteúdos: https://linktr.ee/cicerojmm