Data Lake

Embora Data Warehouses sejam ainda muito relevantes e muito poderosos para dados estruturados, não se pode dizer o mesmo para dados semi-estruturados e não estruturados (KHINE e WANG, 2018; SAWADOGO e DARMONT, 2021). Como a maioria dos dados provenientes de Big Data são dados não estruturados (MILOSLAVSKAYA e TOLSTOY, 2016), pode-se concluir que Data Warehouses tradicionais não mostram-se alternativas viáveis como fonte de dados analíticos de Big Data. Neste sentido, o conceito de Data Lake desafia os tradicionais Data Warehouses no armazenamento de dados heterogêneos e complexos (KHINE e WANG, 2018).

As definições para Data Lake têm variado ao longo do tempo (KHINE e WANG, 2018; SAWADOGO e DARMONT, 2021). Alguns autores definem Data Lake apenas como um novo rótulo para soluções como Apache Hadoop por exemplo, o que, segundo Sawadogo e Darmont (2021) não estaria correto. Outros autores afirmam que Data Lakes podem ser utilizados apenas por alguns profissionais específicos, como estatísticos e cientistas de dados, pois os dados armazenados neste tipo de repositório requer certos cuidados que usuários de negócio poderiam negligenciar. Para Sawadogo e Darmont (2021), a definição mais correta para Data Lake é:

“um sistema escalável de armazenamento e análise de dados de qualquer tipo, retido em seu formato nativo e utilizado principalmente por especialistas em dados (estatísticos, cientistas de dados ou analistas) para extração de conhecimento. Suas características incluem:

um catálogo de dados que reforça a qualidade dos dados;
ferramentas e políticas de governança de dados;
acessível por vários tipos de usuários;
integração de qualquer tipo de dado;
organização física e lógica;
escalabilidade em termos de armazenamento e processamento.“.

Para Sawadogo e Darmont (2021), Data Lakes não necessariamente precisam ser restritos a estatísticos e cientistas de dados. Na visão destes autores, especialistas de negócio podem acessar Data Lakes através de um software de navegação ou de análise de dados apropriados.

De acordo com a Amazon (2022), um Data Lake é um repositório centralizado que permite armazenar dados estruturados e não estruturados, em qualquer escala. Os dados podem ser armazenados como estão, sem precisar primeiro estruturá-los. Uma vez armazenados, podem ser executadas diferentes tipos de análises sobre os dados, desde painéis e visualizações até processamento de big data, análise em tempo real e aprendizado de máquina.

Para Khine e Wang (2018), Data Lake consiste em um repositório em que todos os dados de uma organização, ou seja, dados estruturados, semi estruturados e não estruturados, são armazenados juntos, independentemente dos tipos, formato ou estrutura. Em um Data Lake, o entendimento dos dados, da sua estrutura e natureza, é delegada ao consumidor do dado, no momento da recuperação (ou seja, no momento da consulta). Os dados são transformados pelo usuário, ou aplicação, de acordo com o setor da organização, no intuito de adquirir insights de negócios. Alguns Data Lakes possuem recursos que possibilitam a criação de uma camada semântica sobre os dados, que permitem a construção de uma camada de contexto, significado e relacionamento entre os dados armazenados. (KHINE e WANG, 2018).

No contexto de um Data Lake, todos os dados são primeiramente coletados de suas fontes (Extract - E), depois carregados no Data Lake (Load - L), sem modificação de seus formatos originais, e por fim são transformados (Transform - T), de acordo com o interesse do cliente consumidor (KHINE e WANG, 2018). Ou seja, com Data Lake temos o acrônimo ELT, ao invés do ETL utilizado no Data Warehouse.

Sawadogo e Darmont (2021) apresentam diversas arquiteturas de Data Lakes, e concluem que tanto as arquiteturas funcionais quanto as arquiteturas baseadas em maturidade de dados são limitadas, e expõem a necessidade de uma arquitetura que aborde simultaneamente, funcionalidade e maturidade de dados.

A maioria dos Data Lakes são construídos sobre o ecossistema Apache Hadoop (HDFS, MapReduce, Spark, etc.), mas como exposto por Sawadogo e Darmont (2021), esta não é a única alternativa, visto que a construção de um Data Lake exige diversas partes básicas, tais como:

