Case 09. CDC-based Integration Platform¶

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

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

1. Business problem¶

Интегрировать несколько transactional источников с независимыми downstream SLA, replay и traceable delivery.

2. Functional requirements¶

Снять snapshot, вести CDC, поддерживать schema contracts, route consumers, сохранять DLQ и reprocess approvals.

3. Non-functional requirements¶

Медленный consumer не блокирует остальные. Полнота определяется source cut, восстановление после gap наблюдаемо. Target side effects идемпотентны.

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

Assumption — Debezium 3.3 подходит источникам, NiFi используется на маршрутизации/файловом edge. Спросить supported Oracle mode, WAL/redo retention, DDL policies, registry compatibility, commit frequency и схему tenant isolation.

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

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

Метрика	Формула и подстановка	Результат
Объём событий	2800 × 86 400	241920000 событий/сутки
Сырые данные	241920000 × 1600 B	387.072 GB/сутки
Retention без сжатия	387.072 GB × 14 суток	5419.008 GB
Broker copies при RF=3	5419.008 GB × 3	16257.024 GB, из них 10838.016 GB дополнительные копии
Producer bandwidth, среднее	2800 × 1600 × 8 / 10⁶	35.84 Mbit/s
Producer bandwidth, пик	5600 × 1600 × 8 / 10⁶	71.68 Mbit/s
Partitions при 30% headroom	max(ceil(5600 × 1,3 / 1 500), ceil(5600 × 1600 × 1,3 / 1 800 000))	7 partitions
Consumer parallelism	ceil(5600 × 1,3 / 1 500)	5 workers на группу при принятой производительности
Backfill одних суток при 3× средней capacity и живом среднем потоке	(2800 × 86 400) / (3 × 2800 − 2800)	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, конечного времени восстановления нет.

Для трёх независимых групп условный peak egress 3 × 5 600 × 1 600 × 8 = 215,04 Mbit/s без replication и replay. У каждой группы собственный backlog и spare capacity.

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

A — Debezium → Kafka, registry compatibility и independent consumers. B — NiFi ingestion для файлов/API плюс managed CDC path, explicit routing и provenance. Polling watermark подходит только источнику с проверяемым monotonic change contract.

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

Выбрать A для database changes и B как дополнение для неоднородных feeds. NiFi route не заменяет подтверждённую log capture. Изолировать critical consumer от slow analytics.

8. Component / data-flow¶

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

flowchart LR
 A["Oracle and PostgreSQL"] --> B["Debezium and routed ingest"]
 B --> C["Kafka versioned topics"]
 C --> D["Independent consumers"]

9. Normal processing sequence¶

sequenceDiagram
 participant A as Oracle and PostgreSQL
 participant B as Debezium and routed ingest
 participant C as Kafka versioned topics
 participant D as Independent consumers
 A->>B: Send identified input
 B->>C: Publish source positions and schema identity
 C-->>B: Return durable record and progress evidence
 B->>D: Advance only with durable evidence

Зафиксировать snapshot boundary и schema. Connector применяет snapshot и tail, consumer пишет effect вместе с inbox либо stable revision. DLQ хранит quarantined payload и причину отдельно.

10. Failure / recovery sequence¶

sequenceDiagram
 participant B as Debezium and routed ingest
 participant C as Kafka versioned topics
 participant O as Recovery owner
 B->>C: Attempt write or advance
 Note over B,C: Restart cannot resume past missing log range
 O->>C: Quarantine gap and rebuild isolated generation
 C-->>O: Durable outcome or explicit gap

После restart сравнить committed connector progress с retained source range. При gap не двигать offset через потерянный интервал. Восстановить logs либо resnapshot. DLQ replay под новым approved generation с original identity.

11. Data model и contracts¶

Source system, table, PK, op, source transaction position, schema ID, before/after, ingest time и connector generation. Registry compatibility policy versioned, tombstone и delete semantics проверяются явно.

12. Consistency boundaries¶

Source transaction и broker publication независимы. Connector offsets локальны. Consumer commit включает business guard или atomic inbox. Global ordering между Oracle и PostgreSQL UNKNOWN без отдельного protocol.

13. Scaling и capacity planning¶

Параллельность по partition и consumer group. Pause slow source/consumer отдельно, не смешивая replay с live. Size WAL/redo по измеренным байтам с учётом snapshot и outages.

14. Observability¶

Per-source log headroom, snapshot progress, connector restarts, per-group lag, rejected schemas, DLQ age и unmatched effect IDs.

15. Data Quality и reconciliation¶

На source cut проверить keys, counts, currencies и delete coverage. DLQ не считается доставкой эффекта. Сверить unresolved gaps до принятия новой generation.

16. Security и compliance¶

Разграничить CDC credentials, registry ACL и DLQ access. Raw payload может содержать PII, поэтому redact logs и контролировать replay principal.

17. Implementation roadmap¶

Пилот одной таблицы, затем schema changes и restart tests, несколько групп, managed replay и audited onboarding.

18. Testing и acceptance criteria¶

Инъецировать WAL gap, duplicate snapshot chunk, connector restart, incompatible schema и consumer outage. Acceptance — объявленный gap, repeat-safe effects и независимые checkpoints групп.

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

Длительное log retention влияет на source storage. Нормализованный envelope облегчает replay ценой изменения схемы. Перечитать snapshot проще при доступном authoritative cut.

20. Interview questions¶

Почему Kafka lag=0 не доказывает completeness? Connector мог потерять source range. Как повторить DLQ? Исправить причину, одобрить reprocess, использовать прежнюю identity и сверить эффект.

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

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