Data Warehouse 2026: ClickHouse, Snowflake, BigQuery, отечественные

Data Warehouse в 2026 году — это уже не «большая база для отчетов», а центральный слой аналитической архитектуры: от BI и финансового планирования до продуктовых метрик, ML-фичей и аудита. В этом гайде сравниваем ClickHouse, Snowflake, BigQuery, Redshift, Greenplum, Arenadata и lakehouse-подход без религиозных войн: где быстро, где дорого, где удобно, а где придется платить инженерами.

Что такое Data Warehouse в 2026 и зачем оно бизнесу

Не база данных, а контракт между бизнесом и данными

Data Warehouse — это аналитическое хранилище, куда регулярно попадают данные из продуктовых систем, CRM, ERP, биллинга, маркетинга, логов и внешних источников. Его задача — не обслуживать транзакции пользователя в приложении, а отвечать на вопросы бизнеса: сколько заработали, где теряем клиентов, какой канал окупается, почему выросла нагрузка, какие сегменты покупают чаще.

В 2026 году хорошее хранилище данных обычно работает с десятками или сотнями источников, хранит от сотен гигабайт до петабайт, поддерживает SQL, роли доступа, версионирование схем, интеграции с BI и пайплайнами. Для среднего бизнеса это может быть 2-20 ТБ данных и 20-200 активных пользователей аналитики. Для банка, телекома или маркетплейса — 200 ТБ, 2 ПБ и больше, плюс сотни ETL-задач в сутки.

Почему Excel и реплики PostgreSQL больше не спасают

На ранней стадии компания живет на выгрузках из PostgreSQL, Google Sheets и дашбордах в Metabase. Потом начинаются знакомые симптомы: отчеты считают разные версии выручки, ночные запросы тормозят прод, аналитики ждут данные по 6-12 часов, маркетинг спорит с финансами о цифрах, а дата-инженер вручную чинит CSV в три часа ночи. Это не романтика стартапа, это технический долг с процентной ставкой выше банковской.

Современный DWH решает четыре практические задачи:

• Единая модель метрик: выручка, churn, LTV, CAC и активные пользователи считаются по согласованным правилам.
• Разгрузка боевых систем: аналитические запросы не мешают OLTP-базам, где живут заказы, платежи и пользователи.
• Историчность: можно смотреть состояние данных на дату, анализировать изменения и восстанавливать контекст решений.
• Масштабирование аналитики: десятки команд получают доступ к данным без копирования таблиц в локальные файлы.
• Контроль доступа: персональные данные, финансы и HR-таблицы не лежат в общем чате под видом «финальная_версия_2.xlsx».

Классический DWH, real-time и lakehouse

Классический Data Warehouse хранит очищенные и смоделированные данные в колоночной или MPP-СУБД. Real-time аналитика добавляет потоковую загрузку из Kafka, CDC из транзакционных баз и задержку в диапазоне от секунд до минут. Lakehouse переносит часть логики в объектное хранилище — S3, GCS, HDFS, MinIO — и использует открытые табличные форматы вроде Apache Iceberg или Delta Lake.

На практике архитектура 2026 года редко бывает «чистой». Часто рядом живут Snowflake для корпоративной отчетности, ClickHouse для продуктовой аналитики и логов, S3 с Iceberg для дешевого хранения сырых событий, dbt для трансформаций, Airflow или Dagster для оркестрации, Power BI, Superset или Tableau для витрин. Главный вопрос не «какая платформа лучшая», а где проходит граница между скоростью, стоимостью владения, локальными требованиями и компетенциями команды.

ClickHouse — open-source лидер для аналитики

Где ClickHouse особенно силен

ClickHouse — колоночная OLAP-СУБД с открытым исходным кодом, которую любят за скорость, плотное сжатие и прямолинейную архитектуру. Она хорошо подходит для событийной аналитики, логов, метрик, продуктовых дашбордов, антифрода, adtech, fintech и внутренних аналитических сервисов, где запросы должны отвечать за миллисекунды или секунды, а не «после кофе».

