共用方式為

效能效率的最佳做法

  • 發行項

本文涵蓋效能效率的最佳做法，並按下列各節所列的架構原則進行組織。

1.垂直擴展、水平擴展和線性可擴縮性

在進入最佳做法之前，讓我們來看看一些分散式運算概念：水平調整、垂直縮放和線性延展性。

  • 垂直擴展：藉由從單一電腦新增或移除資源，通常是 CPU、記憶體或 GPU，以垂直擴展。 這通常表示停止工作負載、將其移至較大的機器，然後重新啟動。 垂直擴展有限制：可能沒有較大的機器，或下一部大型機器的價格可能高得令人望而卻步。
  • 水平擴展：藉由從分散式系統新增或移除節點，以水平擴展。 達到垂調擴展的限制時，解決方案會水平調整：分散式運算會使用具有多部機器的系統 (稱為叢集)來執行工作負載。 請務必瞭解，要實現這一點，必須為並行執行準備工作負載，如 Databricks Data Intelligence Platform、Apache Spark 和 Photon 的引擎所支援。 這可讓多台廉價機器組合成較大的運算系統。 需要更多計算資源時，水平擴展會將更多節點新增至叢集，並在不再需要節點時加以移除。 雖然在技術上沒有限制（而Spark引擎會執行負載平衡的複雜部分），但大量的節點確實會增加管理複雜性。
  • 線性可擴縮性，表示當您將更多資源新增至系統時，輸送量與使用的資源之間的關聯性是線性的。 只有當平行工作是獨立的時，才有可能這樣做。 如果沒有，叢集中另一組節點將需要一組中繼結果，以便進一步計算。 節點之間的這項數據交換牽涉到透過網路將結果從一組節點傳輸至另一組節點，這需要相當長的時間。 一般而言，分散式運算對於管理資料的散發和交換有一些開銷。 因此，可以在單一節點上分析的小型數據集工作負載，在分散式系統上執行時可能會更慢。 Databricks Data Intelligence Platform 提供彈性運算 (單一節點和分散式)，以滿足您工作負載的獨特需求。

2. 使用無伺服器架構

無伺服器計算

在 Databricks Data Intelligence Platform 上使用無伺服器計算，計算層會在客戶的 Azure Databricks 帳戶中執行。 這些服務會由 Databricks 完全管理和持續增強。 除了客戶只需為他們使用的內容付費之外，這還可以提高生產力：

  • 雲端系統管理員不必再管理複雜的雲端環境，例如調整配額、建立和維護網路資源，以及連線到計費來源。 他們可以專注於高價值專案上，而不是管理低階雲端元件。
  • 使用者受益於接近零的叢集啟動延遲，並改善查詢並行。

Databricks 為不同的工作負載提供受控服務：

  • 適用於 SQL 工作負載的無伺服器 SQL 倉儲

    工作區管理員可以建立無伺服器 SQL 倉儲，可啟用立即計算，並由 Databricks 管理。 與 Databricks SQL 查詢搭配使用，就像平常搭配原始 Databricks SQL 倉儲一樣。 無伺服器計算隨附非常快速的 SQL 倉儲啟動時間，且基礎結構是由 Databricks 管理及最佳化。

  • 無伺服器工作，實現高效可靠的工作流程

    工作的無伺服器計算可讓您執行 Databricks 工作，而無需設定及部署基礎結構。 透過無伺服器計算，您可以專注於實作資料處理和分析管線，而 Databricks 可高效地管理計算資源，包括最佳化和調整工作負載的計算。 自動調整和 Photon 會自動針對執行工作的計算資源啟用。

    您可以藉由查詢 計費使用量系統 數據表，來監視使用無伺服器計算作業的工作成本。

  • 筆記本的無伺服器計算

    如果工作區已啟用無伺服器互動計算，工作區中的所有使用者都可以存取筆記本的無伺服器計算。 不需要其他權限。

使用企業級模型提供服務

