CNews: После волны импортозамещения многие компании обнаружили, что заменить зарубежную СУБД на отечественную — лишь часть задачи. От чего зависит, станет ли миграция просто заменой технологии или даст бизнесу что-то новое?

Павел Бабурин: Все решает мотивация: зачем компании вообще нужна миграция.

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

Совсем другая ситуация, когда компания решает мигрировать не из-за внешних обстоятельств, а потому, что существующая платформа перестала отвечать ее задачам. Например, бизнес уперся в технологические ограничения, хочет быстрее развивать сервисы, эффективнее работать с данными, повысить скорость принятия решений. Такая мотивация гораздо интереснее, потому что речь идет уже не о вынужденной замене технологии, а о развитии.

В этом случае момент перехода стоит использовать, чтобы пересмотреть архитектуру и получить то, чего у старой системы не было: независимое масштабирование хранения и вычислений, работу с данными в реальном времени, подключение ИИ-агентов к корпоративным данным. Заодно это шанс не перенести на новую платформу старые проблемы. Это другой объем работ и другие инвестиции.

Именно такие проекты обычно получают поддержку бизнеса: если миграция открывает новые возможности, у компании появляется мотивация в нее инвестировать.

CNews: От чего зависят срок и стоимость миграции?

Павел Бабурин: Прежде всего — от объема и характера накопленного кода, числа систем, которые работают с хранилищем, и от цели проекта: перенос «как есть» или перестройка архитектуры. Больше всего времени обычно уходит не на перенос данных, а на бизнес-логику, зашитую в хранимые процедуры, и на перенастройку приложений-потребителей.

Именно эти работы сейчас активнее всего автоматизируются: появляются решения, которые преобразуют код и помогают переносить системы между платформами. Часть задачи мы снимаем на уровне самой платформы. В последнем релизе Data Ocean Nova движок StarRocks получил поддержку сетевого протокола PostgreSQL: приложения, которые работали с PostgreSQL или Greenplum, переключаются на платформу без переработки.

Поэтому миграция постепенно становится менее трудоемкой, и ее конечная стоимость снижается. На стоимость владения после переезда влияет и то, где хранятся данные. В гибридном режиме Nova StarRocks горячие данные остаются на локальных дисках, а редко используемые переезжают в объектное хранилище в открытом формате Iceberg, и для каждого слоя задается свой алгоритм сжатия. При этом гибридная конфигурация возможна в одной инсталляции Nova StarRocks.

CNews: Что сегодня считается легаси (наследием) в ИТ-архитектуре?

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

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

CNews: Что приходит на смену легаси-подходам? Почему все чаще говорят не о СУБД, а о платформе данных?

Павел Бабурин: Раньше системы строились как монолиты. Сегодня архитектура становится модульной. Платформа должна напоминать конструктор: отдельные компоненты можно добавлять, заменять или развивать независимо друг от друга. Это делает систему гораздо более гибкой и позволяет ей эволюционировать без масштабных и дорогостоящих переделок.

Если раньше в центре архитектуры была СУБД, то сегодня этого уже недостаточно. Бизнесу нужны интеграция данных, каталог, средства контроля качества, аналитика, инструменты разработки, ИИ-помощники. Поэтому правильнее говорить уже о платформе данных — единой среде, которая объединяет все необходимые функции и избавляет пользователя от необходимости самостоятельно интегрировать десятки отдельных продуктов.

CNews: Как Data Sapience развивает платформу данных Data Ocean?

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

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

Любая система в какой-то момент оказывается в рамках определенных ограничений. Например, архитектуры массовой параллельной обработки (MPP) прошлого поколения во многих компаниях остаются рабочим решением, которое позволяет закрывать текущие задачи. Но при росте объемов данных и числа сценариев они упираются в ограничения масштабирования и стоимости владения.

Ровно для таких сценариев мы развиваем в платформе преемственность с легаси-системами. Например, процедурное расширение LPSQL позволяет перенести хранимые процедуры, чтобы бизнес-логика работала как раньше, но на новом движке и с возможностью масштабирования. LPSQL работает в движках Impala и StarRocks.

CNews: В таком случае, за какими подходами будущее?

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

Сегодня такой подход часто называют облачно-ориентированной архитектурой. При этом речь не обязательно идет только об облаках: такая модель может работать и в облачной среде, и во внутренней инфраструктуре клиента, и в гибридном варианте. Так устроена и платформа Data Ocean.

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