Типичный профиль нагрузки: миллиарды строк, широкие таблицы событий, частые фильтры по времени, идентификаторам, странам, продуктам, кампаниям. На одном мощном сервере ClickHouse способен обрабатывать десятки и сотни миллионов строк в секунду на удачных запросах. В кластере из 3-12 узлов он закрывает задачи, для которых раньше ставили тяжелые MPP-системы или Elasticsearch с болезненным счетом за железо.

Архитектура и эксплуатация

ClickHouse хранит данные по колонкам, активно использует сжатие, партиционирование, сортировку, векторизованное выполнение и движки семейства MergeTree. Правильно выбранный ключ сортировки часто важнее, чем «добавить еще сервер». Если аналитики постоянно фильтруют по дате, tenant_id и user_id, эти паттерны должны попасть в физический дизайн таблиц.

Слабое место ClickHouse — не скорость, а требовательность к инженерной дисциплине. Нужно понимать:

• как выбирать ORDER BY, PARTITION BY и TTL;
• как устроены мутации, дедупликация и фоновые merge-процессы;
• почему UPDATE и DELETE здесь не стоит использовать как в PostgreSQL;
• как планировать репликацию, шардирование и резервное копирование;
• как ограничивать тяжелые запросы, чтобы один дашборд не съел весь кластер.

ClickHouse Cloud снижает операционную нагрузку: есть управляемые сервисы, автоскейлинг, бэкапы, интеграции, запуск в AWS, GCP и Azure. Самостоятельная установка дешевле по лицензиям, но не бесплатна по людям. Один опытный инженер данных или SRE в России в 2026 году легко стоит компании 300-600 тыс. ₽ в месяц с налогами и накладными расходами. Это надо закладывать в TCO честно.

Когда ClickHouse — правильный выбор

ClickHouse стоит рассматривать первым, если вам нужны быстрые срезы по событиям, дешевые длинные истории логов, real-time дашборды и контроль над инфраструктурой. Он особенно хорош в командах, где уже есть Linux, Kubernetes, Kafka, S3-совместимое хранилище и инженеры, которым не страшны настройки на уровне кластера.

Но для универсального корпоративного Data Warehouse с большим количеством ad hoc-пользователей, сложной безопасностью, data sharing и минимальной эксплуатацией ClickHouse может потребовать больше ручной работы, чем Snowflake или BigQuery. Он не плох для DWH, просто его надо проектировать, а не «залить все таблицы и надеяться». Надежда, как известно, не индекс.

Snowflake — облачный де-факто стандарт

Почему Snowflake стал корпоративным фаворитом

Snowflake занял сильную позицию потому, что снял с команд много неприятной инфраструктурной работы. Хранилище и вычисления разделены, virtual warehouses можно запускать, останавливать и масштабировать независимо, разные команды получают свои compute-кластеры, а данные остаются в одном управляемом слое. Для компаний, которые хотят меньше администрировать и быстрее давать бизнесу доступ к данным, это мощный аргумент.

Snowflake хорошо ложится на классический корпоративный Data Warehouse: финансы, продажи, маркетинг, риск-аналитика, клиентская отчетность, data sharing между организациями. Он поддерживает AWS, Azure и Google Cloud, что удобно для международных компаний с несколькими облаками. Плюс сильная экосистема: dbt, Fivetran, Airbyte, Tableau, Power BI, Sigma, Immuta, Collibra и десятки других инструментов подключаются без героизма.

Как устроена стоимость

Главная единица биллинга Snowflake — credit. В стандартных Gen1 warehouse X-Small потребляет 1 credit в час, Small — 2, Medium — 4, Large — 8, X-Large — 16; дальше размер обычно удваивается. Минимальное списание за запуск compute — 60 секунд, затем тарификация идет по секундам. Цена credit зависит от региона, облака, редакции и контракта; в публичных оценках для Standard/Enterprise часто закладывают диапазон около $2-5 за credit, но финальная цифра у крупных клиентов может отличаться.

Размер warehouse	Credits/час	Практический сценарий
X-Small	1	Небольшие трансформации, BI для малой команды
Medium	4	Регулярные витрины, 20-80 пользователей
X-Large	16	Тяжелые расчеты, ELT, широкие join по большим таблицам
3X-Large	64	Крупные пакетные окна, сотни ТБ, высокая конкуренция