Mosaic AI 模型服務提供整合介面，可用來部署、控管及查詢 AI 模型。 您提供的每個模型都可作為 REST API，您可將其整合到網頁或用戶端應用程式中。

模型服務可為部署模型提供高可用性和低延遲的服務。 服務會自動擴大或縮減，以滿足需求變更，節省基礎結構成本，同時最佳化延遲效能。 此功能使用無伺服器計算。

3.設計效能工作負載

瞭解您的資料擷取和存取模式

從效能觀點來看，資料存取模式會因資料大小而有所不同，例如「匯總與點存取」或「掃描與搜尋」。 大型檔案對於掃描查詢更有效率，較小的檔案較適合搜尋，因為需要讀取較少的資料來尋找特定資料列。

對於擷取模式，通常會使用 DML 陳述式。 當資料叢集化時，DML 陳述式效能最高，而且可以只隔離資料的區段。 務必在數據導入期間將數據保持群集和可隔離：考慮保留自然的時間排序，並將盡可能多的篩選套用至導入目標表。 針對僅限附加和覆寫擷取工作負載，無需考慮太多，因為它是相對便宜的作業。

擷取和存取模式通常指向明顯的資料配置和叢集。 如果沒有，請決定什麼對您的業務更重要，並專注於如何更好地達成該目標。

在有利的情況下使用平行計算

處理資料時，價值實現時間是一個重要的維度。 雖然許多使用案例可以輕鬆地在單一機器上實作 (小型資料、很少和簡單的計算步驟)，但通常會有使用案例需要處理大型資料集、由於複雜的演算法使執行時間較長，或需要重複 100 和 1000 次。

Databricks 平台的叢集環境是有效率地散發這些工作負載的絕佳環境。 它會自動跨叢集的所有節點平行處理 SQL 查詢，並提供 Python 和 Scala 的媒體櫃來執行相同的作業。 在幕後，Apache Spark 和 Photon 引擎會分析查詢、判斷平行執行的最佳方式，以及以彈性的方式管理分散式執行。

與批次工作相同，結構化串流會將串流工作分散到叢集，以獲得最佳效能。

使用平行運算的最簡單方式之一是搭配 Delta Live Tables。 您可以在 SQL 或 Python 中宣告作業的工作和相依性，然後 Delta Live Tables 會處理執行規劃、有效率的基礎結構設定、作業執行和監視。

對於資料科學家來說，Pandas 是 Python 套件，可提供適用於 Python 程式設計語言之易於使用的資料結構和資料分析工具。 不過，Pandas 不會擴增至巨量資料。 Spark 上的 Pandas API 會透過提供可在 Apache Spark 上運作的 Pandas 對等 API 來填補此空白。

此外，平台也隨附標準機器學習媒體櫃 MLlib 中的平行化機器學習演算法。 它支援現成可用的多重 GPU 使用。 深度學習也可以使用 DeepSpeed Distributor 或 TorchDistributor 進行平行處理。

分析整個執行鏈結

大部分的管線或耗用量模式都涉及系統鏈結。 例如，使用 BI 工具，效能會受到數個因素的影響：

  • BI 工具本身。
  • 連接 BI 工具和 SQL 引擎的連接器。
  • BI 工具傳送查詢的 SQL 引擎。

為了達到最佳效能，必須考慮整個鏈結並加以選取/調整，以獲得最佳效能。

偏好較大的叢集

針對較大的叢集規劃，特別是當工作負載以線性方式調整時。 在此情況下，針對工作負載使用大型叢集並不比使用較小的叢集更昂貴。 它只是更快。 關鍵是在工作負載期間租用叢集。 因此，如果啟動兩個背景工作角色叢集，而且需要一小時，則會為這些背景工作角色支付一個小時的費用。 同樣地，如果您啟動四個工作節點的叢集，而且只需要半小時，這就展現了線性擴展性，成本就會相同。 如果成本是具有非常彈性 SLA 的主要驅動程式，自動調整叢集通常是最便宜的，但不一定是最快的方式。

注意

