Об исследовании
Хранилище данных только на 10 % состоит из инструментов и вычислительных систем и на 90 % — из архитектуры решения, которую потребителю предстоит создать самому, используя предлагаемые средства.
Отечественные решения Data Lakehouse чаще всего строятся на основе объединения нескольких кастомизированных open-source продуктов. Поэтому главный вопрос исследования — какую ценность производители добавили к этим продуктам: насколько компоненты интегрированы в единое целое, насколько централизованы управление, мониторинг и информационная безопасность, насколько решение продумано как продукт, а не как набор дистрибутивов.
Отдельное внимание уделено «концептуальной целостности» — продуманности производителем сценариев использования продукта в реальной бизнес-среде. Для этого вендорам были предложены три варианта практического задания на создание корпоративного хранилища данных, а их архитектурные ответы вошли в отчёт.
Облачные и не облачные платформы сознательно объединены в рамках одного исследования. Решения сильно отличаются друг от друга, поэтому от рейтинга мы осознанно отказались.
- Практическое руководство по выбору решений для построения корпоративного хранилища на базе Data Lakehouse
- Источник информации о современных тенденциях и перспективах развития отрасли
- Основу для диалога с производителями при подготовке пилота
- Эволюция подхода: от Data Warehouse и Data Lake к архитектурному шаблону Data Lakehouse
- Компонентный состав каждого решения — от SQL-движка и оркестратора до каталога метаданных и S3
- Экспертные оценки по одиннадцати критериям «продуктовости»
- Архитектурные ответы вендоров на три варианта практического задания
Исследование в цифрах
Решения в исследовании
Десять отечественных платформ, облачных и устанавливаемых в инфраструктуре заказчика. По каждой в отчёте — компонентный состав, варианты поставки, архитектурный ответ на задание, сильные стороны и зоны развития.
Методика
Методика состоит из трёх частей: практическое задание, компонентный анализ и экспертная оценка. Первая проверяет, как производитель видит своё решение в деле; вторая фиксирует технический состав; третья оценивает «продуктовость».
Три варианта практического задания
Сеть из 40 магазинов, источники — интернет, 1С:Зарплата и управление персоналом, 1С:Управление торговлей, WMS. Около 220 Гб сырых данных в год, 840 Гб на пять лет. С хранилищем работают 20–25 аналитиков, уровень зрелости заказчика низкий, доступность 99,5 %.
Непрерывный цикл производства, до 8000 человек, выделенный ИТ-отдел из 26 человек. Источники — MES, SCADA и телеметрия IIoT, 1С:ERP, EAM. Около 71 Тб на пять лет, 50–60 аналитиков, доступность 99,7 %, контур КИИ по 187-ФЗ.
К источникам добавляются видеоданные с 500 камер — 21,6 Тб в сутки при коротком хранении. Всего около 455,5 Тб на пять лет. Собственный центр компетенции по данным из 20 специалистов, ИТ-отдел 46 человек, 110–130 пользователей хранилища.
Компонентный анализ
Технические показатели собирались у производителей и согласовывались с ними. Характеристики приведены в информационных целях и не несут оценочной функции — это консолидированный взгляд на архитектуру решения.
Оркестрация приложений, входит ли Kubernetes в поставку, Helm-чарты и операторы для K8s, рекомендованные дистрибутивы, варианты поставки — облако, инфраструктура заказчика, гибрид.
СУБД и SQL-движок, вычислитель, ETL/ELT, оркестратор, система управления таблицами, объектное (S3) хранилище и рекомендуемые S3, формат хранения данных.
Управление доступом и безопасностью, централизованное управление, мониторинг, система управления метаданными, резервное копирование, пользовательский интерфейс и среда разработки, интеграция с ИИ.
Реализованы ли open-source компоненты в виде собственных форков — от этого зависит, кто отвечает за обновления, исправление ошибок и техническую поддержку.
Документация, бесплатная лицензия, блог, комьюнити, опубликованная дорожная карта.
Регистрация в реестре российского ПО и сертификат ФСТЭК с неистёкшим сроком действия.
Одиннадцать критериев экспертной оценки
| Критерий | Что оценивается |
|---|---|
| Монолитность | Степень продуманности и интеграции в единое решение: инсталляция, управление, мониторинг, управление нагрузками, высокая доступность, контроль происхождения данных, сквозной аудит, общая модель информационной безопасности |
| Универсальность | Возможность реализовать «из коробки» различные сценарии работы с данными в рамках шаблона Data Lakehouse |
| Концептуальная целостность | Производитель демонстрирует продуманность сценариев использования, предлагает типовые модели для разных вариантов применения |
| Интегрированность с AI/ML | Наличие в составе платформы инструментов, основанных на AI/ML-технологиях |
| Безопасность | Единая модель авторизации и аутентификации во всех компонентах, централизованный RBAC во всех вариантах развёртывания |
| Управляемость | Единая консоль управления всеми компонентами, интеграция со средствами мониторинга, управление средствами оркестрации среды исполнения |
| Высокая доступность | Продуманная методика обеспечения высокой доступности компонентов и надёжности хранения данных, наличие описания методик в открытых источниках |
| Пластичность (K8s) | Использование возможностей Kubernetes для горизонтальной масштабируемости, высокой доступности и других аспектов работы решения |
| Интегрируемость | Возможности интеграции с внешними системами — в первую очередь собственные разработки производителя, не входящие в open-source |
| Интегрируемость с отечественными системами | Подтверждённые возможности интеграции с 1С, S3, контейнерными платформами, BI и другими российскими решениями |
| Открытость | Документация в открытом доступе, детальное описание решения и сценариев использования, комьюнити, блог, дорожная карта |
Каждый параметр оценивается как «высокая», «средняя» или «низкая» степень субъективной экспертной оценки.
Решения сильно отличаются друг от друга, поэтому от создания рейтинга мы осознанно отказались. Оценка продукта в целом не может складываться из суммы приведённых оценок — в них учтены не все необходимые параметры для сравнения. Оценки субъективны и основаны в большей степени на экспертных суждениях, чем на объективных данных, поскольку по части решений открытой информации и документации недостаточно.
На что смотреть при выборе
Многие проекты потерпели крах потому, что выбранное решение не могло реализовать то, что хотел получить потребитель, — и это было сложно сделать. Перед выбором системы должны быть сформулированы цели и основные процессы работы с данными.
Сначала — BigData ли ваши данные
Data Lakehouse оправдывает себя на обработке данных, характеризуемых этим составным понятием. Если ваши данные под него не попадают, имеет смысл рассмотреть другие архитектурные шаблоны.
| Свойство | О чём речь | Ориентир из отчёта |
|---|---|---|
| Объём Volume | Объём хранимой информации | Менее 10–30 Тб за три года — стоит рассмотреть другие шаблоны. Большими данными обычно считают от 100 Тб |
| Скорость Velocity | Необходимость обработки данных в реальном времени | При только пакетной обработке внимание смещается на другие свойства; при потоковой — стоит обсудить шаблон Streaming Lakehouse |
| Разнообразие Variety | Структурированные, полуструктурированные и неструктурированные данные | Архитектура актуальна, когда доля полу- и неструктурированных данных превышает 10 % от структурированных |
| Достоверность Veracity | Качество и надёжность данных | Гарантированность ACID, качество данных, прослеживаемость (Data Lineage), версионность, сквозной аудит |
| Ценность Value | Что именно даёт обработка этих данных | Ценность должна превышать стоимость хранения; хранение технической информации «на всякий случай» должно быть обосновано |
Чек-лист из отчёта
Потоковая запись в таблицы Iceberg работает, но системы потоковой обработки интенсивно пишут маленькие файлы: растут метаданные, падает производительность, разрастается потребление ёмкости. Этот способ загрузки нужно детально обсудить с производителем ещё на этапе проектирования.
Наличие нативных интерфейсов с управлением качеством данных и в идеале с интеграцией с семантическим слоем решения для 70–80 % ваших источников — реальный критерий выбора.
Интеграция компонентов, централизация управления, единая модель доступа, централизованная прослеживаемость данных и сквозной аудит. Отдельно — форма оформления open-source: собственный форк означает ответственность производителя за обновления и поддержку, поставка «as-is» перекладывает лицензионную чистоту на заказчика.
Хороший вариант тестирования работоспособности системы — и технологического стека, и производительности связок сервисов. Результаты можно экстраполировать на on-premise реализацию.
Почти все декларируют поддержку Kubernetes — стоит проверить, что под этим понимается и все ли компоненты интегрируются в эту среду как единое целое. Для современного продукта мало приложить Helm-чарты: нужны операторы для управления жизненным циклом приложений. Поставка в виде ПАК снимает с заказчика вопросы инсталляции.
Важно понимать, что производитель планирует делать в части производительности open-source движков и технических каталогов. Решение должно быть зарегистрировано в реестре российского ПО; для контуров ГИС, ИСПДн, АСУ ТП и ЗО КИИ актуален приказ ФСТЭК № 64 от 14.04.2023 о требованиях по безопасности информации к СУБД.
Куда движется рынок
Востребованность технологий подтверждается динамичностью отечественного рынка: за время подготовки исследования рынок успел измениться несколько раз.
Начиная с 2026 года Arenadata позиционирует Arenadata Hyperwave как продукт для построения хранилища на основе архитектурного шаблона Data Lakehouse.
В начале апреля 2026 года VK Tech анонсировала приобретение компании «Кверифай Лабс» — линейки продуктов CedrusData. Качественный форк Trino и Iceberg REST-каталог станут доступны в VK Data Platform.
В апреле 2026 года DIS group анонсировала замену СУБД StarRocks с открытым исходным кодом на коммерческую версию StarRocks Enterprise в основе «Платформы данных Селена»: Multi-Warehouse, SSO через SAML/OIDC, маскирование на уровне строк и колонок, прозрачное шифрование на диске с интеграцией в KMS, полноценный аудит действий пользователей.
Анонсирован продукт «Селена Моделирование» — инструмент моделирования данных на физическом, логическом и концептуальном уровнях с прямой связью с Data Governance и каталогом: после построения модели инструмент сам генерирует схему хранения и пайплайны для её наполнения.
Серверное и сетевое оборудование в отдельном шкафу, системное ПО, предварительно настроенная платформа и средства управления комплексом. Такой подход ускоряет развёртывание, снижает расходы на администрирование и масштабируется добавлением нового ПАКа.
Рынок хранилищ данных на основе Data Lakehouse в стране есть. В ответ на потребность рынка отечественные производители предлагают специализированные продукты, которые отличаются друг от друга и технически, и методологически. Количество предложений уже обеспечивает возможность сравнения и выбора.