DLT資料表效能最佳化與UnityCatalog治理

– 15 分鐘閱讀

Delta Live Tables（DLT）效能的提升對於高效資料處理至關重要，Z-order 聚類別和刪除向量是兩種有效的最佳化技術。Z-order 聚類別藉由指定關鍵欄位，例如 zip_code 和 driver_id，將相關資料儲存在一起，進而減少查詢掃描的資料量。刪除向量則可避免在更新資料時進行整行重寫，有效提升寫入效能。此外，Databricks 的 Unity Catalog 提供了集中式的資料治理方案，簡化了湖倉中的資料安全管理。Unity Catalog 支援三種叢集型別：單使用者叢集、分享叢集和獨立叢集，並透過三級名稱空間（目錄、架構和表）組織資料物件。透過資料標籤和目錄化功能，使用者可以更輕鬆地探索、發現和使用資料集，同時 Unity Catalog 的集中式身份管理和嚴格的存取控制機制，確保資料安全和合規性。

最佳化DLT資料表的效能：Z-order聚類別與刪除向量

在建立高效能的資料處理管線時，最佳化資料表的佈局至關重要。本文將探討如何利用Z-order聚類別和刪除向量來提升Delta Live Tables（DLT）的效能。

使用Z-order聚類別最佳化資料表佈局

Z-order聚類別是一種最佳化技術，能夠改善資料表的查詢效能。在DLT中，可以透過在資料集定義中設定適當的表格屬性來啟用Z-order聚類別。

設定Z-order聚類別

以下是一個範例，展示瞭如何為yellow_taxi_transformed資料表組態Z-order聚類別：

import dlt

@dlt.table(
    name="yellow_taxi_transformed",
    comment="包含財務資料的計程車行程資料。",
    table_properties={
        "quality": "silver",
        "pipelines.autoOptimize.zOrderCols": "zip_code, driver_id"
    }
)

在這個範例中，我們指定了zip_code和driver_id兩個欄位作為Z-order聚類別的依據。

Z-order聚類別的工作原理

當執行日常維護任務時，DLT引擎會動態解析Z-order欄位，並對底層的Delta表執行Z-order命令：

OPTIMIZE yellow_taxi_transformed
ZORDER BY (zip_code, driver_id)

選擇Z-order欄位的考量

選擇合適的欄位進行Z-order聚類別非常重要。一般建議選擇1到3個欄位，最多不超過5個。選擇的欄位應該是數值型別的，並且具有較高的基數（cardinality）。

Z-order聚類別的優點

Z-order聚類別可以改善資料表的查詢效能，減少DLT引擎需要掃描的資料量。結合Hive-style的分割槽策略，可以進一步提升資料管線的效能。

使用刪除向量改善寫入效能

在更新資料表時，DLT引擎會重寫匹配的檔案，這可能導致效率低下。刪除向量（Deletion Vectors）是一種最佳化技術，可以改善寫入效能。

刪除向量的工作原理

刪除向量是一種特殊的資料結構，用於跟蹤在UPDATE或MERGE操作期間更新的行ID。刪除向量可以透過設定底層Delta表的表格屬性來啟用。

啟用刪除向量

可以在DLT資料表定義中設定enableDeletionVectors表格屬性來啟用刪除向量：

@dlt.table(
    name="random_trip_data_silver",
    comment="包含財務資料的計程車行程資料。",
    table_properties={
        "enableDeletionVectors": "true"
    }
)

刪除向量的優點

刪除向量可以改善寫入效能，減少不必要的資料重寫。結合Z-order聚類別，可以進一步提升資料管線的效能。

最佳化資料管線的擴充套件與效能

在處理大量資料和應對不可預測的處理需求時，最佳化資料管線的擴充套件性和效能至關重要。本章節將探討多種方法來提升資料管線的可擴充套件性，並介紹 Databricks Data Intelligence Platform 的多項強大功能。

資料儲存最佳化

表屬性組態

最佳化資料儲存的第一步是正確組態表屬性。以下是一個範例組態：

table_properties={
  "quality": "silver",
  "pipelines.autoOptimize.zOrderCols": "driver_id",
  "delta.enableDeletionVectors": "true"
}

內容解密：

  • "quality": "silver"：定義表的品質等級為銀級，用於區分不同品質要求的資料集。
  • "pipelines.autoOptimize.zOrderCols": "driver_id"：啟用自動最佳化功能，並指定 driver_id 作為 Z-order 聚類別的列，以最佳化查詢效能。
  • "delta.enableDeletionVectors": "true"：啟用刪除向量，加速更新和刪除操作。

