- 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

В докладе мы расскажем, чем архитектурно отличается Postgres Query Optimizer (Planner) родом из 70-х от спроектированного в 90-е планировщика Orca. Мы также объясним, какие запросы Greenplum с Planner будет жевать на порядки дольше, чем запланированные Orca, и почему.
Мы поясним, где Planner не совсем cost-based, а где он всё же использует стоимостную модель, сравним его с Orca на кейсах с пробросом группировки и коррелированными подзапросами. Кроме того, мы коснёмся и конкретных случаев, где Planner всё же остаётся незаменимым.

Столкнувшись с задачей сбора Data Lineage из ETL/ELT процессов, основанных на Apache Spark и Apache Airflow, наша команда надеялась, что это будет довольно просто, и получится использовать какое-то из готовых Open Source решений - OpenMetadata, DataHub, Marquez и т.п. Все оказалось немного сложнее, сходу ни один инструмент нам не подошел, и мы начали разрабатывать собственное решение - сервис DataRentgen.
В докладе описывается путь к разработке инструмента длиною в полтора года - требования пользователей, RnD Open Source решений и их недостатки, немного метаний между разными технологиями сбора и хранения Lineage, и к чему мы в конечном итоге пришли. DataRentgen все еще в активной разработке, но уже собирает довольно много полезных данных.

1. Большая база - большие сложности. Петабайты в MyTracker. ClickHouse не всесилен.

2. Не insert into select-ом единым. Тим Тоуди. ClickHouse прекрасен.

3. Как мы решардим базу удалением.

4. Insert into select тоже торт, и неожиданное применение сэмплирования.

В докладе будет рассказано, как объединить подходы поколоночной обработки с использованием SIMD с JIT компиляцией для вычисления выражений в SQL движке.

Доклад посвящен эволюции и практическому применению самописному DAG Factory в экосистеме Apache Airflow на примере пятилетнего опыта компании. Рассматриваются предпосылки внедрения динамической генерации DAG-файлов, анализируются преимущества и недостатки данного подхода, включая упрощение работы аналитиков с Airflow через YAML-конфигурации и высвобождение ресурсов инженеров. Особое внимание уделяется техническим вызовам при переходе между версиями Airflow (1.x → 2.x), таким как проблемы сериализации DAG и мониторинга, а также специфике реализации собственного решения marts_load_v1. В заключение обсуждаются перспективы развития системы в контексте выхода Airflow 3, миграции от монокластера к мультикластерной архитектуре и дальнейшего сосуществования с современными инструментами при сохранении совместимости с существующими DQ- и BI-решениями.

Расскажу как переводили тяжёлую отчётность с модели импорта Power BI на прямые запросы DataLens + ClickHouse, рассмотрим какие проблемы пришлось решить.
После ухода Power BI столкнулись, что пока нет хороших решений, где можно просто загрузить данные в систему отчётности и отчёт будет работать на мощном облачном сервере более менее терпимо даже при объёме данный в миллиарды строк.
Доступные отечественные и свободные решения, в основном, строятся на прямых запросах, а это значит, что нужно самостоятельно заниматься задачами по оптимизации структуры данных, настройки кластеров и оптимизации запросов.
Сложности добавляло, что наша команда занимается проектами монетизации данных - отчётность предоставляется поставщикам и бюджеты на отчёты весьма ограничены, нет возможности использовать сверхмощные кластера. Требуется реализовывать отчётность в десятки миллиарды строк на скромных мощностях и чтобы данные обрабатывались за десятки секунд.
Мы начинали с Greenplum, но не устроила производительность, остановились на ClickHouse и выжимали оптимизацию из всего что можно, разбирались с движками, типами данных, кодеками, проекциями, индексами, стратегиями объединения данных, парализацией, схемами запросов, метриками производительности и прочим.
В итоге разобрались как настраивать ClickHouse для высокопроизводительной BI отчётности и готовы поделиться опытом.

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

Структура доклада:
1. Приветствие - рассказывает Владислав
2. Знакомство с публикой - рассказывает Владислав
3. Адженда доклада - рассказывает Владислав
4. Что такое SAS? - рассказывает Владислав
5. Причины старта проекта декомиссии - рассказывает Владислав
6. Состав проекта - рассказывает Владислав
7. Стек технологий, какой компонент экосистемы SAS заменили на open-source - рассказывает Владислав
8. С чего начать миграцию? Выбор пилотной задачи - рассказывает Владислав
9. Отсутствие инфо о владении объектов SAS - рассказывает Владислав
10. Отключение неактуальных ETL-процессов, отчетов, витрин - рассказывает Владислав
11. Миграция пользователей, используя чат-бота - рассказывает Владислав
12. Расхождение расчетов на SAS и Greenplum - рассказывает Владислав
13. Соблюдение SLA по поставке данных в новом хранилище - рассказывает Владислав
14. Перенос исторических данных с SAS на HDFS + Greenplum - рассказывает Владислав
15. Построение аналитики хода динамики миграции - рассказывает Владислав
16. Заключение, как подготовить большую платформу данных к миграции? - рассказывает Владислав

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

В этом докладе мы представим WeSQL — облачную СУБД с открытым кодом и раздельными уровнями compute/storage, разработанную на основе MySQL для эффективной работы на S3. Мы расскажем о мотивации создания WeSQL, объясним, почему был выбран движок хранения на основе LSM-дерева, и как локальные диски вычислительных узлов используются совместно с S3.

Вы узнаете, как WeSQL достигает высокой экономической эффективности за счёт:

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

Мы также поделимся планами по дальнейшему развитию WeSQL, а также продвижению и поддержке WeSQL в России.

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

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

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