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

Поиск по тегам:
Показать только принятые доклады

Узкотематические секции: видео, поиск, RTB, биллинги

Знакомы ли вам аббревиатуры CSAT, NPS, CAWI? Каким бы ни был ответ на этот вопрос, доклад будет интересен широкому кругу аналитиков и специалистов по маркетингу.

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

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

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

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

Enterprise-системы

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

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

Что такое класс Java в разрезе построения ИТ-систем крупных компаний? Прежде всего, класс определяет структуру объекта, и по нему будут строиться сообщения, передаваемые сервисами. То есть, в JAVA классы должны быть “проекциями” для всех объектов, со всеми атрибутами, которые задействованы в бизнес-процессе. Топология взаимосвязи классов и подклассов при этом должна отражать топологию бизнес-объектов, участвующих в деловом обороте предприятия.

На основе JAVA-классов строятся DTO (Data Transfer Objects), по которым строятся эндпоинты на конвейерах с микросервисной архитектурой. DTO используется для построения сообщений в формате XML или JSON.

Современные реалии таковы, что никто в начале аналитики не уверен до конца в перечне используемых объектов и атрибутов, а их семантика описана таким образом, что на первый взгляд трудно однозначно определить их первичный смысл и однозначно сопоставить друг с другом, сделав так называемый маппинг. Поэтому DTO в ходе разработки от спринта к спринту приходится постоянно переделывать. Особенно данная проблема обостряется при работе по методикам гибких методологий типа Agile, когда множество SCRUM-команд со своими задачами и своим бэкграундом начинают взаимодействовать в рамках задач интеграции. Другим знаковым примером так называемого «семантического безумия» является концепция построения ИТ-сервиса на основе микросервисной архитектуры, где по факту из-за наличия у каждого микросервиса своей базы данных имеется своя уникальная модель данных и приходится сопоставлять один JAVA-класс другому.

В данной работе рассказывается об опыте применения концепции интеграции между набором микросервисов на брокере KAFKA на основе единой модели данных. Данный подход использует так называемые “глобальные бизнес-сущности”, которые используются для генерации класса и создания сообщений. Такой подход обеспечивает единый подход к формированию топологии и набора атрибутов, а также единую концепцию формирования Java-класса. Говорится о различных методиках построения классов, посредством определения глобальных бизнес-сущностей, данные о которых хранятся в едином репозитории в форматах XSD или JSONSchema. Приводятся методики математического анализа предметных областей и получения глобальных объектов методами математической статистики. Приводится в пример методика ведения единой модели, посредством использования общего репозитория на GITHub. Приводятся примеры работы с библиотеками и генерации объектов на JAXB и JACKSON. Отдельное внимание будет уделено хэшированию метаданных по сущностям.

Доклад будет состоять из следующих частей:
1. Технические тонкости генерации сообщений в формате XML и JSON на основе библиотек JAXB и JACKSON и их применение на микросервисных системах типа KAFKA.
2. Представление модели данных конвейера на микросервисах в виде единого репозитория схем XSD и JSONSchema, по которым будут строиться DTO. Будет рассказано о подходе, в рамках которого модель данных выносится в классы JAVA. Классы при этом становятся основами микросервисов. Аналитики при таком подходе работают не со схемами бизнес-объектов, а с сервисами разработки, где бизнес-объекты являются переменными, а бизнес процессы – методами. Приводятся плюсы и минусы данного подхода.
3. Приводится пример разработки единой модели данных, визуализации предметного поля, выполненные на основе векторизации семантического описания полей, реализованного на JAVA. При этом формируется граф взаимосвязи сущностей, который переводится в схему XSD или JSONSchema или в DTO в соответствии с семантическими взаимосвязями.
4. Применение хэширования метаданных по сущностям для проверки необходимости перегенерации классов в ходе изменений.

Доклад принят в программу конференции

- Как в очень большой и старой компании со всеми ее enterprise проблемами сделать что-то быстро и не в вакууме
- К чему быть готовым, к чему быть не готовым
- Почему .NET

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

Lua @ HighLoad++

Lua — простой язык. Базовые вещи можно выучить минут за 20 без преувеличения. Но несмотря на всю свою простоту, Lua всё-таки может преподнести сюрприз неопытному разработчику. А чтобы писать хороший код, хорошо бы понимать, что происходит за кулисами.

Одна из причин простоты языка заключается в том, что в Lua есть всего один композитный тип данных — таблицы. Таблицы призваны подойти для любых целей — их можно использовать и как массив (если ключи целочисленные), и как key-value-хранилище. А еще таблицам присуще свойство undefined behavior — о нем и рассказ:
- Для массивов с "дырками" не определено свойство длины, на результат может влиять внутреннее представление и фаза Луны.
- Добавление новых элементов во время итерирования может нарушить порядок итерации.
- Порядок итерации pairs() не детерминирован даже для массивов.

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

Доклад принят в программу конференции

С++

В ближайшем время будет релиз С++ коннектора к tarantool.
Во главу угла ставится производительность коннектора и минимальные потери на стороне приложения.
Коннектор не приносит чужеродную концепцию в кодовую базу приложения.
Абстракции в коннекторе придерживаются концепции zero overhead abstraction.
Коннектор изначально разрабатывался с для встраивания в I/O приложения с произвольными событийными циклами (в частности он встаиваеться в сам тарантул), хотя может работать и напрямую с epoll.
Благодаря типизированной серилизации (по возможности в compile time) запросов и использованию state machine для десериализации ответов для msgpack протокола можно добиться поразительных показателей производительности.
Обо всем этом будет у меня в докладе.

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

Расскажем, как в ЛК организован сбор дампов памяти, диагностирующих критичные ошибки. В частности, как мы в С++’ном коде реализовали перехват любых нештатных ситуаций, какие при этом возникли проблемы и как мы их решили. А затем, на примерах рассмотрим анализ пары интересных дампов, связанных с современными фичами С++ (noexcept, корутины).

Доклад принят в программу конференции

# libron: используем CRDT оплог в C++

RON (Replicated Object Notation) это формат данных на основе
операций, разработанный в первую очередь для реализации CRDT
(Conflict-Free Replicated Data Types). От типичного оплога (бинлога
итд) RON оплог отличается Лампортовой адресацией и частичным
(а не линейным) порядком операций. Это значит, что много реплик
могут писать в оплог одновременно и обмениваться этими
правками ("мастера" нет). Для распределённых приложений, это ли
не технология мечты?

Однако же, при реализации RON оплога возник ряд сложностей.

Во-первых, миссия RON - это побитная сходимость реплик
при синхронизации, даже в ненадёжной сети любой топологии.
А это - разработка от уровня "сырых" битов до API структур
данных (из-за чего и пришлось обратиться к C++).

Во-вторых, помимо ведения оплога - нужно уметь доставать из
него объекты с разумными показателями по производительности.
А это открывает вопросы:
* минимизации объёма метаданных (Ахиллесова пята CRDT),
* случайного доступа к логу (немного о структурах данных),
* локальности данных (удивительно долго можно ехать
на связном списке операций, но не бесконечно),
* стоимости (де)сериализации (почему пришлось отказаться
от protobuf varint),
* и другие вопросы, которые пришлось решать.

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

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

Автор надеется, что доклад поможет слушателям использовать
суперсилу CRDT в своих проектах.

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

Tempesta TLS — это реализация TLS, работающая в контексте ядра Linux. Т.к. основные алгоритмы симметричного шифрования уже есть в составе ядра, то мы фокусируемся на асимметричных алгоритмах, преимущественно эллиптических кривых.

За основу мы взяли mbed TLS, которую мы практически полностью переписали, чтобы сделать в 40 раз быстрее. В разработке мы также заимствуем части кода WolfSSL — более быстрой, чем OpenSSL-реализации. WolfSSL использует алгоритмы, аналогичные OpenSSL, которым уже более 5-7 лет. Мы обнаружили, что недавно появились более эффективные алгоритмы, которые мы реализуем в Tempesta TLS.

Работа по оптимизации производительности Tempesta TLS все еще не закончена, но Tempesta TLS уже устанавливает на 40-80% больше TLS-соединений, чем OpenSSL/Nginx, и в некоторых тестах дает до 4 раз меньшее время задержки.

В докладе будут рассмотрены:
* базовые принципы эллиптических кривых и основные "горячие точки";
* возможные side channel attacks (SCA) и методы защиты от них;
* новые и быстрые алгоритмы, используемые в эллиптических кривых;
* альтернативные решения, принимаемые разработчиками OpenSSL, WolfSSL, mbed TLS и Tempesta TLS.

А еще будет много бенчмарков и забавного кода, который на C выглядит сложнее, чем на ассемблере.

Доклад принят в программу конференции

Хэш-таблицы - это королевы структур данных. Нигде не сломано так много копий, как на оптимизации хэш-таблиц.
В своём докладе я расскажу ещё про одну хэш-таблицу, которая используется в ClickHouse.

Я покажу, как zero cost abstractions в современном С++ оправдывают себя, и как с помощью небольших трюков можно получить разнообразные структуры данных из общей кодовой базы.
На основе общих строительных блоков мы получим быстроочищаемую хэш-таблицу; несколько видов LRU кэшей; lookup таблицы без хэшей; хэш-таблицы для строк и т. п.
Я расскажу, как получить максимальную производительность на конкретных сценариях и как не ошибиться при её тестировании.

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

Доклад принят в программу конференции

Безопасность

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

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

Попробуем систематизировать проблемы безопасности AI-систем и инфраструктуры их разработки, а также рассмотрим конкретные примеры из практики анализа защищённости.

Доклад принят в программу конференции

Менеджмент крупных проектов

- Зачем non-food маркетплейсу нужна еда
Как АлиЭкспресс пришел к тому, чтобы вкладываться в продукты питания, бытовые и зоо товары

- С чем минимально можно запуститься
Как отбирали, что войдет в MVP

- С какими проблемами столкнулись
Что оказалось нужно рынку, и как мы с этим справились

- Чего ещё не хватает для счастья
Куда смотрим дальше

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

Системное администрирование

