Como vamos criar uma visão unificada dos nossos dados com Data Lake

Conheça os nossos planos para simplificar o armazenamento e a manipulação dos dados da Geo

Aqui na Geofusion, nossos dados são distribuídos e armazenados em diferentes tecnologias: Oracle, PostgreSQL, MongoDB, Solr, Amazon S3, entre outras. Você deve estar se perguntando o porquê disso. Bom, para nós faz todo o sentido, já que buscamos sempre utilizar as tecnologias mais adequadas para cada tipo de uso dos nossos dados e serviços.

A questão é que, do ponto de vista dos Analistas, Cientistas de Dados e Engenheiros de Dados do nosso time, essa arquitetura exige esforços consideráveis para processar, analisar e disponibilizar os dados.

Para abstrair a complexidade do armazenamento heterogêneo queremos olhar de uma forma unificada para os dados. Ou seja, nossa intenção é criar mecanismos para que seja possível encontrar e entender rapidamente esses dados, independentemente de onde estejam armazenados.

Como faremos isso? Você vai descobrir agora.

Data Lake

Com o desafio de minimizar a complexidade do nosso ambiente de dados, começamos a investigar o conceito de Data Lake no início de 2018 como uma possível solução.

Mas afinal, o que é um Data Lake?

Data Lake é uma abordagem arquitetural que permite rápido armazenamento, processamento escalável e análise diversificada de qualquer tipo de dado. Além disso, é um recurso que ajuda a organizar, entender e manter a precisão dos dados.

Um Data lake fornece maneiras para que os diversos profissionais da organização possam encontrar e disponibilizar rapidamente os dados, com as políticas corretas de acesso. E um de seus principais benefícios é a criação de uma única fonte da verdade para os dados de uma organização, independentemente de onde estejam armazenados.

Alguns requisitos fundamentais que um Data Lake deve satisfazer são:

• disponibilizar um conjunto de ferramentas unificadas para consultar e analisar dados;
• construir e manter metadados automaticamente, conforme os dados evoluem;

Neste link você pode encontrar mais detalhes sobre a definição de um Data Lake.

Data Lake baseado em serviço AWS

Como toda nossa infraestrutura está na AWS, fazia sentido pensar em construir o Data Lake utilizando as ferramentas e os serviços disponíveis nessa nuvem. E é exatamente isso que estamos fazendo. A AWS possui uma grande quantidade de cases de implementação de Data Lakes. Estamos estudando as ferramentas e os serviços que achamos mais adequados para nossa realidade e, aos poucos, definindo a nossa arquitetura.

As tecnologias da AWS que estamos considerando até o momento são as seguintes:

— S3: Pretendemos utilizar object storage da Amazon para armazenar diferentes tipos de dados. Vamos começar pelos dados que consideramos imutáveis ou com ciclo de atualização longo, por exemplo os dados socioeconômicos com que trabalhamos. Esses dados vão ser migrados do Oracle para o S3 como resultado de um projeto de “reestruturação de dados” que estamos realizando. Pretendo escrever um post sobre esse projeto em outro momento.

Um dos requisitos para que um Data Lake, que utiliza o S3 como fonte de dados, tenha bom desempenho e baixo custo é o particionamento dos dados. Com o S3, é possível fazer isso diretamente na definição de diretórios. Como a maioria dos nossos dados podem ser particionados por ano e região administrativa, pretendemos tirar proveito dessa característica do S3.Também vou falar um pouco mais sobre S3 e particionamento de dados em outro post.

— Glue: O AWS Glue é um serviço de ETL que permite preparar e carregar dados de diferentes fontes para diferentes destinos. O que nos chamou a atenção no Glue é que ele faz a gestão automática dos metadados dos dados do Data Lake através de crawlers. Basta indicar a fonte dos dados que ele os descobre e armazena os metadados associados (ex.: schema e definição de tabela) no AWS Glue Data Catalog. Uma vez catalogados, os dados ficam imediatamente disponíveis para o desenvolvimento de ETLs e para consultas em tecnologias como o Athena e o EMR (Hive e Presto), que vou apresentar a seguir.

— Athena: O Amazon Athena é um serviço que permite a execução de consultas interativas usando SQL padrão. Outras vantagens que também identificamos no uso desse serviço:

• Não precisa de servidor (portanto, não há infraestrutura para gerenciar) e cobra apenas pelas consultas executadas;
• Tem integração com o Amazon S3 e com o AWS Glue Data Catalog;
• É possível fazer consultas sobre dados espaciais.

— EMR: O Amazon EMR (Elastic MapReduce) disponibiliza um cluster do Hadoop com toda sua stack de tecnologias, permitindo o processamento e a análise de grandes volumes de dados em instâncias do Amazon EC2. As grandes vantagens que enxergamos em utilizar o EMR em uma das camadas do nosso Data Lake são:

• Permite escalar o cluster com o uso de instâncias Spots;
• Permite o processamento de dados utilizando tecnologias conhecidas, como Hadoop e o Spark;
• Disponibiliza ferramentas que permitem a execução de consultas SQL, como o Hive e o Presto, para a análise dos dados;
• Interage de forma muito fácil com os dados armazenados no S3;
• As ferramentas contidas no cluster reconhecem automaticamente os metadados catalogados no AWS Glue — o que vai nos ajudar a poupar muito trabalho de mapeamento de dados.

Para fechar essa seção, a arquitetura que pretendemos ter em nosso data lake é a seguinte:

Mas então, quais os próximos passos?

Depois de levantar todo o cenário de necessidades que temos aqui na Geofusion e entender as tecnologias que podemos empregar em nosso Data Lake para atendê-las, agora vem a parte da execução.

Estamos começando a implementar o Data Lake com a migração de parte dos nossos dados socioeconômicos do Oracle para o S3. Novos fluxos de dados estão sendo construídos em Python e Spark e estamos utilizando o EMR como camada de processamento. Na camada de disponibilização dos dados, estamos começando a utilizar tecnologias como Hive, Presto, Athena, Notebooks e APIs desenvolvidas em Flask.

Como bem sabemos, nem tudo em tecnologia é simples. Existem várias características positivas e negativas que já identificamos e que ainda vamos identificar durante esse projeto. Meu plano é fazer outros posts no futuro, detalhando melhor os desafios de cada etapa desse nosso novo desafio.