ETL加載策略

ETL 數據加載機制概述

ETL 是數據抽取（Extract）、轉換（Transform）、加載（Load）的簡寫，它的功能是從數據源抽取出所需的數據，通過數據清洗和轉換，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中去，是構建數據倉庫最重要的一步。

在數據加載到數據庫的過程當中，分爲全量加載（更新）和增量加載（更新）。

• 全量加載：全表刪除後再進行數據加載的方式。
• 增量加載：目標表僅更新源表變化的數據。

全量加載從技術角度上說，比增量加載要簡單不少。通常只要在數據加載以前，清空目標表，再全量導入源表數據便可。可是因爲數據量，系統資源和數據的實時性的要求，不少狀況下咱們都須要使用增量加載機制。

增量加載難度在於必須設計正確有效的方法從數據源中抽取變化的數據以及雖然沒有變化，但受到變化數據影響的源數據，同時將這些變化的和未變化但受影響的數據在完成相應的邏輯轉換後更新到數據倉庫中。優秀的增量抽取機制不但要求 ETL 可以將業務系統中的變化數據按必定的頻率準確地捕獲到，同時不能對業務系統形成太大的壓力，影響現有業務，並且要知足數據轉換過程當中的邏輯要求和加載後目標表的數據正確性，同時數據加載的性能和做業失敗後的可恢復重啓的易維護性也是很是重要的考量方面。

增量抽取機制比較適用於如下特色的數據表：

• 數據量巨大的目標表。
• 源表變化數據比較規律，例如按時間序列增加或減小。
• 源表變化數據相對數據總量較小。
• 目標表須要記錄過時信息或者冗餘信息
• 業務系統能直接提供增量（delta）數據

若是每次抽取都有超過 1/4 的業務源數據須要更新，就應該考慮更改 ETL 的加載方法，由增量抽取改成全量抽取，另外全量抽取對於數據量較小，更新頻率較低的系統也比較適用。

ETL 數據增量加載機制：

ETL 增量加載在方式上主要包括：

• 系統日誌分析方式
• 觸發器方式
• 時間戳方式
• 全表比對方式
• 源系統增量（delta）數據直接或者轉換後加載

源表與目標表一對一增量更新

這類更新主要常見於生產庫與備份庫之間，或者是面對不一樣數據集市的數據分發業務。即源表和目標表的數據對應關係十分簡單，數據徹底相同或者是源表僅做部分數據過濾。

對於這種類型的增量更新，能夠採用系統日誌分析方式。

系統日誌分析方式

該方式經過分析數據庫自身的日誌來判斷變化的數據。關係型數據庫系統都會將全部的 DML 操做存儲在日誌文件中，以實現數據庫的備份和還原功能。ETL 增量抽取進程經過對數據庫的日誌進行分析，提取對相關源表在特定時間後發生的 DML 操做信息，就能夠得知自上次抽取時刻以來該表的數據變化狀況，從而指導增量抽取動做。

系統日誌分析方式優缺點

優勢：實現方式簡單。隔離性好，若是發生加載失敗，不會影響源表及其事務的級聯失敗。 

缺點：日誌表維護須要由OLTP系統完成，須要對OLTP系統業務操做程序做修改，記錄日誌信息。日誌表維護較爲麻煩，對原有系統有較大影響。

觸發器方式

觸發器增量抽取主要有 2 種方式：

• 直接進行數據加載
• 利用增量日誌表進行增量加載

直接進行數據加載方式是建立一個與源表結構相似的臨時表，而後建立一個三種類型的觸發器，分別對應 insert , update , delete 操做。每當源表有數據變更的時候，利用觸發器將變化的數據填入此臨時表表中。最後經過維護這個臨時表，在進行 ETL 過程的時候，將目標表中相應的數據進行修改。ETL 過程結束後，清空此臨時表。

利用增量日誌表進行增量加載則是不直接抽取源表數據，僅僅是將操做內容寫入一張增量日誌表裏（同時增量日誌表中抽取過的數據要及時被標記或刪除）。增量日誌表通常不存儲增量數據的全部字段信息，而只是存儲源表名稱、更新的關鍵字值和更新操做類型 (insert、update 或 delete)，ETL 增量抽取進程首先根據源表名稱和更新的關鍵字值，從源表中提取對應的完整記錄，再根據更新操做類型，對目標表進行相應的處理。

