執行 ETL 時如何處理源系統中的模式更改？

在將 ETL 作為 EDW 的一部分執行時，人們通常如何處理源系統中的模式更改？例如，當您正在操作的列消失並且您的 ETL 中斷時。

在將 ETL 作為 EDW 的一部分執行時，人們通常如何處理源系統中的模式更改？例如，當您正在操作的列消失並且您的 ETL 中斷時。

我想在被問到的相同抽象級別上回答這個問題。

使用 Informatica 的概念對像模型

由Source對象表示的表用於Mapping，它列舉所有必需的 Source 列（Ports）。當 Mapping 由Session執行時（作為Workflow的一部分），Mapping 將拋出有關缺少源埠的執行時錯誤。

使用 Kimball 的 ETL 子系統模型

看看Kimball的 The 38 Subsystems of ETL。無論您使用什麼 ETL 工具，您都將擁有以下子系統，它們在解決“可變源”問題方面發揮作用：

• 提取子系統應該擷取執行時錯誤。SELECT *幾乎從來都不是一個好主意。如果數據源的更改導致某些列/表消失，則應觸發錯誤/警告 - 您確實需要記錄/跟踪所有錯誤。看下一張。
• 錯誤事件跟踪。- 又名日誌系統。這很重要，但有時會被內部 ETL 解決方案忽略。ETL 的所有組件都應該能夠以統一的方式記錄不同嚴重程度的錯誤/警告。並且消息應該傳播給負責的 ETL 經理。最低限度：扁平的、類似系統日誌的日誌文件以及一些用於分類和電子郵件錯誤的腳本。
• 作業調度程序和/或工作流監視器。顯然，您將執行自動和/或手動 ETL 作業，並且您應該能夠收到有關錯誤的通知 - 以及查看目前和歷史作業結果，包括狀態、行數、最近作業的警告。
• 問題升級。. 您需要有一個有效的問題升級路徑，這不是技術問題，而是組織問題。從技術上講，發送一封標題為“EDW 工作流 001 失敗並出現 FATAL 錯誤（附加日誌）”的電子郵件通常就足夠了。關鍵是負責人和業務流程，這將推動這一點。

1. DDL 權限：GRANT Drop Table/column或Alter Table 任何可能影響 ETL 的更改對極少數選定的使用者。因此，任何更改都會通過適當的渠道，ETL 開發人員會提前知道。
2. 正確的錯誤處理：擷取錯誤、記錄錯誤並在一些錯誤程式碼中發送電子郵件
3. Select * Into Staging Table：此語法不需要列名。因此您可以圍繞它建構邏輯。不知道您的確切要求，如果可能的話使用暫存表。您可以每次都刪除和創建暫存表。

或者當 column not exists error is Catch輸入時Catch Block你可以這樣寫

Begin TRY
 --your usual ETL Logic
END TRY
BEGIN CATCH
if @@ErrorCode="XYZ"
Begin
Select * into TestStaging
--- Whatever your logic
-- Log Error
-- Shoot email
END
END CATCH

引用自：https://dba.stackexchange.com/questions/232772