Adeus ETL, boas-vindas ao ELT!

Até pouco tempo, era o processo de ETL (em português, extrair, transformar e carregar) o método mais utilizado nos projetos de dados. Hoje, no entanto, as empresas modernas partiram para outra alternativa, muito mais ágil, escalável, flexível e econômica, o ELT (em português, extrair, carregar e transformar).

Quer saber tudo sobre os motivos dessa transição e por que o ELT é a melhor opção para a sua empresa?

Siga com a leitura, porque vamos explicar tudo!

ELT: novas tecnologias para o armazenamento de dados

Nos últimos anos, muitas empresas passaram a se conscientizar sobre o valor gerado pelos dados nos negócios. A possibilidade de utilizar grandes volumes de informação para gerar insights tornou-se uma grande diferenciação competitiva - desde que o acesso aos dados seja feito de forma rápida e confiável.

As novas tecnologias da era do big data e da computação em nuvem oferecem um novo horizonte de possibilidades para o armazenamento de dados. Por isso, atualmente, ficou muito mais fácil criar estruturas de armazenamento acessíveis e escaláveis, como bancos de dados analíticos (data warehouses) e data lakes, o que, consequentemente, contribuiu para um grande aumento de projetos nesse segmento.

Contudo, apesar desse buzz recente, os projetos de data warehouse não são novidade. Pelo contrário, já vêm sendo aplicados desde o surgimento do conceito de DW, nos anos 1990, época em que as grandes promessas dos projetos de data warehouse não eram tão facilmente materializadas em consequência de barreiras, como:

• altos custos
• dificuldade de implementação e utilização
• complexidade de cada projeto
• dificuldade de gerar valor aos usuários finais

Isso não significa que não haja mais dificuldades e barreiras também, mas certamente, com as novas tecnologias, construir um data warehouse ficou muito mais simples e acessível.

A verdade sobre os projetos de data warehouse

Apesar de suas necessidades técnicas e estruturas próprias, o projeto de data warehouse é sobretudo um projeto de negócio. Sendo assim, deve ser idealizado sob a ótica do usuário final.

Portanto, acreditamos que a chave de um projeto de DW é justamente isso: aproximar o usuário de negócios dos dados. Ou seja, trazê-lo para o projeto de forma direta, não apenas após meses ou mesmo anos de implementação.

Na prática, isso reduz a complexidade do código do projeto e permite dar foco total no desenho e implementação das regras de negócio em uma linguagem padrão e facilmente entendida. E a parte de engenharia de software, como: versionamento, validação, testes e documentação, são integradas no projeto para garantir a qualidade dos dados na ponta.

O processo chave para um data warehouse eficiente: o ETL/ELT

Tradicionalmente, a etapa mais importante e demorada de projetos de dados é o chamado ETL (do inglês, extract, transform, load), que é a abordagem tradicional de transformação de dados.

Tanto em um projeto completo de data warehouse quanto em projetos de dados menos complexos, o ETL tende a seguir um padrão como o da figura abaixo.

Essas três etapas do ETL são atribuídas às equipes de data engineering, enquanto os analistas de negócios e cientistas de dados ficam limitados ao consumo desses dados na ponta.

Parece complexo, não é mesmo?

Por isso, vamos ajudar você a entender esse processo!

Na próxima seção, você verá que essa arquitetura gera uma série de dificuldades na implementação eficiente de projetos tradicionais de data warehouse, problemas que distanciam os usuários finais dos dados da criação das lógicas de negócio implementadas no ETL.

E, em seguida, vamos propor uma nova arquitetura de criação de data warehouses através do ELT, mostrando suas vantagens.

Por fim, vamos apresentar uma arquitetura prática que utilizamos em nossos projetos aqui da Indicium.

Vamos lá?

Os problemas de processos de ETL tradicionais

Para começar, já podemos adiantar que o ETL gera muitos problemas para os projetos de data warehouse. Uma reclamação constante é, por exemplo, o tempo elevado entre o início do projeto e a geração de valor para a empresa que, geralmente, é causada pelos seguintes fatores:

• o uso de uma abordagem “big bang”
• a complexidade no processo de ETL
• o distanciamento entre equipe técnica e stakeholders
• a falta de conscientização interna de analytics
• a dificuldade de contratar “super-homens”

Vamos entender melhor esses problemas?

O uso de uma abordagem “big bang”

