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

Управление семантических моделей Direct Lake

  • Статья

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

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

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

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

Настройка облачного подключения

Семантическая модель Direct Lake использует облачное подключение для подключения к конечной точке аналитики SQL. Он обеспечивает доступ к исходным данным, то есть файлам Parquet в OneLake (режиме direct Lake storage, который включает загрузку данных столбцов в память) или конечную точку аналитики SQL (когда запросы возвращаются в режим DirectQuery).

Облачное подключение по умолчанию

При создании семантической модели Direct Lake используется облачное подключение по умолчанию. Он использует единый вход (SSO), что означает, что удостоверение, запрашивающее семантику модели (часто пользователя отчета), используется для запроса данных конечной точки аналитики SQL.

Совместное подключение к облаку

При необходимости можно создать совместное облачное подключение (SCC), чтобы подключения к источнику данных можно было сделать с фиксированным удостоверением. Это может помочь корпоративным клиентам защитить свои корпоративные хранилища данных. ИТ-отдел может управлять учетными данными, создавать scCs и совместно использовать их с предполагаемыми создателями для централизованного управления доступом.

Сведения о настройке фиксированного удостоверения см. в разделе "Указание фиксированного удостоверения" для семантической модели Direct Lake.

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

Фиксированное удостоверение может пройти проверку подлинности с помощью OAuth 2.0 или субъекта-службы.

Примечание.

Поддерживается только проверка подлинности Microsoft Entra. Поэтому обычная проверка подлинности не поддерживается для семантических моделей Direct Lake.

OAuth 2.0

При использовании OAuth 2.0 можно пройти проверку подлинности с помощью учетной записи пользователя Microsoft Entra. Учетная запись пользователя должна иметь разрешение на запрос к таблицам и представлениям конечных точек аналитики SQL и метаданным схемы.

Использование определенной учетной записи пользователя не рекомендуется. Это связано с тем, что запросы семантической модели завершаются ошибкой, если изменение пароля или учетная запись пользователя удаляется (например, когда сотрудник покидает организацию).

Субъект-служба

Проверка подлинности с помощью субъекта-службы рекомендуется, так как она не зависит от конкретной учетной записи пользователя. Субъект безопасности должен иметь разрешение на запрос к таблицам и представлениям конечной точки аналитики SQL и метаданным схемы.

Для обеспечения непрерывности учетные данные субъекта-службы могут управляться сменой секретов и сертификатов.

Примечание.

Параметры клиента Fabric должны разрешать субъекты-службы, а субъект-служба должен принадлежать объявленной группе безопасности.

Единый вход

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

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

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

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

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

Управление членством в роли безопасности

Если семантическая модель Direct Lake обеспечивает безопасность на уровне строк (RLS), может потребоваться управлять участниками, назначенными ролям безопасности. Дополнительные сведения см. в статье "Управление безопасностью в модели".

Настройка разрешений элементов Fabric

Семантические модели Direct Lake соответствуют многоуровневой модели безопасности. Они выполняют проверки разрешений через конечную точку аналитики SQL, чтобы определить, имеет ли удостоверение, пытающееся получить доступ к данным, имеет необходимые разрешения на доступ к данным.

Необходимо предоставить пользователям разрешения, чтобы они могли использовать семантику Direct Lake или управлять ими. Короче говоря, пользователям отчетов требуется разрешение на чтение, а создатели отчетов нуждаются в разрешении на сборку. Разрешения семантической модели можно назначать напрямую или получать неявно с помощью ролей рабочей области. Чтобы управлять параметрами семантической модели (для обновления и других конфигураций), необходимо быть владельцем семантической модели.

В зависимости от настройки облачного подключения и того, должны ли пользователи запрашивать lakehouse или конечную точку аналитики ХРАНИЛИЩА SQL, вам может потребоваться предоставить другие разрешения (описанные в таблице в этом разделе).

Примечание.

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

Рассмотрим следующие сценарии и требования к разрешениям.

