Рейтинг@Mail.ru

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

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

Архитектура и производительность фронтенда

RUST + WEBASSEMBLY

Илья Барышников

* Зачем это нужно?
* О производительности в JavaScript, сильные и слабые стороны браузерных движков.
* Какие проблемы решает WebAssembly.
* Какие выгоды от использования Rust при компиляции в WebAssembly.
* Инструменты для разработки - сборка и публикация модулей, взаимодействие с JavaScript, отладка.
* Прирост производительности по сравнению с JavaScript.
* Внедрение в существующее веб-приложение.
* Опыт применения в реальном проекте.

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

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

Практики, особенности и нюансы при работе с Postgres в Go

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

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта.

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

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

vert.x против классической многопоточности в JVM

Владимир Красильщик

В своем докладе я покажу, как такие классические задачи на многопоточность, как “Читатели и писатели” или “Обедающие философы”, благодаря отходу от классической Java Concurrency с блокировками, могут быть решены без блокировок на vert.x: полиглотном фреймворке для создания реактивных высоконагруженных приложений на JVM.

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

Compile-time-генерация Java-кода на практике

Андрей Маркелов
Сергей Бобков

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

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

Транзакции и блокировки: практические кейсы

Александр Карпинский

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

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

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

Глубокое обучение для распознавания достопримечательностей на изображениях в Mail.Ru

Андрей Бояров

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

Описываемый подход основан на глубоких свёрточных нейронных сетях и требует одного прохода изображения через сеть, что делает его достаточно быстрым для использования в продакшне и обработки большого количества пользовательских фотографий. В докладе будет подробно рассказано об основных компонентах метода, таких как архитектура нейронной сети, стратегия обучения сети и особенности принятия решения о наличии достопримечательности на изображении. Описанная система развернута как часть решения по распознаванию фотографий в Cloud Mail.Ru, которое является сервисом обмена и хранения фотографий в Mail.Ru Group.

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

Дать алгоритму удочку, а не рыбу! Как обучаться в ситуации, когда данных много, а разметки - мало?

Иван Бондаренко

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

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

Что делать, как быть? Как, сохранив преимущества обучения с учителем, заставить алгоритм стать более самостоятельным и использовать минимум размеченных данных? Приходите, расскажу и покажу! Правда, показывать я буду в основном на примерах из компьютерной лингвистики и анализа текстов, поскольку, во-первых, именно для этой области прикладного ML проблема маленького объёма размеченных датасетов особенно актуальна, а во-вторых, я просто люблю компьютерную лингвистику :-)

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

Немного антихайпа про машинное обучение на примере статического анализа кода

Андрей Карпов

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

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

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

Иван Голованов
Станислав Шушкевич

В нашей компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию Glidewelldental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д. Самая сложная и недетерминированная часть производства – дизайн протеза, который в настоящее время выполняется в CAD-системе на компьютере. Каждый протез делается под конкретного человека и уникален по своей геометрии, отвечая конкретному челюстному слепку, при этом у каждого дизайн-техника своё субъективное видение, что такое хорошая зубная коронка. Помимо задачи генерации дизайна, мы решаем также ряд задач по автоматической классификации входных данных: определение номера реставрируемого зуба, выделение его соседей и пр. В докладе будет рассказано о том, как мы автоматизируем различные этапы производства с помощью нейронных сетей, постепенно сводя влияние человеческого фактора к минимуму.

Даже в простых «потоковых» задачах типа предварительной сортировки массива входных зубных слепков по департаментам человек склонен допускать довольно много ошибок – в наших условиях несколько процентов; с помощью несложной распознающей сети процент ошибок можно понизить до долей процента.

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

Для решения таких задач ключевым компонентом с одной стороны является быстрый доступ к данным (общий объем наших данных составляет более 5 млн. кейсов, или порядка 150 Тб, они хранятся в облаке Amazon) и удобные средства для преселекции - выборки случаев с нужным зубом и типом реставрации и пр., для этого мы используем разработанный в компании сервис CMS+Orcas. С другой стороны, необходимо оперативно тестировать натренированные локально сети (разные сети при этом используют разные фреймворки), и с наименьшими изменениями переводить их из режима тестирования в рабочий, высоконагруженный режим. Для этого мы используем внутренний сервис DLFrame, который единообразно хранит и «прогоняет» сети, обеспечивая надёжность, быстрый отклик и масштабируемость.

