Обзор Direct Lake
Direct Lake — это параметр режима хранения для таблиц в семантической модели Power BI, которая хранится в рабочей области Microsoft Fabric. Он оптимизирован для больших объемов данных, которые можно быстро загрузить в память из таблиц Delta, которые хранят данные в файлах Parquet в OneLake — единое хранилище для всех аналитических данных. После загрузки в память семантическая модель обеспечивает высокую производительность запросов. Direct Lake устраняет медленные и дорогостоящие потребности в импорте данных в модель.
Режим хранения Direct Lake можно использовать для подключения к таблицам или представлениям одного хранилища озера Fabric или Fabric. Для обоих элементов Fabric и семантических моделей Direct Lake требуется лицензия на емкость Fabric.
В некотором смысле семантическая модель Direct Lake похожа на семантику импорта. Это связано с тем, что данные модели загружаются в память подсистемой VertiPaq для быстрой производительности запросов (за исключением случаев резервного восстановления DirectQuery, который описан далее в этой статье).
Однако семантическая модель Direct Lake отличается от семантической модели импорта важным образом. Это связано с тем, что операция обновления для семантической модели Direct Lake концептуально отличается от операции обновления для семантической модели импорта. Для семантической модели Direct Lake обновление включает операцию обрамления (описанную далее в этой статье), которая может занять несколько секунд. Это низкая стоимость операции, в которой семантическая модель анализирует метаданные последней версии таблиц Delta и обновляется для ссылки на последние файлы в OneLake. В отличие от этого, для семантической модели импорта обновление создает копию данных, которая может занять значительное время и потреблять значительные ресурсы источника данных и емкости (память и ЦП).
Примечание.
Добавочное обновление для семантической модели импорта может помочь сократить время обновления и использование ресурсов емкости.
Когда следует использовать режим хранения Direct Lake?
Основной вариант использования режима direct Lake storage обычно предназначен для проектов аналитики на основе ИТ-специалистов, использующих архитектуры, ориентированные на озеро. В этом сценарии у вас есть большие объемы данных в OneLake. Быстрая загрузка этих данных в память, частые и быстрые операции обновления, эффективное использование ресурсов емкости и высокая производительность запросов являются важными для этого варианта использования.
Примечание.
Импорт и семантические модели DirectQuery по-прежнему актуальны в Fabric, и они являются правильным выбором семантической модели для некоторых сценариев. Например, режим хранения импорта часто подходит для аналитика самообслуживания, который нуждается в свободе и гибкости, чтобы быстро действовать, и без зависимости от ИТ-специалистов для добавления новых элементов данных.
Кроме того, интеграция OneLake автоматически записывает данные для таблиц в режиме хранения импорта в разностные таблицы в OneLake без каких-либо усилий по миграции. С помощью этого параметра можно реализовать множество преимуществ Fabric, доступных для импорта пользователей семантической модели, таких как интеграция с lakehouses с помощью сочетаний клавиш, запросов SQL, записных книжек и т. д. Мы рекомендуем использовать этот вариант как быстрый способ получения преимуществ Fabric без обязательной или немедленной повторной разработки существующего хранилища данных и /или системы аналитики.
Режим хранения Direct Lake также подходит для минимизации задержки данных, чтобы быстро сделать данные доступными для бизнес-пользователей. Если разностные таблицы изменяются периодически (и предполагается, что вы уже сделали подготовку данных в озере данных), вы можете зависеть от автоматических обновлений для повторного кадра в ответ на эти изменения. В этом случае запросы, отправленные в семантику модели, возвращают последние данные. Эта возможность хорошо работает в партнерстве с функцией автоматического обновления страницы отчетов Power BI.
Помните, что Direct Lake зависит от подготовки данных в озере данных. Подготовка данных может выполняться с помощью различных средств, таких как задания Spark для фабрики lakehouses, инструкции T-SQL DML для хранилищ Fabric, потоков данных, конвейеров и других. Этот подход помогает обеспечить, чтобы логика подготовки данных выполнялась как можно ниже в архитектуре, чтобы обеспечить максимальную повторное использование. Однако если автор семантической модели не имеет возможности изменять исходный элемент, например, в случае с аналитиком самообслуживания, который, возможно, не имеет разрешений на запись в озерном доме, управляемом ИТ-специалистом, то режим хранения импорта может быть лучшим вариантом. Это связано с тем, что она поддерживает подготовку данных с помощью Power Query, которая определяется как часть семантической модели.
Не забудьте учитывать текущую лицензию на емкость Fabric и защиту емкости Fabric при рассмотрении режима хранения Direct Lake. Кроме того, следует учитывать рекомендации и ограничения, описанные далее в этой статье.
Совет
Мы рекомендуем создать прототип (или подтверждение концепции) для определения того, является ли семантическая модель Direct Lake правильным решением и снизить риск.
Принцип работы Direct Lake
Как правило, запросы, отправленные в семантику Direct Lake, обрабатываются из кэша в памяти столбцов, полученных из таблиц Delta. Базовое хранилище для таблицы Delta — это один или несколько файлов Parquet в OneLake. Файлы Parquet упорядочивают данные по столбцам, а не строкам. Семантические модели загружают все столбцы из разностных таблиц в память, так как они требуются запросами.
Семантическая модель Direct Lake также может использовать резервную версию DirectQuery, которая включает в себя простое переключение на режим DirectQuery. Резервный возврат DirectQuery извлекает данные непосредственно из конечной точки аналитики SQL озера или хранилища. Например, резервный вариант может произойти, если таблица Delta содержит больше строк данных, чем поддерживается емкостью Fabric (описано далее в этой статье). В этом случае операция DirectQuery отправляет запрос в конечную точку аналитики SQL. Резервные операции могут привести к снижению производительности запросов.
На следующей схеме показано, как работает Direct Lake с помощью сценария пользователя, который открывает отчет Power BI.
На схеме показаны следующие действия пользователя, процессы и функции.
| Позиция | Description |
|---|---|
|
OneLake — это озеро данных, которое хранит аналитические данные в формате Parquet. Этот формат файла оптимизирован для хранения данных для семантических моделей Direct Lake. |
|
Хранилище Озера Fabric или Fabric существует в рабочей области, которая находится в емкости Fabric. Lakehouse имеет конечную точку аналитики SQL, которая предоставляет интерфейс на основе SQL для запроса. Таблицы (или представления) предоставляют средства для запроса таблиц Delta в OneLake с помощью Transact-SQL (T-SQL). |
|
Семантическая модель Direct Lake существует в рабочей области Fabric. Он подключается к таблицам или представлениям в озерном доме или складе. |
|
Пользователь открывает отчет Power BI. |
|
Отчет Power BI отправляет запросы выражений анализа данных (DAX) в семантику Direct Lake. |
|
Когда это возможно (и необходимо), семантическая модель загружает столбцы в память непосредственно из файлов Parquet, хранящихся в OneLake. Запросы обеспечивают производительность в памяти, что очень быстро. |
|
Семантическая модель возвращает результаты запроса. |
|
Отчет Power BI отрисовывает визуальные элементы. |
|
В некоторых случаях, например, когда семантическая модель превышает пределы емкости, запросы семантической модели автоматически возвращаются в режим DirectQuery. В этом режиме запросы отправляются в конечную точку аналитики SQL озера или хранилища. |
|
Запросы DirectQuery, отправленные в конечную точку аналитики SQL, в свою очередь запрашивают таблицы Delta в OneLake. По этой причине производительность запросов может быть медленнее, чем запросы в памяти. |
В следующих разделах описаны основные понятия и функции Direct Lake, включая загрузку столбцов, кадрирование, автоматическое обновление и резервный резерв DirectQuery.
Загрузка столбцов (перекодирование)
Семантические модели Direct Lake загружают только данные из OneLake и когда столбцы запрашиваются в первый раз. Процесс загрузки данных по запросу из OneLake называется транскодированием.
Когда семантическая модель получает запрос DAX (или многомерные выражения— многомерные выражения), сначала определяет, какие столбцы необходимы для получения результата запроса. Необходимые столбцы включают все столбцы, которые непосредственно используются запросом, а также столбцы, необходимые для связей и мер. Как правило, количество столбцов, необходимых для создания результата запроса, значительно меньше числа столбцов, определенных в семантической модели.
Поняв, какие столбцы необходимы, семантическая модель определяет, какие столбцы уже находятся в памяти. Если какие-либо столбцы, необходимые для запроса, не в памяти, семантическая модель загружает все данные для этих столбцов из OneLake. Загрузка данных столбцов обычно является очень быстрой операцией, однако она может зависеть от таких факторов, как кратность данных, хранящихся в столбцах.
Затем столбцы, загруженные в память, находятся в памяти. Будущие запросы, включающие только резидентные столбцы, больше не должны загружаться в память.
Столбец остается резидентом до тех пор, пока не будет удалено (вытеснено) из памяти. Причины удаления столбцов:
- Модель или таблица обновлены (см . framing в следующем разделе).
- В течение некоторого времени не использовался столбец.
- Другие причины управления памятью, включая давление на память в емкости из-за других параллельных операций.
Ваш выбор SKU Fabric определяет максимальную доступную память для каждой семантической модели Direct Lake в емкости. Дополнительные сведения о ограничениях безопасности ресурсов и максимальных ограничениях памяти см. в разделе "Защита емкости Fabric" и ограничения далее в этой статье.
Обрамление
Фрейминг предоставляет владельцам моделей контроль над тем, какие данные загружаются в семантику модели. Обрамления — это операция Direct Lake, которая активируется обновлением семантической модели, и в большинстве случаев требуется всего несколько секунд. Это связано с низкой стоимостью операции, в которой семантическая модель анализирует метаданные последней версии таблиц Delta Lake и обновляется, чтобы ссылаться на последние файлы Parquet в OneLake.
При возникновении обрамления столбцы резидентов могут быть исключены из памяти, а точка во времени обновления становится новой базовой базой для всех будущих событий транскодирования. С этого момента запросы Direct Lake рассматривают только данные в таблицах Delta по состоянию на время последней операции обрамления. По этой причине таблицы Direct Lake запрашиваются для возврата данных на основе состояния таблицы Delta в точке последней операции обрамления. Это не обязательно последнее состояние таблиц Delta.
На следующей схеме показано, как работают операции с фреймированием Direct Lake.
На схеме показаны следующие процессы и функции.
| Позиция | Description |
|---|---|
|
|
Семантическая модель существует в рабочей области Fabric. |
|
|
Операции обрамления выполняются периодически, и они задают базовые показатели для всех будущих событий перекодирования . Операции обрамления могут выполняться автоматически, вручную, по расписанию или программным способом. |
|
|
OneLake хранит метаданные и файлы Parquet, которые представлены в виде таблиц Delta. |
|
|
Последняя операция обрамления включает файлы Parquet, связанные с таблицами Delta, а также файлы Parquet, которые были добавлены до последней операции обрамления. |
|
|
Более поздняя операция обрамления включает файлы Parquet, добавленные после последней операции обрамления. |
|
|
Столбцы резидентов в семантической модели Direct Lake могут быть исключены из памяти, а точка во времени обновления становится новой базовой базой для всех будущих событий транскодирования. |
|
|
Последующие изменения данных, представленные новыми файлами Parquet, не отображаются до следующей операции обрамления. |
Не всегда желательно иметь данные, представляющие последнее состояние любой таблицы Delta при выполнении операции транскодирования. Рассмотрим, что фреймирование может помочь обеспечить согласованные результаты запросов в средах, где данные в разностных таблицах являются временными. Данные могут быть временными по нескольким причинам, например при длительных процессах извлечения, преобразования и загрузки (ETL).
Обновление для семантической модели Direct Lake можно выполнять вручную, автоматически или программно. Дополнительные сведения см. в разделе "Обновление семантических моделей Direct Lake".
Дополнительные сведения об использовании версий и обрамления таблиц Delta см. в статье "Общие сведения о хранилище для семантических моделей Direct Lake".
Автоматические обновления
Существует параметр уровня семантической модели для автоматического обновления таблиц Direct Lake. По умолчанию он включен. Это гарантирует, что изменения данных в OneLake автоматически отражаются в семантической модели Direct Lake. Вы должны отключить автоматические обновления, если вы хотите управлять изменениями данных путем обрамления, которое было описано в предыдущем разделе. Дополнительные сведения см. в разделе "Управление семантических моделей Direct Lake".
Совет
Вы можете настроить автоматическое обновление страницы в отчетах Power BI. Это функция, которая автоматически обновляет определенную страницу отчета, обеспечивая подключение отчета к семантической модели Direct Lake (или другим типам семантической модели).
Резервный вариант DirectQuery
Запрос, отправленный в семантику Direct Lake, может вернуться в режим DirectQuery. В этом случае он извлекает данные непосредственно из конечной точки аналитики SQL озера или хранилища. Такие запросы всегда возвращают последние данные, так как они не ограничены моментом во времени последней операции обрамления.
Запрос всегда возвращается, когда семантическая модель запрашивает представление в конечной точке аналитики SQL или таблицу в конечной точке аналитики SQL, которая обеспечивает безопасность на уровне строк (RLS).
Кроме того, запрос может вернуться назад, когда семантическая модель превышает сторожевые пределы емкости.
Внимание
Если это возможно, вы всегда должны разработать решение (или размер емкости), чтобы избежать резервного использования DirectQuery. Это связано с тем, что это может привести к снижению производительности запросов.
Вы можете управлять резервным вариантом семантических моделей Direct Lake, задав его свойство DirectLakeBehavior . Дополнительные сведения см. в разделе "Настройка свойства поведения Direct Lake".
Ограничения и ограничения емкости Fabric
Для семантических моделей Direct Lake требуется лицензия на емкость Fabric. Кроме того, существуют ограничения и ограничения емкости, которые применяются к подписке на емкость Fabric (SKU), как показано в следующей таблице.
Внимание
Первый столбец в следующей таблице также включает подписки на емкость Power BI Premium (SKU). Обратите внимание, что корпорация Майкрософт объединяет варианты приобретения и выходит за отставку номера SKU power BI Premium на емкость. Новые и существующие клиенты должны рассмотреть возможность приобретения подписок на емкость Fabric (SKU) вместо этого.
Дополнительные сведения см. в разделе "Важное обновление" для лицензирования Power BI Premium и Power BI Premium.
| Fabric SKU | Файлы Parquet на таблицу | Группы строк на таблицу | Строки на таблицу (миллионы) | Максимальный размер модели на диске или OneLake (ГБ) | Максимальная память (ГБ) 1 |
|---|---|---|---|---|---|
| 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 Для семантических моделей Direct Lake максимальный объем памяти представляет ограничение ресурсов верхнего объема памяти для страницы данных. По этой причине это не охранник, так как превышение его не приводит к резервному режиму DirectQuery; однако это может повлиять на производительность, если объем данных достаточно велик, чтобы привести к чрезмерному разбиению по страницам и из данных модели из данных OneLake.
Если превышено, максимальный размер модели на диске или OneLake приведет ко всем запросам к семантической модели, чтобы вернуться в режим DirectQuery. Все остальные охранники, представленные в таблице, вычисляются на запрос. Поэтому важно оптимизировать таблицы Delta и семантику Direct Lake, чтобы избежать необходимости увеличивать масштаб до более высокого номера SKU Fabric (что приводит к увеличению затрат).
Кроме того, ограничения емкости и максимальной памяти для каждого запроса применяются к семантических моделях Direct Lake. Дополнительные сведения см. в разделе "Емкости и номера SKU".
Рекомендации и ограничения
Семантические модели Direct Lake представляют некоторые рекомендации и ограничения.
Примечание.
Возможности и функции семантических моделей Direct Lake развиваются. Обязательно периодически проверяйте список последних рекомендаций и ограничений.
- Когда таблица семантической модели Direct Lake подключается к таблице в конечной точке аналитики SQL, которая обеспечивает безопасность на уровне строк (RLS), запросы, связанные с этой таблицей моделей, всегда возвращаются в режим DirectQuery. Производительность запросов может быть медленнее.
- Когда таблица семантической модели Direct Lake подключается к представлению в конечной точке аналитики SQL, запросы, связанные с этой таблицей моделей, всегда возвращаются в режим DirectQuery. Производительность запросов может быть медленнее.
- Составное моделирование не поддерживается. Это означает, что таблицы семантической модели Direct Lake нельзя смешать с таблицами в других режимах хранения, таких как import, DirectQuery или Dual (за исключением особых случаев, включая группы вычислений, параметры what-if и параметры поля).
- Вычисляемые столбцы и вычисляемые таблицы, ссылающиеся на столбцы или таблицы в режиме хранилища Direct Lake, не поддерживаются. Группы вычислений, параметры what-if и параметры поля, которые неявно создают вычисляемые таблицы и вычисляемые таблицы, которые не ссылаются на столбцы или таблицы Direct Lake, поддерживаются.
- Таблицы режима хранения Direct Lake не поддерживают сложные типы столбцов разностных таблиц. Двоичные и семантические типы 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.
- Вы можете создать и просмотреть пользовательскую семантику Direct Lake с помощью удостоверения субъекта-службы, но семантическая модель Direct Lake по умолчанию не поддерживает субъекты-службы. Убедитесь, что проверка подлинности субъекта-службы включена для REST API Fabric в клиенте, и предоставьте участнику-службе или более высоким разрешениям рабочей области семантической модели Direct Lake.
- Direct Lake не поддерживает профили субъектов-служб для проверки подлинности.
Сравнение с другими режимами хранения
В следующей таблице сравнивается режим хранилища Direct Lake с режимами импорта и хранения DirectQuery.
| Возможность | Прямое озеро | Import | DirectQuery |
|---|---|---|---|
| Лицензирование | Только подписка на емкость Fabric (SKU) | Любая лицензия Fabric или Power BI (включая бесплатные лицензии Microsoft Fabric) | Любая лицензия Fabric или Power BI (включая бесплатные лицензии Microsoft Fabric) |
| Источник данных | Только таблицы lakehouse или склада (или представления) | Любой соединитель | Любой соединитель, поддерживающий режим DirectQuery |
| Подключение к представлениям конечных точек аналитики SQL | Да, но автоматически откатится к режиму DirectQuery | Да | Да |
| Составные модели | Нет 1 | Да. Может сочетаться с таблицами в режиме хранения DirectQuery или с двумя режимами хранения | Да. Может сочетаться с таблицами режима импорта или двойного хранения |
| Единый вход | Да | Неприменимо | Да |
| вычисляемые таблицы; | Нет— кроме групп вычислений, параметров what-if и параметров поля, которые неявно создают вычисляемые таблицы. | Да | Нет. Вычисляемые таблицы используют режим хранения импорта, даже если они ссылаются на другие таблицы в режиме DirectQuery |
| Вычисляемые столбцы | No | Да | Да |
| Гибридные таблицы | No | Да | Да |
| Секции таблицы моделей | Нет. Однако секционирование можно выполнить на уровне таблицы Delta | Да— автоматически создается путем добавочного обновления или вручную, созданного с помощью конечной точки XMLA. | No |
| Определяемые пользователем агрегаты | No | Да | Да |
| Безопасность на уровне объекта аналитики SQL или безопасность на уровне столбцов | Да. Но запросы возвращаются в режим DirectQuery и могут привести к ошибкам при отказе разрешения | Да. Но необходимо дублировать разрешения с помощью безопасности на уровне объекта семантической модели | Да. Но запросы могут привести к ошибкам при отказе разрешения |
| Безопасность на уровне строк аналитики SQL (RLS) | Да. Но запросы вернутся в режим DirectQuery | Да. Но необходимо дублировать разрешения с помощью семантической модели RLS | Да |
| Безопасность уровня строк семантической модели (RLS) | Да. Но настоятельно рекомендуется использовать фиксированное подключение к облаку удостоверений | Да | Да |
| Безопасность на уровне объекта семантической модели (OLS) | Да | Да | Да |
| Большие тома данных без требования к обновлению | Да | Менее подходящим вариантом— для запроса и обновления может потребоваться более крупный размер емкости. | Да |
| Уменьшение задержки данных | Да. Если автоматические обновления включены или программные рефрейминги; однако подготовка данных должна выполняться в начале вышестоящей передачи данных. | No | Да |
1 Нельзя объединить таблицы режима хранения Direct Lake с таблицами режима directQuery или двух режимов хранения в одной семантической модели. Однако с помощью Power BI Desktop можно создать составную модель в семантической модели Direct Lake, а затем расширить ее с помощью новых таблиц (с помощью режима импорта, DirectQuery или двойного хранилища) или вычислений. Дополнительные сведения см. в разделе "Создание составной модели" в семантической модели.