Big Data

Data Platform Architecture

Сколько стоит построить Data Platform с нуля? Snowflake + dbt + Airbyte + DataHub + Airflow - стандартный modern data stack. Для startup 50-100 человек: $30-100K/год. Для enterprise: $1-10M/год. Неправильные архитектурные решения в начале стоят переделки в 5-10x дороже через 2 года. Архитектор Data Platform - одна из самых высокооплачиваемых ролей: $200-400K в US.

  • **Notion Data Platform (2022)**: переход с ручных SQL запросов к dbt + Snowflake + Airflow. 50 аналитиков, 5 data engineers. Время на ad-hoc запросы снизилось с 3 дней до 30 минут благодаря self-service.
  • **Stripe Data Mesh (2021)**: 100+ команд, каждая owns свои данные. Central Data Platform только infrastructure. Federated governance через OpenLineage стандарт. Каждый месяц 10 000+ Spark jobs.
  • **Databricks Lakehouse для Comcast**: 500+ PB данных, migrated с Hadoop за 18 месяцев. Delta Lake + Spark + Unity Catalog. Экономия $50M/год по сравнению с on-premise Hadoop кластерами.

Проектирование Data Platform: от нуля до масштаба

Data Platform - инфраструктура для сбора, хранения, обработки и доставки данных всей компании. Неправильные архитектурные решения на старте стоят миллионы долларов рефакторинга через 2 года. Основные архитектурные паттерны: Data Warehouse (Snowflake, BigQuery), Data Lake (S3 + Spark), Lakehouse (Delta Lake, Iceberg).

Ключевые архитектурные решения при проектировании: (1) storage layer (cloud DW vs lake), (2) ingestion (batch vs streaming), (3) transformation (ELT vs ETL), (4) serving layer (OLAP cube vs query engine), (5) governance (centralized vs federated), (6) compute isolation (shared vs dedicated).

Uber Data Platform: 10 000+ Spark jobs ежедневно, 5 PB данных, 5000+ пользователей. Переход с Hadoop на Cloud Lakehouse (Presto + S3 + Hudi) в 2020-2021: снижение операционных затрат на 40%, query latency снизилась в 3x. Архитектурные решения влияют на операционные расходы годами.

Компания имеет: 10 аналитиков, 2 data engineers, смешанные workloads (batch ETL + ad-hoc SQL). Что выбрать: Data Warehouse (Snowflake) или Data Lake (S3 + Spark)?

Multi-tenant платформа: изоляция и fairness

Одна Data Platform для 50 команд: команда Finance запускает тяжёлый отчёт в конце квартала и «кладёт» платформу для всех остальных. Это проблема multi-tenancy: изоляция ресурсов между командами-потребителями.

Решения для multi-tenancy: (1) Snowflake Virtual Warehouses - каждая команда имеет свой compute cluster с auto-suspend/resume, платит только за использование. (2) Databricks Cluster Pools - shared кластеры с resource quotas. (3) Kubernetes namespaces + resource limits для Spark on K8s.

  • **Compute isolation**: отдельные Snowflake warehouses или Spark кластеры per team. Finance отчёт не влияет на Analytics pipeline.
  • **Cost allocation**: каждая команда видит свои расходы. Chargeback модель: команда платит за свой compute. Incentive экономить ресурсы.
  • **Resource quotas**: MAX_CLUSTER_SIZE, MAX_CONCURRENT_QUERIES per warehouse. Предотвращает monопольное использование.
  • **Priority queues**: критичные production jobs имеют приоритет над ad-hoc исследовательскими запросами.
  • **Autoscaling**: warehouse масштабируется под нагрузку, auto-suspend при простое. Snowflake: auto-suspend после 5 минут = экономия до 80% compute расходов.

Аналитик случайно запускает `SELECT * FROM events` на таблице 500 GB без LIMIT. Какой механизм предотвратит перегрузку платформы?

Self-service аналитика: демократизация данных

Традиционная модель: аналитик формулирует запрос -> data engineer пишет SQL -> 2-3 дня ожидания. Self-service: аналитик сам работает с данными через понятный интерфейс. Цель платформы - снизить зависимость от data engineers для стандартных задач.

  • **Data Discovery**: аналитик находит нужные данные через catalog (DataHub, Alation). Поиск по business terms, не по техническим именам таблиц.
  • **Semantic Layer**: dbt Metrics Layer или Looker LookML. Бизнес-метрики определены один раз (`revenue = sum(amount) WHERE status='completed'`), аналитик просто выбирает метрику.
  • **Query Builder**: Mode, Metabase, Tableau позволяют строить запросы через drag-and-drop без SQL. Для 80% аналитических задач достаточно.
  • **Notebook среда**: Databricks Notebooks, Google Colab Enterprise - SQL + Python в одном интерфейсе для advanced аналитики.
  • **Governed sandboxes**: отдельная среда для исследований с real (или anonymized) данными и меньшими ограничениями.

