# 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). Oreščanin e Hlupić (2021) mencionam uma combinação entre *Data Wharesouse* e *Data Lake* que envolve a migração de dados históricos de um DW para um *Data Lake*. De acordo com os autores, nesta configuração, o DW teria a função de armazenar os dados (fatos) mais recentes, e, à medida em que o DW for aumentando de tamanho, os dados mais antigos, e portanto menos acessados, poderiam ser migrados para a *Foundation Area* de um *Data Lake*. Deste moto, o DW ganharia performance de consulta e espaço em disco. Nesta configuração, os dados armazenados no *Data Lake* continuariam acessíveis e prontos para serem analisados juntamente com os dados no DW. **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; 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. Deste modo, a definição de uma arquitetura coerente, juntamente com a gestão de metadados, são cruciais para a qualidade de dados. Begoli, Goethert e Knight (2021) afirmam que *Data Lakes* não impõem explicitamente um *schema* para armazenamento de dados. Este aspecto, em um cenário de crescimento exponencial de dados, provenientes de inúmeras fontes, pode transformar o *Data Lake* em um *Data Swamp*, ou seja, em um pântano cheio de detritos de 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. Neste sentido, Khine e Wang (2018) afirmam que gerar valor com *Data Lakes* é ainda algo muito difícil.