Сильная сторона модели — предсказуемое разделение нагрузок. BI-команда не мешает ML-команде, ночные трансформации не съедают интерактивные дашборды. Слабая — счета могут расти незаметно: забытый warehouse, неудачный join, слишком щедрый auto-suspend, копирование данных между регионами. Хорошая FinOps-практика для Snowflake — лимиты, resource monitors, теги cost center и еженедельный разбор топ-20 дорогих запросов.

Кому подходит Snowflake

Snowflake стоит выбирать компаниям, где стоимость лицензии меньше стоимости задержек, найма инфраструктурной команды и ошибок в аналитике. Это банки, SaaS, e-commerce, промышленность, фарма, международные группы с требованиями к governance и audit trail. Если бюджет на платформу начинается от нескольких тысяч долларов в месяц и может вырасти до $50-300 тыс. в год, Snowflake обычно выглядит реалистично.

Для малого стартапа с 300 ГБ событий и одним аналитиком Snowflake может оказаться избыточным. Для компании, где данные должны физически оставаться в России, где есть ограничения по трансграничной передаче и закупкам, Snowflake часто не проходит юридический фильтр. Технологически он силен, но комплаенс не волнует, насколько красив ваш query profile.

Google BigQuery — serverless-аналитика

Модель: загрузил таблицу, написал SQL

BigQuery — serverless-хранилище Google Cloud: пользователю не нужно поднимать кластеры, выбирать тип узлов или руками масштабировать compute. Данные лежат в управляемом хранилище, запросы выполняются на ресурсах Google, а команда платит за обработанные байты или за выделенную емкость через slots и editions. Для многих продуктовых команд это самый быстрый путь от сырых событий до дашборда.

BigQuery особенно хорош там, где компания уже живет в Google Cloud: Firebase, Google Analytics 4, Ads, Pub/Sub, Cloud Storage, Dataflow, Vertex AI. Экспорт GA4 в BigQuery стал почти стандартом для продуктовой аналитики: события прилетают автоматически, дальше аналитики строят витрины, сегменты, retention и воронки. Для команд роста это удобнее, чем выгружать все в сторонний контур.

Цены: удобно, пока запросы аккуратные

В on-demand модели BigQuery берет плату за объем данных, прочитанный запросом. Первый 1 TiB обработки в месяц бесплатен, дальше типичная публичная ставка для многих регионов — около $6.25 за TiB. Хранение активных логических данных в США и ряде регионов оценивается примерно в $0.02 за GiB в месяц, долгосрочное после 90 дней без изменений — около $0.01 за GiB. Есть также физическая модель хранения, где платится за сжатый объем, но ставка выше; она может быть выгодной при хорошем сжатии 3-5x.

Эта модель прекрасна для нерегулярных запросов и опасна для небрежного SQL. SELECT * по таблице на 40 ТБ — это не просто плохой стиль, это маленькая финансовая демонстрация. Спасают partitioning, clustering, materialized views, dry run, лимиты на байты, scheduled queries и привычка смотреть query plan до запуска тяжелой аналитики.

Параметр BigQuery	Ориентир 2026	Что это значит
Бесплатная обработка	1 TiB/месяц	Хватает для учебных и малых проектов
On-demand compute	около $6.25/TiB	Платите за просканированные данные
Активное хранение	около $0.02/GiB/месяц	Недорого для больших исторических таблиц
Long-term storage	около $0.01/GiB/месяц	Скидка после 90 дней без изменений

Когда BigQuery выигрывает

BigQuery хорошо подходит продуктовым и маркетинговым командам, которым нужна аналитика без администрирования. Он удобен для ad hoc-исследований, ML в Google Cloud, обработки больших файлов из Cloud Storage, регулярных витрин через dbt и Dataform. Если нагрузка волнообразная — сегодня 5 запросов, завтра 500 — serverless-модель экономит время и нервы.

Ограничения понятны. BigQuery привязывает вас к Google Cloud и его сетевым, IAM- и billing-моделям. При высокочастотной интерактивной аналитике на одних и тех же данных ClickHouse может быть дешевле и быстрее. При строгих российских требованиях к размещению данных BigQuery, как и другие глобальные облака, часто отпадает. Но если GCP уже выбран, BigQuery остается одним из самых прагматичных способов построить Data Warehouse без большой платформенной команды.

