原生執行引擎是 Microsoft Fabric 中 Apache Spark 工作執行的開創性加強程式。 此向量化引擎會直接在 Lakehouse 基礎結構上執行 Spark 查詢,以最佳化 Spark 查詢的效能和效率。 引擎的無縫整合表示不需要修改程式碼,並避免廠商鎖定。 它支援 Apache Spark API,並相容於 Runtime 1.3(Apache Spark 3.5) 及 Runtime 2.0(Apache Spark 4.1),並支援 Parquet、Delta 及 CSV 格式。 無論您的資料在 OneLake 內的位置為何,或如果您透過捷徑存取資料,原生執行引擎都會將效率和效能最大化。
原生執行引擎可大幅提升查詢效能,同時將營運成本降至最低。 實際結果會因工作負載特性與配置而異。 引擎擅長管理各種資料處理案例,範圍從例行資料擷取、批次作業和 ETL (擷取、轉換、載入) 工作到複雜的資料科學分析和回應式互動查詢。 使用者可受益於加速處理時間、提高輸送量,以及最佳化資源使用率。
原生執行引擎以兩個關鍵的 OSS 元件為基礎:Velox 是由 Meta 推出的 C++ 資料庫加速程式庫,而 Apache Gluten (孵化中) 則是由 Intel 推出的中間層,負責將 JVM 型 SQL 引擎的執行卸載至原生引擎。
支援的運算子會從基於 JVM 的 Spark 卸載到向量化的 C++ 執行路徑,提供欄位式、SIMD 加速處理,並原生支援 Parquet 與 Delta 格式。 原生引擎保留關鍵的 Fabric Spark 查詢優化,包括自適應查詢執行(AQE)、成本導向重寫、欄位修剪及謂詞下推,因此當運算子轉移時,這些優化器行為仍能完全運作。 引擎亦支援平行 Delta 快照載入,並加速利用 Z 排序與 Delta 表格液態叢集的操作,進一步提升有組織資料版面的效能。
使用原生執行引擎的時機
原生執行引擎提供在大型資料集上執行查詢的解決方案;它會使用基礎資料來源的原生功能來最佳化效能,並將通常與傳統Spark環境中的資料移動和串行化相關聯的額外負荷降到最低。 引擎支援各種運算子和資料類型,包括 Rollup 雜湊彙總、廣播巢狀迴圈連接 (BNLJ),以及精確的時間戳記格式。 不過,若要完全受益於此引擎的功能,您應該考慮其最佳使用案例:
- 在處理 Parquet 和 Delta 格式的資料時,此引擎很有效,能夠以原生且有效率的方式處理。
- 涉及複雜轉換和彙總的查詢可大幅受益於引擎的分欄處理和向量化功能。
- 效能提升最顯著的情況是,查詢不會因避免不支援的功能或運算式而觸發後援機制。
- 此引擎非常適合對運算要求較高的查詢,而非簡單或受到輸入/輸出限制的查詢。
如需原生執行引擎所支援的運算子和函式資訊,請參閱 Apache Gluten 文件。
啟用原生執行引擎
若要在預覽階段使用原生執行引擎的完整功能,則需要特定的設定。 下列程式示範如何針對筆記本、Spark 工作定義和整個環境啟用此功能。
在環境層級啟用
若要確保統一的效能增強,請在與環境相關聯的所有工作和筆記本上啟用原生執行引擎:
導覽至包含您環境的工作區,然後選取環境。 如果您尚未建立環境,請參閱 在 Fabric 中建立、設定及使用環境。
在 Spark 計算 下,選取 [加速]。
核取標示為 [啟用原生執行引擎] 的方塊。
儲存併發佈 變更。
在環境層級啟用時,所有後續工作和筆記本都會繼承設定。 此繼承可確保環境中建立的任何新工作階段或資源都會自動受益於增強的執行功能。
重要
先前,原生執行引擎是透過環境組態內的Spark設定來啟用。 現在可以使用環境設定的 [ 加速 ] 索引標籤中的切換,更輕鬆地啟用原生執行引擎。 若要繼續使用,請移至 [ 加速 ] 索引標籤,然後開啟切換開關。 如有偏好,您也可以透過Spark屬性加以啟用。
針對筆記本或 Spark 工作定義啟用
您也可以為單一筆記本或 Spark 作業定義啟用原生執行引擎,您必須在執行腳本開頭納入必要的設定:
%%configure
{
"conf": {
"spark.native.enabled": "true",
}
}
針對筆記本,請在第一個儲存格中插入必要的組態命令。 針對 Spark 任務定義,請在 Spark 任務定義的開頭包含組態。 原生執行引擎會與即時集區整合,因此一旦啟用此功能,它就會立即生效,而不需要您起始新的會話。
查詢層級上的控制
在租用戶、工作區和環境層級啟用原生執行引擎,並與 UI 無縫整合的機制正在積極開發中。 同時,您可以停用特定查詢的原生執行引擎,尤其是當查詢涉及目前不支援的運算子時 (請參閱限制)。 若要停用,請針對包含查詢的特定儲存格,將 Spark 組態 spark.native.enabled 設定為 false。
執行停用原生執行引擎的查詢之後,您必須將spark.native.enabled 設定為 true,為後續儲存格重新啟用它。 此步驟是必要的,因為 Spark 會循序執行程式碼儲存格。
識別引擎執行的作業
有數種方法可用來判斷 Apache Spark 工作中的運算子是否使用原生執行引擎來處理。
Spark UI 和 Spark 歷程記錄伺服器
存取 Spark UI 或 Spark 歷程記錄伺服器,以找出您需要檢查的查詢。 若要存取 Spark Web UI,請流覽至 Spark 作業定義並加以執行。 從 [執行] 索引標籤中,選取 [應用程式名稱 旁邊的 ...],然後選取 [開啟 Spark Web UI]。 您也可以從工作區中的 [監視器] 索引標籤進入 Spark UI。 從 [監視] 頁面中,選取筆記本或管線,即可直接存取作用中作業的 Spark UI。
在 Spark UI 介面中顯示的查詢計劃中,尋找任何以 Transformer、*NativeFileScan 或 VeloxColumnarToRowExec作為後綴結尾的節點名稱。 後置詞表示原生執行引擎已執行作業。 例如,節點可能會標示為 RollUpHashAggregateTransformer、ProjectExecTransformer、BroadcastHashJoinExecTransformer、ShuffledHashJoinExecTransformer 或 BroadcastNestedLoopJoinExecTransformer。 對於 CSV 資料來源,在 Spark UI 中,本地掃描可能以本地檔案掃描或轉換節點形式出現,類似於 Parquet 和 Delta 掃描節點。
DataFrame 說明
或者,您可以在筆記本中執行 df.explain() 命令,以檢視執行計劃。 在輸出中,尋找相同的 Transformer、*NativeFileScan 或 VeloxColumnarToRowExec 後綴。 此方法提供快速的方式,以確認原生執行引擎是否正在處理特定作業。
Fabric Spark Advisor 警示
Fabric Spark Advisor 在筆記本單元執行時提供即時備援可視性。 當操作員或計畫區段退回基於 JVM 的 Spark 而非原生路徑時,Advisor 會直接在筆記本小格輸出中顯示警示,幫助你快速識別不支援的操作員或配置,而不必離開筆記本。 你可以利用這些警示來診斷何時未套用原生卸載,並決定是否調整查詢或設定。
後援機制
在某些情況下,原生執行引擎可能會因為不支援的功能等原因而無法執行查詢。 在這些情況下,此作業會退回到傳統的 Spark 引擎。 此 自動 後援機制可確保工作流程不會中斷。
監視引擎執行的查詢和數據框架
若要進一步瞭解原生執行引擎如何套用至 SQL 查詢和數據框架作業,以及向下切入至階段和運算符層級,您可以參考 Spark UI 和 Spark 歷程記錄伺服器,以取得原生引擎執行的詳細資訊。
原生執行引擎索引標籤
您可以流覽至新的 [麩質 SQL / 數據框架] 索引標籤,以檢視麩質組建資訊和查詢執行詳細數據。 查詢表提供了在原生引擎上執行的節點數目,以及針對每個查詢回退到 JVM 的節點數目的深入解析。
查詢執行圖形
您也可以在 Apache Spark 查詢執行計劃的視覺化中選取查詢描述。 執行圖表提供跨階段及其個別作業的原生執行細節。 背景色彩區分執行引擎:綠色代表原生執行引擎,而淺藍色表示作業是在預設 JVM 引擎上執行。
限制
雖然 Microsoft Fabric 中的原生執行引擎 (NEE) 大幅提升 Apache Spark 作業的效能,但它目前有下列限制:
現有的限制
Spark 功能不相容:原生執行引擎目前不支援結構化串流。 若使用不支援的功能,無論是直接使用還是透過匯入函式庫,Spark 會回復到預設引擎。 現在支援 Python UDF、Scala UDF 以及複雜的資料型別(陣列、映射、結構體)。 如需詳細資訊,請參閱 原生執行引擎中的 Python UDF、Scala UDF 和複雜資料類型。
不支援的檔案格式:針對
JSONXML與格式的查詢不會被原生執行引擎加速。 這些默認會回到常規的 Spark JVM 引擎來執行。 CSV 現在透過向量化 CSV 解析器支援。不支援 ANSI 模式:原生執行引擎不支援 ANSI SQL 模式。 如果啟用,執行會回復至原版 Spark 引擎。
日期篩選類型不符:若要受益於原生執行引擎的加速,請確定數據類型中日期比較的兩端相符。 例如,不要將
DATETIME欄位與字串常值進行比較,而是將它明確地轉型,如下所示:CAST(order_date AS DATE) = '2024-05-20'
其他考量與限制
十進制到浮點數轉換不匹配:從
DECIMAL轉換成FLOAT時,Spark 會藉由轉換成字串並剖析來保留精確度。 NEE (透過 Velox) 會從內部int128_t表示法執行直接轉換,這可能會導致四捨五入差異。時區設定錯誤 :在Spark中設定無法辨識的時區會導致工作在NEE下失敗,而Spark JVM則會正常處理。 例如:
"spark.sql.session.timeZone": "-08:00" // May cause failure under NEE不一致的舍入行為:由於
round()依賴std::round,函數在 NEE 中的行為不同,這不會複製 Spark 的舍入邏輯。 這可能會導致四捨五入結果中的數值不一致。函式中
map()遺漏重複索引鍵檢查:當spark.sql.mapKeyDedupPolicy設為EXCEPTION時,Spark 會擲回重複索引鍵的錯誤。 NEE 目前會略過這項檢查,並允許查詢不正確地成功。
範例:SELECT map(1, 'a', 1, 'b'); -- Should fail, but returns {1: 'b'}中
collect_list()排序的順序差異:使用DISTRIBUTE BY和SORT BY時,Spark 會保留 中的collect_list()項目順序。 NEE 可能會因為洗牌差異而以不同的順序傳回值,這可能會導致順序敏感邏輯的期望不一致。collect_list()這種不相符可能會導致查詢規劃或執行期間發生相容性問題。儲存存取所需的受管理私有端點:當啟用原生執行引擎(NEE)時,若 Spark 作業嘗試使用受管理私有端點存取儲存帳戶,使用者必須為 Blob(blob.core.windows.net)端點和 DFS / 檔案系統(dfs.core.windows.net)端點分別設定受管理私有端點,即使它們指向同一儲存帳戶。 單一端點無法同時用於兩者。 這是目前的限制,且在有管理私有端點到儲存帳號的工作區啟用原生執行引擎時,可能需要額外的網路設定。