Зачем нужно разделять Compute и Storage?

Разделение Compute и Storage в облачных хранилищах

Суть архитектуры

Compute и Storage разделение означает, что вычислительные ресурсы (процессоры, память) и хранилище данных работают независимо друг от друга. Это ключевая архитектура Snowflake, BigQuery, Databricks и других современных DWH.

Основные причины разделения

1. Независимая Масштабируемость

┌─────────────────────────────────────┐
│  Compute (Warehouse)                │
│  • 8 CPU → масштабируем вверх       │
│  • Не зависит от размера данных     │
│  • Можно увеличить на 100x          │
└─────────────────────────────────────┘
                    ↕
┌─────────────────────────────────────┐
│  Storage (Data Lake)                │
│  • 100 TB → 1 PB                    │
│  • Растет независимо от Compute     │
│  • Дешево хранить большие объемы    │
└─────────────────────────────────────┘

Это значит: если вам нужно обработать 1 TB данных, вы платите за хранение 1 TB, но можете арендовать compute ресурсы только на время обработки (часы). В старых системах (например, кластер Hadoop) ресурсы были привязаны друг к другу.

2. Оптимизация Затрат

До разделения (монолитная архитектура):

Auto-scaling Hadoop кластер:
- Нужно обработать 1 TB за 1 час → 50 нодов (дорого)
- Нужно хранить 100 TB → 100 нодов (всегда работают)
- Итого: 150 нодов, плата 24/7 → $50k/месяц

После разделения (облако):

Snowflake:
- Compute: 8 кредитов/час × 24 часа = 192 кредита/день
- Storage: $23/TB/месяц × 100 TB = $2300/месяц
- Когда никто не работает → Compute = 0 (автоматическая остановка)
- Итого: ~$1500-2500/месяц

Экономия: 50-70% за счет платы за compute только во время использования.

3. Гибкость в выборе Compute Resources

# Snowflake пример: разные размеры Warehouse для разных задач

# Небольшая витрина данных
CREATE WAREHOUSE reporting_wh 
  WITH SIZE = XSMALL;  # 1 кредит/час

# Ежедневная обработка большого датасета
CREATE WAREHOUSE etl_wh 
  WITH SIZE = XLARGE;  # 8 кредитов/час, но обработает быстрее

# Экспериментирование ML инженера
CREATE WAREHOUSE ml_wh 
  WITH SIZE = MEDIUM;  # 2 кредита/час

Каждый Warehouse работает на одних и тех же данных в Storage, но платит по мере использования.

4. Параллельная работа без конфликтов

-- Scenario: ETL и аналитика одновременно

-- ETL процесс (etl_wh)
CREATE TABLE new_data AS
SELECT * FROM raw_data WHERE date = TODAY();
-- Использует: etl_wh (4 часа, 32 кредита)

-- Параллельно: аналитик делает отчет (reporting_wh)
SELECT region, SUM(revenue)
FROM sales
GROUP BY region;
-- Использует: reporting_wh (5 минут, 0.08 кредита)

Без разделения: оба процесса конкурируют за одни ресурсы → конфликты и замедление.

5. Система хранения оптимизирована для аналитики

Columnar Format (Storage):

┌─ Таблица Sales ─────────────────────┐
│ customer_id | product_id | amount   │
├─────────────────────────────────────┤
│ 1           | 100        | 1000.00  │
│ 2           | 101        | 2500.00  │
│ 3           | 100        | 1200.00  │
│ 4           | 102        | 890.00   │

CHO MPUTED КАК:

Column 1 (customer_id):  [1, 2, 3, 4]
Column 2 (product_id):   [100, 101, 100, 102]
Column 3 (amount):       [1000, 2500, 1200, 890]

Запрос: суммировать amount по product_id

SELECT product_id, SUM(amount)
FROM Sales
GROUP BY product_id;

• Storage доставляет только столбцы 2 и 3 (не нужен customer_id)
• Compute сжимает данные перед передачей
• На 1000x быстрее, чем row-based storage (как в традиционных БД)

6. Данные остаются в одном месте

Обработка 100 TB:
- Compute "приезжает" к Storage
- Не нужно копировать 100 TB в память ноды
- Сетевые задержки минимальны

Практическая архитектура

┌─────────────────────────────────────┐
│  Cloud Object Storage (S3/GCS)      │
│  - Лямбда озеро (raw)               │
│  - Стоит $23/TB/год хранения        │
│  - 99.9% uptime                     │
└─────────────────────────────────────┘
          ↓ (данные читаются)
┌─────────────────────────────────────┐
│  Query Engine (Compute)             │
│  - Запускается по требованию        │
│  - Масштабируется: 1-128 нодов      │
│  - Платим только за uso             │
│  - Кэширует горячие данные          │
└─────────────────────────────────────┘
          ↓ (результаты)
┌─────────────────────────────────────┐
│  BI Tool / Application              │
│  - Dashboards                       │
│  - Reports                          │
└─────────────────────────────────────┘

Реальные цифры (Snowflake)

# Пример счета за месяц:

# Storage
- 500 TB × $23/TB = $11,500
- Fail-safe data (7 дней) = $2,500

# Compute
- Prod Warehouse (LARGE): 100 hours/день × 8 кредитов/час × 30 дней × $4/кредит = $96,000
- Dev Warehouse (SMALL): 50 hours/день × 2 кредита/час × 30 дней × $4/кредит = $12,000
- Автоматизированный отпуск (XSMALL): 24 hours/день × 1 кредит/час × 30 дней × $4/кредит = $2,880

Всего: $124,880

ПО vs SaaS: с собственным кластером на 500 TB → $500k-1M/месяц

Заключение

Разделение Compute и Storage — это парадигма облачных DWH, позволяющая:

• ✅ Платить только за использованные ресурсы
• ✅ Масштабировать независимо
• ✅ Избежать конфликтов между заданиями
• ✅ Оптимизировать стоимость
• ✅ Сосредоточиться на данных, а не на инфраструктуре