Ответ от вендора: таблицу сначала группировать не нужно. Вы связываете поля по содержимому, тем самым создавая ось агрегации - одну или сколько угодно. И система автоматически агрегирует данные из нескольких источников по объявленным вами осям агрегации (то есть по связанным полям). Сохранённые DOLAPы (сокр. от distributed OLAP) как результаты расчётов остаются в памяти и следующий пользователь уже не ждёт загрузки первичных данных с диска. При обновлении источника результаты расчётов по нему обнуляются. Управление памятью в rapeed - отдельная большая тема. Мы сделали так, что и при малом объёме ОЗУ система справляется с вычислениями на больших объёмах, делая их медленнее, но надёжно. Чем больше доступной памяти, тем меньше её "круговорот" и тем комфортнее работа пользователей. Название, кстати, для любого англоговорящего человека звучит как "быстрый, молниеносный".
да-да, если у аналитика ЕСТЬ сырые данные, он будет DISTINCTCOUNT использовать. Статья про то, и пример про ту ситуацию, когда сырых данных нет. Тогда и SUM, и DISTINCTCOUNT дадут одну и ту же неправильную сумму.
Речь шла о расчёте в DAX остатков, а не уникальных значений. Как Вы остатки в DAX посчитаете? Если же говорить о расчёте уникальных, то он возможен при наличии сырых данных. О чем и речь в статье.
Несколько случаев из практики использования BI говорят о том, что не в проектах дело. А как вы будете валидировать средние показатели без исходных данных?
Ответ от вендора: таблицу сначала группировать не нужно. Вы связываете поля по содержимому, тем самым создавая ось агрегации - одну или сколько угодно. И система автоматически агрегирует данные из нескольких источников по объявленным вами осям агрегации (то есть по связанным полям).
Сохранённые DOLAPы (сокр. от distributed OLAP) как результаты расчётов остаются в памяти и следующий пользователь уже не ждёт загрузки первичных данных с диска. При обновлении источника результаты расчётов по нему обнуляются.
Управление памятью в rapeed - отдельная большая тема. Мы сделали так, что и при малом объёме ОЗУ система справляется с вычислениями на больших объёмах, делая их медленнее, но надёжно. Чем больше доступной памяти, тем меньше её "круговорот" и тем комфортнее работа пользователей.
Название, кстати, для любого англоговорящего человека звучит как "быстрый, молниеносный".
Не так. ETL решает свои задачи, их много. Наш движок обычно после ETL стоит на хранилище + сырые данные, чтобы их сравнивать.
Всё верно, и только на исходных данных всё рассчитывается непосредственно в момент запроса
да-да, если у аналитика ЕСТЬ сырые данные, он будет DISTINCTCOUNT использовать. Статья про то, и пример про ту ситуацию, когда сырых данных нет. Тогда и SUM, и DISTINCTCOUNT дадут одну и ту же неправильную сумму.
Речь шла о расчёте в DAX остатков, а не уникальных значений. Как Вы остатки в DAX посчитаете?
Если же говорить о расчёте уникальных, то он возможен при наличии сырых данных. О чем и речь в статье.
Несколько случаев из практики использования BI говорят о том, что не в проектах дело. А как вы будете валидировать средние показатели без исходных данных?
И что не так?
У нас нет SQL-запросов. В этом и соль. Как считаются count distinct вживую, можно посмотреть здесь
Это должно быть забавно, особенно для тех, кто не очень хорошо знает английский язык.
По сути статьи вопросы или комментарии есть?
Давно известно, ещё с 14 века примерно.