Ingestão de dados: esta etapa envolve a transferência de dados para o Data Lake. Alguns exemplos de ferramentas utilizadas são: Flink, Samza, Flume, Kafka e Sqoop.
Armazenamento: de acordo com Sawadogo e Darmont (2021), existem duas abordagens para armazenamento de dados em Data Lakes. A primeira é por meio da utilização de SGBDs tradicionais, como MySQL, PostgreSQL e Oracle. Geralmente, estes SGBDs são utilizados para armazenamento de dados estruturados e possuem também alguns recursos para armazenamento de dados não estruturados. Mas, geralmente, bancos de dados NoSQL são utilizados para o armazenamento de dados estruturados e não estruturados. A segunda forma é por meio do HDFS, utilizado em torno de 75% das vezes para armazenamento de dados em Data Lakes. No entanto, de acordo com Sawadogo e Darmont (2021), o HDFS sozinho é geralmente insuficiente para lidar com todos os formatos de dados, especialmente dados estruturados. Deste modo, segundo os autores, o ideal é que seja feita uma combinação do HDFS com bancos de dados relacionais e/ou NoSQL.
Processamento de dados: em Data Lakes, o processamento de dados é geralmente feito com o MapReduce ou Apache Spark. O Spark funciona como o MapReduce, mas adota uma abordagem de processamento 100% em memória ao invés de utilizar armazenamento físico para resultados parciais. Deste modo, spark é preferível para processamento de dados em tempo real. O Apache Flink e o Apache Storm são também boas alternativas para o processamento de dados em tempo real. As duas abordagens podem ser utilizadas simultaneamente, com o MapReduce dedicado ao processamento de grandes volumes de dados, e outros motores para o processamento de dados em tempo real.
Acesso aos dados: Em Data Lakes, o acesso a dados pode ser feito por SQL para bancos de dados relacionais, JSONiq para MongoDB, XQuery para bancos de dados XML ou SPARQL para recursos RDF. No entanto, isto não permite a execução de consultas sobre bancos de dados heterogêneos, visto que, geralmente, Data Lakes são construídos sobre uma arquitetura heterogênea (SAWADOGO e DARMONT, 2021). Deste modo, uma alternativa consiste na adoção de soluções capazes de realizar consultas em múltiplas fontes simultaneamente. Por exemplo, Spark SQL, ou SQL++ podem ser utilizados para a recuperação tanto de dados em SGBDs relacionais quanto dados semi estruturados no formato JSON. Outro exemplo é o Apache Drill, que permite consultas e junções sobre dados provenientes de múltiplas fontes. Usuários de negócio têm utilizado ferramentas de visualização amigáveis para visualizar dados em Data Lakes, como o Microsoft Power BI e o Tableau.

Combinando Data Lakes com Data Warehouses

Sawadogo e Darmont (2021) citam duas abordagens de combinação de Data Lakes com Data Warehouses. A primeira utiliza o Data Lake como fonte de dados para o DW, para onde os dados susceptíveis ao rigor do processo de ETL são enviados, enquanto os dados remanescentes ficam disponíveis para análises complementares.

A segunda abordagem considera a construção de um DW dentro do Data Lake. Algo que, segundo Sawadogo e Darmont (2021), seria possível com a abordagem de subdivisão do Data Lake em data ponds, proposta por Inmon (2016). Data ponds estruturados a partir de aplicações operacionais poderiam ser considerados equivalentes a Data Warehouses (INMON, 2016).

Maturidade e segurança

Caso o Data Lake não seja gerenciado adequadamente, este pode deteriorar-se a tal ponto de tornar-se o que é chamado de data swamp (pantano de dados) (KHINE e WANG, ~~2018)~~2018; OREŠČANIN e HLUPIĆ, 2021). Ninguém sabe exatamente o que será incluído em um Data Lake, não havendo procedimentos para prevenção de inclusão de dados inconsistentes ou repetidos, por exemplo. Se ninguém sabe exatamente o que há no Data Lake até a extração, dados corrompidos podem ser utilizados equivocadamente em tomadas de decisão, fazendo com que o erro seja descoberto tarde demais (KHINE e WANG, 2018). De acordo com Sawadogo e Darmont (2021), a gestão de metadados é fundamental para impedir que o Data Lake se torne um data swamp.

Neste mesmo sentido, Khine e Wang (2018) afirmam que a gestão de metadados é fundamental em um Data Lake. Como a forma de armazenamento não possui schemas pré-definidos (schema-on-ready), como em um Data Warehouse (que é schema-on-write), o Data Lake precisa fornecer metadados aos clientes durante o processo de análise e realização de consultas. Os metadados precisam ser adicionados no momento de armazenamento dos dados.

De acordo com Sawadogo e Darmont (2021), temas como governança de dados e segurança em Data Lakes são atualmente pouco abordados pela literatura. De acordo com Khine e Wang (2018), Data Warehouses podem garantir governança, performance, segurança e controle de acesso aos dados, enquanto Data Lakes não podem garantir, de forma plena, nenhum destes aspectos. Portanto, para Khine e Wang (2018), gerar valor com Data Lakes é algo muito difícil.