Нет однозначного ответа, ответ зависит от приоритетов, там обычная модель стоимость/выгода так минимум (в т.ч. финансово и обслуживание)
от таких факторов как импортируемый размер и ограничения сервера по памяти, необходимая скорость
получения данных (не только процессинга, но и получения результата на запрос пользователя)
материализация всего (на разумно смоделированной гранулярности) обычно ведёт к ускорению получения ответа на запрос,
если расчётами делать - снизив материализацию то можно ускорить процессинг но во время runtime запроса пользователями будет замедление.
для мелких измерений в принципе всё равно, для крупных уже надо смотреть баланс факторов и предъявляемые к системе цели
а дальше подбирать под эти приоритеты через профайлинг - что быстрее, с вариациями фильтраций на уровне M или DAX партиций
из основного измерения/источника уже на уровне SSAS (которая всё-таки по идее работает всё равно на columnstore
и там нет network overhead т.к. всё происходит внутри, многопользовательской нагрузки как на DWH т.к.
SSAS обычно dedicated на одну задачу и нет на заднем плане параллельных ETL для других job-ов


Судя по тому что я помню от пары лет назад - партиции бывают как минимум следующих типов:
Type:1-Query (Legacy),2-Calculated,3-None,4-M/PowerQuery,5-Entity, 6-?, 7-(calculation group?) может ещё что добавили

Ибн Хоттаб,

Навскидку там не только calculated колонны (плюс отдельный вопрос: таблицы) но и меры
если упрощённо разложить по шагам то насколько я помню под вечер - есть такие варианты:
1) в источнике (нагрузка на получение данных/сеть и sql? сервер)
2) в PowerQuery/M вычисляемые таблицы
3) в PowerQuery/M вычисляемые колонны
4) в DAX вычисляемые таблицы (в т.ч. основа Calculation Groups без колон/мер)
5) в DAX вычисляемые колонны
6) в DAX вычисляемые меры

Первые 3 материализуются (во время процессинга, на разных его шагах, смотрим на нагрузку ядер cpu,
ставим память побыстрее, с дисками - вроде всё в памяти, посл. не проверял - не было необх.)

Последние 3 рассчитываются во время сессии пользователя / запросов
(на разных шагах, некоторые сразу при инициализации, некоторые по необходимости - меры)

По процессингу надо смотреть где тормозит (Data/Recalc)
https://docs.microsoft.com/en-us/analysis-services/tabular-models/process-database-table-or-partition-analysis-services

Может там на PowerQuery тормоза а не в источнике.
может сеть очень узкая - тогда разумней вытащить нужный датасет один раз и уже на SSAS разложить по своим объектам

При разумной организации если не городить непролазный лес
(падение из-за низкокачественной модели/кода)
и глобальная цель именно ускорение процесинга
(и модификация источника невозможна, напр. cpu быстрее не поставить и пр.)
то можно частично переложить часть ожидания на пользователя - расчёты во время сессии (DAX)
если там пару сотен миллисекунд, если там минуты то естественно пользователь пошлёт такое решение куда подальше

это всё так - пальцем в небо, в общем, а в реальности надо-бы определить - где тормозит.
бывает паралельность лучше урезать.. у нас на нагрузочномм тестировании обычно гоняют и мониторинг на узкие места - потом смотрим можно-ли подкрутить получше..

ну в смысле если речь о 10+ миллионах записей в справочнике (партициями), если там пару тыс. строчек без особых перспектив стремительного роста - то какая разница, можно не заморачиваться (хоть direct query)
// хотя конечно бывает и десяток нужных строчек тянут из многомилионных таблиц по 10 минут..