將 DataOps 套用到 Azure Data Factory

適用於：Azure Data Factory Azure Synapse Analytics

提示

試用 Microsoft Fabric 中的 Data Factory，這是適用於企業的全方位分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告的所有項目。 了解如何免費開始新的試用 (部分機器翻譯)！

Azure Data Factory 是 Microsoft 位於雲端的資料整合和 ETL 服務。 這份白皮書將提供資料處理站中的 DataOps 指導方針。 這不是 CI/CD、Git 或 DevOps 的完整教學課程。 相反地，您能在其中找到資料處理站小組針對在服務中達成 DataOps 的指導方針，其中包含資料處理站部署最佳做法、處理站管理和治理的詳細實作連結參考。 本白皮書結尾有一個資源小節，其中包含教學課程的連結。

什麼是 DataOps？

DataOps 是資料組織針對共同作業資料管理實施的流程，旨在為決策者提供更快的價值。

Gartner 提供了明確的 DataOps 定義 (英文)：

DataOps 是共同作業資料管理做法，專注在改善整個組織中資料管理員和資料取用者間資料流程的通訊、整合和自動化。 DataOps 的目標是透過針對資料、資料模型和相關成品建立可預測的傳遞和變更管理，來以更快的速度傳遞價值。 DataOps 使用技術來將資料傳遞的設計、部署和管理自動化，同時搭配適當程度的治理，並使用中繼資料來改善動態環境中資料的可用性和價值。

如何在 Azure Data Factory 中達成 DataOps？

Azure Data Factory 為資料工程師提供以視覺為基礎的資料管線範例，以輕鬆建置雲端規模的資料整合和 ETL 專案。 Data Factory 依賴與成熟版本控制工具 (例如 GitHub 和 Azure DevOps) 以及更廣泛的 Azure 生態系統的原生整合，以提供許多內建功能來促進包括豐富共同作業、治理和成品關聯性的 DataOps。

具體來說，一旦您將自己的 GitHub 或 Azure DevOps 存放庫帶入資料處理站，服務就會針對常用命令提供直覺式的內建 UI 選項，例如認可、儲存成品和版本控制。 此服務也提供選項來提供 CI/CD 和程式碼簽入最佳做法，以保護實際執行環境的健全性和健康情況。

Azure Data Factory 中的「程式碼」

Azure Data Factory 中的所有成品，無論是管線、連結服務、觸發程序等，在視覺 UI 整合後方的 JSON 中都有對應的「程式碼」表示法。 這些成品會遵循 Azure Resource Manager 範本標準。 您可以透過按一下畫布右上方的括弧圖示來找到程式碼。 範例 JSON「程式碼」看起來像這樣：

即時模式和 Git 版本控制

每個處理站都具有單一事實來源：儲存在服務內的管線、連結服務與觸發程序定義。 此事實來源是管線執行所執行的內容，也能決定觸發程序的行為。 如果您處於即時模式，每次發佈時，都會直接修改單一事實來源。 下圖顯示即時模式中 [全部發佈] 按鈕的外觀。

對於處理個人專案的單一人員來說，即時模式可能會很方便，因為其允許開發人員看見其程式碼變更的立即影響。 不過，不建議處理實際執行層級工作專案的開發人員小組使用此功能。 其危險包括誤觸、意外刪除重要資源、發佈未經測試的程式碼等等。 處理任務關鍵性專案和平台時，請考慮引進 Git 存放庫，並在資料處理站中使用 Git 模式來簡化開發流程。 Git 模式的版本控制 (部分機器翻譯) 和閘道簽入功能，可協助您防止大部分 (甚至全部) 與直接使用即時模式相關聯的意外。

注意

在 Git 模式中，[發佈] 或 [全部發佈] 按鈕將會被取代為 [儲存] 或 [全部儲存]，而且您的變更會認可至您自己的分支 (而不是直接變更即時程式碼基底)。

設定 GitHub 和 Azure DevOps 整合

在 Azure Data Factory 中，強烈建議您將存放庫儲存在 GitHub 或 Azure DevOps 中。 此服務完全支援這兩種方法，而應該要選擇使用哪一種存放庫，則取決於您個別的組織標準。 一共有兩種方法可以設定新存放庫或是連線至現有的存放庫：使用 Azure 入口網站或從 Azure Data Factory Studio UI 建立