Наша группа сотрудничает с институтом Беркли (США) в части разработки глубоких нейронных сетей. По результатам работы написана статья.

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

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

Решардинг, Таблетки от головной боли.

Александр Календарев

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

Фреймворки
,
Миграции данных
,
API
,
PHP
,
Базы данных / другое
,
Проектирование информационных систем
,
Web-scale IT / другое
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

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

Антон Скогорев

Одним из первых и самых живучих алгоритмов работы сервиса Яндекс.Такси был «жадный» алгоритм назначения водителей. От пользователя приходил запрос, в рамках которого мы находили самого подходящего по ряду критериев водителя. Со временем мы стали осознавать, что нам нужно что-то знать не только о том, кто из водителей находится вокруг пользователя, но и о том, какие заказы есть рядом, чтобы назначать водителей более эффективно.

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

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

Как разработать сервис и не разбиться о монолит

Александр Данковцев

Пару лет назад мы в Авито решили распилить монолит на микросервисы и с энтузиазмом принялись за эту задачу, которую, как мы думали, легко затащим за год. На деле всё оказалось куда сложнее. Мы даже не представляли поначалу, что нам предстоит.

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

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

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

Anycast и Same Сost: как самостоятельно строить геораспределенные и отказоустойчивые приложения без load balancer

Рамиль Хантимиров

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

Тем временем, получить собственные PI (Provider-Independent) адреса, настроить анонсирование BGP Anycast и отказаться от балансировщиков нагрузки в пользу обычной внутренней маршрутизации - проще, чем принято думать. Да что там, многие даже не рассматривают такой вариант!

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

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

DropFaaS. Представляя функции как сервис

Анатолий Макаров

* Разработка serverless-вычислительных функций/приложений в распределенной и высокодоступной среде.
* Оптимизация и уплотнение вычислений на своих и/или облачных ресурсах.
* Пути сокращения расходов на ресурсы для "больших" вычислений.

Фреймворки
,
Бэкенд / другое
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Работа с Amazon
,
Архитектуры / другое
,
Технологии виртуализации и контейнеризации
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Согласованность данных в гео-распределенной системе на базе CRDT

Дмитрий Мартьянов

В поисках улучшения масштабируемости и доступности многие команды начинают рассматривать возможности использования AP спектра CAP теоремы. В то же время разработчики программного обеспечения сосредоточены на создании отказоустойчивых систем, готовых к работе в production под нагрузкой с минимальной сложностью, а Eventual Consistency несет в себе опасность потери данных при использовании не синхронизированных состояний. Дмитрий поделится уроками, извлеченными при разработке распределенной системы на основе Eventually Consistent хранилища данных. Разработанное решение использует Conflict-free Replicated Data Types с отслеживанием причинно-следственных связей для достижения надежной согласованности критических данных при развертывании БД в нескольких дата центрах с асинхронной репликацией (Aerospike).

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

Построение системы аналитики в условиях agile-разработки

Илья Середа

- Поговорим о том как начать развивать систему аналитики в компании не имея армию data-инженеров. Как перейти из состояния «я не понимаю какие квадратики на этой схеме нужны для моих задач» и при этом не уйти в R&D на несколько месяцев
- Как реализовать потоковую обработку данных на PHP (~40К записей в минуту)
- Какие технические решения применяли в нашем решении и какие факторы учитывали в принятии решений

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

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

Элегантное тестирование микросервисной экосистемы

Андрей Маркелов
Сергей Бобков

В этом докладе будет рассмотрен подход к системному тестированию платформы, состоящей из нескольких микросервисов. Мы рассмотрим почему другие типы тестирования не получили признания разработчиков.
Демонстрация будет проводиться на сильно упрощенном прототипе, разработанным на основе платформы компании Infobip. В предлагаемом подходе сервисы запускаются в Docker-контейнерах с помощью библиотеки TestContainers и фреймворка JUnit 5. Сервисы построены на Spring Boot 2 и используют Ribbon и Eureka из Spring Cloud для общения между собой. В качестве БД используются Postgres и Redis, для мокирования — MockServer.

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

