Arquitetura Data Lake Agora vamos nos aprofundar no desenho de arquitetura de solução de um Data Lake. Da mesma forma como fizemos no Data Warehouse, aqui eu estou compartilhando com vocês o meu ponto de vista de implementações que eu participei ao longo dos últimos anos da minha carreira profissional e estou trazendo elementos que eu presenciei e que eu vi em diferentes implementações, seja de data lakes mais tradicionais da primeira geração, que são os baseados em Hadoop, e também de data lakes mais recentes, mais modernos, baseados em nuvem, baseados em um armazenamento de objeto como S3. Começando pelo princípio, aqui nós também temos três elementos principais, três pilares. À nossa esquerda, o primeiro pilar, origem de dados. Eu vou destacar as diferenças em relação ao Data Warehouse. Aqui nós já temos uma diversidade de dados e formatos muito maior. Então, em contraste ao Data Warehouse, que tem uma origem de dados altamente estruturada, ou no máximo com alguma semi-estruturação, aqui no Data Lake as nossas origens serão diversas, com muitos formatos, e admite inclusive o formato não estruturado. Então, no primeiro momento, representando esse formato não estruturado, não previsto, são as redes sociais, que a gente pode coletar os seus posts. Esses posts poderão ser textuais, poderão conter imagens, poderão conter vídeos, poderão conter áudios, então esse conteúdo audiovisual. Podem ser também leituras de IoT. Essas leituras frequentemente vêm em um formato semi-estruturado em JSON, mas poderiam também ser documentos, como documentos em PDF, estruturado em JSON, mas poderiam também ser documentos, como documentos em PDF, planilhas de dados também poderiam ser compreendidas nesse universo amplo, nessa grande diversidade não estruturada de dados. Também podemos receber dados vindo dos sistemas em diversos arquivos. arquivos, nós vimos anteriormente quando falamos da comparação entre Data Lake e Data House, os formatos diversos que são suportados, como ORC, Parquet, Avro, que são tipos adicionais de arquivos diversos. E no meio do nosso diagrama temos com grande destaque o Data Lake. E aqui nós vamos ter um artefato novo, na verdade uma separação de papéis nesse artefato que é o Data Lake. Então nós temos o armazenamento, a maneira como esse dado está persistido e isso está separado do processamento destes dados que estão ali armazenados. Então, falando um pouquinho da história de Data Lake, na primeira geração de Data Lake, nós tivemos o predomínio do Apache Hadoop como ferramenta primordial para Data Lake, que atendia aquele requisito amplo de ingestão facilitada de dados brutos no seu formato original e também facilitando o acesso com o processamento desses dados no momento do seu consumo. Naquele momento também era possível fazer a persistência de dados diretamente sobre um sistema de arquivos. Então, você poderia utilizar, por exemplo, um NTFS do Windows ou um EXT do Linux e ter esses formatos diversos sendo persistidos diretamente como arquivos em um sistema de arquivos. Neste momento, o que predominou foi o uso do Hadoop para esta grande maneira plural de persistir arquivos diversos. Aqui também entra com o Hadoop um conceito de distribuição da persistência, então o dado está fisicamente, geograficamente distribuído em diferentes elementos, e na hora de processar também existe um processamento distribuído e paralelo. Nós vamos encontrar isso com bastante frequência sendo referido como Map Reduce. Então são processos que vão fazer a leitura dos dados que nós estamos querendo analisar, então estão sendo preparados e esta leitura vai acontecer de maneira distribuída e paralela e depois, em algum momento, esta leitura é agregada, ela converge. Então, este é o processo do Reduce. Então, MapReduce está muito associado com a estratégia desta primeira geração, que é o Hadoop. Em paralelo a tudo isso, na verdade como evolução, surge o Spark, Apache Spark, com grande popularidade para este papel de processamento. Então, a gente vai ver dentro do Data Lake, o pilar mais à direita, de processamento de informação. Então, é como se fossem jobs que estão lendo a informação, realizando diversas operações de transformação, curadoria, preparação desses dados, que podem devolver para o próprio Data Lake o processamento que foi realizado ou entregar isso para uma plataforma de visualização de dados. Então, por isso que nós temos aqui setas apontando tanto da esquerda para a direita, quanto da direita para a esquerda. Com a popularização da computação em nuvem, nós vamos perceber que os serviços de armazenamento em objeto, sendo o mais famoso o AWS S3, começam a adquirir este papel de persistência em nuvem, devido ao seu custo bastante competitivo, alta durabilidade desta informação que ali está persistida. Então, os data lakes com a nuvem sofrem um upgrade, então fica um ecossistema mais plural, porque nas nuvens a gente também encontra mecanismos de persistir os objetos diretamente. Então o S3, o Cloud Storage no Google. E também nós vamos encontrar o próprio Hadoop sendo entregue como serviço. Em alguns provedores de nuvem tem essa oferta. Mas o ponto principal para a gente destacar nesta arquitetura é principalmente a separação entre armazenamento e processamento e também o predomínio de uma persistência em um processamento que são distribuídos e também são paralelos. E aqui o grande conceito do MapReduce, que faz essa convergência de tudo aquilo que foi lido e prepara essa informação para uma camada de visualização. Do lado direito, nós temos o consumo. Então, o consumo pode ser uma própria ferramenta, uma ferramenta de BI, inclusive a mesma ferramenta que conecta em um Data Warehouse e poderia conectar em um Data Lake. conecta em um Data Warehouse, poderia conectar em um Data Lake. Podem ser ambientes de análise de dados, aí poderiam entrar os notebooks Jupyter, poderia entrar o RStudio, outras ferramentas para uma análise mais técnica. Vamos lembrar que no Data Lake, conforme o nível de preparação da informação, nós vamos ter diferentes níveis dos nossos usuários finais. Então, desde analistas de negócio, que dependem de uma preparação maior do dado, ou pessoas com características mais técnicas, como cientistas e engenheiros de dados. Uma outra coisa interessante para destacar é que o Data Lake pode estar organizado também em camadas. Então, nós vamos discutir mais para frente uma arquitetura medalhão, ou medallion architecture, que basicamente vai separar os dados entre bronze, prata e ouro. E são níveis diferentes de preparação. Então, o nível bronze geralmente está associado com dados brutos, Então, o nível bronze geralmente está associado com dados brutos, formato original, que requer mais técnica para fazer uma análise e obter um insight dessa informação. O nível prata já tem um nível de limpeza, um nível de conformidade, um nível de curadoria dessa informação. Então, vai ficar no meio do caminho. Ainda existe um certo requisito técnico, mas já aproxima um pouco essa massa de dados da área de negócio. E o nível ouro são os dados prontos, preparados, finalizados, provavelmente organizados em dimensões e fatos de análise para facilitar a compreensão humana e facilitar esta entrega nos diferentes mecanismos de análise que nós vamos ter na mão dos usuários finais de um data lake.