ݺߣ

ݺߣShare a Scribd company logo

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

•
•
Mikhail Tabunov
Mikhail Tabunov

Слайды с highload2014

1 of 39
Downloaded 28 times
Как мы строили аналитическую платформу на несколько миллиардов событии в месяц Михаил Табунов Coub
Как мы строили аналитическую платформу на несколько миллиардов событии в месяц
Что такое Coub - Сервис про короткие зацикленные ролики - 50M MAU - 400M просмотров
Что такое Coub
Что такое события { "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
coub.com

More Related Content

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

  • 1. Как мы строили аналитическую платформу на несколько миллиардов событии в месяц Михаил Табунов Coub
  • 3. Что такое Coub - Сервис про короткие зацикленные ролики - 50M MAU - 400M просмотров
  • 5. Что такое события { "type": "web_timeline_page_loaded", "timestamp": "2014-09-09T09:15:00Z", "ip": "91.203.67.55", "page_number": 1, "timeline_type": "profile" }
  • 6. События - Нажал на кнопку - событие отправилось - У всех разная структура данных, трудно выделить какую-то четкую схему - Четыре основных клиента: Web сайт, Flash Player, iOS и Android.
  • 7. Клиенты - Base64 транспорт - Batch отправка
  • 8. Зачем это нужно - Самая честная статистика, с доступом к сырым данным - Для анализа и определения проблем компании - Для анализа поведения пользователей в продуктах
  • 9. Готовые решения - Дорого на больших объемах (> 10K$) - Нет доверия к алгоритмам подсчета - Трудно работать с сырыми данными - Быстро и просто
  • 10. Пишем свое - Непредсказуемый результат: вдруг не заработает - Неясные затраты - Покрывает абсолютно все возможные потребности в анализе данных
  • 11. Требования - Сделать что-то быстро и просто - Иметь возможность делать простые счетчики: считать количество событий какого-то типа - Делать примитивную аналитику (фильтры, distinct) - Если ничего не выйдет - не страшно
  • 12. Архитектура Log Collector NGINX Log Storage HTTP GET /rec.json?data=XXX ces.coub.com
  • 13. Архитектура Log Storage ces.coub.com Postgres Ruby worker
  • 14. Как хранятся данные 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);
  • 15. Старт эксплуатации - От первой строчки до старта в продакшн - 2 недели - Идея рабочая, пользоваться можно - Наконец появились требования и понимание что не так
  • 16. Проблемы - Медленная аналитика (120-180 секунд на запрос) - Ненадежно (одна машина, ненадежный storage) - Не масштабируемо (502, tcpconns, etc)
  • 17. Требования v2 - Данные важны - потерять нельзя ни в коем случае - Latency системы - не более 5 минут - Анализировать так быстро, как можем - Строить сложные группировки и нетипичные отчеты
  • 19. 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
  • 20. Log Fetching AWS S3 Log Fetcher Analysis DB Solution Web Frontend Пользователи (Аналитики)
  • 22. Frontend логика - Добавляем ip, страну и всю meta через GeoIP (MaxMind) - Ставим куки - ces_session_last_visit - ces_session_visit_num - ces_session_visit_page - ces_seswion_total_pageviews
  • 24. Что рассматривали - HADOOP (+ Hive) - AWS Redshift - HP Vertica - Druid - Mongo - PG + hStore
  • 25. Как выбирали - Скорость работы - Простота эксплуатации: - Просто поддерживать (комьюнити, узнаваемость) - Понятно хранит данные на диске
  • 26. Простота Скорость Сумма 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
  • 27. MongoDB - Простая и понятная архитектура - Сильное комьюнити, на любой вопрос есть ответ - Большой инструментарий для аналитики - Не навязывает какую-то определенную структуру данных
  • 28. 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", } ] - Тормозит пропорционально количеству событий - Каждый запрос - аггрегация
  • 29. MongoDB: структура хранения { "_id": {"$oid": "5408881ef7ca2f7995415b36"}, "event_type": "ios_editor_music_choosed", "is_full": false, "timestamp_minute": "2014-09-04T15:00:00Z", "events": [{…},{…}], “events_count": 2 }
  • 30. MongoDB - 101 тысяча документов за день. - 3 млн в месяц - Поминутное хранение событий - Быстро делает примитивные агрегаты - upsert для загрузки
  • 31. Железо, нагрузки - Xeon E5 6 cores - 128GB RAM - 4TB RAID - 9 mongo nodes на машину 2X
  • 32. Железо, нагрузки - 40 млн событий в день, 1.2 млрд в месяц - 750-1250 новых событий в секунду - ~8 млн объектов в коллекции - 1 месяц ~ 600ГБ данных в Mongo
  • 35. Юзкейсы и скорость работы - Сколько у нас загрузок плеера в украине вчера? - Интеграция аналитики в продукт - Куда пошли пользователи из фейсбука, попавшие на страницу коба? - Как часто в неделю люди пользуются лентой?
  • 36. Что плохо - Когда данные не в памяти, все очень очень медленно - Не для всех отчетов такая структура данных годится - Mongo не может делать большие агрегаты в памяти (16MB limit)
  • 37. Команда и цена - Backend: один я парттайм - Разработчики клиентов (Android, iOS) - 1100$ железо, трафик - 300$/месяц Amazon S3
  • 38. Планы - Продуктовые Алерты - Real Realtime - Интеграция с Google Docs - Больше отчетов и user friendly