🖐 В 11:10 стартуют следующие доклады:
⠀
🏰 «00 Зал - Башня». Укрощаем хайлоад из тысячи разработчиков и разрабатываем управляемую систему деплоя. Павел Шерепо (VK, ВКонтакте)
Доклад о том, как построить релизный процесс в крупной компании. Пригодится всем, у кого высокая частота релизов или надо собирать большое количество MR (PR) кода в релизы. Еще всегда очень интересно посмотреть на опыт соседей — этот доклад дает такую возможность.
⠀
🔘 Зал «08 Шатер Голубой». Регламент для работы с ошибками в Go. Илья Сергунин
Обработка ошибок есть в любом приложении, но эта задача только кажется простой. Ошибка может быть строкой, структурой, интерфейсом, содержать стек, другую ошибку… Илья предложит регламент, позволяющий легко определить нужный подход в зависимости от типа приложения и требований к обработке ошибок.
⠀
🔹 «03 Зал Синий». YTsaurus и аналитические витрины с актуальностью в 15 минут. Филипп Козьмин (Яндекс Маркет)
Часто в ETL-процессах возникает потребность «считать часть данных не в batch-режиме, а в NRT». Из доклада мы узнаем, как эффективно реализовать такой процесс для big-data-инфраструктур на базе YTsaurus и при этом не наплодить параллельные вселенные для батча и стриминга.
⠀
🟣 «04 Зал Красный». Нейросети на китайских камерах: дешево и задорно. Максим Лапшин (erlyvideo)
Flussonic уже много лет строит решения видеоаналитики. С точки зрения программиста и продакта, Максим расскажет о своем опыте запуска нейросетей на камерах Rockchip. Это одни из первых доступных камер стандартного форм-фактора и доступной цены, пригодных для запуска нейросетей.
⠀
🟢 «06 Зал Зеленый». Опыт перевода банковского продукта в риалтайм. Владимир Ловцов, Владимир Аврамов (Холдинг Т1)
Доклад-исследование, доклад-детектив. Как на больших масштабах правильно принимать решения, правильно принимать технологии и справляться с рисками и интеграционными проблемами. Рекомендуется для тех, кто любит много технологий.
⠀
🔵 Зал «09 Шатер Фиолетовый». Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны. Роман Щербаков (Т-Банк)
Если вы строите систему доставки данных в распределенной среде, то вам будет полезно узнать, как не наступить на множество граблей. Этот доклад — хорошая возможность взглянуть на свою систему через призму применения любимых паттернов.
🔸 Зал «07 Шатер Оранжевый». Про UUID v.7. Андрей Бородин (Yandex Cloud)
Андрей делает Яндекс.Облако, хорошо разбирается в базах и пишет код, чтобы они работали лучше. В своем докладе он расскажет о патче, который добавляет поддержку UUID в качестве primary key для PostgreSQL. И о том, почему так важно реализовать RFC 7 и 8, а не просто «как-то сгенерировать 16 байт».
⠀
🏰 «00 Зал - Башня». Укрощаем хайлоад из тысячи разработчиков и разрабатываем управляемую систему деплоя. Павел Шерепо (VK, ВКонтакте)
Доклад о том, как построить релизный процесс в крупной компании. Пригодится всем, у кого высокая частота релизов или надо собирать большое количество MR (PR) кода в релизы. Еще всегда очень интересно посмотреть на опыт соседей — этот доклад дает такую возможность.
⠀
🔘 Зал «08 Шатер Голубой». Регламент для работы с ошибками в Go. Илья Сергунин
Обработка ошибок есть в любом приложении, но эта задача только кажется простой. Ошибка может быть строкой, структурой, интерфейсом, содержать стек, другую ошибку… Илья предложит регламент, позволяющий легко определить нужный подход в зависимости от типа приложения и требований к обработке ошибок.
⠀
🔹 «03 Зал Синий». YTsaurus и аналитические витрины с актуальностью в 15 минут. Филипп Козьмин (Яндекс Маркет)
Часто в ETL-процессах возникает потребность «считать часть данных не в batch-режиме, а в NRT». Из доклада мы узнаем, как эффективно реализовать такой процесс для big-data-инфраструктур на базе YTsaurus и при этом не наплодить параллельные вселенные для батча и стриминга.
⠀
🟣 «04 Зал Красный». Нейросети на китайских камерах: дешево и задорно. Максим Лапшин (erlyvideo)
Flussonic уже много лет строит решения видеоаналитики. С точки зрения программиста и продакта, Максим расскажет о своем опыте запуска нейросетей на камерах Rockchip. Это одни из первых доступных камер стандартного форм-фактора и доступной цены, пригодных для запуска нейросетей.
⠀
🟢 «06 Зал Зеленый». Опыт перевода банковского продукта в риалтайм. Владимир Ловцов, Владимир Аврамов (Холдинг Т1)
Доклад-исследование, доклад-детектив. Как на больших масштабах правильно принимать решения, правильно принимать технологии и справляться с рисками и интеграционными проблемами. Рекомендуется для тех, кто любит много технологий.
⠀
🔵 Зал «09 Шатер Фиолетовый». Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны. Роман Щербаков (Т-Банк)
Если вы строите систему доставки данных в распределенной среде, то вам будет полезно узнать, как не наступить на множество граблей. Этот доклад — хорошая возможность взглянуть на свою систему через призму применения любимых паттернов.
🔸 Зал «07 Шатер Оранжевый». Про UUID v.7. Андрей Бородин (Yandex Cloud)
Андрей делает Яндекс.Облако, хорошо разбирается в базах и пишет код, чтобы они работали лучше. В своем докладе он расскажет о патче, который добавляет поддержку UUID в качестве primary key для PostgreSQL. И о том, почему так важно реализовать RFC 7 и 8, а не просто «как-то сгенерировать 16 байт».
Друзья, сегодня в 12:30 ждём вас в Шатре Оранжевый на PostgreSQL Pre-Commitfest Party!
✔️ Обсудим патчи в Postgres — опытом работы поделятся эксперты компании, в том числе Major Contributors Олег Бартунов и Федор Сигаев;
✔️ Покажем решения на базе Postgres Pro: интегрированную в ядро технологию BiHA (Built-in High Availibility) для встроенной отказоустойчивости СУБД и новую распределённую реляционную СУБД Shardman для крупнейших инсталляций в десятки и сотни ТБ.
Вы не просто увидите, а опробуете технологии в деле! На стенде можно отключить шард СУБД Shardman или узел кластера Postgres Pro Enterprise BiHA и посмотреть, как системы справляются с перераспределением нагрузки.
✔️ Разыграем мерч: подходите к шатру (схема прохода — на карте конференции), сканируйте QR-код, правильно отвечайте на вопросы в боте и выигрывайте призы!
✔️ Обсудим патчи в Postgres — опытом работы поделятся эксперты компании, в том числе Major Contributors Олег Бартунов и Федор Сигаев;
✔️ Покажем решения на базе Postgres Pro: интегрированную в ядро технологию BiHA (Built-in High Availibility) для встроенной отказоустойчивости СУБД и новую распределённую реляционную СУБД Shardman для крупнейших инсталляций в десятки и сотни ТБ.
Вы не просто увидите, а опробуете технологии в деле! На стенде можно отключить шард СУБД Shardman или узел кластера Postgres Pro Enterprise BiHA и посмотреть, как системы справляются с перераспределением нагрузки.
✔️ Разыграем мерч: подходите к шатру (схема прохода — на карте конференции), сканируйте QR-код, правильно отвечайте на вопросы в боте и выигрывайте призы!
😁1
🖐 Друзья, следующие доклады ждут вас в 12:30
⠀
🏰 «00 Зал - Башня». Redis — такой простой и такой сложный! Андрей Комягин (STM Labs)
Redis уже давно не является чем-то новым. Каждый использует его немного по-своему и практически каждый думает, что это всё элементарно. Этот доклад покажет, что возможностей и нюансов очень много и, даже если сейчас вам это не понадобится, когда-то пригодится точно.
⠀
🔘 Зал «08 Шатер Голубой». Меньше кода, больше результата: применяем SQLC для работы с БД. Евгений Конечный (Uzum Tezkor)
Кодогенерация — как много скрыто в этом слове для разработчика. В своем докладе Евгений покажет, как, используя этот инструмент, можно облегчить боль при работе с БД. Возвращаясь к основам — к написанию SQL-запросов — можно получить производительный, корректный и типобезопасный код на Go.
⠀
🔹 «03 Зал Синий». Масштабирование системы хранения секретов на базе HashiCorp Vault. Виктор Корейша (Ozon)
Чтобы отдавать сотни тысяч секретов и укладываться в SLA, ребятам из Ozon пришлось хорошенько поработать с Hashicorp Vault. Бэкендом выбрали etcd, словили проблемы из-за бага, поправили и законтрибьютили. Научили vault работать в режиме мультимастер — решили проблемы с кэшами и отмасштабировались.
⠀
🟣 «04 Зал Красный». Эффективная ML-обработка видео в web-браузере для видеоконференций SberJazz. Дмитрий Балиев (SberDevices)
Работа в браузере — одна из самых сложных задач для нейросетей, работающих с медиаконтентом, особенно для сервиса видеоконференций, которому нужно справляться в real-time. Будет интересно узнать о движке инференса нейронок в SberJazz тем, кто занимается инференсом нейросетей и edge computing.
⠀
🟢 «06 Зал Зеленый». Атаки на AI-чат-боты и методы защиты. Евгений Кокуйкин (Raft)
Чем больше LLM проникает в нашу жизнь, тем острее встают вопросы безопасности. Вариативность атак меняется не просто быстро, а очень быстро. Из доклада вы получите полное представление о текущем состоянии атак на LLM и научитесь идентифицировать потенциальные уязвимости в своих приложениях.
⠀
🔵 Зал «09 Шатер Фиолетовый». Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source? Николай Никитин (ИТМО)
Open Source — один из мощных драйверов развития ИИ. Но как правильно выстроить процесс с Open Source и данными, каковы технологические и технические особенности, работа с сообществом? Об этом и многом другом в этом докладе.
🔸 Зал «07 Шатер Оранжевый». Postgres Pre-Commitfest Party
⠀
🏰 «00 Зал - Башня». Redis — такой простой и такой сложный! Андрей Комягин (STM Labs)
Redis уже давно не является чем-то новым. Каждый использует его немного по-своему и практически каждый думает, что это всё элементарно. Этот доклад покажет, что возможностей и нюансов очень много и, даже если сейчас вам это не понадобится, когда-то пригодится точно.
⠀
🔘 Зал «08 Шатер Голубой». Меньше кода, больше результата: применяем SQLC для работы с БД. Евгений Конечный (Uzum Tezkor)
Кодогенерация — как много скрыто в этом слове для разработчика. В своем докладе Евгений покажет, как, используя этот инструмент, можно облегчить боль при работе с БД. Возвращаясь к основам — к написанию SQL-запросов — можно получить производительный, корректный и типобезопасный код на Go.
⠀
🔹 «03 Зал Синий». Масштабирование системы хранения секретов на базе HashiCorp Vault. Виктор Корейша (Ozon)
Чтобы отдавать сотни тысяч секретов и укладываться в SLA, ребятам из Ozon пришлось хорошенько поработать с Hashicorp Vault. Бэкендом выбрали etcd, словили проблемы из-за бага, поправили и законтрибьютили. Научили vault работать в режиме мультимастер — решили проблемы с кэшами и отмасштабировались.
⠀
🟣 «04 Зал Красный». Эффективная ML-обработка видео в web-браузере для видеоконференций SberJazz. Дмитрий Балиев (SberDevices)
Работа в браузере — одна из самых сложных задач для нейросетей, работающих с медиаконтентом, особенно для сервиса видеоконференций, которому нужно справляться в real-time. Будет интересно узнать о движке инференса нейронок в SberJazz тем, кто занимается инференсом нейросетей и edge computing.
⠀
🟢 «06 Зал Зеленый». Атаки на AI-чат-боты и методы защиты. Евгений Кокуйкин (Raft)
Чем больше LLM проникает в нашу жизнь, тем острее встают вопросы безопасности. Вариативность атак меняется не просто быстро, а очень быстро. Из доклада вы получите полное представление о текущем состоянии атак на LLM и научитесь идентифицировать потенциальные уязвимости в своих приложениях.
⠀
🔵 Зал «09 Шатер Фиолетовый». Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source? Николай Никитин (ИТМО)
Open Source — один из мощных драйверов развития ИИ. Но как правильно выстроить процесс с Open Source и данными, каковы технологические и технические особенности, работа с сообществом? Об этом и многом другом в этом докладе.
🔸 Зал «07 Шатер Оранжевый». Postgres Pre-Commitfest Party
HighLoad++
Video message
Счастливый обладатель приза за самый интересный вопрос спикеру. Уникальная матрешка Saint HighLoad++ 🔥
Forwarded from Максим Цепков (Maxim Tsepkov)
#Highload Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога. По этому докладу у меня возникла ассоциация с историей. Когда-то давно были базы данных без SQL, только работа с таблицами, и все join надо было вручную писать в коде. Z это еще застал. Потом пришел SQL и проблема была решена. Сейчас это повторяется: микросервисная аргиюетура разложила объекты о сервисами, для каждого есть свой набор API. GrapgQL позволяет объединять данные из разных узлов в единую схему и делать общие запросы. При этом тогда разработчики относились к появившемуся SQL настороженно: это же накладные расходы, сложно и непривычно. Так и сейчас к GraphQL относятся настороженно как к хипстерской поделке, которая не нужна "настоящим программистам" - OpenAPI достаточно. Докладчик показывал, как GraphQL решает проблемы, сокращает объем кода, делает его более компактным. А также - как решаются проблемы контроля доступа, единой точки отказа и безопасности. Решение GraphQL - легкое и масштабируемое, федерации - stateless, и можно поднимать разные федерации для разных клиентов, подключая только необходимые им сервисные данные. И страивать параллельный доступ для миграции, поднимая федерацию для доступа, но запуская через нее только новые запросы. Тут ситуация выгодно отличается от того, что было с миграцией на SQL-базы данных - там это можно было сделать только целиком. На мой взгляд, получился очень удачный доклад.
🖐 Программа докладов, которые стартуют в 13:50
⠀
🏰 «00 Зал - Башня». Геораспределенные системы. Евгений Кузовлев (Т-Банк)
Самое сложное в больших проектах — сделать нормально работающий геораспределенный сторадж. В докладе автор поделится своим практическим опытом построения геораспределененных систем, а также расскажет всю необходимую теорию (CAP/PACELC) для тех, кто ещё не сталкивался с распределенными системами.
⠀
🔘 Зал «08 Шатер Голубой». Как ускорить программу, не переписав ни строчки: PGO для Go-разработчиков. Кирилл Кузин (Vi.Tech)
Написание быстрого кода — это одна из самых сложных задач при создании высоконагруженного приложения. Кирилл покажет другой путь: используя автоматический анализ работы вашего приложения, Go может сам принять лучшие решения об оптимизации кода. И расскажет, как именно компилятор это делает.
⠀
🔹 «03 Зал Синий». Ищем кратчайший путь в Интернете. Алексей Учакин (EdgeЦентр)
На докладе Алексея попробуем разобраться: из чего складывается задержка и почему это важно; что влияет на путь трафика от клиента до приложения и обратно; при чём тут облака, DDoS-защита и CDN; что можно сделать, чтобы задержка стала меньше.
⠀
🟣 «04 Зал Красный». Мир будущего: управление устройствами с помощью жестов. Александр Нагаев (SberDevices)
Доклад Александра интересен тем, что обращается к корням. Из него вы узнаете, как в современнейшей задаче распознавания динамических жестов можно применить нейросеть, разработанную ещё в XX веке!
⠀
🟢 «06 Зал Зеленый». Как работать с поставщиками на примере поиска доступных отелей. Иван Чернов (Островок!)
Доклад о методах построения архитектуры поиска не только в отельной индустрии, но и в других сферах, где сервис тесно взаимодействует с внешними сервисами. От кэширования до сложных алгоритмов балансировки запросов. Ценное знание для разработчиков, работающих с высокими нагрузками и ограничениями.
⠀
🔵 Зал «09 Шатер Фиолетовый». Как с помощью AI в тысячах видео найти нужный кадр. Александр Соколов (ГПМ Дата)
Доклад затрагивает сложную тему комплексного анализа видео и последующего извлечения нужных сущностей. Для решения задачи в короткий срок используется множество нейронных сетей. Как их подружить, прогнать сотни тысяч видео и научиться извлекать полезное — узнаем из доклада Александра!
🔸 Зал «07 Шатер Оранжевый». ClickHouse не тормозит в Self-Service BI: как мы достигли этого в Visiology. Никита Ильин (Visiology)
Хайлоад — это не всегда миллионы запросов. Порой аналитик и один запрос может написать такой, что его обработка сожрёт все ресурсы. А если систему нужно сделать такой, чтобы эти запросы могли писать даже непрофессиональные аналитики, а обычные сотрудники? Об этом — в докладе Никиты.
⠀
🏰 «00 Зал - Башня». Геораспределенные системы. Евгений Кузовлев (Т-Банк)
Самое сложное в больших проектах — сделать нормально работающий геораспределенный сторадж. В докладе автор поделится своим практическим опытом построения геораспределененных систем, а также расскажет всю необходимую теорию (CAP/PACELC) для тех, кто ещё не сталкивался с распределенными системами.
⠀
🔘 Зал «08 Шатер Голубой». Как ускорить программу, не переписав ни строчки: PGO для Go-разработчиков. Кирилл Кузин (Vi.Tech)
Написание быстрого кода — это одна из самых сложных задач при создании высоконагруженного приложения. Кирилл покажет другой путь: используя автоматический анализ работы вашего приложения, Go может сам принять лучшие решения об оптимизации кода. И расскажет, как именно компилятор это делает.
⠀
🔹 «03 Зал Синий». Ищем кратчайший путь в Интернете. Алексей Учакин (EdgeЦентр)
На докладе Алексея попробуем разобраться: из чего складывается задержка и почему это важно; что влияет на путь трафика от клиента до приложения и обратно; при чём тут облака, DDoS-защита и CDN; что можно сделать, чтобы задержка стала меньше.
⠀
🟣 «04 Зал Красный». Мир будущего: управление устройствами с помощью жестов. Александр Нагаев (SberDevices)
Доклад Александра интересен тем, что обращается к корням. Из него вы узнаете, как в современнейшей задаче распознавания динамических жестов можно применить нейросеть, разработанную ещё в XX веке!
⠀
🟢 «06 Зал Зеленый». Как работать с поставщиками на примере поиска доступных отелей. Иван Чернов (Островок!)
Доклад о методах построения архитектуры поиска не только в отельной индустрии, но и в других сферах, где сервис тесно взаимодействует с внешними сервисами. От кэширования до сложных алгоритмов балансировки запросов. Ценное знание для разработчиков, работающих с высокими нагрузками и ограничениями.
⠀
🔵 Зал «09 Шатер Фиолетовый». Как с помощью AI в тысячах видео найти нужный кадр. Александр Соколов (ГПМ Дата)
Доклад затрагивает сложную тему комплексного анализа видео и последующего извлечения нужных сущностей. Для решения задачи в короткий срок используется множество нейронных сетей. Как их подружить, прогнать сотни тысяч видео и научиться извлекать полезное — узнаем из доклада Александра!
🔸 Зал «07 Шатер Оранжевый». ClickHouse не тормозит в Self-Service BI: как мы достигли этого в Visiology. Никита Ильин (Visiology)
Хайлоад — это не всегда миллионы запросов. Порой аналитик и один запрос может написать такой, что его обработка сожрёт все ресурсы. А если систему нужно сделать такой, чтобы эти запросы могли писать даже непрофессиональные аналитики, а обычные сотрудники? Об этом — в докладе Никиты.
Forwarded from Максим Цепков (Maxim Tsepkov)
#Highload Роман Щербаков из Тинькофф. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны. Рассказ об организации высокой доступности для инфраструктурных потоков: логов, метрик, трейсов. 450 Мб/сек. Целевые хранилища там разные, а архитектура - общая. В докладе - много архитектурных схем, это надо смотреть презентацию. А тут мое краткое резюме принципов.
* Данные пишутся в том же дата-центре, в котором создаются, то есть в каждом - свой набор pipeline, и там же они остывают. А поиск - по всем датацентрам.
* Надо вести мониторинг обращений клиентов и уметь отделять тех, у кого особая нагрузка в отдельный pipeline, с которым отдельно разбираться.
* Worker записи от клиента пишет в Kafka, из которой читает Worker записи в хранилище. И worker записи работает в том темпе, в котором комфортно для БД. Kafka буферизует колебания нагрузки записи. А worker записи делает пакетную запись.
* Отказ операции - нормально. Особые случаи откидываем в отдельную retry-очередь, а если retry не проходит - в очередь ошибок, с которой разбираются вручную. Retry однократный, он на случай, если что-то моргнуло, а если что-то упало - то retry вреден. И такая схема обеспечивает оперативное поступление данных, с которыми все хорошо.
* Если база или узел деградировал - его надо отрубить, для этого фиксировать, что пошли массовые ошибки, для этого Circuit breaking pattern. Аналогично работает bulkhead pattern - ограничение на конкурентные обращения. Это бережет БД.
* Таймауты надо настраивать. Есть бюджет обработки от кафки - таймаут опроса очереди, при превышении которого она считает, что consumer отвалился, и в него надо укладываться, включая все таймауты. И для основного потока там жесткие настройки, а для retry и ошибок - свои.
* Для метрик основной поток пущен напрямую, без kafka, так как на стороне клиента обычно prometheus и у него есть свои буфера. И это экономит. Но при деградации - включается полная схема.
* Данные пишутся в том же дата-центре, в котором создаются, то есть в каждом - свой набор pipeline, и там же они остывают. А поиск - по всем датацентрам.
* Надо вести мониторинг обращений клиентов и уметь отделять тех, у кого особая нагрузка в отдельный pipeline, с которым отдельно разбираться.
* Worker записи от клиента пишет в Kafka, из которой читает Worker записи в хранилище. И worker записи работает в том темпе, в котором комфортно для БД. Kafka буферизует колебания нагрузки записи. А worker записи делает пакетную запись.
* Отказ операции - нормально. Особые случаи откидываем в отдельную retry-очередь, а если retry не проходит - в очередь ошибок, с которой разбираются вручную. Retry однократный, он на случай, если что-то моргнуло, а если что-то упало - то retry вреден. И такая схема обеспечивает оперативное поступление данных, с которыми все хорошо.
* Если база или узел деградировал - его надо отрубить, для этого фиксировать, что пошли массовые ошибки, для этого Circuit breaking pattern. Аналогично работает bulkhead pattern - ограничение на конкурентные обращения. Это бережет БД.
* Таймауты надо настраивать. Есть бюджет обработки от кафки - таймаут опроса очереди, при превышении которого она считает, что consumer отвалился, и в него надо укладываться, включая все таймауты. И для основного потока там жесткие настройки, а для retry и ошибок - свои.
* Для метрик основной поток пущен напрямую, без kafka, так как на стороне клиента обычно prometheus и у него есть свои буфера. И это экономит. Но при деградации - включается полная схема.
👍2❤1