Сравнение платформ, выбор и стоимость

После обзора Snowflake и BigQuery возникает вопрос: как выбрать одну платформу для конкретной команды? И как не разориться на счёте за облако? Плюс на рынке есть ещё два значимых игрока, которых стоит знать на обзорном уровне: Amazon Redshift и Databricks.

В этом уроке — краткое сравнение всех четырёх платформ, decision matrix и практические советы по cost optimization. Это та часть DE-работы, которую часто недооценивают. Junior DE становится senior, когда начинает думать о проекте в долларах, а не только в строках кода.

Ещё два игрока: краткий обзор

Amazon Redshift

Redshift запустился в 2012 году как первый mass-market cloud DWH (форк PostgreSQL с массивным изменением engine от ParAccel). Архитектура — классический кластерный подход: leader node плюс N worker nodes, которые держатся постоянно. К 2026 году его доля рынка падает, но в AWS-shop’ах он жив.

Ключевые особенности:

• RA3 instances (2019) — разделили storage и compute. Данные в Redshift Managed Storage (S3-подобное хранилище), compute на worker nodes с локальным кешированием. Старые типы DS2/DC2 deprecated.
• AQUA (Advanced Query Accelerator, 2021) — proprietary FPGA-слой, который выполняет фильтры и аггрегаты прямо в storage до отправки в workers.
• Sort keys и distribution keys — главная сложность Redshift. Нужно явно указать, как данные распределяются между nodes (KEY/EVEN/ALL/AUTO) и по каким колонкам отсортированы внутри node. Неправильные ключи — главная причина медленного Redshift, чего нет в Snowflake.
• Redshift Serverless (2022) — версия без cluster, оплата за RPU (Redshift Processing Units), попытка догнать BigQuery в удобстве.

Databricks Lakehouse Platform

Databricks — это не DWH, а управляемый Spark плюс Delta Lake плюс Unity Catalog. Основатели — создатели Apache Spark в Berkeley. С 2017 года они построили полноценную lakehouse-платформу, конкурирующую со Snowflake.

Ключевые особенности:

• Delta Lake — open-source table format поверх Parquet. ACID-транзакции, time travel, schema evolution. Данные лежат в S3/GCS/Azure в открытом формате, не vendor-specific.
• Unity Catalog (2022) — единое governance: access control, lineage, audit для таблиц и моделей.
• Photon — проприетарный векторизованный движок (C++) для SQL и DataFrame, конкурент Snowflake-движка.
• Databricks SQL Warehouses (2022) — специальный compute для SQL-нагрузок (Classic, Pro, Serverless), попытка конкурировать со Snowflake в DWH-нише.
• MLflow и Mosaic AI — лучший в индустрии стек для ML lifecycle.
• Spark Structured Streaming — для real-time pipelines.

Минусы: сложнее Snowflake (нужно понимать Spark, Delta, cluster types), дорого при неоптимизированных нагрузках, Photon vendor-specific (хотя Delta open).

Сравнительная таблица

Шесть критериев выбора

Когда тимлид спрашивает: “Snowflake или BigQuery?”, junior’у хочется сказать “оба хорошие”. Senior раскладывает по критериям.

1. Cloud провайдер

Самый сильный фактор. Если компания на AWS — Redshift или Snowflake. Если на GCP — BigQuery. Если на Azure — Snowflake или Databricks. Кросс-cloud egress трафик дорогой, поэтому платформа должна быть в том же облаке, что и данные.

2. Compute и storage модель

• Полный serverless (BigQuery): проще всего, дорого если плохо настроено.
• Warehouses (Snowflake): баланс контроля и удобства.
• Cluster-based (Redshift): дешевле при стабильной нагрузке, сложнее.
• Lakehouse (Databricks): для ML и больших Spark-нагрузок.

3. Ecosystem

• Tableau — отлично работает со всеми.
• Looker — оптимально с BigQuery (один владелец — Google).
• Power BI — лучше с Snowflake и Azure Databricks.
• dbt — со всеми, лучшая поддержка Snowflake/BigQuery.

4. Vendor lock-in

Snowflake — самый closed: данные в проприетарном формате. Уйти можно, но больно. BigQuery — closed (внутри GCP). Databricks с Delta Lake — open: данные в S3, можно читать другими движками. Iceberg-based решения — самые open. В 2026 году все платформы движутся в сторону Iceberg-совместимости.

5. Talent pool

В резюме senior DE чаще встречается Snowflake. BigQuery — следом. Redshift — особенно в US, в AWS-heavy компаниях. Databricks — растущий, особенно в ML-heavy командах.

6. Особые фичи

• ML в SQL: BigQuery ML.
• Multi-cloud: Snowflake.
• Zero-copy clones: Snowflake.
• Real-time streaming: Databricks (Spark Streaming).
• GIS / geographical: BigQuery очень силён.

Когда что выбирать

Реальные сценарии:

