Прямое озеро

Режим Direct Lake — это возможность семантической модели для анализа очень больших объемов данных в Power BI. Direct Lake основан на загрузке файлов с форматированием parquet непосредственно из озера данных без необходимости запрашивать конечную точку lakehouse или хранилища, а также не импортировать или дублировать данные в модель Power BI. Direct Lake — это быстрый путь для загрузки данных из озера прямо в подсистему Power BI, готовую к анализу. На следующей схеме показано, как классические режимы импорта и DirectQuery сравниваются с режимом Direct Lake.

Схема функций Direct Lake.

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

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

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

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

Необходимые компоненты

Direct Lake поддерживается только в номерах SKU Microsoft Premium (P) и SKU Microsoft Fabric (F).

Внимание

Для новых клиентов Direct Lake поддерживается только в номерах SKU Microsoft Fabric (F). Существующие клиенты могут продолжать использовать Direct Lake с номерами SKU уровня "Премиум" (P), но рекомендуется перейти на номер SKU емкости Fabric. Дополнительные сведения о лицензировании Power BI Premium см. в объявлении о лицензировании Power BI Premium.

Гибридное решение "хранилище и озеро данных"

Перед использованием Direct Lake необходимо подготовить lakehouse (или склад) с одной или несколькими таблицами Delta в рабочей области, размещенной в поддерживаемой емкости Microsoft Fabric. Lakehouse является обязательным, так как он предоставляет место хранения для файлов в формате parquet в OneLake. Lakehouse также предоставляет точку доступа для запуска функции веб-моделирования для создания модели Direct Lake.

Чтобы узнать, как подготовить lakehouse, создать таблицу Delta в lakehouse и создать базовую модель для lakehouse, см. статью "Создание озера для Direct Lake".

Конечная точка SQL

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

Хранилище данных

В качестве альтернативы lakehouse с конечной точкой SQL можно также подготовить хранилище и добавить таблицы с помощью инструкций SQL или конвейеров данных. Процедура подготовки автономного хранилища данных почти идентична процедуре для lakehouse.

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

Модели Direct Lake поддерживают операции записи через конечную точку XMLA с помощью таких средств, как SQL Server Management Studio (19.1 и выше), а также последние версии внешних средств бизнес-аналитики, таких как табличный редактор и студия DAX. Операции записи модели с помощью поддержки конечной точки XMLA:

  • Настройка, объединение, скрипты, отладка и тестирование метаданных модели Direct Lake.

  • Управление версиями, непрерывная интеграция и непрерывное развертывание (CI/CD) с Azure DevOps и GitHub.

  • Задачи автоматизации, такие как обновление и применение изменений в моделях Direct Lake с помощью PowerShell и REST API.

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

Включение функции чтения и записи XMLA

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

Для емкостей пробной версии Fabric пробный пользователь имеет права администратора, необходимые для включения чтения и записи XMLA.

  1. На портале Администратор выберите параметры емкости.

  2. Щелкните вкладку "Пробная версия ".

  3. Выберите емкость с пробной версией и именем пользователя в имени емкости.

  4. Разверните рабочие нагрузки Power BI, а затем в параметре конечной точки XMLA выберите "Чтение записи".

    Снимок экрана: параметр чтения и записи конечной точки XMLA для пробной емкости Fabric.

Помните, что параметр конечной точки XMLA применяется ко всем рабочим областям и моделям, назначенным емкости.

Метаданные модели Direct Lake

При подключении к автономной модели Direct Lake через конечную точку XMLA метаданные выглядят как любая другая модель. Однако модели Direct Lake показывают следующие различия:

  • Свойство compatibilityLevel объекта базы данных равно 1604 или выше.

  • Для Mode свойства секций Direct Lake задано directLakeзначение .

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

Ниже приведен пример ЗАПРОСА XMLA в SSMS:

Снимок экрана: запрос XMLA в SSMS.

Дополнительные сведения о поддержке средств через конечную точку XMLA см. в статье "Подключение семантической модели" к конечной точке XMLA.

Резерв

Семантические модели Power BI в режиме Direct Lake считывают таблицы Delta непосредственно из OneLake. Однако если запрос DAX в модели Direct Lake превышает ограничения для номера SKU или использует функции, которые не поддерживают режим Direct Lake, например представления SQL в хранилище, запрос может вернуться в режим DirectQuery. В режиме DirectQuery запросы используют SQL для получения результатов из конечной точки SQL озера или хранилища, что может повлиять на производительность запросов. Вы можете отключить резервный режим DirectQuery, если вы хотите обрабатывать запросы DAX только в чистом режиме Direct Lake. Отключение резервного копирования рекомендуется, если вам не нужен резервный возврат к DirectQuery. Это также может быть полезно при анализе обработки запросов для модели Direct Lake, чтобы определить, если и как часто возникают резервные копии. Дополнительные сведения о режиме DirectQuery см. в разделе "Режимы семантической модели" в Power BI.

Guardrails определяет ограничения ресурсов для режима Direct Lake, за пределами которого требуется резервный доступ к режиму DirectQuery для обработки запросов DAX. Дополнительные сведения о том, как определить количество файлов parquet и групп строк для таблицы Delta, см. в справочнике по свойствам таблицы Delta.

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

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

