Доклады

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

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

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

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

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

Начнем с основных концепций, но копнем глубже, выйдя за рамки общеизвестной информации. Так что же внутри черного ящика? Мы погрузимся в детали архитектуры системы хранения данных Kafka, рассмотрим принципы работы Sequential IO vs Random IO, а также изучим подход Zero Copy и оценим его влияние на производительность работы брокера. Рассмотрим файловую структура хранилища.

Далее оценим влияние выбранного типа сериализации на производительность – посмотрим бенчмарки “json vs protobuf” на примере data payload с реальных проектов. В рамках этой части доклада пристально посмотрим и на влияние компрессии (gzip vs snappy).

А что, если хочется еще быстрее? Поднимем тему тонкой настройки Kafka для максимальной оптимизации производительности. Поговорим про тюнинг пакетной обработки и настройку batching, linger.ms. Посмотрим на бенчмарки и оценим влияние этих параметров конфигурации на реальных примерах с ПРОДа.

Не обойдем стороной тему семантик и гарантий доставки данных – at least once, at most once и exactly once. Тут отдельно остановимся на сценариях их применения в реальных системах.

В самом конце, проведем обзор архитектуры большой высоконагруженной информационной системы на примере топологии гео-кластера, построенного на базе Apache Kafka. Разберемся в отличиях stretched vs connected clusters и рассмотрим инструментарий репликации, включая Mirror Maker 2.

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

Брокеры сообщений широко применяются во всем IT, в частности RabbitMQ, однако это далеко не магическая коробка и написать свой код так, чтобы не потерять свои сообщения - крайне нетривиальная задача. RabbitMQ это сложный инструмент, а любой сложный инструмент требует точной настройки. Мы окунемся глубже в архитектуру RabbitMQ, посмотрим в где мы с легкостью можем ошибиться и потерять сообщения, и как себя от этого застраховать. Глянем на 8 практических кейсов работы с RMQ, в которых опишем нюансы работы, хорошие практики и неочевидные сюрпризы, с которыми вы можете столкнуться.

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

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

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

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

Естественным этапом развития систем серверной виртуализации является виртуализация сети — возможность создавать виртуальные сетевые инфраструктуры «под задачу», не будучи стесненным рамками реальной сетевой инфраструктуры предприятия. Подобный этап развития настал и у проекта zVirt.

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

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

Название доклада - не шутка. В действующей сети Ethereum действительно уже больше миллиона активных валидаторов, каждый из которых периодически становится лидером в сетевом консенсусе. И хотя число реальных мастер-серверов сети оценивается в десятки тысяч, сетевой консенсус Ethereum 2.0 на данный момент является самым децентрализованным консенсусом в мире, безопасность которого обеспечивается примерно 100млрд$ замороженных активов и который работает без серьезных сбоев уже несколько лет. Если перекладывать на язык баз данных, то мы имеем БД с мастер-мастер реплицкацией между огромным числом реплик, устойчивую не только к сбоям, но и к сговору большого числа валидаторов. Доклад рассказывает про эту механику репликации, основные алгоритмы, организацию такой сети и ее параметры. Доклад будет интересен всем, кто интересуется отказоустойчивыми распределенными системами и кого задолбали рассказы про майнинг.

1) Архитектура ранжирования с помощью моделей и факторов (фичей).
2) Инференс моделей ранжирования в поиске Ozon.
3) Попадание новых моделей ранжирования в прод.
4) Вычисление графа зависимостей между моделями и фичами (входами для моделей).
5) Автоматические проверки перфоманса и качества перед доставкой моделей в продакшн.
6) Пайплайн добавления новых факторов ранжирования в прод.
7) Доклад рассказывает про новую версию feature store https://highload.ru/spb/2023/abstracts/10173. Я затрону минусы прошлого решения и расскажу, во что feature store превратился.

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

1. Intro. О проекте с большим количеством внешних систем для сбора данных.
2. Решаем, как будем собирать данные и как их обрабатывать.
3. Систематизация и хранение данных: готовые импортозамещенные инструменты.
4. Расскажу и покажу, почему не стоит париться из-за безопасности.
5. Почему бизнесу важно следить за проектом в реальном времени и принимать решения.

Реальный кейс о том, как я собрал такую систему, и в итоге все были счастливы — бизнес, разработчики и я =)

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

В 2024 году Ozon полностью перенес свою инфраструктуру объектного хранилища на собственное решение S3-server Lusca. В докладе я раскажу, как мы выбирали хранилища индекса; думали, как реализовать strong consistency на eventual consistency базе; открывали для себя особенности фоновых процессов ScyllaDB и придумывали свои алгоритмы; А еще о том, как боролись с восстанием зомби на Хеллоуин и воскрешали терабайты случайно удаленных данных.

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

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