Один из ключевых принципов — разделение хранения и вычислений, а также использование открытых форматов данных. Открытый формат — это своего рода универсальный «переходник»: разные инструменты могут работать с одними и теми же данными, не завязываясь на конкретную технологию.

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

Поэтому в Lakehouse-платформе Data Ocean Nova мы поддерживаем четыре движка обработки данных — Spark, Trino, Impala и StarRocks, — чтобы не зависеть от развития одного решения. При этом задача вендора — превратить open-source компоненты (с открытым исходным кодом) в полноценный продукт: обеспечить надежность, поддержку, удобство эксплуатации и закрыть те задачи, которые обычно остаются за пределами открытых решений.

CNews: Платформа строится на открытых компонентах. Что будет с заказчиком, если проект сменит лицензию или перестанет развиваться?

Павел Бабурин: Это реальный риск, мы его не отрицаем и к нему готовы. За последние годы рынок несколько раз видел, как популярные проекты меняют лицензию: так было с Elasticsearch, Redis, Terraform. Но в каждом из этих случаев сообщество быстро выпускало форк под открытой лицензией: OpenSearch, Valkey и другие. Последняя открытая версия при этом никуда не исчезает. Поэтому для нас вопрос не в том, случится ли такое, а в том, насколько заказчик от этого защищен.

Защиту мы строим на трех уровнях.

Первый уровень — контроль над кодом. Мы не просто берем готовые дистрибутивы. Мы собираем компоненты из исходников, фиксируем проверенные версии и сами выпускаем исправления, включая исправления безопасности. Если исходный проект сообщества (upstream) закроется или замедлится, заказчик этого не почувствует: сопровождение версии, которая работает у него в контуре, остается на нас.

Второй уровень — архитектура. Компоненты связаны между собой через открытые форматы и стандартные интерфейсы, а не через внутренние особенности конкретного продукта. Данные хранятся в открытых форматах, доступ к ним идет через стандартный SQL и программные интерфейсы приложений (API). Поэтому любой отдельный компонент можно заменить на альтернативу. Миграцию берем на себя мы, а не заказчик, и его данные и прикладные решения при этом остаются на месте.

Третий уровень — экспертиза команды. Мы постоянно следим за состоянием сообществ, за лицензионной политикой и активностью разработки ключевых проектов. Решение о замене компонента принимается заранее, а не в момент кризиса.

Кроме того, мы не только сопровождаем открытый код, но и существенно развиваем его сами. Заметная часть возможностей Data Ocean Nova — собственная разработка Data Sapience, которой нет в открытом коде (open source): от платформенных сервисов вроде процедурного расширения LPSQL и уникальных функциональных возможностей StarRocks до нативных вычислений в Trino на полностью переработанном нами фреймворке Velox. Поэтому смену лицензии или остановку проекта мы воспринимаем как инженерную задачу, с которой команда уже умеет работать, независимо от сообщества или приоритетов основных контрибьюторов.

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

CNews: Не проще ли вендору предложить заказчику привычную архитектуру, которая быстро закроет задачу импортозамещения?

Павел Бабурин: Есть такое понятие — «низко висящий фрукт»: когда можно получить быстрый результат здесь и сейчас. Например, есть компании, которые не успели вовремя решить вопрос импортозамещения и сейчас находятся в ситуации, когда им нужно срочно закрыть задачу. В таком случае можно предложить им простое решение — внедрить привычную архитектуру, которая позволит быстро решить насущные проблемы.

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

Поэтому мы в Data Sapience пошли другим путем. Мы развиваем более доступный вариант платформы, который позволяет компаниям начать переход к новой Lakehouse-архитектуре с помощью Data Ocean Nova без больших первоначальных затрат.

CNews: Для каких объемов данных подходит такой вариант, и как его потом развивать?

Павел Бабурин: Раньше считалось, что архитектуры класса Lakehouse — а именно к ним относится новое поколение платформ данных и Data Ocean Nova — имеют высокий порог входа и оправданы в основном для крупных проектов с десятками терабайт данных. Из-за этого многие компании с меньшими объемами просто оставались за рамками такого подхода.

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

Если через несколько лет компания вырастет и поймет, что ей нужны дополнительные возможности, не придется начинать все заново. Можно постепенно добавить новые компоненты — например, еще один вычислительный движок или объектное хранилище — и развивать платформу дальше без радикальной перестройки уже работающей системы.

CNews: В каких направлениях планируете развивать платформу Data Ocean в ближайшее время?

