ELT e a stack de dados na Salvy.

Na Salvy, desde os nossos primeiros dias, buscamos implementar uma solução robusta para acompanhar as nossas métricas mas que ao mesmo tempo fizesse sentido para o nosso tamanho. Procurando entender um pouco mais sobre as diferentes formas de se implementar uma stack de dados eu conheci a abordagem ELT e quero nesse post compartilhar como essa abordagem tem ajudado a gente a atender as diferentes demandas de negócio mantendo nosso time enxuto e sem gastar muito ;)

O Que é ELT?

ELT (Extract, Load, Transform) é uma forma de processamento de dados que prioriza o carregamento de dados brutos diretamente em um data warehouse (local de armazenamento de todos os dados de diferentes sistemas), antes de qualquer transformação. Diferente do método mais tradicional chamado ETL, onde a transformação ocorre antes do carregamento, o ELT aproveita a capacidade de processamento dos data warehouses para transformar os dados após o carregamento. Isso simplifica muito o pipeline de dados.

A principal vantagem que tivemos com ELT foi a a simplificação na etapa de transformação dos dados. Uma vez que todos os dados estão disponíveis no data warehouse, temos que nos preocupar apenas com um único processo de transformação de dados. Utilizando uma só ferramenta, o dbt, que entraremos em mais detalhes no próximo tópico.

A Stack de Dados da Salvy

Mas então, quais são as ferramentas que permitem a gente implementar essa abordagem ELT? Vamos dar uma olhada na nossa stack de dados.

Meltano: Uma iniciativa derivada de uma plataforma de dados interna do GitLab, que foca em soluções open-source e em uma configuração declarativa. O Meltano nos permite manter toda a configuração de nossas pipelines em código, facilitando o compartilhamento de conhecimento e as práticas que usamos normalmente nos nossos dias de desenvolvedores. Além disso, ele possui um hub com diferentes extratores open-source que nos permite extrair dados de diferentes fontes, como Stripe, HubSpot, Google Analytics, entre outros, e carregá-los diretamente no nosso data warehouse. Caso o extrator que precisamos não esteja disponível, podemos criar um extrator customizado em Python utilizando a SDK do Meltano.

dbt: O dbt é uma ferramenta incrível que nos permite criar modelos de dados em SQL, versioná-los no GIT e executá-los em um ambiente de CI/CD. Usamos dbt para criar modelos de dados que refletem as métricas críticas para nosso negócio, como receita recorrente, novas vendas, churn, entre outros. Além disso, dbt nos permite documentar nossos modelos de dados (algo que precisamos melhorar muito ainda) e criar testes que garantem a consistência das métricas calculadas. Por exemplo, o teste abaixo é um teste que garante que nossas métricas de receita recorrente no final do mês é sempre equivalente a soma da receita de inicío do mês mais as receitas de novas vendas, upsell, churn e downsell.

WITH summary_with_difference AS (
    SELECT
        cms.*,
        cms.beginning_of_period_amount + cms.upsell + cms.recovered + cms.new_sales + cms.downsell + cms.churn - cms.end_of_period_amount AS difference
    FROM
        {{ ref('company_mrr_summary') }}
        cms
)
SELECT
    *
FROM
    summary_with_difference
WHERE
    difference != 0

Você pode ter se estranhado com a sintaxe diferente do SQL acima, o {{ ref() }} é uma sintaxe do dbt que permite que a gente referencie outros modelos de dados criados por ele também. Dessa forma, ele consegue montar um grafo de dependências entre os diferentes modelos e executá-los na ordem correta.

No dbt, adotamos uma estrutura organizada em camadas para nossos modelos de dados, que se dividem em raw, staging e analytics. Na camada raw, temos os dados em sua forma original, importados diretamente via Meltano. A camada staging abriga os dados já processados e preparados para análise, servindo como um intermediário entre a coleta e o uso final dos dados. Por fim, na camada analytics, concentramos os modelos que representam as métricas mais importantes para o negócio

Postgres: Um dos banco de dados mais comuns para aplicações web, Postgres é a mesma tecnologia de dados que usamos para nossa aplicação e também data warehouse. Usando a mesma tecnologia diminuimos a carga cognitiva ao lidar com os sistemas e conseguimos compartilhar mais conhecimento interno. Para o nosso tamanho hoje o Postgres tem nos atendido bem, mas a medida que nosso volume de dados aumenta, tanto o meltano quando o dbt possuem suporte a outros data warehouses como o Redshift, Snowflake ou BigQuery.

ECS: Para orquestrar e executar nossas tarefas de dados sem nos preocuparmos com a gestão de servidores, utilizamos o ECS com instâncias Fargate.

CloudWatch: Para agendar e monitorar as tarefas de dados executadas pelo ECS, utilizamos o CloudWatch. Ele funciona também como um sistema de cron, agendando a execução das pipelines em tarefas do ECS.

Metabase: Para visualização de dados e suporte à tomada de decisão, o Metabase é a ferramenta de escolha. Ele nos permite criar dashboards interativos e relatórios. Ele funciona como uma interface para os dados que todos conseguem utilizar, sem precisar de muito conhecimento técnico. Normalmente começamos a criar os relatórios e dashboards no Metabase e depois de um tempo, quando percebemos que a demanda por um relatório é constante, transformamos ele em um modelo de dados no dbt.

Aprendizados e Desafios

Mas claro que nem tudo são flores. Caso você esteja pensando em implementar uma stack de dados similar, aqui vão alguns aprendizados e desafios que tivemos ao longo do caminho.

• Documentação: A documentação dos modelos de dados é algo que ainda precisamos melhorar muito. O dbt nos permite documentar os modelos de dados em Markdown, mas ainda não temos uma prática de documentação consistente. A documentação é essencial para que todos na empresa possam entender como as métricas são calculadas e confiar nos dados que estão sendo apresentados.
• CI: A implementação de um processo de CI não é trivial, principalmente porque o dbt exige uma conexão de dados com o data warehouse para compilar os modelos, dependendo da sua infraestrutura, isso pode ser um desafio.
• Self-Hosted: Como toda solução self-hosted, a manutenção e atualização das ferramentas é uma preocupação constante. Ainda não tivemos problemas sérios, mas é algo que precisamos estar sempre atentos.

Conclusão

Aqui na Salvy, acreditamos que a abordagem ELT tem sido bastante valiosa na nossa implementação da Stack de dados. A simplicidade e a eficiência que ela nos proporciona é sem igual. Se você tiver alguma dúvida ou sugestão, não hesite em entrar em contato comigo. Adoraria ouvir sua opinião e como funciona a Stack de dados na sua empresa.