Case Studies: формат в контексте
Теория — в предыдущих уроках. Здесь — четыре реалистичных сценария, в которых команды применяют фреймворк выбора (урок 01), методологию бенчмаркинга (урок 02) и стратегии миграции (урок 04).
Каждый case study следует структуре: контекст → workload → выбор → миграция → результат.
Case Study 1: E-Commerce — CSV→Parquet→Iceberg
Контекст
Средний e-commerce (50M заказов/год, 2 TB сырых данных в месяц). Исторически: ETL в Airflow записывает CSV в S3, Athena для ad-hoc запросов, Looker для BI dashboards. Боль: Athena-запросы дорогие (scan всех данных), нет schema enforcement, новые аналитики ломают pipeline’ы неправильными типами.
Источники: PostgreSQL + Shopify + GA
Источники: PostgreSQL (orders, products, users), Shopify API (transactions), Google Analytics (events). Airflow DAG'ы: 15 ETL jobs, каждый записывает CSV в S3 партиционированный по date.ETL (Airflow)15 DAG'ов: extract → transform (Python/Pandas) → load CSV в S3. Проблемы: Pandas inference типов (string vs int), нет schema validation, encoding issues (UTF-8 BOM в CSV от Shopify).
Storage (S3)s3://analytics/orders/date=2025-01-01/part-001.csv. 24 TB исторических CSV. Athena scan cost: ~$5/TB scanned × 24 TB = $120 per full scan. 50+ analysts = $3000-5000/month на Athena.
ConsumersAthena: ad-hoc SQL (50 analysts). Looker: BI dashboards (10 dashboards, hourly refresh). ML team: feature extraction (Pandas read CSV). Все читают CSV → полный scan всегда.
Применение фреймворка
Шаг 1: АрхетипДоминирующий workload: OLAP/аналитика. 50 аналитиков пишут SQL запросы с GROUP BY, JOIN, WHERE. Batch ingest (Airflow DAGs). Нет streaming, нет ML-heavy random access, нет OLTP.
Шаг 2: Deal-BreakersMust-have: (1) Column projection — Athena charges per byte scanned, columnar = 5-20x savings. (2) Predicate pushdown — отсечь 90%+ данных по date. (3) Schema enforcement — остановить pipeline на невалидных данных.
Шаг 3: ВыборФормат: CSV → Parquet (columnar, compression, schema). Table format: Iceberg (multi-engine: Athena + Spark + DuckDB, schema evolution, time travel для debug). Не Delta (нет Databricks). Не Hudi (нет CDC).
Результат
Storage24 TB CSV → 3.2 TB Parquet (ZSTD-3). Compression ratio: 7.5x. S3 cost: $552/month → $74/month. Savings: $478/month ($5,736/year).
Query CostAthena cost per query: $5/TB × scan volume. CSV: scan all 24 TB = $120/query (full scan). Parquet + predicate pushdown: scan ~0.3 TB/query (avg) = $1.50/query. Monthly: $4,200 → $630. Savings: $3,570/month ($42,840/year).
Query SpeedTypical dashboard query (7-day window, 3 columns): CSV 45s → Parquet/Iceberg 3.2s (14x). Complex analytical (JOIN + GROUP BY, 90-day): CSV 180s → Parquet/Iceberg 22s (8x). p99 dashboard < 10s (SLA met).
Case Study 2: FinTech — Kafka+Avro → Hudi MOR
Контекст
Финтех-платформа (платежи): 500K транзакций/час, CDC из PostgreSQL через Debezium → Kafka. Требования: near-real-time аналитика (< 5 минут задержки), fraud detection (ML), regulatory compliance (7-year retention, audit trail).
PostgreSQL → Debezium CDC → Kafka (Avro)
PostgreSQL (OLTP): transactions, accounts, merchants. Debezium CDC connector: capture INSERT/UPDATE/DELETE → Kafka topics. Avro + Schema Registry: строгая схема сообщений. 500K events/hour = ~140 events/second.ТранспортKafka: 3 topics (transactions, accounts, merchants). Avro + Confluent Schema Registry: schema evolution (backward compatible). Retention: 72 hours. Consumer group: Flink/Spark Structured Streaming.
ХранениеТребования к хранению: (1) upsert по transaction_id (CDC: UPDATE = delete old + insert new), (2) incremental reads (fraud ML читает только новые транзакции), (3) time travel (regulatory: показать состояние на любую дату за 7 лет).
Consumers1. Near-real-time dashboard (Superset, 5-min refresh). 2. Fraud ML model (Spark, reads incremental changes every 5 min). 3. Regulatory reports (monthly, full scan). 4. Ad-hoc SQL (analysts, Trino).
Применение фреймворка
АрхетипСтриминг/CDC — доминирующий workload. 500K upserts/hour, continuous ingest из Kafka. Вторичный: OLAP (dashboards, reports). Третичный: ML (incremental reads).
Deal-Breakers1. Upsert latency < 5 min (CDC events → queryable). 2. Incremental reads (fraud ML reads only new/changed). 3. Time travel (7 лет, regulatory). Iceberg/Delta: upsert дороже (нет record-level index). Paimon: нет Trino support.
Выбор: Hudi MORHudi MOR: (1) Record-level index → O(log N) upsert (не full file scan). (2) Incremental queries через Timeline. (3) Time travel через Savepoints. Engine: Spark Structured Streaming (write) + Trino (read).
Результат
LatencyCDC → queryable: 2.5 минуты (median). Pipeline: Debezium → Kafka (seconds) → Spark Structured Streaming → Hudi MOR (micro-batch every 2 min) → Trino read. SLA 5 min: met with margin.
Upsert500K upserts/hour через record-level index: O(log N) per record. Compaction async: каждые 4 часа. Без compaction: read amplification 1.3x (log files). С compaction: 1.0x. Spark cluster: 8 × c5.2xlarge.
ComplianceTime travel: 7 лет через snapshot retention + S3 Glacier archival. Regulatory query: 'показать состояние account X на 2023-03-15 12:00' → Hudi time travel query. Audit trail: Hudi Timeline содержит все операции с timestamps.
Case Study 3: ML-платформа — Parquet → Lance
Контекст
ML-платформа для e-commerce рекомендаций: 100M product embeddings (768 dimensions, CLIP), training dataset 500M rows, weekly retraining. Боль: DataLoader bottleneck — Parquet random access для mini-batch sampling = 60% training time spent on I/O.
PyTorch DataLoader → Parquet (S3)
Training pipeline: PyTorch DataLoader → read random mini-batches (1024 rows) → model forward/backward → update weights. Текущее хранение: Parquet files в S3 (~2 TB). DataLoader: random row access через PyArrow.ПроблемаParquet random access: ~1ms per row (page decode). Mini-batch 1024 rows: ~1024ms (1 second). GPU idle while waiting for data: 60% of training time. GPU utilization: 40% (expensive A100 GPUs underutilized).
Дополнительная боль1. Нет dataset versioning: ML experiment tracking (MLflow) не привязан к конкретной версии данных. 'Какой dataset использовался в experiment #42?' — неизвестно. 2. Vector search: для RAG нужен kNN по embeddings → отдельный Pinecone instance ($$$).
Решение: Lance
АрхетипML/AI workload: random access (DataLoader), vector search (RAG/recommendations), dataset versioning (experiment tracking). Все три deal-breakers → Lance.
МиграцияDual read pattern (урок 04): Lance primary, Parquet shadow. Конвертация 2 TB Parquet → Lance: 4 часа на c5.4xlarge. Vector index creation (IVF-PQ, 100M vectors): 45 минут. Валидация: 1 неделя dual read, 0 mismatches.
ИнтеграцияPyTorch DataLoader: lance.dataset().take(ids) вместо pyarrow.parquet.read_row_group(). LanceDB для vector search: заменяет Pinecone. MLflow: dataset version tag = Lance version number.
Результат
Training SpeedRandom access: 1ms → 10μs (100x). Mini-batch 1024: 1024ms → 10ms. GPU utilization: 40% → 92%. Training time: 8 hours → 3.5 hours (weekly retraining). GPU cost savings: $1200/month (fewer A100-hours).
Vector SearchLance IVF-PQ: kNN search 100M vectors in < 5ms (p99). Заменяет Pinecone. Cost: $0 (Lance self-hosted) vs $2000/month (Pinecone). Tradeoff: ops overhead (self-managed), но dataset и vectors — в одном месте.
ReproducibilityDataset versioning: каждый training run тегирует Lance version. MLflow experiment #42 → Lance version 17. Reproducing: lance.dataset(version=17) → exact same data. Rollback: lance.dataset(version=15) если v17 data quality issues.
Case Study 4: Multi-Tenant SaaS — Delta Lake + UniForm
Контекст
B2B SaaS-платформа (data analytics): 200 tenants, каждый с собственными данными (1-50 TB). Databricks — primary compute. Некоторые enterprise tenants требуют доступ через Snowflake (corporate standard). Боль: поддерживать два формата (Delta для Databricks, Iceberg для Snowflake) = двойной pipeline.
200 tenants × 1-50 TB = ~2 PB total
200 tenants: isolated S3 prefixes (s3://data/{tenant_id}/). Ingest: Databricks Structured Streaming from Kafka. Compute: Databricks (primary), Snowflake (10 enterprise tenants). Проблема: enterprise tenants хотят Snowflake access → нужен Iceberg.Databricks (primary)190 tenants: Databricks-only. Delta Lake — natural fit. Photon engine, Auto-optimize, Liquid Clustering. Unity Catalog для governance. Всё работает.
Snowflake (enterprise)10 enterprise tenants: corporate standard = Snowflake. Требуют External Tables в Snowflake, читающие те же данные. Snowflake понимает Iceberg, не Delta. Без UniForm: нужен dual write (Delta + Iceberg) = 2x pipeline cost.
Решение: Delta Lake + UniForm
Delta Lake 3.x + UniForm: авто-генерация Iceberg metadata
Delta Lake 3.x UniForm: при каждом commit Delta автоматически генерирует Iceberg-совместимые metadata (manifests, snapshots). Данные хранятся ОДИН раз в Delta формате. Iceberg readers (Snowflake) читают через сгенерированные Iceberg metadata.Write PathЕдинственный write path: Databricks → Delta Lake. UniForm автоматически генерирует Iceberg metadata при каждом commit. Нет dual pipeline. Нет дополнительного compute. Overhead: ~5% на metadata generation.
Databricks Read190 tenants: Delta Lake read через Photon. Без изменений. Максимальная производительность: Photon оптимизирован под Delta.
Snowflake Read10 enterprise tenants: Snowflake External Tables, указывающие на Iceberg metadata (сгенерированные UniForm). Snowflake читает Parquet data files через Iceberg manifest'ы. Read-only: write только через Databricks.
Результат
Cost SavingsБез UniForm: dual pipeline (Delta write + Iceberg write) = 2x compute для 10 tenants (~50 TB). С UniForm: 0 дополнительного compute. Savings: ~$3,500/month (Spark compute для Iceberg write). Storage: 0 дополнительный (metadata-only).
ComplexityОдин pipeline вместо двух: проще мониторинг, меньше точек отказа, одна schema of truth. Data consistency: гарантированная (один write path). Rollback: стандартный Delta time travel.
ОграниченияUniForm ограничения: (1) Iceberg read-only (write только Delta). (2) Некоторые Iceberg features недоступны (hidden partitioning — через Delta partitioning). (3) Latency: Iceberg metadata генерируется после Delta commit (секунды задержки). (4) Databricks lock-in (UniForm — Databricks feature).
Сравнительная таблица case studies
CaseЧетыре case study с разными workload архетипами и форматными решениями.
АрхетипДоминирующий архетип workload'а по фреймворку из урока 01.
ФорматВыбранный формат (или комбинация форматов).
МиграцияИспользованный паттерн миграции.
Ключевой результатГлавная метрика улучшения после миграции.
E-commerce: 50M заказов/год, 50 аналитиков, Athena/Looker.
OLAP/аналитика: scan-heavy SQL запросы, BI dashboards, batch ingest.
CSV → Parquet (ZSTD-3) + Iceberg. Multi-engine: Athena + Spark EMR.
Shadow write: параллельная запись CSV + Parquet → валидация → switchover. In-place Iceberg migrate.
Query cost: $4,200 → $630/month. Query speed: 14x dashboard, 8x analytical.
FinTech: 500K transactions/hour, CDC pipeline, regulatory compliance.
Streaming/CDC: continuous Kafka ingest, upsert by key, incremental reads.
Kafka (Avro) → Hudi MOR. Spark Structured Streaming. Trino for reads.
Greenfield: новый pipeline, нет миграции существующих данных.
CDC → queryable: 2.5 min. Upsert: 500K/hr. 7-year compliance met.
ML-платформа: 100M embeddings, PyTorch DataLoader bottleneck.
ML/AI: random access (DataLoader), vector search, dataset versioning.
Parquet → Lance. LanceDB для vector search. MLflow version tagging.
Dual read: Lance primary + Parquet shadow. 1 week validation, 0 mismatches.
Training: 2.3x faster. GPU util: 40%→92%. Pinecone eliminated: $2K/month saved.
Multi-tenant SaaS: 200 tenants, Databricks primary, Snowflake for enterprise.
OLAP + multi-engine: Databricks (primary) + Snowflake (enterprise tenants).
Delta Lake + UniForm. Single write path, dual read (Delta + Iceberg).
UniForm activation: ALTER TABLE SET TBLPROPERTIES. No data migration needed.
Dual pipeline eliminated. Compute savings: $3,500/month. Single source of truth.
Уроки из case studies
Workload первиченВсе четыре команды начинали с определения workload'а, не с comparison матрицы форматов. E-commerce: OLAP → Iceberg. FinTech: CDC → Hudi. ML: random access → Lance. SaaS: multi-engine → UniForm. Формат — следствие workload'а.
Миграция ≠ Big BangНи одна команда не делала big bang migration. Shadow write (e-commerce), dual read (ML), gradual rollout (все). In-place migration где возможно (Hive→Iceberg metadata-only). Downtime: 0 во всех cases.
ROI очевиденSavings: от $5K до $50K/year на каждом case. Окупаемость миграции: 1-3 месяца. Основная экономия: compute/query cost (не storage). Неожиданный бонус: data quality (schema enforcement) — снижает downstream incidents.
Ecosystem решаетНи одна команда не выбирала формат по feature matrix. Решающие факторы: какой engine используем (Databricks → Delta), какие consumers (Snowflake → Iceberg), какой workload доминирует (CDC → Hudi, ML → Lance). Ecosystem > features.
Итоги модуля
Модуль 17 дал фреймворк для практического выбора формата:
- Урок 01: Определите архетип workload’а → выделите deal-breakers → сузьте до 1-2 форматов
- Урок 02: Бенчмаркайте на своих данных, по правильной методологии, публикуйте результаты
- Урок 03: Для table format: engine compatibility + streaming support + maintenance overhead → Iceberg / Delta / Hudi / Paimon
- Урок 04: Shadow write → gradual rollout → validate → cleanup. Никогда Big Bang
- Урок 05: Реальные сценарии подтверждают: workload-first выбор, in-place миграция, ROI за 1-3 месяца
В Модуле 18 (Capstone) вы примените весь этот фреймворк на практике: Docker-лаборатория с бенчмарками всех форматов на одном датасете.