Что слушатель вынесет с доклада?
- Рабочий подход к реализации гео резервирования PostgreSQL. Он успешно работает в продакшене для клиентского MDM у одного из крупнейших заказчиков.
- Пошаговое руководство по настройке Debezium, написанию sink-коннектора и адаптации Java-приложения для работы с несколькими базами.

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

Лидеры рынка СУБД в сегменте крупных предприятий — Oracle, MS SQL, PostgreSQL, несмотря на то, что архитектура этих платформ складывалась больше трёх десятилетий назад. В докладе разберём узкие места этой архитектуры и приёмы, применяемые в современных платформах, которые позволяют значительно увеличить производительность базы данных. А в конце посмотрим, почему же никто так и не подвинул PostgreSQL с пьедестала.

Уже дважды на хайлоаде я рассказывал про наш опыт развёртывания и управления распределённым S3 совместимы хранилищем на базе MinIO. Приятно, что доклады находят своих слушателей и вопросы мне в телеграм продолжают приходить до сих пор. некоторый просят продолжения. Поэтому я решил сделать ещё один доклад на эту тему, тем более что наш опыт растёт вместе с объёмом места, которое занимает информация в нашем хранилище. Сейчас оно размещается в 4 ДЦ, включает в себя 12 нод и 300 дисков.

Итак, коротко о том, о чём я хочу рассказать в этом году

1. Расширение хранилища.
Рано или поздно место заканчивается и приходит время добавлять новые ноды и диски. В прошлый раз я рассказывал, как мы расширялись с 3 до 4 дата-центров, по сути, скопировав все данные, что съело много времени. В этот раз я расскажу, как мы добавляем новые ноды, дисковые полки и диски в них соответственно. С одной стороны казалось бы, тривиальная процедура, с другой она представляет из себя куда более сложный процесс, чем увеличение просто раздела на локальном диске.

2. Эффективность сжатия.
Я уже рассказывал, что MinIO поддерживает сжатие. Но насколько оно эффективно и как быстро работает? Красивые цифры и графики.

3. Быстродействие.
Расскажу, как клиентам удалось под 100% удалось загрузить нам канал в одном из ДЦ, переливая данные с серверов в S3. При том, что для хранения мы используем обычные SAS диски.

4. Стоимость.
Мы используем не просто SAS диски. Мы используем б/у SAS диски небольшого объёма, но в большом количестве. Расскажу, как мы к этому пришли.

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

Мы в Mpstats занимаемся аналитикой товаров на маркетплейсах, собираем очень много данных. Например, на WildBerries размещено 110 млн товаров, для каждого товара мы зайдем в его карточку, запишем данные (как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель). Сохраним это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров — каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed-данных в ClickHouse.

В процессе развития сервиса мы упирались в несколько проблем — ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть — мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду.

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

1. SaluteEye - платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Сегодня мы собираем более 5 млрд событий в день, но так было не всегда...
2. С чего всё начиналось. Как мы использовали для аналитики Amplitude и с какими ограничениями сталкивались. Почему импортозамещение было неизбежно.
3. «Верните мне мой 2022» - санкции, экстренное внедрение нового решения и взрывной рост с 10 млн до 10 млрд событий в месяц за два месяца. Первые проблемы и выводы - формирование задела на масштабируемость системы.
4. Как мы собирали шишки и начали их считать - эволюция платформы и повсеместное внедрение мониторинга. Неожиданные проблемы стандартных инструментов и взгляд со стороны продукта - как сохранить лояльность пользователей в условиях частых перебоев.
5. Внедрение ClickHouse и появление realtime аналитики. Нетипичные кейсы применения - технический мониторинг продуктов и работа с логами на ClickHouse + Grafana вместо привычного Elastic Stack. Забиваем гвозди отверткой или эффективно используем уже имеющиеся ресурсы?
6. Что мы имеем сегодня

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

Тема с Supply Chain уже который год не на слуху, закономерно развиваются и меры предотвращения таких атак. Одним из популярных фреймворков является SLSA, однако он достаточно абстрактен и не учитывает некоторые виды атак.

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

Фаззинг API веб-приложений позволяет выявлять уязвимости, которые могут оставаться незамеченными при проведении статического анализа кода (SAST) или ручного анализа. В докладе будет рассмотрен наглядный пример.
Главная проблема фаззинга - это сбор данных. Для того чтобы выявить уязвимость, нужно собрать как можно больше входных точек, параметров запросов и самое главное поддерживать согласованность типов значений для этих параметров. В докладе рассмотрим различные источники, откуда можно добыть данные:
1) Openapi спецификации
2) Postman коллекции
3) Proxy (BurpSuite, OWASP ZAP, mitmproxy)
4) Логи
5) Данные команд нагрузочного тестирования (ammo для yandex-tank)
В качестве движка сканирования рассмотрим open source инструмент от команды Project Discovery - nuclei, который поддерживает фаззинг и имеет community фаззинг шаблоны. Рассмотрим как конвертировать данные из упомянутых выше источников в формат, подходящий для nuclei, и запустить фаззинг.

