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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

Чтобы настроить фиксированное удостоверение, см. статью Указание фиксированного удостоверения для семантической модели Direct Lake.

Аутентификация

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

Заметка

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

OAuth 2.0

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

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

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

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

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

Заметка

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

Единый вход

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

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

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

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

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

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

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

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

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

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

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

Заметка

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

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

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

Важный

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

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

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

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

  • Вручную путем выполнения обновления по запросу на портале Fabric или путем выполнения команды "Язык сценариев табличных моделей" (TMSL) обновить из скрипта в SQL Server Management Studio (SSMS) или с помощью стороннего средства, которое подключается через конечную точку XMLA.
  • Автоматически с помощью настройки расписания обновления на портале Fabric.
  • Информация обновляется автоматически при обнаружении изменений в базовых таблицах Delta. Более подробно см. в разделе Автоматическое обновление (описано далее).
  • Программно путем запуска обновления с помощью REST API Power BI или TOM. Вы можете активировать программное обновление в качестве последнего шага процесса извлечения, преобразования и загрузки (ETL).

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

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

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

Рекомендуем оставить настройку активной, особенно если у вас есть небольшая или средняя семантическая модель. Особенно полезно, когда у вас есть требования к отчетам с низкой задержкой, и 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 Profiler

Вы можете использовать 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.

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