Projetos de data warehouse - ou outras iniciativas abrangentes de analytics - permitem o acesso rápido e confiável aos dados armazenados e distribuídos nos diversos sistemas tradicionais das organizações.

No entanto, um DW é composto por muitos elementos, além de um banco de dados e um sistema ETL que alimenta esse database. Ele interage com:

• múltiplas unidades de negócio
• dados diferentes
• fontes  de dados distintas
• velocidades diversas
• volumes de dados crescentes

Ou seja, o DW não é um produto único, é uma coleção de projetos menores e complexos, que devem ser implementados e testados em ritmos distintos.

Tendo em vista suas grandes ramificações, a entrega de um projeto completo (que é o que chamamos de abordagem "big bang") tornou-se ultrapassada. Principalmente porque é muito mais complexa e demora a apresentar resultados tangíveis ao usuário final.

Hoje, num mundo cada vez mais acelerado, a implementação gradual de projetos de data warehouse é a alternativa eficaz e prática que gera valor rapidamente às organizações, e ainda reduz as dificuldades na implementação de DW.

A complexidade no processo de ETL

Antigamente, os processos de ETL eram feitos por softwares extremamente caros, geralmente acessados somente pelas grandes empresas.

Felizmente a realidade mudou e agora temos centenas de ferramentas para transformação e armazenamento de dados em larga escala disponíveis no mercado.

As equipes técnicas se divertem utilizando as novas ferramentas, como bancos de dados NoSQL, data lake, linguagens de programação paralelizáveis etc. Aliás, não é raro encontrar projetos com mais de uma dezena de tecnologias utilizadas simultaneamente.

Porém, à medida que novas linguagens e ferramentas de engenharia de dados surgem, a complexidade dos projetos e os custos com horas de desenvolvimento e manutenção aumentam.

Por isso, escolher as ferramentas adequadas para solucionar os problemas na implementação de um DW é uma estratégia importante que evita o desperdício de tempo. Além do esforço de uma equipe fixa, composta por vários engenheiros de dados, em tarefas como a manutenção dos códigos e infraestrutura.

Hoje, com tantas tecnologias disponíveis para trabalhar com grandes volumes de dados, na maioria dos casos é mais barato utilizar soluções pagas de PaaS (Platforms as a Service), como Google Big Query e Amazon Redshift, do que desenvolver e manter sua própria estrutura de dados.

O distanciamento entre equipe técnica e stakeholders

A alta complexidade técnica é um grande gargalo na implementação do DW. É uma determinante que distancia a equipe técnica, geralmente composta por engenheiros de dados e desenvolvedores, dos stakeholders, os usuários finais dos dados na organização.

Como já mencionamos, um data warehouse é sobretudo um projeto de negócio e, assim sendo, sua implementação depende da aplicação de tecnologias e processos para atingir sua principal finalidade: a utilização do usuário final.

É importante pensar: em um projeto de DW, o que faz o olho do stakeholder brilhar?

A resposta é simples: disponibilidade instantânea e facilidade de acesso aos dados para tomada de decisão.

Espera-se que o acesso às informações seja rápido e constante para resolver problemas e demandas cotidianas de forma assertiva e cirúrgica. O problema é que, na prática, alcançar esse objetivo não é tarefa simples.

Por isso, o formato tradicional de ETL, que trata o usuário final apenas como um cliente, deixando de priorizá-lo em toda cadeia do projeto, é um dos grandes motivos para o fracasso de projetos de data warehouse.

Nessa perspectiva, é comum as seguintes situações ocorram:

• inconsistência: não há confiança nos dados por parte das unidades de negócio. Mesmo após meses de trabalho, métricas e valores continuam sendo divergentes entre diferentes equipes. E, além disso, testes e validação são relegados a segundo plano ou mesmo completamente ignorados.
• “BI na fila do pão”: as áreas de negócio precisam de tickets para acessar a área técnica do projeto e devem "esperar na fila" para conseguir alguma informação ou alteração nos dados. Isso atrasa a entrega e faz com que os analistas voltem a recorrer a sistemas estáticos, como relatórios de Excel, e percam o interesse pelo projeto.
• complexidade e falta de governança: projetos feitos em linguagens e ferramentas distintas dificultam a comunicação e o entendimento integrado dos dados nos diferentes níveis organizacionais. Além disso, também afetam a criação de uma boa governança de dados, necessária para a utilização e evolução do data warehouse.
• atrasos no projeto: geralmente, a fluidez dos projetos fica prejudicada quando feita sem a colaboração do usuário final na implementação dos ETLs. Sendo assim, é comum que os projetos de DW tradicionais dependam de inúmeras rodadas de ajustes e correções. Isso poderia ser evitado se o analista de negócios fosse incluído nesse processo, pois, com sua expertise em dados, ele poderia identificar e corrigir inconsistências rapidamente, garantindo uma abordagem muito mais célere.

