Vitsliputsli

Время выполнения - 10-12 сек в первый раз и 3-4 сек при повторных запросах

В первй раз идет "прогрев" кеша диска, поэтому долго. Повторный запрос в 3-4 секунды наверное вполне нормальный, т.к. скорее всего необходимо обработать большое кол-во данных (но, конечно, нужно смотреть план, чтобы понимать сколько он обработал).
Решение стандартное - стройте проекции. Агрегирующие с группировкой по дням, для группировок по дням, неделям, месяцам. И top-проекции для "получить 100 элементов, у которых самая большая сумма". Но нужно посмотреть как это делать, так как я больше работал с другой колоночной СУБД.

Как удобно, так и храните. Брокер сообщений предлагают, потому что, это универсальный вариант, гарантирующий доставку (если, конечно, не в памяти он будет хранить).
Если данные уже лежат в классический СУБД, то есть резон там же организовать очередь и забирать из нее, не вводя дополнительный инструмент.
Т.к. инсертим батчами, то разумеется нужно делать инсерт из файла, это будет эффективнее. Т.е. готовите файл, и через какой-либо промежуток времени заливаете его. И, разумеется, только после заливки помечаете записи как обработанные.
Наверное, можно писать даже прямо в файл для заливки, если архитектура позволяет, главное проработать момент, когда начинаем писать в новый файл, чтобы записи не попали в старый, когда началась процедура заливки в ClickHouse.
Но, при этом остается момент: ваш заливщик умер, когда уже получил подтверждение от Clickhouse, что все записалось, но не успел зафиксировать это в очереди. Соответственно это нужно проверять.
Если у вас не только insert, но и update, то нужно усложнять архитектуру (заодно и решится выше указанная проблема), нужно удалять предыдущие записи для обновляемых.