Представим знакомую многим ситуацию пиковой нагрузки в конце квартала. Финансовый директор требует отчет по маржинальности в разрезе каждой единицы складского учета. Отдел маркетинга запускает промо-кампанию и запрашивает данные для сегментации. Три команды дата-сайентистов параллельно обучают прогнозные модели спроса к Черной пятнице. А в это время аналитическая система, купленная несколько лет назад за десятки миллионов, начинает сбоить. Запросы встают в очередь, дашборды не грузятся, а бизнес-команды вместо принятия решений ждут ответа системы.
Для ритейла подобная ситуация – это не частный ИТ-сбой, а архитектурная проблема. Данные давно перестали использоваться только для учетных функций, превратившись в один из ключевых факторов, влияющих на операционные процессы. Особенно остро это чувствуется, когда бизнес начинает внедрять ИИ: оказывается, что внутренняя ИТ-инфраструктура просто не рассчитана на такие нагрузки. Как решать эти проблемы системно и есть ли для этого готовый ответ, – расскажем подробнее в материале.
Конец эпохи «тяжелых» DWH: почему старые решения уже не справляются
Рынок розничной торговли растет и меняется, а вместе с ним меняются и нагрузки на платформы данных. По данным Росстата, оборот российской розницы вырос и превысил 61 трлн ₽ в 2025 году, а значит, в ритейле становится больше клиентских взаимодействий, транзакций, событий и данных. Для многих классических хранилищ данных (DWH) и аналитических платформ рост нагрузок усложняет архитектуру, повышает стоимость эксплуатации и увеличивает конкуренцию за ресурсы. Но главный вызов сегодня связан не только с ростом объемов данных, но и с появлением ИИ-нагрузок, которые ведут себя иначе, чем классическая аналитика. Они более итеративны, параллельны и менее предсказуемы.
Если рассматривать ситуацию более подробно, то ритейл сегодня можно охарактеризовать следующим образом:
• Увеличивается количество аналитиков и команд, которым нужны данные.
• Расширяется набор источников данных: от онлайн-касс и мобильных приложений до CRM-систем, логистики и e-commerce-каналов.
• Одновременно растет число ИИ-моделей, которым нужны актуальные данные для обучения, прогнозирования и автоматизации.
В результате традиционные системы превращаются в «бутылочное горлышко», где аналитики конкурируют за ресурсы с BI-системами, а те, в свою очередь, с моделями машинного обучения. В пиковые моменты сотрудники тратят время не на анализ и принятие решений, а на ожидание ответа от системы.
Именно поэтому при разработке собственной платформы аналитики в Postgres Professional были взяты за основу архитектурные принципы хорошо зарекомендовавших себя современных платформ, таких как Snowflake и Databricks. При этом задачей стало не просто воспроизвести эти идеи, а адаптировать их под нюансы российского ИТ-ландшафта. Акцент был сделан на соответствие стандартам безопасности и на совместимость с локальной ИТ-инфраструктурой.
Что же под капотом?
В первую очередь, был перенят один из ключевых принципов Snowflake — вычисления и хранение живут отдельно. Это позволяет независимо масштабировать работу с данными. Например, если необходимо обработать большой объем прямо сейчас, можно временно увеличить вычислительные ресурсы, не затрагивая слой хранения данных.
У Databricks была взята идея, что данные должны быть доступны для решения разнообразных задач — для отчетов, для ad-hoc запросов, для обучения моделей. Это снижает количество копий, уменьшает расхождение между контурами и позволяет работать с одними и теми же актуальными данными. Особенно это критично для ИИ-моделей, где качество модели напрямую зависит от того, насколько она опирается на актуальные и согласованные данные.
Но было важно не скопировать, а понять, как это будет работать на российском рынке. И вот к чему было сделано несколько выводов:
— Первое. Когда компания хранит данные в проприетарном формате, она попадает в зависимость от вендора. Планируешь перейти на другой инструмент — перегоняй петабайты, переписывай интеграции, теряй время и деньги. Мы сознательно не хотим, чтобы наши заказчики попадали в такую ситуацию.
Кроме того, Iceberg – один из ключевых открытых стандартов для аналитических таблиц, который поддерживается многими движками: Spark, Trino, Flink, Hive, Snowflake, Databricks. Если компания работает с Iceberg, она не привязана к конкретному вендору, и данные остаются доступными, понятными, переносимыми. Для ИИ-команд это важно: они могут использовать любые инструменты, не оглядываясь на то, «а поддерживает ли наша платформа этот фреймворк».
— Второе. Один из основных вопросов – это совместимость с российским прикладным софтом. Это критично сегодня в условиях общего сокращения бюджетов на ИТ. Для работы с Tengri Data не нужно перестраивать ИТ-инфраструктуру, так как она работает на Astra Linux и Linux Debian, которые уже инсталлированы во многих крупных компаниях.
— Третье. Соответствие регуляторным требованиям и возросшим ИБ-рискам. Крупные игроки рынка хранят терабайты персональных данных, поэтому важно было продумать логику безопасности на уровне архитектуры самой платформы. В частности, при увольнении сотрудника доступ отзывается мгновенно по всему контуру. Это закрывает самый частый сценарий утечек.
Data Mesh: как поделить данные между командами без войн
Внедрение ИИ в ритейле порождает не только техническую, но и организационную проблему. Данные нужны всем: команде закупок, маркетингу, разработчикам рекомендательных систем, специалистам по динамическому ценообразованию и многим другим. В результате каждый тянет одеяло на себя.
В Tengri Data это решается не принуждением, а архитектурой. Каждая команда получает собственный вычислительный пул, а также свои ресурсы и политики доступа. Данные при этом физически могут лежать в одном месте, но логически они принадлежат конкретной команде. Если маркетинг хочет данные закупок, он их получает через публичный слой, но нагрузка ложится на маркетинговый вычислительный ресурс (compute), а не на закупочный.
Так, когда дата-сайентисты запускают тяжелый эксперимент, он не нарушает отказоустойчивость продакшен-аналитики, от которой зависят отчеты для ФНС и платежи поставщикам. Эксперименты идут в изолированном контуре, но на тех же данных.
ИИ-агенты и скорость: почему цифровые ассистенты не взлетают
Отдельно стоит поговорить и про ИИ-агентов. Крупный бизнес все чаще рассматривает возможность их внедрения в свой инфраструктурный контур, чтобы сократить количество рутинной нагрузки и ускорить выполнение типовых аналитических задач. На практике многие ритейлеры сталкиваются с тем, что такие ассистенты работают медленно, и в конечном счете пользователи не работают с ними. Даже сильная модель не решает проблему, если данные или вычислительные ресурсы недоступны вовремя: при высокой задержке аналитик просто возвращается к привычному SQL.
В Tengri Data реализованы два принципа:
— Первое – это эластичный пул. Иными словами, вычислительные мощности не закреплены за конкретной задачей, а находятся в общем «резервуаре» и автоматически выделяются по запросу. Когда запросов в системе много, то свободные мощности динамически перераспределяются с тех задач, которые сейчас неактивны.
В традиционной архитектуре ИИ-агенты либо простаивали бы в очереди к занятым серверам, либо для них нужно было бы содержать отдельные мощности, которые большую часть времени простаивают. Это экономически невыгодно.
— Второе – изоляция. Как уже было сказано, в традиционной архитектуре все задачи конкурируют за одни и те же ресурсы, особенно когда они работают в рамках единого контура и пула ресурсов. Тяжелые фоновые процессы (ETL) могут исчерпать все доступные ресурсы, не давая возможности ИИ-агентам решать поставленные задачи.
В Tengri Data у разных типов задач существуют свои изолированные вычислительные пулы. ETL-процессы идут в одном пуле, агенты отвечают на вопросы в другом. Даже если фоновая загрузка полностью поглощает все ресурсы выделенные для нее, на скорость ответа агента это не влияет. В результате агент работает быстро, и, как следствие, специалисты тратят меньше времени на ожидание, а больше на работу с данными.
Вместо вывода
Сегодня важно смотреть не только на практическую применимость ИТ-решений, но и на измеряемый бизнес-эффект. Поэтому Tengri Data решает три конкретные проблемы, с которыми ритейлеры приходят к нам последние пару лет:
1. Как не «уронить» аналитику, когда дата-сайентисты экспериментируют. Изоляция нагрузок и эластичное масштабирование позволяют ИИ-командам работать, не мешая продакшену.
2. Как поделить данные между командами без войн. Data Mesh на практике, а не в теории: каждый получает доступ к данным, но не мешает соседям.
3. Как сделать так, чтобы ИИ-агенты реально работали на пользу бизнеса. Скорость доступа к данным и отсутствие конкуренции за ресурсы превращают «медленных ботов» в полезных ассистентов.
Именно эти вопросы станут предметом обсуждения на секции #Prodata Day на Российском Ритейл Шоу 2026, где Postgres Professional выступит генеральным партнером секции. Форум пройдет 21–23 апреля. Сама секция, посвященная большим данным, аналитике и новой ценности данных для бизнеса, состоится 22 апреля. На протяжении всего форума обсудить архитектурные принципы, сценарии, ограничения и рабочие подходы, а также договориться о демо доступе к Tengri Data или обсудить пилот под ваши сценарии можно будет на стенде компании Postgres Professional (на первом этаже).
___
Российское Ритейл Шоу/Russian Retail Show и Выставка Ритейл ТЕХ Экспо/Retail TECH Expo (21–23 апреля 2026 года) — главное мероприятие о трансформации отрасли розничной торговли. Российские и международные тренды, дискуссии на ключевые темы отрасли, кейсы, бизнес-практики и инновации:
