Заявки на доклады

Поиск по тегам:

Enterprise-системы

Задача о рюкзаке для финтех расчетов

Антон Батяев

Рассмотрим ситуацию решения задачи о рюкзаке из кластера размером в 15k+ CPU который нам надо оптимально загрузить расчетами финансовых рисков. Как можно решить NP полную задачу с учетом специфичных знание о предметной области и как избавиться от излишней сложности.
Дополнительными задачами будут проблемы определения время выполнения тех или иных расчетов, оценки зависимости этого времени от параметров. Посмотрим как можно преобразовать данные чтоб сохранив то же результат получить меньший расчет и ответить на ряд сопутствующих вопросов.

Программный комитет ещё не принял решения по этому докладу

BigData и машинное обучение

Борьба с мошенниками: поиск дубликатов среди сотен миллионов объявлений

Алексей Григорьев

OLX - платформа для онлайн объявлений и миллионы добропорядочных пользователей посещают нас каждый день, чтобы купить и продать товары друг у друга. К сожалению среди них встречаются и мошенники, которые создают несуществующие объявления, копируя содержания других листингов и обманывают покупателей.

В этом докладе мы расскажем как мы боремся с мошенниками и представим систему для поиска дубликатов. Наша система использует машинное обучение для анализа текста и картинок более 10 миллионов объявлений в день, что позволяет нам устранять нежелательные листинги до того, как они нанесут вред нашим пользователям.

Мы покажем, как мы спроектировали нашу систему, поделимся деталями реализации и расскажем про технологии, которые мы использовали для этого.

Технологии: AWS, kubernetes, python, elasticsearch, scikit-learn и keras.

Python
,
Поисковые системы
,
Работа с Amazon
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

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

Артем Просветов
Анастасия Семенова

Имеется задача многоклассовой классификации коротких текстов на примере чеков покупок в Интернет-магазине. Такую задачу возможно решить посредством построения большого количества бинарных классификаторов, каждый из которых предсказывает флаг наличия определенных интересов у покупателя.

Для применения обучения с учителем необходимо использовать размеченную тренировочную выборку, которую получить для каждой конкретной темы проблематично. Мы нашли приемлемое по качеству решение, позволяющее получить размеченную тренировочную выборку для каждой из наших моделей.

В нашем решении модели строятся автоматически, поэтому оказывается важным оценивать их качество используя не только стандартные метрики (в силу высокой разделимости классов метрики имеют большие значения). Для решения контроля качества была найдена новая метрика, позволяющая выявлять наиболее значимые различия между качественными и некачественными моделями классификации. Полученная мета-модель на основе ряда признаков принимает решение о применимости модели классификации.

Наше решение было разработано для условий высоких нагрузок и большого объема данных и на текущий момент активно используется CleverDATA для классификации ежедневного потока чеков от покупок в Интернет-магазинах.

Программный комитет ещё не принял решения по этому докладу

Машинное обучение (lightGBM) и теория вероятностей для предсказания продаж и оптимизации запасов интернет-магазина OZON.RU.

Александр Алексейцев

- Обучение ML моделей для потоварного предсказания спроса
Подводные камни в формировании обучающей выборки (балансировка, очистка данных). Подбор гиперпараметров и постобработка результатов.
Unsupervised кластеризация временных рядов как фича для обучения supervised классификатора товаров без истории продаж.
Первые шаги с LSTM сетями

- Математика и теория вероятностей в процессах пополнения складов.
Оценка распределений ошибок прогноза, ошибок поставок (опоздания, "недовозы" поставщиков). Расчет страховых запасов на основе полученных распределений.

- Методы оптимизации в ценообразовании.
Оптимизация цен товаров для максимизации оборота с ограничением по марже.
Применение моделей предсказания продаж в оптимизации цен. Линеаризация сложной модели для ускорение работы оптимизатора.

