Case 06. Dynamic Airflow Data Platform¶

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

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

1. Business problem¶

Оркестрировать независимые выгрузки с общей публикацией, повтором и изоляцией проблемного источника.

2. Functional requirements¶

Валидировать YAML, определить sources и cuts, выполнять mapped extraction, фиксировать результат, поддерживать selective backfill и replay.

3. Non-functional requirements¶

Уложиться в business close при bounded concurrency, fail isolation и reproducibility. Scheduler не хранит payloads и secrets.

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

Assumption — 120 sources, по 8 chunks в daily run, 40 slots и 90 с на chunk. Спросить source connection limits, зависимые cuts, failure policy, XCom backend, SLA отдельных datasets и кто подтверждает completeness.

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

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

Метрика	Формула и подстановка	Результат
Объём событий	350 × 86 400	30240000 событий/сутки
Сырые данные	30240000 × 2400 B	72.576 GB/сутки
Retention без сжатия	72.576 GB × 7 суток	508.032 GB
Broker copies при RF=3	508.032 GB × 3	1524.096 GB, из них 1016.064 GB дополнительные копии
Producer bandwidth, среднее	350 × 2400 × 8 / 10⁶	6.72 Mbit/s
Producer bandwidth, пик	700 × 2400 × 8 / 10⁶	13.44 Mbit/s
Partitions при 30% headroom	max(ceil(700 × 1,3 / 1 500), ceil(700 × 2400 × 1,3 / 1 800 000))	2 partitions
Consumer parallelism	ceil(700 × 1,3 / 1 500)	1 workers на группу при принятой производительности
Backfill одних суток при 3× средней capacity и живом среднем потоке	(350 × 86 400) / (3 × 350 − 350)	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, конечного времени восстановления нет.

960 tasks / 40 slots × 90 с = 2 160 с, 36 мин при равных chunks без overhead и failures. При 2× p95 длительности проверять tail отдельно. Таблица sizing относится к общему payload downstream archive; mapped concurrency определяется source quotas, а не partitions.

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

A — отдельный DAG на каждый источник. B — discovery плюс Dynamic Task Mapping для однородных inputs. C — внешний worker queue с Airflow на уровне manifest generations.

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

Выбрать B с лимитом chunk count, pools и task instance quotas. A нужен для разных owners/SLAs. C снижает нагрузку scheduler при очень мелких единицах работы, но усложняет tracking.

8. Component / data-flow¶

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

flowchart LR
 A["Versioned YAML"] --> B["Discovery and mapped tasks"]
 B --> C["Validated staged objects"]
 C --> D["Publication manifest"]

9. Normal processing sequence¶

sequenceDiagram
 participant A as Versioned YAML
 participant B as Discovery and mapped tasks
 participant C as Validated staged objects
 participant D as Publication manifest
 A->>B: Send identified input
 B->>C: Export pinned source chunk
 C-->>B: Return path checksum and row counts
 B->>D: Advance only with durable evidence

Validate и hash YAML. Discovery фиксирует список источников, run cut и chunk plans. Mapped task читает один план, пишет immutable output и передаёт через XCom только pointer, checksum и count. Reduce валидирует completeness и публикует manifest.

10. Failure / recovery sequence¶

sequenceDiagram
 participant B as Discovery and mapped tasks
 participant C as Validated staged objects
 participant O as Recovery owner
 B->>C: Attempt write or advance
 Note over B,C: Mapped task dies after writing one chunk
 O->>C: Reuse same cut and validate full generation
 C-->>O: Durable outcome or explicit gap

Успевшие chunks не публикуются как полный отчёт. Retry читает тот же pinned cut, переиспользует verified output либо дописывает deterministic generation. Changed source aborts. Optional source требует явно принятой degraded generation.

11. Data model и contracts¶

YAML contract задаёт source_id, connector_type, secret_ref, schedule, pool, schema version, required flag и cut strategy. Run manifest фиксирует config hash, chunk IDs и lineage.

12. Consistency boundaries¶

Task success и object durability отдельно. Consumer читает только committed manifest. Backfill прошлого периода использует archived config, schema и source cut.

13. Scaling и capacity planning¶

Пакетировать мелкие источники, ограничивать map size и retries. Выделить pool на source, отдельную quota на backfill, cap параллельного scatter.

14. Observability¶

Scheduler queue age, mapped task count, source throttling, retry storm, failed chunks и manifest completeness.

15. Data Quality и reconciliation¶

Сравнить expected chunks, keysets, row counts и hashes. Запретить смешение generations. Хранить approved exceptions и evidence.

16. Security и compliance¶

В YAML только secret references. Source readers least privilege, config changes review, logs redacted. Раздельные права publish и transform.

17. Implementation roadmap¶

Сначала два источника и dry run discovery, затем mapped retry fixture, затем pools, retention и backlog drill.

18. Testing и acceptance criteria¶

Проверить invalid YAML, partial failure, retry того же chunk, changed source, duplicate publish и повтор отчёта. Критерий — один manifest на approved generation и отсутствие partial visibility.

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

Dynamic Task Mapping упрощает runtime fan-out, но metadata DB и scheduler могут стать узким местом. Выбор зависит от granular retries и числа tasks.

20. Interview questions¶

Зачем pointer в XCom? Payload создаёт нагрузку на orchestration metadata и усложняет доступ. Как повторить прошлый день? Использовать сохранённый config и cut, затем выпустить отдельную generation.

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

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