Какие требования по скорости доставки данных: реалтайм или батч

Что проверяют

Умеете ли вы начинать не с технологии, а с вопроса «какая задержка допустима и сколько бизнес готов за неё платить». Следом почти всегда спрашивают про гарантии доставки и про то, что делать с событиями, пришедшими с опозданием.

Как отвечать

Сначала уточните требование в цифрах: через сколько после события данные должны быть доступны потребителю. От ответа зависит класс решения:

• батч: часы или сутки. Выгрузка раз в день, обработка в Spark или SQL в хранилище, оркестрация в Airflow. Дёшево, легко перезапустить и пересчитать историю. Подходит для отчётности, обучения моделей, большинства витрин;
• микробатч: минуты. Так по умолчанию работает Spark Structured Streaming, сюда же относятся частые инкрементальные загрузки. Честный компромисс, когда просят «реалтайм», а на деле хватит пяти минут;
• стриминг: секунды и меньше. Kafka как шина, обработка во Flink или Kafka Streams, CDC из базы через Debezium. Нужен для антифрода, мониторинга, онлайн-фичей для моделей, рекомендаций внутри сессии.

Затем назовите цену потока: состояние операторов, чекпоинты, водяные знаки (watermark) для опоздавших событий, выбор между at-least-once и exactly-once, дедупликация, круглосуточное дежурство. Батч прощает ошибки перезапуском, в потоке о них надо думать заранее.

Хороший ход: предложить гибрид. Поток для оперативных метрик и фичей, батч для точного пересчёта и сверки. В ML это частая схема, и важно, чтобы фичи в потоке и в хранилище считались одной и той же логикой.

Где спотыкаются

Соглашаются на «реалтайм», не спросив, кто и как часто смотрит на данные. Дашборд, который открывают раз в день, стриминг не оправдывает.

Не разделяют время события и время обработки. Окна тогда считаются неверно, а опоздавшие события теряются.

Обещают exactly-once «из коробки». Внутри Kafka и Flink это достижимо, но на границе с внешней системой нужна идемпотентная запись или транзакционный приёмник, иначе появятся дубли.