Так как данные могут попасть в разные шарды?
все неправильно поняли
во первых кто вам мешает шардировать таким образом что бы попадало в один шард во вторых, какая разница, ну попадет в разные шарды и что?
События будут писаться без обогащения, допустим, есть одно событие содерждит колонки user_id, adv_id, hash_slice. И второе событие содержит в себе currency_id, money, hash_slice. И второе событие будет автоматически обогащаться первым. Чтобы получилась одна строка. Пример запроса в мат вью плюс минус такой CREATE MATERIALIZED VIEW ` log_to_statistic ` TO statistic AS SELECT hash_slice as hash_slice, uuid as uuid, min(toStartOfHour(toDateTime(log.created_at))) as datetime, argMaxIfState(campaign_id, log.created_at, campaign_id > 0) as campaign_id, argMaxIfState(news_id, log.created_at, news_id > 0) as news_id, countIf(event_name = 'news_show') as news_shows, countIf(event_name = 'ad_click') as ads_clicks, argMaxIfState(multiIf( log.status = 1, 0, log.status = 2, postback_money, log.status = 3, 0, log.status = 4, 0, 0 ), log.created_at, log.status > 0) as confirmed_money, argMaxIfState(multiIf( log.status = 1, postback_money, log.status = 2, 0, log.status = 3, 0, log.status = 4, 0, 0 ), log.created_at, log.status > 0) as holded_money, max(log.created_at) as updated_at FROM log GROUP BY uuid, hash_slice;
запросы к Summing Merge Tree и Aggregaton Merge Tree надо домерживать в select поэтому запрос к Distributed таблице вернет то что вы хотели в Merge Tree таблицах всегда нефинальное состояние, поэтому вам все равно необходим groupby в запросе к Distributed
Я просто могу на бекенде домерживать по некому свойству, которое залетает без хождения в КХ, и вот думаю, делать на беке и покрывать тестами или на КХ выносить(На КХ чет не очень хочется), но мысли есть
Обсуждают сегодня