Худеем вместе: отбрасываем лишнее железо с прода

Давыдов Иван Владимирович

- Убрать лишнее железо с прода – учимся правильно утилизировать ресурсы:
- Делимся опытом исследований влияния масштабирования экземпляров микросервисов на производительность;
- Закладываем основу под оркестрацию.

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

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

Cross DC services: problems and issues?

Андрей Маркелов
Сергей Бобков

В данном докладе мы расскажем про несколько подходов построения микросервисной архитектуры, в случае когда микросервисы расположены в нескольких дата центрам и они обмениваются данными с большой интенсивностью. Мы расскажем про паттерны и их реализацию:
- sidecar
- data provider
- client-side balancing

Фреймворки
,
Java
,
Бэкенд / другое
,
Базы данных / другое
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

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

Prometheus master-class

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

В ходе мастер-класса слушатель получит информацию об использовании инструментов Prometheus и Grafana для мониторинга сторонних приложений и попробует их реальных примерах. Будут рассмотрены возможности инструментов на примере экпортеров: Node exporter, Jira exporter и Bitbucket exporter. В ходе семинара слушатель узнает как работать с различными типами метрик, как настраивать службы обнаружения и выполнит задания на построение рабочего стола и настройки оповещений. Также будут рассмотрен инструмент push-gateway для задач, которые выполняется по расписанию ( cron ).
После семинара слушатель сможет уверенно пользоваться Grafana для анализа метрик Prometheus и настраивать собственные нотификации. Atlassian-администраторы смогут самостоятельно внедрить решения мониторинга в свою Atlassian эко-систему.

Java
,
Логирование и мониторинг
,
Devops / другое
,
Митапы
Программный комитет ещё не принял решения по этому докладу

Разработчики PVS-Studio сошли с ума? Зачем нужен еще один статический анализатор Java

Евгений Рыжков

Недавно команда PVS-Studio выпустила статический анализатор для Java. Абсурд? Во времена FindBugs, IntelliJ IDEA, SonarQube (SonarJava) выпускать новый продукт может только сумасшедший. Или они что-то знают? На что рассчитывает команда, как она планирует конкурировать с лидерами рынка и какие трудности были при разработке анализатора? Ну и, конечно, не обойдемся без примеров ошибок, найденных в известных opensource-проектах на Java!

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

С vendor lock-in к opensource как дорога к радости

Алексей Шарапов

Доклад раскроет тему перехода с vendor lock-in решения Weblogic на opensource Wildfly, что позволило удачно контейнеризировать, обеспечить zero downtime deploy, увеличить скорость поставки и уменьшить боль обновлений для одного из самых критически важных бизнес-приложений.

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

njs ‒ родной JavaSсript-скриптинг в nginx (модуль для создания переменных и обработчиков стадий запроса на JavaScript)

Дмитрий Волынцев

1) История появления проекта.
2) Зачем nginx скриптинг.
3) Зачем писать собственный интерпретатор с нуля.
4) Почему нас не устраивает lua/openresty.
5) Почему njs работает быстро.
6) Примеры задач которые можно решать при помощи njs в nginx.

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

Анализатор кода PVS-Studio (мастер-класс)

Сергей Хренов

Разработчики PVS-Studio расскажут, как можно эффективно использовать их инструмент. На практике будет показан процесс проверки С++\C#\Java-проектов и правка ошибок в них. Будут рассмотрены различные настройки анализатора, позволяющие свести к минимуму количество ложных срабатываний. Будет рассмотрен режим массового подавления предупреждений и как это позволяет быстро внедрить PVS-Studio в большой проект. Также кратко будет продемонстрирована возможность интеграции инструмента с различными CI и SonarQube.

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

Тестируем на проде: Canary Releases

Андрей Маркелов
Сергей Бобков