Спустимся в самые недра высокопроизводительной open-source библиотеки линейной алгебры Eigen:
* узнаем, как влияют особенности архитектуры библиотеки на ее производительность;
* посмотрим, как в ней реализована поддержка таких архитектурных расширений, как AVX, NEON, SVE;
* добавим оптимизации под векторное расширение RISC-V RVV c учетом возможности группировки векторных регистров.

Если вы
* задаетесь вопросом, зачем программисты продолжают оптимизировать руками в век стремительно умнеющих компиляторов, то вам сюда;
* находитесь в противоборствующем лагере и не отдаете производительность целиком на откуп компилятору, то вам тоже сюда;
* никогда не задумывались о каких-то оптимизациях и из-за чего весь сыр-бор, то тоже приходите!
На примере двух наиболее широко используемых высокопроизводительных open-source библиотек линейной алгебры Eigen и OpenBLAS увидим на графиках производительности, что дает векторизация на RISC-V и всегда ли автовекторизация может с ней сравниться, далеко ли до roofline и где в линейной алгебре прячутся compute-bound и memory-bound алгоритмы.
Даже если вы не знаете, кто такая линейная алгебра, больно не будет.

В 2019 году мы начали предлагать в аренду клиентам выделенные серверы на базе десктопных процессоров Intel Core i9-9900K. И через некоторое время столкнулись с тем, что процессоры сильно перегреваются в 1U корпусе и серверы выходят из строя. Стандартное воздушное охлаждение не справлялось. Увеличивать размеры корпусов мы не хотели — теряли в плотности размещения серверов в стойке, а, как следствие, деньги. Это заставило нас искать нестандартные решения в направлении жидкостного охлаждения.

Путь оказался тернистым. Первые решения от поставщиков с кастомной СЖО, казалось, решили проблему, но на самом деле только отсрочили ее. Через пару лет серверы стали массово выходить из строя. Это привело к длительным простоям оборудования и необходимости замены клиентских серверов. Самостоятельные попытки решить вопрос также не приводили к успеху. Все это подтолкнуло нас к более глубокому изучению вопроса: разобрали по “косточкам” всю систему охлаждения, проанализировали конструктивные особенности, технические ошибки, изучили опыт геймеров и кастомеров, и в итоге создали собственную систему — надёжную в использовании и простую в обслуживании.

В докладе расскажем:
Зачем мы начали ставить десктопные процессоры в клиентские серверы, в то время, как конкуренты нас осуждали
Как решали проблемы с СЖО, чем нам помогли и помешали поставщики
На какие «грабли» наступили и что нужно было делать по-другому
Happy end или очередной этап развития: как дело обстоит сейчас и что мы планируем делать дальше

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

В своем докладе я расскажу про:

- Первую версию архитектуры, державшую нагрузку в тысячи раз меньше текущей;
- Сложности, с которыми мы столкнулись. В частности - как положили kafka для части сервисов;
- Развитие архитектуры, вплоть до текущей версии, выдерживающий 1 500 000 RPS;
- Как мы ежедневно записываем 20 терабайт трафика;
- Зачем мы это делаем.

– Информационная безопасность и конфиденциальность данных: похожие понятия, но разные акценты;

– Защита данных во время использования: централизованный и децентрализованные подходы;

– Разные судьбы яиц, сложенных в одну корзину, или основные проблемы централизации;

– Децентрализация: как делать математику с числами, не глядя на сами числа, или Multi-Party Computation (MPC, совместные конфиденциальные вычисления);

– Пример применения MPC: как Bloomtech сделал первую в РФ (а, может, и в мире) межбанковскую платформу конфиденциальных вычислений, которая работает на проде;

– Цена конфиденциальности: проблемы технологии совместных конфиденциальных вычислений вчера и сегодня;

– Перспективы технологии: MPC как неотъемлемая часть цифровой инфраструктуры и стандарт для информационных коллабораций;

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

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

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

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

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

