Подключение к источникам данных 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 как реляционный источник, как показано на следующем рисунке.

Снимок экрана: диалоговое окно параметров, в котором отображаются параметры DirectQuery

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

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

Определение 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 со значениями Bike, Shirt, Glovesи т. д. В этом случае в списке полей отображается одно поле Product , значения которого представляют собой метки Bike, Shirt, Glovesи т. д., но которые сортируются по значениям ключей , , и с уникальностью определяется по значениям 1ключа , 2, 3. Также создается скрытый столбец Product.Key , который при необходимости разрешает доступ к базовым значениям ключа.

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

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

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

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

  • Вычисляемые столбцы не поддерживаются. Возможность создания вычисляемых столбцов отключена. Это также означает, что группирование и кластеризация, создающие вычисляемые столбцы, недоступны.
  • Дополнительные ограничения для мер: Существуют и другие ограничения, накладываемые на выражения 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.

Схема, показывающая запрос, определенный в Редактор Power Query, который возвращает среднюю цену по коду продукта.

Если данные импортируются в 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, этот результат применяется как для случая Import, так и для DirectQuery. В случае DirectQuery запрос из get data или Редактор Power Query используется во вложенном выборке в рамках одного запроса, отправленного в SAP HANA, и поэтому на самом деле не все данные будут считываться, прежде чем выполнять дальнейшую статистическую обработку.

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

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

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

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

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

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

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

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

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

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

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