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

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

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

Вы можете создать семантику Direct Lake в Power BI Desktop или из многих элементов Fabric в браузере. Например, в открытом Lakehouse можно выбрать новую семантику для создания новой семантической модели в режиме Direct Lake Storage.

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

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

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

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

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

Импортируемые таблицы можно добавить в семантические модели, используя Direct Lake для таблиц OneLake. Вычисляемые таблицы можно добавлять, если они не ссылаются на таблицу Direct Lake. Можно добавить группы вычислений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе "Подключение семантической модели" к конечной точке 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
• Изменение таблиц для семантических моделей Direct Lake
• Интеграция OneLake для семантических моделей