Чтобы контент у конечных пользователей загружался быстро, нужно минимизировать время доставки пакетов от компьютера пользователя до сервера и обратно (rtt, round-trip time). Этого, в свою очередь, можно достичь размещением серверов как можно ближе к конечным пользователям. Так рождаются сети доставки данных, или более привычная аббревиатура — CDN.

"Точкой входа" конечных пользователей является система доменных имён — DNS. Именно DNS отправляет пользователя на ближайшую к нему точку присутствия.

В докладе будет рассмотрена история развития инфраструктуры DNS в CDN G-Core Labs, собранных "граблях", оптимизациях (удачных и не очень), хрупкости Интернета, мониторинге, статистике, методах тестирования DNS-сервера и проблемах нетехнического характера.

Доклад принят в программу конференции

DevOps и эксплуатация

Базы данных и Stateful Apps активно мигрируют в Kubernetes, неся с собой уникальные Persistent Data, требующие персонального отношения, тем самым возрождая дискуссии на тему "pets vs cattle".

Оказывается, что Persistent Data — это именно pets, но никак не cattle!

Kubernetes предоставляет множество самых разнообразных возможностей потерять свои данные, и поэтому мы хотим обсудить практические походы к работе с Persistent Data в Kubernetes.

Доклад принят в программу конференции

Расскажу об успешном внедрении bleeding edge-технологии автоматического мониторинга на основе Prometheus Operator.

Prometheus Operator – это "практически" коробочное решение, позволяющее покрыть большинство потребностей Experienced DevOps/SRE-аудитории.

Позволяет исключить bottleneck в виде отдела Operationals, автоматизировать рутину мониторинга и уменьшить time to market бизнесовых метрик.

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

Что будет внутри? Разберем детали конструктивных особенностей современного инструментария мониторинга архитектуры решения, покрывающего все необходимые требования к мониторингу, которые выдвигают пользователи современных кластерных платформ конфигурирования и деплоймента оператора при помощи Ansible- / Helm-мониторинга инфраструктуры вне K8S ci/cd-практики для алертов и дашбордов.

P.S. Взлеты и падения в продакшне и подводные камни – все, как вы любите.

Доклад принят в программу конференции

Использование eBPF для отладки и мониторинга работы систем становится все более повсеместным.
eBPF, в отличие от "старичка" strace, позволяет гораздо глубже заглянуть в происходящее в приложении и системе, однако инженеры сталкиваются с рядом трудностей при его внедрении: непривычный синтаксис, необходимость создавать eBPF-программы, большое количество различных утилит и отсутствие единообразного способа использования.

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

Мы также рассмотрим возможность использования eBPF для постоянного мониторинга производительности в Kubernetes и рассмотрим ограничения eBPF для такого применения.

Доклад принят в программу конференции

В докладе мы поговорим про то, из чего состоит latency между вашими юзерами и сервером и пройдемся по каждому пункту (DNS, TCP, TLS, HTTP) в поисках современных проколов, позволяющих ускорить Time to first byte (TTFB). Обсудим статус HTTP3 (QUIC) в текущих реалиях.

Доклад принят в программу конференции

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

В своем докладе я поделюсь полезными знаниями об использовании статического анализа в проектах с открытым исходным кодом. Для лучшей демонстрации я дополню свой доклад практическими примерами, предоставленными разработчиками проекта ClickHouse – СУБД с открытым исходным кодом от компании Яндекс.

Вы услышите:
* полезные советы: как правильно использовать статический анализ, если над вашим проектом работает open-source-сообщество;
* практические примеры: как разработчики ClickHouse интегрировали PVS-Studio в свой проект;
* результаты применения: примеры реальных ошибок, найденных в ClickHouse при помощи статического анализа.

Доклад принят в программу конференции

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

В рамках моего доклада я расскажу:
- Что делать, если во время Rolling Update проскакивают кратковременные 500-ые ошибки?
- Как бороться с человеческим фактором, когда одна неправильная буква или цифра в манифесте может привести к аварии?
- Как админам обновлять версию кластера или ядра ОС прямо в середине рабочего дня, не зацепив продакшн?

Обсудим эти и другие кейсы, которые возникли у нас за время эксплуатации Kubernetes.

Доклад принят в программу конференции

Доклад расскажет о том, как выстроить процессы и практики DevOps одновременно для 80+ проектов, одновременно разрабатываемых в компании, как масштабировать эти процессы и практики, как реагировать на изменения, как совмещать разоработку под Embedded-системы с криптографией, как использовать компонентный подход для прохождения сертификации в ФСБ (КС1-КB2)/ФСТЭК сокращения затрат на разработку и сборку, надо ли мигрировать с локальных датацентров в облака, как решать проблемы с тестированием в условиях изменяющихся требований и обилия аппаратных платформ и др.

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

Так что, коллеги, готовьтесь к диалогу и конструктивным спорам (TFS vs Jira - для затравочки :))

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

В настоящее время Helm package manager является одним из самых популярных шаблонизаторов для Kubernetes, и фактически - золотым стандартом индустрии.
Но почему это так? В сети множество разрозненной информации, хайпа и хэйта вокруг этого инструмента. В докладе я постараюсь отсечь лишний хайп и последовательно дать исчерпывающие рецепты для решения большинства ваших болей в зоне деплоя приложений в кубовые кластера. Только практические задачи, только проверенные решения.

Доклад принят в программу конференции

Опять боль и страдания!!! Внедряя NoOps в большой компании, я услышал много разного —
от простых эмоций:
- Да вы теперь просто операторы приватного облака!..
- У нас кончилось админство в компании!!!
- А что я теперь и в мидлваре должен разбираться?..

до вполне интересных вопросов:
- Оптимизацией СУБД кто теперь занимается?
- Кто отвечает за бэкап?
- А кто теперь отвечает за инциденты?

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

Самое тонкое место — это передача компетенций, как быть Томом Сойером, а не "вертухаем", заставляющим делать «чужую» работу. Все это мы прошли, причём в серьезном масштабе — 500 дев на 10 опс.

По классике жанра, мы собрали все возможные "грабли", где-то пришлось пойти на компромиссы, ибо любая концепция требует обработки напильником под себя, чтобы максимально решать свои задачи. У нас есть все — и NoOps, и DevOps, и просто Ops. Хочу рассказать про свой опыт погони за хайпом!

Доклад принят в программу конференции

Kubernetes Operator Pattern был создан для автоматизации роли человека-оператора, который управляет приложениями, имея глубокие знания о том, как их правильно готовить. Это как раз то, что необходимо для управления базами данных! А в этой презентации я расскажу о том, как Kubernetes Operator для управления базой данных может быть устроен внутри и чему мы научились, создавая операторы для MySQL и MongoDB.

Доклад принят в программу конференции

Рассказ о том, как дать кому-то кнопку деплоя в production.

Два года назад мы перенесли первое приложение в только что поднятый с нуля кластер kubernetes и запустили в него клиентский трафик. Kubernetes решил множество проблем и принёс ворох новых. После первых попыток микросервисы передаются в эксплуатацию десятками. Чтобы отдел эксплуатации перестал быть узким местом, мы изменили наши процессы с помощью GitOps-оператора от компании Weaveworks.

В докладе расскажу о том, с какими сложностями мы столкнулись, когда команды разработки распробовали k8s и почему мы выбрали pull-модель GitOps.

Вам будет интересно это узнать, если:
- вы хотите, чтобы NoOps стал реальностью в вашей компании;
- kubernetes дал возможность деплоить микросервисы десятками, а вы к этому оказались не готовы;
- на одного Ops приходится 30+ Dev;
- у вас много команд разработки и они используют разные инструменты CI/CD;
- вы только начинаете осваивать k8s, а глаза разбегаются от количества инструментов;
- вы считаете, что in git we trust.

Доклад принят в программу конференции

"Сила в правде" — так завещал нам известный киногерой. Без достоверных сведений о системе невозможно её правильно эксплуатировать, и тем более автоматизировать процессы в ней.

Концепция "источника правды" или "source of truth" появилась не вчера, но до сих пор не все представляют, что это такое и как с ним работать.

Давайте вместе разберёмся, что это такое, какую пользу может принести и как помогает нашему внутреннему Зануде.

Доклад принят в программу конференции

На мастер-классе мы с участниками на практике:
- разберемся, как минимизировать влияние человеческого фактора через инструменты ResourceQuota, LimitRange, PodDisruptionBudget;
- увидим, как настроить разные стратегии деплоя своего приложения в своем кластере.

Доклад принят в программу конференции

* Доставка в продакшн на примерах русской классической живописи.

Бизнес нашей компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7.
Одной из ключевых целей для нас является доступность наших сервисов 99,999%.
К CI/CD в таких условиях предъявляются особые требования.

Я расскажу об эволюции наших подходов к деплою нового кода: о том, как мы от ручных баш-скриптов шли к связке jenkins + ansible, с остановкой в fabric'е.

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

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

Доклад принят в программу конференции

- MySQL orchestrator — продукт, который необходим для построения отказоустойчивой системы на базе СУБД MySQL для резервирования мастера.
- Как работает orchestrator.
- ProxySQL — это L7-прокся для работы с MySQL, с помощью которой можно существенно облегчить жизнь.
- Через ProxySQL можно переиспользовать коннекты в MySQL, так как это L7-прокся, то можно устроить целую систему фильтров, ограничений.

Доклад принят в программу конференции

Технологии будущего

В ритейле прямо сейчас происходит переход к принципиально новой модели потребления.

Нечто подобное в своё время произошло с появлением водопровода. Еще каких-нибудь 100 лет назад большинство людей, которым была нужна вода, брали ведро и шли к колодцу. С точки зрения нас с вами на это уходило чудовищно много времени: дойти до колодца, наполнить ведро, вернуться обратно. Потом в квартире каждого городского жителя появился водопровод и теперь если вам хочется пить, вы просто открываете кран и наливаете воду. Это изменение настолько масштабно и, в то же время, просто в использовании, что для нас оно стало неотъемлемым атрибутом цивилизации.

В Самокате мы делаем такой “водопровод” для товаров.

Мы доставляем товары в режиме реального времени. Не нужно подстраивать свои планы под ожидание доставки, не нужно следить за телефоном, чтобы не пропустить звонок от курьера «за час». Заказал и через 15 минут курьер у твоей двери. Всё.