Azure 入口網站處理站建立

當您從 Azure 入口網站建立新的資料處理站時，預設的 Git 存放庫是 Azure DevOps。 您也可以選取 GitHub 作為存放庫，並設定存放庫設定。

從 Azure 入口網站，選取存放庫類型，然後輸入存放庫和分支名稱，以建立與 Git 原生整合的新處理站。

在組織中使用 Azure 原則強制 Git 的使用

在 Azure Data Factory 專案中使用 Git 是強烈建議的最佳做法。 即使您未實作完整的 CI/CD 流程，Git 與 ADF 的整合仍可讓您將資源成品儲存在您自己的沙箱環境 (Git 分支) 中，而您可以在其中獨立於處理站分支的其餘部分獨立測試變更。 您可以在組織的處理站中使用 Azure 原則來強制 Git 的使用 (部分機器翻譯)。

Azure Data Factory Studio

建立資料處理站之後，您也可以透過 Azure Data Factory Studio 連線至您的存放庫。 在 [管理] 索引標籤中，您會看到設定存放庫和存放庫設定的選項。

透過引導式流程，系統會引導您完成一系列步驟，以協助您輕鬆地設定並連線到您選擇的存放庫。 完全設定之後，您就可以開始進行共同作業，並將資源儲存至存放庫。

持續整合與持續傳遞 (CI/CD)

CI/CD 是程式碼開發的架構，其中會在變更經過各種階段 (例如開發、測試、預備等) 時對其進行檢查和測試。在變更經過每個階段的檢閱和測試之後，其最終會發佈至實際執行環境中的即時程式碼基底。

持續整合 (CI) 是每次當開發人員對您的程式碼基底進行變更時，都會進行自動測試及驗證的做法。 持續傳遞 (CD) 表示在持續整合測試成功之後，會將變更持續帶入下一個階段。

如先前簡短所述，Azure Data Factory 中的「程式碼」會採用 Azure Resource Manager 範本 JSON 的形式。 因此，經歷持續整合和傳遞 (CI/CD) 流程的變更是由對 JSON Blob 所進行的新增、刪除和編輯所組成。

Azure Data Factory 中的管線執行

在談到 Azure Data Factory 中的 CI/CD 之前，我們必須先討論服務如何執行管線。 在資料處理站執行管線之前，其會執行下列動作：

• 提取管線最新發佈的定義，以及其相關聯的資產，例如資料集、連結服務等。
• 將其編譯為動作；如果資料處理站最近曾加以執行，其會從快取的編譯中擷取動作。
• 執行管線。

執行管線需要下列步驟：

• 服務會擷取管線定義的時間點快照集。
• 在整個管線期間，定義不會變更。
• 即使您的管線長時間執行，其也不會受到在其啟動之後所做的後續變更影響。 如果您在執行期間將變更發佈至連結服務、管線等，這些變更並不會影響進行中的執行。
• 當您發佈變更時，在發佈後開始的後續執行會使用更新的定義。

在 Azure Data Factory 中發佈

在您部署管線時，無論您是使用 Azure 發行管線來將發佈自動化，還是使用 Resource Manager 範本進行手動部署，在後端，發佈都是針對每個成品對資料集 (部分機器翻譯)、連結服務 (部分機器翻譯)、管線 (部分機器翻譯) 與觸發程序 (部分機器翻譯) 所進行的一系列建立/更新作業。 其效果與直接進行底層 Rest API 呼叫相同。

這裡的動作會產生一些結果：

• 這些 API 呼叫都是同步的 (英文)，這表示呼叫只會在發佈成功/失敗的情況下傳回。 成品不會有部分部署的狀態。
• API 呼叫在很大程度上是循序的。 我們會嘗試平行處理呼叫，同時維護成品的引用相依性。 部署順序是連結服務 -> 資料集/整合執行階段 -> 管線 -> 觸發程序。 此順序可確保相依成品可以正確地參考其相依性。 例如，管線相依於資料集，因此資料處理站會在資料集之後部署管線。
• 連結服務、資料集等的部署會獨立於管線。 在某些情況下，資料處理站會在管線更新之前更新連結服務。 我們將在停止觸發程序的時機一節中討論這種情況。
• 部署不會從處理站刪除成品。 您必須針對每個成品類型明確呼叫刪除 API (管線 (部分機器翻譯)、資料集 (部分機器翻譯)、連結服務 (部分機器翻譯) 等) 來清除處理站。 例如，請參閱 Azure Data Factory 的部署後指令碼範例。
• 即使您未觸碰管線、資料集或連結服務，其仍會針對處理站叫用快速更新 API 呼叫。

