Вы можете подключиться к источникам данных SAP HANA напрямую с помощью DirectQuery.

При использовании SAP HANA очень важно понимать некоторые аспекты того, каким образом обрабатываются подключения к этой платформе, чтобы убедиться, что:

  • результаты отображаются должным образом, если представление SAP HANA содержит неаддитивные меры (например, число или среднее значение различных объектов, а не обычные сумы);
  • полученные запросы эффективны.

Когда запрос, определенный в разделе Получение данных или редакторе запросов, выполняет агрегирование, сначала необходимо уточнить поведение реляционного источника, такого как SQL Server. В следующем примере запрос, определенный в редакторе запросов, возвращает значение средней цены по ProductID.

Если импортировать данные в Power BI (вместо использования DirectQuery), мы получим следующие результаты:

  • Данные будут импортированы на уровне агрегата, определенного запросом, созданным в редакторе запросов. Например, средняя цена продукта. В результате мы получаем таблицу с двумя столбцами, ProductID и AveragePrice, которые можно использовать в визуальных элементах.

  • В визуальном элементе любое последующее агрегирование (например, Sum, Average, Min и другие) выполняется над импортируемыми данными. Например, если включить AveragePrice в визуальный элемент, по умолчанию будет использоваться агрегат Sum и будет возвращена сумма AveragePrice для каждого ProductID, в данном случае это — 13,67. Это же правило применяется для альтернативных агрегатных функций (Min, Average и т. д.), используемых в визуальных элементах. Например, значение Average колонки AveragePrice возвращает среднее значение для 6,66, 4 и 3, которое равно 4,56, а не среднее значение столбца Price с 6 записями в базовой таблице, равное 5,17.

Если использовать DirectQuery вместо импорта, будет применена та же семантика и результаты будут совпадать.

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

  • В визуальном элементе любое последующее агрегирование (Sum, Average, Min и другие) снова выполняется над логической таблицей из запроса. Как видим, визуальный элемент, который содержит среднее значение записей в колонке AveragePrice, возвращает то же значение — 4,56.

Теперь давайте рассмотрим SAP HANA. В SAP HANA Power BI может работать с аналитическими представлениями и представлениями вычисления, которые могут содержать меры. Тем не менее сегодня подход к SAP HANA основан на тех же принципах, которые были описаны ранее. Запрос, указанный в колонке Получение данных или редакторе запросов, определяет доступные данные, после чего любое последующее агрегирование в визуальном элементе выполняется над этими данными. Это же правило применяется для импорта и DirectQuery.

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

Эквивалентом приведенного выше примера SQL Server является представление HANA, содержащее записи ID, ProductID, DepotID и меры, включая AveragePrice, определенную в представлении как среднее значение цены.

Если в представлении Получение данных выбраны элементы для меры ProductID и AveragePrice, то по этому представлению запрашивается статистическая обработка данных (в примере выше для простоты используется псевдо-SQL, который не соответствует точному синтаксису HANA SQL). После чего все последующие агрегаты, определенные в визуальном элементе, создают сводку результатов этого запроса. Точно так же, как описано ранее для SQL Server, это применяется для импорта и DirectQuery. Обратите внимание, что в DirectQuery запрос из Получение данных или редактора запросов будет использоваться в подзапросах в рамках одного запроса, отправленного HANA. Таким образом, нельзя утверждать, что все данные будут считываться перед дальнейшим агрегированием.

Это приводит к возникновению следующих важных рекомендаций по использованию DirectQuery с помощью HANA:

  • Необходимо уделять внимание последующему агрегированию в визуальных элементах, если меры в HANA неаддитивные (например, не являются простым агрегатом Sum, Min или Max).

  • В представлении Получение данных или редакторе запросов, чтобы получить необходимые данные, должны быть включены только необходимые столбцы, что отражает тот факт, что результатом должен быть подходящий запрос, который можно отправить HANA. Например, если выбраны десятки столбцов, потому что они могут понадобиться для последующих визуальных элементов, то даже простой визуальный элемент для DirectQuery будет означать, что статистический запрос, используемый в подзапросе, содержит десятки столбцов, что снижает производительность.

Давайте рассмотрим пример. В следующем примере, если выбрать пять столбцов (CalendarQuarter, Color, LastName, ProductLine, SalesOrderNumber) в диалоговом окне Получение результатов вместе с мерой OrderQuantity, то это будет означать, что дальнейшее создание простого визуального элемента, содержащего Min OrderQuantity, приведет к следующему запросу SQL для HANA. Затененная часть – это подзапрос, содержащий запрос из диалогового окна Получение данных или редактора запросов. Если подзапрос приведет к результату с очень большим количеством элементов, то весьма вероятно, что производительность HANA будет низкой.

Поэтому рекомендуется выбирать в окне Получение данных и редакторе запросов только необходимые элементы, которые по-прежнему сформируют подходящий запрос HANA.

Дополнительные сведения

Дополнительные сведения о DirectQuery см. в следующих статьях: