Доклады
Разработка СУБД (10)
Векторный поиск в YDB: опыт выбора и реализации
Мы расскажем о нашем опыте разработки векторного индекса для YDB: какие подходы мы пробовали, с какими трудностями столкнулись и почему от чего-то отказывались.
Поделимся сравнением различных решений, подробно разберём их плюсы и минусы на практике.
Представим финальную версию векторного индекса в YDB, покажем его архитектуру и расскажем, как он помог нам реализовать быстрый и масштабируемый векторный поиск.
Доклад принят в программу конференции
Глобальные вторичные индексы в распределённой СУБД
В докладе разберёмся, что такое глобальные индексы, зачем они нужны, какие бывают подходы к их реализации и с какими минами можно столкнуться. Поговорим о синхронной и асинхронной репликации, о боли с консистентностью, об архитектурных компромиссах и неожиданных граблях.
Доклад акцентирован на теоретических аспектах и практических советах: как реализовать глобальные индексы в распределённой системе и не умереть. Или хотя бы повысить шансы выжить имея приблизительную карту минного поля.
Доклад принят в программу конференции
Подходы к планированию запросов в Postgres Query Optimizer и Orca
В докладе мы расскажем, чем архитектурно отличается Postgres Query Optimizer (Planner) родом из 70-х от спроектированного в 90-е планировщика Orca. Мы также объясним, какие запросы Greenplum с Planner будет жевать на порядки дольше, чем запланированные Orca, и почему.
Мы поясним, где Planner не совсем cost-based, а где он всё же использует стоимостную модель, сравним его с Orca на кейсах с пробросом группировки и коррелированными подзапросами. Кроме того, мы коснёмся и конкретных случаев, где Planner всё же остаётся незаменимым.
Доклад принят в программу конференции
Managed Sharded PostgreSQL Service в Яндекс Облаке
Stateless Postgres Query Router (SPQR) — open-source решение для горизонтального масштабирования PostgreSQL через шардирование. Мы разрабатываем эту систему в Yandex Cloud, и это уже четвёртая итерация наших попыток построить масштабируемый PostgreSQL. До SPQR мы пробовали переиспользовать PostgreSQL FDW механизм, писали хуки в планнере запросов, реализовали прокси на чистом C — и в итоге пришли к SPQR, написанному на Go и работающему на уровне протокола PostgreSQL.
SPQR поддерживает шардирование как по диапазону значений, так и по хэшу. Система совместима не только с обычным текстовым протоколом PostgreSQL, но и с extended protocol — что позволяет использовать prepared statements и клиентские библиотеки без изменений. Роутер работает в сессионном и транзакционном режимах, в реальном времени определяет, на каком шарде нужно выполнить запрос, и управляет перемещением данных между ними.
В докладе мы расскажем:
- как построить масштабируемую OLTP-базу на PostgreSQL;
- какие архитектурные решения легли в основу SPQR;
- как мы добавляем новые шарды без решардинга;
- как устроен собственный SQL-лексер и почему мы отказались от pganalyze/pg_query_go;
- как реализовать PostgreSQL-прокси с поддержкой транзакций и extended protocol;
- какие проблемы возникают при построении таких систем: от оценки нагрузки на ключи до блокировок, перевоза данных и отказоустойчивости;
- будущее развития нашей системы.
Это доклад для разработчиков распределённых систем и тех, кто масштабирует PostgreSQL или только собирается это делать. Вы узнаете, что стоит за словами "Postgres-прокси" на практике — с примерами, болью и кодом.
Доклад принят в программу конференции
Балансировка по нагрузке в динтаблицах YTsaurus
Работа распределённой СУБД существенно зависит от шардирования данных. Когда данных много и они очень неоднородны — тысячи таблиц на сотнях машин — без фонового динамического перераспределения просто ничего не будет работать из-за постоянно возникающих неоднородностей, превышающих возможности отдельного шарда. Данную задачу можно разделить на две основные части: техническую реализацию перемещения шарда между нодами и алгоритмический процесс выбора шардов, которые нужно переместить. В докладе я сконцентрируюсь на второй части и расскажу, как мы решаем задачу планирования перераспределения шардов по нагрузке в динтаблицах YTsaurus — распределённом key-value сторадже, используемом для подготовки больших данных в Яндексе и выложенном в Open Source.
Доклад принят в программу конференции
Многопоточное и/или консистентное чтение из реляционных источников данных в федеративных системах
Федеративные SQL-запросы - запросы, адресованные внешним источникам данных. Они часто используются для оперативной аналитики разнородных данных и их миграции между различными хранилищами. Чтобы федеративные запросы летали, федеративные системы должны уметь быстро извлекать большие объёмы данных из внешних источников. Чтение данных в один поток - слишком медленное и неэффективное, особенно с учётом того, что федеративная система - обычно ещё и система распределённая. Чтение данных в несколько потоков по частям позволяет гораздо лучше утилизировать аппаратные ресурсы федеративной системы, однако ставит вопрос о согласованности данных: смогут ли читающие потоки видеть одно и то же состояние внешней таблицы?
Облачный сервис обработки аналитических запросов Yandex Query, построенный на основе YDB, является примером такой системы. Оптимизируя его пропускную способность, мы занялись задачей многопоточного чтения из внешних источников данных, и в этом докладе хотим поделиться накопленным опытом. Мы проведём сравнительный анализ API популярных реляционных СУБД (PostgreSQL, MySQL, Oracle, MS SQL Server, Greenplum, CocroachDB, YDB) с точки зрения возможностей многопоточного, консистентного и отказоустойчивого чтения, коснёмся темы MVCC - в классическом и распределённом варианте, а также погрузимся в технику разбиения массива данных на "сплиты" - элементарные единицы работы в системе массивно-параллельной обработки данных. А ещё в докладе будет много подробностей об устройстве федеративной YDB и сценариях её применения в Yandex Cloud.
Доклад принят в программу конференции
Как мы решардим петабайтные кликхаузы в MyTracker: удаляй и властвуй
Расскажу про нестандартный способ отмасштабировать (очень) большой кластер ClickHouse — используем репликацию и DELETE вместо INSERT .. SELECT.
Доклад принят в программу конференции
DuckDB для работы с графами: Форматы хранения графа в S3, расширение GraphAr и опыт разработки
Мы расскажем об исследованиях форматов представления графа в DLH-инфраструктуре для различных аналитических сценариев.
Эффективный доступ к данным графа в S3 требует быстрый доступ как к точечным вершинам для поиска соседей, фильтрации меток и загрузки-выгрузки больших частей графа для аналитики. Стандартные форматы хранения в DLH не всегда эффективны в этих сценариях.
Подход от Alibaba в виде платформы GraphScope использует представление графа в формате GraphAr который решает предлагает решение проблемы доступа к данным за счет сочетания хранения семантики графа в слое метаданых, колоночного представления и набора методов оптимизации специфичных для Labeled Property Graph (CSR, дельта-кодирование, Page-alligned Collections и другие). Это позволяет не только эффективно хранить данные графа но и стать центральной частью экосистемы обработки графов в DLH.
В рамках исследования нашей командой была реализована поддержка формата GraphAr для DuckDB и проведены первичные замеры эффективности реализации основных сценариев аналитики на графе в сравнении с Iceberg, Hive и графовыми БД.
Расскажем про детали реализации и выводы о преимуществах и недостатках. Поделимся результатами проведенных бенчмарков на датасетах SNAP и LDBC и реальных графах большого размера, а также нашим опытом в работе с ними.
Доклад принят в программу конференции
Оптимальное вычисление выражений в аналитических запросах с использованием SIMD и JIT.
В докладе будет рассказано, как объединить подходы поколоночной обработки с использованием SIMD с JIT компиляцией для вычисления выражений в SQL движке.
Доклад принят в программу конференции
Балансировка данных на кластерах OpenSearch: покоординатный спуск
Задача о многомерных ранцах или история про то как мы научили OpenSearch распределять данные в кластере так чтобы обеспечить и равномерное потребление диска и нагрузку на индексацию и на поиск
Доклад принят в программу конференции
Практические примеры внедрений (4)
Ревью без боли: DataOps-подход к управлению изменениями в DWH
В условиях Data Mesh, где нет централизованной команды инженеров данных и аналитиков, поддержание качества кода в распределённой среде стало ключевым вызовом. За последние годы наша платформа данных прошла путь от ручного ревью изменений и частых хотфиксов до полностью автоматизированного CI/CD-пайплайна. Мы расскажем, как внедрили статические и интеграционные тесты для SQL-кода и автоматизировали контроль за выполнением пользователями стандартов разработки. Вы узнаете, какие инструменты и подходы помогли нам выявлять неоптимальный код, контролировать права доступа и поддерживать актуальность репозитория.
Мы поделимся инсайтами: как команда адаптировалась к новым процессам, какие ошибки удалось предотвратить и как автоматизация повлияла на скорость и качество разработки. Этот опыт будет полезен инженерам данных, которые хотят минимизировать рутину и сделать свои хранилища надежнее.
Доклад принят в программу конференции
Airflow еще доступнее: опыт self-service оркестрации в LemanaTech
Apache Airflow — популярный инструмент для планирования и оркестрации задач. Несмотря на низкий порог входа, он требует базовых знаний Python, что может затруднять его использование аналитиками и увеличивать нагрузку на инженеров.
В докладе будет рассказано, как нам удалось сделать Airflow удобным не только для разработчиков, но и для аналитиков, переведя типовые сценарии в формат YAML-конфигураций. Вы узнаете:
· как перейти от ручного написания DAG к self-service автоматизации;
· как обеспечить масштабируемость, безопасность и управляемость решений;
· с какими техническими вызовами мы столкнулись при миграции мажорных версий;
· какой опыт эксплуатации был получен за 5 лет использования одного из внутренних решений.
Доклад будет интересен инженерам и аналитикам, которые хотят сделать оркестрацию процессов более доступной и управляемой.
Доклад принят в программу конференции
Выжимаем максимум из Clickhouse для BI отчётности с ограниченным бюджетом
Расскажу как переводили тяжёлую отчётность с модели импорта Power BI на прямые запросы DataLens + ClickHouse, рассмотрим какие проблемы пришлось решить.
После ухода Power BI столкнулись, что пока нет хороших решений, где можно просто загрузить данные в систему отчётности и отчёт будет работать на мощном облачном сервере более менее терпимо даже при объёме данный в миллиарды строк.
Доступные отечественные и свободные решения, в основном, строятся на прямых запросах, а это значит, что нужно самостоятельно заниматься задачами по оптимизации структуры данных, настройки кластеров и оптимизации запросов.
Сложности добавляло, что наша команда занимается проектами монетизации данных - отчётность предоставляется поставщикам и бюджеты на отчёты весьма ограничены, нет возможности использовать сверхмощные кластера. Требуется реализовывать отчётность в десятки миллиарды строк на скромных мощностях и чтобы данные обрабатывались за десятки секунд.
Мы начинали с Greenplum, но не устроила производительность, остановились на ClickHouse и выжимали оптимизацию из всего что можно, разбирались с движками, типами данных, кодеками, проекциями, индексами, стратегиями объединения данных, парализацией, схемами запросов, метриками производительности и прочим.
В итоге разобрались как настраивать ClickHouse для высокопроизводительной BI отчётности и готовы поделиться опытом.
Доклад принят в программу конференции
Как подготовить платформу данных к миграции уже сейчас?
Доклад описывает опыт решения проблем, возникших в рамках проекта миграции аналитического хранилища SAS, включая отсутствие информации о владении объектов, отключение неактуальных процессов, миграцию пользователей и данных, расхождение расчетов, соблюдение SLA, построение аналитики хода динамики миграции и многое другое
Структура доклада:
1. Приветствие
2. Знакомство
3. Адженда доклада
4. Что такое SAS?
5. Про проект миграции
7. С чего начать миграцию?
9. Отсутствие информации о владении объектов SAS
10. Cоблюдение ранее заключенных SLA на новом хранилище
11. Расхождение расчетов между SAS и Greenplum
12. Миграция пользователей
на целевые системы
13. Резюме доклада
14. Секция Q&A
Доклад принят в программу конференции
Архитектура данных (3)
Streaming и batch в единой платформе. Взболтать, но не смешивать!
В Яндекс Go мы строим единую платформу обработки данных для нескольких бизнесов (Такси, Еда, Лавка, Доставка и др.), которая предоставляется нашему ключевому пользователю, инженеру данных, как решение "под ключ", как единое рабочее место (фреймворк и сервисы) для batch и streaming поставки и обработки данных.
В своем докладе я хочу поделиться опытом расширения устройвшейся и зрелой платформы данных для batch-а принципиально другим сценарием - streaming-ом. Я расскажу о том, какая была мотивация интегрировать Apache Flink в единое решение для обработки данных, какие есть плюсы и минусы такого подхода и почему мы верим в то, что это было правильным решением и планируем его активно развивать в будущем.
Этот доклад может быть интересен практикующим инженерам данных, техлидам и архитекторам, руководителям DWH, а может даже и CTO.
Доклад принят в программу конференции
Citus изнутри: как устроен шардинг
В PostgreSQL для горизонтального масштабирования реализован ряд как коммерческих, так и бесплатных решений, и одно из таких - это расширение от компании CitusData (приобретена Microsoft). Как расширение устроено логически и физически, как работают распределенные транзакции, какие запросы оптимизатор выполнить не сможет, как эти запросы устроены на логическом уровне, как построить правильно архитектуру распределенных данных ...в общем, речь пойдет об этих и других вопросах распределенных транзакций в Citus, а также о плюсах и минусах и какие плюшки можно извлечь при небольших доработках.
Доклад принят в программу конференции
(En) WeSQL: Облачная СУБД на базе MySQL
В этом докладе мы представим WeSQL — облачную СУБД с открытым кодом и раздельными уровнями compute/storage, разработанную на основе MySQL для эффективной работы на S3. Мы расскажем о мотивации создания WeSQL, объясним, почему был выбран движок хранения на основе LSM-дерева, и как локальные диски вычислительных узлов используются совместно с S3.
Вы узнаете, как WeSQL достигает высокой экономической эффективности за счёт:
- разделения требований к задержкам и отказоустойчивости
- использования персистентного кеша
- гибридного row-column формата хранения.
Мы также поделимся планами по дальнейшему развитию WeSQL, а также продвижению и поддержке WeSQL в России.
Доклад принят в программу конференции
Управление данными (6)
Мониторинг качества данных - вершина айберга или дно впадины?
Доклад построен на примере контроля качества данных отдела «Управление благосостоянием» Сбера. К этому направлению относятся брокерские счета, индивидуальные инвестиционные счета, продукты доверительного управления, паи в паевых инвестиционных фондах, обезличенные металлические счета, доход от договоров страхования жизни и доход, получаемый от денежных средств в негосударственных пенсионных фондах.
В докладе расскажу о том, как и на что мы сейчас проверяем данные, которые приходят из разных (в том числе внешних и общедоступных) источников, как выстраивали систему мониторинга, как, с кем и какие договоренности достигнуты, также осветить вопрос про сами проверки, какие оказались излишни, а какие крайне важны. Поделиться опытом инцидент-менеджмента между несколькими разными командами и отделами. Показать вариации решений, которые были раньше, и во что трансформировались сейчас.
Поделюсь, почему это важно, что вообще с этим делать, какие подходы сейчас используются и как с этим жить всем участникам процесса
Опыт может быть полезен другим компаниям и командам для повышения качества данных в своих продуктах.
Доклад принят в программу конференции
Гибкая настройка параметров запуска spark приложений
Сегодня актуальной проблемой является неправильная настройка параметров запуска spark приложений, которые зачастую настраиваются неверно или просто копируются из других app, что приводит к замедлению расчета, падениям при запуске и в процессе работы. В своем докладе расскажу, на что стоит обращать внимание и как оптимально настроить потоки, чтобы оптимизировать расчет и избежать вышеописанных проблем
Доклад принят в программу конференции
Data Quality как distributed-система: паттерны отказоустойчивости для данных
В современных data-продуктах качество данных — это не разовые проверки, а непрерывный процесс.
На примере расскажу, как быстро и правильно запустить и внедрить DQ-инструмент, а также о его гибком и мощном арсенале для контроля данных и процессах работы с ним. Это поможет справляться с современными масштабами и вызовами.
Решения, которые будут затронуты:
✔ Базовая архитектура - с чего всё начинается
✔ Автоматизация рутины – чат-бот для алертов + автотикеты
✔ Проверка data-контрактов – как быстро внедрить автоматическую валидацию схем
✔ Реализация гибких триггеров проверок
✔ Детекция аномалий – от простых SQL-правил до ML для сложных кейсов
✔ Полный аудит ошибок – сохраняем проблемные данные + SQL-запросы для анализа
✔ Карантин – изоляция "битых" данных без потери информации
✔ Автогенерация DQ-проверок с помощью LLM – снижение ручного труда за счет автоматического создания SQL-правил и data-контрактов на основе описания данных и требований
✔ Обучение модели на исторических инцидентах для предложения превентивных проверок
Технологии:
Триггеры (Airflow, DWH-интеграция)
Адаптивные пороги для алертов
LLM для генерации DQ-проверок, поддержка естественного языка
Дашборды мониторинга
Что узнаете:
→ Как за минимальный срок развернуть оптимальную DQ архитектуру
→ Каким образом снизить нагрузку на команду за счет умных алертов
→ Когда ML в DQ – это must have, а когда – overkill
→ Как внедрить систему, которая экономит 80% времени
Итог:
Data Quality больше не пожарные бригады — это встроенный иммунитет data-экосистемы. Покажу реальное работающее решение, как перейти от ручного контроля к системной надёжности.
Доклад принят в программу конференции
Python вместо ручек. Как мы автоматизировали проставление атрибутов сущностей в дата каталоге.
Работа с дата каталогом – это всегда очень много ручного труда: описание, проставление владельцев и стюардов, тегирование и тд. Но мы заметили, что есть ситуации, когда мы проставляем некоторые атрибуты по понятным правилам. А если есть правила, значит можно автоматизировать. В докладе расскажу, что это за правила и как мы реализовали систему, в разы сократившую время на рутинную работу с каталогом.
Доклад принят в программу конференции
Data Governance в финтехе: конкурентное преимущество в эпоху AI
Как подойти к Data Governance не как к локальной инициативе, а как к системной трансформации управления данными в крупной организации? В докладе разберём, как мы в Альфа-Банке шаг за шагом выстраиваем такую работу: от выбора подхода до оценки результатов.
Покажем, как в условиях устоявшихся процессов и множества дата-ролей мы внедряем практики управления данными: как выбирали подход, выстраивали ролевую модель, как развиваем собственные инструменты и постепенно встраиваем принципы Data Governance в производственные процессы. И конечно, как доказываем ценность бизнесу.
Доклад принят в программу конференции
Дата Контракты - как создать продукт с нуля, изменив мышление всей компании
Расскажу о пути длиною в год, как мы в компании пришли от идеи продукта Контрактов данных до его реализации и заезда поставщиков в него. Обсудим, какие проблемы мы хотели решить внедрением продукта, какие технологии были выбраны для создания и какая вышла архитектура в финальном варианте. Также, с другой стороны, рассмотрим проблемы внедрения продукта на большую аудиторию: реально ли это сделать в короткий срок?
Доклад принят в программу конференции
Машинное обучение и искусственный интеллект в разработке инструментов управления данными (2)
Рецепты приготовления AI-ready контента в BI
В жизни каждого руководителя бывают моменты, когда зашел за метрикой не в ту дверь: получил значение, обещал перевыполнить план, но не знал о характере обновления дашборда и его фильтрах по умолчанию. Чтобы пользователи нашей платформы данных перестали попадать в подобные ситуации, мы разработали решение для поиска и фильтрации нужных показателей в BI на основе LLM-агентов.
В рамках данного доклада обсудим:
• преимущества и недостатки AI подхода
• основные сложности, с которыми мы столкнулись на этапе подготовки контента для AI-агента
• механизмы верификации AI-ready контента в BI
Доклад принят в программу конференции
Все еще ходите за метриками в BI? Как мы экспериментировали с LLM и не пRAGадали
Мы — платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Коротко о нас:
— собираем более 6 млрд событий в день;
— собрано и накоплено 2,5 трлн событий к концу 1 квартала 2025 года;
— DAU — 200+, WAU — 400+, MAU — 700+ (активные пользователи за день, неделю, месяц соответственно);
— несколько BI (Metabase, Superset, Grafana).
Платформа содержит огромное количество данных. Основной BI инструмент — демократичный Metabase, и из-за демократии куча дашбордов в нем. Поиск и выбор достоверных показателей занимает порою очень много времени даже для опытного аналитика, не говоря уже о новых пользователях системы. Для решения этой задачи мы посмотрели в сторону решения на основе LLM-агентов и запросов в API BI системы.
Технологии:
Python — на нем написана основная функциональность AI-помощника.
Mattermost — корпоративный мессенджер, в котором агент будет работать.
GigaChat — в качестве LLM, которая поможет реализовать агентов.
Доклад принят в программу конференции
Системы хранения (3)
CSI-драйверы: подводные камни и архитектурные решения
Что такое CSI и зачем он Kubernetes.
Как устроена интеграция с разными типами хранилищ - через API и без него.
Наш опыт разработки драйвера csi-scsi-generic.
Подход к архитектуре драйвера, универсальность и расширяемость.
Проблемы, которые мы решали: resize, multipath, очистка устройств.
Доклад принят в программу конференции
Доставка данных для ML в Kubernetes: от S3 до распределенных проектных хранилищ
В докладе будет рассказано о пути оптимизации процесса доставки данных для обучения моделей в Kubernetes.
Начиная с простой загрузки из S3, мы столкнулись с проблемой увеличения времени запуска задач обучения и решали её путем поэтапного развития.
Мы расскажем, как мы:
- Перешли от простой загрузки из S3 к кешированию на нодах с использованием Kubernetes CSI драйвера.
- Улучшили процесс, внедрив кеширование в кластерах с помощью NFS шар и K8S оператора, и какие ограничения мы встретили.
- Разработали и внедрили проектные хранилища с бекапом в S3, используя NFS Storage API, K8S оператор и CRUD сервис.
План доклада
1. Введение в проблему
- Начальные подходы: простая загрузка из S3 и их ограничения.
- Проблемы с большим временем запуска задач обучения.
2. Первый шаг: кеширование на нодах
- Реализация с помощью Kubernetes CSI драйвера.
- Проблемы с утилизацией ресурсов и наблюдаемостью.
3. Улучшение: кеширование в кластерах с NFS
- Реализация с помощью NFS шар и K8S оператора.
- Ограничения по объему и совместной работе.
4. Развитие: именованные хранилища с бекапом в S3
- Архитектура и реализация с использованием Storage API.
- Создание и управление NFS хранилищами с помощью K8S оператора и CRUD сервиса.
5. Практический опыт и результаты
- Как проектные хранилища изменили наш процесс: метрики эффективности.
- Примеры использования и совместной работы в командах.
Доклад принят в программу конференции
Вы строите Lakehouse, а сторадж строит вам проблемы
Вы можете сколько угодно обсуждать компьют и форматы хранения — но если вы строите Lakehouse, рано или поздно упрётесь в сторадж.
Мы прошли через это:
—спасали Lakehouse от тупика в трупуте,
—боролись с шумными соседями и деградацией IO,
—выжали 80 ГБ/с, обойдя ограничения одного кластера,
—и поняли, что архитектура Lakehouse начинается с правильного стораджа.
Этот доклад — честный отчёт о том, как выжить и масштабироваться, когда сторадж стал узким горлышком всей аналитической платформы.
Будет боль, будет правда, будут выводы.
Доклад принят в программу конференции
Разработка инструментов работы с данными (2)
DataRentgen: чем плох lineage в OSS DataCatalog, и как сделать лучше
Столкнувшись с задачей сбора Data Lineage из ETL/ELT процессов, основанных на Apache Spark и Apache Airflow, наша команда надеялась, что это будет довольно просто, и получится использовать какое-то из готовых Open Source решений - OpenMetadata, DataHub, Marquez и т.п. Все оказалось немного сложнее - сходу ни один инструмент нам не подошел, либо по функционалу, либо по производительности. В итоге мы начали разрабатывать собственное решение - сервис DataRentgen https://github.com/MobileTeleSystems/data-rentgen.
В докладе описывается путь к разработке инструмента длиною в полтора года - требования пользователей, RnD Open Source решений и их недостатки, немного метаний между разными технологиями сбора и хранения Lineage, и к чему мы в конечном итоге пришли. DataRentgen все еще в активной разработке, но уже собирает довольно много полезных данных.
Доклад принят в программу конференции
От Pydantic v1 к v3: глубокий разбор Pydantic Core на Rust и алгоритмов валидаторов
- Pydantic v2 перенёс всю логику валидации в Rust-библиотеку pydantic-core через PyO3, что дало до 17× ускорения валидации моделей по сравнению с v1 .
- В PydanticCore используется SIMD-оптимизация целочисленного и строкового JSON-парсинга на AArch64 и fast-path для ASCII-строк (~15% прирост), а также перенос валидации enum-типов в Rust (~4× ускорение) .
- Кэширование и переиспользование CoreSchema для обобщённых типов снижает время старта FastAPI-приложений на 67% в сценариях интенсивного использования generics .
- Повторное использование экземпляров SchemaValidator и SchemaSerializer, а также ленивое вычисление аннотаций FieldInfo сокращает затраты памяти на 2–5× при большом числе вложенных моделей .
- В Pydantic v3 планируется убрать обвязку миграции из v1, добавить более богатый контекст ошибок (номер строки и столбца при JSON-валидации) и оптимизировать @validate_call, сохранив скорость v2
Доклад принят в программу конференции
Резерв (5)
Технология многоуровневого инкрементального резервирования и ее интеграция с ядром СУБД
Каждая СУБД на рынке имеет развитые средства резервного копирования и восстановления. С ростом объемов данных наблюдается смещение приоритетов от логического (на уровне строк) к физическому (на уровне блоков) резервированию. Следующим шагом развития данных инструментов стали технологии инкрементального резервирования. В докладе я расскажу о развитии инструментов инкрементного физического резервирования в СУБД Firebird и Ред База Данных и о нашей технологии многоуровневого инкрементного резервирования, при этом мы взглянем на этот вопрос со стороны ядра СУБД - какие архитектурные доработки потребовались для поддержки данного функционала и какие побочные бонусы привнесла эта технология в жизнь администраторов и пользователей нашей СУБД.
Доклад принят в программу конференции
Внедрение Data Catalog в Циан: наш путь к прозрачности работы с данными
В своем докладе я поделюсь опытом внедрения каталога данных в компании Циан. Что мотивировало нас внедрить новый инструмент, с какими сложностями мы столкнулись на пути и получилось ли у нас достичь прозрачности в работе с данными
Доклад принят в программу конференции
DataPortal: как мы навели порядок в задачах DQ, DataLineage и DataCatalog
В докладе поделюсь проблемами, с которыми мы столкнулись до появления аналитического DWH-контура: разрозненные источники данных, сложность интеграции и отсутствие единой точки доступа. Расскажу, как мы видели решение этих проблем через построение централизованного хранилища и выбор подходящих инструментов, а также поделюсь итоговой архитектурой, которая позволила упростить миграции между инструментами и повысить гибкость аналитической инфраструктуры. Особое внимание уделю сервисам, которые мы внедрили для аналитиков, включая внутренний Data Portal, созданный практически полностью с помощью GPT человеком без опыта в веб-разработке, что значительно ускорило процесс и расширило возможности команды.
Доклад принят в программу конференции
Как мы пришли к централизованной авторизации BigData. Путь от Standalone до CloudNative
В современных Big Data экосистемах управление доступом к данным становится критически важным по мере роста кластеров и усложнения инфраструктуры. В докладе мы расскажем об особенностях организации доступа к большим данным, поделимся опытом Сбера в части эволюции системы авторизации больших данных: от изолированного Standalone-решения к облачной CloudNative архитектуре, способной масштабироваться вместе с бизнес-потребностями.
На примере реального кейса рассматривается путь модернизации механизмов, начиная с выбора подходящего решения, такого как Apache Ranger и его применения к BigData экосистеме, и заканчивая сложностями масштабирования и переносом сервиса в контейнерное окружение Kubernetes. Особое внимание уделяется проблемам сайзинга, возникающим при росте числа клиентов, и способам их решения с использованием технологий Service Mesh. В заключении обсуждаются ключевые аспекты, на которые стоит обратить внимание при миграции в облако и управлении высоконагруженными системами.
Ключевые показатели решения:
· снизили потребление компьютерных ресурсов в 2 раза, не снижая при этом уровень доступности сервиса;
· снизили T2M на 200%+ (с 1,5 часов до 8 сек.).
Доклад принят в программу конференции
Построение управления данными вокруг InMemory хранилища.
Расскажу как мы выстраивали управления данными вокруг InMemory хранилища, как мигрировали с одного MDM на другой и почему нельзя вот так просто использовать коробочные продукты управления мастер данными.
Доклад принят в программу конференции