Cloud DWH: Snowflake, BigQuery, Redshift

В уроках 01 и 02 мы разобрали ClickHouse, который ты обычно поднимаешь сам и сам же эксплуатируешь. Этот урок про другую категорию аналитических систем, где compute и storage разнесены по архитектуре, биллинг идёт за реальное использование, а команда платформенных DBA, это сам облачный провайдер.

Аудитория: ты прошёл уроки 01-02 и понимаешь, что такое колоночное хранилище и distributed query. На работе встречаются датасеты, которые ты не хочешь хранить у себя, и нагрузки, которые не хочешь администрировать. Сам не выберешь между Snowflake, BigQuery и Redshift, надо понимать модели биллинга, архитектурные ограничения и где каждая система проигрывает.

Не цель урока: научить писать SQL под BigQuery с нуля или администрировать Snowflake. Цель, дать карту, чтобы выбрать систему под задачу и не попасть в ловушку счёта в конце месяца.

0. Что такое DWH и почему cloud

DWH (data warehouse), это аналитическое хранилище, рассчитанное на сложные запросы по большому объёму исторических данных. Корни уходят в 1980-е (Teradata, 1979 год), потом MPP-системы 2000-х (Vertica, Netezza, Greenplum), потом облачная волна 2010-х: Redshift (2012), BigQuery (2010, GA 2012), Snowflake (2014).

В 2026 году “DWH” в продуктовом разговоре обычно означает один из трёх облачных гигантов плюс reborn-альтернативы (Databricks SQL, Firebolt, MotherDuck). Сравнения “DWH против data lake” уходят в прошлое: lakehouse (см. урок 04) стирает границу.

Главная разница cloud DWH с self-hosted CH:

• Compute и storage разнесены. Можно держать петабайты в S3/GCS дёшево и поднимать compute только под запрос. У ClickHouse self-hosted compute и storage обычно на одних и тех же узлах (хотя ClickHouse Cloud этот шаблон догнал).
• Биллинг за реальное использование. Платишь либо за время работающего compute (Snowflake, Redshift RA3), либо за объём отсканированных байтов (BigQuery on-demand). Это даёт эластичность, но требует тщательного контроля стоимости.
• DBA, это провайдер. Не надо думать о tuning vacuum, replication, backups, version upgrade. Цена, меньше контроля и непрозрачные баги.
• SQL более стандартный. Snowflake и BigQuery близки к ANSI SQL, в отличие от ClickHouse, у которого сильный диалект.

Дальше разбираем три системы по очереди, потом сравниваем, потом смотрим, когда DWH вообще плох.

1. Архитектурный сдвиг: shared storage, ephemeral compute

Старые MPP-системы (Vertica, Netezza, Greenplum, ранний Redshift) клали данные на диски тех же узлов, которые их считали. Это classical shared-nothing: масштабирование происходило добавлением узла, но добавление узла требовало ребалансировки данных, болезненной операции с downtime.

Cloud DWH ввёл другую модель: shared storage с ephemeral compute. Storage-слой это общий object store, compute поднимается и гасится по требованию.

Snowflake пошёл первым (whitepaper 2014, GA 2015): они описали это как “service of services”, три слоя:

┌──────────────────────────────────────────────────────────┐
│  Cloud Services Layer (metadata, optimizer, transactions)│
└──────────────────────────────────────────────────────────┘
                          ↓ ↑
┌──────────────────────────────────────────────────────────┐
│  Compute Layer: Virtual Warehouses (XS, S, M, L, XL, ...)│
│  ┌──────┐  ┌──────┐  ┌──────┐                            │
│  │ WH-A │  │ WH-B │  │ WH-C │   независимые, изолированные│
│  └──────┘  └──────┘  └──────┘                            │
└──────────────────────────────────────────────────────────┘
                          ↓ ↑
┌──────────────────────────────────────────────────────────┐
│  Storage Layer: micro-partitions в S3 / GCS / Azure Blob │
└──────────────────────────────────────────────────────────┘

Plus или minus детали, эта схема повторилась везде. BigQuery идёт ещё дальше, делая compute полностью невидимым (serverless): пользователь не выбирает узлы, выбирает только размер reservation в slots. Redshift начинал классическим shared-nothing (DC1/DS2-инстансы), но в 2019 году выпустил RA3-инстансы с managed storage в S3, догнав модель Snowflake.

1.1 Что это даёт