A falta de conscientização interna de analytics

Poucas empresas conseguem realmente criar uma cultura de analytics para todos, em que os analistas de negócio tenham maturidade de dados para que:

• entendam a estrutura do DW.
• possam fazer consultas analíticas diretas (quando necessário).
• saibam a importância de colaborar no desenvolvimento e manutenção do projeto.

Como já foi apontado, é difícil exigir essa cultura de tantos departamentos de negócio distintos, ainda mais quando estão distantes dos dados, como nos projetos de ETL tradicionais. Por isso, um novo paradigma precisa ser desenhado.

É muito comum que projetos de data warehouse comecem por iniciativa da alta gestão de uma empresa, após ela entender que os negócios que não se adaptarem à “era dos dados” desaparecerão.

E nem sempre o mesmo esforço e investimento é depositado na criação de uma cultura de dados, sendo capaz de absorver essas novas estruturas na organização. Depois de anos de implementação, e centenas de milhares de reais investidos, analistas continuam:

• criando relatórios em Excel
• usando exportações manuais
• fazendo longas reuniões
• não entendendo quais fontes de determinados indicadores são verídicas, entre outros.

A dificuldade de contratar “super-homens”

Já houve um tempo em que um profissional de dados podia ter tanto o domínio quanto a capacidade técnica de manipulação de dados.

O tamanho e escopo dos dados era limitado, e uma planilha de Excel bem configurada já permitia responder uma boa parte das perguntas relevantes.

Com a expansão da capacidade de armazenamento e de processamento de dados, os horizontes de análise foram ampliados e novas capacidades técnicas passaram a ser fundamentais, como:

• conhecimento de infraestrutura de dados
• boas práticas de desenvolvimento de software
• conhecimento de modelagem de dados, entre outros.

Essa nova realidade impôs duas barreiras para a contratação de profissionais ou serviços na área de dados:

• a dificuldade de encontrar “super-homens” que dominem todas as áreas técnicas de dados e tenham conhecimento do domínio.
• a dificuldade de manter profissionais experientes dentro da organização.

Esses dois fatores precisam ser levados em consideração desde o início do projeto, pois, quando combinados, podem tornar os projetos de DW extremamente caros.

O fato é que não é fácil encontrar esse profissional e é ainda mais difícil mantê-lo.

Portanto, hoje em dia, profissionais das áreas de negócio precisam ampliar a sua capacidade analítica e saber escrever suas próprias consultas de SQL. Com isso, é possível ter uma estrutura harmoniosa para a implementação de DW em empresas de todos os portes.

ELT vs ETL: aproximando os dados dos analistas em projetos de DW

Para se tornar uma empresa data driven, não basta ter um banco de dados de data warehouse e dispor de um ETL complexo para abastecê-lo.

Enquanto analistas ainda fizerem relatórios manualmente ou dependerem de abertura de chamados à equipe técnica para atualizarem seus modelos de dados, é quase impossível atingir a escalabilidade necessária para uma maturidade analítica moderna.

Uma forma de acelerar os processos de implementação de DW é trazer a área de negócio para dentro da etapa de transformação de dados.

Para isso, é necessário que a lógica de negócio seja separada das questões técnicas, como:

• o provisionamento de infraestrutura
• a orquestração dos pipelines
• a materialização de tabelas
• o permissionamento etc.

Por outro lado, é virtualmente impossível exigir que um profissional de negócios domine a  transformação de dados e seja fluente em linguagens altamente complexas utilizadas nas principais ferramentas de ETL atualmente, como Python, Spark e Java.

Logo, o ideal é que a transformação de dados ocorra em uma interface única e intuitiva com uma linguagem amplamente entendida.

A inversão na ordem dos processos: de ETL para ELT

Com o surgimento dos bancos de dados escaláveis na nuvem, como o Amazon Redshift, o  SQL reassumiu seu lugar de destaque como a linguagem universal dos dados.