Мы начинали как «магазин у дома» – продавали только самое необходимое, вроде воды и туалетной бумаги; доставляли 6 заказов в неделю. Сейчас наш ассортимент сопоставим с Пятёрочкой, мы доставляем 150 000 заказов в день в 8 городах-миллионниках России и продолжаем расти.

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

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

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

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

We’ve been building software/hardware systems in a centralized manner for decades, no matter whether they were mainframes with thin clients, clients+server, or web 2.0 — there was always a central place of data storage and execution control. However, time changes and the new uprising trend is all about systems with no central point of control. Blockchain was the first solution, which most programmers still don’t understand. There will be many more solutions in the future, which some of us are yet to design and build.

Доклад принят в программу конференции

Аппаратное обеспечение, инфраструктура

Архитектура процессора Эльбрус 2000 существенно отличается от практически всех известных нам процессоров. Близок к нему, пожалуй, только Интеловсий Итаниум, но он, по сути, является последователем Эльбруса и в известной степени реализует наработки СССР.

Эльбрус — процессор, в котором параллельные вычисления управляются на 90% компилятором. Это отличает его от традиционных суперскалярных процессоров, которые пытаются во время исполнения выявлять в коде участки, пригодные для параллельного выполнения. Это позволило упростить аппаратуру процессора за счёт усложнения компилятора.

Кроме того, у Эльбруса есть ещё несколько чрезвычайно интересных особенностей. Например, аппаратура для параллельной подкачки данных при исполнении цикла. Фактически в процессоре организуется непрерывная предзагрузка данных для циклических вычислений, которая обеспечивает минимальную зависимость вычислений от поступления данных из памяти.

И конечно, жемчужина процессора — защищённый режим. Самый сложный, но, пожалуй, самый интересный режим процессора, который коротко можно описать как valgrind в железе без потери скорости. В этом режиме процессор обеспечивает абсолютную защищённость данных и кода — даже в пределах одного адресного пространства две программы физически неспособны добраться до данных друг друга, если явно не обменялись указателями на них.

Доклад принят в программу конференции

1. HPC-оборудование в десять раз производительней обычного.
2. HPC-среда в разы, а иногда в десятки раз, проще обычного Enterprise/Highload.
3. Как писать приложения в HPC-стиле.
4. Техники для трансформации обычного/highload-приложения в HPC.
5. Пример трансформированного приложения, ставшего в 83 раза производительней.

Доклад принят в программу конференции

Расскажем на примере реализованного кейса о:
- Создание высокопроизводительных баз данных PostgreSQL
-Тестирование различных решений и сравнение горизонтально масштабируемой архитектуры и вертикально масштабируемой архитектуры Exadata
- Тестирование различных вариантов высоконагруженной базы данных Oracl объемом 250 ТБ

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

Векторные расширения в платформах Х86 появились в 1996 году. С тех пор существует мнение, что это для математических вычислений, это для игрушек, это криво и медленно, это сложно, это ни с чем не совместимо и не портабельно, это постоянно меняется, это уже не поддерживается, и это не для моего проекта. За время эволюции векторных расширений действительно было сделано спорных и неоднозначных решений, и накопился приличный исторический багаж. Попробуем посмотреть на современный процессор Х86 и его векторные расширения с практической стороны - как это можно использовать повседневно и для базовых задач. Параллельный поиск в дереве, параллельное вычисление множества хеш функций, сортировка , переупорядочивание и транслирование данных - все это может быть ускорено при корректном применении векторизации. Как и может быть существенно замедлено при некорректном. Практическое применение AVX2 и AVX-512 на примерах проб и ошибок, подчеркивая архитектурные основы векторизации и методику их применения в повседневной практике.

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

Мы 10 лет занимались софтом для видеостриминга и увидели возможность спроектировать и разработать программно-аппаратный комплекс для транскодирования. Т.е. железо+софт.

Что нас подвигло на это? Насколько страшно влезть в такую разработку? Обязательно ли надо минимизировать стоимость железа до последней копейки? Можно ли ввязываться в такой проект, если стартовая партия меньше миллиона экземпляров?

Что делать с материнской платой дальше? Какие вопросы и слова стоит ожидать от дизайнеров, которые будут делать схемотехнику и разводку, если у вас одни программисты в компании?

Как проектировать материнку в расчете на автоматизацию тестирования?

Доклад принят в программу конференции

Пока нет мониторинга, ни одно решение нельзя назвать producton-ready. Без мониторинга никак не узнать, что пора добавить памяти или что кэш отвечает с задержкой в 5 минут. С задачей построения мониторинга мы столкнулись, когда заканчивали проект для одного крупного телекома.

Мы сделали репликацию из Oracle в Tarantool с помощью GoldenGate. Получилось два кэша, каждый примерно в терабайт размером. Это пользовательские данные - номера, договоры, сроки, паспортные данные, подключенные продукты и услуги.

Хороший мониторинг -- это когда алерты предупреждают вас, если

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

А еще мы хотим удобный Grafana дэшборд для эксплуатации, который можно будет передать другим проектам. На него мы вывели

- время обработки HTTP-запросов (средние значения, перцентили),
- health status всех инстансов,
- метрики инстансов Tarantool,
- лаги репликации.

Готового решения не было, так что мы сделали своё и перевели его на open-source. Мы не уверены, что замеряем самые важные показатели. Поэтому для нас важна обратная связь - что замеряете вы? Какие алерты у вас? Что у вас выведено на дэшборд?

Доклад подойдет для тех, кто мониторит, собирается мониторить или создает решения для мониторинга кэшей или приложений на Tarantool.

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

Switchdev — это инфраструктура в ядре Linux для отображения сетевых настроек ядра в железо. Одним из примеров подобного железа (whitebox switches) являются коммутаторы Mellanox, на которых можно запустить любой Linux-дистрибутив.

Доклад представляет обзор опыта эксплуатации коммутаторов Mellanox под управлением Switchdev, какие инструменты и как используются.

Доклад принят в программу конференции

Цифровая культура / CTO-трек

Хранилище данных (DWH) – фундамент любой data driven-компании, источник обработанных данных для аналитиков и платформа для расчета метрик и показателей, вместилище накопленной информации по всем источникам внутри компании. Но что, если одним из источников данных будет само DWH – та информация, которая создается в процессе работы пользователей с хранилищем? На базе этой простой и даже очевидной идеи можно реализовать огромный пласт интересных и практически полезных решений.

В своем условно разбитом на три части докладе я покажу, как в Яндекс.Go покрыли работу пользователей (более 500, DAU 200) с данными (2Пт в YT и 0.5Пт в GP в пределе) в DWH и какую практическую пользу мы из этого извлекли.

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

Затем перейду к реализации metaDWH как еще одного набора процессов внутри DWH и покажу, что это легко реализуется в любом хранилище.

В основной части доклада рассмотрю реализованные нами практические примеры применения metaDWH:
- создание системы метрик и отчетности по использованию DWH;
- постановка и отслеживание KPI продуктовым командам DWH;
- оценка качества доменов данных по разнообразным критериям;
- оптимизация хранения данных в детальном слое;
- и многое другое.

Доклад принят в программу конференции

Data Lake в Яндекс.Такси развивается с 2016 года. В то время как наши технологии совершенствуются, зреют фреймворки, растёт скорость и надуваются объёмы, у нас остаются многие сотни процессов, написанных на устаревших решениях, порой откровенно неудачных, и их поддержка иногда сильно отвлекает нас от движения вперёд. Мы запустили постоянный процесс рефакторинга старой кодовой базы. Я расскажу о принципах, которые позволяют балансировать между укрощением техдолга и продуктовым развитием.

Ключевые вопросы:
* Как объяснить себе и другим, зачем тратить силы на рефакторинг.
* Приоритизация рефакторинга — что делать сейчас, а что может гнить дальше.
* Конфигурация команды и её мотивация.
* Специфика рефакторинга Data Lake в сравнении с бэкендом.
* Архитектура кодовой базы и технические трюки, упрощающие рефакторинг.

Доклад принят в программу конференции

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

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

Интересно, что трансформация роли настолько значительная, что зачастую роль меняется с изменением человека, который ее исполняет, так как редко кто может одинаково эффективно исполнять эту роль на всех этапах развития компании:)

В рассказе буду опираться на свой опыт, а я прокачивался по ветке разработчика, пройдя за 15 лет путь от junior'а до роли CTO в одном из больших управлений в Tinkoff.

Доклад принят в программу конференции

Почему важно доверие пользователей
Как разговаривать с пользователями во время инцидентов
О чём говорить вне инцидентов
Почему важно говорить и какую пользу это приносит
Что говорить
Как говорить
Каналы коммуникации

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

Блокчейн

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

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

Доклад принят в программу конференции

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

В докладе расскажем про эволюцию разработки высоконагруженного сетевого кластера отправки пуш-уведомлений с использованием технологий от unix/bash и PHP до асинхронных неблокируемых многопоточных соединений на базе Rust/Tokio. Поговорим о тонкостях разработки на Rust, особенностях языка, подводных камнях и способах его быстрого изучения и использования веб-разработчиками с навыками LAMP. Поговорим также о Go, Java и причинах принятых технологических решений.

Доклад принят в программу конференции

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

А рассказать хочется про совершенно другие структуры данных.

Существует несколько СД, которые немного сложнее и интереснее вектора; вполне себе практически применимы; но при этом в среднем (среднем!) скорее неизвестны. Heaps, tries, B-trees/LSMs, Bloom filters, CountMin + HyperLogLog, KLL + T-digest. А ещё для как бы стандартных СД существуют всякие интересные реализации или техники. И тоже вполне практически применимые. Judy arrays, parallel_hashmap, google/btree, facebook/rocksdb.

Вот про эти прикладные эзотерические СД и/или реализации и хочется хотя бы обзорно рассказать, что в природе ещё есть. Какие (нечастые, зато интересные) задачи может помочь решать и с какими ходовыми характеристиками. И если времени (уже в коридоре) хватит, как хотя бы в очень общих чертах чего устроено внутри.

Доклад принят в программу конференции

Разработка даже малой финансовой системы — огромная ответственность. Мы — небольшая outsource команда, которая уже 4.5 года пишет финансовый стартап на заказ. Делать под заказ сайт или CRM систему — задача сложная и интересная. А вот делать, в формате аутсорса, финансовую систему — сложно, интересно и стремно:)

