Аналитика в реальном времени от Facebook

HBase в Facebook завоевывает все более и более крепкие позиции, в прошлый раз я рассказывал о применении HBase в роли системы хранения данных для их новой системы обмена сообщений. Вторым продуктом, который теперь полноценно использует данную технологию, является система сбора и обработки статистики в реальном времени под названием Insights. Социальные кнопки (см. слева от поста) стали одним из основных источников трафика для многих сайтов, новая система аналитики позволит владельцам сайтов и страниц лучше понимать как пользователи взаимодействуют и оптимизировать свои интернет-ресурсы, основываясь на данных в реальном времени. Итак, 20 миллиардов событий в день (200 тысяч в секунду) с задержкой не более 30 секунд, как же можно этого достичь?

Цели сервиса

  • Дать пользователям надежные счетчики в реальном времени по ряду метрик
  • Предоставлять анонимные данных - нельзя узнать кто конкретно были эти люди
  • Продемонстрировать ценность социальных плагинов и виджетов. Что они дают сайту или бизнесу?
  • Концепция воронки: сколько людей увидело плагин, сколько совершило действие, сколько было привлечено пользователей обратно на интернет-ресурс
  • Сделать данные более оперативными: сокращение частоты обновлений с 48 часов до 30 секунд

Задачи

  • Множество типов метрик, более 100: показы, лайки, просмотры и клики в новостной ленте, демография и.т.д.
  • Большой поток данных: 20 миллиардов событий в день
  • Неравномерное распределение данных: за большинство контента практически не голосуют, но некоторые материалы набирают просто невероятное количество лайков

Неудавшиеся попытки

MySQL

  • В каждой строке идентификатор и значение счетчика
  • Привело к очень высокой активности в СУБД
  • Статистика считается за каждые сутки, создание новых счетчиков в полночь приводило к большому скачку операций записи
  • Пришлось пробовать искать способы решать проблему распределения счетчиков, пробовали учитывать временные зоны пользователей
  • Пики операций записи неминуемо вели к блокировкам
  • Решение оказалось не очень хорошо подходящим для данной конкретной задачи

Счетчики в памяти

  • Казалось бы: если столкнулись с проблемами ввода-вывода - надо перенести все в память
  • Никаких проблем с масштабируемостью - счетчики находятся в памяти, обновление практически мгновенно, легко распределить по серверам
  • Но на практике оказалось, что при таком подходе теряется точность, видимо из-за неатомарности операций или других последствий столь прямолинейной реализации, подробностей нет
  • Погрешность даже в 1% посчитали неприемлемой и от данного варианта отказались

MapReduce

  • Предыдущий вариант реализации был создан с помощью Hadoop + Hive
  • Подход гибкий, легко справляется с большим входящим потоком информации и объемами данным
  • Основной минус: даже близко не в реальном времени, слишком комплексная система

Cassandra

  • Вариант с Cassandra рассматривался, но так и не был реализован
  • Причины были опубликованы достаточно сомнительные: высокие требования к доступности данных и производительности записи
  • По всем данным у Cassandra нет абсолютно никаких проблем ни с одним, ни с другим

Победитель: HBase + Scribe + Ptail + Puma

В целом система, на которой остановился выбор, выглядит следующим образом:

  • HBase хранит все данные на распределенном кластере
  • Используется система логов, новые данные дописываются в конец
  • Система обрабатывает события и записывает результат в хранилище
  • Пользовательский интерфейс забирает данные из хранилища и отображает пользователям

Как обрабатывается один запрос:

  • Пользователь жмет на кнопку Like
  • Браузер инициирует AJAX запрос к серверу Facebook
  • Запрос записывается в лог в HDFS с помощью Scribe
  • Ptail - внутренний инструмент для чтения данных из нескольких Scribe-логов, на выходе данные разделяются на три потока, которые отправляются в разные кластеры в разных датацентрах:
    • Просмотры плагинов и виджетов
    • Просмотры в новостной ленте
    • Действия (плагины + новостная лента)
  • Puma - механизм для пакетной записи данных в HBase для снижения влияния "горячих" материалов:
    • HBase может справиться с очень большим потоком операций записи, но популярные материалы могут заставить упереться во ввод-вывод даже её
    • В среднем пакет запросов собирается в течении 1.5 секунд, хотелось бы больше - но из-за огромного количества URL очень быстро заканчивается оперативная память
  • Отображение данных пользователю:
    • Сам код для отображения написан на PHP
    • Работа с HBase осуществляется из Java
    • Для взаимодействия по традиции используется Thrift
  • Система кэширования используется для ускорения отображения страниц:
    • Чем более старые данные запрашиваются, тем реже они пересчитываются
    • Многое зависит от типа запрашиваемой статистики
  • MapReduce:
    • Данные передаются для дальнейшего анализа с помощью Hive
    • Сами логи удаляются через какой-то период времени
    • Помимо этого старая система анализа статистики все еще в действии, она используется для регулярных проверок результатов новой системы, а также в роли запасного плана, если что-то пойдет не так

О проекте

  • Продолжительность 5 месяцев
  • 2 с половиной разработчика самой системы
  • 2 разработчика пользовательского интерфейса
  • Всего было задействовано около 14 человек, включая менеджмент, дизайнера и системных администраторов

Направления развития

  • Списки популярных материалов: при текущем подходе их составление является сложной задачей
  • Отдельные пользовательские счетчики
  • Обобщение приложения для использования с другими сервисами, а не только с социальными плагинами
  • Распределение системы на несколько датацентров

Подводим итоги

У новых систем аналитики и сообщений много общего: большой поток входящих данных для записи, HBase и требование работы в реальном времени. Facebook делает ставку на HBase, Hadoop и HDFS, не смотря на громоздкость системы, когда другие предпочитают Cassandra из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным - покажет время.

Источники информации