Z-order 資料聚類別

Z-order 是一種資料聚類別技術，能夠將相關資料聚集在相同的檔案中，從而加快查詢速度和縮短管線處理時間。

刪除向量與 Predictive I/O

刪除向量（Deletion Vectors）不僅最佳化了更新和刪除操作，還與 Predictive I/O 一起使用深度學習和檔案統計資訊，準確預測符合更新條件的資料列位置，顯著減少掃描和重寫資料所需的時間。

無伺服器 DLT 管線

無伺服器 DLT（Delta Live Tables）管線是一種自動化管理計算資源的方式，能夠根據需求動態擴充套件或縮減資源。這種模式簡化了資料管線的維護工作，降低了成本，並提高了處理效率。

無伺服器 DLT 的優勢

  1. 自動化資源管理：無需手動選擇虛擬機器例項型別，Databricks 自動處理基礎設施組態。
  2. 成本可預測性：無伺服器計算的成本是固定的，便於預算管理。
  3. 簡化維護：減少了每條資料管線所需的組態工作，讓資料工程團隊能夠專注於業務邏輯變更和資料驗證。
  4. 彈性擴充套件：無伺服器 DLT 能夠快速擴充套件以應對需求峰值，並且已經與雲供應商協商好了例項限制，避免了手動申請資源限制的麻煩。

Enzyme 效能最佳化層

Enzyme 是專為無伺服器 DLT 管線設計的新型最佳化層，旨在透過動態計算成本模型來保持資料集的物化結果更新，從而降低 ETL（Extract, Transform, Load）的成本。Enzyme 能夠在多種 ETL 技術之間進行選擇，選出最具成本效益的方法。

Enzyme 的工作原理

  1. 成本模型計算：Enzyme 為不同的 ETL 技術建立成本模型，例如傳統的物化檢視、Delta 串流表等。
  2. 動態選擇最優方案：根據成本模型，Enzyme 在執行時動態選擇最有效和最具成本效益的 ETL 重新整理技術。

圖表翻譯： 此圖示展示了 Enzyme 如何評估並選擇最優的 ETL 技術來重新整理資料集。

使用Unity Catalog掌握湖倉資料治理

在現代資料架構中，湖倉（Lakehouse）已成為企業資料管理的核心。Databricks的Unity Catalog提供了一個集中式的資料治理解決方案，簡化了湖倉中的資料安全管理。本章將探討如何使用Unity Catalog實作有效的資料治理策略，包括啟用Unity Catalog、實施資料目錄、執行細粒度資料存取控制以及追蹤資料血緣。

湖倉中的資料治理挑戰

在湖倉實施中，通常會使用多個處理引擎來處理不同的使用案例。然而，每個處理引擎都有其自己的資料安全實作，這些不同的安全解決方案往往無法相互整合。這導致了在實施一致的全域性資料安全政策時面臨巨大的挑戰。確保湖倉中的資料完全且一致地受到保護和隱私，並且只授予正確的使用者存取許可權，是構建資料湖倉的至關重要的任務。

Unity Catalog簡介

Unity Catalog是一個集中式的資料治理解決方案，透過將工作區物件存取策略組織到單一的管理「玻璃窗格」中，簡化了湖倉中的資料安全。除了存取策略外，Unity Catalog還具有強大的稽核功能，允許管理員捕捉所有使用者對工作區物件的存取模式，從而觀察存取模式、工作區使用情況和跨所有Databricks工作區的計費模式。此外，Unity Catalog允許資料專業人員在組織內發現資料集、追蹤資料血緣、檢視實體關係圖、分享企劃的資料集以及監控系統的健康狀況。

Unity Catalog的主要優勢

  • 預設安全：一旦組織的資料進入Unity Catalog，就預設受到保護，除非資料管理員明確授予存取許可權，否則任何內部或外部程式都無法存取該資料。
  • 統一治理：Unity Catalog跨越湖倉的邊界，從一個工作區到另一個工作區，甚至超出Databricks工作區，對組織的資料實施單一的治理模型。

瞭解湖倉中的資料治理

圖5.1展示了Unity Catalog如何為組織的雲端資料提供單一、統一的治理層。

從過去的經驗中學習