- Замкнутый цикл разработки ML решений для продакшена. Бизнес-применение ML.
feature engineering -> model selection -> training -> results evaluation -> feature engineering -> ...

- Работа с большими данными. Как заставить spark быть параллельным.
Сбор данных и генерация фичей на spark. Подбор настроек spark для достижения высокой степени параллельности вычислений. Осознанное репартиционирование таблиц для равномерной нагрузки на вычислительные ноды.

Python
,
Распределенные системы
,
Общение с заказчиком, извлечение требований
,
Hadoop
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Как организовать работу с метаданными для большого бизнеса

Алексей Еремихин

Это доклад о подходах к организации работы с данными на разных масштабах зрелости BI системы. В качестве примера — развитие Business Intelligence системы в крупной компании. Однозначных ответов и советов нет ни у кого, но я расскажу о подходах, которые сработали и не сработали у нас. Интересно, что в основе лежит грамотная автоматизированная работа с мета данными.

Рассмотрим основные технические и организационные трудности и как их решать.
Кто отвечает за качество данных? Как разделить зоны ответственности? Как мотивировать команды разработки пользоваться BI инструментами?

Классический ETL и daily based reporting

Как собрать в одном хранилище данных много разных источников? Как обеспечить обратную совместимость при динамичном развитии проекта? Как разделить релизы разных компонентов? Кто отвечает за качество данных? Как предотвратить превращение data lake в data swamp?

Логи, клик-стрим или эвент стрим
Как перестать писать ETL код для очередного лога событий? Как сделать универсальную шину событий? Как засунуть слабо структурированные данные в реляционную СУБД? Как подружить технические метрики с бизнесовыми? Как подружить клиентские события с серверными? Как мотивировать разработчика продукта пользоваться инструментами BI?

Доклад будет полезен архитекторам BI и хранилищ данных, ETL разработчикам и дата-инженерам.

Архитектура данных, потоки данных, версионирование
,
Синхронизация данных, параллельная обработка, CDN
,
Архитектуры / другое
,
Управление изменениями, управление требованиями
,
Проектирование информационных систем
,
Проектные артефакты, инструментарий
,
Аналитика / другое
,
ETL
Программный комитет ещё не принял решения по этому докладу

Современный ML\DL KubeFlow pipeline от экспериментов до продакшена

Михаил Сальников

Валарм - платформа для автоматизации защиты и тестирования веб-приложений, микросервисов и API, созданная на базе машинного обучения. При помощи машинного обучения мы обрабатываем клиентские запросы и выявляем среди них вредоносные.

В этом докладе я расскажу, как мы построили и продолжаем строить pipeline для наших ML\DL решений. Покажу, как можно использовать KubeFlow для доставки, предобработки и валидации данных, контроля обучения, самого обучения моделей и экспорта этих моделей для использования в боевых условиях.

Технологии: Kubernetes; KubeFlow; TensorFlow; Python; Apache Bean

Python
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Бэкенд, теория программирования

Пересядь с иглы TCP на UDP с миллионами пользователей

Александр Тоболь

Что делать, если вы все оптимизировали, а данные до пользователя доходят недостаточно быстро? как профилировать сеть и как ее ускорить?

В докладе будет рассказано про то как и зачем мы пересадили десятки миллионов пользователей c TCP на UDP, и что это дало.

Нас ждут:
* принципы построения сетевых протоколов и методики написания своих
* анализ инструментов для шейпинга трафика
* тестовая среда
* шифрование трафика, ddos и mitm атаки
* sack и для чего он нужен
* кровь, кишки и велосипеды сетевых протоколов...

Программный комитет ещё не принял решения по этому докладу

Алгоритмы быстрой обработки HTTP строк

Александр Крижановский

HTTP/2 ввел компрессию стандартных заголовков, но тело URI, Cookie, значения User-Agent по-прежнему могут составлять десятки килобайт и требуют токенизации, поиска и сравнения подстрок и пр. Задача становится критичной, если HTTP парсер должен обрабатывать интенсивный злонамеренный трафик, как например HTTP flood. Стандартные библиотеки предоставляют обширный инструментарий обработки строк, но HTTP строки имеют свою специфику и если разрабатывать HTTP парсер с учетом этой специфики, то можно получить в несколько раз более высокую производительность по сравнению с современными open source решениями и даже превзойти быстрейшие из них.

В докладе будет рассмотрено:

* как HTTP flood может сделать ваш HTTP парсер бутылочным горлышком;
* проблемы x86-64 с branch mispredictions, кэшированием и невыровненной памятью на типичных задачах HTTP парсера;
* оптимизации C/С++ компилятора для multi-branch выражений и автовекторизации;
* сравнение switch-driven конечного автомата (FSM) с прямыми переходами (например в Ragel);
* особенность структуры HTTP строк и почему стандартные библиотеки плохо подходят для их обработки;
* strspn()- и strcasecmp()-like алгоритмы для HTTP строк с использованием SSE и AVX расширений x86-64;
* эффективная фильтрация инъекционных атак (SQL, XSS и пр.) с использованием AVX;
* цена переключения контекста FPU и как Linux ядро работает с SIMD;

Все эти топики будут иллюстрированны микробенчмарками.

C/C++
,
Оптимизация производительности
Доклад принят в программу конференции

Базы данных и системы хранения

Распределенные транзакции в YDB

Семён Чечеринда

Цель доклада -- демонстрация применения детерминистических транзакций для обеспечения строгой консистентности распределенной системы.

Yandex Database (YDB) – горизонтально масштабируемая геораспределенная база данных, рассчитанная на OLTP запросы и соответствующая требованиям ACID к транзакционной системе.

В докладе рассмотрим алгоритм планирования транзакций, лежащий в основе транзакционной системы YDB. Разберем какие сущности участвуют в транзакциях, кто назначает транзакциям глобальный порядок, как достигается атомарность транзакций, надежность и строгий уровень изоляции.

На примере распространенной задачи рассмотрим реализации транзакций с применением двухфазного коммита и детерминистических транзакций. Обсудим их различия.

Отказоустойчивость
,
Распределенные системы
,
Алгоритмы и их сравнение
Доклад принят в программу конференции

Практический опыт переезда боевого проекта со 100 Гб базы данных из MySQL Percona в кластер на базе Vitess для горизонтального масштабирования

Кирилл Мельничук

— Горизонтальное масштабирование — проблемы MySQL.
— Партиционирование, шардинг и почему это не всегда возможно.
— Варианты горизонтального масштабирования для MySQL.
— Vitess — запуск и первичная настройка.
— Типичные проблемы и пути их решения.
— Итоговая архитектура.
— Результаты нагрузочных тестов.

Миграции данных
,
Базы данных / другое
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Управление конфигурацией
,
Администрирование баз данных
,
Big Data и Highload в Enterprise
,
MySQL (MariaDB, Percona Server)
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Провалы и успехи с Redis

Андрей Маркелов

За 3 года использования Redis на "проде" накопилось много интересного: как, где и зачем его использовать в микросервисной архитектуре. А также расскажу какие "фейлы" были и как с ними бороться.

Миграции данных
,
Java
,
Микросервисы, SOA
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Отказоустойчивость
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

SWIM - протокол построения кластера

Владислав Шпилевой

SWIM - это протокол обнаружения и мониторинга узлов кластера, распространения событий и данных между ними. Протокол особенен своей легковесностью, децентрализованностью и независимостью скорости работы от размера кластера.

Протокол решает сразу несколько задач. Первая — сборка и обновление топологии кластера без задания явной конфигурации. Задача довольно нетривиальная, потому что:
- новые, только что запущенные узлы ничего не знают про других, и надо донести до них конфигурацию, где будут указаны все остальные члены кластера;
- уже работающие узлы могут выходить из строя, и это нужно обнаруживать, чтобы принять меры вроде смены мастера или исключения упавшего узла из состава кластера.

