Lambda architecture для realtime-аналитики — риски и преимущества / Николай Г...Ontico
HighLoad++ 2017
Зал «Сингапур», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2912.html
В 2017 построить аналитику на больших данных - это уже не достижение.
Витрины, отстающие на день - уже старые. Отставание на час - неплохо.
Достижением для 2017 является realtime BigData - доступные для широкого круга аналитические данные, отстающие от реальности на секунды (миллисекунды!).
...
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
В докладе было рассказано, зачем нужны сессии, где Badoo хранили их раньше, что придумали, почему решили использовать Tarantool, и к чему все это привело.
Lambda architecture для realtime-аналитики — риски и преимущества / Николай Г...Ontico
HighLoad++ 2017
Зал «Сингапур», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2912.html
В 2017 построить аналитику на больших данных - это уже не достижение.
Витрины, отстающие на день - уже старые. Отставание на час - неплохо.
Достижением для 2017 является realtime BigData - доступные для широкого круга аналитические данные, отстающие от реальности на секунды (миллисекунды!).
...
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
В докладе было рассказано, зачем нужны сессии, где Badoo хранили их раньше, что придумали, почему решили использовать Tarantool, и к чему все это привело.
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
BigПочта: как мы строили DataLake в Почте России / Алексей Вовченко (Luxoft)Ontico
HighLoad++ 2017
Зал «Москва», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3014.html
Мы планируем поделиться с аудиторией примером SuccessStory создания BigData-инфраструктуры (Hadoop) в Почте России. Мы расскажем про выбранные решения, мотивацию их выбора, а также про то, куда развивается продукт в Почте.
Доклад будет интересен всем проектам и компаниям, где только задумываются о развитии BigData-технологий, а также всем, кому интересно узнать, как устроена "внутри" современная Почта.
...
Брокер сообщений 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 стоит мониторить и как по ним понять, что что-то идёт не так.
Мастер-класс по BigData Tools для HappyDev'15Alexey Zinoviev
Данила, BigData Tool Master,
собрал Hadoop - кластер,
Запустил Dataset
Он скрипты на Scala
Run'ил на Spark постоянно
И писал в HDFSssss
Если во время доклада "Когда все данные станут большими..." мы будем говорить о вопросах и ответах, то на этом мастер-классе мы уже потопчемся в вотчине BigData-разработчиков.
Начнем с классики на Hadoop, познаем боль MapReduce job, потыкаем Pig + Hive, затем плавно свальсируем в сторону Spark и попишем код в легком и удобном pipeline - стиле.
Для кого хорошо подходит данный мастер-класс: вы умеете читать и понимать код на Java на уровне хотя бы Junior, умеете писать SQL-запросы, в универе вы ходили хоть на одну пару по матану или терверу, вас либо недавно поставили, либо вскоре поставят на проект, где надо уметь ручками работать с вышеперечисленным зверинцем. Ну или вам просто интересно посмотреть на мощь даннодробилок, написанных на Java, и у вас в анамнезе неудачный опыт с NoSQL/SQL, как хранилищем, которое было ответственно за все, включая аналитику.
Gobblin как ETL-фреймворк / Иван Ахлестин (Rambler&Co)Ontico
HighLoad++ 2017
Зал «Москва», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/2855.html
В своем докладе расскажу об ETL, как об общем классе задач извлечения, подготовки и доставки данных.
Поймем, какую нишу ETL занимает в мире BigData, какие существуют подходы и инструменты для операций над большими данными и какие требования могут к ним предъявляться.
Разберемся с тем, что такое Gobblin, открою нашу историю успеха по его внедрению и применению в отделе машинного обучения Rambler&Co, а также решаемые им задачи.
...
Dennis Anikin - Tarantool Case Studies in Mail.Ru GroupMail.ru Group
Денис рассказал о трех кейсах использования Tarantool в Mail.Ru Group - это система аутентификации пользователей, система нотификаций для мобильных приложений и система показа рекламы. Во всех трех кейсах Tarantool является краеугольным камнем распределенной серверной инфраструктуры, которая обслуживает суммарно порядка 100 миллионов пользователей в месяц.
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
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.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
BigПочта: как мы строили DataLake в Почте России / Алексей Вовченко (Luxoft)Ontico
HighLoad++ 2017
Зал «Москва», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3014.html
Мы планируем поделиться с аудиторией примером SuccessStory создания BigData-инфраструктуры (Hadoop) в Почте России. Мы расскажем про выбранные решения, мотивацию их выбора, а также про то, куда развивается продукт в Почте.
Доклад будет интересен всем проектам и компаниям, где только задумываются о развитии BigData-технологий, а также всем, кому интересно узнать, как устроена "внутри" современная Почта.
...
Брокер сообщений 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 стоит мониторить и как по ним понять, что что-то идёт не так.
Мастер-класс по BigData Tools для HappyDev'15Alexey Zinoviev
Данила, BigData Tool Master,
собрал Hadoop - кластер,
Запустил Dataset
Он скрипты на Scala
Run'ил на Spark постоянно
И писал в HDFSssss
Если во время доклада "Когда все данные станут большими..." мы будем говорить о вопросах и ответах, то на этом мастер-классе мы уже потопчемся в вотчине BigData-разработчиков.
Начнем с классики на Hadoop, познаем боль MapReduce job, потыкаем Pig + Hive, затем плавно свальсируем в сторону Spark и попишем код в легком и удобном pipeline - стиле.
Для кого хорошо подходит данный мастер-класс: вы умеете читать и понимать код на Java на уровне хотя бы Junior, умеете писать SQL-запросы, в универе вы ходили хоть на одну пару по матану или терверу, вас либо недавно поставили, либо вскоре поставят на проект, где надо уметь ручками работать с вышеперечисленным зверинцем. Ну или вам просто интересно посмотреть на мощь даннодробилок, написанных на Java, и у вас в анамнезе неудачный опыт с NoSQL/SQL, как хранилищем, которое было ответственно за все, включая аналитику.
Gobblin как ETL-фреймворк / Иван Ахлестин (Rambler&Co)Ontico
HighLoad++ 2017
Зал «Москва», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/2855.html
В своем докладе расскажу об ETL, как об общем классе задач извлечения, подготовки и доставки данных.
Поймем, какую нишу ETL занимает в мире BigData, какие существуют подходы и инструменты для операций над большими данными и какие требования могут к ним предъявляться.
Разберемся с тем, что такое Gobblin, открою нашу историю успеха по его внедрению и применению в отделе машинного обучения Rambler&Co, а также решаемые им задачи.
...
Dennis Anikin - Tarantool Case Studies in Mail.Ru GroupMail.ru Group
Денис рассказал о трех кейсах использования Tarantool в Mail.Ru Group - это система аутентификации пользователей, система нотификаций для мобильных приложений и система показа рекламы. Во всех трех кейсах Tarantool является краеугольным камнем распределенной серверной инфраструктуры, которая обслуживает суммарно порядка 100 миллионов пользователей в месяц.
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
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.
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Обновленный и дополненный доклад о микросервисах, специально для конференции DevOpsPro.ru
http://www.devopspro.ru/ivan-evtukhovich/?lang=ru
Углубил и расширил тему оргдизайна согласно закону Конвея, рассказал про смерть "аналоговых" компаний, и про платформы и DCOS-ы.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
The human race is on a journey from beasts to superheroes to gods. This short presentation frames our progression, and the key challenge that we need to face to get there.
Развитие DevOps/NoOps инструментов. Что было, что есть, что будет.Ivan Evtukhovich
Доклад для конференции SQADays 20, обзорно рассказывает про DevOps, переход к NoOps и микросервисной архитектуре, а также почему ручное тестирование умрет.
Адаптивная оптимизация запросов в реляционных СУБД / Олег Иванов (Postgres Pr...Ontico
Как известно, SQL - декларативный язык. В SQL-запросе заданы операции и свойства данных, над которыми эти операции должны быть выполнены. Но за выбор конкретного алгоритма выполнения запроса отвечает СУБД. В реляционных СУБД эти алгоритмы называются планами выполнения запроса, а процесс поиска наиболее быстрого плана - оптимизацией запроса. От выбора правильного плана существенно зависит скорость и эффективность выполнения запроса, а, значит, и производительность всей СУБД.
Наиболее популярным методом оптимизации запросов в современных реляционных СУБД является стоимостная оптимизация запросов, которая впервые была предложена в System R. В докладе описывается метод стоимостной оптимизации, рассматривается, какую статистику и как использует этот метод для оптимизации запросов. Затем разбираются основные недостатки стоимостной оптимизации и существующие подходы к их исправлению.
Основная тема доклада - адаптивная оптимизация запросов. Адаптивная оптимизация запросов - это новый подход, основанный на стоимостной оптимизации, но позволяющий избавиться от некоторых ее недостатков. Основная идея адаптивной оптимизации запросов - использование при оптимизации запросов статистики выполнения, собранной во время предыдущего исполнения похожих запросов. В отличие от адаптивной оптимизации, в классической стоимостной оптимизации используется только предварительно собранная статистика по данным.
В докладе рассматривается конкретный способ адаптивной оптимизации, основанный на методах машинного обучения. Для него приводятся результаты сравнения адаптивной и стоимостной оптимизации на примере СУБД PostgreSQL, обсуждаются плюсы и минусы адаптивной оптимизации, возможности её применения.
Автоматизация нагрузочного тестирования в связке JMeter + TeamСity + Grafana ...Positive Hack Days
1. Описание старого процесса сбора данных о тестах: как было до, что хорошего, что плохого
2. Influxdb, как хранилище time-series данных,
3. Zabbix - мониторинг нагрузочных стендов: windows и linux агенты, активный сбор данных, autodiscovery виртуальных машин в esx
4. Grafana, как способ превратить графики и дашборды в конфетку
5. Автоматизация нагрузки от пользователей через web-UI при помощи Jmeter, отображение статистики в реальном времени, CI в Teamcity
С чего начать внедрение Hadoop в компании / Алексей Еремихин (Badoo)Ontico
+ Обзор внутреннего устройства Hadoop и продуктов вокруг;
+ Как можно использовать для решения (спектр);
+ Как подходить к обоснованности использования даже в небольших проектах;
+ Hadoop в Badoo - история успеха;
+ Hadoop в Badoo - история проблем.
Про некоторые кейсы использования elasticsearch в современных проектах.
- С какими сложностями столкнулись
- Где успешо применили elasticsearch, а где был избыточен
Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Open source субд глазами обычного программистаSlach
Попытался "быстренько" пробежаться по всем СУБД с которыми работал за 20 лет и постараться вложить слушателям мысль что СУБД надо выбирать под нагрузку
и что для СУБД надо знать "алгоритмы" и "эксплуатацию"
libfpta: в памяти, с персистентностью, быстрее хайпаLeonid Yuriev
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
libfpta обеспечивает полностью параллельно выполнение запросов чтения/поиска без блокировок внутри БД и без атомарных операций, а также реализует эффективное хранение multi-value значений. Поэтому интегрально libfpta опережает по производительности и Tarantool и RocksDB. А разница с такими "быстрыми" решениями как Hazelcast или Apache Ignite достигает иногда 10-ти и более раз.
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
Tempesta FW: challenges, internals, use cases / Александр Крижановский (Tempe...Ontico
Tempesta FW — это Open Source гибрид Web-акселератора и файервола, специально разработанный для высокопроизводительной доставки контента вне зависимости от DDoS или наплыва посетителей.
В докладе будет рассказано про задачи, которые ставились при разработке проекта и пути их решения. Рассмотрим проблемы современных операционных систем в приложении к Web-стеку (система фильтрации, Web-сервер, application слой, БД), и как они решаются в Tempesta — некоторые уже решены, некоторые еще в процессе работы.
И самое главное — у нас появился рабочий прототип, и я расскажу про типовые примеры инсталляции, фичи и конфигурацию, а также покажу бенчмарки.
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
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 — как фундамент для масштабирования.
Similar to Pulsedb — система хранения временных рядов (20)
2. Проблема
• Надо хранить статистику
• Ежесекундные замеры
• Много стримов, много серверов
• Потом рисовать графики по выборкам
• Обновлять графики на лету
• Сжимать и удалять ненужные данные
Saturday, April 12, 14
3. NIH?
• Неизвестное количество метрик
• Необходимо встраивать в эрливидео
• Раздельное управление по аккаунтам
• Риалтайм графики
Saturday, April 12, 14
4. С чем сравнивали?
• rrdtool
• graphite (whisper/ceres)
• opentsdb (tempo-db, kairodb)
• influxdb
• прочее (librato, blueflood, seriesly,
circonus)
Saturday, April 12, 14
5. С чем НЕ сравнивали
• statsd
• rienmann
• хранилища логов
Saturday, April 12, 14
6. Терминология
• Равномерный временной ряд
• statsd — агрегация потока в равномерный
ряд
• rrdtool — хранение равномерных рядов
• агрегация — склейка двух равномерных
временных рядов
• downsampling — разрежение временного
ряда
Saturday, April 12, 14
8. rrdtool
• невообразимо медленный (fork на замер)
• нет возможности склейки метрик на лету
• плохое управление хранением
• слишком примитивный
Saturday, April 12, 14
9. Graphite
• не умеет склеивать метрики на лету
• графики строит сам
• никакого риалтайм фида
Saturday, April 12, 14
10. OpenTSDB
• Hadoop (со всеми вытекающими)
• Сам рисует графики
• Свой язык: sum:avg-2m:metric{tag=value}
• Умеет склеивать ряды
• Нет риалтайм фида
• Огромный оверхед на хранение
Saturday, April 12, 14
11. InfluxDB
• Очень развитое решение
• SQL-like язык запросов
• Агрегация рядов и операции над ними
• Умеет хранить и события
• Никакой явы!
• Появилось позже нашего кода
• Большой объём хранения и передачи
Saturday, April 12, 14
12. Прочие
• Пользуются Kassandra, Couch и прочей
инфернальщиной для хранения
• Или уже дорогущие промышленные
SCADA решения
Saturday, April 12, 14
13. Pulsedb
• Метрика — имя + теги
• Замер — UTC + имя + теги
• Библиотека + демон
• Компактное неточное хранение
• OpenTSDB-like язык запросов
• Websocket подписка
Saturday, April 12, 14
15. Структура
• HTTP Upgrade + текстовый протокол
• Собственный формат хранения
• Последняя минута в памяти
Saturday, April 12, 14
16. Хранение на диске
• 2 байта на замер
• хранение приблизительного значения
• 14 бит значения, 2 бита на порядок
• часовые блобы для каждой метрики
• мердж баз простым апдейтом
Saturday, April 12, 14
17. Транспорт по сети
• Statefull протокол
• Метрики кодируются номерами
• Время передается дельтой
• Значение неточное: 340K, 25G
Saturday, April 12, 14
18. Для сервиса
• Шардинг данных по аккаунтам
• Раздельная очистка секундных и
минутных данных
• Внешняя авторизация продюсеров
• Внешний резолвинг графиков
• Репликация
Saturday, April 12, 14
19. Немного цифр
• 20-50 серверов
• 30-150 каналов на каждом
• по 3 метрики с канала (in,out,clients)
• 2000 - 10 000 замеров в секунду
• 25 GB в месяц (10 млрд замеров)
• Одна холодная виртуалка в DigitalOcean
Saturday, April 12, 14