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

Разработка семантических моделей Direct Lake

  • Статья

В этой статье описываются темы проектирования, относящиеся к разработке семантических моделей Direct Lake.

Создание модели

Портал Fabric используется для создания семантической модели Direct Lake в рабочей области. Это простой процесс, включающий выбор таблиц из одного озера или хранилища для добавления в семантику модели.

Затем можно использовать интерфейс веб-моделирования для дальнейшего разработки семантической модели. Этот интерфейс позволяет создавать связи между таблицами, создавать меры и группы вычислений, помечать таблицы дат и задавать свойства для модели и его объектов (например, форматов столбцов). Вы также можете настроить модель безопасности на уровне строк (RLS), определив роли и правила, а также добавив участников (учетные записи пользователей Или группы безопасности Microsoft Entra) в эти роли.

Кроме того, вы можете продолжить разработку модели с помощью средства, совместимого с XMLA, например SQL Server Management Studio (SSMS) (версии 19.1 или более поздней) или с открытым кодом, средств сообщества. Дополнительные сведения см. в разделе Поддержка записи модели с конечной точкой XMLA далее в этой статье.

Совет

Вы можете узнать, как создать lakehouse, таблицу Delta и базовую семантику Direct Lake, выполнив этом руководстве.

Таблицы моделей

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

Таблицы должны содержать столбцы для фильтрации, группировки, сортировки и суммирования в дополнение к столбцам, поддерживающим связи модели. Хотя ненужные столбцы не влияют на производительность запросов семантической модели (так как они не загружаются в память), они приводят к большему размеру хранилища в OneLake и требуют больше вычислительных ресурсов для загрузки и обслуживания.

Предупреждение

Использование столбцов, которые применяют динамическое маскирование данных (DDM) в семантических моделях Direct Lake, не поддерживается.

Сведения о выборе таблиц для включения в семантическую модель Direct Lake см. в разделе Изменение таблиц для семантических моделей Direct Lake.

Дополнительные сведения о столбцах для включения в таблицы семантической модели см. в статье Общие сведения о хранилище для семантических моделей Direct Lake.

Принудительное применение правил доступа к данным

Если у вас есть требования к доставке подмножества данных модели различным пользователям, вы можете применить правила доступа к данным. Правила применяются путем настройки безопасности на уровне объектов (OLS) и (или) безопасности на уровне строк (RLS) в конечной точке аналитики SQL или семантической модели.

Заметка

Тема применения правил доступа к данным отличается, но связана с настройкой разрешений для потребителей содержимого, создателей и пользователей, которые будут управлять семантической моделью (и связанными элементами Fabric). Дополнительные сведения о настройке разрешений см. в статье Управление семантических моделей Direct Lake.

Безопасность на уровне объекта (OLS)

OLS включает ограничение доступа к объектам или столбцам для их обнаружения и запроса. Например, можно использовать OLS для ограничения пользователей, которые могут получить доступ к столбцу Salary из таблицы Employee.

Для конечной точки аналитики SQL можно настроить OLS для управления доступом к объектам конечной точки, таким как таблицы или представления, а также безопасность на уровне столбцов (CLS) для управления доступом к столбцам таблиц конечных точек.

Для семантической модели можно настроить OLS для управления доступом к таблицам моделей или столбцам. Для настройки OLS необходимо использовать средства сообщества с открытым кодом, такие как табличный редактор.

Безопасность на уровне строк (RLS)

RLS включает ограничение доступа к подмножествам данных в таблицах. Например, вы можете использовать RLS, чтобы гарантировать, что продавцы могут получать доступ только к данным о продажах для клиентов в их регионе продаж.

Для конечной точки аналитики SQL можно настроить RLS для управления доступом к строкам в таблице конечных точек.

Важный

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

Для семантической модели нужно настроить RLS для управления доступом к строкам в модельных таблицах. RLS можно настроить в веб-моделировании или с помощью стороннего средства.

Как оцениваются запросы

причина разработки семантических моделей Direct Lake заключается в достижении высокой производительности запросов по большим объемам данных в OneLake. Поэтому следует стремиться к разработке решения, которое повышает вероятность запросов в памяти.

