Фреймворк выбора формата по workload
Предыдущие 16 модулей разобрали каждый формат в деталях: внутреннее устройство, кодировки, транзакции, экосистему. Но на практике вопрос не “как работает Iceberg?”, а “какой формат решает мою задачу?”. Этот модуль переворачивает перспективу: вместо “формат → фичи” мы идём от “workload → требования → формат”.
WARNING
Этот модуль — не повторение сравнительных таблиц из ORC vs Parquet, Avro vs альтернатив, сериализации или next-gen форматов. Мы используем те сравнения как справочник, но строим решение от рабочей нагрузки, а не от фичей формата.
Почему feature matrix не работает
Типичная ошибка — сравнивать форматы по чеклисту: “поддерживает schema evolution? +/−”. Проблема в том, что контекст определяет вес каждого критерия:
Feature Matrix
Feature matrix: список фичей в таблице, галочки напротив каждого формата. Выглядит объективно, но все критерии имеют одинаковый вес — это не отражает реальность.ПроблемаВсе критерии равноценны в матрице. Но для стриминг-pipeline schema evolution критичен (данные меняются), а для ad-hoc аналитики — нет. Для ML random access решает всё, а для ETL — не нужен. Равные веса = неверный выбор.
Формат с максимумом + Не оптимален для задачи
Результат: выбирается формат с максимальным числом галочек — но это не значит, что он оптимален для конкретной задачи. Parquet 'побеждает' по числу фичей, но проигрывает Lance в ML-задачах и Avro в стриминге.Workload-First
Workload-first: начинаем с анализа рабочей нагрузки — какие операции доминируют, какая латентность допустима, как часто меняется схема, каков паттерн записи/чтения.ПодходСначала определяем архетип workload'а. Затем выделяем 2-3 критических требования, которые формат обязан удовлетворить (deal-breakers). Остальные фичи — nice-to-have. Это сужает выбор до 1-2 форматов.
Формат под конкретную задачу Оптимален по deal-breakers
Результат: формат, оптимальный для конкретного набора операций. Может не иметь максимума галочек в feature matrix, но закрывает именно те требования, которые критичны.Четыре архетипа workload’ов
Большинство data-pipeline’ов попадают в один из четырёх архетипов. Каждый предъявляет свой набор критичных требований:
OLAP / АналитикаОсновной паттерн: scan колонок с фильтрацией по предикатам. Типичные запросы: агрегации, JOIN'ы, GROUP BY. Данные записываются пакетно (batch ingest), читаются часто и разнообразно. Главные требования: scan throughput, predicate pushdown, compression ratio.
Стриминг / CDCОсновной паттерн: непрерывная запись мелких батчей (micro-batch или row-level), чтение инкрементальных изменений. Данные приходят из Kafka/Flink/CDC. Главные требования: write latency, schema evolution, upsert support, incremental reads.
ML / AIОсновной паттерн: случайный доступ к строкам (mini-batch sampling), vector search для retrieval, версионирование датасетов для воспроизводимости. Данные: embedding'и, feature stores, training sets. Deal-breakers: random access speed, vector search, dataset versioning.
Операционный / OLTPОсновной паттерн: point reads/writes с низкой латентностью. Обновление одной строки, чтение одной строки по ключу. Аналитические форматы здесь — компромисс: они не заменяют OLTP-базы, но могут обслуживать serving layer с near-real-time обновлениями.
NOTE
Реальные pipeline’ы часто комбинируют архетипы: CDC-поток (стриминг) наполняет lakehouse, на котором работает аналитика (OLAP) и ML-pipeline (ML/AI). В этом случае выбирается формат, оптимальный для доминирующего архетипа, а остальные обслуживаются с приемлемым компромиссом.
Decision Tree: от workload к формату
Вместо таблицы — дерево решений. На каждом уровне — один вопрос, ответ сужает множество кандидатов:
Какой паттерн доступа доминирует?
Первый вопрос: какой паттерн доступа к данным доминирует? Sequential scan (read all/most columns), random point access (read specific rows), или continuous ingest (write-heavy, micro-batches)? Этот вопрос отсекает 50-70% неподходящих форматов.Sequential ScanКолоночные форматы оптимальны: Parquet, ORC, Arrow. Следующий вопрос: нужны ли ACID-транзакции и schema evolution? Если да → table format поверх Parquet.
Нужны ACID транзакции?
Нужны ACID, time travel, schema evolution? Если данные — stateless файлы в data lake без обновлений — достаточно голого Parquet/ORC. Если нужны транзакции, обновления, инкрементальные чтения — нужен table format.НетRead-only данные без обновлений: ETL результаты, архивы, партиционированные export'ы. Parquet — де-факто стандарт. ORC — если Hive ecosystem. Простейший путь.
ДаНужны транзакции → table format. Следующий вопрос: какая экосистема? Spark-first → Delta Lake. Vendor-neutral → Iceberg. Flink-first → Paimon.
Random AccessНужен быстрый доступ к конкретным строкам по ID или через vector search. Parquet/ORC неэффективны: page-level granularity. Lance или специализированные решения.
Нужен vector search?
Нужен vector search (nearest neighbor по embedding'ам)? Если да — Lance (встроенный IVF-PQ/HNSW). Если нет (feature store без embeddings) — Parquet + point-query оптимизация или Lance для random access speed.ДаLance — единственный open-source формат со встроенным vector search. Альтернатива: Parquet + отдельный vector DB (Pinecone, Milvus), но это два компонента вместо одного.
НетБез vector search, но с random access: Lance (100x vs Parquet) или Parquet + row-group level indexing. Для feature stores: Hudi MOR (record-level index) или Lance.
Continuous IngestНепрерывная запись: Kafka → format → query engine. Важны: write latency (мелкие батчи быстро), upsert (обновление по ключу), schema evolution (данные меняются). Row-oriented форматы для транспорта, columnar для хранения.
Транспорт или хранение?
На каком этапе pipeline'а? Транспорт (Kafka topics, message queues) → row-oriented форматы (Avro, Protobuf). Хранение (lakehouse) → table formats с upsert (Hudi, Delta, Paimon).ТранспортKafka/Pulsar/Kinesis: Avro (Schema Registry, schema evolution) или Protobuf (компактность, gRPC совместимость). JSON — legacy, избегать для новых pipeline'ов. См. детали: Модуль 04 (Avro), Модуль 05 (Protobuf).
ХранениеLakehouse-хранение стриминг-данных: Hudi (MOR для low-latency upsert), Delta Lake (streaming tables), Paimon (Flink-native). Выбор зависит от engine: Flink → Paimon, Spark → Delta/Hudi.
Архетип 1: OLAP / Аналитика
Аналитический workload — самый распространённый случай. Данные записываются пакетно (ETL/ELT), читаются ad-hoc запросами и BI-инструментами.
OLAP Workload
Аналитический workload: SELECT с агрегациями, GROUP BY, JOIN. Читаются 3-5 колонок из 100+ доступных. Предикаты отсекают 90%+ строк. Формат должен минимизировать I/O: читать только нужные колонки и строки.Must HaveБез этих свойств формат непригоден для OLAP. Columnar layout — возможность читать отдельные колонки. Predicate pushdown — пропуск данных по statistics. Compression — сжатие экономит I/O и storage.
Nice to HaveЖелательно, но не deal-breaker. ACID — если данные обновляются. Schema evolution — если схема меняется. Time travel — для аудита и дебага.
Не нужноЭти свойства для OLAP неважны или даже вредны (усложняют формат). Random access к отдельным строкам — не паттерн аналитики. Vector search — ML-задача. Low-latency writes — данные пишутся пакетно.
Без транзакцийStateless Parquet/ORC файлы: простейший путь для read-only данных. ETL записывает партиционированные файлы, query engine читает. Нет metadata overhead. Работает везде: Spark, Presto, DuckDB, Polars, Pandas.
С транзакциямиTable format поверх Parquet: Delta Lake (Spark), Iceberg (vendor-neutral), Paimon (Flink). Добавляют ACID, time travel, schema evolution. Overhead: metadata management, compaction. Оправдан если данные обновляются или нужен audit trail.
Когда Parquet без table format достаточен
Если ваш pipeline — чистый batch ETL без обновлений и удалений:
- Данные записываются один раз, читаются много раз (write-once, read-many)
- Нет необходимости в ACID-транзакциях (нет конкурентных writer’ов)
- Schema не меняется или меняется крайне редко (добавление колонок — ручной процесс)
- Нет требований к time travel или аудиту
В этом случае table format — overhead. Parquet файлы + партиционирование по дате/региону + Hive metastore или Glue Catalog — проверенная простая архитектура.
Когда нужен table format
Table format оправдан когда:
- Данные обновляются (MERGE/UPDATE/DELETE)
- Нужен time travel для аудита или дебага
- Конкурентные writer’ы (несколько pipeline’ов пишут в одну таблицу)
- Schema evolution — поля добавляются/удаляются/переименовываются регулярно
- Incremental processing — downstream pipeline’ы читают только изменения
Выбор между Delta Lake, Iceberg и Paimon — тема урока 03.
Архетип 2: Стриминг / CDC
Streaming / CDC Pipeline
Стриминг-pipeline состоит из двух фаз: транспорт (message broker → consumer) и хранение (consumer → lakehouse/warehouse). Каждая фаза предъявляет разные требования к формату данных.Фаза 1: ТранспортKafka / Pulsar / Kinesis. Данные сериализуются в сообщения. Требования: компактность (меньше байт = дешевле), schema evolution (producer может добавить поле, consumer не падает), десериализация speed. Row-oriented формат.
AvroAvro + Schema Registry — стандарт для Kafka. Compactный бинарный формат, schema evolution с full/transitive/forward/backward compatibility. Confluent Schema Registry — production-ready. Подробнее: Модуль 04, урок 05.
ProtobufProtobuf — если ecosystem уже gRPC/Protobuf. Compактнее Avro на 10-20% для мелких сообщений. Schema evolution через field numbers. Confluent Schema Registry поддерживает Protobuf с версии 5.5+.
Фаза 2: ХранениеLakehouse / Warehouse. Данные из стрима материализуются в таблицы для аналитики. Требования: upsert (CDC → обновление строк по ключу), incremental reads (downstream читает только изменения), compaction (мелкие файлы → большие).
HudiHudi MOR (Merge-on-Read) — оптимален для CDC: record-level index → upsert за O(log N), log files → мгновенная запись. Compaction в фоне. Incremental queries через timeline. Подробнее: Модуль 13, уроки 02 и 05.
PaimonPaimon — если engine = Flink. LSM-tree хранение: мгновенная запись (append to memtable), merge в фоне. Changelog producer для downstream CDC. Bucket partitioning. Подробнее: Модуль 14.
TIP
Delta Lake и Iceberg тоже поддерживают стриминг-запись (Structured Streaming → Delta, Flink → Iceberg). Но у них нет нативного record-level index — upsert на больших таблицах дороже, чем у Hudi/Paimon. Если латентность upsert критична (минуты, не часы) — Hudi MOR или Paimon.
Архетип 3: ML / AI
ML / AI Pipeline
ML-pipeline: training data → feature engineering → model training → serving. Каждая фаза требует особого паттерна доступа: random sampling для training, vector search для retrieval, versioning для воспроизводимости.Training DataХранение обучающих данных: изображения, тексты, embedding'и, табличные фичи. Требования: random access для mini-batch sampling (DataLoader), dataset versioning для воспроизводимости, большие BLOB'ы (embedding'и 768-4096 dim).
Feature StoreОнлайн-хранение features для inference. Требования: point lookup по entity_id (латентность < 10ms), batch read для обучения, incremental updates при появлении новых данных.
Vector IndexRetrieval-Augmented Generation (RAG), semantic search, recommendation. Требования: nearest-neighbor search по embedding'ам, sub-millisecond latency, масштабирование до миллиардов векторов.
LanceLance закрывает все три задачи: random access (100x vs Parquet), встроенный IVF-PQ/HNSW vector index, version log для dataset versioning. Единственный формат с нативной поддержкой ML-паттернов. Подробнее: Модуль 15, уроки 01-02.
Parquet + Vector DBАльтернатива: Parquet для табличных данных + отдельный vector database (Pinecone, Milvus, Weaviate) для embedding'ов. Два компонента вместо одного. Больше ops overhead, но каждый компонент — mature production-ready система.
Когда Parquet + Vector DB лучше Lance
Lance — молодой формат (production с 2023). Parquet + отдельный vector DB оправдан когда:
- Команда уже эксплуатирует Pinecone/Milvus/Qdrant в production
- Табличные данные и embedding’и имеют разные lifecycle’ы (разные retention, разные pipeline’ы)
- Нужна managed-инфраструктура (Pinecone Serverless, Zilliz Cloud)
- Scale > 10B vectors — специализированные vector DB оптимизированы для этого масштаба
Lance оправдан когда нужно единое хранилище для табличных данных и embedding’ов, и dataset versioning — first-class citizen.
Архетип 4: Операционный / OLTP-like
Operational / Near Real-Time
Операционный паттерн: чтение/запись одной строки по ключу с низкой латентностью. Это НЕ классический OLTP (PostgreSQL/MySQL) — это serving layer, где аналитические данные отдаются приложению в реальном времени.Ограничения аналитических форматовАналитические форматы (Parquet, ORC) не предназначены для point reads: чтение одной строки = загрузить row group (~128MB) + декодировать page. Latency: 100ms+ вместо < 1ms у OLTP-баз. Update: перезапись целого файла.
Компромиссные решенияДля near-real-time serving: Hudi MOR (record-level index для point lookup, upsert через log files) или Delta Lake + Databricks Serverless (query caching). Не < 1ms, но 10-50ms на point reads — достаточно для serving layer.
РекомендацияДля настоящего OLTP (< 1ms latency, row-level transactions) — используйте OLTP-базу (PostgreSQL, MySQL, DynamoDB). Для near-real-time serving layer (10-50ms, read-heavy) — Hudi MOR или materialized views в DuckDB. Аналитические форматы не заменяют OLTP-базы.
WARNING
Распространённая ошибка — пытаться заменить OLTP-базу на Delta Lake или Iceberg. Table formats оптимизированы для scan’ов и batch operations, не для point reads с миллисекундной латентностью. Если приложению нужен OLTP — используйте OLTP-базу, синхронизируйте через CDC в lakehouse для аналитики.
Сводная карта: workload → формат
WorkloadЧетыре основных архетипа рабочих нагрузок. Реальные системы — комбинации, но доминирующий архетип определяет выбор основного формата.
PrimaryОсновной рекомендуемый формат — оптимален для данного архетипа. Начинайте с него.
AlternativeАльтернатива — выбирается при дополнительных ограничениях (ecosystem lock-in, масштаб, команда).
AvoidНе рекомендуется: формат не оптимален для данного паттерна, даже если технически может работать.
OLAPАналитические scan-тяжёлые запросы: DWH, BI, ad-hoc SQL. Batch ingest, read-heavy.
Parquet: де-факто стандарт для аналитики. Максимальная engine-совместимость. С table format (Iceberg/Delta) для ACID.
ORC: если Hive/Presto ecosystem. Чуть лучше compression для некоторых типов данных, но уже экосистема.
Avro: row-oriented, нет predicate pushdown, нет column projection. Не для аналитических scan'ов. JSON/CSV: ещё хуже.
StreamingНепрерывная запись мелких батчей, CDC, event sourcing. Write-heavy, upsert, schema evolution.
Транспорт: Avro + Schema Registry. Хранение: Hudi MOR (upsert) или Paimon (Flink).
Protobuf для транспорта (gRPC ecosystem). Delta Lake Streaming Tables для хранения (Spark ecosystem).
Голый Parquet без table format: нет upsert, нет incremental reads, нет schema evolution. JSON в Kafka: 5-10x overhead по размеру.
ML/AIRandom access, vector search, dataset versioning. Training pipelines, feature stores, RAG.
Lance: random access 100x Parquet, встроенный vector search, нативное версионирование. Единственный формат для ML-native pipeline.
Parquet + отдельный vector DB (Pinecone, Milvus): если команда уже эксплуатирует managed vector DB. Больше компонентов, но mature.
ORC: нет преимуществ для ML. Avro: row-oriented, медленный scan. Hudi/Iceberg: overhead table format не нужен для read-heavy ML.
OLTP-likePoint reads/writes, low latency. Serving layer, operational analytics.
OLTP-база (PostgreSQL) + CDC в lakehouse. Для serving layer: Hudi MOR с record-level index. DuckDB embedded для hybrid.
Delta Lake + Databricks SQL Serverless: query caching снижает latency для повторяющихся запросов. Не < 1ms, но 10-50ms.
Голый Parquet: point read = загрузка row group (100ms+). Iceberg: нет record-level index. Не для point reads.
Мультиформатные архитектуры
Реальные production-системы редко используют один формат. Типичная архитектура — разные форматы для разных слоёв:
Sources (App, IoT, API)
Источники данных: приложения, IoT-устройства, API. Генерируют события в реальном времени. Формат: JSON/Protobuf на выходе из приложения.Transport LayerKafka / Pulsar / Kinesis. Формат сообщений: Avro или Protobuf + Schema Registry. Row-oriented, оптимизирован для последовательной записи/чтения отдельных событий.
Storage LayerData Lakehouse: S3/GCS/ADLS. Table format: Iceberg или Delta Lake для ACID, time travel, schema evolution. Физический формат: Parquet. Оптимизирован для scan'ов и аналитики.
ML LayerFeature store / training data. Lance для embedding'ов и training datasets. Dataset versioning для ML experiments. Vector index для RAG/retrieval.
Serving LayerApplication-facing API. Данные из lakehouse материализуются в serving store для low-latency reads. Redis/DynamoDB для point reads, DuckDB embedded для hybrid queries.
TIP
Ключевой принцип: каждый слой использует формат, оптимальный для своего паттерна доступа. Не пытайтесь найти один формат для всего pipeline’а. CDC из PostgreSQL в Avro → материализация в Iceberg → export embeddings в Lance → serving через DuckDB — это нормальная архитектура, не over-engineering.
Итоги
Шаг 1Определите доминирующий архетип workload'а: OLAP, Streaming, ML/AI, или Operational. Если комбинация — выберите доминирующий по объёму данных и частоте запросов.
Шаг 2Для выбранного архетипа выделите 2-3 критических требования (deal-breakers). Остальные свойства — nice-to-have. Deal-breakers сужают множество кандидатов до 1-2 форматов.
Шаг 3Проверьте совместимость с экосистемой: query engine (Spark/Flink/DuckDB/Presto), orchestrator (Airflow/Dagster), storage (S3/GCS/ADLS), cloud provider. Формат бесполезен, если его не читает ваш engine.
Шаг 4Бенчмарк на своих данных. Синтетические бенчмарки (TPC-H, TPC-DS) — стартовая точка, но ваши данные, ваши запросы, ваш hardware — уникальны. Методология бенчмаркинга — следующий урок.
В следующем уроке — как правильно проводить бенчмарки форматов: методология, типичные ошибки, воспроизводимость результатов.