Adeus ETL, boas-vindas ao ELT
Nos últimos anos, muitas empresas passaram a se conscientizar sobre o valor gerado pelos dados nos negócios. A possibilidade de utilizar grandes volumes 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 na nuvem oferecem um novo horizonte de possibilidades para o armazenamento de dados. 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, por isso, houve uma grande expansão de projetos nesse segmento.
Apesar do buzz recente, os projetos de data warehouse não são novidade: estão em voga desde o surgimento do conceito de DW nos anos noventa. Na época, as grandes promessas dos projetos de DW não eram facilmente materializadas. Seus benefícios eram ofuscados por barreiras como altos custos, dificuldade de implementação e utilização. De fato, um relatório da consultoria Gartner aponta que em 2005, mais de 50% dos projetos de Data Warehouse não atingiram os resultados esperados.
Os principais obstáculos para criar um projeto de Data Warehouses de sucesso são: a complexidade inerente a cada projeto bem como a dificuldade de gerar valor aos usuários finais. Apesar de suas necessidades técnicas e estruturas próprias, o projeto de DW é sobretudo um projeto de negócio, portanto, deve ser idealizado principalmente sob a ótica do usuário do negócio.
Acreditamos que a chave de um projeto de Data Warehouse é aproximar o usuário de negócios dos dados, trazendo-o para o projeto de forma direta, não apenas após meses ou mesmo anos de implementação. Na prática, isso significa reduzir a complexidade do código do projeto e focar no desenho e implementação das regras de negócio em uma linguagem padrão e facilmente entendida.
Além disso, boas práticas de engenharia de software como versionamento, validação, testes e documentação devem ser integradas no projeto para garantir a qualidade dos dados na ponta.
Tradicionalmente, a etapa mais importante e demorada de projetos de dados é o chamado ETL (do inglês, extract-transform-load). Tanto um projeto completo de Data Warehouse quanto projetos de dados menos complexos tendem a seguir um padrão como o da figura abaixo .
As três etapas do ETL são atribuídas às equipes de Data Engineering ou outras áreas técnicas da empresa, enquanto os analistas de negócios e cientistas de dados ficam limitados ao consumo desses dados na ponta. Como veremos na próxima seção, essa arquitetura gera uma série de dificuldades na implementação eficiente de projetos de Data Warehouse ao distanciar os usuários finais dos dados da criação das lógicas de negócio implementados no ETL. Já na seção 3 vamos propor uma nova arquitetura de criação de Data Warehouses através do ELT e discutir suas potenciais vantagens. Por fim, vamos apresentar uma arquitetura concreta que utilizamos em nossos projetos.
Os Problemas de Processos de ETL tradicionais
Uma reclamação constante em projetos de DW é o tempo elevado entre o início do projeto e a geração de valor para a empresa. Tipicamente, essa demora é geralmente causada por um ou mais dos seguintes fatores: 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 e a dificuldade de contratar “super-homens”.
Feito é melhor que perfeito
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. De fato, é um projeto complexo, que interage com múltiplas unidades de negócio, dados diferentes, de fontes distintas, velocidades diversas e em volumes 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 de DW (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 é alternativa eficaz e prática que gera valor rapidamente às organizações — e ainda reduz as dificuldades na implementação de DW.
Excesso de complexidade não significa melhora de qualidade
Antigamente, os processos de ETL eram feitos por softwares extremamente caros, geralmente acessados somente pelas grandes empresas. Hoje, a realidade é outra: centenas de ferramentas para transformação e armazenamento de dados em larga-escala estão disponíveis no mercado. A tentação de utilizar novas ferramentas como bancos de dados NoSQL, Data Lakes, linguagens de programação paralelizáveis etc é grande entre as equipes técnicas — e não é raro encontrar projetos com mais de uma dezena de tecnologias utilizadas simultaneamente.
À 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 aumenta. Escolher as ferramentas adequadas para solucionar os problemas na implementação de um DW é uma estratégia importante que evita o dispêndio de tempo e 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.
Distanciamento entre equipe técnica e stakeholders
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, e stakeholders, os usuários finais dos dados na organização. Como já mencionamos, um Data Warehouse é sobretudo um projeto de negócio, por isso, sua implementação de sucesso 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. Eles esperam ter acesso às informações de forma rápida e constante para resolver problemas e demandas cotidianas de forma assertiva e cirúrgica. Ocorre que na prática, alcançar esse objetivo não é tarefa simples.
Por isso, o formato tradicional — 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. 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 área técnica do projeto e devem “esperar na fila” para conseguir alguma informação ou alteração nos dados, e.g. adicionar uma nova coluna em uma tabela. Essas inconsistências resultam no atraso na entrega dos dados e faz com que os analistas voltem a recorrer a sistemas estáticos como relatórios de Excel — e ainda 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 da organização. Isso também afeta 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. Por isso, é 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. Com sua expertise em dados, poderia identificar e corrigir inconsistências rapidamente, garantindo uma abordagem muito mais célere.
Falta de conscientização interna de Analytics
É muito comum que projetos de Data Warehouse ou outras iniciativas equivalentes comecem por iniciativa da alta gestão da empresa, após ser impactada por alguma consultoria ou relatório dizendo que as empresas que não se adaptarem à “era dos dados” irão desaparecer. No entanto, nem sempre o mesmo esforço e investimento é depositado na criação de uma cultura de dados, capaz de absorver essas novas estruturas na organização. Passados dois anos de implementação e centenas de milhares de reais investidos, analistas continuam criando relatórios em Excel usando exportações manuais, reuniões continuam se alongando sobre quais fontes de determinados indicadores é verídica, entre outros.
Poucas empresas conseguem realmente criar uma cultura de Analytics para todos, em que os analistas de negócio tenham maturidade de dados para entender a estrutura do DW e possam fazer consultas analíticas diretas (quando necessário) e principalmente entendam a importância de colaborar no desenvolvimento e manutenção desse projeto. Como já mencionamos, é difícil exigir essa cultura de 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!
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 o conhecimento de infra-estrutura 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 ainda tenham conhecimento do domínio, além da dificuldade de manter profissionais experientes dentro da organização. Esses dois fatores precisam ser levados em consideração desde início do projeto, pois quando combinados, podem tornar os projetos de DW extremamente caros.
O fato é: não é fácil encontrar este profissional e é ainda mais difícil mantê-lo. Projetos de dados bem-sucedidos são aqueles que exploram e obtém o máximo de profissionais em suas devidas áreas de expertise. Isto é, projetos em que a manutenção da infraestrutura de dados se concentra nos Engenheiros de Dados, enquanto a transformação dos dados é feita por equipes capacitadas de Analistas e Cientistas de Dados, que detém o conhecimento de Domínio e sabem fazer as perguntas necessárias para gerar dados em insights poderosos. Nesse modelo, é essencial reduzir a distância entre dados e insights. Para tanto, profissionais das áreas de negócio também 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.
Aproximando os dados dos analistas em projetos de DW — ELT vs ETL
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, orquestração dos pipelines, materialização de tabelas, permissionamento, etc.
Por outro lado, é virtualmente impossível exigir que um profissional de negócio 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. Dessa forma, o ideal é que a transformação de dados ocorra em uma interface única e intuitiva com uma linguagem amplamente entendida.
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 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 ter protagonismos 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, 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 das grandes dificuldades 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 modernas de ELT, como o DBT, resolvem este 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 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 a metodologia que estamos apresentando não resolve todo e qualquer projeto de Analytics. Data Warehouses são tipicamente utilizados para dados estruturados — ainda que sua capacidade de trabalhar com dados não estruturados tenha aumentado significantemente nos últimos anos. O que sugerimos é utilizar a ferramenta certa para o problema certo, e salvo situações específicas, como em casos de empresas com uma estrutura de dados extremamente complexa, a abordagem ELT é perfeitamente viável e em nossa opinião, recomendada.
Conclusão
É comum que projetos de Data Warehouse sejam um dos maiores investimentos realizados pelas empresas. Por outro lado, a abordagem tradicional apresenta muitas barreiras e dificulta a geração de valor desses projetos, aumentando o tempo, complexidade e seu custo de implementação. Ainda sim, novas tendências estão surgindo para solucionar esses obstáculos
Em nossa experiência, os melhores resultados em termos de implementação e adoção do projeto de DW, ocorrem quando os departamentos de negócio estão imersos dentro do projeto. Isto é, quando a metodologia de transformação de dados ocorre dentro do próprio DW.
Processos inovadores como o de ELT podem demandar o emprego novas ferramentas ou ainda a combinações delas. Para operacionalizar esse processo, há algumas alternativas disponíveis no mercado. 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. Para a criação dos modelos de dados, documentação e transformação, nós geralmente utilizamos o Dbt. Os dados brutos são geralmente carregados no DW através de Singer Taps ou ferramentas próprias desenvolvidas em Apache Spark. A depender 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 PowerBI, Tableau, Metabase, Looker, etc.