無伺服器計算無需偏好大型叢集，因為它會自動管理叢集。

使用原生 Spark 作業

使用者定義函式 (UDF) 是擴充 Spark SQL 功能的絕佳方式。 不過，如果存在原生函式存在，請勿使用 Python 或 Scala UDF：

原因：

  • 需要序列化，才能在 Python 和 Spark 之間傳輸資料。 這會大幅降低查詢速度。
  • 增加對平台中已存在的功能的實作和測試投入。

如果缺少原生函式，且應實作為 Python UDF，請使用 Pandas UDF。 Apache Arrow 可確保資料在 Spark 與 Python 之間有效率地來回移動。

使用原生平台引擎

Photon 是 Azure Databricks 上的引擎，可直接在資料湖上提供低成本的快速查詢效能，從資料擷取、ETL、串流、資料科學和互動式查詢。 Photon 與 Apache Spark API 相容，因此開始使用就像開啟它一樣簡單，不需要變更程式碼，也沒有鎖定。

Photon 是高效能執行階段的一部分，可更快速地執行現有的 SQL 和 DataFrame API 呼叫，並降低每個工作負載的總成本。 Photon 預設會在 Databricks SQL 倉儲中使用。

了解您的硬體和工作負載類型

並非所有雲端 VM 都是一樣的。 雲端提供者所提供的各種機器系列差異顯著，足以影響選擇。 有明顯的差異 - RAM 和核心 - 以及更細微的差異 - 處理器類型和產生、網路頻寬保證，以及本機高速儲存體與本機磁碟和遠端磁碟。 「現貨」市場也有差異。 在決定工作負載的最佳 VM 類型之前，應先了解這些類型。

注意

無伺服器計算不需要這樣做，因為無伺服器計算會自動管理叢集。

使用快取

快取會將經常存取的資料儲存在較快的媒體中，相較於存取原始資料來源，縮短擷取資料所需的時間。 這會使延遲較低和回應速度更快，從而大幅改善應用程式的整體效能和使用者體驗。 藉由將原始資料來源的要求數目降到最低，快取有助於降低網路流量和資料傳輸成本。 此效率提升特別有利於依賴外部 API 或依使用量付費資料庫的應用程式。 這有助於將負載更平均地分散到整個系統，以防止出現瓶頸和潛在的停機時間。

這些是 Azure Databricks 中可用的數種快取： 以下是每種類型的特性：

  • 使用磁碟快取

    磁碟快取 (先前稱為「差異快取」) 會將遠端資料的復本儲存在虛擬機器的本機磁碟上 (例如 SSD)。 它可以改善各種查詢的效能，但無法用於儲存任意子查詢的結果。 磁碟快取會自動偵測何時建立或刪除資料檔案，並據以更新其內容。 建議的（也是最簡單的）使用磁碟快取的方式是在配置叢集時，選擇具有 SSD 磁碟區的工作類型。 這類背景工作角色會針對磁碟快取啟用並設定。

  • 避免 Spark 快取

    Spark 快取 (使用 .persist() 和 .unpersist()) 可以儲存以 Parquet 以外的格式儲存的任何子查詢資料和資料的結果 (例如 CSV、JSON 和 ORC)。 不過，如果在查詢中的錯誤位置使用，它會取用所有記憶體，甚至可能會大幅降低查詢的速度。 根據經驗，除非確切知道影響，否則請避免 Spark 快取。

  • 查詢結果快取

    針對所有透過 SQL 倉儲的查詢結果進行叢集快取。 若要受益於查詢結果快取，請專注於具決定性的查詢，例如，請勿使用 = NOW() 之類的述詞。 當查詢具決定性時，且基礎資料為 Delta 格式且未變更時，SQL 倉儲會直接從查詢結果快取傳回結果。

  • Databricks SQL UI 快取

    每個使用者快取所有查詢和舊版儀表板的結果都會產生 Databricks SQL UI。

使用壓縮

