Можно почитать про vertipaq engine

При импорте Power bi с одной стороны данные сожмет, вопрос того, насколько хорошо их бд жала, конечно,
Но с другой стороны, для быстрой работы данных в оперативке этой самой оперативки нужен запас. Есть разные оценки, но разброс 50-150%. Если загрузим в память ровнехонько столько данных, сколько есть памяти, или даже чуть меньше, работать будет очень плохо и медленно

При импорте Power bi с одной стороны данные сожмет, вопрос того, насколько хорошо их бд жала, конечно,
Но с другой стороны, для быстрой работы данных в оперативке этой самой оперативки нужен запас. Есть разные оценки, но разброс 50-150%. Если загрузим в память ровнехонько столько данных, сколько есть памяти, или даже чуть меньше, работать будет очень плохо и медленно

и поэтому возвращаемся к моему вопросу: размер выгружаемой БД ограничен размером доступной оперативки? если оперативки хоть на байт меньше, чем размер БД (ну имеется ввиду итоговый для целей pbi. там же разное хранение. разный учёт. поэтому усредним, что это уже размер того, что принял у себя pbi), то данные не загрузятся?

Ожидали такой результат?

Тут уже сугубое ИМХО. Биг дату в принципе можно обрабатывать как в классических SQL хранилищах, так и в вот в этом всем. Если данные норм структурированы то имхо лучше сразу строить нормальное ХД, MPP Субд (а если в 6НФ, то можно брать и не столь уж структурированные данные) норм справятся с любыми обьемами при грамотном проектировании. А если данные не структурированы, или проблемы с проектированием - то приходится крутить Apache Spark, Hadoop, и прочее. Такое ИМХО, тема не совсем моя.

Выбрать между кубами MD или Tabular легко, просто делайте в том в чем умеете, результат в любом случае будет лучше, чем делать в том в чем не умеешь). Если навык одинаковый и там и там (0)), или просто смотрите на перспективу, то берите Tabular, он современный, он развивается, он инмемори, разрабатывать гора-аздо в нем проще и быстрей, и при этом результат не страдает, не надо заморачиваться с дизайном агрегаций и прочим. Язык DAX, имхо, более понятен чем MDX, есть оч. удобный инструмент DAX Studio, отладка запросов делается гораздо приятней чем в MDX, и DAX используется в SSAS и в PBI, плюс можно спихнуть часть разработки на аналитиков, тот же PBI позволят писать собственные меры при прямом подключении к Tab кубу. В целом связка PBI+Tabular богата на возможности - можно реализовать incremental update в кубе, без всяких PBI Premium. Tabular куб опять же многое прощает, но до определенного предела, потом все равно надо вникать в оптимизацию. И несмотря на ограниченность обьемами оперативной памяти и лицензией, запихнуть туда можно очень много, при грамотном проектировании, запихивают до десятков миллиардов строк в пределе.

Ссылки почитать.. да еще valuable.. читайте книжки итальянце в части моделирования SSAS Tabular, не ошибетесь )

О, моя тема :)
В общем, различие oltp/olap это основа, которая за последние 20+ лет особо и не изменилась
Всегда, вне зависимости от BI системы, данные для отчетов всегда стремились денормализовать вплоть до 1й плоской таблицы.
Но сам вопрос шире, и тут нужны годы, чтобы не только понять теорию, но и освоить, набить шишек на практике.

Можете попробовать пройти курсы для подготовки к экзаменам МС по разработке хранилищ данных и моделей данных.
К примеру курсы Специалиста, от Самородова, - для начинающих очень неплохо, мне в свое время понравилось, дается некий фундамент, подход Инмона, Кимбалла, отличие olap и oltp, построение всяких SCD2, паттерны захвата измененных данных и тд
Книжки итальянцев тоже хорошо раскрывают тонкости проектирования ХД и olap, причем старые книжки навроде "Expert Cube Development with SSAS Multidimensional Models" - раскрывают подходы к построению ХД в тч.. хотя новые наверное тоже )
Далее - уже практика и самостоятельное изучение. чтение статей, посещение конференций, вебинаров и тд. Подходов очень много, Кимбалл и Инмон - только основа, кроме них есть подходы гибридные, а есть вообще никак с ними не связанные, к примеру - на 6НФ (anchor modelling), плюс еще делают гибридную OLTP/OLAP базу, когда поверх OLTP базы строятся Nonclustered columnstore indexes для целей аналитики, плюс есть MPP базы для сверхбольших данных. Очень много всего, и это почти никак не структурировано концептуально, тк все очень специфично, структурированы только основы.

Teradata же, это Massive parallel processing БД, для реально больших объемов (десятки, сотни миллиардов и больше строк). На практике я дела с ними не имел, но опыт коллег мониторил. И тут подход в части BI уже другой, тут отказываются от какого либо импорта данных в средство BI или олап кубов ( ну либо только если есть возможность импортировать совсем сверхагрегированные данные), - от всего этого отказываются, а работают с помощью прямого подключения, Direct Query, т.е. БД должна отрабатывать все запросы к данным, фильтрацию, агрегацию - на лету, и понятно, что для этого необходимо специально проектировать хранилище, чтобы запросы максимально и равномерно параллелились между нодами. И соответственно куча заморочек, специфичных именно для MPP СУБД.

@iashell - такой вопрос, как знатоку кастомных форматов - Можно ли в Power BI десятичные дроби отображать как "обычные" - например - 2.5 показать как 2 1/2 и т.п.

Ожидали такой результат?

А пользовательский формат не позволяет?)