Amazon Redshift — для AWS-ориентированных команд

Redshift как часть AWS-ландшафта

Amazon Redshift — логичный выбор для компаний, которые уже держат инфраструктуру в AWS: S3, Glue, Lake Formation, IAM, Kinesis, DMS, QuickSight, SageMaker. Он начинался как управляемый MPP-кластер, но за последние годы стал более гибким: появились RA3-узлы с разделением compute и managed storage, Redshift Spectrum для запросов к данным в S3, Serverless для команд, которые не хотят постоянно думать о размере кластера.

В отличие от BigQuery, Redshift ближе к классическому «кластерному» мышлению. Даже если вы используете serverless, важно понимать WLM, concurrency scaling, dist keys, sort keys, vacuum/analyze, форматы файлов в S3 и сетевую стоимость. AWS многое автоматизировал, но Redshift все еще любит инженеров, которые читают документацию, а не только Terraform plan.

Стоимость и варианты развертывания

По публичному прайсу AWS Redshift Provisioned начинается примерно от $0.543 в час для минимальных конфигураций, Redshift Serverless — от $1.50 в час, при этом фактическая стоимость зависит от региона, RPU, объема managed storage, резервирований и сетевых операций. Serverless Reservations могут снижать compute-расходы до 24% при устойчивой загрузке. Для крупной аналитики RA3 обычно предпочтительнее старых dense compute/storage-подходов, потому что хранение масштабируется отдельно.

• Provisioned: лучше для предсказуемой нагрузки, понятного окна ETL и зрелой эксплуатации.
• Serverless: удобен для нерегулярных команд, sandbox, быстрых проектов и переменной конкуренции.
• Spectrum: полезен, когда часть данных дешевле оставить в S3 и читать по мере необходимости.
• Reserved/commitment: снижает стоимость, если команда уверена в длительном использовании.

Где Redshift уместен

Redshift хорошо работает как корпоративное хранилище для AWS-native компаний: e-commerce, логистика, медиа, SaaS, IoT, финансовые сервисы за пределами жестких локальных ограничений. Его сильная сторона — интеграция с AWS-безопасностью и data lake на S3. Если в компании уже выстроены IAM-роли, VPC, KMS, CloudWatch, Glue Catalog и CI/CD вокруг AWS, внедрение Redshift пройдет спокойнее, чем перенос всего в Snowflake или BigQuery.

Слабые места — необходимость тюнинга и риск получить сложную смесь Redshift, Spectrum, Glue, Athena и S3 без ясных границ ответственности. Для интерактивной событийной аналитики ClickHouse часто даст лучшую латентность. Для совсем serverless-подхода BigQuery может быть проще. Но если AWS — ваш основной дом, Redshift остается зрелым и понятным кандидатом для Data Warehouse с хорошей поддержкой экосистемы.

Greenplum / Arenadata — российский MPP

Почему Greenplum до сих пор жив

Greenplum — MPP-СУБД на базе PostgreSQL-подхода, созданная для параллельной обработки больших аналитических массивов. Архитектура проста для объяснения: есть master/coordinator, есть segment-узлы, данные распределяются по сегментам, запросы выполняются параллельно. Это не модный serverless, зато понятная промышленная машина для SQL-аналитики, витрин, регламентной отчетности и корпоративных хранилищ.

В России Greenplum получил вторую жизнь из-за импортозамещения, наличия специалистов и совместимости с привычной SQL-культурой. Arenadata DB — российская MPP-СУБД на базе Greenplum с enterprise-дистрибутивом, поддержкой, документацией, инструментами эксплуатации и поставкой для компаний, которым нужны договоры, SLA, сертификация, локальная экспертиза и предсказуемый вендорский контур.

Где российский MPP выглядит рационально

Greenplum и Arenadata стоит рассматривать в банках, страховых, телекоме, госсекторе, промышленности, ритейле и крупных холдингах, где данные должны оставаться в российском ЦОДе или частном облаке. Типичные объемы — от 10-20 ТБ до сотен ТБ полезных данных. Нагрузки — ежедневные регламентные расчеты, витрины для BI, скоринг, сверки, риск-отчеты, финансовый контур.

• Плюсы: MPP-архитектура, SQL, зрелость, локальное развертывание, контроль инфраструктуры.
• Плюсы: совместимость с частью PostgreSQL-инструментов и понятная модель для DBA.
• Минусы: больше операционной работы, чем в Snowflake или BigQuery.
• Минусы: требования к грамотному распределению данных, статистике и обслуживанию таблиц.
• Минусы: real-time сценарии обычно требуют дополнительного слоя.

Цена владения: лицензии плюс железо плюс люди

В on-prem MPP нет красивой строки «$6 за TiB». Есть серверы, диски, сеть 25/40/100 GbE, стойки, резервирование, лицензии или подписка, внедрение, обучение, дежурства и обновления. Кластер на 8-16 узлов с NVMe/SSD, 512 ГБ-1 ТБ RAM на узел и нормальной сетью может стоить десятки миллионов рублей капитальных затрат. Поддержка и сопровождение — еще 15-30% в год от стоимости платформы и инфраструктуры, в зависимости от договора.

Зато для компаний с жестким комплаенсом это может быть не недостатком, а условием задачи. Когда данные нельзя вынести в западное облако, выбор идет не между Snowflake и BigQuery, а между отечественным MPP, ClickHouse, Postgres-расширениями, Hadoop-стеком и lakehouse на локальном объектном хранилище. В таком контексте Arenadata выглядит не «заменой Snowflake», а практичным вариантом для классического корпоративного DWH в российской реальности.

Apache Iceberg, Delta Lake — Lakehouse-парадигма

Что меняет lakehouse

Lakehouse — попытка соединить дешевое хранение data lake и управляемость аналитического хранилища. Данные лежат в объектном хранилище в форматах Parquet/ORC, а табличный слой добавляет транзакции, схемы, snapshots, time travel, partition evolution и конкурентную запись. Самые заметные форматы — Apache Iceberg и Delta Lake. Они не заменяют compute-движок: поверх них работают Spark, Trino, Flink, Athena, Snowflake, BigQuery, Redshift, Databricks и другие системы.

Идея простая: не запирать петабайты данных в одном вендорском хранилище, а хранить их в открытом формате, доступном разным движкам. Для компаний с большими историческими массивами, ML, потоками и несколькими аналитическими платформами это снижает риск vendor lock-in. Для маленькой команды это может добавить сложности, потому что теперь у вас не одна база, а формат таблиц, catalog, object storage, compute engines и правила обслуживания файлов.

Iceberg против Delta Lake

Apache Iceberg продвигается как открытый табличный формат для огромных аналитических таблиц. Его сильные стороны — скрытое партиционирование, эволюция схемы и партиций, snapshots, serializable isolation, интеграции со Spark, Trino, Flink, Presto, Hive, Impala и REST Catalog. Iceberg особенно популярен в архитектурах, где Trino/Athena/Spark читают одни и те же данные в S3 или совместимом хранилище.

Delta Lake вырос из экосистемы Databricks и Spark. Он дает ACID-транзакции, schema enforcement, time travel, merge/update/delete, batch и streaming в одном табличном слое. В 2026 году Delta уже не только «формат Databricks»: есть UniForm и интеграции с разными движками, но исторически его сильнейшая зона — Spark/Databricks-центричные платформы.

Формат	Сильная зона	На что смотреть
Apache Iceberg	Открытый multi-engine lakehouse	Catalog, поддержка движков, compaction, governance
Delta Lake	Spark, Databricks, streaming/batch	Совместимость, UniForm, операции merge, стоимость платформы

Когда lakehouse нужен, а когда мешает

Lakehouse нужен, если у вас сотни ТБ или петабайты исторических данных, много ML/AI-нагрузок, несколько compute-движков, потребность в открытых форматах и долгий горизонт хранения. Он хорош для сырых и полуочищенных слоев: bronze/silver/gold, CDC-история, feature store, аудит, дешевые архивы.