Павел Бабурин: Не буду раскрывать все карты. Но одним из главных направлений станет расширение интеграционных возможностей.

Если посмотреть на развитие современных цифровых сервисов, то они движутся в сторону экосистем и супераппов (суперприложений). Пользователь работает в привычном интерфейсе, а внутри постепенно появляются новые функции и сервисы. Нам близка эта логика.

Наша задача — сократить количество переключений между разными окнами, модулями и интерфейсами. Пользователь должен работать с платформой как с единым решением.

Первый шаг мы уже сделали в Data Ocean Platform UI. В обновленном модуле Explore аналитик в одном окне пишет SQL-запросы, работает с ноутбуками, собирает процесс обработки и ставит его на расписание. Раньше для этого требовалось три-четыре отдельных инструмента.

Мы продолжаем развивать управление качеством данных, каталог и бизнес-глоссарий, Data Lineage (происхождение данных), интеграционные инструменты и другие компоненты в платформе Data Ocean Governance. Но многие из этих возможностей настолько тесно связаны между собой, что для клиента уже не имеет большого значения, сколько отдельных продуктов стоит за ними. Гораздо важнее получить цельный пользовательский опыт.

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

Еще одна важная часть интеграционной истории — ИИ-агенты. В последнем релизе Data Ocean Nova появился сервер протокола контекста модели (Model Context Protocol, MCP): агенты на основе больших языковых моделей (LLM) подключаются к платформе по стандартному протоколу, получают доступ к данным и метаданным и выполняют запросы на чтение в StarRocks, Impala и Trino с теми же правами, которые пользователю выданы в платформе. Раньше для этого командам приходилось писать собственный коннектор к каждому движку и отдельно настраивать доступ. ИИ-ассистент уже является частью интерфейса Explore, в котором пользователь может исследовать данные в диалоговом режиме.

Следующий шаг — поддержка протокола контекста модели не только у вычислительных движков. MCP-интерфейс в следующем релизе получат все внутренние сервисы платформы, и уже администратор через агента сможет работать с платформой целиком, так же как сегодня с ней работает пользователь.

CNews: Где можно будет подробнее узнать о дальнейших планах развития платформы?

Павел Бабурин: 18 ноября в Москве мы проводим Data Sapience Data Day 2026 — ежегодную конференцию, посвященную данным. Расскажем о готовности платформы к ИИ-задачам и о планах ее развития. Но главное на конференции — практика заказчиков. Клиенты из разных отраслей поделятся опытом миграции хранилищ на Data Ocean Nova, в том числе с помощью ИИ, и замены зарубежных DWH и BI продуктами Data Sapience. А в демозоне мы покажем, как ИИ работает в наших продуктах.

CNews: А если говорить об ожиданиях заказчиков, какие тенденции вы могли бы выделить?

Павел Бабурин: Подход компаний к выбору платформ данных заметно изменился. Если еще недавно многие активно смотрели в сторону облачных решений, то сегодня на первый план снова выходит вопрос устойчивости и управления рисками.

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

При этом заказчики хотят, чтобы переход на новую архитектуру был максимально простым. Никто не стремится запускать многолетние проекты миграции или полностью перестраивать ИТ-ландшафт. Наоборот, запрос сегодня — на быстрое развертывание, готовые инструменты миграции и минимальные требования к компетенциям команды.

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

CNews: Получается, курс на упрощение работы с платформами сохранится независимо от изменений на рынке?

Павел Бабурин: Думаю, да. Эта тенденция сохранится. Платформа данных сама по себе не является конечной ценностью для бизнеса. Она лишь фундамент. Настоящая задача — как можно быстрее довести данные до человека, который принимает решения.

Именно поэтому сейчас сокращается весь путь от данных до результата. Раньше информация проходила через множество этапов: платформу данных, отдельную BI-систему (Business Intelligence — систему бизнес-аналитики), настройку отчетов, визуализацию. Сегодня благодаря ИИ-агентам значительную часть этих операций можно автоматизировать.

Мы уже видим примеры, когда клиенту не нужно отдельное решение для бизнес-аналитики. Он может обратиться к платформе на естественном языке, а она сама найдет нужные данные, построит график и ответит на вопрос или даже сформирует готовый отчет или презентацию с выводами и рекомендациями к дальнейшим действиям. В Data Ocean Nova так работает встроенный ИИ-ассистент через тот же сервер протокола контекста модели. Именно в этом мы в команде Data Sapience видим дальнейшее развитие платформ данных.