Сценарий Необходимые разрешения Комментарии
Пользователи могут просматривать отчеты • Предоставьте разрешение на чтение отчетов и разрешение на чтение для семантической модели.
• Если подключение к облаку использует единый вход, предоставьте по крайней мере разрешение на чтение для озера или хранилища.		 Отчеты не должны принадлежать той же рабочей области, что и семантическая модель. Дополнительные сведения см. в статье "Стратегия" для потребителей только для чтения.
Пользователи могут создавать отчеты • Предоставьте разрешение на сборку для семантической модели.
• Если подключение к облаку использует единый вход, предоставьте по крайней мере разрешение на чтение для озера или хранилища.		 Дополнительные сведения см. в статье "Стратегия для создателей контента".
Пользователи могут запрашивать семантику модели, но запрещают запрашивать конечную точку lakehouse или аналитики SQL. • Не предоставляйте никаких разрешений для озера или склада. Подходит только в том случае, если облачное подключение использует фиксированное удостоверение.
Пользователи могут запрашивать семантические модели и конечную точку аналитики SQL, но отклоняют запросы к lakehouse • Предоставьте разрешения на чтение и чтение данных для озера или хранилища. Важно. Запросы, отправленные в конечную точку аналитики SQL, будут обходить разрешения доступа к данным, применяемые семантической моделью.
Управление семантической моделью, включая параметры обновления • Требуется владение семантической моделью. Дополнительные сведения см. в разделе "Семантическая модель владения".

Внимание

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

Дополнительные сведения см. в разделе "Разрешения семантической модели".

Обновление семантических моделей Direct Lake

Обновление семантической модели Direct Lake приводит к операции обрамления . Можно активировать операцию обновления:

Автоматические обновления

Существует параметр уровня семантической модели с именем Keep your Direct Lake data to date , который выполняет автоматическое обновление таблиц Direct Lake. По умолчанию он включен. Это гарантирует, что изменения данных в OneLake автоматически отражаются в семантической модели Direct Lake. Параметр доступен на портале Fabric в разделе "Обновить " параметров семантической модели.

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

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

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

Примечание.

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

Тепло кэша

Операция обновления семантической модели Direct Lake может вытеснить все столбцы резидентов из памяти. Это означает, что первые запросы после обновления семантической модели Direct Lake могут столкнуться с некоторой задержкой при загрузке столбцов в память. Задержки могут быть заметны только в том случае, если у вас очень большие объемы данных.

Чтобы избежать таких задержек, рассмотрите возможность потепления кэша путем программной отправки запроса в семантику модели. Удобный способ отправки запроса — использовать семантику ссылки. Эта операция должна выполняться сразу после завершения операции обновления.

Внимание

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

Установка свойства поведения Direct Lake

Вы можете управлять резервным вариантом семантических моделей Direct Lake, задав его DirectLakeBehavior свойство. Для него можно задать следующее:

  • Автоматические запросы (по умолчанию) возвращаются в режим DirectQuery, если необходимые данные не могут быть эффективно загружены в память.
  • DirectLakeOnly: все запросы используют только режим хранения Direct Lake. Отключается режим DirectQuery. Если данные не могут быть загружены в память, возвращается ошибка.
  • DirectQueryOnly: все запросы используют только режим DirectQuery. Используйте этот параметр для тестирования резервной производительности, где, например, можно наблюдать производительность запросов в подключенных отчетах.

Свойство можно задать в интерфейсе веб-моделирования или с помощью табличной объектной модели (TOM) или языка скриптов табличных моделей (TMSL).

Совет

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

Мониторинг семантических моделей Direct Lake

Вы можете отслеживать семантику Direct Lake, чтобы определить производительность визуальных запросов DAX отчета или определить, когда он возвращается в режим DirectQuery.

Вы можете использовать Анализатор производительности, SQL Server Profiler, Azure Log Analytics или средство с открытым кодом, например DAX Studio.

Анализатор производительности

Вы можете использовать Анализатор производительности в Power BI Desktop для записи времени обработки, необходимого для обновления элементов отчета, инициированных в результате любого взаимодействия с пользователем, которое приводит к выполнению запроса. Если результаты мониторинга показывают метрику прямого запроса , это означает, что запросы DAX были обработаны в режиме DirectQuery. В отсутствие этой метрики запросы DAX были обработаны в режиме Direct Lake.

Дополнительные сведения см. в статье "Анализ с помощью Анализатор производительности".

Профилировщик SQL Server

Вы можете использовать SQL Server Profiler для получения сведений о производительности запросов путем трассировки событий запроса. Он установлен с SQL Server Management Studio (SSMS). Перед началом работы убедитесь, что установлена последняя версия SSMS.

Дополнительные сведения см. в статье "Анализ с помощью SQL Server Profiler".

Внимание

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

Azure Log Analytics

Azure Log Analytics можно использовать для сбора, анализа и действия с данными телеметрии, связанных с семантической моделью Direct Lake. Это служба в Azure Monitor, которую Power BI использует для сохранения журналов действий.

Дополнительные сведения см. в статье Об использовании Azure Log Analytics в Power BI.

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