Но lakehouse не отменяет Data Warehouse. Бизнесу все равно нужны витрины, SLA, понятные метрики, BI-производительность и доступы. Часто лучшая архитектура — гибрид: Iceberg или Delta для дешевого масштабного слоя, ClickHouse для быстрых событийных запросов, Snowflake/BigQuery/Redshift/Greenplum для управляемых витрин. Да, звучит сложнее, чем «купим одну платформу». Зато ближе к тому, как живут реальные данные после третьего года роста.

Сравнительная таблица: цена, скорость, экосистема

Короткая версия для выбора

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

Платформа	Лучший сценарий	Цена	Скорость	Операционная сложность	Регионы/комплаенс
ClickHouse	События, логи, real-time BI	Низкая-средняя; cloud от десятков $/мес, self-hosted зависит от железа	Очень высокая на OLAP	Средняя-высокая	Cloud глобально, self-hosted где угодно
Snowflake	Корпоративная аналитика, governance, sharing	Средняя-высокая; credits и storage	Высокая, стабильная	Низкая-средняя	AWS/Azure/GCP, зависит от региона
BigQuery	GCP, ad hoc, маркетинг, GA4	Низкая на старте, риск роста из-за scan	Высокая на больших scan	Низкая	Google Cloud регионы
Redshift	AWS-native DWH и lake на S3	Средняя; provisioned/serverless	Высокая при тюнинге	Средняя	AWS регионы
Greenplum	On-prem MPP, SQL-витрины	Средняя; железо плюс поддержка	Высокая на пакетной аналитике	Высокая	Локальный ЦОД
Arenadata DB	Российский enterprise MPP	Средняя-высокая; проектная поставка	Высокая на классическом DWH	Средняя-высокая	Россия, on-prem/private cloud

Ориентиры по бюджету

Для небольшого проекта на 1-3 ТБ данных и 5-20 пользователей минимальный бюджет может быть почти нулевым на open-source ClickHouse или BigQuery free tier, но реальная эксплуатация быстро выходит на $100-1000 в месяц. Средняя продуктовая компания с 10-50 ТБ, потоковой загрузкой и BI обычно тратит $2-15 тыс. в месяц на облачную аналитику или сопоставимую сумму в пересчете на on-prem с учетом людей. Enterprise с сотнями ТБ и требованиями к SLA может платить $100-500 тыс. в год и выше.

Самый частый просчет — считать только compute и storage. В реальности TCO включает ingestion, orchestration, data quality, каталог данных, мониторинг, бэкапы, сетевой трафик, обучение, поддержку, безопасность и зарплаты. Если платформа стоит дешево, но требует двух редких инженеров, она не обязательно дешевле управляемого облака. Если облако удобно, но юридически недоступно, его удобство не имеет значения.

Как выбрать DWH под задачу

Начните не с вендора, а с профиля нагрузки

Выбор хранилища данных начинается с описания нагрузки на 1-2 страницы. Сколько источников? Какой объем сырых данных в день: 10 ГБ, 500 ГБ, 5 ТБ? Какая задержка допустима: сутки, час, пять минут, секунды? Сколько пользователей одновременно открывают BI? Есть ли персональные данные, банковская тайна, коммерческая тайна, требования 152-ФЗ, PCI DSS, внутренние политики по регионам?

Полезная минимальная анкета:

1. Объем сейчас и прогноз на 24 месяца: например, 5 ТБ сегодня и 80 ТБ через два года.
2. Тип данных: транзакции, события, логи, документы, CDC, внешние справочники.
3. Тип запросов: агрегаты по времени, широкие join, full scan, point lookup, ML features.
4. Пользователи: 5 аналитиков или 800 сотрудников с дашбордами каждое утро.
5. SLA: отчет к 9:00, задержка 15 минут, интерактивный ответ до 3 секунд.
6. Ограничения: облако запрещено, данные только РФ, нужен AWS/GCP/Azure, нужен open source.

Практические рекомендации

Если у вас много событий, логов и продуктовой аналитики — начинайте с ClickHouse. Если нужна корпоративная платформа с сильным governance, data sharing и минимальной эксплуатацией — смотрите Snowflake. Если компания уже в Google Cloud и активно использует GA4, Ads, Firebase, Vertex AI — BigQuery будет естественным выбором. Если весь стек в AWS — Redshift проще защитить перед платформенной командой. Если данные должны жить в российском контуре — Greenplum/Arenadata и self-hosted ClickHouse становятся первыми кандидатами.

