Табличная модель AAS в режиме DirectQuery повышает производительность - PullRequest
2 голосов
/ 06 февраля 2020

Предположим, у вас есть 10 довольно больших таблиц фактов (каждая по 50-100 ГБ), которые следует запрашивать с помощью Power BI. Они не вписываются в Azure RAM служб анализа (разумная цена). Таким образом, чтобы использовать табличную модель и AAS, вы должны придерживаться следующей схемы:

(1) Power BI Desktop -> Azure Analysis Services -> [DirectQuery] -> SQL Database

Но насколько я знаю из этой статьи , табличная модель AAS не кеширует какую-либо агрегированные результаты (значит, не потребуются дополнительные оптимизации производительности). Более того, AFAIK, Power BI (PowerPivot) уже имеет встроенный AAS.

В качестве альтернативы я могу запросить SQL источник данных напрямую из Power BI:

(2) Power BI Desktop -> [DirectQuery] -> SQL Database


Обеспечивает ли 1-я схема (с использованием AAS) какие-либо преимущества в производительности по сравнению с 2-я схема (без использования AAS)?

PS Мой вопрос не о плюсах и минусах слоя semanti c, см. в этой статье . Этот вопрос отличается от этого вопроса , поскольку он касается только аспекта производительности ASS DirectQuery.

1 Ответ

2 голосов
/ 06 февраля 2020

Повышение производительности потребует тестирования в зависимости от вашей рабочей нагрузки и других факторов.

Предостережение (Этот ответ основан на моем собственном опыте и опыте моих коллег и тестирования)

Стандарт обслуживания: С точки зрения обслуживания основное различие будет между Azure Службами анализа (AAS) и Службой Power BI (PBIS) в том, что AAS представляет собой известный набор аппаратного обеспечения / производительности, где PBIS является общей емкостью и может страдать от проблем «шумного соседа», если другой клиент находится в том же кластере и интенсивно использует его, это повлияет на производительность вашего отчета.

Производительность: По сути, PBI и AAS делают одно и то же, переводят DAX в запрос SQL и затем возвращают данные. Исходя из моего опыта построения PBI и AAS с точки зрения производительности, между ними нет большой разницы. Основной проблемой, которая обычно является узким местом, является использование шлюза для локальной SQL и емкости сервера SQL либо на локальной, либо в облачной среде. Например, для повышения производительности вы можете использовать кластеризованные индексы столбцов для переноса, например, таблиц фактов в память, и будет проще увеличить / уменьшить Azure SQL DTU базы данных / емкость в рабочие часы.

В настоящее время AAS не имеет агрегированного режима, который есть в PBI, который может уменьшить количество запросов, отправляемых обратно, и немного быстрее, но также имеет недостаток, заключающийся в том, что в какой-то момент его нужно обновлять.

Я бы порекомендовал провести тестирование с использованием, например, DAX Studio, чтобы увидеть, какие изменения вы можете получить в производительности. Мое собственное тестирование показало различия в диапазоне от миллисекунды до 1 секунды в пользу AAS.

Однако преимущества слоя semanti c являются важным фактором

Соединения: AAS поддерживает другие соединения, такие как Excel, SSMS, SSRS и т. Д. c лучше, чем Power BI. Excel может подключаться к моделям Power BI с помощью дополнительного подключаемого модуля.

Поддержка: В Visual Studio / SSDT с помощью Azure поддерживать модель данных в течение всего ее жизненного цикла намного проще. DevOps, Git et c. чем в Power BI Desktop. С помощью AAS вы также можете использовать группы вычислений для вычислений с учетом времени, а не множественные меры или обходные пути для YTD, параллельного периода, MTD и т. Д. При использовании AAS из-за преимуществ, связанных с отсутствием факторов производительности, перед переключением он должен будет значительно улучшить производительность.

Надеюсь, что это поможет

...