Наилучшая практика для реализации системы агрегации журналов отслеживания пользовательских событий? - PullRequest
0 голосов
/ 15 марта 2019

Я испытываю трудности в стажировке, и мне сказали внедрить систему для отслеживания агрегации пользовательских событий в режиме реального времени.

Входные данные, поступающие из кластера Кафки. Для простоты, скажем, схема

{"userId" = "AAA", "region" = "US", {"like" = 1}}

И я должен агрегировать результат каждые 5 минут, каждый 1 час и каждый день для команды машинного обучения и рабочей группы и иметь отказоустойчивость для встряхивания сети. Они хотят, чтобы данные агрегировались как счет за каждые 5 минут, но это не произвольно, это должно быть примерно 10:00 - 10:05 10:05 - 10:10. То же самое для часа и дня.

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

Во-первых, я пытаюсь решить проблему, пытаясь использовать такие инструменты, как Flink с окном. Я нахожу 3 окна размером 5 минут, 1 час и 1 день. И используйте обратный вызов onElement для граничного условия все время. Но загрузка памяти непредсказуема, иногда в окне остается много разных пользователей, что вызывает проблемы с производительностью узла.

Таким образом, я должен использовать некоторое KV-хранилище в качестве промежуточного значения для частично рассчитанных данных.

И я использую кластер Redis для хранения хранилища KV. Но, похоже, Flink ударил Redis слишком сильно, пропускная способность Flink намного выше, чем Redis. DAU составляет около 10 млн по всему миру.

Кажется, есть только один способ изменить Rocketdb, прикрепленный к Flink, и реализовать некоторый кеш, а не удалять окно.

Мне интересно, кто-нибудь реализовывал такую ​​систему раньше, и дайте мне несколько советов.

Спасибо.

...