В настоящее время показатель успешности продуктов - это стабильность и время доставки новой функциональности конечным пользователям (time to market).
Рассмотрим пример: микросервисная архитектура, которая требует обновления как минимум раз в день. Притом производственное окружение невозможно повторить на тестовом окружении, и нет группы тестирования. Можно ли минимизировать ошибки разработки? Можно! И в докладе будет рассказано об успешном опыте использования метода «canary releases». Мы расскажем как и на каких технологиях мы это реализовали.

Микросервисы, SOA
,
Архитектурные паттерны
,
Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Обслуживание клиентов, техническая поддержка, обратная связь
Программный комитет ещё не принял решения по этому докладу

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

Обфускация баз данных

Алексей Миловидов

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

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

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

C/C++
,
Защита информации
,
Бэкенд / другое
,
Базы данных / другое
,
Алгоритмы и их сравнение
,
Администрирование баз данных
,
Нагрузочное тестирование
Доклад принят в программу конференции

Катастрофы больше не страшны: как мы сделали асинхронную транзакционную репликацию в GridGain

Иван Раков

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

Из доклада вы узнаете, как мы сделали всё это возможным в GridGain, а именно:

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

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

K8s CSI implementation for XtremIO: pairing enterprise storage performance and reliability with containerizied applications through CSI

Itzik Reich

Container Storage Interface – secure, flexible, easy. Connecting a storage device to a Kubernetes cluster has never been an easy endeavor. The driver code lived in K8s source, took quite some time to develop and to get thru upstream reviews and could potentially break the whole cluster. Kubernetes team developed an awesome way to avoid all the pitfalls and to speed up storage drivers by vendors. This presentation is a walk-through of a driver implementation for XtremIO enterprise storage array. It explains the benefits of enterprise storage for containerizied applications, how these benefits are exposed through CSI driver, driver architecture and usage scenarios.

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

Postgres Highload Checklist

Иван Панченко

* Почему СУБД часто становится узким местом проекта, и как этого избежать?
* Как снизить нагрузку на СУБД? Как распределить (расшардить) её?
* Структурированная экскурсия вокруг основных "грабель", разбросанных на поляне Highload специально для постгресистов. Надевайте каски и вперёд!

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

ZFS + PostgreSQL: как не разочароваться...

Виктор Ягофаров

Кому всё еще нужна файловая система ZFS для баз данных, если мы знаем, что она почти вдвое медленней Ext4 для OLTP-задач?

Кого-то этот доклад расстроит результатами бенчмарков, а кому-то даст понять как ZFS поможет оптимизировать производительность production путём ускорения экспериментов в dev-среде.

Придя в зал или посмотрев видео, вы увидите:
* Максимальный тюнинг ZFS, Ext4 для нужд Postgres;
* Убедительные бенчмарки на топовом железе с NVME;
* Открытую и подробную методику тестирования (с ссылками на скрипты и большим подробным guide);
* Неожиданные заключения.

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

Columnstore - "старый" новый движок для аналитики от MariaDB

Роман Ноздрин

MariaDB давно переросла своего родителя MySQL за счёт функционала, добавляемого в MDB. Одной из таких фич стал engine для аналитической нагрузки - Columnstore AKA MariaDB AX, который отлично укладывается в парадигму MariaDB: каждой нагрузке свой движок.

В рамках доклада я познакомлю аудиторию с архитектурой и возможностями Columnstore.

MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Как мы обрабатываем миллиард событий в сутки без ClickHouse

Александр Харитонов

С 2011 года игровая студия Pixonic разрабатывает свою аналитическую систему AppMetr. При ее создании использовались Apache Kafka, Apache Cassandra и свои велосипеды на Java.

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

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

Расскажем о проблемах, с которыми столкнулись на этом пути.

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

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

Типичные ошибки при разработке приложений, работащих с PostgreSQL

Иван Фролков

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

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

Архитектура системы хранения данных для реализации "закона Яровой" 374-ФЗ

Артем Шпынов

Рассказ про архитектуру системы хранения для реализации "Закона Яровой".