發佈觸發程序

• 觸發程序具有兩種狀態：已啟動或已停止。
• 您無法對已啟動模式下的觸發程序做出變更。 在發佈任何變更之前，您必須停止觸發程序。
• 您可以對處於已啟動模式的觸發程序叫用建立或更新觸發程序 API (部分機器翻譯)。
  • 如果承載變更，API 就會失敗。
  • 如果承載保持不變，API 就會成功。
• 此行為會對停止觸發程序的時機具有深遠的影響。

停止觸發程序的時機

對於具有隨時都會啟動管線執行之即時觸發程序的實際執行資料處理站來說，若要在其中進行部署，我們總是會遇到一個問題：「我們是否應該停止這些觸發程序？」。

簡短的答案是：只有在下列幾個案例中，您才應該考慮停止觸發程序：

• 如果您要更新觸發程序定義，包括結束日期、頻率和管線關聯等欄位，則必須停止觸發程序。
• 如果您要更新即時管線中參考的資料集或連結服務，建議您停止觸發程序。 例如，如果您要輪替 SQL Server 的認證。
• 如果相關聯的管線擲回錯誤，並且發生失敗，造成您伺服器的負擔，您可以選擇停止觸發程序。

以下是針對停止觸發程序應考量的幾個要點：

• 如 Azure Data Factory 中的管線執行一節所述，當觸發程序啟動管線執行時，其會擷取管線、資料集、整合執行階段和連結服務定義的快照集。 如果管線在變更填入後端之前執行，觸發程序會以舊版啟動執行。 在大部分情況下，這應該不會有任何問題。
• 如在發佈觸發程序一節中所述。 當觸發程序處於已啟動狀態時，就無法加以更新。 因此，如果您需要變更觸發程式定義的相關詳細資料，請在發佈變更之前停止觸發程序。
• 如在 Azure Data Factory 中發佈一節中所述，對資料集或連結服務的修改會在管線變更之前發佈。 為了確保管線執行使用正確的認證，並與正確的伺服器通訊，建議您也停止相關聯的觸發程序。

準備「程式碼」變更

建議您針對提取要求遵循這些最佳做法。

• 每個開發人員都應該在自己的個別分支上工作，並在一天結束時，對存放庫的主要分支建立提取要求。 請參閱關於 GitHub (英文) 和 DevOps (部分機器翻譯) 中提取要求的教學課程。
• 當閘道管理員核准提取要求並將變更合併到主要分支時，CI/CD 流程就可以啟動。 有兩個建議的方法，可以在環境中促進變更：自動化和手動。
• 在您準備好啟動 CI/CD 管線時，您通常可以使用 Azure 管線發行 (部分機器翻譯) 來這麼做，或是使用這個來自 Azure Player 的開放原始碼公用程式 (英文) 對特定的個別管線進行部署。

自動化的變更部署

為了協助進行自動化部署，我們建議使用 Azure Data Factory 公用程式 npm 套件。 使用 npm 套件有助於驗證管線中的所有資源，並為使用者產生 ARM 範本。

若要開始使用 Azure Data Factory 公用程式 npm 套件 (英文)，請參閱持續整合和傳遞的自動發佈 (部分機器翻譯)。

手動的變更部署

將分支合併回 Git 存放庫中的主要協作分支之後，您可以手動將變更發佈至即時 Azure Data Factory 服務。 此服務會使用 [停用發佈 (從 ADF Studio)] 選項，針對從非開發處理站進行發佈提供 UI 控制。

選擇性部署

選擇性部署需要依賴 GitHub 和 Azure DevOps 一項稱為揀選的功能。 這項功能可讓您只部署特定變更，但不部署其他變更。 例如，一位開發人員已對多個管線進行變更，但對於今天的部署，我們可能只想要對其中一個管線部署變更。

