Разница в том, что появляется техническая возможность хранить массив данных в QVD, даже если нет возможности прогрузить все исходные данные из источника разом, чтобы сохранить в QVD

Реализовывал такой подход для транзакций платежных систем внутри игрового департамента, там в день могло до 2х миллионов строк транзакций прилетать.
В итоге первичная выгрузка складировала чистые данные по структуре папок год—>месяц->день.
И она же считала агрегаты по такой же структуре.

Инкремент докладывал транзакции в чистые данные и так же инкрементально обновлялись только те дни/месяцы/года в которые прилетало изменение.

И потом уже для разных целей брались агрегаты нужного уровня или чистые данные для точечного анализа

Вот тут описание. И цифры на выходе по обновлению

Источником был сервлет, который возвращал из кубов csv

А зачем его хранить в qvd? Только потому что это быстрее запроса в базу ?

Главное - правильное слово

И Евгений его использовал

Шардирование!!! Это не просто какой нить лайв

И не вот это вот все

Вообщем шардирование - убедило.

Я просто сторонник того что клик не очень для бигдаты. Бигдата это mpp прежде всего и тру масштабирование

От источника зависит)
Сервлет опрашивали раз в час и он не всегда мог вернуть полный объём новых данных, приходилось  сокращать интервал выгружаемых данных порой до 10секунд и делать последовательно выгрузку внутри часа.
Каждый раз опрашивать такой источник целиком не представляется возможным

Хороший вариант

Есть еще вариант когда запросы тупо дольшк чем qvd

может быть быстрее запроса в БД. БД может хуже отрабатывать параллельные запросы множественных пользователей

Ну и не забываем что модель данных может не ограничиваться только тем что есть в БД)

А кстати это интересный вопрос. Есть приложение, в нем динамическая вьюха. Один пользователь загрузил например 10Гб из QVD файлов, другой те же файлы плюс еще 10Гб. Какова утилизация памяти>

30Гб или 10Гб? То есть исопользуют ли динамические вьюхи общее пространство в памяти (верится слабо) или нет