Case 10. Financial Reporting Pipeline¶

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

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

1. Business problem¶

Выпускать воспроизводимый ежедневный отчёт и объяснять расхождения при поздних корректировках.

2. Functional requirements¶

Фиксировать consistent cut, immutable inputs, SQL/dbt version, approvals, publication receipt и связь исправления с прежней версией.

3. Non-functional requirements¶

Close deadline зависит от source availability. Частично завершившийся DAG не публикует отчёт. Действующая версия доступна при сбое staging.

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

Assumption — business date определяется владельцем, несколько источников имеют самостоятельные cuts. Спросить timezone, regulatory scope, tolerated late files, FX rule version, approval и отправку.

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

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

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

При 77,76 GB сырых входов/сутки и условных 4 полных scan passes дневной transform читает 311,04 GB до pruning. Срок хранения input snapshots следует считать отдельно от короткого Kafka retention.

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

A — operational SQL напрямую в source DB на согласованном snapshot. B — staged batch cut, Airflow, object storage и versioned SQL/dbt transformations. C — streaming preliminary plus verified daily close.

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

Выбрать B для official close. A подходит малой нагрузке с одним источником и bounded query. C дополняет B предварительной видимостью, не заменяя approval.

8. Component / data-flow¶

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

flowchart LR
 A["Authoritative source cuts"] --> B["Airflow extraction and dbt"]
 B --> C["Object storage staged generation"]
 C --> D["Approved publication registry"]

9. Normal processing sequence¶

sequenceDiagram
 participant A as Authoritative source cuts
 participant B as Airflow extraction and dbt
 participant C as Object storage staged generation
 participant D as Approved publication registry
 A->>B: Send identified input
 B->>C: Build transforms from immutable inputs
 C-->>B: Return reconciliation and signed manifest
 B->>D: Advance only with durable evidence

Зафиксировать source positions и hashes. Extract на pinned cut, dbt materializes staging, independent oracle сверяет keys и суммы. Approval публикует manifest, отправка подтверждается отдельно.

10. Failure / recovery sequence¶

sequenceDiagram
 participant B as Airflow extraction and dbt
 participant C as Object storage staged generation
 participant O as Recovery owner
 B->>C: Attempt write or advance
 Note over B,C: Correction arrives after official close
 O->>C: Issue approved restatement with prior lineage
 C-->>O: Durable outcome or explicit gap

После failed task повторить fixed inputs. При late correction создать новый cut, новую report generation и ссылку на прежний выпуск. Lost submission ACK разрешить по submission ID.

11. Data model и contracts¶

report_id, entity, period, cut per source, schema/ref versions, transform hash, generation, approval record, submission evidence. Rows связываются с journal IDs и currency/FX policy.

12. Consistency boundaries¶

Snapshot локален источнику. Cross-source cut документирует ограничения. Publication pointer переключается атомарно после validation, receipt относится к отдельной внешней системе.

13. Scaling и capacity planning¶

Изолировать backfill pool, partition по period/entity, оценивать scan passes и peak close contention. Tune batches по measured source read budget.

14. Observability¶

Freshness per input, close blockers, drift, failed approvals, generation age, submission receipts и run lineage.

15. Data Quality и reconciliation¶

Сверить journal keysets, balance conservation, adjustments и amount per currency. Независимая проверка не использует тот же ошибочный aggregate. Сохранять zero-sum counterexample.

16. Security и compliance¶

Separate preparation/approval/submission roles, restricted evidence storage, проверенная policy retention и redaction. Не назначать регуляторный SLA без юрисдикции.

17. Implementation roadmap¶

Сначала reproduce старого cut, затем staged runs и validator, approval pointer, restatement rehearsal и audit drill.

18. Testing и acceptance criteria¶

Partial export, mutated input, duplicate publish, late correction, mismatched currency и lost submission ACK. Acceptance — прежний выпуск остаётся воспроизводимым, новый связан с approved correction.

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

Immutable snapshots увеличивают хранение, но позволяют доказать cut. Для late files нужны явно agreed close/reopen decisions.

20. Interview questions¶

Чем отличается backfill от restatement? Backfill может пересчитать ту же версию входов. Restatement публикует новую официальную версию. Почему недостаточно успешного DAG? Task states не доказывают completeness и финансовую сверку.

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

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