Подключение к источникам данных SAP HANA напрямую с помощью DirectQuery в Power BI

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

  • Рассматривайте SAP HANA как многомерный источник (по умолчанию): В этом случае поведение будет аналогично тому, когда Power BI подключается к другим многомерным источникам, таким как SAP Business Warehouse или службы Analysis Services. Если при подключении к SAP HANA использовать этот параметр, выбирается одно представление аналитики или вычисления, и все меры, иерархии и атрибуты этого представления будут доступны в списке полей. При создании визуализации сводные данные будут всегда извлекаться из SAP HANA. Этот подход является рекомендуемым и используется по умолчанию для новых отчетов DirectQuery на базе SAP HANA.

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

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

Screenshot of the Options dialog, showing the DirectQuery options.

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

Два подхода формируют разное поведение. Поэтому для существующего отчета невозможно изменить один подход на другой.

Рассмотрим подробнее каждый из этих подходов.

Определение SAP HANA в качестве многомерного источника (по умолчанию)

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

Ниже описаны особенности, характерные при подключении к SAP HANA как к многомерному источнику.

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

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

  • Так как мера используется в визуализации, к SAP HANA будет направлен запрос для получения значения меры на уровне агрегирования, который требуется для визуализации. Поэтому при работе с неаддитивными мерами (счетчики, коэффициенты и т. д.) все операции агрегирования создает SAP HANA, и после этого службе Power BI не нужно создавать их.

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

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

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

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

  • В SAP HANA можно определить атрибут для использования другого атрибута в качестве его метки. Например, атрибут Product со значениями 1, 2, 3 и т. д. можно использовать в качестве метки атрибута ProductName со значениями "Велосипед", "Рубашка", "Перчатки" и т. д. В этом случае одно поле Product будет отображаться в списке полей, значениями которых будут метки "Велосипед", "Рубашка", "Перчатки" и т. д. Но эти значения будут отсортированы по уникальности и по ключевым значениям 1, 2, 3. Кроме того, можно создать скрытый столбец Product.Key, чтобы при необходимости предоставлять доступ к базовым значениям ключа.

Все переменные, определенные в базовом представлении SAP HANA, отображаются во время подключения, и для них можно ввести необходимые значения. Эти значения можно впоследствии изменить. Для этого выберите на ленте элемент Преобразовать данные, а затем в раскрывающемся меню выберите Изменить параметры.

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

Дополнительные ограничения моделирования

Ниже перечислены основные дополнительные ограничения моделирования при подключении к SAP HANA с помощью DirectQuery в Power BI (HANA считается многомерным источником):

  • Вычисляемые столбцы не поддерживаются. Возможность создания вычисляемых столбцов отключена. Это также означает, что группирование и кластеризация, которые создают вычисляемые столбцы, недоступны.
  • Дополнительные ограничения для мер. На выражения DAX, которые могут использоваться в мерах, накладываются дополнительные ограничения, чтобы отразить уровень поддержки, предоставляемый SAP HANA.
  • Определение связей не поддерживается. В отчете можно подать запрос только на одно представление. Поэтому определение связей не поддерживается.
  • Нет представления данных.Представление данных обычно отображает детальные данные в таблицах. Учитывая характер источников OLAP, таких как SAP HANA, это представление недоступно для SAP HANA.
  • Сведения о столбцах и мерах фиксированы. Список столбцов и мер, которые видны в списке полей, фиксируется базовым источником, и его нельзя изменить. Например, нельзя удалить столбец или изменить его тип данных. Но его можно переименовать.
  • Дополнительные ограничения в DAX. Для функций DAX, которые могут использоваться в определениях мер, накладываются дополнительные ограничения в соответствии с ограничениями в источнике. Например, нельзя использовать агрегатную функцию для таблицы.

Дополнительные ограничения визуализации

Ниже перечислены ограничения для визуализаций при подключении к SAP HANA с помощью DirectQuery в Power BI (HANA считается многомерным источником):

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

Определение SAP HANA в качестве реляционного источника

Если выбрать подключение к SAP HANA как реляционному источнику, будут доступны дополнительные гибкие возможности. Например, можно создать вычисляемые столбцы, включить данные из нескольких представлений SAP HANA и создать связи между итоговыми таблицами. Однако это поведение отличается при работе с SAP HANA как с многомерным источником, особенно если представление SAP HANA содержит неаддитивные меры (например, отдельные счетчики или средние значения, а не простые суммы). Отличия касаются производительности запросов, выполняемых к SAP HANA.

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

Diagram showing a query defined in Power Query Editor that returns the average price by Product I D.

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

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

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

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

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

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

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

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

Исходя из указанного выше, при использовании DirectQuery для подключения к SAP HANA нужно учитывать следующие важные моменты:

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

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

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

Screenshot of a query example, showing the S Q L query to S A P HANA.

Поэтому мы рекомендуем выбирать в разделе Получение данных или Редакторе Power Query только необходимые элементы, которые сформируют правильный запрос к SAP HANA.

Советы и рекомендации

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

Рекомендации и ограничения

В следующем списке перечислены все функции SAP HANA, которые поддерживаются не полностью или работают иначе при использовании Power BI.

  • Иерархии дочерних элементов родительских элементов. Иерархии дочерних элементов родительских элементов не отображаются в Power BI. Это связано с тем, что Power BI обращается к SAP HANA с помощью интерфейса SQL, а к иерархиям родителей-потомков невозможно получить полный доступ через SQL.
  • Другие метаданные иерархии. Базовая структура иерархий отображается в Power BI, но некоторые метаданные иерархии (например, метаданные, управляющие поведением неоднородных иерархий) не будут работать. Это ограничение также связано с интерфейсом SQL.
  • Подключение с помощью SSL. Вы можете подключиться с использованием импорта и многомерного источника по протоколу SSL, но нельзя подключиться к экземплярам SAP HANA, настроенным для использования SSL в качестве реляционного соединителя.
  • Поддержка для представлений атрибутов. Power BI может подключаться к представлениям аналитики и вычислений, но не может подключаться напрямую к представлениям атрибутов.
  • Поддержка объектов каталога. Power BI не может подключаться к объектам каталога.
  • Изменение переменных после публикации. Переменные SAP HANA невозможно изменить непосредственно в службе Power BI после публикации отчета.

Известные проблемы

Ниже перечислены все известные проблемы, которые могут возникнуть при подключении к SAP HANA (DirectQuery) с помощью Power BI.

  • Проблема с SAP HANA при выполнении запроса счетчиков и других мер. Если при подключении к представлению аналитики мера счетчиков и другая мера коэффициента включены в одну и ту же визуализацию, из SAP HANA возвращаются неправильные данные. Это рассматривается в примечании SAP 2128928 (непредвиденные результаты при запросе вычисляемого столбца и счетчика). Мера коэффициента в этом случае будет неправильной.

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

Дальнейшие действия

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