Conceito de Datalake e armazenamentos possíveis
Todo mundo quer um Datalake
O motivo desse post é bem óbvio, todo mundo quer um Datalake, o sonho da centralização dos dados em um único ponto e cruzar as informações entre eles. Quem pede um e não conhece muito sobre o assunto já imagina o mundo dos sonhos, onde vou cruzar PDF com vídeo, arquivos jurídicos com notas fiscais, planilhas com fotos e assim vai.
Estamos falando de formatos legíveis para uma consulta, dados colunares ou chave valor, arquivos de log e alguns outros.
Tirado do Google mesmo o conceito de Datalake:
O data lake é um repositório que centraliza e armazena todos os tipos de dados gerados pela e para a empresa. Eles são depositados ali ainda em estado bruto, sem o processamento e análise e até mesmo sem uma governança.
Ah, mas tenho um data warehouse aqui:
Não são a mesma coisa, de longe não é a mesma coisa, esse conceito consiste no armazenamento constante dos dados tratados e prontos para uso no caso da necessidade de alguma analise, bem diferente do conceito anterior.
Em outras palavras vai ser o “quartinho da bagunça” caso você não se planeje direito e com base nisso, te faço algumas perguntas:
- Seus dados possuem o mesmo formato?
- Qual a finalidade de armazenamento desses dados?
- Quais consultas você fará nesses dados?
- O formato do seu dado suporta leitura em grandes volumes? Alterações estruturais?
- Qual o tamanho do arquivo gerado? Ele trabalha com partição?
- De quando é esse dado? Você armazena do jeito certo ou está pagando armazenamento sem saber disso?
- Os processadores desses dados, estão sobrecarregados devido a não ter o size correto ou porque você está fornecendo o formato de dado errado para analise?
Tenho mais uma lista de perguntas pra estressar o seu Datalake, que mal implantado pode ser um tiro no pé.
Nesse vídeo curtinho falo um pouco sobre Data Lake a data Warehouse e mostro no final um desenho de arquitetura que mostra a origem de dados, o armazenamento, o consumo e a exibição dos resultados extraídos de forma simplificada mas simples de entender.
Agora, vou iniciar falando sobre os possíveis armazenamentos que posso ter em ambientes Bigdata.
Armazenamentos de arquivos em ambientes Bigdata
Não irei entrar no detalhe e nem vou falar sobre os formatos que desconheço, vou falar só do que já mexi. O primeiro deles é o famosão Hadoop também conhecido como HDFS.
HDFS
Em curtas palavras é um sistema de arquivos de pastas e subpastas, possui controle por usuário e permissões do tipo RWX (Leitura, Gravação e Execução), esses tipos de atributos seria o chamado Journaling, onde você limita os acesso e privilégios trazendo segurança aos dados.
A diferença de um sistema de arquivos comum é que ao contrario do seu computador que tem os arquivos somente no seu notebook por exemplo, o Hadoop trabalha com o conceito de cluster e eu por exemplo posso ser um cluster de 10 nodes fazendo o papel de um.
Qual a vantagem disso? A vantagem é que ele usa por baixo um cara que chama YARN/MapReduce, digamos que você tem um arquivo de 7GB e você tem um cluster de 7 datanodes, o seu arquivo de 7GB vai ser quebrado 1GB para cada datanode a grosso modo e quando você pesquisa algo no seu arquivo de 7GB cada maquina busca sua parte de 1GB, trazendo paralelismo e trazendo o resultado mais rápido.
É bem mais que isso a arquitetura mas a grosso modo como disse é isso. Como dissemos de nodes do cluster cada maquina tem um disco, cada disco tem uma maquina, que por sua vez tem um custo. Ou seja o Hadoop é viável se você for lidar com grandes volumes de informação, para datasets pequenos a conta simplesmente não fecha. Outro ponto é que se vou processar esses mesmos dados todo dia e de forma constante, caso seja isso preciso de um ambiente Hadoop Fixo, todo dia ali, como um banco de dados Oracle por exemplo.
Deep Storage
Veja o seguinte cenário:
Vamos supor que eu precise processar um grande volume de informações, mas que seja de forma pontual, não preciso fazer isso todo dia com os mesmos dados, amanhã serão novos dados e nem vou usar os antigos. Como exemplo eu recebo 30TB de informações as quais preciso gerar um relatório que pode trazer extrema assertividade no meu negócio.
Um banco de dados convencional não conseguiria processar essas informações sem um hardware poderosíssimo. Mas eu também não precisaria de Hardware todo dia certo?
Pensando nisso essas plataformas cloud (não sei se a Microsoft tem isso na Azure) permitem que suas ferramentas de bigdata, como EMR, Athena, BigQuery e outras consigam acessar esses dados sem a necessidade de ter um HDFS, você ponta pro bucket do S3 ou do GCS e boa.
Vantagens:
Baixo custo de armazenamento, como nem o S3 nem o GCS envolvem instancias/maquinas é bem mais barato do que construir um cluster Cloudera com HDFS por exemplo. Mas a Cloudera como viu que isso podia distanciar seus clientes, tratou de criar a opção de armazenamento e consulta no S3 e GCS também. Que ficaria um cenário bem legal usando dados parte lá e parte no HDFS.
Desvantagens:
O armazenamento no S3 não possui um Journaling, um controle de acessos em pastas e subpastas assim como o HDFS, portanto se você precisa realmente disso, não seria a sua opção apesar de bem barato.
Fiz um videozinho com as minhas considerações sobre cada um deles e as vantagens de uso:
Qual a diferença para os meus armazenamentos de bancos de dados convencionais?
Os bancos de dados convencionais usam geralmente um único servidor, em alguns casos como o Oracle RAC em cluster porém quando se tratam de grandes volumes de informação uma única máquina além de exigir mais recursos de disco, vai exigir maior esforço computacional. Você pode até ter o seu Storage EMC de última geração, mas ele nunca vai vencer a “exponencialidade” de crescimento dos dados.
Os modelos mostrados são voltados para processamento de larga escala, devem ser usado por quem tem dados em larga escala (mais de TERAS E PETABYTES de informação), caso contrário seu banco convencional te atende e o Datalake é só uma ideia mirabolante sua.
Bom agora que você conhece os possíveis meios de armazenamento de dados voltados para Bigdata, no próximo post vou mostrar quais seriam os tipos de dados e quais o melhores para cada caso.
Espero que ajude bastante a entender o básico sobre o assunto e sinta-se a vontade de compartilhar esse material.
Abraço e até o próximo!
Anselmo Borges.