Номера SKU Fabric Файлы Parquet на таблицу Группы строк на таблицу Строки на таблицу (миллионы) Максимальный размер модели на диске или OneLake1 (ГБ) Максимальная память (ГБ)
F2 1000 1000 300 10 3
F4 1000 1000 300 10 3
F8 1000 1000 300 10 3
F16 1000 1000 300 20 5
F32 1000 1000 300 40 10
F64/FT1/P1 5,000 5,000 1500 Не ограничено 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 . Если превышено, максимальный размер модели на диске или Onelake приведет ко всем запросам к модели вернуться к DirectQuery, в отличие от других охранников, которые вычисляются на один запрос.

В зависимости от SKU Fabric дополнительные единицы емкости и максимальное количество памяти для каждого запроса также применяются к моделям Direct Lake. Дополнительные сведения см. в разделе "Емкости и номера SKU".

Резервное поведение

Модели Direct Lake включают свойство DirectLakeBehavior , которое имеет три варианта:

Автоматически — (по умолчанию) Указывает запросы, возвращаемые в режим DirectQuery , если данные не могут быть эффективно загружены в память.

DirectLakeOnly — указывает, что все запросы используют только режим Direct Lake. Резервный доступ к режиму DirectQuery отключен. Если данные не могут быть загружены в память, возвращается ошибка. Используйте этот параметр, чтобы определить, не загружаются ли запросы DAX в память, принудив возвращать ошибку.

DirectQueryOnly — указывает, что все запросы используют только режим DirectQuery. Используйте этот параметр для тестирования резервной производительности.

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

В следующем примере указываются только все запросы, использующие режим Direct Lake:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Анализ обработки запросов

Чтобы определить, обеспечивают ли запросы DAX визуального элемента отчета к источнику данных, обеспечивая оптимальную производительность с помощью режима Direct Lake или возвращаясь в режим DirectQuery, можно использовать анализатор производительности в Power BI Desktop, SQL Server Profiler или другие сторонние средства для анализа запросов. Дополнительные сведения см. в статье "Анализ обработки запросов для моделей Direct Lake".

Refresh

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

Снимок экрана: параметр обновления Direct Lake в параметрах модели.

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

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

Безопасность доступа к данным уровня

Модели Direct Lake, созданные на вершине озерных домов и складов, соответствуют многоуровневой модели безопасности, поддерживаемой озерами и хранилищами, выполняя разрешения проверка через конечную точку T-SQL, чтобы определить, имеет ли удостоверение, пытающееся получить доступ к данным, имеет необходимые разрешения на доступ к данным. По умолчанию модели Direct Lake используют единый вход ( единый вход), поэтому действующие разрешения интерактивного пользователя определяют, разрешен ли пользователю или запрещен доступ к данным. Если модель Direct Lake настроена для использования фиксированного удостоверения, эффективное разрешение фиксированного удостоверения определяет, могут ли пользователи, взаимодействующие с семантической моделью, получить доступ к данным. Конечная точка T-SQL возвращает разрешенную или запрещенную модель Direct Lake на основе сочетания разрешений OneLake и SQL.

Например, администратор хранилища может предоставить пользователю разрешения SELECT для таблицы, чтобы пользователь смог прочитать из этой таблицы, даже если у пользователя нет разрешений на безопасность OneLake. Пользователь был авторизован на уровне lakehouse или склада. И наоборот, администратор хранилища также может ЗАПРЕТить пользователю доступ на чтение к таблице. Пользователь не сможет прочитать из этой таблицы, даже если у пользователя есть разрешения на чтение безопасности OneLake. Инструкция DENY переопределяет все предоставленные разрешения oneLake или SQL. Ознакомьтесь со следующей таблицей, чтобы получить действующие разрешения, которые пользователь может предоставить любому сочетанию разрешений oneLake и SQL.

Разрешения безопасности OneLake Разрешения SQL Действующие разрешения
Разрешить нет Разрешить
нет Разрешить Разрешить
Разрешить Запрет Запрет
нет Запрет Запрет

Известные проблемы и ограничения

  • По сути, только таблицы в семантической модели, производные от таблиц в Lakehouse или Warehouse, поддерживают режим Direct Lake. Хотя таблицы в модели могут быть производными от представлений SQL в Lakehouse или Warehouse, запросы, использующие эти таблицы, возвращаются в режим DirectQuery.

  • Таблицы семантической модели Direct Lake могут быть производными только от таблиц и представлений из одного Lakehouse или Хранилища.

  • Таблицы Direct Lake в настоящее время не могут быть смешанными с другими типами таблиц, такими как Import, DirectQuery или Dual, в той же модели. Составные модели в настоящее время не поддерживаются.

  • Связи DateTime не поддерживаются в моделях Direct Lake.

  • Вычисляемые столбцы и вычисляемые таблицы не поддерживаются.

  • Некоторые типы данных могут не поддерживаться, например десятичные и денежные типы с высокой точностью.

  • Таблицы Direct Lake не поддерживают сложные типы столбцов таблиц Delta. Двоичные и семантические типы Guid также не поддерживаются. Эти типы данных необходимо преобразовать в строки или другие поддерживаемые типы данных.

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

  • Длина строковых значений столбцов ограничена 32 764 символами Юникода.

  • Значение с плавающей запятой "NaN" (не число) не поддерживается в моделях Direct Lake.

  • Внедренные сценарии, использующие внедренные сущности, пока не поддерживаются.

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

  • Вкладка Direct Lake в журнале обновления содержит только ошибки обновления, связанные с Direct Lake. Успешные обновления в настоящее время опущены.

Начать

Лучший способ приступить к работе с решением Direct Lake в организации — создать Lakehouse, создать в нем таблицу Delta, а затем создать базовую семантику для lakehouse в рабочей области Microsoft Fabric. Дополнительные сведения см. в статье "Создание озера для Direct Lake".