Перейти к содержанию

A. Banking CDC

Walkthrough · Раздел03

Тип материала: учебный архитектурный сценарий. Не описывает систему конкретной компании.

Границы и версии

PostgreSQL17 либо Oracle19c → Debezium3.3 → Kafka4.1 → ClickHouse25.8. Это две source-specific конфигурации connectors, не один универсальный reader. Все узлы и связи HYPOTHETICAL; версия source adapters и bundled Connect требует runtime проверки.

Data contracts

Envelope содержит source_instance, source_table, primary_key, operation(r/c/u/d), before/after, schema_version, source transaction/position и snapshot identity. Деньги остаются exact minor units/decimal с converter contract. Normalized revision определяется source-specific total order для одной сущности; PostgreSQL LSN и Oracle SCN не сравниваются между собой. Snapshot baseline, row order внутри transaction и tie/conflict policy должны быть явно реализованы и проверены; Kafka offset сам по себе не заменяет source business version.

State ownership и transaction boundaries

Владелец State / scope
Source DB Authoritative rows/constraints и source-specific log
Debezium / Connect Snapshot protocol, retained progress и Oracle schema history либо PG slot
Kafka Retained CDC envelopes, независимые consumers
ClickHouse Восстанавливаемая аналитическая current-state/history projection

Архитектура — HYPOTHETICAL

flowchart TB
  PG[PostgreSQL snapshot and WAL] --> Debezium[Separate source-specific connector]
  Oracle[Oracle snapshot and redo] --> Debezium
  Debezium --> Kafka[Versioned CDC envelopes]
  Kafka --> Adapter[Source-order and schema mapping]
  Adapter --> CH[ClickHouse revisions]
  CH --> Reconcile[Latest-state reconciliation]

Нормальная обработка по шагам

  1. Задать scope таблиц и consistent cutoff. PG: publication/slot/replica identity; Oracle: supplemental logging/redo privileges/archive/schema history. Не копировать PG settings в Oracle.

  2. Connector выполняет свой snapshot/log coordination. op=r строит baseline state; это не новая денежная проводка и не команда внешнему провайдеру.

  3. Kafka хранит версионированный envelope. Target adapter проверяет schema, точность decimal, ключи, source identity и delete semantics.

  4. CH ingestion сохраняет revisions, включая delete markers. Latest-state query сначала выбирает последнюю версию по проверенному source-order contract, затем применяет фильтры. Mutable business date не должна разводить revisions по несовместимым partitions.

  5. Source multi-table transaction не становится атомарной публикацией нескольких CH tables. Reporting читает согласованный source cut/target generation либо явно допускает partial visibility.

  6. Reconciliation сравнивает keys, counts и exact currency totals на согласованном cutoff; snapshot status и Kafka lag недостаточны.

sequenceDiagram
  participant Source as Source or caller
  participant Connector as Debezium
  participant Kafka as Kafka retained log
  participant Sink as Processing worker
  participant Target as Target state
  Source->>Connector: Consistent snapshot plus source log position
  Connector->>Kafka: Snapshot and committed change envelopes
  Kafka->>Sink: At-least-once CDC records
  Sink->>Target: Persist versioned rows and delete markers
  Sink->>Kafka: Advance safe consumer progress
  Target-->>Source: Reconcile explicit cutoff

Failure / recovery sequence — HYPOTHETICAL

sequenceDiagram
  participant Source as Source or caller
  participant Kafka as Kafka retained log
  participant Sink as Processing worker
  participant Target as Target state
  Kafka->>Sink: Deliver change at offset N
  Sink->>Target: Insert revision
  Target-->>Sink: Write succeeds
  Note over Sink,Kafka: Crash before progress commit
  Kafka->>Sink: Replay from retained offset
  Sink->>Target: Same source revision or safe latest-state replacement
  Note over Source,Target: Log gap needs new snapshot generation, not silent reset

Replay / backfill protocol

Если source log отсутствует, создать isolated baseline generation с новым snapshot identity, восстановить current state и сверить. Это не восстанавливает утраченную полную transaction history. Schema changes rollout readers→source→mapping с сохранением совместимости; unsupported mapping/cutoff помечать UNKNOWN.

Monitoring и alerting

PG retained WAL/slot lag, Oracle redo availability/schema history, snapshot progress, connector/task errors, Kafka offsets/age, CH rejected rows/parts/merge backlog и reconciliation mismatches. Alert owner должен успеть до исчерпания source log/archive horizon.

Trade-offs и альтернативы

CDC минимизирует изменения legacy приложения, но теряет часть domain intent. Альтернатива — outbox/application events для semantic contract или bounded snapshot при допустимой freshness. В source-order normalizer нет заявленного готового implementation/E2E test; это обязательное ограничение модели.

Типичные ошибки проектирования

Считать всю цепочку одной transaction; терять stable identity/versions; скрывать late/rejected scope; смешивать backfill и live generations; делать external financial effect во время технического replay.

Вопросы на собеседовании

Какая E2E guarantee доказана этой схемой? Сама схема ничего не доказывает. Нужны реализованные source/state/sink protocols и experiments для указанных failure points; фактически выполненные проверки перечислены в отчёте.

Практические упражнения

Воспроизведите failure sequence в изолированном runtime и сохраните source positions, target state, count/key/amount reconciliation и recovery evidence. До этого distributed guarantee остаётся документированной моделью.

Дополнительные источники и примеры

Протокол проверок (архив рабочего проекта) · Журнал ограничений (архив рабочего проекта).