Azure Databricks 上的 Delta Lake 可以改善從數據表讀取查詢的速度。 其中一個方式是將小型檔案合併成較大的檔案。 您可以執行 OPTIMIZE 命令來觸發壓縮。 請參閱 優化資料檔設定。

Delta Lake 提供選項來自動設定寫入的目標檔案大小，並用於 OPTIMIZE 操作。 Databricks 會自動調整其中許多設定，並啟用可藉由尋求適當大小檔案來自動改善數據表效能的功能：

  • 自動合併 將 Delta 表分區中的小型檔案結合起來，以自動減少小型檔案問題。 自動壓縮會在寫入數據表成功之後發生，並在已執行寫入的叢集上同步執行。 自動壓縮僅會壓縮先前尚未壓縮的檔案。
  • 優化寫入 改善檔案大小，因為數據會寫入，並有利於數據表上的後續讀取。 優化寫入對分割數據表最有效，因為它們會減少寫入每個分割區的小型檔案數目。

如需詳細資訊，請參閱設定 Delta Lake 來控制資料檔大小。

使用資料略過

資料略過可以略過不符合查詢準則的資料，大幅改善查詢效能。 這樣可減少需要讀取和處理的資料量，進而加快查詢執行時間。

為了達到此目的，當您將數據寫入 Delta 數據表時，會自動收集略過數據的數據（根據預設，Azure Databricks 上的 Delta Lake 會收集數據表架構中定義前 32 個數據行的統計數據）。 Azure Databricks 上的 Delta Lake 會在查詢時間使用這項資訊（最小值和最大值），以提供更快速的查詢。 請參閱 Delta Lake 的資料略過。

以下技術可以應用於資料略過：

  • Z 排序，一種在相同檔案集中共置相關信息的技術。 Delta Lake 資料略過演算法會自動在 Azure Databricks 上使用此共同位置。 此行為可大幅減少 Delta Lake 必須讀取的資料量。

  • Liquid 叢集 可簡化數據配置決策，並將查詢效能優化。 隨著時間的推移，它將取代資料分割和 Z 軸排序。 Databricks 建議針對所有新的 Delta 表格進行液態叢集。 Liquid 叢集可讓您彈性地重新定義叢集索引鍵，而不需重寫現有的數據，讓數據配置隨著時間而隨著分析需求而演進。 Databricks 建議對所有新的 Delta 資料表進行液體群集。

    具有下列特性的數據表受益於液體群集：

    • 依基數大的欄位進行篩選。
    • 資料分佈明顯偏斜。
    • 快速成長且需要維護和微調。
    • 具有並行寫入要求。
    • 具有隨時間變更的存取模式。
    • 一般的分區鍵可能會讓資料表有太多或太少的分區。

如需詳細資訊和技術，請參閱 優化 Databricks、Spark 和 Delta Lake Workloads的完整指南。

為 Delta Lake 啟用預測最佳化

預測優化 可以使得不再需要在 Databricks 上手動管理 Delta 表格的維護作業。 啟用預測優化后，Databricks 會自動識別受益於維護作業的數據表，併為使用者執行這些數據表。 維護作業只會視需要執行，消除了不必要執行維護作業的情況，並且消除了執行追蹤和疑難排解工作所產生的負擔。

避免過度分割

過去，資料分割是略過資料最常見的方式。 不過，資料分割是靜態的，而且會將本身顯示為檔案系統階層。 當存取模式隨著時間推移變更時，無法輕易變更分割區。 通常，資料分割會導致過度分割 - 換句話說，太多分割區具有太小檔案，導致查詢效能不佳。

Databricks 建議您不要分割大小低於 1TB 的數據表，而且如果您預期每個分割區中的數據至少為 1 GB，則只會依數據行進行分割。

同時，比資料分割更好的選擇是 Z 軸排序或較新的液體叢集 (請參閱上文)。