• B2C-стартап на AWS, 5 DE, ограниченный бюджет. Snowflake (простота) или Redshift (дешевле на reserved). Если есть DevOps для Redshift dist/sort tuning — Redshift; иначе Snowflake.
• Enterprise банк на Azure, ML-команда 30 человек. Databricks — лучшая ML-платформа, нативная интеграция с Azure (через Azure Databricks).
• GCP-startup. BigQuery — serverless, ML в SQL, без overhead.
• Multi-cloud Fortune 500. Snowflake (multi-cloud) плюс Iceberg lakehouse для cross-cloud workloads.

В реальности крупные компании часто используют несколько платформ: Snowflake для аналитики и BI, Databricks для ML, BigQuery в GCP-областях. С Iceberg-стандартом эта мультиплатформенность становится дешевле.

Cost optimization: общие принципы

Облачные счета умеют расти неожиданно. Несколько правил, которые экономят 30-70% денег:

Snowflake

• Auto-suspend на 60 секунд. По умолчанию 10 минут. Если warehouse используется редко, ставь AUTO_SUSPEND = 60.
• Правильный размер warehouse. Сначала запускай на XS/S, поднимай только если медленно.
• Multi-cluster scaling для concurrency вместо одного XL.
• Resource monitors с лимитами по credits и suspend-actions.
• Clustering keys только когда нужно — auto-clustering расходует credits.

BigQuery

• Партиционирование обязательно (PARTITION BY DATE) и всегда фильтруй по партиционирующей колонке.
• SELECT только нужные колонки — SELECT * сканирует всё.
• LIMIT 0 для preview схемы без оплаты scan.
• maximum_bytes_billed как guardrail от случайного SELECT * FROM 100TB.
• Materialized views и BI Engine для часто читаемых данных.
• Editions vs On-Demand — если стабильная нагрузка, Editions со 100-500 slots часто дешевле.

Redshift

• Reserved instances на 1 или 3 года — скидка до 75% против on-demand.
• Workload Management (WLM) queues для разделения ETL и BI нагрузок.
• Pause cluster при простое в non-production средах.
• RA3 nodes — не используй устаревшие DS2/DC2.
• AQUA enabled — бесплатно ускоряет некоторые запросы.
• Right-sizing — мониторь утилизацию, не покупай 16 нод, если 4 хватает.

Databricks

• Spot instances для job clusters — скидка до 90%.
• Auto-scaling clusters — minimum 1-2 workers, maximum по необходимости.
• Job clusters вместо all-purpose для production — дешевле.
• Delta Lake optimization: OPTIMIZE плюс Z-ORDER регулярно для compaction.
• Photon для SQL-нагрузок — быстрее значит меньше времени и меньше credits.

Универсальные техники

• Кеши на BI-стороне. Tableau Extracts, Looker Persistent Derived Tables — не дёргать DWH на каждый дашборд.
• dbt incremental models для больших таблиц — не пересоздавать с нуля.
• Удалять старые данные. Логи 3-летней давности обычно никому не нужны.
• Tagging ресурсов для FinOps-учёта: кто платит за что.
• Регулярный cost review — раз в месяц анализ топ-10 самых дорогих запросов.

Что делать, когда счёт уже большой

Реальный сценарий: пришёл счёт за месяц, в 3 раза больше ожидаемого.

Talking to business: ROI vs cost

Когда говоришь с бизнесом о стоимости data platform, не показывай только cost. Показывай ROI:

• Сколько решений принято на основе данных в этом месяце.
• Сколько часов аналитики сэкономили на dbt-витринах.
• Какие revenue-импактные эксперименты были возможны.

Бизнес платит за insights, не за credits. Если компания тратит 50k USD/мес на Snowflake, но получает один эксперимент в год, давший 5M revenue — это ROI 100x.

В 2024-2026 годах быстро растёт роль FinOps Engineer / Data Platform Cost Specialist. Если в компании 100+ инженеров на data — FinOps уже не option, а необходимость.

Что учить junior DE

Простой совет: учи всё, но глубоко — Snowflake. Это самая универсальная платформа, навыки переносятся на конкурентов. После Snowflake:

• BigQuery — если работаешь в GCP-shop.
• Databricks — если есть ML или большие Spark-нагрузки.
• Redshift — реже первой нужен, разве что AWS-legacy.

SQL остаётся базой везде. Различия — в управлении ресурсами, pricing model, специфических фичах.

Попробуй сам

Возьми любой свой проект (или sample dataset в trial-аккаунте). Запусти 10 разных запросов разной сложности. В Snowflake посмотри в SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY или в BigQuery — INFORMATION_SCHEMA.JOBS_BY_PROJECT — какие запросы какой credit/scan дали. Найди самый дорогой запрос, попробуй его оптимизировать: добавить фильтр, выбрать меньше колонок, добавить партицирование. Сравни до и после. Это даёт практический навык FinOps на DWH.