Поделиться через

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

  • Статья

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

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

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

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

снимок экрана диалогового окна

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

Два метода подключения SAP HANA представляют собой разное поведение, и невозможно переключить существующий отчет из одного метода подключения на другой.

Рассматривать SAP HANA как многомерный источник (по умолчанию)

Все новые подключения к SAP HANA используют этот метод подключения по умолчанию, рассматривая SAP HANA как многомерный источник. При подключении к SAP HANA в качестве многомерного источника применяются следующие рекомендации.

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

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

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

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

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

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

  • Любой атрибут, включенный по крайней мере в одну иерархию, по умолчанию скрыт. Однако их можно увидеть, если это необходимо, выбрав Просмотреть скрытые в контекстном меню списка полей. В том же контекстном меню они могут быть видимы при необходимости.

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

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

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

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

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

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

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

При подключении к SAP HANA в качестве многомерного источника существуют ограничения в визуальных элементах:

  • Нет агрегирования столбцов: невозможно изменить способ суммирования столбца на визуальном представлении, всегда Не суммировать.

Рассматривать SAP HANA как реляционный источник

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

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

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

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

Диаграмма, показывающая запрос, определенный в редакторе Power Query, который возвращает среднюю цену по идентификатору продукта.

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

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

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

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

  • В визуальном элементе все последующие агрегаты, такие как Сумма, Среднееи Минимум, выполняются снова над этой логической таблицей из запроса. И снова визуальный элемент, содержащий среднее значение от AveragePrice, возвращает те же 4,56.

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

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

Если в интерфейсе получения данных выбраны ProductID и мера AveragePrice, то это определяет запрос по представлению, запрашивая эти статистические данные. В предыдущем примере для простоты используется псевдо SQL, который не соответствует точному синтаксису SAP HANA SQL. Любые дальнейшие агрегирования, определенные в визуализации, дополнительно объединяют результаты этого запроса. Как ранее описано для SQL Server, этот результат применяется как в случае Import, так и DirectQuery. В случае DirectQuery запрос из Get Data или редактор Power Query используется в подзапросе в рамках одного запроса, отправляемого в SAP HANA, и поэтому не происходит предварительное считывание всех данных перед их дальнейшей агрегацией.

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

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

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

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

снимок экрана: пример запроса, показывающий SQL-запрос к SAP HANA.

Из-за этого мы рекомендуем, чтобы элементы, выбранные в получение данных или в редакторе Power Query, ограничивались только необходимыми элементами, при этом по-прежнему приводя к разумному запросу к SAP HANA. По возможности рекомендуется повторно выполнить все необходимые меры в семантической модели и использовать SAP HANA больше как традиционный реляционный источник.

Лучшие практики

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

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

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

  • Родительские-дочерние Иерархии: Родительские-дочерние иерархии не отображаются в Power BI. Это связано с тем, что Power BI обращается к SAP HANA с помощью интерфейса SQL, а родительские дочерние иерархии не могут быть полностью доступны с помощью SQL.
  • другие метаданные иерархии: базовая структура иерархий отображается в Power BI, однако некоторые метаданные иерархии, такие как управление поведением неровных иерархий, не имеют никакого эффекта. Опять же, это связано с ограничениями, введенными интерфейсом SQL.
  • подключение с помощью SSL: можно подключиться с помощью импорта и многомерного подключения с TLS, но не удается подключиться к экземплярам SAP HANA, настроенным для использования TLS для метода реляционного подключения.
  • поддержка представлений атрибутов: 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 используется в нескольких иерархиях, SAP HANA предоставляет столбец в виде двух отдельных атрибутов. Этот подход приводит к созданию двух столбцов в Power BI. Однако эти столбцы скрыты по умолчанию, и все запросы, связанные с иерархиями, или столбцы напрямую ведут себя правильно.

Связанное содержимое

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