Согласно протоколу, участники кластера делают широковещательные и точечные ping-запросы. Широковещательные обнаруживают новые узлы, точечные проверяют доступность уже известных.

Вторая задача — распространение событий в кластере. Событие — это отказ узла, смена его UUID или IP-адреса, появление нового узла. Бывает, что пользователь вводит свои собственные типы событий. Когда о событии узнают один или несколько узлов, им надо его распространить, чтобы у нем узнали все. Протокол SWIM описывает алгоритм обнаружения и распространения событий, которому требуется:
- константное время, чтобы хотя бы один узел узнал о событии;
- время, логарифмическое от размера кластера, чтобы о событии узнали все.

В докладе рассказывается о том, как устроен протокол SWIM, как и с какими расширениями он реализован в Тарантуле, как им пользоваться.

API
,
Бэкенд / другое
,
Tarantool
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Разработка библиотек, включая open source библиотеки
,
Lua
Доклад принят в программу конференции

Новая инфраструктура компонентов в MySQL 8.0

Vittorio Cioe

Вы, вероятно, заметили новые команды в MySQL 8.0, INSTALL COMPONENT и UNINSTALL COMPONENT, и вам было интересно, "что это такое".
Я собираюсь объяснить, что такое "Инфраструктура Компонентов", зачем она нужна, что позволяет и какие у нас есть амбиции развития.
Я также представлю то что необхдимо знать для создания простого компонента.
Инфраструктура компонентов в MySQL задумана как новое начало функциональности плагина, построена по принципу модульности, явных интерфейсов и зависимостей, запутывания сложных внутренних структур и экземпляров объектов.
Она наследует лучшее от функциональности плагина, избегая известных подводных камней и предоставляя отсутствующие функциональные возможности.
Мы рассмотрим архитектурные принципы, лежащие в основе Компонентов, сервисов и их реализации.
Мы также создадим простой компонент, посмотрим, как декларировать необходимые API-интерфейсы, и как он взаимодействует с другими API-интерфейсами, доступными в реестре сервисов. В конце мы пройдемся по перечислению сервисов, доступных из серверного компонента MySQL. Затем мы попытаемся вместе подумать о том, чего не хватает, что может быть дальше и что более желательно с точки зрения функциональности.

Программный комитет ещё не принял решения по этому докладу

Тестирование, нагрузочное тестирование

Изображая продакшн: нагрузочное тестирование виртуальных инфраструктур в рамках бюджета

Михаил Бородин

Зачастую в процессе разработки высоконагруженных систем возникает необходимость создания тестовых стендов, приближенных к инфраструктуре заказчика, которая может исчисляться тысячами сокетов и терабитами пропускной способности. Полное дублирование серверных и сетевых инфраструктур не всегда целесообразно, и требует оценки с учетом выделенного времени и ресурсов.

В данном докладе я расскажу о создании стендов для нагрузочного тестирования разрабатываемого нами сертифицированного средства защиты платформ виртуализации и о симуляции больших виртуальных инфраструктур в рамках бюджета. На конкретных кейсах покажу, до какой стадии проект может обходиться малыми hardware ресурсами, и к чему может привести их несоответствие ожиданиям заказчиков.

Расскажу о некоторых особенностях работы с платформой VMware vSphere: преодолении неочевидных ограничений nested гипервизоров и тонкостях Auto Deploy. В докладе будут рассмотрены проблемы использования восстановленного и бывшего в эксплуатации аппаратного обеспечения в качестве «личного» тестового стенда. Также проведена грань, за которой экономия начинает вредить обслуживаемости и масштабируемости тестовой инфраструктуры, что сказывается на качестве выпускаемого ПО.