Следующие шаги описывают, как оцениваются запросы (и успешность их выполнения). Преимущества режима хранения Direct Lake возможны только при достижении пятого шага.

  1. Если запрос содержит любую таблицу или столбец, ограниченный семантической моделью OLS, возвращается результат ошибки (визуальный элемент отчета не сможет отобразиться).
  2. Если запрос содержит столбец, доступ к которому ограничен конечной точкой CLS аналитики SQL (или таблица недоступна), возвращается ошибка (визуальный элемент отчета не будет отображаться).
    1. Если облачное подключение использует SSO (по умолчанию), среда CLS определяется уровнем доступа потребителя отчета.
    2. Если облачное подключение использует фиксированное удостоверение, CLS определяется уровнем доступа этого фиксированного удостоверения.
  3. Если запрос содержит любую таблицу в конечной точке аналитики SQL, которая применяет RLS или представление используется, запрос возвращается в режим DirectQuery.
    1. Если облачное подключение использует систему единого входа (по умолчанию), RLS определяется уровнем доступа к отчету потребителя.
    2. Если облачное подключение использует фиксированное удостоверение, RLS определяется уровнем доступа фиксированного удостоверения.
  4. Если запрос превышает ограничения емкости, он возвращается в режим DirectQuery.
  5. В противном случае запрос удовлетворен из кэша в памяти. Данные столбцов загружаются в память по мере необходимости.

Разрешения исходного элемента

Учетная запись, используемая для доступа к данным, является одной из следующих.

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

Учетная запись должна иметь по крайней мере разрешения Чтение и ReadData для исходного элемента (lakehouse или warehouse). Разрешения на элементы могут наследоваться от ролей рабочей области или быть назначены явно для конкретного элемента, как описано в этой статье.

Если это требование выполнено, Fabric предоставляет необходимый доступ к семантической модели, чтобы читать таблицы Delta и связанные файлы Parquet (для загрузки данных столбцов в память), и можно применять правила доступа к данным.

Параметры правила доступа к данным

Вы можете настроить правила доступа к данным в:

  • Только семантическая модель.
  • Только конечная точка аналитики SQL.
  • Как в семантической модели, так и в конечной точке аналитики SQL.

Правила в семантической модели

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

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

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

Важный

Разрешения элемента семантической модели можно явно с помощью приложений Power BIили получать неявно с помощью ролей рабочей области.

В частности, правила доступа к данным семантической модели не применяются для пользователей, у которых разрешение на запись для семантической модели. И наоборот, правила доступа к данным применяются к пользователям, которым назначена роль просмотра рабочей области. Однако пользователи, назначенные роли Администратор, Участникили роли Участник, неявно имеют разрешение на запись в семантической модели, и поэтому правила доступа к данным не применяются. Дополнительные сведения см. в разделе Роли в рабочих областях.

Правила в аналитической конечной точке SQL

Необходимо применять правила доступа к данным на конечной точке аналитики SQL, когда семантическая модель, подключаемая к облаку , использует единый вход (SSO) . Это связано с тем, что полномочия пользователя делегированы для запроса точки доступа аналитики SQL, гарантируя, что запросы возвращают только те данные, к которым пользователь имеет доступ. Кроме того, необходимо применить правила доступа к данным на этом уровне, когда пользователи будут запрашивать конечную точку аналитики SQL непосредственно для других рабочих нагрузок (например, чтобы создать отчет с разбивкой на страницы Power BI или экспортировать данные).

В частности, запрос семантической модели возвращается в режим DirectQuery, если он включает в себя любую таблицу, которая применяет RLS в конечной точке аналитики SQL. Следовательно, семантическая модель никогда не кэширует данные в память, чтобы обеспечить высокую производительность запросов.

Правила на обоих уровнях

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

Сравнение параметров правила доступа к данным

В следующей таблице сравниваются параметры настройки доступа к данным.

Применение правил доступа к данным Комментарий
Только семантическая модель Используйте этот параметр, если пользователи не имеют разрешения выполнять запросы к lakehouse или складу. Настройте облачное подключение для использования фиксированного удостоверения. Высокую производительность запросов можно достичь из кэша в памяти.
Только конечная точка аналитики SQL Используйте этот параметр, если пользователям нужно получить доступ к данным из хранилища или семантической модели, а также с согласованными правилами доступа к данным. Убедитесь, что единый вход включен для облачного подключения. Производительность запросов может быть медленной.
Семантическая модель озеро-хранилища или склада и Этот параметр включает дополнительные затраты на управление. Настройте облачное подключение для использования фиксированного идентификатора.