在Unity Catalog之前，資料存取控制策略是透過一種稱為**表存取控制列表（ACLs）**的機制按工作區定義的。當這些機制正確實施時，表ACLs提供了一個強大的資料治理解決方案。然而，這種安全模型很快就出現了四個主要問題：

  1. 重複定義存取策略：需要在每個獨特的Databricks工作區中重複定義資料存取策略。
  2. 維護開銷：如果一個工作區中的資料存取策略發生變化，則需要更改所有工作區中的存取策略，從而導致不必要的維護開銷。

技術需求

要跟隨本章的內容，您需要具備以下技術需求：

  • Databricks工作區許可權，用於建立和啟動全用途叢集，以執行本章的配套筆記本。
  • 建議將您的Databricks使用者提升為帳戶管理員和元儲存管理員，以便佈署新的Unity Catalog元儲存並將其附加到現有的Databricks工作區。
  • 所有程式碼示例都可以從本章的GitHub儲存函式庫下載。

實作Unity Catalog

本章將指導您如何在現有的Databricks工作區上啟用Unity Catalog，實施資料目錄以進行資料發現，並執行細粒度資料存取控制。此外，還將介紹如何追蹤資料血緣，以確保資料來源的可信度。

啟用Unity Catalog

要在現有的Databricks工作區上啟用Unity Catalog，請遵循以下步驟：

  1. 建立Unity Catalog元儲存：使用Databricks CLI或UI建立新的Unity Catalog元儲存。
  2. 將元儲存附加到工作區：將建立的元儲存附加到現有的Databricks工作區。

實施資料目錄

資料目錄是Unity Catalog的一個關鍵功能，它允許您對資料資產進行編目和發現。要實施資料目錄，請遵循以下步驟：

  1. 建立目錄：使用Databricks CLI或UI建立新的目錄。
  2. 註冊資料資產：將您的資料資產註冊到建立的目錄中。

執行細粒度資料存取控制

Unity Catalog允許您在表、行和列級別執行細粒度資料存取控制。要執行細粒度存取控制，請遵循以下步驟：

  1. 定義存取策略：使用Unity Catalog定義細粒度的存取策略。
  2. 將策略應用於資料資產：將定義的存取策略應用於註冊的資料資產。

統一目錄（Unity Catalog）架構概述與資料治理

統一目錄（Unity Catalog）旨在解決 Databricks 工作區中的資料治理問題，實作跨工作區的端對端資料治理方案。該架構允許資料管理員在集中位置定義資料存取控制策略，並確保在整個組織中一致地應用這些策略，無論使用何種計算資源或處理引擎來與統一目錄中的資料集進行互動。

統一目錄的關鍵優勢

統一目錄提供了多項關鍵優勢，使其成為現代湖倉（lakehouse）架構中理想的資料治理解決方案：

  • 預設安全：使用者無法在未經授權的情況下從任何計算資源讀取資料，除非使用啟用了統一目錄的叢集，並被授予存取特定資料集的許可權。
  • 管理員介面友好：統一目錄緊密整合 ANSI SQL，允許管理員使用熟悉的資料函式庫物件（如目錄、資料函式庫、表、函式和檢視）來表達資料存取許可權。
  • 資料發現：統一目錄允許資料管理員為資料集新增描述性後設資料，從而方便組織內使用者搜尋和發現可用的資料集。
  • 強大的稽核功能：統一目錄自動捕捉使用者級別的存取模式和資料操作，允許管理員檢視和稽核使用者與湖倉中資料的互動行為。
  • 資料血緣追蹤：統一目錄透過其強大的資料血緣 API 和系統表，使追蹤表格和列如何從上游來源生成的過程變得簡單。

統一目錄啟用的叢集型別

在啟用了統一目錄的工作區中，使用者可以使用三種型別的叢集：

  • 單使用者叢集：僅允許單個使用者或服務主體在該型別的叢集上執行 notebook 單元格或工作流程。該型別的叢集支援多種語言，包括 Scala、Java、R、Python 和 SQL。
  • 分享叢集：多個使用者或服務主體可以在該型別的叢集上執行 notebook 單元格或工作流程。然而，該型別的叢集僅限於執行 Python、SQL 和 Scala 工作負載。
  • 獨立叢集：單個使用者或多個使用者可以將 notebook 附加到該型別的叢集並執行 notebook 單元格。但是，該型別的叢集無法查詢在統一目錄中註冊的資料集。

統一目錄物件模型

