Case de Sucesso: Como a Somos Educação iniciou sua jornada de Dados na nuvem da AWS

Por Thiago Guimaraes, Engenheiro e Arquiteto de Dados, Somos Educação,

e Bruno Dantas, Engenheiro e Arquiteto de Dados, Somos Educação,

e Marcelo Oliveira, Arquiteto de Dados, Somos Educação,

e Wesley Rodrigues, Arquiteto de Soluções Sênior, AWS Brasil.

A Somos Educação

A SOMOS Educação é um dos principais grupos de educação básica do Brasil. Oferece um amplo portfólio de soluções educacionais, como sistemas de ensino, editoras, soluções de ensino complementar, além de uma tecnológica plataforma de aprendizado digital e de e-commerce, que permite a ela se apresentar como o parceiro integral da escola. São mais de 4.100 escolas parceiras e aproximadamente 1,3 milhão de alunos. De todo o tráfego web educacional no Brasil, 50% passa pela plataforma do Plurall, o ambiente virtual de aprendizagem criado pela SOMOS, sendo que 25% dos alunos brasileiros de escolas privadas utilizam o Plurall.

Reestruturação do Ambiente de Dados e seus Desafios 

Apesar de já existirem produtos de dados na SOMOS, o Plurall demandou atenção dedicada, e dois novos times foram criados: um time de Data Analytics e um time de Data Science. O primeiro time tem como missão construir o Data Lake, o Data Warehouse, e toda a estrutura necessária para lidar com os dados. O time de Data Science será responsável por utilizar os dados do Plurall para agregar inteligência competitiva ao produto, trazendo insights, previsões, correlações, aplicando AI/ML para melhorar a experiência dos usuários da plataforma.

A meta de reestruturar um ambiente já em operação dentro de uma empresa possui alguns grandes desafios, e um deles é que a nova proposta deve atender de maneira plena todas as necessidades já cobertas no desenho atual, além é claro, de resolver alguns problemas de performance, segurança, e principalmente custos.

Em uma rotina de operação normal, o time de engenharia de dados tende a focar mais no processo de desenvolvimento do que na exploração de oportunidades de redução custos. E isso é compreensível, uma vez que as metas de entrega estão mais alinhadas com prazos do que com indicadores de otimização e eficiência. Criar uma cultura onde o desenvolvedor se coloca como dono do negócio, e busca alternativas que sejam ao mesmo tempo efetivas e de baixo custo, além é claro seguras, eleva a empresa para um outro nível de maturidade.

No universo de serviços disponíveis pela AWS para uso pelos clientes, existem inúmeras estratégias de arquiteturas que podem ser seguidas. Identificar o serviço certo a ser utilizado em cada uma das etapas do pipeline de dados, como ingestão, tratamento e acesso, pode parecer uma tarefa simples, mas ao mesmo tempo pode esconder uma grande armadilha de custos excessivos se não for bem construída.

No processo de reestruturação do nosso ambiente de dados, escolhemos adotar uma abordagem chamada Lambda pattern, já conhecida, robusta e colocada à prova do tempo em várias empresas que tiveram sucesso em sua jornada rumo a uma cultura data-driven. Apesar de existir um padrão que nos orientou em como deveríamos seguir na nossa estratégia de construção desse ambiente, os detalhes de como isso é feito e quais serviços são utilizados é parte do desafio do time de engenharia e arquitetura de dados.

Organizando a Casa

O primeiro ponto que priorizamos nessa jornada de reestruturação do ambiente de dados foi a organização dos buckets que formam o conceito de Data Lake da empresa. Nós optamos por trabalhar com um conjunto de buckets segmentados por etapas que representam cada um dos momentos pelo qual o dado vai passar na sua jornada de preparação, até se tornar um elemento de valor para as áreas de negócio, de forma a facilitar a organização, o fluxo e principalmente melhorar a segurança e a governança.

Figura 1 – Organização sequencial dos dados em buckets do Data Lake

Nesse ponto já encontramos algumas oportunidades de trabalhar de forma mais efetiva os custos de armazenamento dos nossos dados. Os buckets que receberam dados no seu formato original, com tamanho maior, terão uma política de ciclo de vida dos objetos em um período pré-determinado, para que eles sejam movimentados para outras classes de armazenamento do S3, e dessa forma reduzindo o custo de armazenamento em até 10 vezes.

O segundo ponto que endereçamos nessa estratégia de organização dos dados, foi a criação de um ambiente de Data Warehouse, utilizando o conceito de modelagem dimensional com o objetivo de facilitar a entrega dos dados para as áreas de negócio através de um self-service BI, deixando dessa forma área de negócio mais autônoma na hora de explorar e criar os seus relatórios sem uma dependência direta do time de dados.

Para prover o serviço de Data Warehouse, utilizamos o Amazon Redshift, um serviço de armazenamento de dados em escala de petabyte totalmente gerenciado na AWS. Para chegar no cenário ótimo de operação, houve um trabalho a ser feito na modelagem das tabelas, padronização de nomes e mnemônicos, além da preparação dos dados para posterior carga das tabelas fatos e dimensões.

