Real-time transaction analytics¶

Раздел 05 · Редакционный стандарт

Тип материала — референсная архитектура. HYPOTHETICAL — схемы и операции. INFERENCE — инженерные рекомендации и критерии выбора. Внешние контракты ограничены источниками ниже.

Бизнес-задача¶

Показывать актуальные показатели и своевременно исправлять late/corrected data.

Требования¶

Явно обозначать freshness и completeness. Версионировать merchant, currency и definition of metric.

Поток данных и владение состоянием¶

flowchart LR
 A["Posted facts"] --> B["Kafka"]
 B --> C["Window computation"]
 C --> D["Analytical serving"]
 D --> E["Dashboard"]

Ledger facts и business cut задают контрольные данные. Dashboard хранит вычисленную projection.

Транзакционные границы¶

Checkpoint, serving write и offset связаны только при поддержанном протоколе. Upsert или rebuild нужны при повторах.

Порядок и идемпотентность¶

Stable transaction ID и revision. Delta требует retract старого вклада либо пересчёта окна.

Нормальная последовательность¶

sequenceDiagram
 participant A as Posted facts
 participant B as Kafka
 participant C as Window computation
 participant D as Analytical serving
 A->>B: Publish posted fact revision
 B->>C: Apply contribution to event-time window
 C-->>B: Return revised window snapshot
 B->>D: Publish analytic upsert

Отказ и восстановление¶

sequenceDiagram
 participant B as Kafka
 participant C as Window computation
 participant E as Recovery operator
 B->>C: Serving state is lost after checkpoint
 Note over B,C: Outcome becomes uncertain
 E->>C: Rebuild window generation and reconcile input coverage
 E->>B: Resume from verified boundary

После serving loss создать generation и восстановить нужные окна. Не считать max timestamp доказательством полноты.

Сверка¶

Сравнить signed contributions по ключам и версии окна, учитывать reversals.

Пример HYPOTHETICAL. Dashboard получил capture 100 и затем исправление суммы на 80. Latest-view считает вклад 80. Append-only deltas должны содержать корректировку −20 со своей identity. Виджет маркирует предварительный cut до получения полноты. Counter обновляется по устойчивой revision либо пересчитывается по immutable inputs, если target потерял часть истории.

Наблюдаемость¶

Watermark age, correction lag и completeness marker.

Безопасность и применимость требований¶

Защитить drill-down и ограничить PII.

Альтернативы и trade-offs¶

Streaming ускоряет preliminary view. Micro-batch облегчает повторяемую публикацию.

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

Почему нельзя суммировать обе revisions? Они представляют замену состояния, а не два независимых вклада.