Делайте расчеты в ETL/ELT инструментах. Думаю понимаете, что никаких курсоров, все считать масс запросами. Для сложных вычислений можно использовать локальные временные таблицы для хранения промежуточных результатов, но помните, что они висят в памяти и кушают с ресурсного пула. Если промежуточные результаты сжирают гигабайты памяти, то лучше их класть в постоянные таблицы, которые перед использованием можно транкейтить.

Правильная схема в Вертике жизни до расчетов:
загрузка первички

фиксация в мониторинге загруженных данных

определение по мониторингу, что уже можно посчитать

расчет витрин и показателей

использование в BI

Однако, есть неприятные моменты, когда считать надо по требованию. Не комментируя, правильно ли это или нет, могу подсказать несколько решений:
1. В мониторе делается флаг требования расчета. Джоб ETL сканирует монитор и увидев выставленный флаг проводит нужные расчеты.
2. Через ESB подключается сервис от ETL, который запускает расчет.
3. На Си/Java делается UDLib, в которой можно дернуть функцию, которая сделает нужный расчет.
Первый способ самый культурный и надежный, с защитой от дурака и прочего. Второй позволяет делать цепочку вызовов разных расчетов. Третий рисковый, но позволяет любому BI через SELECT дернуть напрямую перед работой нужную логику расчетов :)

GuestsASCRUS, Спасибо за подробный ответ!
Уточню пару моментов:
1) "фиксация в мониторинге...", "В мониторе делается флаг требования расчета..."
Про какой монитор речь?

Про Ваш :) Который стоит сделать в виде слоя метаданных в таблицах той же Вертики и фиксировать в нем процессы над ХД.

Guests2) "Правильная схема в Вертике жизни до расчетов:"
На примере 1-й ноды получается, загрузили первичку в Вертику через ETL/ELT - ок,
потом снова тянем данные на сервер ETL/ELT, обрабатываем и возвращаем на сервер Вертики?
Или через ETL/ELT вызывать запросы insert from select?

Через ETL/ELT вызывать запросы insert from select.

Guests3) Есть ли у Вертики открытый роадмэп? Планируются ли процедуры/функции?
Процедуры не планируются. Это же ХД, должен быть какой то централизованный инструмент, управляющий циклом загрузки, преобразованием и хранением данных в хранилище. По многолетнему опыту работы с OLTP могу сказать, что сначала отсутствие ХП напрягает, далее уже привыкаешь к парадигме, что данные отдельно, управляющие процессы отдельно и все выравнивается. Ну а функции есть, элементарно пишутся на Си или Java как библиотеки и подключаются для использования в запросах в Вертике. Мы например писали функции маскирования данных по бизнес сущностям - используем их в COPY для маскирования на момент загрузки столбцов, которые содержат конфиденциальную информацию и не должны в явном виде попадать в ХД.