Переосмысление подхода Sprout Social к большим данным

Sprout Social по своей сути является компанией, управляемой данными. Sprout ежедневно обрабатывает миллиарды сообщений из множества социальных сетей. Из-за этого инженеры Sprout сталкиваются с уникальной проблемой — как хранить и обновлять несколько версий одного и того же сообщения (например, ретвиты, комментарии и т. д.), которые поступают на нашу платформу в очень большом количестве.

Поскольку мы храним несколько версий сообщений, перед инженерами Sprout стоит задача «воссоздавать мир» несколько раз в день — важный процесс, который требует повторения всего набора данных, чтобы объединить каждую часть социального сообщения в один «источник правды».

Например, отслеживание лайков, комментариев и ретвитов одного поста в Твиттере. Исторически сложилось так, что мы полагались на самоуправляемые кластеры Hadoop для обслуживания и обработки таких больших объемов данных. Каждый кластер Hadoop будет отвечать за разные части платформы Sprout — практика, на которую опирается команда инженеров Sprout для управления проектами по работе с большими данными в масштабе.

Ключи к подходу Sprout к большим данным

Наша экосистема Hadoop зависела от Apache Hbase, масштабируемой и распределенной базы данных NoSQL. Что делает Hbase решающим для нашего подхода к обработке больших данных, так это его способность не только выполнять быстрое сканирование диапазона по всем наборам данных, но также выполнять быстрый случайный поиск отдельных записей.

Hbase также позволяет нам массово загружать данные и обновлять случайные данные, чтобы нам было легче обрабатывать сообщения, поступающие не по порядку или с частичными обновлениями, а также решать другие проблемы, связанные с данными социальных сетей. Однако самоуправляемые кластеры Hadoop обременяют наших инженеров по инфраструктуре высокими эксплуатационными расходами, включая ручное управление аварийным восстановлением, расширением кластера и управлением узлами.

Чтобы сократить время, затрачиваемое на управление этими системами с сотнями терабайт данных, группы разработчиков и инфраструктуры Sprout объединились, чтобы найти лучшее решение, чем использование самоуправляемых кластеров Hadoop. Наши цели заключались в следующем:

• Позвольте инженерам Sprout лучше создавать, управлять и оперировать большими наборами данных
• Сведите к минимуму временные затраты инженеров на ручное владение и обслуживание системы
• Сократите ненужные затраты на избыточное выделение ресурсов из-за расширения кластера
• Обеспечьте лучшие методы аварийного восстановления и надежность

Когда мы оценивали альтернативы нашей текущей системе больших данных, мы стремились найти решение, которое легко интегрировалось бы с нашей текущей обработкой и шаблонами и облегчило бы операционный труд, связанный с ручным управлением кластером.

Оценка альтернатив новым шаблонам данных

Одним из решений, которое рассматривали наши команды, были хранилища данных. Хранилища данных действуют как централизованное хранилище для анализа и агрегирования данных, но больше напоминают традиционные реляционные базы данных по сравнению с Hbase. Их данные структурированы, отфильтрованы и имеют строгую модель данных (т.е. имеют одну строку для одного объекта).

Для нашего случая хранения и обработки сообщений социальных сетей, в которых множество версий сообщения живут бок о бок, у хранилищ данных была неэффективная модель для наших нужд. Нам не удалось эффективно адаптировать нашу существующую модель к хранилищам данных, и производительность оказалась намного ниже, чем мы ожидали. Переформатирование наших данных для адаптации к модели хранилища данных потребовало бы больших накладных расходов на переделку в сроки, которые у нас были.

Еще одно решение, которое мы рассмотрели, — хранилища данных у озера. Озера данных расширяют концепции хранилищ данных, чтобы обеспечить менее структурированные данные, более дешевое хранилище и дополнительный уровень безопасности для конфиденциальных данных. Хотя хранилища данных предлагали больше, чем могли бы хранилища данных, они были не так эффективны, как наше текущее решение Hbase. При тестировании нашей записи слияния и наших шаблонов обработки вставки и удаления мы не смогли создать приемлемые задержки записи для наших пакетных заданий.

Сокращение накладных расходов и обслуживания с помощью AWS EMR

Учитывая то, что мы узнали о хранилищах данных и решениях Lakehouse, мы начали искать альтернативные инструменты, работающие под управлением Hbase. Хотя мы решили, что наше текущее использование Hbase эффективно для того, что мы делаем в Sprout, мы задались вопросом: «Как мы можем лучше использовать Hbase, чтобы снизить нашу операционную нагрузку, сохраняя при этом наши основные модели использования?»

Именно тогда мы начали оценивать управляемый сервис Amazon Elastic Map Reduce (EMR) для Hbase. Оценка EMR требовала оценки его производительности таким же образом, как мы тестировали хранилища данных и озерные домики, например тестирование приема данных, чтобы увидеть, может ли оно соответствовать нашим требованиям к производительности. Нам также пришлось протестировать хранилище данных, высокую доступность и аварийное восстановление, чтобы убедиться, что EMR соответствует нашим потребностям с точки зрения инфраструктуры и администрирования.

Функции EMR улучшили наше текущее самоуправляемое решение и позволили нам повторно использовать наши текущие шаблоны для чтения, записи и выполнения заданий так же, как мы это делали с Hbase. Одним из самых больших преимуществ EMR является использование файловой системы EMR (EMRFS), которая хранит данные в S3, а не на самих узлах.

Проблема, которую мы обнаружили, заключалась в том, что у EMR были ограниченные параметры высокой доступности, что ограничивало нас запуском нескольких основных узлов в одной зоне доступности или одним основным узлом в нескольких зонах доступности. Этот риск был снижен за счет использования EMRFS, поскольку она обеспечивала дополнительную отказоустойчивость для аварийного восстановления и отделение хранилища данных от вычислительных функций. Используя EMR в качестве нашего решения для Hbase, мы можем улучшить нашу масштабируемость и восстановление после сбоев, а также свести к минимуму ручное вмешательство, необходимое для обслуживания кластеров. В конце концов, мы решили, что EMR лучше всего подходит для наших нужд.

Процесс миграции был легко протестирован заранее и выполнен для переноса миллиардов записей в новые кластеры EMR без простоев клиентов. Новые кластеры показали улучшенную производительность и снижение затрат почти на 40%. Чтобы узнать больше о том, как переход на EMR помог снизить затраты на инфраструктуру и повысить производительность, ознакомьтесь с примером использования Sprout Social с AWS.

Что мы узнали

Масштабы и масштабы этого проекта дали нам, группе инженеров по обеспечению надежности баз данных инфраструктуры, возможность кросс-функциональной работы с несколькими инженерными группами. Несмотря на то, что это было сложно, это оказалось невероятным примером крупномасштабных проектов, которыми мы можем заниматься в Sprout как совместная инженерная организация. В рамках этого проекта наша команда по инфраструктуре получила более глубокое понимание того, как данные Sprout используются, хранятся и обрабатываются, и теперь у нас больше возможностей для устранения будущих проблем. Мы создали общую базу знаний для нескольких команд, которая поможет нам создавать клиентские функции нового поколения.

Если вам интересно то, что мы создаем, присоединяйтесь к нашей команде и подайте заявку на одну из наших открытых инженерных должностей сегодня.