Case 05. High-volume Event Archive¶

Практикум · Связанная теория · Редакционный стандарт

Тип материала — практический архитектурный кейс. HYPOTHETICAL — все численные параметры, сценарий и схемы. INFERENCE — выбор и критерии. UNKNOWN — фактическая производительность и параметры, которые предстоит согласовать.

1. Business problem¶

Хранить большой поток для дешёвого replay, расследования и ad hoc queries при ограничениях object storage и catalog.

2. Functional requirements¶

Писать Parquet, хранить schema IDs и source offsets, сжимать, публиковать manifests, compact small files и удалять по policy.

3. Non-functional requirements¶

Объём и RTO replay измеряются отдельно от query latency. Reader видит целиком approved generation. Retention зависит от purpose и legal hold.

4. Assumptions и вопросы заказчику¶

Assumption — raw log нужен три дня, архив 90 суток, compressed ratio 4:1. Спросить scan patterns, cardinality tenants, timezone, evolution policy, egress и deletion SLA. UNKNOWN — реальная compression и cloud тарифы.

5. Оценка нагрузки и объёма данных¶

HYPOTHETICAL. Средняя скорость 22000 events/s, пик 44000 events/s, payload mean/p95/p99 800/1500/3000 B. Перцентили заданы отдельно для тестового профиля, среднее используется для объёма. Суточный профиль упрощён до постоянного среднего, накладные расходы протокола, индексов и WAL исключены.

Метрика	Формула и подстановка	Результат
Объём событий	22000 × 86 400	1900800000 событий/сутки
Сырые данные	1900800000 × 800 B	1520.64 GB/сутки
Retention без сжатия	1520.64 GB × 3 суток	4561.92 GB
Broker copies при RF=3	4561.92 GB × 3	13685.76 GB, из них 9123.84 GB дополнительные копии
Producer bandwidth, среднее	22000 × 800 × 8 / 10⁶	140.8 Mbit/s
Producer bandwidth, пик	44000 × 800 × 8 / 10⁶	281.6 Mbit/s
Partitions при 30% headroom	max(ceil(44000 × 1,3 / 1 500), ceil(44000 × 800 × 1,3 / 1 800 000))	39 partitions
Consumer parallelism	ceil(44000 × 1,3 / 1 500)	39 workers на группу при принятой производительности
Backfill одних суток при 3× средней capacity и живом среднем потоке	(22000 × 86 400) / (3 × 22000 − 22000)	43 200 с = 12 ч

GB и Mbit здесь десятичные. 1 500 events/s на partition/worker и 1,8 MB/s на partition — допущения теста. Для варианта без брокера строки RF/partitions относятся к альтернативному потоку или downstream outbox. RF не моделирует egress каждого consumer: добавьте по одной копии трафика на активную группу и репликационный трафик до RF−1 дополнительных копий. Пересчитайте отдельно при catch-up на пике, skew и p99 payload. Если capacity ≤ live rate, конечного времени восстановления нет.

Архив HYPOTHETICAL: 22 000 × 800 × 86 400 = 1 520,64 GB/сутки. При 4:1 получаем 380,16 GB/сутки, за 90 суток 34 214,4 GB. При 256 MB compressed на файл нижняя оценка ceil(380 160/256) = 1 485 файлов/сутки до дробления по partition. Cost = stored GB × тариф + requests × тариф + scanned GB × тариф + egress + compute. Compaction добавляет временные копии и I/O. RF строки выше относятся к Kafka, storage tier требует собственного overhead.

6. Варианты архитектуры¶

A — append objects по часу и topic с manifest. B — transactional table format поверх объектов с catalog snapshots и compaction. C — raw blobs на событие с простым writer.

7. Сравнение вариантов и выбор¶

Выбрать B при concurrent readers, compaction и schema evolution. A дешевле по метаданным, если один writer и простые queries. C создаёт высокую стоимость запросов и мелких файлов.

8. Component / data-flow¶

Иллюстративная схема выбранного варианта.

flowchart LR
 A["Kafka log"] --> B["Partitioned Parquet writer"]
 B --> C["Object storage and manifests"]
 C --> D["Query and replay jobs"]

9. Normal processing sequence¶

sequenceDiagram
 participant A as Kafka log
 participant B as Partitioned Parquet writer
 participant C as Object storage and manifests
 participant D as Query and replay jobs
 A->>B: Send identified input
 B->>C: Publish files for durable offset interval
 C-->>B: Return verified manifest generation
 B->>D: Advance only with durable evidence

Buffer по partition/time bucket. Записать Parquet и checksum, проверить source range, затем publish manifest с compare-and-set. Commit offsets после durable evidence либо связывать restart с manifest.

10. Failure / recovery sequence¶

sequenceDiagram
 participant B as Partitioned Parquet writer
 participant C as Object storage and manifests
 participant O as Recovery owner
 B->>C: Attempt write or advance
 Note over B,C: Writer dies after object upload before manifest
 O->>C: Reconcile immutable files and commit generation
 C-->>O: Durable outcome or explicit gap

Crash после upload оставляет orphan objects. Новый writer читает committed manifest, повторяет тот же range с deterministic object identity или пишет новую generation. Cleanup только после проверки, что файл вне reachable snapshots и retention window.

11. Data model и contracts¶

Envelope содержит topic, partition, offset, source schema, event time, ingest date и payload. Manifest содержит contiguous offset ranges, file checksum, counts, schema versions и writer generation.

12. Consistency boundaries¶

Object PUT относится к одному объекту. Согласованность многих объектов задаётся publish protocol. Catalog commit и Kafka offsets сверяются отдельно. Reader фиксирует один manifest на запрос.

13. Scaling и capacity planning¶

Для managed S3 посчитать тарифы хранения, запросов и egress. Для MinIO дополнительно оценить диски, сеть, compute, операторское время и запас на rebuild. Коэффициент overhead зависит от фактической схемы защиты данных. Сравнивать варианты на одинаковом retention и тесте восстановления.

Partition по date/hour и ограниченному hash bucket, избегать player/tenant как отдельной директории для sparse workloads. Tune row-group и file size по scan economics. Отдельно измерить compaction headroom.

14. Observability¶

Small-file rate, manifest lag, orphan count, compression ratio, scan amplification, replay capacity и storage growth.

15. Data Quality и reconciliation¶

Сравнить source range coverage без дыр и перекрытий, проверить checksums, counts, field compatibility и selective replay.

16. Security и compliance¶

Разграничить writer, reader и cleanup roles. Encryption, scoped keys, retention, legal hold и доступ к raw PII. Удаление включает backups и catalog snapshots согласно policy.

17. Implementation roadmap¶

Начать с single-writer archive, проверить offset oracle, добавить compaction, lifecycle и периодический restore drill.

18. Testing и acceptance criteria¶

Убить writer между upload и publish, повторить batch, подать evolution с несовместимым типом, проверить orphan cleanup и replay. Критерий — один verified offset range и полное восстановление выбранного cut.

19. Trade-offs и ограничения¶

Большие файлы уменьшают request cost, но повышают задержку закрытия и повтор при сбое. Time partitions ускоряют типовые scans, а skew создаёт малые файлы в редких buckets.

20. Interview questions¶

Почему высокая object-store consistency не решает publication? Публикация многих файлов требует единицы видимости. Когда нужен compaction? Когда фактическая стоимость планирования и мелких запросов превышает стоимость переписывания и storage overlap.

Первичные источники¶

Проверка источников: 2026-11-03. Документация описывает свойства компонентов. Результаты испытаний выбранной системы требуют отдельного evidence.