Um outro desafio que existe no uso de bancos de dados colunares para self-service BI é a questão de consultas submetidas pelos usuários de forma não performática, que acabam comprometendo a capacidade do cluster responder com eficiência e velocidade as perguntas de negócio. Muitas vezes esse problema é resolvido utilizando-se da força bruta, aumentando a capacidade computacional do cluster que compõe o banco de dados do Redshift. Porém essa abordagem não é muito efetiva do ponto de vista de custos, uma vez que a operação de um cluster ligado e com a sua capacidade computacional aumentada, acaba gerando despesas no final do mês.

Nossa estratégia para lidar com este problema consiste em copiar as tabelas do Redshift em formato parquet para um bucket denominado Catalog, onde utilizamos o AWS Glue Crawler para mapear a estrutura dos arquivos e disponibilizá-los para acesso pelos times de negócio via AWS Athena. Para facilitar a vida dos usuários que não possuem conhecimento em linguagem SQL, utilizamos uma ferramenta drag-and-drop open source chamada Metabase. Com o Metabase, os times fazem exploração de dados e geração de insights, além de construírem dashboards e automatizarem o envio de relatórios. Outra ferramenta open source que utilizamos é o DBeaver, um cliente SQL compatível com Athena e Redshift.

Figura 2 – Integração do Metabase e DBeaver com os repositórios de dados

Desafio

O desafio que enfrentamos nesse desenho foi identificar qual o melhor serviço da AWS, do ponto de vista de eficiência operacional e de custos, para realizar a função de cópia das tabelas do Redshift para o bucket S3. Como esse evento acontece em um momento bem definido do fluxo de tratamento do pipeline de dados, que é ao término da carga da tabela no Data Warehouse, nós optamos por utilizar o serviço gerenciado AWS Lambda. O AWS Lambda é um serviço de computação sem servidor e orientado a eventos que permite executar código para praticamente qualquer tipo de aplicação ou serviço de backend sem provisionar ou gerenciar servidores.

O Lambda pode ser iniciado com base em um evento, que no nosso caso é a inserção de um arquivo JSON em uma fila do Amazon SQS. No arquivo, enviamos as informações de nome da tabela que precisa ser copiada e o caminho de destino no Amazon S3. Quando esse arquivo é criado e inserido na fila, o AWS Lambda executa o comando copy do Redshift utilizando os parâmetros disponíveis nesse comando para compressão de arquivo e particionamento.

Esse processo de cópia executado pelo Lambda acabou gerando um custo elevado nos testes que foram executados, chegando as $2 USD em 4 dias de teste. Iniciamos um processo de entendimento da cobrança observando o log de eventos do Amazon CloudWatch e identificamos que o maior impacto no custo era o tempo em que a função Lambda aguardava o término do comando copy do Redshift.

A solução foi executar de forma assíncrona a função de copy via Lambda. Reduzimos o timeout de execução da função Lambda para 5 segundos. Como resultado, o custo baixou para $0,0002, durante o mesmo intervalo de tempo. Uma redução de 10.000x do valor inicial.

Já está no nosso roadmap a verificação de sucesso do comando copy utilizando o arquivo manifest, que indica se os dados foram copiados com sucesso e qual o número de registros inseridos no arquivo copiado.

Considerações Finais

A jornada para uma empresa se tornar data-driven vai muito além de se implantar áreas de Analytics ou implantar serviços de Machine Learning. Ela passa pela criação de uma estrutura robusta e segura que vai sustentar todas as iniciativas de dados da empresa, e garantir que os serviços de processamento e análise estarão disponíveis sempre que forem necessários. Ter um baixo custo de operação junto com um acompanhamento detalhado dos valores gastos em cada serviço e projeto se faz essencial.

Sobre os Autores

Thiago Guimaraes é engenheiro e arquiteto de dados na Somos Educação, onde trabalha com a criação e manutenção de uma Arquitetura de Dados escalável, poderosa e barata. Entusiasta de tecnologia, estudante de Engenharia de Computação e Informação na Universidade Federal do Rio de Janeiro e co-fundador do Hemocione (@hemocione), Associação sem fins lucrativos que fomenta a doação de sangue no Brasil. Também atuou como desenvolvedor backend. Nerd de marca maior. Siga-o no twitter em @guimadev.

Bruno Dantas é um engenheiro e arquiteto de dados na Somos Educação, atuando principalmente na estruturação do fluxo de dados utilizando a cloud da AWS. Desenvolvedor amante do Open Source e estudante de Engenharia de Computação e Informação na Universidade Federal do Rio de Janeiro, além de atuar compartilhando seus conhecimentos em tecnologias no 4noobs, um projeto da He4rt que visa ensinar o básico sobre tecnologias e linguagens de programação publicamente. Acompanhe meus projetos em github.com/DantasB

Marcelo Oliveira é arquiteto de dados na Somos Educação, com mais de 10 anos de experiência no mundo de dados e arquitetando desde o início o 3º DW/ Data Lake em empresas diferentes. Alucinado por tecnologia, jogos eletrônicos e quadrinhos.

Wesley Rodrigues é arquiteto de soluções sênior na AWS, curioso e apaixonado por aprender novas tecnologias. Adora estudar segurança, inteligência artificial e eletrônica, e usa estes conhecimentos para ajudar os clientes do setor de educação em suas jornadas para a nuvem. Ama Linux, open source, música e boa comida com os amigos.