Ниже приведены рекомендации, связанные с применением правил доступа к данным:

  • Если разные пользователи должны быть ограничены подмножествами данных, при необходимости применяйте RLS только на уровне семантической модели. Таким образом, пользователи получат преимущества от высокопроизводительных запросов в памяти. В этом случае настоятельно рекомендуется, чтобы облачное подключение использовало фиксированное удостоверение вместо единого входа.
  • Если это возможно, избегайте применения OLS и CLS на любом уровне, так как это приводит к ошибкам в визуальных элементах отчета. Ошибки могут привести к путанице или озабоченности для пользователей. Для суммируемых столбцов рекомендуется создавать меры, которые возвращают BLANK в некоторых условиях вместо CLS (если это возможно).

Поддержка записи модели с конечной точкой XMLA

Семантические модели Direct Lake поддерживают операции записи с конечной точкой XMLA с помощью таких средств, как SSMS (19.1 или более поздней версии), а также средства сообщества с открытым кодом.

Совет

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

Перед выполнением операций записи опция чтения-записи XMLA должна быть включена для возможности. Дополнительные сведения см. в разделе Включение режима чтения-записи XMLA.

Операции записи модели с поддержкой конечной точки XMLA:

  • Настройка, объединение, скрипты, отладка и тестирование метаданных модели Direct Lake.
  • Управление версиями, непрерывная интеграция и непрерывное развертывание (CI/CD) с Azure DevOps и GitHub. Дополнительные сведения см. в разделе Управление жизненным циклом содержимого.
  • Задачи автоматизации, такие как обновление семантической модели и применение изменений в семантических моделях Direct Lake с помощью PowerShell и REST API.

При изменении семантической модели с помощью XMLA необходимо обновить ChangedProperties и PBI_RemovedChildren коллекцию измененного объекта, чтобы включить любые измененные или удаленные свойства. Если вы не выполняете это обновление, средства моделирования Power BI могут перезаписать любые изменения при следующей синхронизации схемы с Lakehouse.

Узнайте больше о тегах происхождения объектов семантической модели в статье «Теги происхождения для семантических моделей Power BI».

Важный

Таблицы Direct Lake, созданные с помощью приложений XMLA, изначально будут находиться в непроцессованном состоянии, пока приложение не отправит команду обновления. Запросы, включающие необработанные таблицы, всегда возвращаются в режим DirectQuery. Поэтому при создании новой семантической модели обязательно обновите модель для обработки таблиц.

Более подробную информацию см. в подключении семантической модели к конечной точке XMLA.

Метаданные модели Direct Lake

При подключении к семантической модели Direct Lake с конечной точкой XMLA метаданные выглядят как любые другие модели. Однако модели Direct Lake показывают следующие различия:

  • Свойство compatibilityLevel объекта базы данных равно 1604 (или выше).
  • Для свойства режима секций Direct Lake задано значение directLake.
  • Секции Direct Lake используют общие выражения для определения источников данных. Выражение указывает на конечную точку аналитики SQL озера или хранилища. Direct Lake использует конечную точку аналитики SQL для обнаружения схемы и сведений о безопасности, но загружает данные непосредственно из OneLake (если он переключается обратно на режим DirectQuery по какой-либо причине).

Задачи после публикации

После публикации семантической модели Direct Lake необходимо выполнить некоторые задачи установки. Дополнительные сведения см. в статье Управление семантических моделей Direct Lake.

Неподдерживаемые функции

Следующие функции модели не поддерживаются семантической моделью Direct Lake:

  • Вычисляемые таблицы, ссылающиеся на таблицы или столбцы в режиме хранилища Direct Lake
  • Вычисляемые столбцы, ссылающиеся на таблицы или столбцы в режиме хранилища Direct Lake
  • Гибридные таблицы
  • Определяемые пользователем агрегации
  • Составные модели, поскольку таблицы режима хранения Direct Lake нельзя объединить с таблицами режима хранения DirectQuery или двух режимов хранения в одной модели. Однако вы можете использовать Power BI Desktop для создания динамического подключения к семантической модели Direct Lake, а затем расширить ее с помощью новых мер, а затем выбрать вариант, чтобы внести изменения в эту модель добавить новые таблицы (с помощью режима импорта, DirectQuery или двойного хранилища). Это действие создает подключение DirectQuery к семантической модели в режиме Direct Lake, поэтому таблицы отображаются как режим хранения DirectQuery, но этот режим хранения не указывает на резервный вариант DirectQuery. Только соединение между этой новой моделью и моделью Direct Lake является DirectQuery и запросы по-прежнему используют Direct Lake для получения данных из OneLake. Дополнительные сведения см. в статье Сборка составной модели на семантической модели.
  • Столбцы, связанные с конечными точками аналитики SQL, которые применяют динамическое маскирование данных.

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