В своем докладе я поделюсь, в основном, фейлами и проблемами, с которыми мы столкнулись из-за отсутствия опыта разработки финансовых систем.

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

Паксос - алгоритм принятия решений в распределённых системах, лежащий в основе многих современных инструментов - Consul, Zookeeper, etcd и других. Только сам автор Лесли Лампорт сделал много попыток объяснить как работает алгоритм - в работах "Part time parliament", "Paxos made simple", многочисленных выступлениях. Неавторских интерпретаций тысячи. Большинству из нас это мало помогает понять алгоритм. В одном из своих выступлений Лесли признаётся что в нескольких известных ему реализациях есть ошибки. В презентации я попробую объяснить Пакос с помощью картинок. Цель доклада не прикладная - я попробую объяснить принципы и ограничения, лежащие в основе алгоритма.

Доклад принят в программу конференции

Платформа .NET разработана отличными программистами, которые опирались на опыт десятков других платформ, чтобы создать то, с чем мы работаем сегодня: высокоэффективную платформу, производительность которой крайне высока. Вопрос-то на самом деле в нас самих: знаем ли мы инструментарий платформы, который позволяет писать код столь эффективно.

Доклад будет построен вокруг модификации кода чужих библиотек: когда из своего мы уже выжали максимум, а изменение кода сторонних библиотек может дать x4-x10-кратную производительность.

Доклад принят в программу конференции

Устали разбирать сетевые протоколы на C++ и binpac? На каждый анализатор уходит много сил, а когда QA приходит с очередным багом, то вас бросает в дрожь от того, что снова придётся вернуться к громоздкому коду? Мы нашли решение этих проблем и хотим рассказать вам про Konjac.

Konjac ориентирован на скорость разработки анализаторов протоколов, на их читаемость и простоту поддержки. Konjac позволяет без участия программиста:
* описать разбор сетевых протоколов,
* связать несколько анализаторов с помощью механизма диспетчеризации,
* описать сборку фрагментов (например для IP и TCP),
* связать запросы и ответы для протоколов с клиент-серверной структурой передачи данных.
При отсутствии спецификации на протокол можно использовать konjac для реверс-инжиниринга образцов трафика.

Konjac является основой для системы разбора трафика, поэтому мы серьезно относимся к производительности и используем кодогенерацию на основе LLVM.

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

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

Прямая работа с диском при файловом I/O — не самая дешевая операция и современные ОС применяют различные оптимизации, такие как кэширование и readahead, чтобы уменьшить ее влияние на производительность. В некоторых случаях обращений к диску можно почти полностью избежать, читая большую часть данных из кэша.

В докладе мы рассмотрим методы оптимизации I/O в JVM и копирования памяти в ядре Linux и как это позволяет увеличить пропускную способность передачи данных на 20%.

Доклад принят в программу конференции

Нейронные сети, искусственный интеллект

В докладе расскажем, с чем мы столкнулись и как получается решать интересные задачи, помогая бизнес-клиентам с помощью предобученных нейросетей от Google. Рассмотрим в целом решения в отрасли, более подробно поговорим о tensorflow-js, миграции обученных моделей из одного нейросетевого фреймворка в другой, видах и особенностях конверторов.
Расскажем также, почему нам понравилась opencv для задач вырезания фона и как мы подружили ее с моделями tensorflow-js.
Подробно остановится на оптимизации производительности нейросетей tensorflow-js в браузере - профилировании, анимации, GPU, последних возможностях современных браузеров и их эффективном использовании.

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

Задачи Natural Language Processing в последнее время становятся локомотивом исследований всего глубокого обучения в целом. Это неизбежно порождает внимание ML-сообщества и разумную долю хайпа вокруг новых моделей. И мы в антиспаме Почты Mail.ru тоже не остаемся в стороне и радостно предвкушаем адаптацию SOTA-достижений.

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

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

Доклад принят в программу конференции

- Несмотря на головокружительный прогресс в области NLP последних трех лет, вывод полностью автоматического решения в продакшн все еще не такая простая задача: те самые несколько процентов ошибок на валидации может стать настоящей головной болью для продакт менеджеров. Ведь именно этот несчастный неудачный кейс норовит на главную страницу и испортить впечатление от системы, или же сорвет сделку о партнерстве
- Мы в Whisk (часть SamsungNext) уже более 7 лет разрабатываем продукт по глубокому анализу кулинарных рецептов, и МЛ является ключевой технологией, питающей наш продукт. На базе нашего решения построена система работы с рецептами в холодильниках Samsung FamilyHub, внутренний продукт по интеграции сайтов рецептов с крупнейшими ритейлерами (Walmart, Tesco, etc) и собственный B2C продукт Whisk (победитель Google Play Awards 2020)
- В связи с такой разноплановостью применения нашей ключевой технологии нам очень важно давать гарантии по качеству, что привело к большому количеству инженерных и организационных решений вокруг МЛ моделей, и некоторыми из них хотелось бы поделиться

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

Команда SberDevices активно разрабатывает виртуальных ассистентов Салют. Мы используем технологии AI для распознавания голоса и обработки естественного языка, чтобы наши помощники умели вести беседу и приносили реальную пользу людям.

Для этого постоянно приходится решать различные nlp-задачи. Мы адаптируем и обучаем большие языковые модели на базе трансформеров (BERT, GPT), которыми делимся с сообществом в open source:

https://habr.com/ru/company/sberbank/blog/524522/
https://habr.com/ru/company/sberdevices/blog/547568/

С одной стороны, возникает большое количество специфичных задач: например, классификация сообщений, выделение именованных сущностей, определение интентов, моделирование диалога, а с другой – необходимость быстрого инференса в условиях большой нагрузки.

В рамках доклада мы поделимся своими практиками, как эффективно обучать большие multitask-модели, быстро собирать необходимые данные и, самое главное, как оптимизировать использование ресурсов памяти и ускорять модели в продакшене.

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

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

На примере одной из наших задач обсудим:
- как использовать обученные ML модели в продакшне;
- как мы мониторим модели и почему это важно;
- путь ML-модели от постановки задачи в Jira до прода;
- как реализуем переобучение (если это необходимо).

Доклад принят в программу конференции

- Математика прогнозирования сложных зависимостей временных рядов;
- эффективные архитектуры для прогнозирования временных рядов;
- ансамблирование подходов в прогнозе временных рядов;
- инфраструктура автоматического решения в облаке.

Презентация - https://docs.google.com/presentation/d/1amBu57gzR4z7vqfHUXB_umTpH9hPycQcg3_glON91EI/edit?usp=sharing

Доклад принят в программу конференции

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

Опыт создания одного из самых успешных BigData сервисов Microsoft, который начинался с небольшой команды разработки специализированного Data solution для сервиса телеметрии и аналитики логов. Отталкиваясь от нескольких нестандартных идей, объединяющих технологии column stores, search engines и классических реляционных баз данных, мы сделали платформу BigData, которая сейчас не только используется многими продуктовыми командами в Azure, но и представляет собой самостоятельный продукт, который успешно продвигается на рынке. В рамках сессии от создателей Azure Data Explorer, будет представлен опыт разработки и лучшие практики взаимодействия в командах, которые сделали Kusto полноценной платформой Big Data с поддержкой AI/ML не только для Log Analytics, но и в областях IoT, BI, Security, Time Series, Finance и Gaming

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

- Modern Data Stack: основные тренды в data infrastruсture
- Большое смещение в ролях Data Engineers vs Data Analysts vs Data Workers
- Что такое AI-augmented data preparation tools?
- Как построить technology-agnostic data pipelines для современных стеков данных вместе с AI
- Требования к современным languages and frameworks для обработки данных и построения data pipelines


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

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

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

Spark Structured Streaming – фреймворк для распределенной обработки данных в режиме близком к реальному времени. Его внушительный функционал позволяет строить сложные realtime-pipeline поставки данных для аналитики и машинного обучения.

Как перевести пайплайн обработки логов с ежедневного ETL на полноценный realtime? Как при этом не потратить все свободные ресурсы кластера? Что делать, если микробатч обрабатывается за 4 часа? Все это разберем на примере интеграции реального контура стриминга логов в рекомендательной системе Rambler&Co, с описанием граблей, на которые мы наступили в процессе разработки и интеграции нового решения.

Я расскажу про свой опыт построения realtime контура обработки данных с использованием Spark Structured Streaming. Обсудим с какими подводными камнями можно столкнуться, если использовать его вместе с Kafka и Clickhouse, и как увеличить свои шансы получить надежную шину для передачи данных в реальном времени.

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

Автоматизация и алгоритмизация — один из векторов развития Delivery Club. Мы стремимся минимизировать ручной труд, сократить субъективное принятие решений и максимально опираться на данные в построении процессов.

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

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

Доклад принят в программу конференции

Many powerful Machine Learning algorithms are based on existing graphs and text retrieval algorithms, e.g., Page Rank (Pregel), Recommendation Engines (collaborative filtering), text summarization and other NLP tasks.
There are even more applications once we consider data pre-processing and feature engineering which are both vital tasks in Machine Learning Pipelines.

But how can we combine Databases with Machine Learning Systems such as TensorFlow or Pytorch? How do Databases fit in more complex Machine Learning Pipelines such as TensorFlow Extended (TFX)? How can we scale Graph-based Machine Learning to the data sizes typically involved in Machine Learning?

Using real-world examples we show how Multi-Model Databases and Machine Learning System (supporting Graph and Search natively) form a very powerful combination. In particular, we will focus on graph-based Machine Learning models and graph-based data pre-processing and feature engineering (which can, in turn, serve as input for a deep neural network).

In this talk you learn about:
* How graphs and text retrieval can help us to model complex Machine Learning tasks in practice.
* How to leverage Databases for graph-based Machine Learning Models.
* How to leverage graphs and search for data pre-processing and feature engineering.
* How Databases integrate into existing Machine Learning Pipelines such as TensorFlow Extended.

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

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

Единственное, что остается в таких случаях — это анализировать текст сообщения.

