Nos últimos anos, os rápidos avanços tecnológicos levaram a um aumento dramático no tráfego de informações. Nossas redes móveis aumentaram a cobertura e a taxa de transferência de dados. Os smartphones estão cada vez mais presentes em nossas vidas e gerando mais dados como nunca.
Graças a isso, mais e mais pessoas estão constantemente on-line através de vários dispositivos usando muitos serviços diferentes. Dispositivos de IoT coletam cada vez mais conjuntos de dados – informações aéreas, imagens, som, informações de RFID, dados meteorológicos, etc.
Todo esse progresso resulta em mais dados sendo compartilhados on-line. Os conjuntos de dados aumentaram rapidamente em volume e complexidade, e os aplicativos de processamento de dados tradicionais começaram a ser inadequados para tratar esse novo tipo e estrutura de dados. É incrível como muitas empresas e profissionais insistem em não perceber que as características dos dados estão mudando e que novas tecnologias de armazenamento e processamento de dados são necessárias.
Esse vasto volume de dados introduziu novos desafios na captura, armazenamento, análise, pesquisa, compartilhamento, transferência, visualização, consulta, atualização e privacidade das informações.
Inevitavelmente, esses desafios exigiram um projeto de arquitetura completamente novo e novas tecnologias, que nos ajudam a armazenar, analisar e obter insights desses conjuntos de dados grandes e complexos.
Aqui apresentarei a arquitetura do Data Lake, que introduz uma interessante revolução no armazenamento e processamento de dados. O Data Lake não é uma revolução no mundo do Big Data, uma solução de tamanho único, mas um simples passo evolucionário no processamento de dados, o que naturalmente aconteceu.
Conceitos
Vamos começar definindo o que é Data Lake (clique aqui para ver outro artigo aqui no blog sobre Data Lake):
“Data Lake pode ser definido como armazenamento centralizado, consolidado e persistente de dados brutos, não modelados e não transformados de múltiplas fontes, sem um esquema pré-definido explícito e sem metadados definidos externamente.”
Esta definição mostra um dos principais conceitos do Data Lake – armazenamento de dados não alterados. Tradicionalmente, tentamos filtrar e estruturar os dados antes que eles entrem no Data Warehouse. Com o Data Lake isso é diferente.
Duas coisas emergem disso – a estruturação e transformação de dados na ingestão geram um impacto no desempenho e uma possível perda de dados. Se tentarmos fazer cálculos complexos em uma grande quantidade de dados recebidos, provavelmente teremos sérios problemas de desempenho. Se tentarmos estruturar dados sobre a ingestão, poderemos perceber mais tarde que precisamos de partes de dados descartadas durante a estruturação.
O problema é que, com dados vastos e complexos, é muito provável que não saibamos quais insights você pode extrair deles. Não sabemos qual será o valor, se houver, dos dados coletados para nossa empresa. Se tentarmos adivinhar, há uma boa chance de adivinhar errado.
O que fazemos então? Nós armazenamos dados brutos. Agora, não queremos apenas colocá-los lá, pois isso levará a um pântano de dados (Data Swamp) – um conjunto de dados antigos, sem qualquer informação sobre o que ele representa. Os dados devem ser enriquecidos com metadados, descrevendo sua origem, tempo de ingestão, etc. Também podemos particionar dados na ingestão, o que torna o processamento mais eficiente posteriormente.
A ingestão de dados dessa maneira não oferece garantias de qualidade e não tem controle de acesso. Se realmente não sabemos o que está lá, não podemos configurar uma segurança eficiente em torno deles. Tudo isso virá mais tarde, quando os dados forem processados. Todos com acesso ao Data Lake terão acesso irrestrito a dados brutos.
Podemos introduzir um esquema de sistema de segurança trivial, permitindo o acesso seletivo a partições de dados. Esta é uma segurança bastante grosseira e pode, ou não, trazer qualquer valor.
Arquitetura
A definição anterior concentrou-se em enfatizar o conceito central do Data Lake. Vamos expandir um pouco:
“O Data Lake suporta aquisição de dados de forma ágil, modelo de armazenamento natural para dados complexos e multiestruturados, suporte para computação não relacional eficiente e fornecimento de armazenamento econômico de grandes e variados conjuntos de dados.”
Essa adição à nossa primeira definição nos dá uma imagem mais clara do que o Data Lake deve ser.
Devemos ser capazes de coletar dados de diferentes fontes, usando protocolos diferentes, para armazenar dados relacionais e não relacionais, e oferecer API para análise e processamento. Tudo isso deve ser flexível o suficiente para escalar para cima e para baixo.
Geralmente, o Data Lake é separado em três camadas: ingestão, armazenamento em cache e processamento. A camada de ingestão pode ser dividida ainda em camada de aquisição de dados em batch e streaming e camada de mensagens. A camada de caching é também chamada de camada de armazenamento.
Qualquer uma dessas camadas pode conter várias tecnologias, cada uma oferecendo diferentes APIs e funcionalidades. Cada aplicação / tecnologia em cada uma dessas camadas deve ser capaz de se beneficiar do escalonamento horizontal e vertical e permitir até certo ponto a tolerância a falhas. Cada um desses sistemas deve ser orquestrado usando o gerenciador de recursos, para oferecer elasticidade no custo, capacidade e tolerância a falhas.
O objetivo da camada de ingestão é agir como uma camada de armazenamento para dados brutos que chegam ao sistema Data Lake. Essa camada não deve forçar o usuário a aplicar o esquema aos dados recebidos, mas pode oferecer isso como uma opção. Podemos querer enriquecer os dados com metadados, portanto, poderíamos querer estruturá-los um pouco, afinal.
Os dados recebidos geralmente consistem em séries temporais, mensagens ou eventos. Esses dados geralmente são coletados de sensores de dispositivos IoT, estações meteorológicas, sistemas industriais, equipamentos médicos, armazéns, redes sociais, mídia, portais de usuários, etc.
O suporte ao particionamento de dados, mesmo que não seja obrigatório, é altamente recomendado, pois podemos particionar dados de processamento para tentar melhorar o desempenho ao processá-lo.
O objetivo da camada de armazenamento em cache é armazenar temporariamente ou permanentemente dados processados (ou pré-processados), relacionais ou não relacionais. Os dados armazenados aqui estão prontos para visualização / consumo por sistemas externos ou estão preparados para processamento adicional.
Os aplicativos que residem na camada de processamento pegarão os dados da camada de processamento, os processarão, estruturarão de alguma forma e os armazenarão aqui, opcionalmente particionando-os de uma certa maneira.
É comum ter um conjunto de dados, usado por sistemas de recebimento de dados, espalhados em torno de diferentes sistemas de armazenamento encontrados dentro da camada de armazenamento em cache (relacional, NoSQL, mecanismos de indexação, etc.).
O objetivo da camada de processamento é oferecer uma ou mais plataformas para processamento distribuído e análise de grandes conjuntos de dados. Ele pode acessar dados armazenados na camada de ingestão e armazenamento em cache.
Geralmente, as tecnologias encontradas aqui são implementadas usando arquitetura mestre-trabalhador – algoritmos de processamento de dados de análise de nó mestre codificados em aplicativos que são submetidos a ela, criam estratégia de execução e distribuem a carga de trabalho por várias instâncias de trabalho, para que possam executá-la em paralelo. Com esse tipo de arquitetura, a camada de processamento pode ser facilmente dimensionada para atender às necessidades de potência computacional necessárias para casos de uso específicos.
Critérios de tecnologias
Olhando para as propriedades Data Lake anteriormente declaradas, vamos definir os critérios que a pilha de tecnologia usada para implementá-la precisa atender.
- Escalabilidade. As tecnologias precisam ser capazes de aceitar uma quantidade vasta e crescente de dados de maneira eficiente.
- Durabilidade. Os dados precisam ser persistidos com segurança e a prevenção de perda de dados precisa ser suportada (usando replicação, backups ou algum outro mecanismo).
- Suporte para ingerir dados não estruturados (sem esquema).
- Suporte para manipulação eficiente de dados semelhantes a fluxo (séries temporais, eventos/mensagens).
- Suporte para eliminação de dados, para poder remover dados desnecessários ou dados que não estão autorizados a estar presentes, devido a preocupações de privacidade/legais.
- Suporte para atualizações de dados.
- Suporte para diferentes padrões de acesso – acesso aleatório, idiomas de pesquisa/consulta, leituras em lote.
- Diferentes sistemas downstream podem ter requisitos diferentes no acesso aos dados, dependendo de seus casos de uso.
Conclusão
O Data Lake vem ganhando cada vez mais popularidade por trazer uma nova concepção de armazenamento e processamento de dados, aderente às necessidades impostas pelo Big Data e o volume de dados que não para de crescer. É bem provável que em um futuro próximo o Data Lake faça parte da infraestrutura de dados de qualquer empresa.
David Matos
Referências:
Data Lake – Design, Projeto e Integração
Data Lake vs Data Warehouse: Key Differences
Amazon AWS – What is a Data Lake?
Build a foundation for Big Data Analytics with a Data Lake
Data Lake – the evolution of data processing