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


Обзор Direct Lake

Direct Lake — это параметр режима хранения для таблиц в семантической модели Power BI, которая хранится в рабочей области Microsoft Fabric. Он оптимизирован для больших объемов данных, которые можно быстро загрузить в память из таблиц Delta , хранящихся в OneLake, — единое хранилище для всех аналитических данных. После загрузки в память семантическая модель обеспечивает высокопроизводительный интерактивный анализ.

схема показывает семантику Direct Lake и способ подключения к таблицам Delta в OneLake, как описано в предыдущих абзацах.

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

Однако Direct Lake отличается от режима импорта важным образом: операция обновления для семантической модели Direct Lake концептуально отличается от операции обновления для семантической модели импорта. Режим импорта реплицирует данные и создает всю кэшированную копию данных для семантической модели, в то время как обновление Direct Lake копирует только метаданные (известные как обрамления, описанные далее в этой статье), что может занять несколько секунд. Обновление Direct Lake — это операция с низкими затратами, которая анализирует метаданные последней версии таблиц Delta и обновляется с ссылкой на последние файлы в OneLake. В отличие от этого, при обновлении импорта создается копия данных, требующая много времени и потребляющая значительные ресурсы источника данных и вычислительных мощностей (память и ЦП). Direct Lake перемещает подготовку данных в OneLake и использует полный спектр технологий Fabric для подготовки данных, включая задания Spark, инструкции T-SQL DML, потоки данных, конвейеры и многое другое.

Режим direct Lake Storage предлагает следующие ключевые преимущества:

  • Как и в режиме импорта, запросы Direct Lake обрабатываются подсистемой VertiPaq и таким образом обеспечивают производительность запросов, сравнимую с режимом импорта без затрат на управление циклами обновления данных для загрузки всего тома данных.
  • Использует существующие инвестиции Fabric путем простой интеграции с большими озерами, складами и другими источниками Fabric с разностными таблицами. Например, Direct Lake является идеальным выбором для слоя золотой аналитики в архитектуре medallion lakehouse.
  • Максимизирует рентабельность инвестиций (ROI), так как проанализированные тома данных могут превышать максимальные ограничения памяти емкости, так как только данные, необходимые для ответа на запрос, загружаются в память.
  • Сводит к минимуму задержку данных, быстро и автоматически синхронизируя семантику модели с источниками, что делает новые данные доступными для бизнес-пользователей без расписаний обновления.

Когда следует использовать режим хранения Direct Lake?

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

Заметка

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

Кроме того, интеграция OneLake автоматически записывает данные таблиц в режиме импорта хранения в таблицы Delta в OneLake, без каких-либо усилий по миграции, что позволяет пользователям, использующим семантическую модель импорта, реализовать множество преимуществ Fabric, таких как интеграция с lakehouses через сочетания клавиш, запросы SQL, записные книжки и многое другое. Мы рекомендуем использовать этот вариант как быстрый способ получить преимущества Fabric без обязательного или немедленного изменения существующего хранилища данных и /или системы аналитики.

Direct Lake зависит от подготовки данных в хранилище данных. Подготовку данных можно выполнить с помощью различных инструментов, таких как задания Spark для озер данных Fabric, инструкции T-SQL DML для хранилищ данных Fabric, потоки данных, конвейеры и другие инструменты, которые помогают гарантировать выполнение логики подготовки данных на ранних этапах в архитектуре для максимального повышения возможности повторного использования. Тем не менее, если автор семантической модели не имеет возможности изменять исходный элемент, например, если у аналитика самообслуживания нет разрешений на запись в lakehouse, управляемом ИТ,то расширение модели с таблицами режима импорта хранилища может быть хорошим выбором, так как режим импорта поддерживает подготовку данных с помощью Power Query, который определяется как часть семантической модели.

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

Совет

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

Основные понятия и терминология

