YTsaurus Flow: когда магазину нужны данные сразу, а не по ночам

Что открыл Яндекс

По пресс-релизу Яндекса от 6 октября 2026, YTsaurus Flow это технология непрерывной обработки больших потоков данных в реальном времени. Её сделали вместе команды инфраструктуры и Яндекс Рекламы. Лицензия Apache 2.0, коммерческое использование разрешено. Код лежит в репозитории ytsaurus/ytsaurus, это часть открытой платформы YTsaurus для больших данных.

Главное обещание: режим exactly-once. Каждое событие (клик, показ, заказ) учитывается один раз, даже если сервер упал посреди обработки. Яндекс пишет, что в Рекламе Flow тянет больше 100 ГБ данных в секунду и миллионы событий. Подготовка данных для дообучения моделей там сократилась с более чем 10 часов, но конечную цифру источники называют по-разному, поэтому я её не привожу. Flow используют также Маркет (статистика для продавцов) и антифрод.

В документации указано, что типичная задержка обработки составляет от секунды до десяти секунд. Бизнес-логику пишут на C++, Java, Kotlin, Python или Go, есть и декларативный язык YQL. Состояние хранится в динамических таблицах YTsaurus.

Поток против пакета на примере магазина

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

Потоковая схема другая. Каждый заказ, оплата и отмена это событие. Событие сразу попадает в обработчик, а он обновляет остаток, счётчик продаж и, например, отправляет сообщение менеджеру. Данные отстают на секунды.

Разница в цене. Ночной отчёт это один запрос и cron. Поток это постоянно работающая система, которую надо мониторить, обновлять и чинить в три часа ночи. Ценность появляется, когда задержка в сутки стоит денег.

Когда потоковая обработка действительно нужна

Есть задачи, где ночной отчёт не подходит по смыслу:

Антифрод платежей. Подозрительную оплату надо остановить до отгрузки, пока товар ещё на складе.

Живые остатки. Когда один товар продаётся на сайте, в маркетплейсах и в рознице одновременно, задержка в час уже даёт перепродажу.

Рекомендации здесь и сейчас. Подборка «с этим берут» по действиям покупателя в текущей сессии. Как строить её при малом числе данных, я разбирал в статье про рекомендации без истории покупок.

Уведомления по событиям. Бросил корзину, оплата не прошла, курьер опаздывает.

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

Где Flow не нужен и что важно учесть

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

По Flow я нашёл вот что. Подтверждено: лицензия, назначение, рабочая нагрузка внутри Яндекса, поддержка нескольких языков. Релиз Flow 0.3.0 указан на странице релизов GitHub как первый официальный, дату я не подтверждал. Документация сама пишет, что Flow в активной разработке, а YQL-часть ещё не завершена. Продакшен-процессы на нём построили больше десяти команд, это опыт самого Яндекса, у обычных компаний картина может быть другой.

Не нашёл: готовых требований к железу для боевого кластера, отзывов внешних внедрений и цен на сопровождение. Для знакомства есть локальный запуск в Docker и в Kubernetes (Minikube или Kind) с минимумом 4 ядра, 8 ГБ памяти и 30 ГБ диска, но это стенд для пробы платформы, на боевую нагрузку он не рассчитан. Flow работает внутри YTsaurus, то есть вам придётся поднимать и вести кластер платформы целиком.

Ещё одна оговорка про exactly-once. Гарантия касается обработки внутри системы. Если ваш склад, платёжный шлюз или CRM принимают данные с повторами, дубль может появиться на границе. Для этого в простых схемах используют идемпотентность: у каждого события свой номер, повторная запись с тем же номером игнорируется.

Что можно сделать уже сейчас

Посчитать цену задержки. Выпишите, какие данные вам нужны быстрее, чем раз в сутки, и сколько стоит каждый час опоздания. Если ответ «ничего не стоит», вам нужен ночной отчёт. Собрать его в понятном виде можно на Metabase.

Начать с вебхуков и счётчика в Redis. Живой счётчик заказов или остатка делается за считанные дни. Вторая ступень: очередь для событий, чтобы сбой одного сервиса не терял заказы.

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

Подключить ИИ к живым данным. Агент, который отвечает по свежей базе, работает лучше, чем по выгрузке недельной давности. Про доступ ассистента к базе написано в статье про MCP Toolbox, про ответы по документам в материале о RAG-системах для бизнеса.

Заранее разметить рост. Договоритесь, при каком числе событий вы вернётесь к вопросу распределённой обработки. Тогда переход пройдёт по плану, без аврала.

Что спросить у исполнителя до выбора технологии

Задайте пять вопросов. Сколько событий в секунду вы ждёте сейчас и через год. Что произойдёт с бизнесом, если событие потеряется или посчитается дважды. Почему не подойдёт PostgreSQL с очередью. Кто будет обслуживать систему после запуска и сколько это стоит в месяц. Как мы откатимся к простой схеме, если выбранная окажется лишней.

Если исполнитель сразу называет модное название и не спрашивает про ваши объёмы, это повод насторожиться. Подбор архитектуры под нагрузку входит в работу с данными и аналитикой, и первая встреча обычно сводится к этим вопросам. Статья не заменяет технический аудит вашей системы.

Частые вопросы

Можно ли поставить YTsaurus Flow малому бизнесу?

Технически код открыт, лицензия Apache 2.0 это позволяет. Практически вам придётся вести целый кластер YTsaurus, а нагрузка магазина с парой заказов в минуту этого не оправдывает.

Что такое exactly-once простыми словами?

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

Чем поток отличается от обычного отчёта?

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

Коротко о главном

Flow открыт, лицензия свободная, внутри Яндекса на нём работают рекламные, маркетные и антифрод-системы. Для малого и среднего бизнеса это опыт для чтения, а рабочая схема выглядит проще: очередь, вебхуки, PostgreSQL, Redis и понятные дашборды. Поток стоит подключать, когда задержка в данных измеряется деньгами.

Если хотите понять, что нужно вашему магазину, пересказать нагрузку и выбрать схему без лишних серверов, напишите мне в Telegram кодовое слово «СОБЫТИЯ», разберём ваши цифры и скажу, хватит ли обычной базы.