因爲增量日誌表中並無徹底記錄增量數據自己，只是記錄了增量數據的來源。進行增量 ETL 時，只須要根據增量日誌表中的記錄狀況，反查源表獲得真正的增量數據。

觸發器方式優缺點

優勢：數據抽取的性能較高。

缺點：要求業務表創建觸發器，對業務系統有影響，須要對用戶數據庫進行修改，不能對多表和視圖進行操做，若是目標表發生錯誤會形成級聯事務失敗，這在生產系統沒法忍受，另一個缺點是若是觸發器運行過程當中產生問題，有時須要從新加載整個表來恢復加載做業的運行。 這類方法適用於一對一且業務邏輯不復雜的表的增量更新。

源表與目標表一對一增量更新，但須要進行一些數據轉換操做

有些源表與目標表之間不是簡單的數據對應關係，可能二者之間有不一樣的數據結構，須要進行一些數據轉換，例如彙總，行轉列等操做後才能進行更新。上文提到的日誌分析方式 和觸發器方式就不太適用，這時採用時間戳的方法比較合適。

時間戳方式

實現原理是指增量抽取時，抽取進程經過比較系統時間或者源表上次抽取時的最大時間戳與抽取源表的時間戳字段的值來決定抽取哪些數據。這種方式須要在源表上增長一個時間戳字段，系統中更新修改表數據的時候，同時修改時間戳字段的值。

採用時間戳進行增量更新時須要源表有相應的時間戳字段，因此對於沒有時間戳的源表須要進行相應業務須要改造，增長必要的時間戳字段。

時間戳方式優缺點

優勢：實現邏輯簡單，能夠大批量更新數據。不只能夠對一張源表進行數據捕獲，也能夠對多張源表的增量數據進行捕獲。

缺點：

a. 使用時間戳方式能夠正常捕獲源表的插入和更新操做，但對於刪除操做則無能爲力，須要結合其它機制才能完成。這時能夠設計一張和源表相同的數據表記錄源表中刪除的數據，同時記錄刪除時的時間戳，在對目標表更新時同時讀取這張表的記錄，進行刪除操做。

或者在目標表經過打標記的方式（update active_flag=1）進行邏輯刪除。

b. 若是系統自動更新或手工更新時間戳字段時可能會出現數據延遲現象產生。

c. 若是採用系統自動更新時間戳的方式，須要特別注意在 Load 整個表的操做時，要保持此字段數值不變，不然時間戳將會自動加載爲 Load 的最新時間，影響整個表的增量更新邏輯。

d. 應用起來有部分侷限性。即源表都須要有時間戳字段。若是部分源表（或參考表）無時間戳字段，且源表有部分字段更新時（常見於維度表的定義更新，如地區維度，產品維度等），則面臨歷史數據的更新問題。此時採用時間戳方法只能更新新增數據的維度定義，而沒法更新歷史數據。這時通常須要採用 SQL 語句或者下文介紹的全表對比方式進行歷史數據更新。或者調整時間戳範圍，作全表數據的刷新。這種狀況須要對目標表的實時性要求不高，能夠在系統空閒時進行處理。

e. 因爲時間戳增量更新常常應用於業務邏輯複雜的 ETL 過程，在面對源表裏有多條記錄彙總至目標表一條記錄狀況時，例如源表裏記錄 R1，R2，R3（主鍵均相同），根據主鍵彙總至目標表生成記錄 T1，則須要注意若是時間窗口內有源表一條數據發生了數據變更（R2），則須要利用 R2 的主鍵將源表中的 R1，R3 也同時捕獲出來（雖然 R1，R3 在時間窗口內沒有數據變更），從新進行彙總，更新目標表中的 T1 記錄，以免數據丟失或者數據邏輯不正確問題。

源表與目標表多對一增量更新

平常的 ETL 更新中，還會遇到目標表的數據來源來自於多張源表，經過關鍵字段的拼接進行更新操做。若是多張源表都有時間戳字段，能夠利用時間戳進行增量更新，另外還能夠採用全表比對的方式進行增量更新。

全表比對方式

全表比對即在增量抽取時，ETL 進程逐條比較源表和目標表的記錄，將新增和修改的記錄讀取出來。優化以後的所有比對方式是採用 MD5 校驗碼，須要事先爲要抽取的表創建一個結構相似的臨時表，該臨時表記錄源表的主鍵值以及根據源表全部字段的數據計算出來的 MD5 校驗碼，每次進行數據抽取時，對源表和 MD5 臨時表進行 MD5 校驗碼的比對，若有不一樣，進行 UPDATE 操做：如目標表沒有存在該主鍵值，表示該記錄尚未，則進行 INSERT 操做。而後，還須要對在源表中已不存在而目標表仍保留的主鍵值，執行 DELETE 操做。

