Shadow Fight 2: архитектура системы аналитики для миллиарда событийVyacheslav Nikulin
Аудитория Shadow Fight 2, насчитывающая 50 миллионов игроков, ежедневно генерирует огромное количество событий, анализ которых происходит в реальном времени. Доклад посвящен архитектуре системы аналитики на основе поискового движка Elasticsearch. Будет рассмотрен технологический стек Elasticsearch, Logstash, Kibana, который позволяет в сжатые сроки создать гибкое и надежное решение. Также Вячеслав поможет разобраться со схемой обработки событий, моделью данных и особенностями настройки, расскажет о команде и трудозатратах на разработку и поддержку системы
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Shadow Fight 2: архитектура системы аналитики для миллиарда событийVyacheslav Nikulin
Аудитория Shadow Fight 2, насчитывающая 50 миллионов игроков, ежедневно генерирует огромное количество событий, анализ которых происходит в реальном времени. Доклад посвящен архитектуре системы аналитики на основе поискового движка Elasticsearch. Будет рассмотрен технологический стек Elasticsearch, Logstash, Kibana, который позволяет в сжатые сроки создать гибкое и надежное решение. Также Вячеслав поможет разобраться со схемой обработки событий, моделью данных и особенностями настройки, расскажет о команде и трудозатратах на разработку и поддержку системы
- Как начать развивать систему аналитики в компании, не имея армию data-инженеров.
- Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев.
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту).
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений.
Презентация с мероприятия https://habr.com/ru/company/tuturu/blog/426059/
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2710.html
В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
Всеволод Поляков "История одного мониторинга"Fwdays
«Мир изменился… Я чувствую это в воде… Я чувствую это в земле…»
Галадриэль
«Какой-то отсталый у неё мониторинг»
Сева Поляков
В этом докладе я хочу рассказать вам историю о современном мониторинге, на примере выбора для моего текущего проекта. Когда нужен prometheus, когда нужен SaaS и почему графит не умрёт. Также я постараюсь пройтись по всем новинкам и важным изменениям в современном мире мониторинга.
Общие сведения о clickhouse и возможностях его применения для аналитики на примере нашего опыта.
More useful info on our:
- website: https://clickky.biz
- blog: https://clickky.biz/blog
Sign up!
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 18:00
Тезисы:
http://backendconf.ru/2017/abstracts/2542.html
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Доклад Валерия Старынина на DevConf 2014. "StatsCollector, или "Мама! Он и ме...Badoo Development
Рассказываем о том, как мы в Badoo собираем статистику для каждого пользователя, обсчитываем каждое открытие страницы (и не только!), обрабатываем 120000 событий в секунду и планируем расширяться.
А также:
- как собирать события с тысяч серверов;
- как правильно распределять их для обработки на несколько серверов;
- как устроена система сбора простых логов и агрегированной статистики в Badoo;
- какие есть перспективы развития системы.
Доклад будет интересен любому человеку, который хочет построить подобную систему распределенного сбора и перераспределения статистики.
Примеры использования базы clickhouse для анализа данных.
Экспорт данных access.log в clickhouse. Примеры анализа скорости пользователей на основе логов сервера.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Использование Elasticsearch для организации поиска по сайтуOlga Lavrentieva
Дмитрий Жлобо, Ruby and Rails Developer в Twinslash
«Использование Elasticsearch для организации поиска по сайту»
Организация качественного поиска на сайте – сложная и нетривиальная задача. В своем докладе Дмитрий расскажет о том, как ее решить с помощью Elasticsearch.
Будет рассмотрено, как Elasticsearch работает с текстом или другими данными: от анализа и индексации документов до поиска и агрегации. По шагам и на примерах будет показано, как настроить поиск, учитывающий, например, морфологию и фонетику русского языка. Также Дмитрий расскажет, как все это использовать в приложениях на Ruby, как организовать добавление документов в индекс и др.
Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2710.html
В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.
ClickHouse: очень быстро и очень удобно / Виктор Тарнавский, Алексей Миловидо...Ontico
ClickHouse - высокопроизводительная база данных для больших данных и аналитики.
На ClickHouse основана Яндекс.Метрика - крупнейшая система веб-аналитики в России.
Ради чего мы написали свою базу данных? Ради скорости! ClickHouse работает невероятно быстро, быстрее всех известных нам конкурентов, и при этом может обрабатывать запросы по петабайтам данных.
Я расскажу про:
- Краткую историю создания проекта;
- Основные преимущества и особенности ClickHouse;
- Архитектура проекта; подход к хранению данных, отказоустойчивости, исполнению запросов;
- Как работает внутри, почему ClickHouse такой быстрый;
- Текущие кейсы использования в Метрике и других проектах Яндекса;
- Профит, который вы можете получить от ClickHouse.
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 14:00
Тезисы:
http://backendconf.ru/2017/abstracts/2778.html
Хотите научиться принимать решения на основе данных, но не знаете, с чего начать? Нужно записать миллионы событий, но не уверены, как делать это правильно? Вы не знаете, как быстро и дёшево строить аналитические отчеты или запутались в инструментах?
На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.
Всеволод Поляков "История одного мониторинга"Fwdays
«Мир изменился… Я чувствую это в воде… Я чувствую это в земле…»
Галадриэль
«Какой-то отсталый у неё мониторинг»
Сева Поляков
В этом докладе я хочу рассказать вам историю о современном мониторинге, на примере выбора для моего текущего проекта. Когда нужен prometheus, когда нужен SaaS и почему графит не умрёт. Также я постараюсь пройтись по всем новинкам и важным изменениям в современном мире мониторинга.
Общие сведения о clickhouse и возможностях его применения для аналитики на примере нашего опыта.
More useful info on our:
- website: https://clickky.biz
- blog: https://clickky.biz/blog
Sign up!
«Система развёртывания многокомпонентного сервиса» — Алексей Салов, YaC 20132ГИС Технологии
Нельзя, да и неправильно, проектировать веб-сервис как монолитное приложение. Рано или поздно это приведёт к его закостенелости или даже умиранию. С другой стороны, декомпозиция системы на несколько компонент приносит проблемы интеграционной зависимости, которые усложняют развёртывание или эксплуатацию приложения. В докладе я представлю систему, которая позволяет нам оперативно развёртывать многокомпонентное приложение 2ГИС API на три сервера в Новосибирске, Москве, Амстердаме. Особое внимание уделю гибкой архитектуре приложения, процессу развёртывания, версионированию кеша и индексов (Sphinx, C++-демоны), миграции схем БД (PostgreSQL), инструментам мониторинга и развёртывания (Zabbix, Chef, Phing, Yii).
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...Ontico
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 18:00
Тезисы:
http://backendconf.ru/2017/abstracts/2542.html
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Доклад Валерия Старынина на DevConf 2014. "StatsCollector, или "Мама! Он и ме...Badoo Development
Рассказываем о том, как мы в Badoo собираем статистику для каждого пользователя, обсчитываем каждое открытие страницы (и не только!), обрабатываем 120000 событий в секунду и планируем расширяться.
А также:
- как собирать события с тысяч серверов;
- как правильно распределять их для обработки на несколько серверов;
- как устроена система сбора простых логов и агрегированной статистики в Badoo;
- какие есть перспективы развития системы.
Доклад будет интересен любому человеку, который хочет построить подобную систему распределенного сбора и перераспределения статистики.
Примеры использования базы clickhouse для анализа данных.
Экспорт данных access.log в clickhouse. Примеры анализа скорости пользователей на основе логов сервера.
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Использование Elasticsearch для организации поиска по сайтуOlga Lavrentieva
Дмитрий Жлобо, Ruby and Rails Developer в Twinslash
«Использование Elasticsearch для организации поиска по сайту»
Организация качественного поиска на сайте – сложная и нетривиальная задача. В своем докладе Дмитрий расскажет о том, как ее решить с помощью Elasticsearch.
Будет рассмотрено, как Elasticsearch работает с текстом или другими данными: от анализа и индексации документов до поиска и агрегации. По шагам и на примерах будет показано, как настроить поиск, учитывающий, например, морфологию и фонетику русского языка. Также Дмитрий расскажет, как все это использовать в приложениях на Ruby, как организовать добавление документов в индекс и др.
Talk given for the #phpbenelux user group, March 27th in Gent (BE), with the goal of convincing developers that are used to build php/mysql apps to broaden their horizon when adding search to their site. Be sure to also have a look at the notes for the slides; they explain some of the screenshots, etc.
An accompanying blog post about this subject can be found at http://www.jurriaanpersyn.com/archives/2013/11/18/introduction-to-elasticsearch/
Денис Колошко, Пример нагруженной системы на базе продуктов Microsoft, Amazon...Tanya Denisyuk
Будет показан пример архитектуры популярной социальной сети в Англии, переработанной на новом стеке, чтобы решить проблемы производительности, отказоустойчивости и горизонтального масштабирования. Новый стек базируется на технологиях: .NET, SignalR, Couchbase, RabbitMQ, ElasticSearch, Amazon Services (CloudFront, S3, EC2, Route 53, Balancer), Windows, Linux. Цель: показать одну из моделей архитектуры нагруженных веб-систем, практики и возможные подводные камни при разработке высоконагруженных Интернет систем.
Движение по хрупкому дну / Сергей Караткевич (servers.ru)Ontico
Сегодня Интернет увлечен микросервисами, контейнерами и immutable-инфраструктурой. Очень сложно не поддаться искушению внедрить что-то подобное в компании, в которой вы работаете сейчас. Я попытаюсь отговорить вас использовать эти технологии во вред приложению, себе и бизнесу компании в целом. Я расскажу о типовом проекте, который был запущен в 20 странах за 4 месяца, проблемах, которые я встретил, и выводах, которые я сделал.
- Почему микросервисы не спасут, а похоронят ваш проект.
Я расскажу на основе собственного опыта, почему не стоит увлекаться микросервисами для небольших проектов, почему благие намерения — упрощение деплоя и увеличение числа деплоев, увеличение доступности и улучшение масштабирования ведут к отсутствию гибкости и критическому уменьшению стабильности системы.
- Почему ваша система слишком сложна для своих задач.
Я расскажу, почему не стоит усложнять систему, почему, скорее всего, ваша система слишком сложна для задач, которые она решает и почему вы не контролируете то, что происходит в системе. Я объясню, почему вы потратите все свое время на отладку сложной системы, вместо того чтобы решать задачи бизнеса.
- Почему Docker используется неправильно.
Будут предоставлены реальные примеры использования Docker для нового проекта и для портированного проекта, я объясню, с какими проблемами сталкиваются операторы при работе с Docker на живых примерах, объясню, почему вы, скорее всего, используете Docker неправильно, и предложу варианты, как этого избежать.
- Почему immutable слишком статичен для вашей компании.
Я расскажу про свой опыт работы с immutable и объясню, почему, на мой взгляд, переход к подобной инфраструкт
Deep Dive on ElasticSearch Meetup event on 23rd May '15 at www.meetup.com/abctalks
Agenda:
1) Introduction to NOSQL
2) What is ElasticSearch and why is it required
3) ElasticSearch architecture
4) Installation of ElasticSearch
5) Hands on session on ElasticSearch
ElasticSearch introduction talk. Overview of the API, functionality, use cases. What can be achieved, how to scale? What is Kibana, how it can benefit your business.
A presentation about the deployment of an ELK stack at bol.com
At bol.com we use Elasticsearch, Logstash and Kibana in a logsearch system that allows our developers and operations people to easilly access and search thru logevents coming from all layers of its infrastructure.
The presentations explains the initial design and its failures. It continues with explaining the latest design (mid 2014). Its improvements. And finally a set of tips are giving regarding Logstash and Elasticsearch scaling.
These slides were first presented at the Elasticsearch NL meetup on September 22nd 2014 at the Utrecht bol.com HQ.
Лучшие практики Continuous Delivery с Docker / Дмитрий Столяров (Флант)Ontico
Потребность в отстроенном процессе Continuous Delivery встает перед каждым развивающимся highload-проектом. Чем больше серверов и составных приложений, чем выше динамика релизов, тем раньше проект сталкивается с данной потребностью, и тем острее она стоит.
Многие команды эксплуатации смогли отстроить этот процесс, некоторые добились впечатляющих результатов, а некоторые — потерпели неудачу. Но все из них знают, что их процесс можно улучшить: сделать быстрее, надежнее, предсказуемее и удобнее.
В этом докладе я хочу обобщить и систематизировать лучшие практики построения процесса Continuous Delivery с использованием актуальных Open Source технологий (Docker, Chef, Gitlab, Kubernetes), а также обозначить известные проблемы и потенциальные пути их решения.
Будет предпринята попытка однозначно ответить на следующие практические вопросы:
- Почему пора всем переходить на Docker? Как лучше собирать Docker-образы? Как лучше доставлять и хранить Docker-образы?
- Как правильно построить процесс разработки Infrastructure as Code (IaC)?
- Как оптимально интегрировать автоматическое и ручное тестирование в процесс Continuous Delivery?
- Как перестать бояться регулярных выкатов новых версий и сделать этот процесс надежным?
- Почему Continuous Delivery не заканчивается релизом новой версии и зачем нужен Kubernetes?
Curso en español del motor de búsqueda distribuido Elasticsearch. De nivel básico a medio, cubre las principales características y detallas algunas funcionalidades avanzadas: configuración del cluster, mapeos, búsqueda de texto libre, relevancia de resultados, etc.
Fue diseñado para dictarse en la empresa Mercadolibre con lo que hace foco en aspectos de calidad de un site alto tráfico, como alta disponibilidad, performance y tolerancia a fallos.
Attack monitoring using ElasticSearch Logstash and KibanaPrajal Kulkarni
With growing trend of Big data, companies are tend to rely on high cost SIEM solutions. However, with introduction of open source and lightweight cluster management solution like ElasticSearch this has been the highlight of the year. Similarly, the log aggregation has been simplified by logstash and kibana providing a visual look to the complex data structure. This presentation will exactly cater to this need of having a appropriate log analysis+Detecting Intrusion+Visualizing data in a powerful interface.
Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"IT Event
Мы рассмотрим важные особенности построения архитектуры распреденных кластеров NoSQL с использованием ресурсов Amazon Web Services, мы затронем такие аспекты как: архитектура гео распределенных кластеров, оптимизация производительности, выбор основных опций для деплоймента и ряд других аспектов. В докладе мы сконцентрируемся на таких популярных базах данных, как Cassandra, MongoDB и некоторых других.
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
BigMemory - работа с сотнями миллионов бизнес-объектов / Дмитрий Хмаладзе (Ag...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 11:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2683.html
Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.
...
Выступление на Pgconf Москва 2015. История развития сервиса МойСклад, статистика эксплуатации, особенности внутренней реализации работы с СУБД PostgreSQL.
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"Technopark
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана. Курс "Базы данных".
Лекция №10 "Нереляционное решение в области баз данных — NoSQL". Лектор - Станислав Ступников.
Вводная часть посвящена определению и истории развития концепции NoSQL. Даются характеристики, рассказывается о способах использования. Рассматриваются виды NoSQL БД, теоретические основы NoSQL, а в конце лекции обсуждаются недостатки NoSQL-решений, а также проводится сравнение разных NoSQL-решений.
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9obOz5K695ugYuiOOCBciEi
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...Ontico
Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.
Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.
Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.
Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.
Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.
3. Поиск готового решения
● Готово к использованию
● Технические и функциональные ограничения
● Высокая цена
4. РСУБД
● Знакомый SQL - путь
● Сложно масштабировать и поддерживать
● А может нам не нужна РСУБД?
5. NoSQL
● Документоориентированность, масштабируемость, отказоустойчивость
● Огромный спектр технологий
Hadoop HBase Cassandra MongoDB Redis Riak Kafka Storm RabbitMQ ZeroMQ Spark etc
● Нет опыта - разработка может занять годы
7. Elasticsearch за 10 секунд
● Документо-ориентированное хранилище, не требующее описание схемы
таблиц
● Распределенное, горизонтально-масштабируемое, отказоустойчивое
● RESTful API (json поверх http)
● Мощное поисковый движок
● Написан на Java, расширяем
● Активно развивается (> 15 релизов в этом году)
● Разработан поверх Apache Lucene
● Открытый исходный код (Apache License 2.0)
● Много пользователей (StackOverflow, GitHub, TheGuardian, Bloomberg)
10. Терминология
● Узел - один сервер (один инстанс elasticsearch/jvm)
● Кластер - множество узлов
● Документ - базовый юнит информации, который может быть
индексирован.
● Индекс - коллекция документов с походими характеристиками
● Тип - множество документов с одинаковым набором полей
● Шард - неделимый юнит масштабирования
● Реплика - копия шарда
Примерное соотвествие между понятиями РСУБД и Elasticsearch
● РСУБД ⇒ База данных/Схема⇒ Таблица ⇒ Строка ⇒ Столбец
● Elasticsearch ⇒ Индекс ⇒ Тип ⇒ Документ ⇒ Поле
13. Процессинг логов
● Генерация и сохранение логов в клиенте
● Отправка логов на сервер
● Фильтрация логов, добавление полей в события, сохранение лога на
диск
● Централизация логов
● Импорт логов в Elasticsearch
● Визуализация данных
14. Генерация событий в клиенте
● Эвент - это json-объект
● Проектирование перечня эвентов и их структуры
○ Список эвентов
○ Обязательные параметры эвента
○ Дополнительные параметры
15. Отправка логов на сервер
● Http-запрос на веб-сервер
● Бэкенд на PHP
● Прореживание логов
○ Каждый Nый
○ Плательщик
○ High level
○ Участник A/B теста
○ Некоторые события нужно принимать от всех юзеров
○ Стратегии можно комбинировать
○ Фильтрация читеров
16. Обработка логов на сервере
● Фильтрация логов
● Добавление полей в событие
● Сохранение логов на диск
17. Централизация логов
● Несколько серверов (ios, android etc) с установленным logstash
● Logstash отслеживает изменения в директории и отсылает новые данные
на сервер консолидации логов
● Logstash на центральном сервере принимает данные и отправляет их в
elasticsearch
18. Маппинг данных
● Иногда необходим явный маппинг
○ Nested объекты
○ Timestamp в виде long
○ Специфичный настройки индексирования
● Задается шаблоном в файле или с помощью REST API
19. Разбиение по индексам
● User-based индексы
● Timestamp-based индексы
○ /logs-2014-09-01/purchase, /logs-2014-09-02/fight_end
○ Удалять лучше индекс целиком
20. О чем не стоит забывать
● Mapping explosion
○ Неправильно: {"1": 1} {"2": 4} {"3": 9} {"4": 16} {"5": 25}
○ Правильно: {"key": 1, "value": 1} {"key": 2, "value": 4}
● Длинные GC паузы
● Много вложенных агрегаций
● Проблема зиллиона шардов
○ Индекс одного документа приведет к OOM
24. Цифры
● Один сервер
500 ГБ SSD, 4x-ядерный E3-1270 3.50GHz, 32 GB RAM
● 50 rps индексирования, в пике было 10к
● в день 3М событий, 1ГБ в elasticsearch
● 1-2% cpu load
● всего 100M документов
● Поиск < 100 мс
25. Команда, поддержка
● Сейчас занято 1.5 человека
● Запустили в продакшн за 2 месяца силами 2.5 человек
● Геймдизайнеры осваивают инструмент и сами пишут запросы
● Большие планы на будущее: больше гд-отчетов, статистика пуш
уведомлений, внедрение в другие проекты компании