Защита информации
,
Оптимизация производительности
,
Технологии виртуализации и контейнеризации
,
Проектирование информационных систем
,
Нагрузочное тестирование
Доклад принят в программу конференции

Архитектуры, масштабируемость

Time-series DB in E-Commerce - InfluxDb

Борис Тверитнев

TBD

Бэкенд / другое
,
Базы данных / другое
,
Архитектурные паттерны
Программный комитет ещё не принял решения по этому докладу

Заключая контракт: как осуществить хороший API для (микро)сервиса

Мелехова Анна
Владимир Лапатин

Процесс построения API никогда не проходит без споров. Процесс вывода API в public - это настоящий coming out, которому предшествуют масштабные переделки и даже изменения процессов компании.

В этом докладе мы поговорим про дизайн REST API для сервисов и предложим практический checklist для оценки зрелости API.

Мы обсудим:
- Контрактные выборы и их значимость: RAML vs swagger, API first vs code first. Как сделать выбор и как обеспечить его поддержку на всех уровнях компании?
- Разработка API Guideline. Как сформировать этот свод правил и можно ли форсировать его применение?
- Toolchain. Что можно и что нужно автоматизировать, можно ли проверять безопасность на уровне RAML
- Внедрение практик на все команды. Как помочь программистам добиться совершенного API и не помешать project-manager-ам выпустить продукт в срок

Взаимодействие с серверной стороной (API)
,
API
,
Микросервисы, SOA
,
Стандарты кодирования
,
Автоматизация разработки и тестирования
Программный комитет ещё не принял решения по этому докладу

Почему вам нужна платформа межсервисного взаимодействия и как её построить уже сегодня?

Артемий Рябинков

Вы уже начали переезжать с монолита на микросервисы? Или, может, сразу строите сервисную архитектуру? Тогда я хочу поговорить с вами о взаимодействии между сервисами — о платформе для межсервисного взаимодействия. Что это? Зачем надо? Как её быстро построить? Попробуем ответить на эти вопросы.

В сервисной архитектуре сложность поддержки растёт экспоненциально с количеством сервисов. Я дам вам инструмент, который позволит значительно замедлить рост этой сложности. Мы поговорим, что можно считать платформой для межсервисного взаимодействия, как она может уже сейчас помочь вам решить проблемы с «наблюдаемостью» сервисов и увеличить надёжность системы, уменьшить объем рутины и снизить Time To Market.

Обсудим плюсы и минусы актуальных протоколов прикладного уровня. Расскажу, почему gRPC — «не вариант», и с какими проблемами вы столкнётесь, если начнёте его использовать.

Доклад будет интересен как тем, кто только начинает свой путь в SOA, так и тем, кто уже хорошо знаком с инструментами OpenAPI, Swagger, gRPC, protobuf. Авторизация запросов, трассировка и логирование, A/B тестирование, сегментация фичей — как получить всё то, что так легко давалось нам в монолите?

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Методы и техника разработки ПО
,
Масштабирование с нуля
,
Архитектуры / другое
,
Логирование и мониторинг
,
Автоматизация разработки и тестирования
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
GO
Доклад принят в программу конференции

AWS для бережливых: трюк как снизить затраты на compute

Александр Патрушев

Все хотят экономить на облачных сервисах. Для этого есть масса трюков. Использование Spot Instances - один из них. Мы поговорим о том, что такое Spot, обсудим детали и примеры использования в различных сервисах AWS (Analytics, Containers, ML / AI и др).

Оптимизация производительности
,
Работа с Amazon
Программный комитет ещё не принял решения по этому докладу

Starship Enterprise Evolution: архитектура e-commerce платформы

Алексей Скоробогатый

Что из себя представляет архитектура современного e-commerce? Поговорим об эволюции систем от монолитов через микросервисы к event-based архитектуре. Lamoda – это data-driven компания, которая уделяет большое внимание аналитике данных и использует полученные результаты для развития продукта.

