HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Не все базы данных одинаково полезны. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
О компании:
Badoo — не только самая большая, но и одна из самых инновационных и высокотехнологичных компаний в сфере социальных сетей, входящий в топ-100 крупнейших мировых проектов. Она насчитывает 139 миллионов пользователей, и еще более чем 100,000 новых пользователей присоединяются к ней каждый день.
Badoo — это глобальная социальная онлайн-система, которая дает возможность знакомиться с новыми людьми, живущими пососедству и по всему миру. Мы предлагаем многочисленные технические возможности социальных сетей, делая акцент на играх и сервисах, позволяющих расширить социальный круг. Мы продолжаем расширять географию своего пребывания и использовать самые последние технологии в сетевом общении, позволяющие нашим пользователям знакомиться друг с другом и изменять реальность вокруг себя.
Видеоприглашение на конференцию:
http://www.youtube.com/watch?v=2mRGcz0UODY
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Мастер-класс по 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, как хранилищем, которое было ответственно за все, включая аналитику.
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Не все базы данных одинаково полезны. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
О компании:
Badoo — не только самая большая, но и одна из самых инновационных и высокотехнологичных компаний в сфере социальных сетей, входящий в топ-100 крупнейших мировых проектов. Она насчитывает 139 миллионов пользователей, и еще более чем 100,000 новых пользователей присоединяются к ней каждый день.
Badoo — это глобальная социальная онлайн-система, которая дает возможность знакомиться с новыми людьми, живущими пососедству и по всему миру. Мы предлагаем многочисленные технические возможности социальных сетей, делая акцент на играх и сервисах, позволяющих расширить социальный круг. Мы продолжаем расширять географию своего пребывания и использовать самые последние технологии в сетевом общении, позволяющие нашим пользователям знакомиться друг с другом и изменять реальность вокруг себя.
Видеоприглашение на конференцию:
http://www.youtube.com/watch?v=2mRGcz0UODY
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Мастер-класс по 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, как хранилищем, которое было ответственно за все, включая аналитику.
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
Кирилл Алешин, Ламбда Архитектура на практикеTanya Denisyuk
Кирилл расскажет о таких темах, как практичность современных распределенных файловых систем для складирования структурированных данных, сложности синхронизации данных на разных Ламбда уровнях, а также несколько Big Data новинок для закрытия брешей в традиционном описании Ламбда архитектуры. Кирилл расскажет как о пользе этой модели, так и об извлеченных уроках ее использования.
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
[JokerConf] Верхом на реактивных стримах, 10/13/2016Viktor Gamov
Вы из тех, кто считает, что, распараллелив любой цикл, можно улучшить перформанс, и Collection.parallelStream() — ваш лучший друг? А как вам идея — вбросить ещё пачку машин и получить распределенную обработку? Интересно? Тогда для вас этот доклад обязателен к просмотру.
Виктор познакомит слушателей со своим другом, Ориентированным (Направленным) Ациклическим Графом (или Маркизом?!), и покажет, как с его помощью была организована распределенная высокопроизводительная система обработки информации в памяти поверх нашего знакомого Java 8 Stream API.
Этот доклад я презентовал на конференции BI тренды 11 октября 2012 года в Москве. http://events.cnews.ru/events/programm/bi_instrumenty_v_rossii__poslednie_trendy.shtml
Брокер сообщений 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 стоит мониторить и как по ним понять, что что-то идёт не так.
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
Кирилл Алешин, Ламбда Архитектура на практикеTanya Denisyuk
Кирилл расскажет о таких темах, как практичность современных распределенных файловых систем для складирования структурированных данных, сложности синхронизации данных на разных Ламбда уровнях, а также несколько Big Data новинок для закрытия брешей в традиционном описании Ламбда архитектуры. Кирилл расскажет как о пользе этой модели, так и об извлеченных уроках ее использования.
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
[JokerConf] Верхом на реактивных стримах, 10/13/2016Viktor Gamov
Вы из тех, кто считает, что, распараллелив любой цикл, можно улучшить перформанс, и Collection.parallelStream() — ваш лучший друг? А как вам идея — вбросить ещё пачку машин и получить распределенную обработку? Интересно? Тогда для вас этот доклад обязателен к просмотру.
Виктор познакомит слушателей со своим другом, Ориентированным (Направленным) Ациклическим Графом (или Маркизом?!), и покажет, как с его помощью была организована распределенная высокопроизводительная система обработки информации в памяти поверх нашего знакомого Java 8 Stream API.
Этот доклад я презентовал на конференции BI тренды 11 октября 2012 года в Москве. http://events.cnews.ru/events/programm/bi_instrumenty_v_rossii__poslednie_trendy.shtml
Брокер сообщений 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 стоит мониторить и как по ним понять, что что-то идёт не так.
Автоматизация процесса разработки "Мобильной почты Mail.Ru" на базе продуктов...Ontico
- Jira как ядро инфраструктурной экосистемы.
Что такое JIRA.
Почему JIRA.
JIRA Agile - хочу гибко.
- Ревью кода и управление репозиториями с помощью Atlassian Stash.
Создание и управления репозиториями. Плюсы.
Процесс Code Review с Atlassian Stash.
Сравнение с Atlassian Fisheye/Crucible
- Непрерывная интеграция на базе Atlassian Bamboo.
Проекты и планы.
Удаленные агенты.
Сборка и тестирование продукта.
Плюсы и минусы.
- Замкнутый цикл или красота интеграции представленных сервисов.
Как избавиться от рутинных процессов и сделать так, чтобы инфраструктура работала на тебя.
Chitosan (2-amino-2deoxy-(1→4)-β-D-glucopyranan), a polyaminosaccharide, normally obtained by alkaline deacetylation of chitin is the principal component of living organisms such as fungi and crustacea.
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
Не все базы данных одинаково полезны. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
Машинное обучение в электронной коммерции - практика использования и подводны...Ontico
РИТ++ 2017, секция ML + IoT + ИБ
Зал Белу-Оризонти, 5 июня, 16:00
Тезисы:
http://ritfest.ru/2017/abstracts/2532.html
Простыми словами расскажем о популярных, эффективных и используемых в нашей компании техниках применения машинного обучения для привлечения и удержания клиентов:
- кластеризации товарного каталога,
- классификации клиентов (готовых перейти на платный тариф, готовых уйти, способных принести прибыль),
- повышении релевантности e-mail-рассылок.
Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.
Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.
Распространенные ошибки применения баз данныхSergey Xek
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3111.html
This talk is prepared as a bunch of slides, where each slide describes a really bad way people can screw up their PostgreSQL database and provides a weight - how frequently I saw that kind of problem. Right before the talk I will reshuffle the deck to draw ten random slides and explain you why such practices are bad and how to avoid running into them.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
10. Мы стали хранить и анализировать
то, что раньше казалось ерундой
11. BigData – это..
• Работа с объемом данных, которые не влезает в
один Excel – файл?
12. BigData – это..
• Работа с объемом данных, которые не влезает в
один Excel – файл?
• Способ продать клиенту старые тряпки в новой
упаковке?
13. BigData – это..
• Работа с объемом данных, которые не влезает в
один Excel – файл?
• Способ продать клиенту старые тряпки в новой
упаковке?
• Спасительное средство, когда MySQL для моего
сайта тормозит?
14. BigData – это..
• Работа с объемом данных, которые не влезает в
один Excel – файл?
• Способ продать клиенту старые тряпки в новой
упаковке?
• Спасительное средство, когда MySQL для моего
сайта тормозит?
• Совокупность методологий и технологий
построения систем, хранилищ и средств анализа
данных с высокой степенью горизонтального
масштабирования и «стрессоустойчивостью»?
15. У меня 1 млн записей в MySQL. Это
уже BigData?
16. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
17. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
• Зачем тюнить если есть Hadoop и Amazon?
18. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
• Зачем тюнить если есть Hadoop и Amazon?
• А вы знаете сколько стоит Amazon?
19. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
• Зачем тюнить если есть Hadoop и Amazon?
• А вы знаете сколько стоит Amazon?
• А у вас есть статистика по запросам?
20. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
• Зачем тюнить если есть Hadoop и Amazon?
• А вы знаете сколько стоит Amazon?
• А у вас есть статистика по запросам?
• А вы профилировали хоть раз?
21. У вас была SQL БД с медленными
запросами?
• А не пойти ли вам потюнить?
• Зачем тюнить если есть Hadoop и Amazon?
• А вы знаете сколько стоит Amazon?
• А у вас есть статистика по запросам?
• А вы профилировали хоть раз?
• А какой прогноз по объему данных на
ближайший год?
24. Типичный EPAM BigData кластер
• 450 машин
• Master Nodes (24 ядра, 158 Gb RAM).
• Data Nodes (24|32 ядра, 96|128 Gb RAM).
• Средняя YARN Queue utilization 85% (по
дням).
• 12Pb – емкость хранения данных
25. Биг дата – это когда что-то
невероятно большое, да?
26. Нет, дело не только в размере
• У нас становится просто больше типов и
моделей данных, в том числе скрытых от нас
• Нам нужно так быстро обрабатывать
входящие данные, что через парус секунд
они станут никому не нужны и могут быть
просто удалены
• И да, нам иногда нужно что-то сложнее чем
отчет по остаткам на складах
27. Это просто данные, которые на
данный момент сложно …
• Хранить
• Обрабатывать
• Искать в них что-то
• Анализировать
• Передавать по сети
• Визуализировать
29. Parallel Computin vs
Distributed Computing
• Можно запустить на 1000 ядерной машине
• Но тогда нам нужен суперкомпьютер
• А можно каждой маленькой машинке
считать, хранить и обрабатывать свою
порцию данных отдельно!
• Круто, а кто писать будет всю
инфраструктуру?
39. Инфраструктурные задачи
• Настройка/оптимизация SQL/NoSQL – систем
• Непрерывная интеграция всего хозяйства
• Плавность смены версий в вашем ToolBox
• Батюшка – деплой
• Матушка – ошибки в логах
40. Инфраструктурные задачи
• Настройка/оптимизация SQL/NoSQL – систем
• Непрерывная интеграция всего хозяйства
• Плавность смены версий в вашем ToolBox
• Батюшка – деплой
• Матушка – ошибки в логах
• 24*7 выход чего-то из строя
41. Инфраструктурные задачи
• Настройка/оптимизация SQL/NoSQL – систем
• Непрерывная интеграция всего хозяйства
• Плавность смены версий в вашем ToolBox
• Батюшка – деплой
• Матушка – ошибки в логах
• 24*7 выход чего-то из строя
• Ну или кредитка для Amazon ^__^
42. Инфраструктурные задачи
• Настройка/оптимизация SQL/NoSQL – систем
• Непрерывная интеграция всего хозяйства
• Плавность смены версий в вашем ToolBox
• Батюшка – деплой
• Матушка – ошибки в логах
• 24*7 выход чего-то из строя
• Ну или кредитка для Amazon ^__^
43. Если вы умеете извлекать
интересные факты из своих данных,
то за вами придут
48. Специалисты
• Бывший backend – разработчик как личинка
Hadoop/Spark девелопера
• Бывший сисадмин как личинка
DevOps/Infrastrucure Specialist
49. Специалисты
• Бывший backend – разработчик как личинка
Hadoop/Spark девелопера
• Бывший сисадмин как личинка
DevOps/Infrastrucure Specialist
• Быший 1С-ник как BI/Data Warehouse
Specialist
50. Специалисты
• Бывший backend – разработчик как личинка
Hadoop/Spark девелопера
• Бывший сисадмин как личинка
DevOps/Infrastrucure Specialist
• Быший 1С-ник как BI/Data Warehouse
Specialist
• Бывший математик как Data Scientist
51. Специалисты
• Бывший backend – разработчик как личинка
Hadoop/Spark девелопера
• Бывший сисадмин как личинка
DevOps/Infrastrucure Specialist
• Быший 1С-ник как BI/Data Warehouse
Specialist
• Бывший математик как Data Scientist
• … ну и менеджер, с техническим
бэкгранудом
53. Есть что спросить/рассказать?
• https://twitter.com/zaleslaw
• https://twitter.com/BigDataRussia
• http://vk.com/big_data_russia Big Data Russia
• http://vk.com/java_jvm