В своем докладе я расскажу про то, как мы исследовали миллионы спам-писем и разработали систему под названием Spam Term Generator. Эта технология объединила в себе использование CTPH (Context Triggered Piecewise Hashing), DBSCAN (Density-Based Spatial Clustering of Applications with Noise) и LCS (Longest Common Substring) для того, чтобы автоматически определять похожие спам-письма и извлекать из них кусочки повторяющегося текста, которые могут быть использованы для детектирования спам-рассылок.

Во время презентации я расскажу, как наша технология устроена изнутри, с какими сложностями мы столкнулись в процессе разработки, как мы избежали "brute force" анализа исходных текстов и каких результатов нам удалось достичь.

Доклад принят в программу конференции

В Delivery Club есть много задач, которые успешно решаются при помощи алгоритмов машинного обучения (например, планирование количества курьеров, которых мы выводим на смены). Эти алгоритмы используются в offline-режиме.

Однако, есть целый класс задач, для которых требуется наличие в production-инфраструктуре сервисов, способных отдавать предсказания ML-моделей в режиме online.

Мы расскажем, как создавали в Delivery Club первые сервисы, использующие под капотом ML-модели, как мы обеспечиваем безопасность деплоя таких сервисов и как оцениваем качество их работы.

Обсудим следующие темы:
1. особенности ML-сервисов в сравнении с обычными микросервисами;
2. построение инфраструктуры для обучения ML-моделей в production;
3. особенности деплоя и тестирования ML-приложений;
4. как организовать процесс совместной работы Data Science и ML-инженеров.

Доклад принят в программу конференции

Вы узнаете на мастер-классе:

- Как загружать данные любых источников в два клика для управления данными на уровне всей организации;

- Как подход Model Driven Architecture позволяет проектировать процессы обработки данных в визуальном редакторе, а исполняемый Scala-код генерировать автоматически;

- Как конструировать иерархические процессы извлечения, обработки и сохранения данных с использованием библиотеки Spark;

- Как использовать операторы реляционной алгебры в трансформациях данных, бизнес-правила (drools) для обогащения данных;

- Как писать Spark SQL запросы, объединять их в последовательности (pipeline); строить планы запросов, отлаживать и оптимизировать их.

Эксперты компании «Неофлекс» проведут демонстрацию Neoflex Datagram, в рамках которой вы, в режиме реального времени, увидите разработку и запуск трансформаций данных.

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

Несколько лет назад в одном из крупных мобильных операторов переживали рост в части аналитики данных. В компании внедрялись BigData технологии и мы переводили ETL-процессы в хранилище DWH на коробочное решение от Informatica. Изначально у нас были классические ETL-процессы в хранилище DWH на Oracle c ночной загрузкой из источников с помощью настроенных db-link-ов и Oracle Loader.
Объем данных - 10-30 Гб/день. После этого мы начали внедрять большое хранилище с МРР архитектурой (Teradata) размером 150ТБ. А в качестве архитектурного решения для ETL-процессов купили инструмент репликации данных Golden Gate(GG) и Informatica Power Center( IPC ). И настраивали отказоустойчивую систему интеграции данных (High Availability)


В этом докладе хочу поделится:
- причинами внедрения Golde Gate и его преимущества
--специфика промежуточного(STAGE) слоя при загрузке в DWH
- преимущества и недостатки ручных и коробочных ETL решений (на примере Informatica Power Center)
- реальные кейсы ETL процессов загрузки "больших" объемов данных в хранилища. И примеры масштабирования загрузок на IPC.
- с какими сложностями столкнулись при переходе на GG и IPC
- технической архитектурой решения отказоустойчивой системы для IPC.
- архитектура движения потоков данных dataflow от источников к хранилищам
- сформированная методология разработки, отладки и деплоя на IPC и добавления новых источников в Golden Gate

Цель доклада:
--рассказать основные преимущества и недостатки разных ETL-решений и частично помочь зрителю с выбором инструмента интеграции данных.
--Дать представление зрителю с какими вопросами придется столкнутся при переходе на решение IPC
--Показать примеры реальных кейсов загрузки "больших" объемов
--Показать текущий процесс движения потоков данных в хранилище

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

Apache Airflow широко используется для оркестрации ETL data-пайплайнов.
Давайте более детально взглянем на Airflow с точки зрения разработки и эксплуатации: какие особенности помогут избежать проблем, а какие могут потенциально привести к отказу работы распределенных систем.

Кроме того, обсудим:
- Какие есть альтернативы и почему именно Airflow?
- Как выглядит типичный Airflow pipeline и какую функциональность предоставляет?
- С какими трудностями предстоит столкнуться при разработке?
- Можно ли иметь гибкую оркестрацию as a code, с тестами, CI/CD и документацией?
- Способы мониторинга и восстановления после отказов.
- Как можно упростить процесс поддержки кода?
- Интеграция с облачными сервисами и внешними системами: стоит ли пробовать?

Доклад принят в программу конференции

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

Я расскажу о своём опыте прикручивания Spark к проприетарному хранилищу Яндекса YT. На примерах покажу, с какими трудностями пришлось столкнуться, какие есть тонкости и подводные камни. Расскажу, как написать свой коннектор: просто и быстро, или сложнее, но более эффективный. Я объясню внутреннее устройство Spark'а в этой области, обращая внимание на неочевидное поведение и места для расширения.

Доклад принят в программу конференции

Практический опыт создания и эволюции одного из крупнейших в России Озера Данных. Задачи, которые приходится решать, и как удается совмещать технические желания и бизнес-рационализм. Как совместить классические и более современные подходы к архитектуре данных с Hadoop-экосистемой, концептуальная архитектура данных — современные подходы, в чем разница концепций Data Lake и Data Mesh.

Доклад принят в программу конференции

Мы представим DeepQuarantine — облачную технологию для обнаружения и карантина потенциальных спам-сообщений.

Спам-атаки становятся все более разнообразными и могут нанести существенный вред пользователям электронной почты. Стандартные методы борьбы со спамом основаны на создании сигнатур, которые описывают уже известный спам, например, пойманный в специальные ловушки. В большинстве случаев такой подход позволяет обнаружить и описать атаку быстрее, чем она дойдет до клиентов. Однако, иногда это условие не выполняется, и часть нежелательных сообщений может попасть пользователям. Для того чтобы выиграть время для обнаружения спама в ловушках, мы создали решение, которое определяет подозрительные письма и откладывает их в карантин на некоторый срок для повторной проверки. Благодаря высокой точности классификатора большая часть почты, помещенной на карантин, является спамом, что позволяет клиентам использовать электронную почту без задержки. Наше решение основано на применении сверточных нейронных сетей на заголовках MIME для извлечения нетривиальных признаков из большого объема исторических данных. Мы оценили предложенный метод на реальных коллекциях и показали, что решение снижает False-Negative на 30%.

Доклад принят в программу конференции

Почему считается, что data scientist’ы плохо пишут код? О хороших практиках внедрения моделей машинного обучения глазами исследователя данных Kaspersky. MLOps: CI/CD, мониторинг, алертинг на живом примере. Как модель постепенно обросла вокруг себя развесистой инфраструктурой и что из этого вышло.
Что будет на выступлении:
– Пройдем весь этап эволюции модели от notebook, до production на конкретном примере. Соберем грабли и рассмотрим наши решения;
– Рассуждение на тему важности MLOps и почему это необходимо современному DS'у

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

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

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

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

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

MLOps вид сверху
MLOps роли
Философия и принципы компонентов MLOps
Важность качества данных
Интеграция проверки качества данных по всему MLOps процессу

Доклад принят в программу конференции

Год назад мы выбирали open-source платформу машинного обучения для заказчика, чтобы их специалисты (а так же специалисты IBM) могли вести коллаборационную работу в совместных data science проектах.
В докладе будет рассказано про основные решения, которые были рассмотрены нами в качестве кандидатов, их минусы и плюсы. Перечислены основные выученные уроки, подводные камни и функциональные требования, выведенные нами к ходе работы над данным проектом.

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

Мы реализуем продукт, который позволяет преобразовать пользовательскую историю web-браузера в n-значный числовой вектор (embedding). Для преобразования неструктурированной информации о пользователе в векторный вид используется совокупность методов и моделей машинного обучения.

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

Важным преимуществом использования представления человека в виде числового вектора является деперсонификация и анонимизация профиля человека, поэтому одной из перспектив использование модели является обучение в режиме Federated Learning в контуре заказчика.

Доклад принят в программу конференции

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

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

В этом докладе я расскажу о методике online-оценки ёмкости сервиса и планирования ресурсов, применяемой в Яндекс.Маркете.

Доклад принят в программу конференции

В докладе я расскажу про разработку и использование платформы для автоматизации тестирования финтех-приложений th2. Я работаю в компании Exactpro и руковожу проектом по разработке этой платформы. В моей команде сейчас 40 человек.

Основная особенность платформы состоит в том, что она создана специально для тестирования на стыке между функциональными и нефункциональными требованиями, с использованием больших объемом автоматизированного функционального тестирования (HiVAT).

Я расскажу про процесс разработки и технологический стек платформы th2, который включает в себя Kubernetes, Cassandra, RabbitMQ.

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

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

Не тормозить — основное продуктовое качество ClickHouse, которое возникает как результат целостной работы по многим направлениям: подходящих архитектурных решений, алгоритмической оптимизации, и небольшого количества связующей магии. За последний месяц в основную ветку ClickHouse добавилось 650 самостоятельных изменений — всевозможные улучшения, новая функциональность, исправления багов. Как при такой скорости разработки не потерять достигнутого? Ответ известен: автоматические тесты. Любое важное продуктовое качество необходимо тестировать, чтобы не потерять его в постоянном потоке изменений. Это верно и для производительности.

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

Доклад принят в программу конференции

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

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

Мы покажем только интересное о том, как:
1. смоделировать большую распределенную сеть на одном узле?
2. подключить внешние сервисы?
3. смотреть за сообщениями в протоколе?
4. интерактивно динамически мучить сервисы и сеть;
5. описать процесс в виде воспроизводимого теста (из кода).

Вся эта магия средствами ПО с открытым исходным кодом. С автоматизацией процесса за 300 строк или меньше!

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

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

На самом деле это не так: ошибки будут всегда и надо уметь с ними правильно обращаться.