В этой статье предполагается знакомство со следующими понятиями:

  • Пользователи взаимодействуют с визуальными элементами в отчетах Power BI, которые создают запросы DAX к семантической модели.
  • Режим хранения: семантическая модель обрабатывает запросы DAX по-разному в зависимости от используемого режима хранения. Например:
    • Режимы импорта и хранения Direct Lake используют подсистему VertiPaq для обработки запросов DAX и возврата результатов в отчет Power BI и пользователя.
    • С другой стороны, DirectQuery преобразует запросы DAX в синтаксис запроса источника данных (обычно это форма SQL) и объединяет их в базовую базу данных. Процессоры запросов к исходной базе данных часто не предназначены для бизнес-аналитики, агрегированных запросов и, следовательно, приводят к снижению производительности и снижению интерактивности пользователей по сравнению с режимами импорта и Direct Lake.

Режим хранения — это свойство таблицы в семантической модели. Если семантическая модель включает таблицы с различными режимами хранения, она называется составной моделью. Дополнительные сведения о режимах хранения см. в режимах семантической модели в службе Power BI.

  • Режим Direct Lake может использовать два разных метода доступа:

    • Direct Lake в OneLake не зависит от конечных точек SQL и может использовать данные из любого источника данных Fabric с таблицами Delta. Direct Lake в OneLake не возвращается в режим DirectQuery.

    Заметка

    Direct Lake на OneLake в настоящее время находится в общедоступной предварительной версии.

    • Direct Lake на конечных точках SQL использует конечную точку SQL озера или склада данных Fabric для обнаружения таблиц Delta и проверки разрешений. Direct Lake на конечных точках SQL может вернуться в режим DirectQuery, если он не может загрузить данные непосредственно из таблицы Delta, например, когда источник данных является представлением в SQL или когда в хранилище используется безопасность на уровне строк на основе SQL (RLS). Direct Lake на конечных точках SQL общедоступен и полностью поддерживается в рабочей среде.

Сравнение режимов хранения

В следующей таблице сравнивается режим хранилища Direct Lake с режимами импорта и хранения DirectQuery.

Способность Direct Lake на OneLake Direct Lake на конечных точках SQL Импорт Прямой запрос
Лицензирование Только подписка на производительность Fabric (SKU) Только подписка на производительность Fabric (SKU) Любая лицензия Fabric или Power BI (включая бесплатные лицензии Microsoft Fabric) Любая лицензия Fabric или Power BI (включая бесплатные лицензии Microsoft Fabric)
Источник данных Таблицы любого источника данных Fabric, поддерживаемые таблицами Delta Только lakehouse-таблицы или складские таблицы (или представления) Любой соединитель Любой соединитель, поддерживающий режим DirectQuery
Подключение к представлениям конечных точек аналитики SQL Нет Да, но автоматически откатится к режиму DirectQuery Да Да
Составные модели Нет 1 Нет 1 Да, может сочетаться с таблицами в режиме DirectQuery или в режиме двойного хранения. Да. Может сочетаться с таблицами режима импорта или двойного хранения
Единый вход (SSO) Да Да Неприменимо Да
Вычисляемые таблицы Да, но вычисления не могут ссылаться на столбцы таблиц в режиме Direct Lake. Нет. Кроме групп вычислений, параметров what-ifи параметров поля, которые неявно создают вычисляемые таблицы. Да Нет. Вычисляемые таблицы используют режим хранения импорта, даже если они ссылаются на другие таблицы в режиме DirectQuery
Вычисляемые столбцы Да, но вычисления не могут ссылаться на столбцы таблиц в режиме Direct Lake. Нет Да Да
Гибридные таблицы Нет Нет Да Да
Разделы таблицы модели Нет. Однако секционирование можно выполнить на уровне таблицы Delta. Нет. Однако секционирование можно выполнить на уровне таблицы Delta. Да — либо создается автоматически путем добавочного обновления, либо создается вручную с помощью конечной точки XMLA Нет
Агрегации, определяемые пользователем Нет Нет Да. Поддерживаются таблицы агрегирования импорта в таблицах DirectQuery Да
Безопасность на уровне объекта аналитики SQL или безопасность на уровне столбцов Нет Да, но может привести к ошибкам при отклонении разрешения Да. Но необходимо дублировать разрешения с помощью безопасности на уровне объекта семантической модели Да. Но запросы могут привести к ошибкам при отказе разрешения
Безопасность уровня строк (RLS) в аналитической конечной точке SQL Нет Да. Но запросы вернутся в режим DirectQuery Да. Но необходимо дублировать разрешения с помощью семантической модели RLS Да
Безопасность уровня строк семантической модели (RLS) Да — однако настоятельно рекомендуется использовать облачное подключение с фиксированной идентификацией . Да — однако настоятельно рекомендуется использовать облачное подключение с фиксированной идентификацией . Да Да
Безопасность на уровне объекта семантической модели (OLS) Да Да Да Да
Большие тома данных без требования к обновлению Да Да Нет Да
Уменьшение задержки данных Да — при включении автоматического обновления или программном изменении структуры. Да, при включении автоматических обновлений или программного рефрейминга Нет Да
Power BI Embedded (встраиваемая платформа для бизнес-аналитики) Да 2 Да 2 Да Да

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

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