瞭解統一目錄中的物件模型有助於使用者理解可以被統一目錄保護和治理的物件型別。統一目錄引入了三級名稱空間的概念，包括目錄、架構（或資料函式庫）和表。要參照統一目錄中的完全限定資料集，使用者需要提供目錄、架構和表的名稱。

三級名稱空間的優點

這種三級結構提供了更好的組織和管理能力，使得資料治理更加有效和精細。

Unity Catalog 的資料治理核心概念與實作

Unity Catalog 是 Databricks Lakehouse 架構中的核心資料治理解決方案，提供完整的資料安全與管理功能。本章節將探討 Unity Catalog 的物件模型、啟用流程以及身分識別聯盟的實作方法。

Unity Catalog 物件模型解析

Unity Catalog 的物件模型設計旨在組織與管理不同型別的資料資產，主要包含以下幾個層級：

資料組織相關物件

  1. Metastore：Unity Catalog 的實體實作，一個雲端區域最多隻能包含一個 Metastore。
  2. Catalog：頂層容器，用於組織多個 Schema 物件。
  3. Schema：第二層容器，可包含多個資料表、檢視、函式、模型和 Volume。
  4. Table：具備定義結構的資料集，以行列形式組織。
  5. View：根據查詢結果的虛擬資料表，唯讀且無法進行 DML 操作。
  6. Model：使用 MLflow 註冊的機器學習模型。
  7. Function：自定義函式，通常包含複雜的業務邏輯。
  8. Volume：用於儲存結構化、半結構化或非結構化資料的儲存位置。

外部資料存取相關物件

  1. Connection：用於存取外部關聯式資料函式庫或資料倉儲的唯讀連線。
  2. Storage Credential：存取雲端儲存位置的身份驗證憑證。
  3. External Location：指向 Databricks 管理根儲存位置以外的雲端儲存位置。

Delta Sharing 相關物件

  1. Provider：資料提供者，將多個資料集組織成 Share 供收件者使用。
  2. Share：邏輯上的一組分享資料集，可被授權給收件者。
  3. Recipient：資料收件者，可查詢 Share 中的資料集。

在現有 Databricks 工作區啟用 Unity Catalog

對於 2023 年 11 月後在 AWS 或 Azure 建立的工作區，Unity Catalog 預設已啟用。對於舊有工作區，需手動佈署 Metastore 並繫結工作區：

  1. 登入帳戶控制檯並建立新的 Metastore。
  2. 指定 Metastore 名稱、區域和預設儲存路徑。
  3. 將 Metastore 指派給目標工作區。

重點注意事項

  • 一旦啟用 Unity Catalog 便無法停用，但仍可將資料遷移回 HMS 實作。
  • 需為每個雲端區域佈署一個 Metastore。

身分識別聯盟實作

啟用 Unity Catalog 後，身分識別聯盟功能也隨之啟用，管理員可集中管理使用者身分與許可權，確保 Lakehouse 環境中的資料存取安全。

身分識別聯盟的優勢

  1. 統一的身分管理機制
  2. 跨工作區的身分一致性
  3. 更精細的存取控制
圖表翻譯：

此圖示展示了 Unity Catalog 的主要物件模型及其相互關係，包括 Metastore、Catalog、Schema 等核心元件，以及 Connection、Storage Credential 等外部存取相關物件。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title DLT資料表效能最佳化與UnityCatalog治理

package "機器學習流程" {
    package "資料處理" {
        component [資料收集] as collect
        component [資料清洗] as clean
        component [特徵工程] as feature
    }

    package "模型訓練" {
        component [模型選擇] as select
        component [超參數調優] as tune
        component [交叉驗證] as cv
    }

    package "評估部署" {
        component [模型評估] as eval
        component [模型部署] as deploy
        component [監控維護] as monitor
    }
}

collect --> clean : 原始資料
clean --> feature : 乾淨資料
feature --> select : 特徵向量
select --> tune : 基礎模型
tune --> cv : 最佳參數
cv --> eval : 訓練模型
eval --> deploy : 驗證模型
deploy --> monitor : 生產模型

note right of feature
  特徵工程包含：
  - 特徵選擇
  - 特徵轉換
  - 降維處理
end note

note right of eval
  評估指標：
  - 準確率/召回率
  - F1 Score
  - AUC-ROC
end note

@enduml

