Databricks 資產包(DAB)提供一種結構化方法,用於封裝和佈署 Databricks 工作流程、DLT 管線等資源。透過 YAML 組態檔案定義資源和目標環境,開發者可以輕鬆管理不同環境的佈署,並利用 Databricks CLI 進行版本控制和自動化佈署。DAB 支援開發和生產兩種模式,並可透過 U2M 和 M2M 驗證方式與 Databricks 工作區互動。此外,DAB 也能與 GitHub Actions 整合,實作 CI/CD 流程自動化,簡化跨團隊協作和程式碼佈署流程,提升開發效率。

Databricks 資產包(DAB)簡介

Databricks 資產包(DAB)是一種用於簡化資料管線佈署的工具。在本章中,我們將探討 DAB 的基本概念、組態檔案的結構,以及如何使用 DAB 來佈署和管理 Databricks 資源。

DAB 組態檔案結構

DAB 組態檔案通常採用 YAML 格式,並包含三個主要部分:bundleresourcestargets

Bundle 部分

此部分包含有關當前 DAB 的高階資訊,例如其名稱。

Resources 部分

此部分定義了新的 Databricks 工作流程,包括一個單一的筆記本任務,該任務將在現有的叢集上執行。

resources:
  job:
    name: hello_dab_world
    tasks:
      - task_key: notebook_task
        existing_cluster_id: <cluster_id>
        notebook_task:
          notebook_path: ./src/hello_dab_world.py

Targets 部分

此部分指定了目標 Databricks 工作區的資訊,包括工作區的主機 URL。

targets:
  dev:
    default: true
    workspace:
      host: https://<workspace_name>.cloud.databricks.com

佈署模式

DAB 組態檔案支援兩種佈署模式:開發模式和生產模式。

開發模式

在開發模式下,所有資源都會被標記為開發中,並且會暫停所有工作流程的排程,以便進行臨時執行。

targets:
  dev:
    default: true
    mode: development
    compute_id: <cluster_id>
    workspace:
      host: https://<workspace_name>.cloud.databricks.com

生產模式

在生產模式下,資源不會被標記為開發中,並且會驗證資源是否正確組態,例如確保所有 DLT 管道都已設定為生產模式。

使用 Databricks CLI 進行佈署

DAB 完全依賴 Databricks CLI 工具來建立、佈署和管理資源包。要使用 DAB,需要安裝版本 0.218.0 或更高版本的 Databricks CLI。

驗證 Databricks CLI 版本

databricks --version

檢視 bundle 命令的手冊頁面

databricks bundle --help

身份驗證

DAB 使用 OAuth 令牌進行身份驗證。有兩種型別的 OAuth 身份驗證可用:使用者到機器(U2M)身份驗證和機器到機器(M2M)身份驗證。

使用者到機器(U2M)身份驗證

U2M 身份驗證涉及使用者透過網頁瀏覽器登入以生成 OAuth 令牌。這種身份驗證方式適合於開發場景。

databricks auth login --host <workspace-url>

切換不同的 Databricks 工作區

databricks bundle deploy --profile TEST_ENV

利用 Databricks Asset Bundles 簡化資料管線佈署

Databricks Asset Bundles(DABs)提供了一種結構化和可重複使用的方法來管理和佈署 Databricks 資源。透過 DABs,您可以將 Databricks 工作區中的資源(如 DLT 管線、作業和筆記本)定義為程式碼,並使用 CLI 或 CI/CD 工具進行佈署。

機器對機器驗證

在生產環境中,建議使用機器對機器(M2M)驗證,因為它支援完全自動化的 CI/CD 工作流程,並且與版本控制系統(如 GitHub、Bitbucket 和 Azure DevOps)相容。M2M 驗證需要使用服務主體來產生 OAuth 令牌,並將其用於自動化建置和佈署工具中。

服務主體提供了比使用使用者或群組更高的安全性,因為它們只允許 API 存取 Databricks 資源。要使用 M2M 驗證,需要由 Databricks 帳戶管理員建立服務主體並產生 OAuth 令牌。然後,可以使用該令牌填充環境變數,如 DATABRICKS_HOSTDATABRICKS_CLIENT_IDDATABRICKS_CLIENT_SECRET

初始化資產包

DABs 提供了專案範本,可以快速建立具有預定義設定的新資產包。範本包含了常用 Databricks 專案的預定義構件和設定。例如,可以使用以下命令初始化本地 DAB 專案:

