mayton2019

В данном задании непонятно насколько остро стоит необходимость именно в MQ системе.

Можно начать просто с централизованного сбора логов. Мне кажется это проще
чем строить кафку. Кроме того логгирование работает всегда, пока есть файловая
система. А Кафка может быть недоступна какое-то количество минут или секунд в году.
И вам надо будет думать что делать с событиями которые не ушли в Кафку. Блокировать.
Дропать события. Или искать резервное мето куда форварднуть.

Я не специалист в кликхаусе, но если ты указываешь

ENGINE = ReplacingMergeTree
Order by (....)

то это (скорее всего) включает некоторые механизмы дедубликации. Почитай вот тут пишут
https://clickhouse.com/docs/en/engines/table-engin...

Выше ты писал

должны убраться дублирующиеся записи, но их нет.

это нужно доказать отдельным SQL запросом. Я думаю что ты скорее всего ошибся.
Проверь.

Кликхаус относится к классу column-oriented dbms. Это означает что data-row как таковой отсуствует.
Строк нет. Но есть столбцы которые хранятся физически консолидировано. И когда ты указываешь
SELECT * то это заставляет кликхаус сделать гораздо больше действий чем надо на самом деле. В
силу этой колоночатой организации. Сами строки - виртуальны и чтобы их сформировать кликхаус
должен вычитать физических данных гораздо больше чем реляционка. Столбец - больше чем ячейка.

Чтоб такая система работала эффективно ты должен ее грузить аналитическими запросами типа

select avg(amount) from my_table;
Тогда кликхаус сработает быстрее чем Oracle или PG. В силу этой особенности формата.

А то что ты делаешь - экспорт во внешние файлы лучше вообще не делать. Или делать редко
или как-то по другому. Явно это не сильная сторона такой системы.

В парадигме современной BigData, вы должны писать все что приходит на вход.
Как это там обзывают.... ELT (Extract, Load, Transform)
Никто не знает наперед какие данные понядоабятся - поэтому фиксируйте весь raw
трафик. Потом - отфильтруете. Построете материализованные views. Но главное что данные
будут.

Учитывая что clickhouse - column oriented - безразлично 2 поля из 2 выбирать или
2 поля из 2000.

Если хранилище у вас все таки переполнится - (со скоростью 2.5 Гб в день) то тогда уже почистите те
колонки которые стали объективно не нужны после например пары месяцев эксплуатации.

Да ничего тут нельзя особо сделать. 10 секунд - холодный запуск группировки по 88 млн строк - это вполне себе хорошая цифра. Сомнительно что железо выдавит из себя больше. Ведь так или иначе нужно эти 88 млн пересчитать и даже будь это все в памяти - все равно обойти каждую ячейку. А дальше дело будет только хуже. Ведь табличка растет.

Есть техники микро-батчинга когда большая задача разбиватеся на порции. Например у тебя есть дневной партишен на 15 млн. Делишь его на часовые. Получается по 625 тыщ строк. Уже лучше.

Делаешь некую кумулятивную табличку. Типа

create table charge_cumulative(
  id long,
  cnt_cumulative long,
  delta_sum_cumulative long
)

Ну и на каждый микро-батч добавляешь к ней значения count, delta_sum. У тебя вроде удачно получается что можно только складывать.