Принцип работы Direct Lake

Как правило, запросы, отправленные в семантическую модель Direct Lake, обрабатываются из кэша в памяти столбцов, источником которых являются таблицы Delta. Базовое хранилище для таблицы Delta — это один или несколько файлов Parquet в OneLake. Файлы Parquet упорядочивают данные по столбцам, а не строкам. Семантические модели загружают все столбцы из разностных таблиц в память, так как они требуются запросами.

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

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

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

Загрузка столбцов (перекодирование)

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

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

После понимания необходимых столбцов семантическая модель определяет, какие столбцы уже находятся в памяти. Если какие-либо столбцы, необходимые для запроса, не в памяти, семантическая модель загружает все данные для этих столбцов из OneLake. Загрузка данных столбцов обычно является быстрой операцией, однако она может зависеть от таких факторов, как кратность данных, хранящихся в столбцах.

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

Столбец остается в памяти до тех пор, пока не появится причина для его удаления (вытеснения) из памяти. Причины удаления столбцов:

  • Модель или таблица была обновлена после обновления таблицы Delta в источнике (см. структурирование в следующем разделе).
  • В течение некоторого времени запрос не использовал столбец.
  • Другие причины управления памятью, включая давление на память в емкости из-за других параллельных операций.

Ваш выбор SKU Fabric определяет максимальный объем доступной памяти для каждой семантической модели Direct Lake в рамках емкости. Дополнительные сведения об ограничениях защиты ресурсов и максимально допустимых ограничениях памяти см. в разделе Ограничения на емкость Fabric и их пределы далее в этой статье.

Обрамление

Framing предоставляет владельцам моделей моментальный контроль над тем, какие данные загружаются в семантическую модель. Фреймирование — это операция Direct Lake, активируется обновлением семантической модели, и в большинстве случаев требуется всего несколько секунд. Это связано с низкой стоимостью операции, в которой семантическая модель анализирует метаданные последней версии таблиц Delta Lake и обновляется, чтобы ссылаться на последние файлы Parquet в OneLake.

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

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

На следующей схеме показано, как работают операции фреймирования Direct Lake.

Диаграмма показывает, как работают операции фреймирования Direct Lake.

На схеме показаны следующие процессы и функции.

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

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

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

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

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

Совет

Вы можете настроить автоматическое обновление страниц в отчетах Power BI. Это функция, которая автоматически обновляет определенную страницу отчета, обеспечивая подключение отчета к семантической модели Direct Lake (или другим типам семантической модели).

Резервный вариант DirectQuery

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

При резервном режиме DirectQuery запрос перестает использовать режим Direct Lake. Запрос не может использовать режим Direct Lake, если семантическая модель запрашивает представление в конечной точке аналитики SQL или таблицу в конечной точке аналитики SQL, которая обеспечивает безопасность на уровне строк (RLS). Кроме того, запрос не может использовать режим Direct Lake, если таблица Delta превышает пределы емкости.

Важный

Если это возможно, вы всегда должны разработать решение (или размер емкости), чтобы избежать резервного использования DirectQuery. Это связано с тем, что это может привести к снижению производительности запросов.

Вы можете управлять резервным вариантом семантических моделей Direct Lake, задав его свойство DirectLakeBehavior. Этот параметр применяется только к Direct Lake в конечных точках SQL. Direct Lake в OneLake не поддерживает резервный вариант DirectQuery. Дополнительные сведения см. в разделе Установите свойство поведения Direct Lake.

