Reinventando a abordagem do Sprout Social para big data

O Sprout Social é, em sua essência, uma empresa orientada por dados. O Sprout processa bilhões de mensagens de várias redes sociais todos os dias. Por causa disso, os engenheiros do Sprout enfrentam um desafio único – como armazenar e atualizar várias versões da mesma mensagem (ou seja, retuítes, comentários, etc.) que chegam à nossa plataforma em um volume muito alto.

Como armazenamos várias versões de mensagens, os engenheiros do Sprout têm a tarefa de “recriar o mundo” várias vezes ao dia – um processo essencial que requer a iteração de todo o conjunto de dados para consolidar cada parte de uma mensagem social em uma “fonte de verdade”.

Por exemplo, acompanhar as curtidas, comentários e retuítes de uma única postagem no Twitter. Historicamente, contamos com clusters Hadoop autogerenciados para manter e trabalhar com grandes quantidades de dados. Cada cluster Hadoop seria responsável por diferentes partes da plataforma Sprout – uma prática que é utilizada por toda a equipe de engenharia do Sprout para gerenciar projetos de big data, em escala.

Chaves para a abordagem de big data do Sprout

Nosso ecossistema Hadoop dependia do Apache Hbase, um banco de dados NoSQL escalável e distribuído. O que torna o Hbase crucial para nossa abordagem de processamento de big data é sua capacidade de não apenas fazer varreduras rápidas em conjuntos de dados inteiros, mas também fazer pesquisas rápidas, aleatórias e de registro único.

O Hbase também nos permite carregar dados em massa e atualizar dados aleatórios para que possamos lidar com mais facilidade com mensagens que chegam fora de ordem ou com atualizações parciais e outros desafios que acompanham os dados de mídia social. No entanto, os clusters Hadoop autogerenciados sobrecarregam nossos engenheiros de infraestrutura com altos custos operacionais, incluindo o gerenciamento manual da recuperação de desastres, expansão do cluster e gerenciamento de nós.

Para ajudar a reduzir o tempo gasto com o gerenciamento desses sistemas com centenas de terabytes de dados, as equipes de infraestrutura e desenvolvimento do Sprout se uniram para encontrar uma solução melhor do que executar clusters Hadoop autogerenciados. Nossos objetivos eram:

• Permita que os engenheiros do Sprout criem, gerenciem e operem melhor grandes conjuntos de dados
• Minimize o investimento de tempo dos engenheiros para adquirir e manter manualmente o sistema
• Corte custos desnecessários de provisionamento excessivo devido à expansão do cluster
• Forneça melhores métodos de recuperação de desastres e confiabilidade

À medida que avaliávamos alternativas para nosso sistema de big data atual, nos esforçamos para encontrar uma solução que se integrasse facilmente com nossos padrões e processamento atuais e aliviasse o trabalho operacional que acompanha o gerenciamento manual de um cluster.

Avaliando novas alternativas de padrão de dados

Uma das soluções que nossas equipes consideraram foram os data warehouses. Os data warehouses atuam como um armazenamento centralizado para análise e agregação de dados, mas se assemelham mais aos bancos de dados relacionais tradicionais em comparação com o Hbase. Seus dados são estruturados, filtrados e possuem um modelo de dados estrito (ou seja, com uma única linha para um único objeto).

Para nosso caso de uso de armazenamento e processamento de mensagens sociais que possuem muitas versões de uma mensagem lado a lado, os data warehouses tinham um modelo ineficiente para nossas necessidades. Não conseguimos adaptar nosso modelo existente de maneira eficaz aos data warehouses, e o desempenho foi muito mais lento do que prevíamos. Reformatar nossos dados para adaptá-los ao modelo de data warehouse exigiria uma grande sobrecarga para retrabalhar na linha do tempo que tínhamos.

Outra solução que analisamos foram data lakehouses. Os data lakehouses expandem os conceitos de armazenamento de dados para permitir dados menos estruturados, armazenamento mais barato e uma camada extra de segurança em torno de dados confidenciais. Embora os data lakehouses oferecessem mais do que os data warehouses poderiam, eles não eram tão eficientes quanto nossa solução Hbase atual. Ao testar nosso registro de mesclagem e nossos padrões de processamento de inserção e exclusão, não conseguimos gerar latências de gravação aceitáveis ​​para nossos trabalhos em lote.

Redução de sobrecarga e manutenção com o AWS EMR

Dado o que aprendemos sobre soluções de armazenamento de dados e lakehouse, começamos a procurar ferramentas alternativas executando o Hbase gerenciado. Embora tenhamos decidido que nosso uso atual do Hbase era eficaz para o que fazemos no Sprout, nos perguntamos: “Como podemos executar o Hbase melhor para reduzir nossa carga operacional e, ao mesmo tempo, manter nossos principais padrões de uso?”

Foi quando começamos a avaliar o serviço gerenciado Elastic Map Reduce (EMR) da Amazon para Hbase. Avaliar o EMR exigia avaliar seu desempenho da mesma forma que testamos data warehouses e lakehouses, como testar a ingestão de dados para ver se ele poderia atender aos nossos requisitos de desempenho. Também tivemos que testar o armazenamento de dados, alta disponibilidade e recuperação de desastres para garantir que o EMR atendesse às nossas necessidades de uma perspectiva administrativa/infraestrutura.

Os recursos do EMR melhoraram nossa solução autogerenciada atual e nos permitiram reutilizar nossos padrões atuais para leitura, gravação e execução de trabalhos da mesma forma que fizemos com o Hbase. Um dos maiores benefícios do EMR é o uso do EMR File System (EMRFS), que armazena dados no S3 em vez de nos próprios nós.

Um desafio que encontramos foi que o EMR tinha opções limitadas de alta disponibilidade, o que nos restringia a executar vários nós principais em uma única zona de disponibilidade ou um nó principal em várias zonas de disponibilidade. Esse risco foi mitigado aproveitando o EMRFS, pois forneceu tolerância a falhas adicional para recuperação de desastres e a dissociação do armazenamento de dados das funções de computação. Ao usar o EMR como nossa solução para Hbase, podemos melhorar nossa escalabilidade e recuperação de falhas e minimizar a intervenção manual necessária para manter os clusters. Por fim, decidimos que o EMR era o mais adequado para nossas necessidades.

O processo de migração foi facilmente testado de antemão e executado para migrar bilhões de registros para os novos clusters EMR sem nenhum tempo de inatividade do cliente. Os novos clusters apresentaram melhor desempenho e redução de custos em quase 40%. Para ler mais sobre como a mudança para o EMR ajudou a reduzir os custos de infraestrutura e melhorar nosso desempenho, confira o estudo de caso do Sprout Social com a AWS.

O que aprendemos

O tamanho e o escopo deste projeto nos deram, a equipe de Engenharia de Confiabilidade de Banco de Dados de Infraestrutura, a oportunidade de trabalhar multifuncionalmente com várias equipes de engenharia. Embora tenha sido desafiador, provou ser um exemplo incrível dos projetos de grande escala que podemos enfrentar no Sprout como uma organização de engenharia colaborativa. Por meio desse projeto, nossa equipe de infraestrutura obteve uma compreensão mais profunda de como os dados do Sprout são usados, armazenados e processados, e estamos mais preparados para ajudar a solucionar problemas futuros. Criamos uma base de conhecimento comum entre várias equipes que pode nos ajudar a capacitar a criar a próxima geração de recursos para o cliente.

Se você estiver interessado no que estamos construindo, junte-se à nossa equipe e candidate-se a uma de nossas funções abertas de engenharia hoje mesmo.