Привет. У нас мобильное приложение, для него делаем доморощенный аналог

амплитуды.

Прошу вашей помощи, очень типичная задача, вижу в поиске много упрминаний юзер пропсов, но не нашел полного ответа.

Хотим получать ивенты и юзер пропсы с приложения и из других источников (например, из вебхуков эппла о подписках). И потом когда строить графики, хотим, чтобы у ивентов были эти юзер пропсы. Например, эппл сказал, что данный юзер подписан, все последующие события данного пользователя имеют свойство "подписан" true. Когда отписался, аналогично для будущих событий false.

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

Варианты, что видим:
1. Сохранять пропсы в другой бд типа постгреса или даже редиса, в момент прихода ивента дёргать оттуда пропсы, популизовать ими ивент и сохранять в клик
2. Скидывать все в клик в одну таблицу и иметь materialized view, которые переводят пропсы и enriched events в две отдельные таблицы
3. Скидывать все в одну таблицу и иметь набор индексов и хитрые запросы, чтобы джойнить ее саму с собой, проставляя все незаполненные поля (насколько это медленно?)
4. См. 1, но без внешней бд. Но я так понимаю, что кх не очень хорошо подходит для выдергивания юзера на каждый новый ивент.

Объёмы: 100млн ивентов, 100к новых пользователей в месяц, до 1000 свойств.

Сейчас используем jitsu в качестве ингресса (мб есть какие-то аналоги?)

> кх не очень хорошо подходит для выдергивания юзера на каждый новый ивент Для этого же и есть внешние словари, отдельный движок Redis тоже есть. Но при тысяче свойст стоит в первую очередь оценить потребление рамы. Подходит / не подходит — это всё в каждом конкретном сценарии использования стоит рассматривать. Если вам чисто детализацию по конкретным пользакам (или небольшой группе) в аналитике нужно по требованию выдавать, то #1 вариант самый простой, а если атрибуты используются непосредствено, то обогащать лучше где-то во вне. #2 вообще не понял, зачем что-то скидывать в одну таблицу, чтобы потом в итоге получать две разных? #3 "Скидывать всё в одну таблицу" — именно так, но только уже в готовом обогащённом виде, чтобы потом без всяких извращений с джойнами. Если есть возможность обогащать перед вставкой в клик, то стоит так и сделать, если нет, ну прикрутите ETL, тут же сценарий достаточно простой: извлекаете порцию данных, обогащаете, вставляете обратно в кликхаус

Спасибо. А не подскажете инструменты для приема и обогащения готовые? Мб либы. Что за внешние словари для этих целей?

Выбор от уже используемого стека же зависит. Как и откуда события поступают? Типичный сценарий: кафка и флинк, либо самопичный подписчик Про словари: https://clickhouse.com/docs/en/sql-reference/dictionaries

может проще https://github.com/openreplay/openreplay взять? или https://github.com/PostHog/posthog и https://github.com/openmeterio/openmeter вместо того чтобы свое пилить?

ну, сделайте словарь какой то, например в REDIS и DIRECT LAYOUT апдейтите REDIS а в clickhouse через dictGet кладите текущее значение пропса...

JOIN Точно плохая идея. не надо так