* Самый «хайповый» закон в сфере связи предыдущих 2 лет.
* Как мы реализовывали по-настоящему BIG data.
* Как сохранить весь интернет одного из операторов Большой тройки в городе участнике ЧМ-2018 на 1 месяц?
* Как мы "снимаем" трафик. Как обработать 320 Гигабит в секунду? Как передать его в СХД?
* 320 Гигабит/с и 1 месяц хранения это: 100 Петабайт, 10 миллионов новых потоков каждую секунду, 500 миллионов текущих потоков,
* Как строится СХД объемом в сотни Петабайт. Откуда начали и к чему в итоге пришли.
* Расскажу про стек используемых opensource-решений. Как мы использовали PostgreSQL, чем не устраивает elasticsearch.
* Опишу собственные разработки. В чем их преимущества и где недостатки.
* Расскажу про СОРМ на сетях передачи данных. Особенности требований предъявляемых к таким СХД, и где лежат компромиссы. Какие самые сложные проблемы приходится решать.

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

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

Академия джедаев: как вырастить команду экспертов на смену армии клонов

Нина Агеева

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

На бумажках и в диаграммах Гантта некоторые менеджеры оперируют абстрактными ролями “разработчик”, “тестировщик”, “аналитик”. Из таких ролей, конечно, можно создать армию исполнителей. Но команду? Команду, работающую как единый слаженный организм, в котором все открыто взаимодействуют и дополняют друг друга ? Сорян! Так не получится! Для того чтобы создать настоящую команду джедаев, вам придётся основательно поработать, и я хочу рассказать об опыте внедрения JediEdu.

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

Обо всём - по этапам, со скриншотами и конкретикой:
1. Выбор компетенций, необходимых для развития в команде, и их распределение между Джедаями.
2. Определение сильных и слабых сторон каждого Джедая, и пробуждение его Силы.
3. Табло для отслеживания прогресса Джедаев, и регулярные замеры уровня Джедайности в организме.
4. Использование взаимодополняющих компетенций как альтернатива копипасту универсальных сотрудников.
5. Инструменты оценки суммарной эффективности команды и замеры командной Силы как альтернатива единоличных результатов.
6. Регулярные презентации “своих” навыков и помощь Джедаям-коллегам в “своих” областях экспертизы.

Я расскажу и покажу, как 15 опытных и признанных экспертов решились на полгода снова стать Падаванами - для того, чтобы переродиться в Джедаев нового уровня, с новым уровнем требований к себе и многократно возросшей Силой. Правда, выжили не все 15… Но об этом - на выступлении!

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

Большие проекты/команды
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление / другое
,
QA / другое
Программный комитет ещё не принял решения по этому докладу

Управление удаленной децентрализованной командой

Леонид Кофман

Суть доклада рассказать о том, как не имея офиса управлять коллективом из 15 человек, разбросанных по всему СНГ и при этом расти на 10% ежемесячно. Расскажу о том как построена работа с программистами, с отделом технической поддержки, какие есть плюсы и минусы такого подхода к работе, какие инструменты мы используем и какие лайфхаки применяем.

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

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

Распределенная тренировка и инференс на TensorFlow с использованием Apache Ignite

Юрий Бабак

Что делать, когда появляется необходимость использования TensorFlow в распределенном окружении? Чтобы не изобретать велосипед, мы научили распределенную In-Memory базу данных работать с TensorFlow в качестве источника данных и Cluster Management System.

План доклада:
— Apache Ignite как источник данных для TensorFlow;
— Ignite Thin Client Dataset: работа с данными произвольной структуры;
— Apache Ignite как инфраструктура для распределенного обучения и инференса на TensorFlow;
— Демо.

Java
,
Python
,
Базы данных / другое
,
Распределенные системы
,
Machine Learning
,
ETL
Программный комитет ещё не принял решения по этому докладу

Технологии в историях мобильного банка Tinkoff.ru

Андрей Иванов

В декабре 2017 года Тинькофф Банк выпустил обновление мобильного приложения, в котором самым заметным изменением стало появление раздела "Истории". Каждый месяц редакторы в Tinkoff.ru выпускают около 200 новых историй, а одновременно за право быть показанными пользователю соревнуются более полутора тысяч единиц контента, месячная аудитория которого составляет более 3 млн. человек, по данным на начало ноября 2018 года. Большая часть историй узко таргетирована, и при этом, решение о показе той или иной истории клиенту принимается в режиме реального времени с учетом множества факторов: начиная от банковского профиля клиента и заканчивая местом, где клиент открывает приложение мобильного банка.

В докладе мы расскажем о том, что рекомендательная система раздела "Истории" основана, на ставшем уже классическим, протоколе OpenRTB и специально модифицированных платформах DMP, DSP, SSP. На принятие решения о показе той или иной истории с учетом аудиторных и технических таргетингов нам требуется не более 100 млс., мы используем быстрые фильтры и их интервальную модификацию. Статистика раздела "Истории" доступна менеджерам в режиме реального времени посредством реализации лямбды-архитектуры и, одновременно с этим, мы сделали ее доступной для внутренних чат-ботов.

Яркость и цвета, использованные на обложке истории влияют на ее популярность, а сохраненные в закладки клиентом истории позволяют нам точнее понимать его интересы. Для каждого региона, города и для каждого человека, облачная редакция регулярно готовит большое количество контента, анализируя инфоповоды, городские ленты, социальные сети и другие источники данных в полуавтоматическом режиме. Мы рассматриваем подходы к полной автоматизации задачи поиска инфоповодов, различные интеллектуальные агенты могут подсказывать редакции актуальные темы и характеризовать их целевые аудитории. Обратная связь о качестве контента - пользователи могут оценить материал, поставить лайк или дизлайк, позволяет обучать и измерять качество работы интеллектуальных систем. Истории в мобильном банке не только увеличивают частоту использования приложения и длину сессии — это также и канал для получения обратной связи и проведения маркетинговых исследований, все это в совокупности позволяет непрерывно улучшать качество сервисов в экосистеме Tinkoff.ru.

В 2018 году Тинькофф Банк признан лучшим розничным онлайн-банком в мире (Best Consumer Digital Bank) в рамках премии Best Digital Bank Award международного журнала о банках и финансах Global Finance, а мобильное приложение Тинькофф стало лучшим в мире среди всех розничных банков (Best Mobile Banking App). В октябре 2018 года состоялась презентация "Историй" на одной из главных мировых площадок финтех достижений Finovate Fall в Нью-Йорке.

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

Antispam ML: как и зачем автоматизировать обучение моделей

Дмитрий Меркушов

Внедрение и эксплуатация машинного обучения в антиспаме имеет свои особенности в сравнении с другими доменами. Это связано с непрекращающейся адаптацией спамеров под системы защиты, которая происходит днем, ночью, на выходных и когда вы в отпуске без Интернета. Постоянная гонка вооружений между силами добра и зла порождает много вызовов:
* Как добиться эффективности ML в течение продолжительного времени? А не только первые 30 минут (true story!)
* Как убедиться, что качественные метрики на выборках подтвердятся в проде?
* Как гарантировать, что ночью/на выходных/под Новый Год модель не сойдет с ума после очередного обучения?
* и многие другие...

Эти вопросы становятся все более актуальными и в других бизнесах: adversarial атаки уже характерны для систем face recognition, банковского скоринга, поиска, social медиа. И на горизонте - атаки с использованием машинного обучения. Одно из решений всех этих вызовов лежит в ускорении цикла дообучения всевозможных моделей на новые паттерны, а также в формировании быстрого и эффективного пайплайна их выкатки в продакшн. Все это требует как кастомизации обучения самих моделей, так и построения качественной ML-инфраструктуры.

Как мы прошли этот путь в Почте Mail.ru, я расскажу в рамках своего доклада.

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

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

Поддерживаем разработку нескольких версий продукта в Git

Станислав Лукьянов

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

Поддержка нескольких версий продукта - это сложно. Если пустить всё
на самотёк, то рано или поздно случится коллапс: будут появляться регрессии (фикс попадёт в 1.1, но потеряется в 1.2), выпуск версий будет замедляться из-за хаоса в release scope.

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

Расскажу:
— Как мы поняли, что нам нужен формализованный процесс по работе с версиями
— Почему git-flow — не панацея
— Почему мы запрещаем merge, не ставим tags и не делаем forward ports
— Как выглядит наш workflow сегодня, и как построить такой же у себя
— Почему наш workflow — тоже не панацея.

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

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

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

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

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