圖表翻譯： 此圖示呈現了 Unity Catalog 的物件層級結構，從 Metastore 到 Table、View 等不同型別的資料資產，並展示了外部資料存取相關物件的關聯性，有助於理解 Unity Catalog 的整體架構與功能模組。

統一目錄（Unity Catalog）中的資料治理精要

集中式身份管理

在 Databricks 平台上，使用者管理曾經是在各個工作區內部進行的。統一目錄（Unity Catalog）將使用者管理集中到單一的治理面板——帳戶控制檯。這使得管理員可以在帳戶層級定義使用者及其許可權，從而簡化跨多個工作區的身份角色和許可權管理。

在統一目錄之前，工作區管理員需要從身份提供者（如 Okta、Ping 或 Azure Active Directory (AAD)）同步組織身份。統一目錄透過跨域身份管理系統（SCIM）在帳戶層級同步身份，並將這些身份同步到適當的工作區，這一過程稱為身份聯合。這使得組織可以在其內部身份提供者中繼續管理身份，同時確保更改自動傳播到各個 Databricks 工作區。

身份聯合在統一目錄中的運作

在 Databricks 資料智慧平台中，「管理員」一詞涵蓋了多種角色。讓我們來看看不同的管理角色及其在啟用統一目錄的工作區中的許可權級別：

  • 帳戶擁有者：最初開通 Databricks 帳戶的個人。預設情況下，此使用者將擁有存取帳戶控制檯的許可權，並將被新增為帳戶管理員和工作區管理員。
  • 帳戶管理員：具有存取帳戶控制檯許可權的強大使用者，可以進行帳戶層級的更改，如佈署新的統一目錄 Metastore、進行網路組態更改，或將使用者、群組和服務主體新增到工作區。此使用者有權授予其他帳戶管理員和 Metastore 管理員。
  • Metastore 管理員：具有進行 Metastore 層級更改許可權的管理使用者，如更改目錄所有權、授予使用者建立或刪除新目錄的許可權，或組態透過 Delta Sharing 協定共用的新資料集。此使用者無權存取帳戶控制檯。
  • 工作區管理員：具有進行工作區層級組態更改許可權的管理使用者，包括建立叢集策略和例項池、建立新的叢集和 DBSQL 倉函式庫，或組態工作區外觀設定。此使用者無權存取帳戶控制檯。

資料探索與目錄化

資料標籤的使用

資料標籤是一種有用的資料目錄結構，能夠讓資料管理員將描述性後設資料與資料集和其他可安全存取的物件（如目錄、卷或機器學習模型）相關聯。在 Unity Catalog 中，可以對以下資料物件新增標籤：目錄、資料函式庫、表格、卷、檢視和機器學習模型。

讓我們來看一個例子，如何對現有的計程車行程資料集應用描述性標籤，使其更容易被組織中的使用者搜尋、發現和使用。在 Unity Catalog 中，可以透過多種方法將標籤新增到表格中。最簡單的方法是直接透過 Databricks 資料智慧平台中的 Catalog Explorer UI 進行操作。

-- 在 Unity Catalog 中為 yellow_taxi_raw 資料集新增標籤
ALTER TABLE default.yellow_taxi_raw SET TAGS ('sensitivity', 'confidential', 'owner', 'data_team');

內容解密：

上述 SQL 陳述式用於在 Unity Catalog 中為 yellow_taxi_raw 資料集新增標籤。其中，'sensitivity' 和 'confidential' 表示資料的敏感性，而 'owner' 和 'data_team' 則表示資料的所有者。這些標籤可以幫助使用者更好地搜尋和理解資料集的內容。

圖表說明

此圖示顯示瞭如何在 Catalog Explorer 中為資料集新增標籤。

圖表翻譯： 此圖示展示了在 Catalog Explorer 中為 yellow_taxi_raw 資料集新增標籤的過程。使用者可以透過點選「Add tags」按鈕來新增標籤，並以鍵值對的形式輸入標籤內容。這使得資料集更容易被搜尋和理解。

使用統一目錄進行資料治理的最佳實踐

在實施統一目錄時，組織應遵循以下最佳實踐：

  • 集中式身份管理：利用統一目錄的集中式身份管理功能，簡化跨多個工作區的身份角色和許可權管理。
  • 資料標籤和目錄化：使用資料標籤和目錄化功能，使資料集更容易被搜尋、發現和使用。
  • 嚴格的存取控制：實施嚴格的存取控制，確保只有授權使用者才能存取敏感資料。
玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。