Capstone-проект: обзор и требования
За 17 модулей мы разобрали форматы побайтово — от Parquet и ORC через Arrow до Delta Lake, Iceberg, Hudi и Paimon. Изучили кодировки, компрессию, schema evolution. В Модуле 17 построили decision framework.
Теперь пора применить всё вместе. Capstone-проект — это не экзамен с правильными ответами. Это инженерная задача с trade-offs, где вы проектируете реальную data-платформу и защищаете каждый выбор формата.
WARNING
Capstone-проект требует знания всех предыдущих модулей. Если вы пропустили workload archetypes или бенчмаркинг — вернитесь к ним перед началом.
Сценарий: мультиформатная data-платформа
Вы — data-архитектор в компании, которая строит платформу обработки данных для e-commerce. Платформа должна решать четыре задачи одновременно:
CDC Ingestion
Change Data Capture — захват изменений из OLTP-базы (PostgreSQL/MySQL) в реальном времени. Каждое INSERT/UPDATE/DELETE становится событием в Kafka. Формат: Avro или Protobuf.ИсточникOperational база: PostgreSQL с ~50 таблицами, ~10K транзакций/сек. Debezium коннектор публикует change events в Kafka. Schema меняется ~2 раза в месяц.
Lakehouse Storage
Lakehouse хранение — единая система хранения для всех данных: raw, curated, aggregated. Table format обеспечивает ACID, time travel, schema evolution поверх object storage.ФорматObject storage (S3/MinIO) + table format (Delta/Iceberg/Hudi). File format внутри: Parquet или ORC. Encoding и compression подбираются под тип данных.
Analytics Queries
Аналитические запросы — ad-hoc SQL от аналитиков и BI-дашборды. Требования: scan speed, predicate pushdown, partition pruning. Query engine: Spark SQL / Trino / DuckDB.ПотребителиАналитики (Jupyter + SQL), BI (Superset/Metabase), scheduled reports. SLA: ad-hoc запросы до 30 сек, BI-дашборды до 5 сек.
ML Features
ML Feature Extraction — вычисление фичей для моделей машинного обучения. Random access к конкретным строкам/колонкам. Batch и near-real-time. Feature store как промежуточный слой.PipelineFeature engineering на Spark/Arrow, хранение в feature store. Модели потребляют фичи через batch (training) и online (inference). Форматы: Parquet для batch, Arrow IPC для online.
Масштаб и ограничения
Платформа обслуживает средний e-commerce:
Объём данных~500 GB новых данных в день. За год — ~180 TB. Исторические данные хранятся 3 года. Пиковый объём storage: ~500 TB с учётом партиций, snapshots, time travel.
ThroughputIngestion: ~10K events/sec steady, ~50K events/sec peak (Black Friday). Kafka: 3 брокера, 12 партиций на топик. Consumer lag SLA: не более 5 минут.
Query SLAAd-hoc SQL: p95 под 30 секунд на запросах по последнему месяцу. BI дашборды: p95 под 5 секунд на pre-aggregated данных. Full-scan по 3 годам: до 5 минут.
ML RequirementsBatch features: вычисление раз в час, 200+ фичей на пользователя. Online features: p99 lookup под 10ms. Training: random access к 1 млн строк за ~30 сек. Все фичи должны быть point-in-time correct.
NOTE
Эти параметры — не абстракция. Они соответствуют реальному среднему e-commerce с 5-10 млн пользователей. Если ваш опыт — меньший масштаб, используйте числа как ориентир. Если больший — масштабируйте пропорционально.
Архитектура: от источника до потребителя
Capstone-проект охватывает полный путь данных. Вот референсная архитектура — ваша задача выбрать конкретные форматы на каждом уровне:
PostgreSQL (OLTP)
OLTP-база (PostgreSQL): источник правды. Debezium CDC коннектор читает WAL и публикует change events. Каждый event: before/after state + metadata (LSN, timestamp, op type).Clickstream (Web)
Clickstream — события из веб-приложения: page views, clicks, searches. Формат: JSON → Avro через Schema Registry. Объём: ~100K events/sec peak.External APIs
Внешние API: платёжные системы, доставка, CRM. Данные приходят в JSON/XML, конвертируются в единый internal формат. Объём: ~1K events/sec.Serialization + Schema Registry
Kafka + Schema Registry
Apache Kafka — центральная шина данных. Все потоки проходят через Kafka. Schema Registry обеспечивает контракт между producers и consumers. Retention: 7 дней (replayability).Consumers (Spark Structured Streaming / Flink)
Bronze (Raw)
Bronze layer: raw данные в исходной схеме. Минимальная трансформация — только десериализация + добавление metadata (ingestion timestamp, source). Append-only, full history.Формат?Выбор формата для bronze: file format (Parquet/ORC) + table format (Delta/Iceberg/Hudi). Критерии: write throughput (append-only), compression ratio, schema evolution (upstream schema меняется).
Silver (Curated)
Silver layer: очищенные, дедуплицированные данные. SCD Type 2 для dimensions. Merge/upsert операции. Партиционирование по бизнес-ключам (date, region).Формат?Silver требует merge/upsert — не все table formats одинаково эффективны. Copy-on-Write vs Merge-on-Read (см. Модуль 11-13). Encoding: dictionary для categorical, delta для timestamps.
Gold (Aggregated)
Gold layer: агрегированные данные для BI и ML. Materialized views, pre-aggregated metrics, feature tables. Оптимизировано для read — sort order, Z-order, column pruning.Формат?Gold оптимизирован для read performance. Sort order подбирается под типичные запросы. Compression: aggressive (данные меняются редко). Row group size: крупный для scan, мелкий для point lookups.
Query Engines
Spark SQL / Trino
Spark SQL / Trino — для ad-hoc и batch аналитики. Predicate pushdown, partition pruning, columnar vectorized reads. Подключение к table format через каталог (Hive Metastore / Nessie / Unity).Feature Store
Feature Store (Feast / Tecton) — для ML pipeline. Batch features из gold layer, online features из Redis/DynamoDB. Формат хранения offline features: Parquet. Online: Arrow IPC или custom binary.BI Dashboards
BI Tools (Superset / Metabase) — дашборды и отчёты. Подключение через SQL endpoint. Кеширование результатов. Pre-aggregated gold tables для быстрого отклика.Требования к проекту
Deliverables
Capstone-проект состоит из четырёх частей — по одной на каждый оставшийся урок:
1. Ingestion Pipeline DesignУрок 02: выбор serialization формата для Kafka, настройка Schema Registry, стратегия schema evolution. Обоснование: почему Avro/Protobuf, compatibility mode, consumer backward/forward compatibility.
2. Storage Layer DesignУрок 03: выбор file format + table format + encoding + compression для каждого слоя (bronze/silver/gold). Обоснование с привязкой к workload archetypes из Модуля 17.
3. Benchmark ResultsУрок 04: запуск Docker lab, сбор метрик (write throughput, scan speed, compression ratio, merge latency), интерпретация результатов, сравнение с ожиданиями из design document.
4. Format Selection ReportФинальный отчёт: обобщение всех решений, trade-offs, рекомендации. Формат: 1-2 страницы с диаграммами. Презентация перед воображаемым архитектурным комитетом.
Критерии оценки
Каждый deliverable оценивается по трём измерениям:
Техническая корректность
Техническая корректность: правильно ли описан формат? Совместимы ли выбранные encoding и compression? Соответствует ли table format workload? Нет ли фактических ошибок?Вес: 40%Самый важный критерий. Проверяет, что вы понимаете внутреннее устройство форматов. Пример ошибки: выбрать Dictionary encoding для колонки с высокой кардинальностью — технически неверно, потеря в размере и скорости.
Обоснование
Обоснование решений: каждый выбор привязан к конкретному требованию. Ссылки на материал курса. Trade-offs проговорены явно. Альтернативы рассмотрены и отвергнуты с причиной.Вес: 35%Не достаточно сказать 'выбрали Parquet'. Нужно: 'Parquet для bronze, потому что (1) columnar scan для аналитики [Модуль 02], (2) лучше compression ratio vs ORC при наших типах данных [Модуль 09], (3) Iceberg catalog поддерживает Parquet нативно [Модуль 12]'.
Практичность
Практическая реализуемость: можно ли это реально построить? Учтены ли operational concerns (мониторинг, compaction, vacuum)? Есть ли путь миграции если requirements изменятся?Вес: 25%Архитектура на бумаге может выглядеть идеально, но если она требует 50 Spark-нод для 500 GB/день — это overengineering. Если нет плана compaction — storage взорвётся за месяц. Практичность проверяет инженерное чутьё.
Как работать с capstone-проектом
Подход: workload-first
Используйте decision framework из Модуля 17:
- Определите workload — какой архетип (OLAP, streaming, ML, OLTP) доминирует на каждом уровне
- Выведите требования — из workload следуют конкретные требования (write throughput, scan speed, merge latency)
- Выберите формат — формат должен удовлетворять требованиям, а не наоборот
- Проверьте совместимость — encoding + compression + file format + table format должны работать вместе
- Обоснуйте — каждый выбор привязан к конкретному требованию и материалу курса
TIP
единственного “правильного” ответа. Разные комбинации форматов могут удовлетворять требования. Важно не что вы выбрали, а почему и какие trade-offs приняли.
Чего избегать
Нет Один формат на всё«Везде Parquet + Delta Lake» — ленивый ответ. Bronze, silver, gold имеют разные workloads. Ingestion и analytics — разные требования. Один формат не оптимален для всех слоёв.
Нет Выбор без обоснования«Выбрали ORC потому что он хороший» — не обоснование. Нужно: «ORC для silver-layer merge, потому что ACID в Hive Metastore [Модуль 03], native bloom filter для point lookups [Модуль 03, урок 04]».
Нет Игнорирование operationsКрасивая архитектура без compaction strategy, vacuum policy, monitoring — мёртвая архитектура. Production platform требует operational runbook: когда запускать compaction, как мониторить lag, что делать при schema change.
Нет OverengineeringТри table формата в одной платформе, custom encoding, real-time ML serving на 500 GB/день — overengineering. Платформа среднего размера не требует решений уровня Netflix. Простое решение, которое работает > сложное, которое теоретически лучше.
Навигация по capstone-урокам
Следующие три урока — пошаговое выполнение проекта:
| Урок | Тема | Основные модули-референсы |
|---|---|---|
| 02. Ingestion Pipeline | Serialization, Schema Registry, evolution | M04 Avro, M05 Protobuf, M10 Schema Evolution |
| 03. Storage Layer | File + table format, encoding, compression | M02 Parquet, M03 ORC, M08 Encoding, M09 Compression, M11-14 Table Formats |
| 04. Benchmarking | Docker lab, metrics, report | M17 Benchmarking |
NOTE
Рекомендуемый порядок: 02 → 03 → 04. Ingestion определяет формат данных в Kafka, storage layer потребляет эти данные, бенчмарки проверяют выбор. Но если хотите начать со storage layer — это тоже допустимо, при условии что serialization выбор потом согласуется.
Референсные материалы
Для каждого deliverable полезны конкретные уроки:
Ingestion (Урок 02):
- Avro schema design — правила проектирования Avro-схем
- Protobuf wire format — как Protobuf кодирует данные
- Schema Registry — конфигурация и compatibility modes
- Forward/backward compatibility — правила совместимости
Storage (Урок 03):
- Parquet file layout — row groups, column chunks, pages
- ORC file layout — stripes, indexes, bloom filters
- Encoding deep-dive — dictionary, RLE, delta, bit-packing
- Compression tuning — codec selection per column
- Delta Lake transactions — commit log, checkpoint, vacuum
- Iceberg metadata — manifest files, snapshot isolation
Benchmarking (Урок 04):
- Benchmarking methodology — dimensions, pitfalls, reproducibility
- Table format selection — criteria per workload
- Migration strategies — как мигрировать между форматами
Приступаем к первому deliverable — проектирование ingestion pipeline.