- Мир шоссейно-кольцевых гонок
- Суть дисциплины
- Суть мотоспорта: сочетание технической подготовки мотоцикла и скилла пилота
- Техническая часть. Чем гоночный мотоцикл отличается от обычного (спойлер: почти всем)
- Пилот и умение управлять мотоциклом. Из чего складывается пилотирование.
- К чему приводят критические ошибки при пилотировании, помимо ухудшения времени круга. Самые распространенные виды падений
- Данные не врут. В отличие от пилотов мотогонок 😃
- Необъективность ощущений пилотов. Как мы оцифровываем скиллы.
- Датчики, которые мы ставим
- Метрики, которые мы собираем
- Примеры графиков, основанных на реальных данных
- Разбор телеметрии. Что мы видим на графиках, и как картинки на экране приводят к победе в чемпионате
- Пример 1. Закрытие газа
- Пример 2. Улучшение техники торможения, сдвиг точки торможения (1 поворот трассы Igora Drive)
- Пример 3. Изменение траектории и увеличение скорости прохождения поворота (4 поворот трассы Moscow Raceway)
- Заключение. Мотоспорт и снимаемые метрики как метафора реальному бизнесу

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

В рамках доклада расскажу:

1. Вредные советы по работе с ClickHouse — поделюсь полученными на собственном опыте знаниями, распространёнными ошибками при создании и разработки на CH-кластере. Расскажу, к каким последствиям приводят ошибки и как их избежать.

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

3. Результаты первого квартала – раскрою, как мы вышли на стабильность кластера в 99,9% и разделили большой кластер между аналитическими командами.

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

Отношения между Spark и Parquet (и другими колоночными форматами) можно вкратце описать так:
– Мама, можно нам домой doExecuteColumnar?
– У нас есть дома doExecuteColumnar.
*doExecuteColumnar дома: ColumnarToRowExec.*

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

Чтобы понять причины такого поведения и выяснить, можем ли мы его контролировать, нам надо сделать шаг назад и разобрать текущую модель вычислений в Spark: данные (строки, колонки, партиции, JVM-объекты, внутренние структуры и типы даных Spark, Arrow) и их обработка (Columnar Execution, WholeStageCodeGeneration), связав эти понятия в единую картину. Рассмотрим, как из примитивных конструкций формируются распределенные коллекции, и как нам их приручить, чтобы писать более оптимальные приложения. Обсудим нюансы и детали связанных концепций: кеширование, шаффл, некоторые трансформы. В конце проведем небольшое сравнение архитектуры Spark и смежных фреймворков: Databricks Photon, Apache Comet, Apache Gluten.

1. Использование Debezium и kafka-connect для репликации
- Использование Kafka-Connect для доставки изменений из базы данных в топик Kafka

2. Роль Heartbeat, и как он решает проблему отставания слота репликации
- Heartbeat облегчает мониторинг Debezium.
- Решение проблемы отставания в PostgreSQL при чтении части таблиц.

3. Сигналы в Debezium: новый уровень управления снепшотами
- Современный подход к созданию снепшотов.
- Снижение нагрузки на БД при их использовании.
- Гибкость управления: запуск, пауза, отмена.
- Прозрачный мониторинг снепшотов

Data Lake является хранилищем сырых данных в Аналитической платформе X5 . Уже много лет данные в него загружается самописным фреймворком при помощи Sqoop. Это крайне простая и удобная утилита, отлично справляющаяся со своими задачами. Мы даже её портировали на Hadoop3, хотя для него нет готовых сборок, но она больше не развивается и уже морально устарела.
Было принято решение найти ему замену, но как оказалось Sqoop не оставил приемников.
Конечно же есть универсальный швейцарский нож Spark который справится с любыми задачами. Но после использования элементарной утилиты не хотелось утяжелять решение.

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

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

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

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

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

Классификация эмбеддингов(Текстовые, Звуковые, Изображения, Составные эмбеддинги)

Операции с эмбеддингами:
Суммирование и кластеризация для выявления групп и схожести данных.

Эмбеддинге в поиске:
Делаем векторный поиск на коленке на базе Qdrant

Рекомендательные системы:
Векторная рекомендательная система за 5 минут

Основной посыл:
Эмбеддинги — мощный инструмент для структурирования и анализа данных, который трансформирует подход к поиску, рекомендациям и обработке информации.

Расскажу о создании Streaming Platform от возникновения идеи и до реализации. Про проблемы, с которыми сталкивались, и расскажу возможными решениями. Обсудим особенности стриминговой обработки, которые сложно уложить в шаблонное решение. И я предложу альтернативу Streaming Platform в виде стриминговых инструментов as a service.

Что спрятано под кнопкой "Я согласен"?
В докладе планирую рассказать немного о том, кому обычно принадлежат права на код, написанный самостоятельно, и много времени посветить разбору лицензионных соглашений от ChatGPT, GigaChat (+ GigaCode) Copilot, Codeium, CodeWhisperer, Gemini.
Путей обхода - не будет.
Подводные камни - будут.