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

Разработка семантических моделей 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, чтобы ограничить пользователей, которые могут получить доступ к столбцу SalaryEmployee из таблицы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

  • Если разные пользователи должны быть ограничены подмножествами данных, при необходимости применяйте 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.

Внимание

Таблицы 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, которые применяют динамическое маскирование данных.

Связанный контент