ETL技術規范ETL設計規范ETL設計規范主要應用于ETL編碼的前期工作。由于ETL全過程是面向數據的，主要工作為數據的抽取（Extract）、轉換（Transform）、裝載（Loading），正確界定所涉及到的數據范圍和應當應用的轉換邏輯對于后續的編碼工作非常重要，這些數據關系的確定，我們稱之為Mapping（數據映射）。正確定義數據映射關系是ETL成功實施的前提，一個完善的Mapping應該包含以下幾個部分：源數據集屬性此部分應該詳細描述數據源的相關屬性，包括：實體名稱——含數據來源名稱（DSN）、所有者等信息；字段名稱——英文名稱；字段簡述——中文名稱，如為參數信息應該有相關取值解釋，如性別字段（1：男；2：女；0：不詳）類型——字段類型，含長度和精度信息；非空屬性——字段是否可以為空；目標數據集屬性此部分應該詳細描述目標數據集的相關屬性，包括：實體名稱——含數據來源名稱（DSN）、所有者等信息；字段名稱——英文名稱，建議根據字段含義來命名，而不是簡單用拼音來定義字段（此部分由負責設計數據集的人員控制）；字段簡述——中文名稱，對于保留字段應該給出默認值；類型——字段類型，含長度和精度信息；非空屬性——字段是否可以為空；命名規范作業命名規范ETL是一個復雜的工作，數據倉庫的建設一般會花費70％以上的工作量在ETL上面，而且這是一個細致活，任何一點小的錯誤都有可能造成后續工作的出錯和失敗；此外，數據倉庫需要不斷的更新維護，相應的ETL程序也需要進行相關的更新維護，所花費的成本也很大。一個好的命名規范，能夠使ETL的程序更清晰易懂，很好地避免了開發過程中出錯；同時更好的可讀性，也極大地減低了ETL程序的更新維護成本。作業命名規則：[JOBTYPE][DESCRIPTION][SEQNUM]JOBTYPE：作業類型DESCRIPTION：有效的描述信息SEQNUM：作業的編號。由于一定的原因，有可能需要拆分作業數據多次加載數據，這個編號就可以區分加載。如果一次加載可以成功的話這個編號就不需要了。作業內部命名規范對于作業內部命名，應該遵循代碼的可讀性與可傳遞性原則，命名規則：[Function][Description]Function：表示用途，Ex:抽取，Create:創建，Ld:裝載，Lookup:查找等Description：有意義的描述，比如數據庫表名，文件名等。作業注釋規范ETL開發過程往往要經歷一個較長時間段，為了便于團隊開發和后期維護，除開發設計文檔要齊全外，還應該在作業設計界面中適當加注釋信息，主要包括作業功能說明、所屬模塊、開發時間、開發人員等信息。結構規范作業目錄組織結構對于ETLPROJECT而言，我們需要劃分清晰的目錄結構，根據一定的規則將作業組織起來，這樣無論是對ETL設計人員，運行人員，維護人員，都有很大的幫助。目錄結構劃分遵循以下原則：體現作業的依賴關系。體現作業功能。獨立放置二次開發作業。模塊化結構ETL按照處理邏輯分為E階段（Extract）、T階段（Transformer）和L階段（Loading）。E、T、L階段可能分處不同的服務器上，需要跨網絡運行，他們之間的配置情況可能存在較大的差異，而多數ETL設計的處理機制是串行運行機制，基于數據行處理。如果E、T、L的過程同時運行，那么整體的處理能力應該是三個環節中效率最低的那個環節的處理水平。如果我們將三個環節的設計分開，實行模塊化流程處理，即E環節、T環節、L環節均設計成可獨立運行的模塊，那么在整個處理過程中，將可以最大限度發揮功效，不會因為串性處理機制而相互制約。另外，模塊化的流程設計，對于開發階段的調試以及維護階段的出錯處理都提供了良好的輔助作用。ETL維護規范日志檢查日志文件報告ETL提供日志監測和報告功能。報告分匯總報告和詳細報告。匯總報告報告內容：作業總數，WARNING作業數，成功作業數，失敗作業數，開始時間，結束時間等詳細報告報告內容：作業名稱，開始時間，結束時間，運行狀態等作業狀態排查在ETL管理控制臺上，可點擊進入查看作業更為詳細的狀態及出錯信息，以便于維護更正。出錯處理即使是經過嚴格測試的程序，在實際運行中仍然會因為種種原因而導致出錯，根據ETL的處理邏輯，我們將錯誤分為以下三類：抽取錯誤：簡稱E（Extract）類錯誤轉換錯誤：簡稱T（Transformer）類錯誤裝載錯誤：簡稱L（Loading）類錯誤E類錯誤這類錯誤發生在數據抽取階段。諸如數據庫連接故障、網絡資源不足等原因都可以導致此類故障。由于此類錯誤發生時，數據還處于原始狀態，未發生轉換，對目標數據集也未產生任何影響，理論上可以看做是ETL處理未開始，因此處理此類錯誤相對簡單，只需要排除故障原因后重新運行ETL處理即可。T類錯誤這類錯誤發生在數據轉換階段。引發原因較多，既有環境資源故障的可能，也有設計邏輯缺陷的可能。此類錯誤發生在ETL的中間階段，應根據實際故障原因進行處理。對于環境資源故障所引發的錯誤，只需要排除故障原因，重新運行ETL的T（Transformer）階段和L（Loading）階段即可。對于設計邏輯缺陷所引發的錯誤，處理相對復雜——首先要定位錯誤并修正程序，同時要明確該錯誤是否涉及到數據源的抽取邏輯，如果未涉及到，則在修正邏輯后重新運行T（Transformer）階段和L（Loading）階段程序即可；若邏輯錯誤與數據源相關，則需要重新運行包括E（Extract）階段在內的整個ETL處理。L類錯誤這類錯誤發生在數據裝載階段，除環境資源故障原因外，最大可能性是需要裝載到目標集的數據違反了目標數據集數據約束，如主鍵重復、非空字段出現空值、數據超長、類型不匹配等等。因環境資源故障（網絡故障等等）所引發的出錯，處理簡單，只需排除故障，將目標數據集恢復到裝載前狀態，重新運行L階段的處理即可。對于非環境資源所引發的問題，處理與T類錯誤類似：先定位原因，根據以往的經驗，問題多數發生在T階段，可能存在設計缺陷或者運行邏輯缺陷，需要對T部分的處理進行修正，并將目標數據集恢復到裝載前狀態，重新運行T階段和L階段的處理。在上一章“設計規范”里，我們強調了模塊化的流程設計，將E階段、T階段、L階段按流程分模塊化設計，其實不僅僅是為了解決系統資源瓶頸問題，同時也是為了方便出錯時進行處理。在發生T類和L類錯誤時，由于各處理階段設計相對獨立，對于不同階段的問題，只需要單獨運行與該階段相關的處理，而無須將所有處理過程都重新運行，大大減低重復運行的代價。備份、恢復與版本控制ETL系統的備份包括兩個部分，即ETL運行環境備份及數據庫的備份。運行備份是指為保證如果運行的ETL系統崩潰時可以通過備份的ETL系統繼續完成ETL的工作，為達到這個目的，應安裝兩臺ETL環境，并建立相同的配置，其中一臺處于運行狀態，而另一臺為待機狀態。每日在日常ETL完成后對運行環境的各文件進行備份，即將ETL的運行目錄轉儲到外掛磁盤或外部存儲介質。而數據庫的數據備份對于ETL非常重要，建議系統管理員每日做數據的完全備份，每天保留一個備份文件，建議至少保留7天。ETL系統的恢復相應也包括兩個部分，即運行恢復及數據恢復運行恢復是指當運行系統遇到嚴重故障如硬件故障、操作系統崩潰等無法及時修復時，啟用備份的運行系統繼續，通過將上一日備份的ETL環境恢復到待機系統，然后啟動待機系統運行日常ETL。數據庫恢復通常兩種情況下會用到，一種是數據庫系統本身出了故障需要重新安裝，這時需要將上一日備份的數據