Доклад принят в программу конференции

Реляционные СУБД нанесли очередной удар NoSQL — это стандартизация работы с JSON на языке SQL, что открывает богатые возможности для разработчиков приложений. Я расскажу про то, что уже реализовано в постгресе, что ожидается в ближайшем релизе и каким мы видим будущее JSON.

Доклад принят в программу конференции

Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool.

Доклад принят в программу конференции

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

В докладе рассмотрим, что на самом деле происходит под капотом: как данные распределяются в кластере Apache Ignite, индексируют для поиска на узле и как в конечном счете записываются на жесткий диск.

Доклад принят в программу конференции

При использовании бэкапов пользователь всегда надеется на 2 вещи: из бэкапа можно гарантированно восстановиться, восстановление будет быстрым.

В данном докладе мы расскажем о том, с какими проблемами сталкивались в Яндексе, когда эти надежды не оправдывались, и как, благодаря этим проблемам, мы придумали и реализовали решения, позволяющие создавать с помощью WAL-G более надежные бэкапы и восстанавливать их еще быстрее.

WAL-G — простой и эффективный инструмент резервного копирования PostgreSQL (и не только) в облака. В основной функциональности WAL-G является наследником WAL-E, написан на Go. Доклад будет посвящён новым возможностям WAL-G, реализованным в ходе Google Summer of Code, базовая функциональность резервного копирования будет рассмотрена предельно сжато.

Доклад принят в программу конференции

Каждый владелец большой базы данных, разработчик и DBA должен понимать возможности по модификации структуры базы данных. В мире MySQL уже есть несколько технологий, которые помогают справиться с этой проблемой: online DDL, pt-online-schema-change, gh-ost, JSON поля. Репликация и синхронные кластеры (InnoDB Cluster, Galera) позволяют работать с отличиями в схемах на узлах и обновлять кластер постепенно узел за узлом. Презентация позволит детально понимать ограничения каждого из методов и научит не убивать боевую базу дурацким ALTER TABLE.

Доклад принят в программу конференции

Вы когда-нибудь задумывались о том, чтобы сделать свою собственную SQL-базу данных? Или о том, чтобы запускать SQL-запросы в вашей NoSQL-базе данных? Это кажется очень непростой задачей: нужно научиться парсить, оптимизировать и исполнять пользовательские запросы. А если мы говорим о распределенной базе данных, то сложность задачи многократно возрастает. К счастью, благодаря фреймворку с открытым кодом под названием Apache Calcite, вы сможете сделать это довольно легко.

В докладе я расскажу об опыте интеграции Apache Calcite в распределенную in-memory-платформу Apache Ignite. Покажу примеры кода и поделюсь универсальным планом интеграции SQL на основе Apache Calcite в любую другую систему.

Доклад принят в программу конференции

Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

В докладе мы подробно разберём ряд типичных ошибок разработчиков, архитекторов и администраторов баз данных, регулярно совершаемые при активной разработке приложений, когда необходимо изменить схему БД — от добавления новых объектов БД, столбцов до рефакторинга и оптимизации существующей схемы. Обсудим подводные камни, связанные с управлением транзакциями, блокировками, различными настройками Постгреса.

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

И наконец, основываясь на многолетнем опыте работы с быстрорастущими командами, обсудим организационные вопросы — как выстроить процессы разработки так, чтобы риски простоя и деградации производительности были сведены к минимуму, а команды разработчиков развивались и постоянно наращивали экспертизу работы с БД.

Доклад принят в программу конференции

К конференции уже будет окончательно определено, какие фичи попадут в состав 14-й версии PostgreSQL. Мы обсудим те из них, которые повышают производительность СУБД и помогают создавать устойчивые к высоким нагрузками архитектуры систем. Заодно поговорим и о 13-й версии, которая вышла, а на Highload'е представлена так и не была.

Будут затронуты вопросы: вакуума, секционирования таблиц, настроек и другие.
Самое интересное будет снабжено практическими примерами и иллюстрациями.

Доклад принят в программу конференции

GitLab.com has an aggressive SLA, that made us research and development for solutions to improve our performance in all the directions, on one of the most important components in our architecture, the PostgreSQL relational database.
During this talk, we would like to invite you to explore the details about how we improve the performance of the main PostgreSQL relational database of GitLab.com in a high demanding environment with a load between 40k to 60k transactions per sec.

We would share with you our projects, processes and tools, and all the components that we have developed with our partner Postgres.ai, which makes possible deep analysis in several aspects from our database ecosystem.

Доклад принят в программу конференции

Мы разрабатываем Badoo и Bumble — дейтинг-приложения для миллионов пользователей по всему миру. Для анализа такой нагрузки мы создали инструмент поиска аномалий на графиках.

Основная цель Anomaly Detection — зафиксировать аномалии в поведении метрик и сообщить об этом ответственным за них сотрудникам.

В этом докладе я буду делать упор на технологии, которые мы использовали: Clickhouse, алгоритмы предсказаний и процесс портирования этих алгоритмов на SQL. Такой стек позволяет нам процессить миллионы графиков в сжатые сроки.

Я расскажу:
* что такое аномалии, основные термины;
* как мы выбирали стек технологий;
* как работают алгоритмы предсказаний;
* о выборе доверительного интервала;
* о выборе лучшей модели;
* о последующем анализе аномалий.

Вы увидите, что портирование математических формул в клике — не так уж и сложно.

Доклад принят в программу конференции

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

Доклад принят в программу конференции

Большинство современных СУБД изначально не задумывались для использования в Облаках, и требуются значительные усилия для их использования в облачном окружении. Облака всем обещают масштабируемость, надежность, доступность и прочее, но сдержать эти обещания для приложений, интенсивно работающих с данными, очень нетривиально. В докладе я расскажу об опыте Altinity в этой области на примере ClickHouse, но наш опыт и выводы в целом применимы для любых СУБД.

Мы рассмотрим модель типа "матрешка", в которой используется Kubernetes для управления кластерами СУБД в публичных облаках (AWS, GCP), и какие дополнительные штуки нужны, чтобы сделать СУБД "дружественной" к облакам. Возможности всех трех уровней — публичного облака, Kubernetes и СУБД — должны быть согласованы друг с другом для надежной работы облачного сервиса. В принципе, это работает, но напоминает то ли "прокрустово ложе" из греческой мифологии, то ли "испанский сапог" из Средних веков.

Мы обсудим, что требуется от СУБД, чтобы она чувствовала себя удобно и комфортно в Облаке. Это включает в себя разделение вычисления и хранения, интеграция с сетевыми системами хранения, другая модель репликации и т.д.

А в конце немного помечтаем о будущих бессерверных (serverless) СУБД.

Доклад принят в программу конференции

Tarantool — это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности, движок для хранения данных в оперативной памяти — memtx. Tarantool — open source-проект: исходный код находится в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания.

Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.

Данная структура используется для многомерного поиска. Часто в БД для подобных задач применяют R-Tree, но здесь возникло желание реализовать своё экзотическое решение и сравнить его с традиционными подходами. В основе лежит обычное B-дерево, поэтому данный подход должен получиться компактным и быстрым.

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

Доклад принят в программу конференции

Правда ли, что распаковать данные — быстрее, чем просто скопировать их? Ответ: "нет и да", а вообще всё сложнее. Как быстрее всего транспонировать Structure of Arrays в Array of Structures и зачем это нужно? Как лучше читать файлы — read, O_DIRECT, mmap, io_uring? Ответ снова нетривиален. Почему MergeTree-таблицы в ClickHouse могут работать лучше, чем in-memory-таблицы?

В своём докладе я расскажу про некоторые интересные случаи исследования и оптимизации производительности, с которыми разработчики ClickHouse сталкиваются на практике.

Доклад принят в программу конференции

1. Использование особенностей MySQL и причины невозможности перехода на другую БД?
2. multisource репликация, наш опыт перехода и эксплуатации
3. Эволюционный путь монолита

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

В этом докладе пойдет речь о малоизвестной утилите под названием cluster-copier, которая включена в стандартную поставку ClickHouse.

Я расскажу о ее внутреннем устройстве и о том, что я сделал для ее улучшения. Также будут затронуты такие темы, как репликация и шардирование.

Доклад принят в программу конференции

Внедряем CubeJs - готовый аналитический бекэнд для вашего проекта.
Вопросы интеграции, безопасности, производительности, мултитенантности, деплоя CubeJs на реальных примерах

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

Running databases in Kubernetes attracts a lot of attention today. Orсhestration of MySQL on Kubernetes is no way a straightforward process. There are several good MySQL based solutions in the open-source world, made by Oracle, Presslabs, and Percona. Having a common base, they differ in self-healing capabilities, consistency guarantees, storage capabilities, monitoring, proxying and backup / restore support, etc. So, let’s make a fair comparison to figure out the pros and cons of their current state.

Доклад принят в программу конференции

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

Но если главный узел выполнил транзакцию, успешно ответил клиенту и не успел отправить транзакцию на реплики до своего отказа, то после переключения на резервную реплику с точки зрения клиента транзакция потеряна. Была и пропала.

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

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

Обычно синхронная репликация реализуется через протокол Raft. Он проверен временем, его корректность доказана. Но у него есть ограничения:
* не предполагается наличие мастер-мастер-репликации ни в каком виде;
* журнал транзакций (WAL, Write Ahead Log) должен удовлетворять определенным свойствам.

Это сильно усложняет внедрение Raft в существующую БД без поломок обратной совместимости в журнале и без запрета мастер-мастер-репликации.

Именно эта задача появилась в СУБД Тарантул. Годами продолжались попытки реализовать чистый Raft или что угодно на его замену. Задача нетривиальна, так как мастер-мастер в Тарантуле поддерживается, из-за чего его журнал имеет очень специфичный формат, использующий векторные часы.

В версии 2.5.1 был создан новый алгоритм. Он берет за основу Raft и делит его на две независимые части: репликация и выборы лидера. При этом можно выбирать, какие транзакции синхронные, а какие — нет. Это позволяет платить за синхронность только для действительно критичных изменений. Журнал при этом полностью совместим со старыми версиями, и открыта возможность реализации синхронной мастер-мастер-репликации в будущем.

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

Доклад принят в программу конференции

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