Разрешения на безопасность и доступ к данным

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

Разрешения элементов Fabric

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

Важно знать, что Direct Lake в OneLake и Direct Lake в конечных точках SQL выполняют проверки разрешений по-разному.

  • Для доступа к таблицам Delta на Direct Lake в OneLake требуются разрешения Read и ReadAll на lakehouse/warehouse.
  • Direct Lake в конечных точках SQL требует разрешений на чтение и чтение данных в lakehouse или хранилище для доступа к данным из конечной точки аналитики SQL.

Заметка

Для Direct Lake в OneLake требуется, чтобы пользователи имели доступ для чтения таблиц Delta в OneLake, а не к конечной точке SQL. Это обеспечивает централизованную структуру безопасности, в которой OneLake является одним источником управления доступом.

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

Разрешения семантической модели

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

Требования к разрешениям

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

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

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

Если семантическая модель использует Direct Lake в OneLake, а облачное подключение использует единый вход, предоставьте по крайней мере разрешения Read и ReadAll для таблиц Delta в OneLake.
Отчеты не должны принадлежать той же рабочей области, что и семантическая модель. Для получения дополнительной информации, см. статью Стратегия для потребителей только для чтения.
Пользователи могут создавать отчеты Предоставьте разрешение на сборку для семантической модели.

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

Если семантическая модель использует Direct Lake в OneLake и облачное подключение использует единый вход, предоставьте по крайней мере разрешения Read и ReadAll для таблиц Delta в OneLake.
Дополнительные сведения см. в статье Стратегия для создателей содержимого.
Пользователи могут просматривать отчеты, но отклоняются запросы к lakehouse, конечной точке аналитики SQL или таблицам Delta в OneLake Предоставьте разрешение на чтение отчетов и разрешение на чтение для семантической модели.

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

Важный

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

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

Требования к емкости сети Fabric

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

Важный

Первый столбец в следующей таблице также содержит подписки на емкость Power BI Premium (P SKU). Корпорация Майкрософт объединяет варианты приобретения и прекращает выпуск SKU Power BI Premium по емкости. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (F SKU).

Для получения дополнительной информации см. важное обновление для лицензирования Power BI Premium и Power BI Premium.

SKU ткани Файлы в формате Parquet для каждой таблицы Группы строк в таблице Строки в таблице (миллионы) Максимальный размер модели на диске или в OneLake (ГБ) Максимальный объем памяти (ГБ) 1
F2 1 000 1 000 300 10 3
F4 1 000 1 000 300 10 3
F8 1 000 1 000 300 10 3
F16 1 000 1 000 300 20 5
F32 1 000 1 000 300 40 10
F64/FT1/P1 5 000 5 000 1,500 Неограниченный 25
F128/P2 5 000 5 000 3,000 Неограниченный 50
F256/P3 5 000 5 000 6000 Неограниченный 100
F512/P4 10 000 10 000 12 000 Неограниченный 200
F1024/P5 10 000 10 000 24,000 Неограниченный 400
F2048 10 000 10 000 24,000 Неограниченный 400

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

При превышении размера модели Max на диске или в OneLake все запросы к семантической модели автоматически переключаются в режим DirectQuery. Все остальные ограждения, представленные в таблице, оценены для каждого запроса. Поэтому важно оптимизировать таблицы Delta и семантическую модель Direct Lake, чтобы избежать необходимости перехода на более высокий SKU Fabric.

Кроме того, единица емкости и Максимальный объем памяти для каждого запроса применяться к семантических моделях Direct Lake. Дополнительные сведения см. в разделе Емкости и номера SKU.

Рекомендации и ограничения

Семантические модели Direct Lake представляют некоторые рекомендации и ограничения.

Заметка

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

Соображение / ограничение Прямой доступ к OneLake Direct Lake в конечных точках SQL
Когда конечная точка аналитики SQL обеспечивает безопасность на уровне строк, запросы DAX обрабатываются по-разному в зависимости от типа используемого режима Direct Lake.

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