Isso aconteceu porque praticamente não há mais limitações de escalabilidade, como ocorria em bancos de dados relacionais tradicionais e que foram o objeto de criação de diversas tecnologias de processamento de dados de big data, como Hadoop, Spark etc.

Para isso, é preciso inverter o processo de extract, transform, load (ETL) para um processo extract, load, transform (ELT).

Com essa alteração, a etapa de transformação passa a protagonizar e operar através de modelos escritos em SQL de fácil manutenção e amplo entendimento. Outras vantagens da arquitetura ELT incluem:

• modularidade: ao separar as regras de negócio das etapas de extração e load, é possível utilizar ferramentas 3rd-party para integração de dados com baixo investimento, como Stitch, Fivetran, entre outras. Além disso, é mais simples utilizar as ferramentas certas de forma incremental, acelerando a implementação do projeto.
• simplicidade: ao invés de escrever códigos em linguagens complexas, como Java, Python e Scala, a transformação pode ser centralizada em uma só linguagem, reduzindo custos com treinamento e manutenção, facilitando o entendimento organizacional e muito mais.
• governança: um ambiente único simplifica a documentação e governança dos dados. Com isso, é possível criar lógicas de permissionamento e gerenciar  dados sensíveis de forma integrada.
• versionamento: uma dos grandes desafios em se trabalhar com bancos de dados era a dificuldade de controle de versionamento, essencial nas boas práticas de engenharia de software modernas. Ferramentas de ELT, como o DBT, resolvem esse problema, pois separam os arquivos de modelos de dados em SQL do banco de dados em si.
• separação de ambientes: o ELT permite separar os ambientes de dados brutos, staging e dados finais através de diferentes schemas no banco de dados. A partir disso, cada usuário pode ter diferentes ambientes de desenvolvimento, onde  o trabalho colaborativo é facilitado e os erros de produção podem ser evitados.
• testes: o modelo ELT centraliza as boas práticas de testes em um único local no projeto, assim como ocorre em projetos de software modernos. Dessa forma, o analista pode escrever os testes diretamente em SQL, com os dados que ele confia, garantindo a consistência e confiabilidade nos modelos finais.

É importante lembrar que essa nova metodologia que estamos apresentando não resolve todo projeto de analytics, uma vez que os data warehouses ainda são mais utilizados para dados estruturados.

Por isso, o que sugerimos é utilizar a ferramenta certa para o problema certo, porque, salvo situações específicas, como em casos de empresas com uma estrutura de dados extremamente complexa, a abordagem ELT é perfeitamente viável.

Conclusão: ETL ou ELT?

É comum que projetos de data warehouse sejam um dos maiores investimentos realizados pelas empresas. Por outro lado, a abordagem tradicional do ETL apresenta muitas barreiras e dificulta a geração de valor desses projetos, aumentando o tempo, complexidade e seu custo de implementação.

Ainda assim, novas tendências estão surgindo para solucionar esses obstáculos.

Em nossa experiência aqui na Indicium, os melhores resultados em termos de implementação e adoção do projeto de DW é, de fato, a adoção da nova abordagem ELT.

Ou seja, os departamentos de negócio estão imersos dentro do projeto e a etapa de transformação de dados ocorre dentro do próprio DW, como mostra a figura abaixo.

Processos inovadores como esse demandam o emprego de novas ferramentas ou ainda combinações delas. E, para operacionalizar esse processo, há algumas alternativas disponíveis no mercado.

Aqui na Indicium, nós geralmente optamos por ferramentas open-source, que possuam uma ampla base de usuários e tenham maturidade em projetos modernos de analytics.

Por exemplo, para a criação, documentação e transformação dos modelos de dados, nós geralmente utilizamos o DBT. E é através de Singer Taps, ou ferramentas próprias desenvolvidas em Apache Spark, que os dados brutos são geralmente carregados no DW.

Além disso, dependendo do volume de dados, banco de dados PostgreSQL ou Amazon Redshift são as escolhas iniciais. Com essa configuração, a criação de BIs e relatórios é direta e pode ser feita por qualquer ferramenta de BI moderna, como Power BI, Tableau, Metabase, Looker etc.

Invista em ELT

Agora que você entendeu algumas vantagens que a abordagem de ELT tem sobre a de ETL, é hora de colocar em prática e se beneficiar dela.

E se você precisar de ajuda para implementação do ELT no seu negócio, entre em contato para conversarmos sobre seu projeto hoje mesmo clicando aqui!