Задача	Первый кандидат	Почему
Real-time продуктовые метрики	ClickHouse	Высокая скорость агрегаций и дешевые события
Финансовая отчетность группы компаний	Snowflake / Greenplum / Arenadata	Governance, SQL, регламентные витрины
Маркетинговая аналитика GA4	BigQuery	Нативный экспорт и serverless
AWS data lake плюс BI	Redshift	Интеграция с S3, Glue, IAM
Петабайтный архив и ML	Iceberg / Delta Lake	Открытые форматы и дешёвое объектное хранение

Пилот: 4 недели вместо вечного RFP

Нормальный выбор Data Warehouse можно сделать через пилот. Берете 3-5 реальных таблиц, 10-20 типовых запросов, один поток загрузки, один BI-дашборд и один сценарий доступа. Прогоняете на двух-трех платформах. Меряете не только скорость, но и стоимость, сложность загрузки, качество ошибок, удобство мониторинга, поведение при росте данных в 5 раз.

И главное: не верьте бенчмаркам без вашего профиля данных. У вендоров все быстро, дешево и с красивым графиком. В вашем проде есть перекошенные tenant_id, грязные timestamps, JSON на полтаблицы, странный join с Excel-справочником и отчет, который запускает директор по продажам ровно в 9:01. Вот это и надо тестировать.

Миграция между DWH: типичные сложности

Миграция — это не только перелить таблицы

Переезд между хранилищами почти всегда сложнее, чем кажется на презентации. Таблицы можно выгрузить в Parquet, переложить через S3/GCS, загрузить в новую платформу. Но вместе с ними едут схемы, права, расписания, SQL-диалекты, UDF, materialized views, BI-семантика, dbt-модели, тесты качества, SLA и привычки аналитиков. Особенно больно мигрировать системы, которые строились 5-10 лет без каталога и владельцев данных.

Типичные проблемы:

• SQL-диалект: даты, массивы, JSON, оконные функции и типы данных ведут себя по-разному.
• Производительность: запрос, быстрый в старой системе, может стать дорогим из-за другой модели хранения.
• Права: роли и политики доступа редко переносятся автоматически один к одному.
• BI-зависимости: отчеты содержат кастомный SQL, скрытые фильтры и ручные вычисления.
• История: старые партиции могут быть грязными, неполными или с устаревшей схемой.
• Стоимость: двойная эксплуатация на время миграции длится 2-6 месяцев, иногда год.

Порядок работ

Хорошая миграция начинается с инвентаризации. Нужно понять, какие таблицы реально используются, какие отчеты открывали за последние 90 дней, какие пайплайны критичны, где лежат персональные данные, кто владелец каждой витрины. В крупных компаниях 20-40% таблиц в старом DWH могут оказаться мертвыми или почти мертвыми. Переносить их «на всякий случай» — дорогое хобби.

1. Соберите каталог таблиц, запросов, отчетов и владельцев.
2. Разделите объекты на critical, active, archive и delete candidates.
3. Перенесите сначала сырые данные и 3-5 ключевых витрин.
4. Сравните метрики между старой и новой системой на одинаковых датах.
5. Переведите BI и пользователей по доменам, а не одним большим взрывом.
6. Оставьте read-only период старого хранилища на 1-3 месяца.

Как снизить риск

Лучший способ облегчить будущие миграции — хранить сырые данные в открытых форматах Parquet/Iceberg/Delta, описывать трансформации в dbt или похожем инструменте, тестировать метрики, версионировать схемы и не писать бизнес-логику только внутри BI. Чем меньше логики заперто в конкретном вендоре, тем дешевле следующий переезд.

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

Глубже на тему — исследования it-institute.ru

На партнёрском портале it-institute.ru опубликована подборка релевантных исследований с медианами, выборками и методологией:

• Тренды Data/ML платформ
• Cloud Native и Kubernetes 2026

FAQ о Data Warehouse

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.