Отчёт за вчера вместо текущего момента
Операционная команда принимает решения по данным ночной загрузки: остатки на складе, статус заказов и загрузка курьеров видны только на утро. Реагировать на ситуацию уже поздно.
Аналитика в реальном времени
Данные через несколько секунд после события, а не на следующий день
Проектируем потоковый контур: события из операционных систем попадают в Kafka, обрабатываются с окнами и дедупликацией, складываются в ClickHouse и обновляют дашборды и алерты почти мгновенно.
Или сразу: +7 (962) 368-39-51 Telegram
Kafka
шина событий с буфером и повтором
CDC
изменения из БД без нагрузки на мастер
ClickHouse
агрегаты по потоку за секунды
lag
задержка измеряется и контролируется
Где ломается аналитика в реальном времени
Батч ночью почти всегда работает. Сложности начинаются, когда данные нужны в момент события.
Повтор при сбое даёт дубли
Консьюмер упал после обработки, но до фиксации смещения, и события обработались дважды. В потоковой системе без ключа идемпотентности это означает двойной счёт в метрике.
Пиковая нагрузка ломает расчёт
Распродажа или массовая рассылка увеличивают поток в десять раз. Пайплайн, рассчитанный на средний темп, начинает отставать, лаг растёт, а дашборд показывает устаревшие цифры без предупреждения.
Опоздавшие события искажают окна
Событие с мобильного клиента приходит позже, чем закрылось минутное окно агрегации, и выпадает из расчёта. Итоговая сумма за час не совпадает с фактической, и никто не понимает почему.
Два источника показывают разное
В операционной системе уже новый статус заказа, а в аналитической витрине ещё старый: потоки идут разными путями с разной задержкой, и оператор не понимает, какому экрану верить.
Поток запущен «на всякий случай»
Кластер, топики с бесконечным хранением и три копии каждого сообщения обходятся заметно дороже, чем нужно. Без оценки объёма и политики хранения счёт за инфраструктуру растёт ежемесячно.
Из чего состоит потоковый контур
Собираем решение по слоям: сбор событий, обработка, хранение и наблюдаемость. Можно начать с одного сценария — например, статусы заказов.
Сбор событий
Публикуем изменения из источников в шину событий так, чтобы рабочая система не страдала от аналитической нагрузки.
- Apache Kafka как буфер между источниками и потребителями
- Debezium для чтения журналов изменений MySQL и PostgreSQL
- Схемы сообщений и Schema Registry: Avro или JSON Schema с проверкой совместимости
- Продюсеры в приложении: события заказа, платежа, статуса доставки, действия пользователя
Потоковая обработка
Считаем метрики по мере поступления данных и корректно обрабатываем границы окон.
- Apache Flink или Kafka Streams для окон, соединений и агрегатов
- Watermarks и допустимое опоздание событий, пересчёт поздних данных
- Дедупликация по ключу события и идемпотентная запись в хранилище
- Обогащение справочниками: товар, клиент, канал, регион
Хранилище для быстрых запросов
Складываем поток в базу, которая отдаёт агрегаты за секунды и держит историю под контролем.
- ClickHouse с движком MergeTree и ключом сортировки под типовые срезы
- Материализованные представления для предрассчитанных агрегатов
- Партиционирование по датам и TTL для горячих и архивных данных
- Разделение горячего потока и суточной витрины для тяжёлой отчётности
Наблюдаемость и SLA
Измеряем задержку и полноту данных, потому что поток без мониторинга быстро становится недостоверным.
- Лаг консьюмеров, время обработки и размер отставания по топикам
- Сквозная задержка от события в источнике до записи в витрину
- Алерты при отставании, потере сообщений и резком изменении объёма
- Дашборды в Grafana или Superset и контроль стоимости кластера
Как мы запускаем поток
Потоковый контур внедряем по одному сценарию за раз: сначала метрика, которую видно в первые минуты, потом расширение.
-
01 1 неделя
Сценарий и требования к задержке
Выбираем первый бизнес-сценарий и фиксируем, какая задержка считается приемлемой: секунды, минуты или пять минут. Считаем объём событий и пиковую нагрузку.
-
02 2–4 недели
Пилот на одном потоке
Поднимаем Kafka с одной темой, включаем CDC или продюсера в приложении, пишем события в ClickHouse и собираем первый дашборд с задержкой.
-
03 3–6 недель
Обработка и надёжность
Добавляем окна, дедупликацию, обогащение и пересчёт опоздавших событий. Настраиваем мониторинг лага, алерты и сценарий восстановления после сбоя.
-
04 по SLA
Расширение и эксплуатация
Подключаем новые источники и сценарии, оптимизируем стоимость хранения, обучаем операционную команду работе с потоковыми отчётами.
Когда реальное время действительно нужно
Потоковая аналитика оправдана там, где задержка меняет решение. Оперативный мониторинг заказов и доставки, контроль остатков в момент продажи, антифрод и проверка платежей, динамическое ценообразование, наблюдение за нагрузкой и ошибками в продукте, реакция на инцидент в первые минуты.
Если отчёт нужен раз в день и никто не принимает решения в течение часа, батч надёжнее и дешевле: его проще пересчитать, отладить и объяснить. Мы обычно предлагаем разнести задачи: операционные метрики уводим в поток с задержкой в секунды, а тяжёлую отчётность и сверку с бухгалтерией оставляем в ночном расчёте. Смешивать их в одном конвейере — верный способ получить дорогую и хрупкую систему.
Как обеспечить достоверность данных в потоке
В батче результат можно пересчитать: загрузили период заново и получили правильные цифры. В потоке такой возможности нет, поэтому корректность закладывается в архитектуру. Первое — каждое событие имеет уникальный идентификатор, а запись в хранилище идемпотентна: повторная обработка не создаёт дубль. Второе — определена политика опоздавших данных: сколько времени ждём событие и как пересчитываем закрытое окно.
Третье — контроль полноты. Мы сравниваем количество событий в источнике и в хранилище за одинаковый период, следим за лагом консьюмеров и объёмом сообщений в топиках. Если поток отстал или часть событий потерялась, система сообщает об этом, а не молча рисует заниженную выручку. И четвёртое — регулярная сверка потоковой витрины с батчевым расчётом за сутки: расхождение больше оговорённого порога считается инцидентом.
Сколько стоит потоковая аналитика и как её не переплатить
Основные затраты — не лицензии, а инфраструктура: брокеры, хранилище быстрых запросов, репликация и объём хранения сообщений. На стоимость влияют три параметра: пиковый поток событий, требуемая глубина хранения и число копий данных. Мы начинаем с оценки реального объёма — часто выясняется, что девяносто процентов событий не нужны в реальном времени и спокойно уезжают в ночную загрузку.
Экономить помогает политика хранения: горячие данные держим в ClickHouse с TTL и партиционированием, а полную историю — в объектном хранилище. В Kafka ограничиваем срок хранения сообщений разумным окном повторной обработки, а не бесконечностью, и настраиваем сжатие. Отдельно отслеживаем стоимость на дашборде, чтобы рост потока не превращался в сюрприз в счёте за месяц.
Частые вопросы
На практике это диапазон от секунды до нескольких минут. Для мониторинга заказов и платежей обычно достаточно 5–30 секунд от события до появления в дашборде, для антифрода — доли секунды. Мы всегда уточняем требование в цифрах до начала работ: от него зависят и архитектура, и стоимость, а формулировка «в реальном времени» без числа почти всегда приводит к переплате.
Для небольших объёмов иногда да: например, писать события напрямую в ClickHouse из приложения через буфер или использовать встроенный механизм очередей. Kafka нужна, когда есть несколько потребителей одного потока, требуется буфер при недоступности хранилища и повторная обработка после сбоя. Если объём — тысячи событий в час и один потребитель, промежуточная шина добавляет сложности больше, чем пользы.
События остаются в топиках Kafka в течение заданного срока хранения, поэтому данные не теряются. Консьюмер при перезапуске продолжает с сохранённого смещения, а идемпотентная запись не создаёт дублей при повторной обработке. Мы отдельно описываем сценарий восстановления: сколько времени занимает перезапуск, как проверить, что отставание ликвидировано, и как уведомить пользователей дашборда о возможной неполноте данных.
Обычно нет. Потоковый контур дополняет батчевый: операционные метрики идут через Kafka в отдельные таблицы ClickHouse, а суточные витрины продолжают считаться ночью и служат эталоном для сверки. Такой подход позволяет запустить поток, не перестраивая уже работающую отчётность, а расхождения между быстрым и эталонным расчётом мы разбираем как часть регулярного контроля качества.
Data Science: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Нужны данные в момент события?
Опишите сценарий и требуемую задержку — оценим объём потока, архитектуру и сроки пилота.