Исходные данные:
Windows: 2016 Standart
Процессор: 2 Xeon E5-2697 v4 (18 ядерные) - 72 потока
Диски: полка SSD (20Тб) - c пиковой скоростью 3Гб /сек
ОЗУ: 1.5Тб (Терабайт)
SSAS: 2019EE

Куб на полном объеме процессился на SQL-2008R 6.5 часов на 64 потоках
Сейчас процесс идет более 12 часов -- пока не окончился ....

Куб:
10 групп мер в среднем по 20 показателей
Примеры групп
Остатки: 12 млрд записей - 1.2ТБайт
Продажи: 4 млрд записей - 400 Гб
10 групп many-to-many -- применены для быстрого расчета DistinctCount

Общий размер хранилища 3ТБайт - данных для OLAP

В хранилище данные разделены на месячные секции : размер секций для остатков 50Гб в среднем, по продажам 15Гб

Группы мер разделены на партиции по дням максимум 12млн записей на пратицию, параметр Slice определен

Настройки SSAS:
HardMemoryLimit = 70
TotalMemoryLimit = 60
LowMemoryLimit = 50

Query\MinThreads = 36
Query\MaxThreads = 72

Process\MinThreads = 180
Process\MaxThreads = 360

CoordinatorExecutionMode = -36
FlightRecorder\Enabled = 0

CoordinatorQueryBalancingFactor=1
CoordinatorQueryBoostPriorityLevel=0

RandomFileAccessMode=0

FactPrefetchMode = 1

Где еще копать ?
MS SQL настроен оптимально

Перевел и XD и SSAS

Проект SSAS был подготовлен на 2008 для 2019 просто сконвертил и пытаюсь сделать процессинг на 2019 -- тормозит (14 часов уже процессит) .
Тот же проект на тех же данных и оборудовании на 2008R2 6.5 часов процессится
настройки OLAP те же самые кроме RandomFileAccessMode

Организация: торговая сеть 10 тыс магазинов, 2 тыс активных товаров (всего с архивными 17 тыс)
Поддержкой занимаюсь 1 , данные закачиваются из полностью самописной 1с8 ,
Загрузка / выгрузка с помощью BCP и BULK INSERT, подготовка XD за 1 день около 1 часа
Измерения маленькие

Премьер-поддержки от MS - нет

Вопрос то в том что SSAS 2008R2 обрабатывает все нормально - источник XD один и тот же
Статистику обновить на MS SQL -- возможно в этом проблема - но 2008-му это не мешает

Поставщик данных (Data Provider) имеет значительное влияние на то, как быстро Analysis Services может потреблять поступающие данные с источника. Смените провайдер с SQL Server Native Client на Microsoft OLE DB Provider for SQL Server, пропускная способность может повыситься на 30%. Правда, компания Microsoft заявляла, что OLE DB станет устаревшей функцией
-- Источник: https://www.dvbi.ru/articles/reading/SSAS-optimization


Пользовался для SQL-2008 такой рекомендацией - возможно ODBC на 18.3 надо обновить

Все совершенно верно

--- тормозит процессинг только на новом SSAS

Один и тот же сервер
Один и тот же источник данных
Одна и та же сеть
Диск один и тот же для сборок

Наибольший вклад в тормоза -- агрегация данных
Такое впечатление по 3 раза агрегации обходит
Cмотрю на диск каталог Data -- размер каталога не меняется -- хотя монитор системы показывает что интенсивно пишет .
В Temp вообще пусто - так как это сборка первый раз

Нет . Попробуем в эту сторону покопать

Все совершенно верно

--- тормозит процессинг только на новом SSAS

узкое место нашел
processing data,index - все нормально скорость очень высокая доходит запись/чтение до 2Гб сек когда доходит до агрегатов скорость падает до 33 Мб сек и молотит бесконечно, чтения SQL базы уже совсем нет

Как вариант дизайн агрегатов заново сделать на 2019

Ускорить этот этап агрегаций настройками никак нельзя ???

Спасибо не знал

Вот как раз и переразворачивал
Вот в том и дело что все помечено - под руководством службы поддержки

Это точно -- делал агрегаты до дня

Вчера переделал:
1. Агрегаты - убрал уровень день
2. Убрал many-to-many заменил на DistinctCount

