Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

3.031 visualizaciones

Publicado el

Слайды с highload2014

Publicado en: Software
  • Inicia sesión para ver los comentarios

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

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

×