В этом докладе я расскажу о наиболее важных улучшениях наблюдаемости в MySQL 8, начиная от Performance Schema и Information Schema и заканчивая улучшенным логированием ошибок и Optimizer Trace. А также разберу одну из важнейших составляющих мониторинга – анализ запросов – на примере работы с бесплатным инструментом Percona Monitoring and Management (PMM).

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

Доклад принят в программу конференции

Есть нагруженная SQL-база данных известного вендора, есть потребность: получать изменения из этой базы в realtime, желательно, не переписывая все сервисы, которые пишут в эту базу данные, и отправлять их дальше. Расскажем, как мы сделали Change Data Capture из Oracle, какие способы опробовали, какие грабли собрали и как их обошли.

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

Мы сделали change data capture и стриминг событий из Oracle в витрины на Tarantool с использованием GoldenGate и Tarantool. У нас получилось довольно простое и производительное решение, которое встало в существующую архитектуру.

Расскажем:
- что такое и зачем нужен change data capture;
- варианты встраивания в существующую архитектуру;
- как мы делали загрузку и репликацию данных из Oracle в Tarantool;
- про грабли и как мы их побороли.

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

API Gateway — тема, которую обсуждают давно, технология, которую применяют уже многие компании по всему миру. Но все еще возникают вопросы: а какие функции в себе должна содержать эта технология? Зачем этим функции нужны? Что они дают, что отнимают?

В этом докладе я расскажу о том:
- какие функции API Gateway должен иметь;
- что они дают;
- когда API Gateway нужно применять, а когда это вредно.

И напоследок рассмотрим несколько популярных API Gateway и поймем, какая роль у данной технологии в Mesh Oriented-архитектуре.

Минимум теории, больше практики и реальных случаев. Все материалы, мысли, тезисы, представленные в этом докладе, — это накопленный опыт последних 3-х лет.

Доклад принят в программу конференции

В этом докладе я расскажу, что происходит под капотом: от "приложил карту" в магазине до "получил "ок" на POS-терминале.

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

Доклад принят в программу конференции

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

В докладе я расскажу:
- что вообще должен делать типичный игровой сервер, из каких частей он состоит;
- на каких технологиях мы остановились для разработки игровых серверов (спойлер: Vert.X Hazelcast, Postgres, Kafka, Prometheus + Grafana, Consul, Photon Cloud);
- как мы их используем (спойлер: не все по прямому назначению);
- каким образом мы устанавливаем обновления;
- несколько интересных ошибок, которые мы словили при работе с Vert.X и Hazelcast.

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

Доклад принят в программу конференции

Мы делаем платформу для работы с биометрическими данными в масштабах страны: система рассчитана на 150 миллионов человек, на высокие нагрузки в сотни транзакций в секунду, включая юридически значимую верификацию и проверку “liveness”.

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

Также рассмотрим вопросы обеспечения высокой производительности и масштабируемости, отказоустойчивости и отсутствия потерь данных при отказах оборудования. Покажем примеры использования Openshift, Hadoop, HBase, Kafka для решения этих вопросов.

Доклад принят в программу конференции

При проектировании высоконагруженных систем многие используют подход «сначала померить». Этот подход дает точный результат, но требует больших трудозатрат, особенно в случае ошибки в архитектуре.

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

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

Доклад принят в программу конференции

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

Почти все встречались с упоминанием процесса выбора нового мастера при отказе существующего, многие слышали о распределенных транзакциях, некоторые даже знают такие страшные слова, как Paxos, Raft и Bitcoin-консенсус. Но понимаете ли вы, как они работают и зачем нужны?

Я постараюсь объяснить, как эти алгоритмы устроены и зачем нам, рядовым разработчикам, это знать.
Если останется время, то разберем нюансы реализации в различных приложениях.

Доклад принят в программу конференции

Любой облачный провайдер ставит своим приоритетом сохранность пользовательских данных, и резервное копирование — один из инструментов, который используется для решения этой задачи. При развертывании сервиса резервного копирования у себя в Mail.ru Cloud Solutions мы столкнулись с серьезной проблемой. Средства резервного копирования, предоставляемые программным обеспечением платформы, не могли обеспечить копирование требуемых объемов данных за заданное время.

Несколько попыток обойтись “малой кровью” ясно обозначили — мы ограничены со всех сторон: производительность систем хранения, производительность самих драйверов резервного копирования дисков, производительность процессора, способы работы Runtime Environment с системой хранения. Для нас это означало невозможность реализовать бизнес-сценарии и вынудило к реализации своего драйвера копирования дисков виртуальной платформы, который обходил эти ограничения.

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

Доклад принят в программу конференции

В докладе я расскажу о том, как мы строили свою первую облачную платформу и каким получился этот опыт. Мы прошли путь от идеи до сервиса с личным кабинетом и публичным API. Обсудим архитектурные решения, которые принимались в процессе разработки и "грабли", на которые наступили.

Что будет в докладе:
- с чего начинался проект, идея и первые шаги
- что «под капотом» у нашего облака - архитектура проекта
- проблемы на этапе разработки и интеграции систем
- как готовили public API к релизу: чем руководствовались и как оптимизировали

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

В докладе расскажу, как в Авито перешли от программирования формочек до полноценной Metadata Management System или, как мы ее называем, — Infomodel.

Цель доклада — поделиться опытом построения архитектуры управления метаданными. Наша система объединяет все этапы работы с метаданными сайтов объявлений и маркетплейсов: от построения форм, построения url для SERP до индексации данных и поисковых фильтров. Раскрою технические детали системы, которая обрабатывает десятки тысяч запросов в секунду. Расскажу, зачем мы написали свою read only-базу данных с интерпретируемым DSL и как у нас выглядит EAV.

Система уже ведена в эксплуатацию, и я расскажу о ее плюсах и минусах. Доклад будет интересен разработчикам и архитекторам схожих проектов для перенятия нашего опыта в построении подобных систем.

Доклад принят в программу конференции

С конца прошлого года фокус развития всего сервиса объявлений Юла направлен на социализацию, и в связи с этим у нас было два крупных релиза: мы первые в мире запустили видеозвонки внутри сервиса и мы первые на российском рынке классифайдов запустили P2P-звонки и сториз. Именно о реализации последнего расскажем подробнее.

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

Доклад принят в программу конференции

Мы разрабатываем Badoo и Bumble — дейтинг-приложения для миллионов пользователей по всему миру. При внушительном количестве клиентов, версий и интерфейсов на 52 языках, вопрос локализации для нас не просто важен, а критичен.

Я расскажу, как:
- синхронизировать работу переводческих и инженерных команд;
- версионировать тексты и их переводы;
- обновлять тексты и переводы на клиенте и сервере;
- обеспечить консистентность переводов на сервере и клиентах.

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

Доклад принят в программу конференции

Hazelcast IMDG — это распределенное key-value-хранилище. В докладе я расскажу, как мы добавляли поддержку SQL в продукт и с какими трудностями столкнулись:
- реализация оптимизатора распределенных запросов на основе Apache Calcite;
- адаптация существующей key-value-архитектуры продукта под потребности SQL;
- проблемы отказоустойчивости и масштабируемости SQL в кластере.

Доклад принят в программу конференции

При недоступности приложения Такси пользователь в пару кликов уходит к конкуренту. Поэтому отказоустойчивость — наш приоритет.

Я расскажу:
- что часто приводит к проблемам в больших сервисах;
- какие подходы (паттерны отказоустойчивости) помогают переживать их незаметно;
- как паттерны "делают стабильность" и как применить их в любом проекте;
- зачем сделали свой circuit breaker, чем полезен API Gateway, как приготовить конфиги; как пережить отказ критической СУБД.

Доклад принят в программу конференции

Мой доклад осветит набор основных инструментов из экосистемы cloud native compute fundation для перехода к микросервисной архитектуре. Я расскажу, что важно не забыть сделать при таком переходе и какие могут появиться проблемы: от изменений в оргструктуре компании до смены парадигм в разработке.

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

Доклад принят в программу конференции

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

В докладе расскажу, как мы разрабатывали платформу видеоконференций ВКонтакте и как сделать высоконагруженный сервис конференц-звонков на 1000+ участников в одном звонке своими руками.

Рассмотрим, как вообще устроены звонки и какие проблемы предстоит решить, чтобы сделать ваши звонки лучше звонков конкурентов. Из доклада вы узнаете:
* Как внедрить групповые звонки в web, iOS, Android.
* Зачем в звонках CDN и как выбрать географию.
* Как еще можно уменьшить latency.
* Что нужно, чтобы реализовать конференции на 1000+ участников.
* Отказоустойчивость уровня дата-центра.
* Как работать со звуком и сделать шумоподавление.
* Как искусственный интеллект помогает сделать видеозвонки лучше.

А также поговорим о том, что найти баланс между количеством серверных мощностей, нагрузкой на пользовательские устройства и качеством — это и есть главный челлендж высоконагруженного сервиса видеоконференций.

Доклад принят в программу конференции

Юла активно переходит на микросервисную архитектуру и год назад начала использовать GraphQL, внедрив её в новый gateway. Однако, за год мы столкнулись с определенными проблемами: растущее число внутренних сервисов и команд уже не позволяло так же быстро и гибко внедрять новый функционал, а изначально легкий gateway начал превращаться в очередной монолит.

Исследовав варианты решения, мы пришли к Apollo Federation – технологии, которая с одной стороны позволила нам разбить монолитную схему основного gateway, а с другой – объединиться со схемами других бизнес-юнитов.

Мы поделимся своим опытом использования GraphQL на примере большого сервиса: от внедрения первого легковесного gateway до распределенной схемы с использованием Apollo Federation.

Доклад принят в программу конференции

Можно ли деплоить Kubernetes кластеры так же просто как мы деплоим приложения? Да, мы сделали Kubernetes проще.
Декларативные API и инструменты для автоматизации развертывания и сопровождения жизненного цикла отдельных узлов и целых кластеров OpenShift.

Доклад принят в программу конференции

Иногда серверы “умирают”.