Вроде залетало - но так и не получилось собрать - не хватило места для TempDB SQL (было на RAM) - включу оптимизацию TempDB для 2019

Дело в том , что MS SSAS 2008 нормально все скушал при переносе базы на SQL 2019
И основная проблема была не в получении данных - а в дизайне агрегаций и избыточных many-to-many

a_voronin,

Понятно что немного другая тема
Но когда создавались агрегаты увидел что куча полей измерений по которым при агрегации установлено None в каждую партицию копируется
Данные поля - не используются в итогах - это просто свойства измерений

Если сделать IsAggregation = False ничего страшного не произойдет ?

У меня как-то не было до этой работы больших кубов - 2Тб - в основном мелочь была до 100Гб и особых настроек не требовалось

Спасибо
Как бы так и делаю.

Пока готовый куб не превысил 2Тб и время не зашкалило за 6 часов
об оптимизации не задумывался.
3-4 часа на процессинг при объеме готового куба 1Тб вполне устраивало .

Структуру измерений не думая перенес из 1С вместе с типами и размерами, придется уплотнять неявными преобразованиями через View

Взрывного роста объема не предвидится (все большие факты уже готовы)
У аналитиков плавающее окно данных - 3 года им достаточно .
Максимум предполагаю в 2 раза вырастет
Обновления за 1 день укладываются в 1 час -- круглосуточной работы аналитиков не предвидится .

Спасибо за рекомендации


Сделал неправильно - пошел по пути наименьшего сопротивления
В 1С ключевые поля Binary(16) - сделал CAST(IDREF As Bigint) -- получились все ключи уникальные но без обратного преобразования в 1С и понятно что не легкие

Переводить все справочники и перечисления в легкие ключи (int) не так просто
т.е. надо вытаскивать из всех справочников коды (а их может и не быть),
а перечисления вообще без кодов , а если документы вытаскивать то вообще проблема какие преобразования делать . Даже на 1с77 пришлось для документов ключ bigint делать

Пути для оптимизации понятны -- буду делать

Примечание: чуть-чуть пересекается с темой "зачем эти преобразования" ...

Сеть "Красное и белое"
https://ru.wikipedia.org/wiki/Красное_и_Белое


База в 1С8 живет 7 лет и общим сканированием ключей bigint по всем документам и справочникам повторения нет (пока)
В каждом магазине (8500 магазинов) своя база - каждый день идет обмен
(товары централизованно вводятся) и коллизий не возникает, также есть стыковка со сторонними программами


Вот у нас сделали отдельную базу 1С для хранения детальных чеков до товара
И внутренние разработчики ничего "умнее" не придумали как сделать регистр сведений с ключевыми полями НомерМагазина (varchar(5)) + КодТовара(varchar(5))+НомерЧека(varchar(18)) и отдельно регистр с шапкой чека
с ключевыми полями Период(Date) + НомерМагазина (varchar(5)) + НомерЧека(varchar(18))
Так загрузка этих данных занимает 50% от загрузки всех данных


Ну насколько я понял - слетят фильтры - когда в отчете отфильтровано по определенному товару и магазину - это не страшно ....

Таких отчетов единицы - пользуются OLAP пока 30 аналитиков -- т.е. проект пока в этапе опытно-промышленной эксплуатации (начали интенсивно с 1 марта пользоваться)
И мои аналитики занимаются в корне неправильным формированием отчетов
1.Формируют "простыню" (без кодов товара) по всем товарам по датам без всякой фильтрации с выводом в столбцах всех атрибутов товара
2.Переводят эту таблицу в POWER BI и там уже делают DashBoard
-- либо свою сводную делают
3.Стыковку с пока недостающими данными из 1С делают по наименованию товара через ВПР() .....

С переходом на 2019 убираю лишние атрибуты . Пример дублировал наименование отдельным атрибутом (был случай в предыдущих местах когда пользователям было нужно и краткое наименование и полное) - здесь это избыточное поле тормозящее расчеты
В любом случае придется моим аналитикам отчеты переделывать


Внутрь OLAP особо никогда не залезал, но проанализировал сейчас структуру и понятно что можно в 2 раза утрамбовать с переходом на суррогатные ключи