Павел Артёмкин — Разработка C++ API для реализации алгоритмов на больших графахYandex
В докладе рассказано о вычислительной модели на графах, в основе которой лежит механизм передачи сообщений между вершинами, а также о реализации в рамках данной модели API для написания алгоритмов на C++.
Презентация к докладу «Практические приёмы оптимизации .NET-приложений» с конференции dotnetconf (Челябинск, 19 апреля 2015) http://dotnetconf.ru/materialy/optimization
AI&BigData Lab 2016. Константин Герасименко: MOLAP: Новые границы возможного.GeeksLab Odessa
4.6.16 AI&BigData Lab
Upcoming events: goo.gl/I2gJ4H
Рассказ о том что такое MOLAP. Сравнение с традиционными подходами. Преимущества и недостатки. Рассказать как с этим работать на моём проекте.
Павел Артёмкин — Разработка C++ API для реализации алгоритмов на больших графахYandex
В докладе рассказано о вычислительной модели на графах, в основе которой лежит механизм передачи сообщений между вершинами, а также о реализации в рамках данной модели API для написания алгоритмов на C++.
Презентация к докладу «Практические приёмы оптимизации .NET-приложений» с конференции dotnetconf (Челябинск, 19 апреля 2015) http://dotnetconf.ru/materialy/optimization
AI&BigData Lab 2016. Константин Герасименко: MOLAP: Новые границы возможного.GeeksLab Odessa
4.6.16 AI&BigData Lab
Upcoming events: goo.gl/I2gJ4H
Рассказ о том что такое MOLAP. Сравнение с традиционными подходами. Преимущества и недостатки. Рассказать как с этим работать на моём проекте.
MyRocks: табличный движок для MySQL на основе RocksDBSergey Petrunya
MyRocks: табличный движок для MySQL на основе RocksDB.
Презентация с HighLoad++ 2015.
Рассказывается о принципах работы LSM-Trees, их реализации в RocksDB, зачем и как был сделан MyRocks, с какими проблемами столкнулись и как их решили.
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
Мы покажем, как можно перенести разработанные алгоритмы для работы с Big Data с минимальными изменениями исходных программ. Рассмотрим возможности по распараллеливанию счета на многоядерных процессорах (вычислительных кластерах) и графических процессорах, поддерживающих CUDA.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Dataset и Dataframe стали предпочтительными интерфейсами работы со Spark. Во многом благодаря активной разработке оптимизатора запросов Catalyst. В докладе мы рассмотрим мотивацию создания Spark.SQL и поймем, почему он так критически важен для работы PySpark. А так же подробно разберем как устроен Catalyst изнутри и как можно расширить его функциональность.
В своем докладе я расскажу о том, как мы перезапускали Рамблер/топ-100, доступных инструментах на рынке и о нашем опыте переезда с архитектуры батч-обсчета данных на обсчет данных в реальном времени. Расскажу об архитектуре двух решений и их компонентах. Кратко обсудим особенности обработки данных с помощью Python в Hive, фундаментальные проблемы хранения агрегатов, кратко рассмотрим преимущества и недостатки альтернативного подхода. Подробно разберем способ обработки меняющихся событий с помощью PySpark, способы работы с различными компонентами системы из PySpark, возникающие при этом проблемы и их решение. Плюс посмотрим на результаты, скорость работы новой системы и некоторые подводные камни.
MyRocks: табличный движок для MySQL на основе RocksDBSergey Petrunya
MyRocks: табличный движок для MySQL на основе RocksDB.
Презентация с HighLoad++ 2015.
Рассказывается о принципах работы LSM-Trees, их реализации в RocksDB, зачем и как был сделан MyRocks, с какими проблемами столкнулись и как их решили.
MyRocks Табличный Движок для MySQL / Алексей Майков (Facebook) / Сергей Петру...Ontico
Facebook использует MySQL в качестве основного хранилища данных. MySQL работает на десятках тысяч серверов в нескольких ЦОДах. В качестве дисков используются Flash-накопители. Они дают большую производительность, но дорогой ценой — MySQL хранит данные на диске в структуре B-tree, которая использует flash-диск неоптимальным образом. В масштабах Facebook'a цена вопроса измеряется миллионами долларов.
Для оптимального использования Flash-дисков в Facebook была разработана библиотека RocksDB. Она основана на LSM-деревьях и оптимизирована для работы в условиях высокой загрузки. Чтобы использовать ее из MySQL, [совместно с MariaDB] был разработан табличный движок — MyRocks.
Данный доклад посвящен RocksDB и MyRocks. Мы расскажем о принципах их работы и преимуществах, как их настраивать, и какие возможны подводные камни.
Авторы доклада — ведущие разработчики MyRocks от Facebook и MariaDB.
RocksDB и MyRocks доступны на GitHub для свободного использования, участие в разработке также приветствуется.
Мы покажем, как можно перенести разработанные алгоритмы для работы с Big Data с минимальными изменениями исходных программ. Рассмотрим возможности по распараллеливанию счета на многоядерных процессорах (вычислительных кластерах) и графических процессорах, поддерживающих CUDA.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Евгений Рыжков, Андрей Карпов Как потратить 10 лет на разработку анализатора ...Platonov Sergey
Кто-то верно подметил, что разработчики статических анализатора часто сталкиваются с "проблемой айсберга". Им сложно объяснить разработчикам, почему сложно написать и развивать статические анализаторы кода. Дело в том, что сторонние наблюдатели видят только вершину всего процесса, так как им доступен для изучения только простой интерфейс, который предоставляют анализаторы для взаимодействия с миром. Это ведь не графический редактор с сотнями кнопок и рычажков. В результате и возникает ощущение, что раз прост интерфейс взаимодействия, то и прост продукт. На самом деле статические анализаторы кода — это сложные программы, в которых живут и взаимодействуют разнообразнейшие методы поиска дефектов. В них реализуется множество экспертные системы, выдающие заключения о коде на основе как точных, так и эмпирических алгоритмах. В парном докладе, основатели анализатора PVS-Studio расскажут о том, как незаметно потратить 10 лет, чтобы написать хороший анализатор. Дьявол кроется в деталях!
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Dataset и Dataframe стали предпочтительными интерфейсами работы со Spark. Во многом благодаря активной разработке оптимизатора запросов Catalyst. В докладе мы рассмотрим мотивацию создания Spark.SQL и поймем, почему он так критически важен для работы PySpark. А так же подробно разберем как устроен Catalyst изнутри и как можно расширить его функциональность.
В своем докладе я расскажу о том, как мы перезапускали Рамблер/топ-100, доступных инструментах на рынке и о нашем опыте переезда с архитектуры батч-обсчета данных на обсчет данных в реальном времени. Расскажу об архитектуре двух решений и их компонентах. Кратко обсудим особенности обработки данных с помощью Python в Hive, фундаментальные проблемы хранения агрегатов, кратко рассмотрим преимущества и недостатки альтернативного подхода. Подробно разберем способ обработки меняющихся событий с помощью PySpark, способы работы с различными компонентами системы из PySpark, возникающие при этом проблемы и их решение. Плюс посмотрим на результаты, скорость работы новой системы и некоторые подводные камни.
Тензорные разложения для рекомендаций на Spark RamblerML
В Spark.ML для рекомендаций присутствует реализация алгоритма ALS, который достаточно хорошо себя показывает в большинстве реальных примеров. В докладе я хочу представить свою реализацию на Spark алгоритма iTALS, который является обобщением алгоритма матричных разложений ALS для тензоров. Такой алгоритм позволяет учитывать контекст в рекомендациях, делать их более точными и гибкими. В докладе будет рассказано о результатах сравнительного эксперимента ALS и iTALS.
Динамическая аллокация ресурсов или как жить в условиях общежития? RamblerML
При помощи динамической аллокации ресурсов в Spark можно добиться того, чтобы задача получала дополнительные ресурсы, если таковые имеются в свободном пуле. Таким образом, иногда, можно использовать всю мощь кластера и быстрее проводить вычисления. В докладе я расскажу, как динамическая аллокация ресурсов помогла сделать возможной работу 30-40 студентов в условиях приближающегося дедлайна по лабораторным работам и жить всем в счастье.
2. Criteo 1 TiB benchmark
Мотивация
• Появилась задача, не укладывающаяся в традиционную
схему “Local fit + Distributed apply” – предсказание CTR
• В открытых источниках не существует полноценного
(распределенного) теста Spark.ML
3. Criteo 1 TiB benchmark
Данные
• Открытый датасет – логи показов рекламы Criteo
• 1 TiB, около 4 млрд строк, 24 дня
• 40 колонок:
зависимая переменная (факт клика – {0, 1})
13 числовых фичей
26 категориальных фичей (хэши)
5. Criteo 1 TiB benchmark
Подготовка данных
• Сэмплы для обучения – , строк, n ∈ {4, 5, …, 9},
все дни кроме последнего
• Сэмпл для теста – 1 млн строк, последний день
• Criteo → LibSVM (для XGBoost) → VW (для Vowpal Wabbit)
↳DataFrame (для Spark.ML)
3⋅10
n
10
n
6. Criteo 1 TiB benchmark
План эксперимента
1.Взять сэмпл 10000 строк и обучить модель с настройками
по-умолчанию
2.Повторять, увеличивая сэмпл, пока хватает терпения
ждать результат
3.Сделать пункты 1, 2 для VW и XGBoost, замеряя время
обучения, качество модели, используемые ресурсы
4.Сделать пункты 1, 2 для моделей Spark.ML и сравнить с VW
и XGBoost
20. Criteo 1 TiB benchmark
VW & XGBoost – выводы
• XGBoost out-of-core ≈ in-memory по качеству, но на
порядок медленнее
• XGBoost in-memory на порядок медленнее VW
• XGBoost ≈ VW по качеству на большем на порядок
сэмпле
21. Criteo 1 TiB benchmark
Часть 2
Распределенное обучение Spark.ML
22. Criteo 1 TiB benchmark
Spark.ML – данные
• Binomial logistic regression – one-hot-encoding (*) hashing
trick, 100k hashes
• Random forest – данные как есть, 39 фичей (так как даже
на 1000 hashes очень долго обучается)
(*) – очень высокая кардинальность категориальных фичей
24. Criteo 1 TiB benchmark
Spark.ML – настройки
Кластер:
• 4 ядра и 16 GiB памяти на executor
• (сэмпл < строк) 64 executors – всего 256 ядер и 1 TiB
памяти
• (сэмпл ⩾ строк) 128 executors – всего 512 ядер и 2 TiB
памяти
10
9
10
9
27. Criteo 1 TiB benchmark
Spark.ML – time vs. cores
• Сэмпл
• Число ядер от 5 до 50
10
7
28. Criteo 1 TiB benchmark
Spark.ML – выводы
• Random forest – медленный, а с большим числом фичей
очень медленный
• Logistic regression нельзя хорошо приготовить
одновременно на всем диапазоне сэмплов
• Не стоит выделять слишком много ресурсов на
небольшие задачи
29. Criteo 1 TiB benchmark
Сравнение
Локальные и распределенные модели
32. Criteo 1 TiB benchmark
Выводы
• На больших данных Spark.ML быстрее, чем и XGBoost, и VW
• Но есть нюансы:
медленная работа с большими векторами
высокие побочные затраты на параллельные вычисления
для мелких задач
• В целом: для разных объемов данных – разные инструменты
33. Criteo 1 TiB benchmark
Мы на Github
https://git.io/v9sNz