Как стать автором
Обновить

Комментарии 5

А если надо совсем не терять данные?

Для достижения данной цели могут применяться различные решения - многое зависит от того к каким инструментам и каким этапам процесса вы имеете доступ.

Можно, к примеру, увеличить период хранения сообщений в топике Kafka до нескольких суток и периодически делать бэкапы топика в БД (или ElasticSearch, если данные долго хранить не планируете). После этого уже выполнять вычисления на сохранённых данных в БД, если бизнес требования допускают отклонения от моментальной онлайн-потоковой обработки данных. Либо сперва обрабатывать данные как есть в потоке онлайн, а потом проводить пост обработку на уже большом наборе данных.

Если же есть проблема, что данные от источника периодически в принципе не доходят до Kafka, то стоит задуматься над механикой работы источника. В случае с кейсом "Интернет-рекламы" - можно добавить в JS-скрипты механизм бэкапа действий пользователя в "Local Storage" и раз в N часов повторно отправлять всё что накоплено. После, уже на стороне приёмника, выполнять повторную аналитику на выявление новых данных, которые не дошли сразу во время события.

одна из лучший статей , моё уважение!

Такой вопросик: как в этом всем сделать такую вещь: например котировки акций, тоесть в postgres есть LAG и LEAD которыми можно выбрать предыдущие значение допустим если агрегировалось по дням

будет:

LABEL | CURRENT PRICE | PREV DAY VALUE | CHANGE

GGL | 75 | 50 | +50%

Никаких проблем - делайте так же, как в PostreSQL.
Spark SQL поддерживает оконные функции, в том числе LAG и LEAD.

Ссылка на официальную документацию: https://spark.apache.org/docs/latest/sql-ref-syntax-qry-select-window.html

Не пушили прототип на гит? Если организуете - было бы интересно увидеть!!!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий