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.

OsPara dadosKhine armazenadose Wang (2018), data lake consiste em um datarepositório lakeem que todos os dados de uma organização, ou seja, dados estruturados, semi estruturados e não possuem uma finalidade específica, sendo transformados apenas quandoestruturados, são necessáriosarmazenados parajuntos, análises e relatórios.

Comparação com um Data Warehouse (DW)

Dependendoindependentemente dos requisitos,tipos, umaformato organizaçãoou poderáestrutura. exigir um data warehouse eEm um data lake, poiso atendementendimento 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 diferentescriação necessidadesde uma camada semântica sobre os dados, que permitem a construção de uma camada de contexto, significado e casosrelacionamento entre os dados armazenados.  (KHINE e WANG, 2018).

No contexto de uso.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.

Pode-seSawadogo dizere Darmont (2021) apresentam diversas arquiteturas de Data Lakes, e concluem que umtanto dataas warehousearquiteturas consistefuncionais 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 sistemaData 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 originadosem 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,fontes. especialmenteUsuários estruturadosde negócio têm utilizado ferramentas de visualização amigáveis para consulta e análise. A estrutura dos dados é definida antecipadamente e, no caso de um DW com modelagem dimensional,  desenvolvida para facilitar o entendimento pelo usuário final e otimizado para aumentar o desempenho de consultas SQL.

  Por meio do processo de ETL, osvisualizar dados em umData DWLakes, sãocomo previamenteo limpos,Microsoft enriquecidosPower BI e transformadoso paraTableau.

que

possam

Combinando atuarData comoLakes "fontecom únicaData daWarehouses

verdade", em que os usuários possam confiar

Sawadogo e utilizarDarmont como(2021) apoiocitam àduas tomadaabordagens de decisão.

-----------------

Um data lake pode armazenar tanto dados relacionais provenientescombinação de sistemasData transacionais, quanto dados não relacionais de dispositivos dispositivos IoT e mídias sociais por exemplo. Em um data lake, a estrutura dos dados não é definida quando os dados são capturados. Isso significa que você pode armazenar todos os seus dados sem um design cuidadoso.

----------

Diferentes tipos de análise em seus dados, como consultas SQL, análise de big data, pesquisa de texto completo, análise em tempo real e aprendizado de máquina, podem ser usados ​​para descobrir insights.

À medida que as organizaçõesLakes com dataData warehousesWarehouses. veemA osprimeira benefíciosutiliza doso dataData lakes, elas estão evoluindo seu warehouse para incluir data lakes e habilitar diversos recursos de consulta, casos de uso de ciência de dados e recursos avançados para descobrir novos modelos de informações. O Gartner nomeia essa evolução como “Solução de gerenciamento de dados para análise” ou “DMSA”.

https://mastechinfotrellis.com/blog/can-big-data-replace-edw

https://aws.amazon.com/big-data/datalakes-and-analytics/what-is-a-data-lake/

https://cloud.google.com/blog/products/data-analytics/google-named-a-leader-in-2019-gartner-magic-quadrant-for-data-management-solutions-for-analytics

https://info.microsoft.com/gartner-mq-dmsa-register.html?ls=Website

http://docs.media.bitpipe.com/io_13x/io_134691/item_1446109/2016%20Magic%20Quadrant%20for%20Data%20Warehouse%20and%20Data%20Management%20Solutions%20for%20Analytics.pdf

data lake - Limitações e considerações

• Complexidade de utilização direta e dificuldade de entendimento pelos usuários finais
• Surgimento de data swamps -- amontoado de dados desorganizados
• Questões de qualidade e governança de dados
• Pode ser utilizadoLake 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.

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). 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.