請遵循 Azure DevOps 和 GitHub 的教學課程，以選取與您所需管線相關的認可。 請確定已揀選所有變更，包括對與管線相關聯的觸發程序、連結服務和相依性所做的相關變更。

一旦您揀選變更並合併到主要共同作業管線之後，您就可以開始針對建議的變更啟動 CI/CD 流程。 有關如何進行 Hotfix、揀選或利用外部架構進行選擇性部署的其他資訊，如本文自動化的測試一節所述。

單元測試

單元測試是開發新管線或編輯現有資料處理站成品之流程的重要部分，其著重於測試程式碼的元件。 Data Factory 允許使用管線偵錯功能，在管線和資料流程成品層級進行個別單元測試。

開發資料流程時，您將能夠使用資料預覽功能 (部分機器翻譯) 來取得每個個別轉換和程式碼變更的見解，以在將變更部署到實際執行環境之前先達成單元測試。

在 Azure Data Factory 中進行偵錯和單元測試時，服務會在 UI 中提供管線活動的即時和互動式反饋。

自動化測試

有數個可以搭配 Azure Data Factory 使用的工具可用於自動化的測試。 由於服務會將物件以 JSON 實體的形式儲存在服務中，因此使用開放原始碼 .NET 單元測試架構 NUnit 搭配 Visual Studio 可能會很方便。 請參閱針對 Azure Data Factory 設定自動化的測試 (英文) 一文，其中提供如何為您的處理站設定自動化單元測試環境的深入說明。 (特別感謝 Richard Swinbank 提供使用此部落格的權限。)

客戶也可以使用 PowerShell 或 AZ CLI 執行 TEST 管線，作為 CI/CD 流程中預先和後續部署步驟的一部分。

資料處理站的主要優勢在於其資料集的參數化。 這項功能可讓客戶使用不同的資料集來執行相同的管線，以確保他們的新開發符合所有來源和目的地需求。

Azure Data Factory 的其他 CI/CD 架構

如先前所述，內建 Git 整合可透過 Azure Data Factory UI 原生提供，包括合併、分支、比較和發行。 不過，Azure 社群中還有其他實用的 CI/CD 架構，可提供替代機制來提供類似的功能。 Azure Data Factory Git 方法是以 ARM 範本為基礎，而如 Kamil Nowinski 所建置的 ADFTools (英文) 之類的架構則採取不同的方法，並且會改為依賴您處理站中個別的 JSON 成品。 善用 Azure DevOps 且偏好在該環境中工作 (而非服務提供的現成 ARM 型的 UI 做法) 的資料工程師，可能會覺得這個架構比較適合他們，也比較適合用於如部分部署之類的常見案例。 此架構也可以在部署到具有執行中觸發程序狀態的環境時，簡化觸發程序的處理。

Azure Data Factory 中的資料治理

有效 DataOps 的其中一個重要層面是資料治理。 針對資料整合 ETL 工具，提供資料譜系和成品關聯性，可為資料工程師提供重要資訊，以了解下游變更的影響。 Data Factory 提供構成您處理站實作的內建相關成品檢視。

與 Microsoft Purview 的原生整合能進一步提供譜系、影響分析和資料目錄編寫。

Microsoft Purview 提供整合的資料治理解決方案，可協助您管理和治理內部部署、多重雲端和軟體即服務 (SaaS) 資料。 其可讓您透過自動資料探索、敏感性資料分類和端對端資料譜系，輕鬆地為資料態勢建立最新的全面性資料地圖。 這些功能可以讓資料取用者存取有價值且值得信任的資料管理。

透過與您 Purview 資料目錄的原生整合，資料處理站可讓您輕鬆地搜尋和探索資料資產，以用於您組織整個資料資產上的資料整合管線之中。

您可以使用 Azure Data Factory Studio 中的主要搜尋列來尋找您 Purview 目錄中的資料資產。

相關內容

• Azure Data Factory 中的自動發行 CI/CD (部分機器翻譯)
• Azure Data Factory 中的原始檔控制 (部分機器翻譯)
• 針對在資料處理站中使用 CI/CD 提供實用影片的 Azure Data Factory 影片庫 (英文)
• Git 中的 Hotfix 資料處理站 (部分機器翻譯)