Data Lakehouse: Unindo conceitos e expectativas
Empresas têm gerado, dia após dia, um grande volume e variedade de dados cada vez mais relevantes. E, para transformar esses dados em informações estratégicas para os negócios, as companhias buscam repositórios que atendam suas necessidades, como por exemplo: monitoramento real time, latência, resiliência, escalabilidade, velocidade de acesso e de carga de grandes volumes, possibilitando análises de dados por SQL, Dashboards, Ciência de Dados, Machine Learning, entre outros.
Para atender essas demandas, é necessário recorrer a repositórios como Datas Lakes e/ou Data Warehouses. É possível utilizar o Data Warehouse para criar um Data Lake e vice-versa ou utilizar o Data Warehouse como responsável pelos dados estruturados como planilhas, CSV e tabelas de bancos de dados, e o Data Lake responsável por grandes volumes de dados não estruturados como imagens, vídeos e documentos, além dos semi-estruturados como JSON e XML.
Mas, seria essa a abordagem ideal? Qual o custo financeiro de duas estruturas distintas coexistirem? Qual o esforço para utilização dos dados? Qual a complexidade de unir esses dados para uma visão única e estratégica para auxiliar os negócios da empresa? Os dados estão na Nuvem ou em Servidores OnPremises? E a principal pergunta, alguém usa esses dados, com toda essa complexidade?
Esta abordagem resulta em pipelines de ETL complexos devido à grande movimentação, processamento e duplicação dos dados, além da necessidade de profissionais altamente capacitados para operacionalizar, quando possível automatizar e fazer a governança desta arquitetura de dados. E, claro, as metas de entrega desses dados, que, a cada dia, estão ficando mais próximas do Real-Time.
Então, como é possível resolver esse desafio e ainda ter uma arquitetura com um único repositório e que ajude com todas as questões levantadas até o momento? O ponto positivo é que já existe uma terceira arquitetura no mercado, que combina os principais benefícios do Data Warehouse e do Data Lake, unindo os conceitos e centralizando as informações, reduzindo custos operacionais, melhorando a governança e acabando de vez com a redundância de dados, conhecida como Data Lakehouse
Data Lakehouse é uma junção Join, ou um Merge, ou um Union. Essa arquitetura impacta positivamente o tratamento dos dados. Agora, para entender melhor esse impacto positivo, é necessário conhecer mais sobre as tecnologias citadas até o momento.
Afinal, o que é um Data Warehouse?
Um Data Warehouse, popularmente conhecido no mundo dos dados como DW, é um clássico repositório construído para armazenamento centralizado de informações. O processo consiste em unificar as informações que anteriormente ficavam em bancos transacionais (OLTP) em um banco analítico (OLAP). O DW também permitiu a unificação de outro conceito de armazenamento conhecido como Data Mart, onde os dados eram armazenados de acordo com sua aplicação, não possuindo uma base centralizada.
Os DWs destinam-se a realizar consultas e análises avançadas e geralmente contêm grandes quantidades de dados históricos. Os DWs alimentam ferramentas de relatórios, painéis (Front-End) e fornecem resultados de consulta de forma mais rápida para um grande número de usuários simultaneamente.
Os Data Warehouses surgiram para ajudar as empresas sobre os dados estruturados, dando suporte a tomadas de decisões através de ferramentas de inteligência de negócio, ou seja, o Business Intelligence.
De uma forma bem resumida, um DW moderno possui:
- Um Sistema de Gerenciamento de Banco de Dados Relacional (RDBMS) com o principal intuito de armazenar dados consolidados de várias fontes;
- Ferramentas de Extração, Transformação e Carga de Dados (ETL) para integração entre os sistemas fontes e o DW, principalmente para criação de histórico de dados;
- Ferramentas de Front-End para facilitar a visualização dos dados sem movê-los para bases distintas e com mecanismos que permitem acessos concorrentes.
A limitação de termos somente dados estruturados em um DW, começou a incomodar as empresas, principalmente os arquitetos e analistas que não conseguiam evoluir nas análises de situações que estavam em outras fontes de dados. Outro ponto muito interessante é que a maioria dos DWs estavam em servidores OnPremises, que dificultam a escalabilidade de armazenamento e processamento, criando processos bem burocráticos e caros para dar uma atualização que é sempre bem-vinda. E, claro, não é importante lembrar dos Cientistas de Dados que não conseguem evoluir em soluções de Machine Learning, como, por exemplo, algoritmos de visão computacional que utilizam dados de imagens e vídeos como entrada.
Vamos falar sobre Data Lake?
Surge uma nova maneira de olhar para os dados: o Big Data. Agora a demanda de armazenar, além de um grande volume, também possui uma grande variedade de dados e, com ela surgiu o novo conceito de Data Lake, que armazena não somente dados estruturados, como em um DW, mas também dados semi estruturados e não estruturados.
Com o surgimento do Data Lake, começaram a aparecer novas nomenclaturas, como o Modern Data Warehouse. Outro benefício que ajudou bastante foi a capacidade de organizar os dados não estruturados, uma grande vantagem pois os dados eram tratados e depois carregados no Data Warehouse.
Além disso, permitiu também que os Cientistas de Dados conseguissem unir os dados estruturados e os não estruturados para suas análises e modelos complexos.
Principais características do Data Lake:
- Compatibilidade com novos formatos de dados;
- Escalável;
- Uso de Dados Brutos;
- Alto poder de organização;
- Espaço de armazenagem de dados elevado.
Mas como a principal característica do Data Lake é trabalhar com o Dado Bruto, ou seja, com o mínimo de transformação possível, ainda havia a necessidade de uma grande interação com o Data Warehouse. Os dados eram enviados do Data Lake para o Data Warehouse para enriquecimento do BI, como dados eram trazidos do Data Warehouse para o Data Lake para enriquecer as análises dos Cientistas de Dados.
Outro ponto importante, com o uso de Dados Brutos em um Data Lake, é necessário investir muito tempo na preparação dos dados do que realmente nas regras de negócio. Além disso, a exploração dos dados exige uma expertise em ferramentas de codificação para extrair valor das informações.
Como consequência negativa, é possível a observar a criação de vários repositórios a nível departamental, tirando a característica de ter os dados centralizados e uma visão unificada, aumentando ainda mais a duplicação dos dados dentro da empresa, algo parecido com os antigos Data Marts.
Dessa forma, a vida de um Engenheiro de Dados ficou ainda mais agitada, além de cuidar dos Dados Estruturados, Semi-Estruturados e Não Estruturados, ainda precisa entender a necessidade de vários times e a estrutura de cada repositório para fazer todo esse meio de campo entre o Data Lake e o Data Warehouse.
O que poderia ser um alívio para os cofres das empresas, na verdade foi o contrário, mais uma arquitetura que, mesmo sendo mais barata que a citada anteriormente, iria consumir recursos financeiros das empresas. Basicamente as empresas agora estão pagando por dois armazenamentos, dois processamentos e precisando de profissionais altamente gabaritados para equilibrar os pratos e deixar tudo funcionando perfeitamente.
O que é um Data Lakehouse?
Agora que você já sabe os prós e os contras de um Data Warehouse e um Data Lake, uma arquitetura é necessária para resolver os desafios de redução de custos operacionais, simplificar o processo de transformação e melhorar a governança. O Data Lakehouse se tornou uma forma de centralizar e unificar as fontes de dados, de qualquer formato e esforços de engenharia na organização. Essencialmente, o uso do Data Lakehouse permite que todos os usuários possam explorar os dados, independentemente de suas capacidades técnicas.
A ideia principal do Data Lakehouse é ter um sistema de armazenamento de dados centralizado (característica do Data Warehouse) de baixo custo (característica do Data Lake), utilizando um formato aberto de arquivos, como por exemplo o Parquet (mais uma vez o Data Lake), com acesso simultâneo de Leitura e Escrita (o Data Warehouse aparecendo mais uma vez) que permita o uso e manipulação de dados estruturados, semi-estruturados e não estruturados (agora está completo).
Para facilitar os processos dos profissionais que trabalham com dados, os mesmos são armazenados de forma estruturada, com esquema de dados (modelagem, tabelas, colunas, datatypes, etc). Dessa forma usuários do DW e usuários do DL conseguirão usufruir de todos os benefícios de um Data Lakehouse.
Para que tudo isso funcione, a arquitetura de um Data Lakehouse separa os recursos de processamento e armazenamento, parecido com o Data Lake. Também é possível configurar vários motores de processamento, dessa forma é viável ter acessos concorrentes na arquitetura, lembrando o Data Warehouse.
Isso tudo só se tornou possível com o amadurecimento de tecnologias que permitem um controle transacional em um Data Lake, como por exemplo o Delta Lake (desenvolvido pela DataBricks), que consiste em uma nova tecnologia que traz confiabilidade para os dados armazenados no Data Lake, possuindo transações ACID, essas antes presentes somente na arquitetura de um Data Warehouse, um processo unificado de dados em batch e streaming e o tratamento de metadados escalonáveis.
Utilizando uma camada de metadados transacional, implementada sobre o sistema de armazenamento para definir quais objetos fazem parte de uma versão da tabela, é possível fornecer as funcionalidades dos DWs sobre os arquivos de formato aberto. Além disso, estruturas de dados auxiliares como índices e estatísticas e o uso de cache ajudam a melhorar ainda mais o desempenho das consultas.
Resumindo as explicações acima, além de transações ACID, o Data Lakehouse permite gerenciamento, versionamento, auditoria, indexação, cachê e otimização de consultas utilizando formato de arquivos abertos.
Outra característica herdada do Data Lake, o Data Lakehouse separa o processamento do armazenamento. Pode-se destinar clusters específicos para aplicações específicas e desativar os clusters quando estiverem em desuso. Isso ajuda muito em relação aos custos de manter essa estrutura funcional.
Então, é possível desligar os DWS e DLS?
Primeiramente, é necessário analisar a real necessidade e o cenário financeiro de cada empresa, só assim é possível entender a arquitetura mais aderente. Uma companhia que utiliza somente dados estruturados, pode apostar em um Data Warehouse que terá sua necessidade atendida.
O mais importante é saber que existe uma tecnologia promissora que combina a flexibilidade, a eficiência de custos e a escalabilidade dos Data Lakes com o gerenciamento de dados e transações ACID de Data Warehouses.
Esse artigo tem como principal objetivo demonstrar as características das principais tecnologias quando falamos de dados e um pouco de sua evolução. Quanto mais as empresas evoluem juntamente com a tecnologia, mais facilmente o data-driven se tornará uma realidade.