優化聯結效能

  • 請考慮 範圍聯結優化。

    當兩個關聯使用區間中的點或區間重疊條件進行聯結時，就會發生區間聯接。 Databricks Runtime 中的 範圍聯結優化 支援，可帶來查詢效能的大幅改善，但需要仔細手動調整。

  • 使用自適性查詢執行。

    彈性查詢執行 (AQE) 是在查詢執行期間所進行的查詢重新最佳化。 它有 4 個主要功能：

    • 動態地將排序合併聯結轉換為廣播哈希聯結。
    • 隨機交換後，動態合併分割區。
    • 動態處理排序合併聯結和重排哈希聯結中的偏斜。
    • 動態偵測並傳播空關聯。

    建議保持啟用 AQE。 可以單獨設定不同的功能。

如需詳細資訊，請參閱 完整指南，以將 Databricks、Spark 和 Delta Lake 工作負載優化。

執行分析表命令以收集表格統計數據

ANALYZE TABLE 語句會收集指定架構中數據表的相關統計數據。 查詢優化器 會使用這些統計數據來產生最佳查詢計劃、選取正確的聯結類型、在哈希聯結中選取正確的建置端，或以多重方式聯結來校正聯結順序。

預測性優化會自動執行 ANALYZE （公開預覽），這是收集 Unity 目錄受控數據表上統計數據的命令。 Databricks 建議為所有 Unity 目錄受控數據表啟用預測優化，以簡化數據維護並減少記憶體成本。 請參閱 Unity 目錄受控數據表的預測性優化。

4.在開發範圍內執行效能測試

測試生產資料的資料代表

對生產資料 (唯讀) 或類似的資料執行效能測試。 使用類似資料時，磁碟區、檔案配置和資料扭曲等特性應與生產資料類似，因為這會對效能產生重大影響。

考量預先載入資源

不論查詢和資料格式為何，叢集上的第一個查詢一律比後續查詢慢。 這是因為所有不同的子系統都在啟動並讀取其所需的所有資料。 預先載入會對效能測試結果產生重大影響：

  • 預先載入叢集：叢集資源必須在多層上初始化。 可以預熱叢集：Databricks 集區 是一組閒置且隨時可用的實例。 使用閒置執行個體建立叢集節點時，叢集啟動和自動調整時間會減少。
  • 預先載入快取：當快取是設定的一部分時，第一次執行可確保資料在快取中，加快後續工作的速度。 可以藉由執行特定查詢來初始化快取，以預先載入快取 (例如，在叢集重新啟動之後)。 這可以大幅改善前幾個查詢的效能。

因此，若要了解不同案例的行為，請測試帶預先載入和不帶預先載入的第一次執行以及後續執行的效能。

找出瓶頸

瓶頸是工作負載中的區域，隨著生產負載的增加，這些區域可能會降低整體效能。 在設計時間識別這些問題，並針對較高的工作負載進行測試，將有助於讓生產環境中的工作負載保持穩定。

5. 監視器效能

監視查詢效能

監視查詢效能可協助您了解不同查詢使用資源的方式。 可以識別執行緩慢的查詢，讓您找出系統中的效能瓶頸。 也可以識別取用大量系統資源的查詢，這些可能會導致不穩定或停機時間。 此資訊可協助您優化資源配置、減少浪費，並確保有效率地使用資源。

Databricks Data Intelligence Platform 具有各種監視功能（請參閱 卓越營運 - 設定監視、警示和記錄），其中一些可用於效能監視：

監視串流工作負載

串流監視可讓您分析資料並偵測問題，並提供系統效能和行為的即時深入解析。 藉由分析串流資料，您可以識別最佳化的趨勢、模式和機會。 這可協助您微調系統、改善資源使用率，以及降低成本。

針對串流查詢，請使用 Spark UI 中的內建結構化串流監視，或使用 Apache Spark 串流查詢接聽程式介面將計量推送至外部服務。

監視工作效能

作業監視可協助您識別並解決 Databricks 作業中的問題，例如失敗、延遲或效能瓶頸。 作業監視提供作業效能的深入解析，讓您將資源使用率優化、減少使用量，並提升整體效率。