CDC-лаг до 90 минут: витрина выручки расходится с боевой БД на 12%

Ситуация: Финдиректор видит в дашборде выручку за день на 12% ниже, чем в OLTP. Расхождение скачет от 0% ночью до 12% в пик. CDC-поток из Postgres в DWH через Debezium+Kafka должен иметь лаг до 2 минут.

Нужно за смену найти, где именно теряется свежесть данных в CDC-конвейере orders, и предложить устойчивый фикс плюс honest-метрику свежести витрины для бизнеса. Витрина mart_revenue_daily собирается из реплицированной таблицы orders_cdc.

Доступные данные

• orders_oltp: order_id, user_id, status, amount, created_at, updated_at
• orders_cdc: order_id, status, amount, created_at, updated_at, _cdc_op, _cdc_ts, _ingested_at
• cdc_offsets: connector, topic, partition, committed_offset, lag_records, captured_at
• mart_revenue_daily: dt, orders_cnt, revenue, built_at, source_max_cdc_ts
• etl_runs: run_id, job, started_at, finished_at, rows_in, rows_out, status

Задачи

• Измерить фактический CDC-лаг как разницу между updated_at в OLTP и _ingested_at в orders_cdc по перцентилям и по часам суток.
• Связать всплески лага с пиковой нагрузкой и с consumer lag из cdc_offsets (растёт ли отставание в записях).
• Проверить, отстаёт ли сборка витрины (built_at vs source_max_cdc_ts) — лаг в CDC или в downstream-джобе.
• Сверить агрегаты OLTP и витрины по дню, разложить дельту на пропущенные и на устаревшие заказы.
• Предложить фикс (партиции Kafka, тюнинг snapshot/poll, инкрементальное окно витрины) и метрику data freshness SLO.

Все кейсы для подготовки → ← Все кейсы