Как отвечать запросам развивающегося бизнеса полного продуктовых идей? Как при этом управлять сложностью между системами? Как эволюция архитектуры ложится на команды разработки? Расскажу о том, как мы развиваем нашу платформу, чтобы отвечать поставленным перед нами требованиям.

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
Программный комитет ещё не принял решения по этому докладу

Какие вызовы ставит перед инженерами e-commerce бизнес?

Тимур Нурутдинов

Расскажу как устроен современный e-comm, мало кто догадывается, обычно это не просто сайт на WordPress, а десятки сервисов в части интернет магазина и еще в 10 раз больше в собственной службе доставки, управления огромным автоматизированным складом, системой управления современной студией, контакт центр, а также финансовые и операционные процессы.

Какие вызовы ставит перед инженером индустрия e-commerce? Какие интересные задачки могут встретиться в работе? И почему мы от этого получаем удовольствие?

Доклад будет полезен тем, кому хочется познакомиться с индустрией e-commerce и тем, кто хочет разобраться в деталях, как устроен большой интернет-магазин.

Микросервисы, SOA
,
Архитектура данных, потоки данных, версионирование
,
Критерии выбора технологий для проекта
,
Большие проекты/команды
,
Бизнес на стыке онлайн и офлайн
Программный комитет ещё не принял решения по этому докладу

Реализация асинхронного фреймворка на базе Nginx: асинхронные задачи и сервисы на примере nginx-haskell-module

Алексей Радьков

Технические аспекты реализации асинхронных задач, контент-хэндлеров и сервисов (то есть персистентных задач, не привязанных к запросам пользователей) и их интеграции в событийный механизм Nginx. Асинхронные каналы eventfd. Разделяемые сервисы, то есть сервисы, обслуживающие все рабочие процессы одновременно, и как реализовать их безопасно (использование advisory file locks). Сервисные хуки и глобальные состояния.

Быстрая и безопасная передача данных между Nginx и Haskell хэндлерами, и почему cleanup хэндлеры Nginx играют здесь важную роль. Оптимизация работы с памятью в обычных и разделяемых сервисах (разделение и подсчет ссылок). Типизированная передача данных.

Краткое описание плюсов и минусов Haskell в роли языка для написания сервисов и асинхронных задач.

Пример. Онлайн мониторинг распределения запросов между рабочими процессами Nginx.

Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Оптимизация производительности
,
Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Архитектура данных, потоки данных, версионирование
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу

Reversive Decentralized Deployment: Zold Cryptocurrency Example

Егор Бугаенко

A traditional deployment scenario includes a central point of control, which sends updates to server nodes. In our Zold cryptocurrency project we were forced to create a different and reversive deployment model, where distributed and anonymous servers pull updates from an open public repository and restart themselves. The biggest problems we had to solve were related to error tracking and resolving of exceptional situations. In the presentation I will demonstrate how it works and we will deploy a new version right on the stage.

Архитектурные паттерны
,
Оптимизация производительности
,
Распределенные системы
Программный комитет ещё не принял решения по этому докладу

Управление командой разработки (тимлиды)

Обучение. А как могло бы быть?

Сапогов Антон

Что нужно знать?
Важные моменты?
Налоги?
Запустились...

Программный комитет ещё не принял решения по этому докладу

Как отличить профессионального разработчика от непрофессионального?

Даниил Пилипенко

* Как плохой разработчик понижает общую производительность.
* Из 20-ти человек, называющих себя программистами, только один действительно им является.
* Как отличить профессионального разработчика от любителя: критерии по С.Макконнеллу, Дж. Спольски, Р. Мартину.
* Компоненты профессионализма: как оценить.
* Опасные (неэффективные) способы подбора.
* Практические советы по повышению точности подбора программистов.

Поиск и развитие команды
Программный комитет ещё не принял решения по этому докладу
Rambler's Top100