$ databricks bundle init

該命令會提示您選擇 DAB 範本。目前,DABs 提供了四個範本:default-pythondefault-sqldbt-sqlmlops-stacks

實作練習:佈署您的第一個 DAB

在本實作練習中,我們將建立一個根據 Python 的資產包,並佈署一個簡單的 Databricks 工作流程,該流程執行 DLT 管線。

首先,建立一個新的目錄來存放專案:

$ mkdir –p ~/chapter9/dabs/
$ cd ~/chapter9/dabs

接下來,使用 U2M 驗證產生新的 OAuth 令牌:

$ databricks auth login

然後,使用 Databricks CLI 初始化一個空的 DAB 專案:

$ databricks bundle init

選擇 default-python 範本,並輸入有意義的專案名稱,如 my_first_dab。在提示是否包含範例 DLT 管線時選擇 Yes,並在提示是否新增範例 Python 程式函式庫時選擇 No

程式碼初始化

# dlt_pipeline.ipynb 中的程式碼片段
import dlt

@dlt.table
def nyc_taxi_raw():
    return spark.read.format("json").load("dbfs:/databricks-datasets/nyctaxi/sample/json/")

@dlt.table
def filtered_taxi_data():
    return dlt.read("nyc_taxi_raw").filter(dlt.col("fare_amount") < 30)

內容解密:

上述程式碼定義了兩個資料集:nyc_taxi_rawfiltered_taxi_data。第一個資料集讀取 NYC Taxi 資料集中的原始 JSON 檔案,而第二個資料集則過濾出 fare_amount 小於 30 的資料列。

探索生成的 DAB 專案

使用您喜歡的程式碼編輯器(如 VS Code)開啟專案目錄:

$ cd ./my_first_dab
$ code .

DAB 專案結構

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Databricks資產包簡化資料管線佈署

package "安全架構" {
    package "網路安全" {
        component [防火牆] as firewall
        component [WAF] as waf
        component [DDoS 防護] as ddos
    }

    package "身份認證" {
        component [OAuth 2.0] as oauth
        component [JWT Token] as jwt
        component [MFA] as mfa
    }

    package "資料安全" {
        component [加密傳輸 TLS] as tls
        component [資料加密] as encrypt
        component [金鑰管理] as kms
    }

    package "監控審計" {
        component [日誌收集] as log
        component [威脅偵測] as threat
        component [合規審計] as audit
    }
}

firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成

@enduml

圖表翻譯: 此圖示呈現了 DAB 專案的結構,包括 src 目錄、resources 目錄和 databricks.yml 檔案。src 目錄包含了 DLT 管線定義,而 resources 目錄則包含了資源定義檔案。databricks.yml 檔案是 DAB 的主要進入點,定義了要佈署的資源和目標工作區資訊。

利用 Databricks 資產包簡化資料管道佈署

Databricks 資產包(DAB)提供了一種簡化資料管道和其他 Databricks 資源佈署的方法。在本文中,我們將透過一個實作練習來建立第一個 DAB 並將其佈署到開發工作區。

設定 DAB 專案

首先,我們需要設定 databricks.yml 檔案以定義 DAB 專案。移除 targets 對映下的所有區段,除了 dev 區段。確保 dev 目標指向正確的開發工作區。您的 databricks.yml 檔案應類別似於以下內容:

