Резюме решения (коротко): для реального времени с низкой задержкой, высокой устойчивостью и возможностью восстановления консистентных суммарных значений — гибрид: агрегация на краю (edge) + распределённый durable лог (Kafka) + stateful stream-processing (Flink/Beam) + материализованное хранилище с репликацией (Cassandra/Scylla/ClickHouse/Redis). Ниже — архитектура по компонентам и обоснование выбора против MapReduce/batch и чистого edge-only.
Архитектура — компоненты и взаимодействия
- Edge-агрегатор (на каждой ноде/регионе):
- Локально аккумулирует/предагрегирует метрики (например, 1s/5s оконные суммы, редуцирование шума).
- Уменьшает трафик и даёт низкую локальную задержку; сохраняет буфер при потере сети.
- Формат сообщений: timestamp + metric_id + value + origin_id + monotonic_seq + idempotency_key.
- Надёжный буфер/транспорт: Kafka (локальные региональные кластеры или Mirror/Cluster Linking для кросс-DC):
- Kafka как единый durable commit-log для всех событий (topic-per-metric-family, compacted topics для состояний).
- РП=3+; min.insync.replicas = 2 для устойчивости.
- Stream processing (Flink/Apache Beam on Flink):
- Stateful операторы для агрегации, окон, корреляции; checkpointing в durable state-backend (RocksDB) + changelog в Kafka.
- Exactly-once семантика (Flink + Kafka transactional sink / two-phase commit) или at-least-once + deduplication.
- Materialized views / Read store:
- Менеджер агрегатов записывает результаты в распределённое, реплицируемое хранилище для чтений: Cassandra/Scylla (для высоких QPS и устойчивости), ClickHouse (OLAP), Redis (hot cache).
- Репликация на уровне БД (RF, quorum).
- Контроль, мониторинг, SLO:
- Метрики по задержке/отставанию (consumer lag), алерты на отклонения, audit log для восстановления.
- Recovery / Replay:
- Храним offsets и checkpoints; при сбое можно пересчитать, проиграв Kafka с нужного offset.
- Compacted topics + changelog state позволяют восстановить state даже после длительного простоя.
Согласованность и репликация
- Внутри Kafka: репликация log-structured с leader/follower; для устойчивости — RF >= 3, ISR quorum, min.insync.replicas > 1. На запись — запись подтверждается quorum.
- В read-store (Cassandra): репликация по RF и тактика quorums (WRITE_QUORUM / READ_QUORUM) для сильнее согласованности при чтении; при необходимости использовать lightweight transactions для критических операций.
- Между DC: асинхронная репликация (MirrorMaker2 / Cluster Linking) — выбор асинхронности ради доступности; критичные метрики можно дублировать синхронно по региональным кластерам.
Idempotency и дедупликация
- Генерируем idempotency_key на источнике (combination origin_id + monotonic_seq или UUID+seq).
- На ingestion — сохраняем последние seq per origin в compacted topic / dedup map в Flink; при at-least-once повторная вставка обнаруживается и отбрасывается.
- Для exactly-once используем Kafka producer id + transactions и Flink two-phase commit sinks.
- Для агрегатов используем коммутативные/ассоциативные операции или CRDT-структуры, чтобы обеспечить безопасное повторение.
Обработка сетевых разрывов и partition tolerance
- Edge-first: при сетевом разрыве edge-агрегатор буферизует (локально и в Kafka producer buffer), продолжает локальные предагрегации и обслуживает локальные запросы; при восстановлении сети — реплей/пуш.
- Трейд‑оф: доступность в partition => разрешаем локальные агрегаты (eventual consistency), а затем reconcile через merge (см. CRDTs).
- Для критичных согласованных операций — использовать quorum-политики и отклонять операции при недостаточном кворуме (жертвовать доступностью).
- Для глобальной корректности — использовать mergeable summaries (G-counter, PN-counter, OR-Set для наборов, t-digest/HDR для распределений), которые корректно объединяются после разделения.
Выбор алгоритмов агрегирования (типы метрик)
- Счётчики (sum): G-Counter/monotonic sequences или idempotent increments. Коммутативны — легко merge.
- Gauges: last-write-wins с timestamp и versioning (vector clock для приоритета источников).
- Гистограммы/percentiles: mergeable sketches (t-digest, HDR, DDSketch).
- Списки/сеты: CRDT OR-Set/PN-Set если нужно.
Гарантии семантики доставки
- Требуется: низкая задержка + корректность сумм => рекомендуем exactly-once либо at-least-once + детекція дупликацій.
- Exactly-once: Flink + Kafka transactional sinks + state checkpointing. Минус — сложнее и нагрузка выше.
- Pragmatic: at-least-once + dedup по idempotency_key + агрегаты коммутативны => правильность при повторе.
Почему не MapReduce / batch?
- MapReduce / batch (Hadoop) даёт высокую сквозную задержку (минуты—часы). Не подходит для real-time и SLO с низкой задержкой.
- Подходит как доп. offline слой для бэктестов, долгосрочного переагрегирования и историки.
Почему не только edge-aggregation?
- Edge снижает трафик и локальную задержку, но:
- теряется единая глобальная точка согласования (сложно реализовать агрегаты с сильной глобальной согласованностью),
- при полной потере центра — восстановление и согласование сложнее,
- обновления правил/агрегаций сложнее развертывать везде.
- Поэтому edge + централизованный durable log + stream processing — лучший компромисс.
Почему Kafka + Flink (stream processing)?
- Kafka: высоко‑доступный, durable commit-log, retention/replay, partitioning, встроенная репликация; natural buffer при сетевых проблемах.
- Flink: stateful streaming с checkpointing, exactly-once интеграция с Kafka, поддержка windowing и сложной логики, state-backend (RocksDB) для больших состояний.
- Позволяют: low-latency (<100–500ms), масштабирование на тысячи нод, восстановление state из checkpoints/changelogs.
Operational рекомендации и меры надёжности
- Тестировать failover: leader election, partition loss, DC outage.
- Использовать compaction для topics с состояниями; retention для raw events.
- Мониторинг lag, checkpoint age, IO, backpressure.
- Регулярные DR-тесты: replay от offsets + восстановление state.
- Техники контроля потока: throttling на edge, circuit-breakers, SLA-based routing.
Краткое окончательное обоснование
- Для требований: низкая задержка + устойчивость + возможность восстановления консистентных суммарных значений — оптимален гибридный паттерн: edge-aggregation (уменьшает задержку и трафик) + Kafka (durable log, replay) + Flink (stateful, exactly-once опции) + реплицируемое read-store. MapReduce/batch — слишком медленно; чистый edge — недостаточно для глобальной консистентности и восстановления.
Если нужно — могу дать пример топологии topics/partitions, конфигурации Kafka RF/min.insync, настройки Flink checkpointing и примеры CRDT для конкретных типов метрик.