Об исследовании
Специфика исследования — рассмотрение DWH через призму СУБД, на основе которой строится решение. Мы разбираем, как отечественные производители видят своё решение в парадигме корпоративного хранилища данных.
В отличие от рынка построения DWH на основе архитектурных шаблонов Data Lake и Data Lakehouse, на отечественном рынке практически отсутствуют законченные решения, основанные на архитектуре классического DWH в виде единого продукта. Эта специфика и определила направленность исследования на СУБД в контексте применения в рамках создания DWH.
Помимо рынка отечественных СУБД, отчёт даёт системное и технически точное изложение эволюции архитектур аналитических хранилищ — от первых попыток организовать запросы к продуктивным транзакционным базам данных до современных концепций классических DWH, Data Mesh и Data Fabric.
- Архитекторов, инженеров и системных аналитиков
- CDO и руководителей центров компетенций по данным
- Специалистов, участвующих в проектировании, сопровождении и развитии аналитических платформ
- Методическое руководство при выборе архитектуры и построении аналитического хранилища на основе отечественных решений
- Инструмент оценки зрелости существующих решений
- База для диалога между бизнесом и техническими специалистами
- Аналитический справочник по возможностям современных СУБД и архитектурных паттернов
Исследование в цифрах
Два сегмента рынка
В контексте исследования мы разделили СУБД на два сегмента — по способу наращивания производительности и по роли, которую продукт играет в архитектуре хранилища.
«Классические» СУБД — 13 продуктов
Решения, ориентированные на вертикальное масштабирование и гибридные (HTAP) нагрузки. Горизонтальное масштабирование реализуется за счёт специализированных надстроек: репликации, read-only-реплик, резервного кластера, ручного шардирования.
202 критерия: 50 функциональных, 96 технических, 56 бизнес-критериев.
«MPP» СУБД — 10 продуктов
Решения, поддерживающие горизонтальное масштабирование «из коробки». Аналитический запрос автоматически декомпозируется на фрагменты и параллельно исполняется на нескольких узлах с централизованной или распределённой координацией.
175 критериев: 55 функциональных, 87 технических, 33 бизнес-критерия.
Сравнение «базовых» СУБД
Отечественные разработки чаще всего наследуют характеристики «базовых» СУБД, получая «обогащение» функционала за счёт собственных доработок или дополнительных open-source модулей. Поэтому исследование начинается со сравнения ванильных версий по 122 критериям — это материал, от которого можно отталкиваться при выборе платформы.
Greenplum 6.27
Основное назначение в КХД: классическое корпоративное хранилище (EDW).
Ключевые преимущества: MPP-архитектура для петабайтных данных, зрелое решение, стандартный SQL.
Ключевые ограничения: устаревание технологической базы, закрытие open-source проекта.
ClickHouse 25.8
Основное назначение в КХД: аналитические витрины (Data Marts), слой быстрой аналитики, векторный поиск.
Ключевые преимущества: экстремальная скорость аналитических запросов, колоночное хранение, эффективное сжатие.
Ключевые ограничения: инструмент для аналитики, а не для построения всего корпоративного хранилища.
StarRocks 3.5
Основное назначение в КХД: универсальная аналитическая платформа (OLAP, near real-time OLAP).
Ключевые преимущества: высокая производительность, поддержка реального времени, гибкость архитектуры, инновационный ИТ-стек.
Ключевые ограничения: молодой продукт, экосистема ещё не развита.
PostgreSQL 18
Основное назначение в КХД: поддержка гибридных (HTAP) нагрузок, универсальная платформа для малых и средних DWH.
Ключевые преимущества: надёжность, ACID, расширяемость, зрелая экосистема, активное развитие, уникально широкая экосистема расширений.
Ключевые ограничения: ограниченная горизонтальная масштабируемость для больших данных.
YDB 25.3
Основное назначение в КХД: универсальная платформа для гибридных нагрузок в среде продуктов Яндекс.
Ключевые преимущества: единая платформа для транзакций и аналитики, разделение хранения и вычислений, поддержка Kafka-фреймворков, колоночное хранение.
Ключевые ограничения: молодой продукт, экосистема преимущественно развивается внутри продуктов Яндекс.
В отчёте сравнение развёрнуто по 122 критериям: типы нагрузок, интеграция с Kubernetes, соответствие стандартам SQL, производительность и оптимизатор, аналитические конструкции, интеграция в Data Lakehouse, ETL, ILM, Data Science, BI, безопасность, резервное копирование, высокая доступность, архитектурные паттерны DWH и потоковые сценарии.
Методика
Формирование критериев
Перечень формируется и актуализируется на основе открытых стандартов, опыта эксплуатации и требований крупных заказчиков, включая государственные и финансовые организации.
Анкетирование вендоров
Критерии направляются производителям: разработчик обладает наиболее полной информацией о внутренней архитектуре, ограничениях и реальных сценариях. Ответы предоставляются в формализованном виде со ссылками на подтверждающие материалы.
Аналитическая проверка
Данные сопоставляются с официальной документацией, демонстрационными стендами и открытыми источниками, а при наличии технического доступа — с развёрнутым тестовым экземпляром.
Структурированное описание
Если вендор не участвует в исследовании или предоставляет информацию не в полном объёме, описание формируется по открытым данным с указанием ограничений по глубине и достоверности.