Direct Lake 是 Power BI 語意模型中儲存在 Microsoft Fabric 工作區中的數據表儲存模式選項。 它已針對大量數據進行優化，可從儲存在 OneLake 中的 Delta 數據表快速載入記憶體，這是所有分析數據的單一存放區。 載入記憶體後，語意模型會啟用高效能互動式分析。
Direct Lake 非常適合用於語意模型，這些模型透過 Delta 表格連接到大型 Fabric Lakehouse、資料倉儲和其他來源，特別是在將整個資料量複製進匯入模型中成為挑戰或不可能的情況下。 Direct Lake 查詢類似於「匯入」模式，由 VertiPaq 查詢引擎處理，而 DirectQuery 會將查詢發送至基礎數據源。 這表示 Direct Lake 查詢，例如匯入模式，通常優於 DirectQuery。
不過，Direct Lake 與匯入模式之間有一個重要的不同之處：對 Direct Lake 語意模型來說，重新整理操作在概念上與重新整理匯入語意模型的操作不同。 匯入模式會複製數據，並為語意模型建立整個快取的數據複本，而 Direct Lake 功能的重新整理只會複製元數據（如本文稍後所述的 框架），只需幾秒鐘即可完成。 Direct Lake 重新整理是低成本的作業，可分析最新版 Delta 數據表的元數據，並更新為參考 OneLake 中的最新檔案。 相反地，匯入重新整理會產生數據的複本，這可能需要大量時間並耗用相當多的數據來源和容量資源（記憶體和 CPU）。 Direct Lake 會將數據準備移至 OneLake，因此會使用網狀架構技術的完整廣度來進行數據準備，包括 Spark 作業、T-SQL DML 語句、數據流、管線等等。
Direct Lake 儲存模式提供下列主要優點：
- 與匯入模式類似，VertiPaq 引擎會處理 Direct Lake 查詢，因此可提供可比作匯入模式的查詢效能，而不需要數據重新整理週期的管理額外負荷來載入整個數據磁碟區。
- 透過與大型 Lakehouse、倉儲和其他使用 Delta 表格的 Fabric 架構來源緊密整合，活用現有的 Fabric 投資。 例如，Direct Lake 是獎牌湖屋架構中 黃金 分析層的理想選擇。
- 這樣能最大化投資報酬率（ROI），因為分析中數據的量可能會超出記憶體容量的上限，但只有回答查詢所需的數據才會被載入到記憶體中。
- 藉由快速且自動同步處理語意模型與其來源，讓新數據可供商務使用者使用，而不需要重新整理排程，即可將數據延遲降到最低。
何時應該使用 Direct Lake 儲存模式？
Direct Lake 儲存模式的主要使用案例通常是針對使用以湖為中心的架構的 IT 驅動分析專案。 在這種情況下，您有或預期會在 OneLake 中累積大量數據。 將數據快速載入記憶體、頻繁且快速重新整理作業、有效率地使用容量資源，以及快速查詢效能對於此使用案例而言都很重要。
注意
匯入和 DirectQuery 語意模型仍然與 Fabric 相關，而且是某些案例語意模型的正確選擇。 例如，匯入儲存模式通常適用於自助分析師，其需要自由和靈活度來快速採取行動，而不需要依賴 IT 來新增數據元素。
此外， OneLake 整合 會自動將匯入儲存模式中的數據表數據寫入 OneLake 中的 Delta 數據表 ，而不需要任何移轉工作，這可讓您了解匯入語意模型使用者可以使用的 Fabric 的許多優點，例如透過快捷方式、SQL 查詢、筆記本等方式與 Lakehouses 整合。 我們建議此選項快速取得 Fabric 的優點，而不一定或立即重新設計現有的數據倉儲和/或分析系統。
Direct Lake 依賴於在數據湖中完成的數據準備工作。 您可以使用各種工具來完成數據準備，例如 Fabric Lakehouses 的 Spark 作業、適用於網狀架構倉儲的 T-SQL DML 語句、數據流、管線等，這有助於確保數據準備邏輯在架構中上游執行，以最大化重複使用性。 不過，如果語意模型作者無法修改來源專案，例如，如果自助分析師在IT管理的Lakehouse上沒有寫入許可權，則使用匯入儲存模式數據表來增強模型可能是不錯的選擇，因為匯入模式支援使用Power Query進行數據準備， 定義為語意模型的一部分。
當您考慮 Direct Lake 儲存模式時，請務必考慮您目前的 Fabric 容量授權和 Fabric 容量防護。 此外，請考慮 的考量和的限制，本文稍後會加以說明。
提示
建議您產生 原型或概念證明（POC），以判斷 Direct Lake 語意模型是否為正確的解決方案，以及降低風險。
重要概念和術語
本文假設您熟悉以下概念：
- 使用者與 Power BI 報表中的視覺效果互動，這些視覺效果會產生語意模型的 DAX 查詢。
-
儲存模式：語意模型會根據採用的儲存模式，以不同的方式處理DAX查詢。 例如：
- 匯入和 Direct Lake 儲存模式會使用 VertiPaq 引擎來處理 DAX 查詢，並將結果傳回 Power BI 報表和使用者。
- 另一方面，DirectQuery 會將 DAX 查詢轉譯為數據源的查詢語法（通常是 SQL 形式），並將其同盟至基礎資料庫。 相較於匯入和 Direct Lake 模式，源資料庫查詢處理器通常不適合 BI 樣式、匯總查詢，因此會導致效能變慢，且用戶互動性降低。
儲存模式是語意模型中數據表的屬性。 當語意模型包含具有不同儲存模式的數據表時，即稱為複合模型。 如需儲存模式的詳細資訊，請參閱 Power BI 服務中的語意模型模式。
Direct Lake 模式 可以使用兩種不同的存取方法：
- OneLake 上的 Direct Lake 不依賴 SQL 端點，而且可以使用來自任何 Fabric 資料來源的資料與 Delta 表格。 OneLake 上的 Direct Lake 不會回復為 DirectQuery 模式。
注意
OneLake 上的 Direct Lake 目前處於公開預覽狀態。
- 在 SQL 端點上的 Direct Lake 使用 Fabric 湖倉或倉庫的 SQL 端點來進行 Delta 表探索和權限檢查。 當 Direct Lake on SQL 端點無法直接從 Delta 數據表載入數據時，例如當數據源是 SQL 檢視，或當倉儲使用 SQL 型數據列層級安全性 （RLS） 時，Direct Lake 可以回復為 DirectQuery 模式。 SQL 端點上的 Direct Lake 已在生產環境中正式推出且完全支援。
記憶體模式的比較
下表比較 Direct Lake 儲存模式與匯入和 DirectQuery 儲存模式。
| 能力 | OneLake 上的 Direct Lake | SQL 端點上的 Direct Lake | 進口 | DirectQuery |
|---|---|---|---|---|
| 授權許可 | 僅限網狀架構容量訂用帳戶 （SKU） | 僅限網狀架構容量訂用帳戶 （SKU） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） | 任何網狀架構或 Power BI 授權（包括Microsoft網狀架構免費授權） |
| 數據源 | 任何使用 Delta 表格支援的 Fabric 數據來源之數據表 | 只有湖倉或數據倉儲的資料表（或檢視表） | 任何連接器 | 任何支援 DirectQuery 模式的連接器 |
| 連接到 SQL 分析端點檢視 | 不 | 是 – 但會自動回復到 DirectQuery 模式 | 是的 | 是的 |
| 複合模型 | 無 1 | 無 1 | 是 – 可以結合 DirectQuery 或雙重儲存模式數據表 | 是 – 可以結合匯入或雙重儲存模式數據表 |
| 單一登入 （SSO） | 是的 | 是的 | 不適用 | 是的 |
| 計算表格 | 是 – 但計算無法參考 Direct Lake 模式中的數據表數據欄。 | 否 – 除了 計算群組、假設參數，以及 字段參數，以隱含方式建立導出數據表 | 是的 | 否 – 計算表即使在參考 DirectQuery 模式中的其他表時，也會使用匯入儲存模式。 |
| 計算欄位 | 是 – 但計算無法參考 Direct Lake 模式中的數據表數據欄。 | 不 | 是的 | 是的 |
| 混合式數據表 | 不 | 不 | 是的 | 是的 |
| 模型數據表分割區 | 否 – 不過，可以在 Delta 表層級進行分割 | 否 – 不過，可以在 Delta 表層級進行分割 | 是 – 由累加式重新整理自動建立，或使用 XMLA 端點手動建立 | 不 |
| 使用者定義的匯總 | 不 | 不 | 是 – 支援在 DirectQuery 數據表上匯入匯總數據表 | 是的 |
| SQL 分析端點物件層級安全性或數據行層級安全性 | 不 | 是 – 但可能會在許可權遭到拒絕時產生錯誤 | 是，但必須在語意模型中重複設定物件層級安全性的許可權。 | 是 – 但當許可權遭到拒絕時，查詢可能會產生錯誤 |
| SQL 分析端點資料列層級安全性（RLS） | 不 | 是 – 但查詢會回復為 DirectQuery 模式 | 是 – 但必須要使用語意模型 RLS 複製許可權 | 是的 |
| 語意模型資料列層級安全性 （RLS） | 是 – 但強烈建議使用 固定身分識別 雲端連線 | 是 – 但強烈建議使用 固定身分識別 雲端連線 | 是的 | 是的 |
| 語意模型物件層級安全性 （OLS） | 是的 | 是的 | 是的 | 是的 |
| 不需要重新整理的大型數據磁碟區 | 是的 | 是的 | 不 | 是的 |
| 減少數據延遲 | 是 – 啟用 自動更新 或以程序設計方式重新建構時 | 是 – 啟用 自動更新 或以程序設計方式重新建構時 | 不 | 是的 |
| Power BI Embedded | 是 2 | 是 2 | 是的 | 是的 |
1 在 SQL 端點上使用 Direct Lake 時，您無法將 Direct Lake 儲存模式數據表與 相同語意模型中的 DirectQuery 或雙重儲存模式數據表結合在一起。 不過，您可以使用Power BI Desktop 在 Direct Lake 語意模型上建立複合模型，然後使用新的數據表來擴充它（使用匯入、DirectQuery 或雙重儲存模式）或計算。 如需詳細資訊，請參閱 在語意模型上建置複合模型。
2 需要 V2 嵌入令牌。 如果您使用服務主體，則必須使用固定識別雲端連線。
Direct Lake 的運作方式
通常，傳送至 Direct Lake 語意模型的查詢是從 Delta 表中取得資料欄後，由記憶體快取（暫存）處理。 Delta 數據表的基礎記憶體是 OneLake 中的一或多個 Parquet 檔案。 Parquet 檔案會依數據行而非數據列來組織數據。 語意模型會將整個數據行從 Delta 資料表載入記憶體，因為查詢需要這些數據行。
OneLake 上的 Direct Lake 不會與 SQL 端點結合，因此提供更緊密的整合，特別是與 OneLake 的各項功能，如 OneLake 安全性和更高效的 DAX 查詢計劃。這樣一來，例如，便不需要執行 SQL 基礎的安全性檢查。 OneLake 上的 Direct Lake 不支援 DirectQuery 回退機制。
使用 SQL 端點上的 Direct Lake 時，DAX 查詢可能會使用 DirectQuery 後援，這牽涉到順暢地切換至 DirectQuery 模式。 DirectQuery 備援直接從 lakehouse 的 SQL 分析端點或倉儲 擷取數據。 例如，在 SQL 端點中偵測到 SQL 型安全性時，就會發生後援。 在此情況下，DirectQuery 作業會將查詢傳送至 SQL 分析端點。 後援作業可能會導致查詢效能變慢。
下列各節說明 Direct Lake 概念和功能，包括數據行載入、框架、自動更新和 DirectQuery 後援。
欄位載入（轉碼）
Direct Lake 語意模型僅在首次查詢欄位時，從 OneLake 同時載入數據。 從 OneLake 按需載入資料的過程稱為 轉碼。
當語意模型收到 DAX （或多維度表示式 — MDX） 查詢時，它會先判斷產生查詢結果所需的數據行。 查詢中直接使用的任何欄，以及關聯性和量值所需的欄都是必需的。 一般而言，產生查詢結果所需的數據行數目明顯小於語意模型中定義的數據行數目。
一旦瞭解需要哪些數據行，語意模型就會判斷哪些數據行已經在記憶體中。 如果查詢所需的任何數據行不在記憶體中，語意模型會從 OneLake 載入這些數據行的所有數據。 載入欄位數據通常是快速的操作，然而這可能取決於欄位中儲存的數據基數等因素。
載入至記憶體中的欄位然後會常駐於記憶體中。 未來只涉及常駐數據行的查詢不需要將更多數據行載入記憶體中。
欄位會持續駐留，直到有理由將它從記憶體中移除（逐出）。 可能會被移除的這些欄位原因包括：
- 在來源的 Delta 數據表更新之後，模型或數據表會重新整理（請參閱下一節中的 框架）。
- 這個數據欄已經有一段時間沒有被查詢使用。
- 其他記憶體管理原因，包括由於其他並行作業而導致容量記憶體壓力增加。
您選擇的 Fabric SKU 將決定容量內每個 Direct Lake 語意模型的最大可用記憶體。 如需資源護欄和記憶體限制上限的詳細資訊，請參閱本文稍後 網狀架構容量護欄和限制。
框架
框架設計為模型擁有者提供在特定時間點控制哪些數據載入語意模型的能力。 框架是由語意模型重新整理所觸發的 Direct Lake 作業，在大部分情況下只需要幾秒鐘的時間才能完成。 因為這是一個低成本的操作，語意模型會分析 Delta Lake 表格最新版本的元數據，並更新以參考 OneLake 中最新的 Parquet 格式檔案。
當框架化發生時，如果基礎數據已變更，而重新整理的時間點成為未來所有轉碼事件的新基準，駐留於記憶體中的表格列段和字典可能會被移除。 從這一點開始，Direct Lake 查詢只會考慮到最近一次框架操作時的 Delta 表格中的數據。 因此，系統會查詢 Direct Lake 表，以根據 Delta 表在 最近的框架操作時的狀態返回數據。 該時間不一定是 Delta 數據表的最新狀態。
語意模型會在框架過程中分析每個 Delta 表的 Delta 日誌，僅卸載受影響的欄位區段，並在轉碼過程中重載新加入的數據。 重要的優化是，當累加框架生效時，通常不會卸除字典，而且會將新的值新增至現有的字典。 這個累加框架方法有助於降低重載負擔，並有利於查詢效能。 在理想情況下，當 Delta 資料表沒有收到任何更新時，記憶體中已駐留的欄位不需要重載，而查詢在處理框架後的效能影響明顯減少，因為增量處理框架基本上使語義模型能夠就地更新現有記憶體數據的大部分。
下圖顯示 Direct Lake 框架作業的運作方式。
此圖描述下列程式和功能。
| 項目 | 描述 |
|---|---|
|
Fabric 工作區中存在語義模型。 |
|
框架作業會定期進行，並設定所有未來 轉碼 事件的基準。 框架作業可以自動、手動、依排程或以程式設計方式進行。 |
|
OneLake 會儲存元數據和 Parquet 檔案，以 Delta 數據表表示。 |
|
最後一個框架作業包含與 Delta 資料表相關的 Parquet 檔案，特別是上一次 最後一個 框架作業之前新增的 Parquet 檔案。 |
|
後續的框架作業會包含在最後框架作業之後新增的 Parquet 檔案。 |
|
Direct Lake 語意模型中的駐留欄可能會被逐出記憶體，並且刷新的時間點將成為所有未來轉碼事件的新基準。 |
|
後續的數據修改，會以新的 Parquet 檔案形式呈現，直到下一次框架操作發生時才會顯示。 |
轉碼作業發生時，並非總是需要獲得代表任何 Delta 數據表最新狀態的數據。 請考慮使用框架可以幫助您在 Delta 資料表中的短暫性環境中提供一致的查詢結果。 數據可能會因為多種原因而暫時性存在，例如當長時間執行的提取、轉換和載入（ETL）過程發生時。
Direct Lake 語意模型的重新整理可以手動、自動或以程式設計方式完成。 如需詳細資訊，請參閱 重新整理 Direct Lake 語意模型。
自動更新
有語意模型層級設定可自動更新 Direct Lake 數據表。 默認會啟用。 它可確保 OneLake 中的數據變更會自動反映在 Direct Lake 語意模型中。 當您想要透過框架控制數據變更時，應該停用自動更新，如上一節所述。 如需詳細資訊，請參閱 管理 Direct Lake 語意模型。
提示
您可以在 Power BI 報表中設定 自動頁面重新整理。 這是一項自動重新整理特定報表頁面的功能，前提是報表連接到 Direct Lake 語意模型（或其他類型的語意模型）。
DirectQuery 備援
在 SQL 端點上使用 Direct Lake 時，傳送至 Direct Lake 語意模型的查詢可以回復為 DirectQuery 模式 ，在此情況下，數據表不會再以 Direct Lake 模式運作。 它會直接從 Lakehouse 或倉儲的 SQL 分析端點擷取數據。 這類查詢一律會傳回最新的數據，因為它們不會受限於最後一個框架作業的時間點。
當 DirectQuery 後援機制啟動時，查詢將不再使用 Direct Lake 模式。 當語意模型查詢 SQL 分析端點中的檢視，或強制執行數據列層級安全性的 SQL 分析端點數據表時，查詢就無法利用 Direct Lake 模式。 此外，當 Delta 資料表超出容量限制時，查詢將無法利用 Direct Lake 模式。
重要
如果可能，您應該一律設計您的解決方案或調整您的容量，以避免 DirectQuery 回退機制。 這是因為它可能會導致查詢效能變慢。
您可以藉由設定其 DirectLakeBehavior 屬性來控制 Direct Lake 語意模型的回退。 此設定僅適用於 SQL 端點上的 Direct Lake。 OneLake 上的 Direct Lake 不支援 DirectQuery 後援。 如需詳細資訊，請參閱 設定 Direct Lake 行為屬性。
數據安全性和訪問許可權
根據預設，Direct Lake 會使用單一登錄 （SSO），這表示查詢語意模型的身分識別（通常是報表用戶）必須獲得存取數據的授權。 或者，您可以將 Direct Lake 模型系結至可共用的雲端連線 （SCC），以提供固定身分識別並停用 SSO。 在此情況下，只有固定身分識別需要來源中數據的讀取許可權。
布料項目許可權
Direct Lake 語意模型遵守分層式安全性模型。 他們會執行許可權檢查，以判斷嘗試存取數據的身分識別是否具有源數據項和語意模型中的必要數據訪問許可權。 在 Microsoft Fabric 中使用工作區角色可以直接指派許可權，或隱含地取得許可權。
請務必知道 OneLake 上的 Direct Lake 和 SQL 端點上的 Direct Lake 會以不同的方式執行許可權檢查。
- OneLake 上的 Direct Lake 需要 Lakehouse/warehouse 的 讀取 和 ReadAll 許可權，才能存取 Delta 數據表。
- Direct Lake on SQL 端點需要 Lakehouse/warehouse 的 讀取 和 ReadData 許可權，才能從 SQL 分析端點存取數據。
注意
OneLake 上的 Direct Lake 要求使用者有權讀取 OneLake 中的 Delta 數據表，而不一定是 SQL 端點。 這會強制執行集中式安全性設計，其中 OneLake 是單一訪問控制來源。
另一方面，Sql 端點上的 Direct Lake 需要使用者具有 SQL 端點的讀取許可權，而不一定能夠存取 OneLake 中的 Delta 數據表。 這是因為 Fabric 會將必要的許可權授與語意模型，以讀取 Delta 數據表和相關聯的 Parquet 檔案（將數據行數據 載入記憶體中）。 語意模型也具有定期讀取 SQL 分析端點以執行許可權檢查的必要許可權，以判斷查詢使用者（或固定身分識別）可以存取的數據。
語意模型權限
除了 Fabric 專案許可權之外，您也必須將許可權授與使用者，讓他們可以使用或管理 Direct Lake 語意模型。 簡言之，報表取用者需要 讀取 許可權，而報表建立者需要額外的 建置 許可權。 語意模型許可權可以直接 指派 ，或使用 工作區角色隱含取得。 若要管理語意模型設定（用於重新整理和其他組態），您必須是 語意模型擁有者。
權限需求
請考慮下列案例和許可權需求。
| 情境 | 所需權限 | 評論 |
|---|---|---|
| 用戶可以檢視報表 | 授與報表的 讀取 許可權，以及語意模型的 讀取 許可權。 如果語意模型在 SQL 端點上使用 Direct Lake，且 雲端連線 使用 SSO，請至少授與 Lakehouse 或倉儲的 Read 和 ReadData 許可權。 如果語意模型使用 OneLake 上的 Direct Lake，且雲端連線使用 SSO，請至少授與 OneLake 中 Delta 數據表的 讀取 和 ReadAll 許可權。 |
報表不需要屬於與語意模型相同的工作區。 如需詳細資訊，請參閱 唯讀取用者的策略。 |
| 使用者可以建立報表 | 授與語意模型的 建置權限。 如果語意模型在 SQL 端點上使用 Direct Lake，且雲端連線使用 SSO，請至少授與 Lakehouse 或倉儲的 Read 和 ReadData 許可權。 如果語意模型使用 OneLake 上的 Direct Lake，且雲端連線使用 SSO，請至少授與 OneLake 中 Delta 數據表的 讀取 和 ReadAll 許可權。 |
如需詳細資訊，請參閱 內容建立者策略。 |
| 用戶可以檢視報表，但拒絕查詢 OneLake 中的 Lakehouse、SQL 分析端點或 Delta 數據表 | 授與報表的 讀取 許可權，以及語意模型的 讀取 許可權。 請勿將 lakehouse、warehouse 或 Delta 數據表的任何許可權授與使用者。 |
只有在 Direct Lake 模型透過已停用 SSO 的雲端連線使用固定身分識別時才適用。 |
| 管理語意模型，包括重新整理設定 | 需要語意模型擁有權。 | 如需詳細資訊，請參閱 語意模型擁有權。 |
重要
在將語意模型和報表發行至生產環境之前，您應該一律徹底測試許可權。
如需詳細資訊，請參閱語意模型權限。
網狀架構容量需求
Direct Lake 語意模型需要 Fabric 容量授權。 此外，還有適用於您的 Fabric 容量訂用帳戶的容量防護欄和限制，如下表所示。
重要
下表中的第一欄也包含 Power BI Premium 容量訂用帳戶（P SKUs）。 Microsoft正在合併購買選項，並淘汰針對不同容量的 Power BI Premium 存貨單位（SKU）。 新舊客戶應考慮購買 Fabric 容量訂閱（F SKU）作為替代選擇。
如需詳細資訊，請參閱 Power BI Premium 授權 和 Power BI Premium的重要更新。
| 布料 SKU | 每個資料表的 Parquet 檔案 | 每個表格的行群組 | 每個資料表的資料列數 （百萬個） | 磁碟或 OneLake 上的模型大小上限（GB） | 最大記憶體 （GB） 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 | 6,000 | 無限 | 100 |
| F512/P4 | 一萬 | 一萬 | 12,000 | 無限 | 200 |
| F1024/P5 | 一萬 | 一萬 | 24,000 | 無限 | 400 |
| F2048 | 一萬 | 一萬 | 24,000 | 無限 | 400 |
在 Direct Lake 語義模型中，Max Memory 代表可載入數據的記憶體資源上限。 基於這個理由，它不被視作一個限制，因為即使超過這個範圍，系統也不會退回至 DirectQuery 模式；然而，如果數據量大到足以導致 OneLake 數據中的模型數據過多地分頁和調出/調入，可能會對效能造成影響。
當超出磁碟/OneLake 上模型的最大大小 時，所有對語意模型的查詢將回退到 DirectQuery 模式。 數據表中呈現的所有其他護欄都會根據每個查詢進行評估。 因此，請務必將 Delta 數據表 和 Direct Lake 語意模型 優化，以避免不必要地升級至更高級別的 Fabric SKU。
此外，容量單位 和 每個查詢的最大記憶體限制 適用於 Direct Lake 語意模型。 如需詳細資訊，請參閱 容量和 SKU。
考慮和限制
Direct Lake 語意模型提供一些考慮和限制。
注意
Direct Lake 語意模型的功能和功能正在快速演進。 請務必定期回來查看，以檢閱最新的考慮和限制清單。
| 考量與限制 | OneLake 上的 Direct Lake | Direct Lake on SQL （分析端點） |
|---|---|---|
| 當 SQL 分析端點強制執行數據列層級安全性時，DAX 查詢會根據採用的 Direct Lake 模式類型以不同的方式處理。 使用 OneLake 上的 Direct Lake 時，查詢將會成功，而且不會套用以 SQL 為基礎的 RLS。 OneLake 上的 Direct Lake 需要使用者能夠存取 OneLake 中的檔案，而 OneLake 中不會觀察以 SQL 為基礎的 RLS。 |
查詢將會成功。 | 是，除非停用後援，否則查詢將會失敗。 |
| 如果語意模型中的數據表是以 （非具體化） SQL 檢視為基礎，則 DAX 查詢會根據採用的 Direct Lake 模式類型以不同的方式處理。 在此情況下，SQL 端點上的 Direct Lake 會回復至 DirectQuery。 不支持根據非具體化的 SQL 檢視，在 OneLake 數據表上建立 Direct Lake。 您可以改用 lakehouse 實體化檢視，因為 Delta 資料表已被建立。 或者，針對以非具體化 SQL 檢視為基礎的數據表，使用不同的儲存模式，例如 Import 或 DirectLake。 |
不適用 | 是，除非停用後援，否則查詢將會失敗。 |
| 目前不支持複合模型化，這表示 Direct Lake 語意模型數據表無法與其他儲存模式中的數據表混合，例如 Import、DirectQuery 或 Dual（除了特殊案例，包括 計算群組、 假設參數和 字段參數除外）。 | 不支援 | 不支援 |
| 不支援計算資料行和計算資料表參照 Direct Lake 儲存模式中的資料行或資料表。 計算群組、假設參數，以及 欄位參數，隱式創建計算表，以及支持未參考 Direct Lake 欄或表的計算表。 | 不支援 | 不支援 |
| Direct Lake 儲存模式數據表不支援複雜的 Delta 數據表資料行類型。 也不支援二進位和 GUID 語意類型。 您必須將這些資料類型轉換成字串或其他支援的數據類型。 | 不支援 | 不支援 |
| 數據表關聯性需要相關數據行的數據類型才能比對。 | 是的 | 是的 |
| 關聯性的單向欄位必須包含唯一的值。 如果在單邊數據行中偵測到重複的值，查詢會失敗。 | 是的 | 是的 |
| Power BI Desktop 中的自動日期/時間智慧 ，只使用 datetime 數據行的日期部分來建立關聯性。 注意：支援 將您自己的日期數據表標示為日期數據表 ，並使用日期數據行建立關聯性。 | 支持 | 不支援 |
| 字串數據行值的長度限制為 32,764 個 Unicode 字元。 | 是的 | 是的 |
| 不支援非數值浮點值，例如 NaN （不是數位）。 | 是的 | 是的 |
| 使用服務主體從 Power BI 發行至 Web，只有在使用 Direct Lake 語意模型 的固定身分識別時，才支援 。 | 是的 | 是的 |
| 在 Web 模型化體驗中，Direct Lake 語意模型的驗證有限。 用戶的選擇會被假定為正確，並且不會發出任何查詢來驗證關聯上的基數或交叉篩選的選項，以及標記的日期表中選定的日期欄位。 | 是的 | 是的 |
| 在 Fabric 入口網站中，重新整理歷程記錄的 [Direct Lake] 索引標籤會列出與 Direct Lake 相關的重新整理失敗。 除非重新整理狀態變更，否則通常不會列出成功的重新整理（框架）作業，例如狀態從之前沒有執行或重新整理失敗變更為重新整理成功，或重新整理成功且有警告。 | 是的 | 是的 |
| 您的網狀架構 SKU 會針對容量決定每個 Direct Lake 語意模型的最大可用記憶體。 超出限制時，語意模型的查詢可能會因為模型數據的載入和卸載而變慢。 | 是的 | 是的 |
| 不支援在位於數據源工作區不同區域的工作區中建立 Direct Lake 語意模型。 例如，如果 Lakehouse 位於美國中西部，則您只能從相同區域中的這個 Lakehouse 建立語意模型。 一個解決方案是在其他區域的工作區中創建 Lakehouse，並在創建語意模型之前，先對數據表建立捷徑。 若要尋找您位於哪個區域，請參閱 尋找您的 Fabric 主區域。 | 是的 | 是的 |
| 內嵌報表需要 V2 內嵌令牌。 | 是的 | 不支援 |
| 用於驗證的服務主體配置檔。 | 不支援 | 不支援 |
| 服務主體和查看者角色成員資格可以用來建立和查詢 Power BI Direct Lake 語意模型，但在 Lakehouse/warehouse 上的預設 Direct Lake 語意模型無法支持這種情境。 | 是的 | 是的 |
| Lakehouse 中的快捷方式可作為語意模型數據表的數據源。 | 公開預覽期間不支援 | 支持 |
| 在個人工作區中建立 Direct Lake 模型（我的工作區）。 | 不支援 | 不支援 |
| 部署管線規則以重新系結數據源。 | 不支援 | 支持 |