全表比對方式優缺點

優勢是適用於：

a. 涉及多張源表的抽取與轉換，業務邏輯複雜的增量更新。

b. 源表無時間戳字段，沒法採用時間戳方式進行增量更新。

缺點是採用全表比對，對於大數據量數據表，效率不高。

總結與分析

表 1. 各種增量抽取方式比較表

	系統日誌分析方式	觸發器方式	時間戳方式	全表比對方式
對目標表新增數據	可	可	可	可
對目標表更新數據	可	可	可	可
對目標表刪除數據	可	可	沒法捕獲	可
目標表數據量	小	小	大	適中
目標表類型	全部	除視圖之外都可	全部	全部
源表數量	1	1	多	多
源表處理邏輯	簡單	簡單	複雜	複雜
系統資源佔用	較多	較少	較少	較多
數據抽取性能	優	優	較優	差
源表是否須要有時間戳字段	不須要	不須要	須要	不須要
容災能力	較差	普通	普通	優

在選擇合適的增量加載機制時，須要注意的方面包括：

1. 增量抽取的容災能力。主要是指增量加載更新方式若是運行失敗或者數據庫宕機重啓後，是否能夠從新加載增量數據或者是否須要手工補錄數據的能力，必定程度上也影響着增量加載的可維護性。

其中系統日誌分析方式 在失敗或者未運行情況下，將沒法捕獲源表的增量數據，沒法恢復歷史增量數據的加載，因此容災能力最差。觸發器方式和時間戳方式，若是有相應的日誌表存在，或者增量日誌未被清除，則能夠在再次啓動後從新加載歷史增量數據，容災性通常。而全表比對方式，根據它的實現原理則在從新啓動時不受任何影響，能夠全面捕獲增量數據，容災性最好。

2. 增量抽取的性能因素。表如今兩個方面，一是抽取進程自己的性能，二是對源系統性能的負面影響。觸發器方式、日誌表方式以及系統日誌分析方式因爲不須要在抽取過程當中執行比對步驟，因此增量抽取的性能較佳。全表比對方式須要通過複雜的比對過程才能識別出更改的記錄，抽取性能最差。

若是增量更新的業務邏輯比較複雜，對機器性能要求較高，在進行更新時可能會有影響現有業務邏輯表的性能，則能夠評估其增量更新的重要性，若是對現有業務影響不大，且源表比較穩定，客戶能夠容忍暫時性的必定程度的數據不一致。則能夠考慮定時進行增量更新。例如更新程序每日凌晨運行一次，甚至每週空閒時間運行一次。

另外業界廣泛經常使用的方式是源系統在它的閒時抽取增量 delta 數據文件，數據倉庫系統獲得 delta 文件後再加載到倉庫系統。在數據倉庫架構設計中，生產系統層和 ODS 層的直接數據交互即爲此類型。

3. 觸發器方式須要在源表上創建觸發器，這種在某些應用場合中遭到拒絕。還有一些須要創建臨時表的方式，例如全表比對和日誌表方式。可能由於開放給 ETL 進程的數據庫權限的限制而沒法實施。一樣的狀況也可能發生在基於系統日誌分析的方式上，由於大多數的數據庫產品只容許特定組的用戶甚至只有 DBA 才能執行日誌分析。例如 DB2 的 Replication 功能只能由 DBA 維護與修改，普通用戶沒法操做。

4. 爲了保證增量更新的數據準確性，建議創建一系列的核查腳本，以保證源表和數據表的數據一致性問題。覈查腳本能夠根據輕重緩急設定其運行頻率。

5. 數據抽取須要面對的源系統，並不必定都是關係型數據庫系統。某個 ETL 過程須要從若干年前的遺留系統中抽取 EXCEL 或者 CSV 文本數據的情形是常常發生的。這時，全部基於關係型數據庫產品的增量機制都沒法工做，時間戳方式和全表比對方式可能有必定的利用價值，在最壞的狀況下，只有放棄增量抽取的思路，轉而採用全表刪除插入方式（或者要求源系統提供增量 delta 數據文件）。