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 очень быстро заканчивается оперативная память
- Отображение данных пользователю:
- Система кэширования используется для ускорения отображения страниц:
- Чем более старые данные запрашиваются, тем реже они пересчитываются
- Многое зависит от типа запрашиваемой статистики
- MapReduce:
- Данные передаются для дальнейшего анализа с помощью Hive
- Сами логи удаляются через какой-то период времени
- Помимо этого старая система анализа статистики все еще в действии, она используется для регулярных проверок результатов новой системы, а также в роли запасного плана, если что-то пойдет не так
О проекте
- Продолжительность 5 месяцев
- 2 с половиной разработчика самой системы
- 2 разработчика пользовательского интерфейса
- Всего было задействовано около 14 человек, включая менеджмент, дизайнера и системных администраторов
Направления развития
- Списки популярных материалов: при текущем подходе их составление является сложной задачей
- Отдельные пользовательские счетчики
- Обобщение приложения для использования с другими сервисами, а не только с социальными плагинами
- Распределение системы на несколько датацентров
Подводим итоги
У новых систем аналитики и сообщений много общего: большой поток входящих данных для записи, HBase и требование работы в реальном времени. Facebook делает ставку на HBase, Hadoop и HDFS, не смотря на громоздкость системы, когда другие предпочитают Cassandra из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным - покажет время.
Источники информации
- Facebook's New Realtime Analytics System: HBase To Process 20 Billion Events Per Day
- Building Realtime Insights (видео)