Airbnb перешёл на self-service через Dataportal + Superset в 2020 году: 90% SQL запросов аналитики выполняют самостоятельно без data engineers. Data engineering team переключилась на инфраструктуру и качество данных вместо написания ad-hoc запросов.

Аналитик хочет посчитать «revenue за последний месяц» но находит в каталоге 3 разных таблицы с похожими именами. Как semantic layer решает эту проблему?

Оптимизация стоимости Data Platform

Snowflake bill $500K/месяц для scale-up компании - не редкость. BigQuery scan costs могут взорваться при неоптимальных запросах. FinOps для data platforms - отдельная практика. 3 кита оптимизации: хранение, вычисления, query efficiency.

  • **Партиционирование и кластеризация**: partition pruning снижает scan в 10-100x. Snowflake Clustering Keys: данные физически сортируются по ключу - `WHERE date = '2024-01-01'` сканирует только нужный micro-partition.
  • **Auto-suspend warehouses**: Snowflake warehouse с auto-suspend 5 минут. 80% warehouses простаивают ночью - suspend = $0 compute.
  • **Data retention policies**: Snowflake Time Travel 90 дней стоит 2x от storage. Для большинства таблиц достаточно 7-14 дней. Fail Safe (дополнительные 7 дней) нельзя отключить, но Time Travel можно.
  • **Query optimization**: `SELECT *` -> `SELECT needed_columns`. Materialized views для часто используемых агрегатов. Result cache в Snowflake: идентичный запрос за 24 часа не тратит compute.
  • **Storage tiering**: S3 Intelligent-Tiering. Данные старше 90 дней -> S3 IA (Infrequent Access), старше 1 года -> S3 Glacier. Экономия 40-70% на хранении.

Дешевле хранить все данные навсегда - storage дешёвый, а удалить потом сложно

Стоимость хранения включает: S3 storage + Snowflake Time Travel + query scan costs + governance overhead (каждый датасет нужно документировать). Retention policy + tiering снижает total cost of ownership на 30-60%

Snowflake Time Travel 90 дней = 90 дней * 2x storage overhead. Для таблицы 10 TB это 900 TB*дней хранения ежемесячно. При $23/TB/месяц = $20 700 только за Time Travel. 14 дней Time Travel -> $3 220. Разница $17 000/месяц за одну таблицу.

BigQuery таблица 10 TB, запросы каждые 5 минут фильтруют по `created_date`. BigQuery стоимость $5 per TB scan. Как снизить стоимость?

Ключевые идеи

  • **Lakehouse архитектура**: Bronze/Silver/Gold медальонная архитектура на Delta Lake/Iceberg объединяет lake (дешёвое хранение) и warehouse (ACID, схема) преимущества.
  • **Multi-tenancy**: изоляция compute через Virtual Warehouses или cluster pools. Cost chargeback incentivizes экономию. Resource quotas защищают от runaway queries.
  • **Self-service**: semantic layer (dbt Metrics), data catalog, governed notebooks. 90% аналитических задач без data engineers.
  • **Cost optimization**: партиционирование + clustering (10-100x scan reduction), auto-suspend, retention policies, storage tiering.

Связанные темы

Data Platform объединяет все слои data stack:

  • Data Governance и Catalog — Unity Catalog (Databricks) и DataHub встраиваются в платформу для federated governance; без catalog self-service невозможен
  • Streaming: Kafka и Flink — Современная платформа включает streaming layer (Kafka) для real-time ingestion рядом с batch ETL; Lambda/Kappa архитектуры

Вопросы для размышления

  • Data Mesh предлагает federated ownership: каждая команда owns свои данные. Но если quality у команды плохое - страдают все downstream потребители. Как balancer autonomy с centralized standards?
  • Snowflake auto-suspend экономит деньги, но первый запрос после suspend занимает 10-30 секунд на «прогрев». Как проектировать platform SLA с учётом этой особенности?
  • BigQuery on-demand pricing ($5/TB) vs flat rate ($2000/месяц, неограниченные запросы). При каком объёме запросов в месяц flat rate выгоднее? Как принять это решение?

Связанные уроки

  • sd-01-intro
Data Platform Architecture

0

1

Войти