С 12 ТБ данных вы, вероятно, будете смотреть на 500 - 1200 ГБ сжатого размера табличной модели, если вы не сможете уменьшить размер модели, не сохраняя всю историю, удаляя неиспользуемые строки из измерений и пропуская ненужные столбцы. Это очень много даже для табличной модели, которая обрабатывается только еженедельно. Поэтому я согласен, что импортная модель не будет практичной.
Моя рекомендация будет табличной моделью. Для многомерной модели ROLAP по-прежнему требуются размеры MOLAP для приличной работы, и ваши размеры и частота sh сделают это непрактичным.
Таким образом, табличная модель в Azure Analysis Services в режиме DirectQuery должна работать. Если вы хорошо оптимизируете Synapse, вы должны надеяться получить время ответа на запрос в диапазоне 10-60 секунд. Если вы сделаете потрясающую работу, вы, вероятно, сможете получить ее еще быстрее. Но производительность будет во многом зависеть от Synapse. Таким образом, материализованные представления, включающие кэш результатов запросов, обеспечивающие правильное распределение и обеспечивающие хорошее качество сжатия Columnstore, будут важны. Если вы не являетесь экспертом в Synapse и Azure Analysis Services, найдите кого-нибудь, кто вам поможет.
В Azure Analysis Services убедитесь, что вы помечаете отношения как , обеспечиваете ссылочную целостность , которая изменит SQL запросов на внутренние объединения, что повышает производительность. И сделайте модель и расчеты как можно более простыми, поскольку ваша модель очень велика.
Другой альтернативой, если вы хотите очень быстрой производительности интерактивной панели мониторинга для ранее ожидаемых визуализаций, было бы использование Power BI Premium вместо Azure Analysis Services и создание составных моделей. Это позволяет создавать несколько небольших таблиц агг, которые импортируются и быстро отвечают на запросы с ожидаемой зернистостью. Но тогда другие запросы будут «пропускать» агги и запускать SQL запросов к Synapse. Фил Симарк хорошо описывает агрегатов в Power BI.