Расписание

Как научить LLM не просто писать правдоподобный SQL, а действительно работать с корпоративными данными: находить правильные источники, понимать метрики, писать ETL и проверять собственные ответы. На опыте полутора лет внедрения AI в Яндексе разберем рабочую архитектуру, подход к оценке качества и ошибки, из-за которых красивые демо не превращаются в полезные инструменты.

Раньше спорили про формат хранения данных и то, какой аналитический движок использовать. Но ведь еще и надо задумываться над тем, как мы эти данные получим.

Доклад о том, почему на масштабе большой Data Platform набор разрозненных инструментов перестает работать и почему платформу нужно рассматривать как единый ADLC, а не как набор отдельных сервисов. Покажу, как это влияет на ETL, ad hoc-разработку, Data Governance, Data Quality и метрики, и расскажу, почему AI и агентный подход становятся главным драйвером новых требований к платформе.

В докладе я разберу практический подход к измерению производительности self-hosted LLM. 

Параллельное чтение из топиков Kafka, KRaft, серверная балансировка и tiered storage. Какие реальные проблемы разработчика это решает и почему в YDB мы сделали чуть по-другому.

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

Поговорим о том, какие важные функции необходимы для управления Iceberg таблиц и роли REST Catalog в этом. 

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

Доклад посвящен практической диагностике проблем производительности PostgreSQL для backend-разработчиков, которые самостоятельно поддерживают свои базы данных и не имеют выделенного DBA.

Доклад посвящен практическому опыту оптимизации инференса и ML-serving на базе GPUStack в production-среде корпоративного AI Portal. 

Разберем реальный опыт миграции витрин данных с монолитного решения на Greenplum 6 на стек Data Lakehouse, уделив внимание и тому, как сделать этот процесс наименее болезненным для пользователей. Вы узнаете, с какими неочевидными проблемами придется столкнуться и как выстроить процессы так, чтобы новая архитектура оказалась эффективнее legacy-решения, а не его менее производительной копией.

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

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

Как мы научились при помощи Python, K8s и S3 эффективно считать данные в облаках.

AI‑ассистент начинается просто: большая модель в vLLM, embeddings, reranker и RAG по документам. Потом приходят production‑нагрузки: длинные сессии, рост KV‑cache, очередь запросов, нестабильная задержка и желание докупить GPU.

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

Покажу, как считать память и KV‑cache, как решения inference‑слоя меняют профиль нагрузки, а затем перейдем к нашей реализации в Deckhouse: планировщик инференса заранее считает конфигурацию запуска модели, а GPU control plane исполняет этот план через DRA, MPS/MIG и scheduler extender.

Расскажу, как мы построили экосистему Magnit Data, где каталог, глоссарий, DQ-движок, дашборды и чат-бот работают как единый механизм.

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

Доклад посвящен практическому опыту построения Data Streaming Lakehouse для аналитики в near real-time с использованием стека MySQL, Flink, Paimon, HDFS и StarRocks. 

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

Хранилище под Trino уперлось в потолок производительности одного кластера Ceph — и мы стали размазывать каждую таблицу сразу по нескольким кластерам, а всю логику шардирования спрятали в HAProxy-сайдкары на compute-нодах, не добавив в архитектуру ни одного нового звена. Чтение ускорилось с 20 до 60–80 ГБ/с, latency GET — с минут до 1–2 секунд.

LLM-агенты уверенно галлюцинируют в бизнес-отчетах, а точность Text-to-SQL явно недостаточна для регуляторной и управленческой отчетности. Покажу, как семантический слой на базе MetricFlow поднимает точность до 90% и выше и как развернуть это решение в on-prem, чтобы вашим отчетам можно было доверять.

Массовые операции изменения данных (Bulk INSERT/UPDATE/DELETE) в ванильном PostgreSQL упираются в фундаментальное ограничение: движок не поддерживает нативное распараллеливание таких операций в рамках одного запроса. А стандартный обходной путь через разделение запросов на несколько независимых параллельных сессий на уровне приложения неизбежно разрушает ACID-гарантии СУБД.

В докладе расскажу, как мы реализовали атомарный коммит распределенных транзакций на уровне ядра PostgreSQL, построенный на базе переработки механизмов 2PC/XA, и покажу результаты его тестирования.

Расскажу про опыт внедрения и использования YTsaurus в Честном знаке.

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

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

Как Vectorless помогает справиться с проблемой потери иерархии данных.

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

В докладе я разберу кейс, возникший в процессе разработки ПО СХД TATLIN.UNIFIED: баг, который выглядел утечкой памяти, оказался неочевидной проблемой с фрагментацией.

Поговорим про тестирование, поиск и отладку проблем в высоконагруженном ПО, а также поддержку работы СХД с решениями сторонних вендоров.

Apache NiFi — это ETL-инструмент для автоматизации процессов сбора, агрегации и передачи данных. Он предоставляет удобный веб-интерфейс для настройки и мониторинга потоков данных. Интерфейс удобен для разработки у управления потоками, но непригоден для регулярного проведения ревью изменений потоков.

В докладе расскажу про внедрение процесса ревью и деплоя для потоков NiFi в команде с большим количеством разработчиков и где изменения в потоки вносятся несколько раз в день. Прокомментирую эволюцию нашего процесса от чистого NiFi до NiFi + NiFi Registry + GitLab. И подробно остановлюсь на функциональности, которая сделала ревью и деплой процессорных групп таким же удобным, как и ревью Java-кода процессоров.

В докладе покажем, как мы построили масштабируемую ML-платформу для обнаружения хакеров на основе открытых инструментов (Airflow, Trino, Iceberg, MLflow). 

Как в Uzum мы перевели команды от ручных договоренностей и разрозненных схем к data contracts как части delivery-процесса. На production-конвейере покажем, как один merge запускает validation, compatibility checks, генерацию ingestion, публикацию данных и обновление каталога, а также какие метрики, сопротивление команд и технические грабли встретились по пути.

Наш опыт построения Metric Store.