Как мы строили аналитическую платформу на несколько миллиардов событии в месяц

Как мы строили
аналитическую платформу
на несколько миллиардов
событии в месяц
Михаил Табунов
Coub

Что такое Coub
- Сервис про короткие зацикленные
ролики
- 50M MAU
- 400M просмотров

Что такое события
{
"type": "web_timeline_page_loaded",
"timestamp": "2014-09-09T09:15:00Z",
"ip": "91.203.67.55",
"page_number": 1,
"timeline_type": "profile"
}

События
- Нажал на кнопку - событие отправилось
- У всех разная структура данных, трудно
выделить какую-то четкую схему
- Четыре основных клиента: Web сайт, Flash
Player, iOS и Android.

Клиенты
- Base64 транспорт
- Batch отправка

Зачем это нужно
- Самая честная статистика, с доступом к
сырым данным
- Для анализа и определения проблем
компании
- Для анализа поведения пользователей в
продуктах

Готовые решения
- Дорого на больших объемах (> 10K$)
- Нет доверия к алгоритмам подсчета
- Трудно работать с сырыми данными
- Быстро и просто

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

Требования
- Сделать что-то быстро и просто
- Иметь возможность делать простые счетчики:
считать количество событий какого-то типа
- Делать примитивную аналитику (фильтры, distinct)
- Если ничего не выйдет - не страшно

Архитектура
Log
Collector
NGINX
Log
Storage
HTTP GET
/rec.json?data=XXX
ces.coub.com

Архитектура
Log Storage
ces.coub.com
Postgres
Ruby
worker

Как хранятся данные
CREATE TABLE events_2014_04_18 (
type character varying(255),
datetime time without time zone,
data hstore
);
CREATE INDEX index_events_2014_04_18_on_type
ON events_2014_04_18 USING btree (type);

Старт эксплуатации
- От первой строчки до старта в
продакшн - 2 недели
- Идея рабочая, пользоваться можно
- Наконец появились требования и
понимание что не так

Проблемы
- Медленная аналитика (120-180
секунд на запрос)
- Ненадежно (одна машина,
ненадежный storage)
- Не масштабируемо (502, tcpconns,
etc)

Требования v2
- Данные важны - потерять нельзя ни в коем
случае
- Latency системы - не более 5 минут
- Анализировать так быстро, как можем
- Строить сложные группировки и нетипичные
отчеты

Запись и
хранение
логов

Frontends
Log Collector &
Log Uploader
NGINX
HTTP GET
/rec.json?data=XXX
AWS S3
f01.ces.coub.com; f02.ces.coub.com; f03.ces.coub.com

Log Fetching
AWS S3
Log
Fetcher
Analysis
DB
Solution
Web
Frontend
Пользователи
(Аналитики)

Чуть-чуть про node.js

Frontend логика
- Добавляем ip, страну и всю meta
через GeoIP (MaxMind)
- Ставим куки
- ces_session_last_visit
- ces_session_visit_num
- ces_session_visit_page
- ces_seswion_total_pageviews

Что рассматривали
- HADOOP (+ Hive)
- AWS Redshift
- HP Vertica
- Druid
- Mongo
- PG + hStore

Как выбирали
- Скорость работы
- Простота эксплуатации:
- Просто поддерживать (комьюнити,
узнаваемость)
- Понятно хранит данные на диске

Простота Скорость Сумма
Hadoop, Hive 1 2 3
Redshift 3 5 8
Vertica 2 5 7
Druid 1 5 6
PG 4 5 9
Mongo 5 5 10

MongoDB
- Простая и понятная архитектура
- Сильное комьюнити, на любой вопрос
есть ответ
- Большой инструментарий для аналитики
- Не навязывает какую-то определенную
структуру данных

MongoDB: структура хранения
[
{
"type": "web_timeline_page_loaded",
"timestamp": "2014-09-09T09:15:00Z",
},
{
"type": “fp_player_started”,
"timestamp": "2014-09-10T09:15:00Z",
},
{
"type": "fp_player_finished",
"timestamp": "2014-09-10T09:15:00Z",
}
]
- Тормозит
пропорционально
количеству событий
- Каждый запрос -
аггрегация

MongoDB: структура хранения
{
"_id": {"$oid": "5408881ef7ca2f7995415b36"},
"event_type": "ios_editor_music_choosed",
"is_full": false,
"timestamp_minute": "2014-09-04T15:00:00Z",
"events": [{…},{…}],
“events_count": 2
}

MongoDB
- 101 тысяча документов за день.
- 3 млн в месяц
- Поминутное хранение событий
- Быстро делает примитивные
агрегаты
- upsert для загрузки

Железо, нагрузки
- Xeon E5 6 cores
- 128GB RAM
- 4TB RAID
- 9 mongo nodes на
машину
2X

Железо, нагрузки
- 40 млн событий в день, 1.2 млрд в месяц
- 750-1250 новых событий в секунду
- ~8 млн объектов в коллекции
- 1 месяц ~ 600ГБ данных в Mongo

Лучшая аналитика - Excel

Юзкейсы и скорость работы
- Сколько у нас загрузок плеера в украине вчера?
- Интеграция аналитики в продукт
- Куда пошли пользователи из фейсбука,
попавшие на страницу коба?
- Как часто в неделю люди пользуются лентой?

Что плохо
- Когда данные не в памяти, все очень очень
медленно
- Не для всех отчетов такая структура данных
годится
- Mongo не может делать большие агрегаты в
памяти (16MB limit)

Команда и цена
- Backend: один я парттайм
- Разработчики клиентов (Android, iOS)
- 1100$ железо, трафик
- 300$/месяц Amazon S3

Планы
- Продуктовые Алерты
- Real Realtime
- Интеграция с Google Docs
- Больше отчетов и user friendly

Как мы строили аналитическую платформу на несколько миллиардов событии в месяц

More Related Content

Как мы строили аналитическую платформу на несколько миллиардов событии в месяц