• Эластичность. Большой ETL-job: подними XL warehouse, прогоняй 30 минут, погаси. Заплатишь за 30 минут, не за пожизненную инфраструктуру.
• Изоляция нагрузок. ETL и ad-hoc-аналитика, на разных warehouses. ETL не убивает дашборд.
• Zero-copy clone. Snapshot таблицы, это указатель на те же micro-partitions. Можно “клонировать” 10 ТБ за миллисекунды и без storage cost (пока не начнёшь модифицировать).
• Time travel. Запрос к “вчерашней” версии таблицы (Snowflake, до 90 дней; BigQuery, 7 дней).

1.2 Что это стоит

• Network latency между compute и storage. Каждое чтение, это сетевой round-trip. Решается агрессивным кешированием на compute (warm warehouse держит горячие данные локально).
• Cold-start. Поднять warehouse занимает секунды (Snowflake, 1-3 секунды; BigQuery, доли секунды через slot pool; Redshift Serverless, 10-30 секунд).
• Биллинг при ошибке запроса. SELECT * без LIMIT на 10 ТБ датасете в BigQuery on-demand стоит реальные деньги, даже если ты потом нажал Cancel.

2. Snowflake: virtual warehouses

Snowflake продаёт compute как T-shirt-размеры warehouse-ов: XS (2 vCPU), S, M, L, XL, …, 6X-Large. Каждый шаг в 2 раза больше и в 2 раза дороже. Биллинг идёт по секундам активной работы.

2.1 Размер warehouse

Размер	Серверы	Кредиты в час	Когда
XS	1	1	dev / lookups
S	2	2	small ETL, аналитика на сотни GB
M	4	4	средний ETL, дашборды
L	8	8	продовый ETL, десятки TB
XL	16	16	sub-минутные SLA на TB-данных
4XL+	128+	128+	петабайтные jobs

Один кредит, это ~3-4 USD в зависимости от региона и edition (Standard, Enterprise, Business Critical). Это значит, час L warehouse, ~24-32 USD; день, ~600 USD. Цена растёт линейно с размером.

Главная фишка Snowflake: multi-cluster warehouse. Если на одном WH стоят 50 одновременных запросов и они начинают друг друга подпирать, Snowflake поднимает второй кластер того же размера и распределяет нагрузку. Когда нагрузка падает, лишние кластеры гасятся. Это автоскейл compute.

-- многокластерный warehouse, который автоматически масштабируется 1-4 кластеров
CREATE WAREHOUSE analytics
  WITH WAREHOUSE_SIZE = 'LARGE'
       MIN_CLUSTER_COUNT = 1
       MAX_CLUSTER_COUNT = 4
       SCALING_POLICY = 'STANDARD'   -- или 'ECONOMY' для медленного скейла
       AUTO_SUSPEND = 60             -- через 60 секунд idle, гасим
       AUTO_RESUME = TRUE;           -- запрос автоматически разбудит

AUTO_SUSPEND = 60 критически важен. Без него warehouse тикает 24/7 даже когда никто не запрашивает. С 60-секундной паузой, гасится за минуту, цена за idle, пара кредитов в день.

2.2 Storage и micro-partitions

Snowflake режет таблицы на micro-partitions по 50-500 MB, immutable, со статистиками на каждой. UPDATE и DELETE, это новые micro-partitions с измененными версиями записей; старые остаются для time travel.

Clustering key можно задать вручную, и Snowflake фоном будет реорганизовать micro-partitions, чтобы фильтрация по этому ключу пропускала больше партиций. По дефолту таблица “natural-cluster”, сортируется по порядку вставки.

2.3 Биллинг compute раздельно по WH

-- ETL пишет в L
USE WAREHOUSE etl_l;
COPY INTO orders FROM @stage/orders.parquet;

-- BI читает с M
USE WAREHOUSE bi_m;
SELECT * FROM orders_summary;

Это даёт изоляцию: тяжёлый ETL не отжимает CPU у дашборда. Стандартная схема в Snowflake: 3-4 named warehouses (etl, bi, ad_hoc, dev), каждый со своим размером и auto_suspend.

2.4 Когда выбрать Snowflake

• Предсказуемая нагрузка по времени (ETL-окно ночью, BI днём). Хорошо ложится на T-shirt billing.
• Несколько команд, надо изолировать compute. Multi-warehouse решает.
• Multi-cloud. Snowflake работает в AWS, GCP, Azure одинаково.
• Data sharing между организациями (Data Marketplace, Secure Data Sharing). Тут Snowflake уникален.

Минусы:

• Дорого при 24/7 высокой нагрузке. Если warehouse работает 24 часа, проще self-hosted.
• Storage layer закрыт. Нельзя положить туда свой формат, читать ChickHouse-ом или Spark-ом без unload.
• Нет внешних engines. Нельзя дать Trino читать Snowflake-таблицы напрямую.