В этом случае на SQL-конечных точках Direct Lake переключится на DirectQuery.

Не поддерживается создание Direct Lake в таблице OneLake на основе нематериализованного представления SQL. Вместо этого можно использовать материализованное представление lakehouse, так как создаются таблицы Delta. Кроме того, используйте другой режим хранения, например import или DirectLake для таблиц на основе нематериализованных представлений SQL.
Неприменимо Да, если резервный вариант не отключен, в этом случае запросы завершаются ошибкой.
Составное моделирование в настоящее время не поддерживается, что означает, что таблицы семантической модели Direct Lake нельзя смешать с таблицами в других режимах хранения, таких как Import, DirectQuery или Dual (за исключением особых случаев, включая группы вычислений, параметры what-if и параметры поля). Не поддерживается Не поддерживается
Вычисляемые столбцы и вычисляемые таблицы, ссылающиеся на столбцы или таблицы в режиме хранилища Direct Lake, не поддерживаются. Группы вычислений, параметров "что-если"и параметров поля, которые неявно создают рассчитанные таблицы, и рассчитанные таблицы, не ссылающиеся на столбцы или таблицы Direct Lake, поддерживаются. Не поддерживается Не поддерживается
Таблицы режима хранения Direct Lake не поддерживают сложные типы столбцов таблиц Delta. Двоичные и семантические типы GUID также не поддерживаются. Эти типы данных необходимо преобразовать в строки или другие поддерживаемые типы данных. Не поддерживается Не поддерживается
Для сопоставления связей таблиц требуются типы данных связанных столбцов. Да Да
Односторонние столбцы связей должны содержать уникальные значения. Запросы завершаются ошибкой, если в одном столбце обнаружены повторяющиеся значения. Да Да
автоматическая аналитика данных и времени в Power BI Desktop не поддерживается. Пометка собственной таблицы дат в качестве таблицы дат поддерживается. Да Да
Длина строковых значений столбцов ограничена 32 764 символами Юникода. Да Да
Нечисловые значения с плавающей запятой, такие как NaN (не число), не поддерживаются. Да Да
Публикация в Интернете из Power BI с помощью служебного принципала поддерживается только при использовании фиксированной идентичности семантической модели Direct Lake. Да Да
В веб-моделированиипроверка семантических моделей Direct Lake ограничена. Предполагается, что выборы пользователя правильны, и запросы не выдаются для проверки кардинальности или перекрёстных фильтров в связях, а также для выбранного столбца дат в отмеченной таблице дат. Да Да
На портале Fabric вкладка Direct Lake в журнале обновления содержит список сбоев обновления, связанных с Direct Lake. Операции обновления (фреймирования), завершившиеся успехом, обычно не перечислены, если только не изменяется состояние обновления, например, достижение успешного обновления после отсутствия предыдущего запуска или сбоя, или успешное обновление с предупреждением. Да Да
SKU вашей платформы Fabric определяет максимальную доступную память для емкости в семантической модели Direct Lake. При превышении лимита запросы к семантической модели могут выполняться медленнее из-за чрезмерного переключения страниц в данных модели. Да Да
Создание семантической модели Direct Lake в рабочей области, которая находится в другом регионе рабочей области источника данных, не поддерживается. Например, если Lakehouse находится в западной части США, вы можете создавать только семантические модели из этого Lakehouse в том же регионе. Обходным решением является создание Lakehouse в рабочей области другого региона и создание ссылок на таблицы перед формированием семантической модели. Чтобы узнать, в каком регионе вы находитесь, см. как определить ваш домашний регион в системе Fabric. Да Да
Для встраивания отчетов требуется токен встраивания V2. Да Не поддерживается
Direct Lake не поддерживает профили субъекта-службы для проверки подлинности. Не поддерживается Да
Семантические модели Direct Lake Power BI могут создаваться и запрашиваться субъектами-службами и членством в роли просмотра с субъектами-службами, но модели семантики Direct Lake по умолчанию в lakehouse или warehouse не поддерживают этот сценарий. Да
Ярлыки в лейкхаусе можно использовать в качестве источников данных для таблиц семантической модели. Не поддерживается во время общедоступной предварительной версии Да