Инженеры данных часто задают вопрос: «Грузить данные в реальном времени (real time streaming) или пачками (batch)»
Если спросить у бизнес заказчика, то мы получим ответ - «нам нужно в режиме реального времени отслеживать данные и быстро реагировать!» Иногда это правда, а иногда нет.
При выборе решения следует задавать следующие вопросы: «Кто будет поддерживать data pipeline? Понимает ли моя команда, как починить этот datapipeline, когда он сломается? » - Стрминговые решения часто сложнее классчической загрузки данных раз в день/раз в час.
Другой вопрос - «Будет ли кто-нибудь действительно просматривать эти данные в нерабочее время?» - если это правда, то в отчетах в реальном времени больше смысла. Если нет, то им, вероятно, можно обойтись без streaming решения.
Задавать правильные вопросы при создании аналитического решения абсолютно необходимо для его успешного внедрения.
У вас есть кейсы, когда вы создавали стриминговое решение? Может быть есть история, когда бизнес просил real time metrics, а на самом деле им не нужно было?
Если показать бизнесу сравнение затрат ресурсов на передачу данных в рил тайме и на передачу батчами, то в 99% случаев оказывается, что рил тайм то и не нужен))
Я делал стриминг для отправки пушей. Это не риалтайм, но близко к нему. Кейс - когда публикуют объявления об аренде, то хорошие объекты уходят очень быстро. Мы информирует пользователей у которых в избранном есть объявление из того же дома, что появилось новое предложение с максимальной задержкой в 1 час. Можем чаще, но это оптимальное время чтоб большенство новых объявлений прошли проверку авто модерации и мы не слали юзера всякий лохотрон и заманухи. По стеку Spark streaming для чтения данных из Kafka + HBase для хранение кешей(кому уже сдали, что у кого в избранном и т.п.)
У нас сейчас кейс, когда данные идут с буровой. Но проблема, что некоторые станки находятся в зонах, где интернет пропадает (в том числе спутниковый) а данные нужны реалтайм. Вопрос пока открыт. Ждём интернет от Маска, вдруг будет лучше спутниковых решений Иридиума того же)