Все начинается с необычного скачка нагрузки на веб-сервере — повышенное потребление памяти и CPU. У клиентов сайт грузится медленно, DevOps наблюдают увеличение задержек на графиках. Через несколько минут база данных дает сбой, и вскоре еще несколько серверов “отваливаются” один за другим. Перезапуск серверов не помогает, поскольку при запуске сервер сразу попадает в аварийный цикл, и становится понятно, что хотя изначальный всплеск нагрузки давно позади, ситуация уже не исправится сама собой. Характерно то, что в коде нет очевидного “бага”, и трудно понять, почему возник аварийный цикл перезагрузок.

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

Если человеку дать больше работы, чем он может выполнить, то может случиться так, что будет выполнена только часть работы, но мы обычно не ожидаем смертельных случаев. Должны ли наши серверы отличаться в этом отношении?

> Вопрос на миллион долларов — должен-ли сервер умирать из-за нагрузки?

К сожалению, ситуация аварийного цикла (crash loop) знакома многим инженерам, и цель этого доклада — вооружить инженеров всем необходимым для защиты от нее.

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

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

Теоретические исследования были проверены на практике в нашей компании, и наши системы выстояли под нагрузкой в праздничные дни, когда многие системы массового обслуживания терпят сбои.

Слушатели смогут сразу применить полученные знания в своих системах, независимо от экосистемы разработки.

Доклад принят в программу конференции

Когда пропадает простой способ масштабировать сервис под нагрузкой — появляется хайлоад. Но случается такое не сразу, не у всех и не всегда. Многие сервисы годами работают на "нехайлоадных" PHP, Python и Ruby, обрабатывая тысячи веб-запросов в секунду и не чувствуя необходимости писать свой компилятор PHP или переходить на Go с Rust.

В докладе я расскажу о том, когда именно наступает переломный момент для Python и Ruby, двух "хипстерско-хайповых" стеков, первый из которых нам регулярно приносят дейта-сайентисты, а второй все никак не может умереть и время от времени демонстрирует проекты вроде "hey.com".

Взяв за основу "типовые" Python- и Ruby-проекты, как их модно делать в 2020 году, я покажу, что именно происходит после nginx, как современные application-сервера для этих языков взаимодействуют с виртуальными машинами, что дают и отнимают веб-фреймворки и чем это все отличается по скорости от "си-шного" хайлоада, способного выдавать сотни тысяч запросов в секунду. Python и Ruby действительно медленные и с GIL, но при правильном использовании это не проблема, а статья расходов — и я расскажу, что мы можем получить за эти деньги.

Доклад принят в программу конференции

Мой доклад будет посвящён вопросам, которые у вас возникнут при внедрении или эксплуатации публичных облаков от компаний AWS, Google, Azure, Yandex.

Если вы долго работали в приватной инфраструктуре или с традиционными IaaS-провайдерами, то вы, вероятно, думаете, что публичное облако работает так же. Но это немного не так. Каждое такое облако работает по своим законам, которые могут показаться новыми. Зная эти законы, можно сделать свою инфраструктуру полностью автоматизированной и масштабируемой. О них мы и поговорим.

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

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

План доклада:
1. Что такое публичное облако в 2020 году.
2. Какие парадигмы меняет публичное облако.
3. Зачем публичное облако действительно нужно.
4. Рекомендации для обеспечения масштабирования, высокой доступности и мультитенантности.

1. IaaS.
2. PaaS — Databases.
3. PaaS — Containers.
4. PaaS — Serverless.

Доклад принят в программу конференции

Kafka в Авито постоянно развивается, и вот настало время начать жить на 3 ДЦ. Мы провели исследование различных топологий размещения кластеров, разных способов межкластерной репликации и реализовали итоговое решение.

В докладе я расскажу, какие вызовы может встретить компания при использовании Kafka в нескольких ДЦ и как эти вызовы решили мы в Авито. Также пройдемся по возможностям Kafka (версия 2.4+) и технологиям из Kafka-экосистемы, помогающим организовать мультиДЦ-кластеры.

Доклад принят в программу конференции

В OZON мы разработали и успешно внедрили инструмент DMP (Data Management Platform), который автоматизирует процесс создания сегментов через фильтрацию пользовательских событий. DMP — программная платформа для сбора, хранения, систематизации и анализа данных о взаимодействии пользователей с OZON.

Ежедневно мы обрабатываем более 1,5 млрд. событий от миллионов пользователей. Эти данные мы используем для построения сегментов с целью планирования рекламных кампаний, проведения маркетинговых акций и персонализированных коммуникаций.

В своем докладе я расскажу:
- как мы пришли к необходимости разработки собственной платформы DMP;
- об архитектуре платформы и как храним сегменты в PostgreSQL;
- как обеспечивается время ответа < 10 мс;
- как мы используем ClickHouse для хранения пользовательских событий;
- каким было сегментирование до внедрения конструктора сегментов и как используем сегменты для повышения бизнес-метрик;
- о плюсах и минусах нашего решения и с какими проблемами мы столкнулись в процессе эксплуатации.

Доклад принят в программу конференции

Рассмотрим одну из базовых задач, которую решает любая мировая биржа — быструю доставку данных о заявках до клиентов. На первый взгляд, задача не выглядит сложной, но есть отягчающие обстоятельства:
- поток данных может достигать нескольких сотен тысяч запросов в секунду;
- потребителей может быть сотни, а то и тысячи;
- время между генерацией ордера и попаданием его конечному потребителю должно быть не более 5 мс в 99% случаев.

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

Доклад принят в программу конференции

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

В своём докладе я расскажу, на что нужно смотреть при выборе очереди, а также приведу сравнительные характеристики RabbitMQ, Kafka, NSQ и других кандидатов.

Доклад принят в программу конференции

* Создать stateless-платежный шлюз — это реально. Достаточно кодировать данные о платежной транзакции в подписанный url.
* Не спешите использовать реляционные базы данных для хранения информации о платежах, обратите внимание на S3-хранилище — оно легко масштабируется и, как показывает практика, его можно подружить с PCIDSS.
* etcd — это хорошее решение для недопущения двойных списаний со счетов клиентов по одной платежной транзакции.
* Кролики — это не только ценный мех, но и еще и хороший инструмент для реализации паттерна retry (с использованием RabbitMQ).

Доклад принят в программу конференции

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

В этом докладе поговорим о том, зачем нужен распределенный SQL, чем он отличается от SQL в традиционных базах, что он делает отлично, а что — не так хорошо. Как пример поддержки распределенного SQL будем использовать Apache Ignite.

Доклад принят в программу конференции

Причины, зачем может понадобится сбор данных о доменах и размещенных на них сайтах, могут быть разными. В нашем случае речь шла о лучшем понимании, что же происходит на сайтах клиентов и как меняется интернет. Некоторое время мы покупали эти данные, но качество оставляло желать лучшего. Таким образом мы пришли к задаче написания собственного Domain Crawler'а, способного обходить до 100 миллионов доменов и собирать самую разную информацию о них.
В докладе планируется осветить различные аспекты и проблемы построения такого решения: где можно получить данные бесплатно, где можно купить нужные данные, как можно организовать архитектуру, как масштабировать проект, как следить за качеством и, конечно же, какие ожидают грабли на этом, весьма тернистом, пути.

Доклад принят в программу конференции

Мы используем распределенное хранилище Apache Ignite в продакшне, как следствие, — предъявляем к нему высокие требования по надежности и доступности.

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

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

Доклад принят в программу конференции

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции.

Эволюция технологий JIT- и AOT-компиляции во многом идут параллельными путями.

В докладе будет рассказано о новейших достижениях JIT-компиляторов для Java- и JavaScript-платформ, а также о фундаментальных отличиях JIT- и AOT-компиляторов.

Доклад принят в программу конференции

Ключевой составляющей инфраструктуры Яндекса является система YT, позволяющая распределенно и надежно исполнять вычисления над большими объемами данных. YT (https://habr.com/ru/company/yandex/blog/311104/, https://www.youtube.com/watch?v=VQGfH0sZi18) – это собственная разработка компании. Данная система предоставляет пользователям распределенное отказоустойчивое хранилище данных, а также богатые возможности для выполнения Map-Reduce-вычислений над этими данными.

В докладе мы поговорим про планировщик – компоненту, которая отвечает за оперативное выделение ресурсов под задачи пользователей и соблюдение гарантий, данных пользователям. В одном из предыдущих докладов (https://www.highload.ru/moscow/2019/abstracts/6085) мы рассказывали про архитектуру планировщика и используемые подходы к масштабируемости и отказоустойчивости. В этот раз мы поговорим про то, как решать непосредственно задачу планирования.

Одна из важных задач, стоящих перед компанией – экономия вычислительных ресурсов, которая позволяет уменьшить затраты на покупку и эксплуатацию серверов. Поэтому внутри компании развернуто несколько больших YT-кластеров в разных дата-центрах, в которых на одних и тех же серверах сосуществуют batch-вычисления самых разных проектов: от регулярного построения поискового индекса и решения задач маршрутизации до ad-hoc-аналитики и экспериментов с обучением нейронных сетей на GPU-картах.

Описанная ситуация накладывает на планировщик следующие требования:
1. Отказоустойчивость: любой даунтайм планировщика – это простой десятков тысяч серверов в кластере и нарушение гарантий на время выполнения production-задач.
2. Эффективность: каждую секунду на кластере завершаются тысячи задач; чтобы обеспечивать хорошую утилизацию, планировщик должен оперативно планировать на их место новые задачи.
3. Честность: одним кластером пользуется множество различных потребителей; из продуктовых соображений разным потребителям полагаются те или иные гарантии. Планировщик должен уметь соблюдать гарантии, отраженные в его конфигурации, и оперативно выделять проектам полагающиеся им ресурсы.

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

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

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

Доклад принят в программу конференции

Рассмотрим ошибки, проблемы и особенности систем мониторинга транспорта в реальном времени на примере конкретной микросервисной архитектуры Python + Rabbit + Clickhouse, обслуживающей взаимодействие 40 тысяч движущихся и 2 миллионов статичных объектов на карте.

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

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

Доклад принят в программу конференции

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

Вместе с вами мы попытаемся найти ответ на вопрос "Действительно ли это так?". На примерах реальных отказов разберем ситуации, в которых геораспределенность не помогла, а усугубила потенциальные проблемы.

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

Доклад принят в программу конференции