bundle:
  name: my_first_dab
  include:
    - resources/*.yml
targets:
  dev:
    mode: development
    default: true
    workspace:
      host: https://<workspace_name>.cloud.databricks.com

儲存對 databricks.yml 檔案的更改並傳回終端機視窗。使用 Databricks CLI 執行 validate 命令以驗證對 DAB 專案的更改:

$ databricks bundle validate

佈署 DAB 到開發工作區

現在,執行以下命令以將 DAB 佈署到開發工作區:

$ databricks bundle deploy

Databricks CLI 將解析 DAB 定義並將資源佈署到開發目標。登入開發工作區並驗證是否已建立標題為 [dev <username>] my_first_dab_job 的新工作流程,且您的 Databricks 使用者被列為擁有者。

測試佈署

執行以下命令以啟動新工作流程的執行並觸發 DLT 管道的更新:

$ databricks bundle run

您可能會被提示選擇要執行的資源。選擇 my_first_dab_job。如果成功,您應該會看到 CLI 的確認訊息,指出工作流程正在執行。

銷毀資源

如果需要從目標工作區取消佈署資源,可以使用 destroy 命令:

$ databricks bundle destroy

簡化跨團隊協作與 GitHub Actions

在生產場景中,您將與組織內的團隊成員協作,以撰寫資料管道和其他 Databricks 資源。DAB 可以輕鬆整合到 CI/CD 管道中。讓我們看看如何使用 GitHub Actions 自動佈署對程式碼儲存函式庫主要分支的更改,並自動將資源更改佈署到生產 Databricks 工作區。

設定 GitHub Actions 環境

.github 資料夾中建立一個新的私有資料夾,並在其中建立另一個子資料夾 workflows。在此資料夾中,建立一個新的 YAML 檔案 dab_deployment_workflow.yml

組態 GitHub Action

在 YAML 檔案中,新增基本結構以定義 GitHub Actions 工作流程。指定當核准的提取請求合併到主要分支時,應執行 CI/CD 管道。

name: "DABs in Action"
on:
  push:
    branches:
      - main

定義作業

定義一個作業以複製 GitHub 儲存函式庫、下載 Databricks CLI,並將 DAB 佈署到目標 Databricks 工作區。

jobs:
  bundle-and-deploy:
    name: "DAB Deployment Job"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: databricks/setup-cli@main
      - run: databricks bundle deploy --target prod
        working-directory: ./dabs
        env:
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_SERVICE_PRINCIPAL_TOKEN }}

圖表翻譯:

此圖示展示了使用 GitHub Actions 自動佈署 Databricks 資產包的流程。首先,開發人員將更改推播到 GitHub 儲存函式庫的主要分支。GitHub Actions 工作流程被觸發,自動複製儲存函式庫、下載 Databricks CLI,並將 DAB 佈署到生產 Databricks 工作區。

圖表翻譯: 此圖示呈現了一個自動化 CI/CD 管道的程式,該管道利用 GitHub Actions 將 Databricks 資產包佈署到生產環境。主要步驟包括程式碼推播、GitHub Actions 工作流程觸發、自動佈署到 Databricks 工作區等關鍵過程。

詳細說明:

  1. 程式碼推播:開發人員將更改推播到 GitHub 儲存函式庫的主要分支。
  2. GitHub Actions 工作流程觸發:推播事件觸發了預先設定的 GitHub Actions 工作流程。
  3. 自動佈署:工作流程自動執行一系列步驟,包括複製儲存函式庫、下載 Databricks CLI,並使用指定的驗證令牌將 DAB 佈署到生產 Databricks 工作區。

透過這種自動化流程,團隊可以更快速地迭代開發和佈署 Databricks 資源,從而提高整體的開發效率和生產力。

使用 GitHub Actions 簡化跨團隊協作的實作練習

在本章中,我們將探討如何利用 Databricks Asset Bundles(DABs)和 GitHub Actions 來自動化佈署 Databricks 資源,並實作跨團隊協作的簡化。我們將介紹如何建立一個 CI/CD 管道,以自動化測試和佈署 Databricks 工作流程。

設定 GitHub Actions 工作流程

首先,我們需要在 GitHub Actions 中建立一個新的工作流程檔案。這個檔案將定義當我們的 GitHub 儲存函式庫中有新的推播(push)或提取請求(pull request)時,應該執行的步驟。

name: Databricks CI/CD Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  bundle-and-deploy:
    name: "Deploy DAB to Databricks Workspace"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: databricks/setup-cli@main
      - run: databricks bundle deploy
        working-directory: ./dabs
        env:
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_SERVICE_PRINCIPAL_TOKEN }}

內容解密:

  • name: 定義了 GitHub Actions 工作流程的名稱。
  • on: 指定了觸發工作流程的事件,例如推播到 main 分支或對 main 分支的提取請求。
  • jobs: 定義了一個名為 bundle-and-deploy 的作業,該作業負責佈署 DAB 到 Databricks 工作區。
  • steps: 包含了執行作業所需的步驟,例如簽出程式碼、設定 Databricks CLI 以及佈署 DAB。
  • working-directory: 指定了執行 databricks bundle deploy 命令的工作目錄。
  • env: 設定了環境變數 DATABRICKS_TOKEN,該變數儲存了用於驗證 Databricks 工作區的服務主體令牌。

測試工作流程

為了測試我們的工作流程,我們需要在 GitHub Actions 工作流程檔案中新增一個新的作業,該作業將觸發我們之前建立的 Databricks 工作流程。

run-workflow:
  name: "Test the deployed pipeline workflow"
  runs-on: ubuntu-latest
  needs:
    - bundle-and-deploy
  steps:
    - uses: actions/checkout@v3
    - uses: databricks/setup-cli@main
    - run: databricks bundle run my_first_dab_job
      working-directory: ./dabs
      env:
        DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_SERVICE_PRINCIPAL_TOKEN }}

內容解密:

  • run-workflow: 定義了一個新的作業,該作業負責測試佈署的管道工作流程。
  • needs: 指定了該作業依賴於 bundle-and-deploy 作業的完成。
  • steps: 包含了執行作業所需的步驟,例如簽出程式碼、設定 Databricks CLI 以及執行 Databricks 工作流程。

版本控制和維護

DABs 使我們能夠輕鬆地將變更佈署到不同的環境中,並記錄這些變更來自特定的儲存函式庫版本。我們可以在 DAB 組態檔案中指定儲存函式庫 URL 和分支名稱,以註解佈署到目標 Databricks 工作區的不同版本的程式碼函式庫。

bundle:
  name: new-feature-dab
  git:
    origin_url: https://github.com/<username>/<repo_name>
    branch: my_experimental_feature_br

內容解密:

  • bundle: 定義了 DAB 的組態。
  • git: 指定了儲存函式庫的 URL 和分支名稱。

在生產環境中監控資料管道

在前面的章節中,我們學習瞭如何使用 Databricks Data Intelligence Platform 建置、組態和佈署資料管道。為了完善湖倉(lakehouse)的資料管道管理,在本文的最後一章,我們將探討在生產環境中監控資料管道的關鍵任務。我們將學習如何利用 Databricks Data Intelligence Platform 的全面監控技術來追蹤管道健康狀況、管道效能和資料品質等。

資料管道監控簡介

資料管道監控是確保資料管道穩定運作和及時發現問題的關鍵步驟。Databricks Data Intelligence Platform 提供了一系列工具和功能,幫助使用者監控資料管道的健康狀況、效能和資料品質。

管道健康和效能監控

管道健康和效能監控是確保資料管道穩定運作的重要環節。Databricks Data Intelligence Platform 提供了以下功能來幫助使用者監控管道健康和效能:

  • 警示功能:使用者可以設定警示,以便在資料管道出現問題時及時收到通知。
  • 事件日誌:使用者可以檢視資料管道的事件日誌,以瞭解管道的執行情況和錯誤資訊。
  • Lakehouse Monitoring:使用者可以使用 Lakehouse Monitoring 功能來測量資料管道的統計指標,例如資料處理量、處理時間等。

資料品質監控

資料品質監控是確保資料管道輸出資料準確可靠的重要環節。Databricks Data Intelligence Platform 提供了以下功能來幫助使用者監控資料品質:

  • 資料驗證:使用者可以設定資料驗證規則,以確保資料管道輸出資料的準確性和完整性。
  • 資料剖析:使用者可以對資料進行剖析,以瞭解資料的分佈、模式和異常情況。

生產環境故障解決的最佳實踐

在生產環境中,故障解決是確保資料管道穩定運作的重要環節。以下是一些最佳實踐,可以幫助使用者及時發現和解決故障:

  • 定期檢查:使用者應該定期檢查資料管道的健康狀況和效能,以及時發現潛在問題。
  • 警示設定:使用者應該設定警示,以便在資料管道出現問題時及時收到通知。
  • 故障排除:使用者應該具備故障排除的能力,以便及時解決故障。

設定Webhook警示的實作練習

在本文中,我們將進行一個實作練習,示範如何設定 Webhook 警示,以便在作業執行時間過長時及時收到通知。

練習步驟

  1. 登入 Databricks 工作區,並導航到「Jobs」頁面。
  2. 選擇要設定的作業,並點選「Edit」按鈕。
  3. 在「Notifications」部分,點選「Add notification」按鈕。
  4. 選擇「Webhook」作為通知型別,並輸入 Webhook 的 URL 和其他相關資訊。
  5. 設定警示條件,例如作業執行時間過長等。
  6. 儲存變更並測試警示功能。