1、ETL和ELT

????????ETL是Extract、Transfrom、Load即抽取、轉換、加載三個英文單詞首字母的集合：

????????E：抽取，從源系統(Souce)獲取數據；

????????T：轉換，將源系統獲取的數據進行處理加工，比如數據格式轉化、數據精度轉換、數據清洗、缺失數據補齊、異常數據排除等。

????????L：加載，將數據加載到目標數據庫(Target)。

????????ELT也是同樣三個單詞的首字母組合，只是把T、L顛倒了下順序。ETL強調的是先進性數據轉換，然后再加載到目標。這個轉換過程可以在原系統進行，也可以在中間環境進行進行。而ELT是把數據加載到數據倉庫后再進行轉化。ETL優勢是充分利用各關聯系統的性能，提高效率，但程序部署分散，運維成本較高。ELT是充分發揮數據倉庫平臺數據加工的高性能，并且可以保存原始數據方便后續復用。

????????隨著數據倉庫平臺的性能越來越高，容量成本越來越低，目前更多的是采用ELT方式，充分利用數據倉庫的高性能，提高加工效率。但在數據加載前也需要進行數據編碼轉化、異常數據等影響加載的處理，確保數據正確加載到數據倉庫平臺，但不做數據邏輯加工。

????????由于ETL出現較早，通常使用ETL來代表數據抽取加載和轉換的統稱。

2、ETL架構設計

????????數據ETL需要有ETL服務器集群執行數據ETL作業來進行數據抽取、轉換和加載，所有ETL作業的腳本部署多臺ETL服務器上，ETL作業可以根據服務器資源由調度工具分配到任意一臺ETL服務器執行，常見架構如下圖：

????????ETL架構不僅僅是作為數據倉庫的架構，但也是全行批量數據交換的統一架構和標準，雖然數據倉庫是其中最大的一個數據加載的目標系統和數據源系統，但從架構規劃角度來看，需要從全行、全集團的角度來設計批量數據交換，考慮多機構間交互場景，減少不必要的轉換，提高效率和穩定性。

????????ETL服務器集群需要做到高可用，對于不能正常服務或負載過高的服務器，調度平臺不會將作業分配到該服務器，所有的ETL作業腳本需要在每臺服務器上部署，不能只部署一份代碼到共享存儲中。

????????在硬件資源上，服務器的IO和內存需要配置較高，同是由于批量數據容量較大，網絡帶寬需要千兆以上，同時需要考慮在傳輸高峰不能影響交易系統的網絡通訊。

?

（1）文件方式和端到端方式

?? ? ????數據抽取和加載從是否經過中間落地成文件來區分主要有文件落地方式和端到端不落地（內存）的兩種方式。文件方式指ETL服務器的抽取數據作業從源系統獲取轉煥為文件放到文件共享存儲中，再由加載作業到目標系統中。端到端方式是ETL服務器從 源系統獲取數據后在內存中直接加載到目標系統。

????????從步驟中可以看出端到端方式在內存中直接加載，從單個作業速度對比來看速度應該更快，開發更簡單，但端到端方式對內存資源要求較高，并行作業的最大值一般較文件低，同時文件具有以下好處：

??????? 1）各數據庫對文件導入和導出支持較好，一般都會提供專門的工具和高性能接口（如oracle sqlload導入文件和spool導出文件的性能較高）。因此大批量的數據抽取和加載作業的效率從整體看文件方式不一定比端到端的方式慢。

??????? 2）文件方式耦合性比端到端低，如果發現數據加載出現問題，可以不用重新抽取數據，減少抽數對源系統的性能影響。

??????? 3）文件通用性較好，如果涉及多網絡或多機構之間的數據交換，A子公司的ETL服務器無法連接到B子公司的數據庫。另外對于非結構化數據來源廣泛，導出文件比較通用。

?????? 具體采用文件方式，端到端方式還是兩者都采用的方式，各公司需要考慮服務器資源、現有工具及數據庫驅動性能、成本、數據交換場景等多種情況來確定。

（2）文件方式方案需要考慮的要點

?????? 文件方式比較通用，多機構之間較多采用文件方式進行批量數據交互，但采用文件方式進行架構設計和開發時需要關注以下幾點：

??? 1）統一的文件交換規范和文件傳輸平臺

文件存儲規范制定文件目錄、文件命名、用戶權限、文件校驗、文件清理等規范，如果涉及到跨機構批量文件傳輸，還需要統一有文件傳輸平臺，提供統一的文件高效傳輸、加密、校驗、限流、文件夾同步等功能。國內銀行使用較多的文件傳輸平臺有東方通、神州數碼等公司產品。

???? 文件目錄規范中需要區分數據產生系統、數據使用系統、數據日期等，文件名中需要說明產生系統、文件內容描述、增量全量標志、數據日期等，規則舉例如下：

????????數據源系統/數據日期/目標系統/源系統_文件內容描述_數據日期_增全量標志_頻率標志.txt

????????舉例：CBS/20190620/EDW/CBS_DEPOSIT-ACCOUT_20190620_ALL_D.txt

????????說明：【CBS、EDW為系統名】【ALL為全量標志】【D為每日】

?????? 2）文件格式：定長or 變長（分隔符）

定長：文件大，I/O資源消耗大，但能消除回車符、分隔符以及亂字符問題。

變長（分隔符）：文件小，處理性能高，但需處理異常情況較多：

?????????<1>分隔符：數據中存在分隔符，導致加載報錯，可選用兩個連續的不可見字符作為分隔符，基本可以解決該問題；

?????????<2>換行符：導出文件時一般以換行符作為一行數據的結束，如果導出工具支持可以改成不可見字符作為換行符，不支持的話導出時對數據中的換行符進行替換；

???????? <3>異常字符：如截取導致的半個UTF-8字符的編碼或者HEX00等字符，一些數據庫不支持會報錯，一般這些字符發生在以前的主機上，異常情況下出現沒處理，可以提前在源系統進行數據清洗或者導出時進行替換清洗。

????????因此一般在這些問題都有較好解決方法不影響抽取加載作業效率的情況下，都會采用變長（分隔符）的方式。

??? 3）文件編碼

????????文件導出需要統一編碼，一般采用UAT-8編碼，適應多國字符，但如果只有國內應用，也可以考慮GB18030或GBK編碼，因為這兩種編碼中文字符比UTF-8編碼節省1/3多的存儲空間。性能較好。

（3）端到端方式需要考慮的要點

1）工具選擇

????????目前市場上商用的ETL工具如DATASTAGE、INFORMATICA，開源的SQOOP都支持端到端的處理，商用工具還提供中間的圖形化的數據轉換編碼功能，但商用軟件一般成本較高，對于一些數據庫的高性能驅動還需要收費，開源工具功能較通用，但性能需要優化，同時需要有一定的技術能力來定制功能和軟件升級。

?? 2）驅動選擇

????????選擇數據庫提供的高性能原生（native）驅動，不要使用ODBC驅動，原生的驅動性能數倍于ODBC等通用驅動，采集數據較多時能很大提高效率。

?? 3）字符編碼

? ? ? ?需要將數據從源系統導出時轉換為目標數據庫的編碼格式，在全公司的數據庫編碼和數據倉庫內的字符編碼需要進行統一規范，既可以減少轉換成本，也可以減少生僻字、無法轉換等異常情況。

3、抽取和加載開發設計

（1）開發需求分析

????????由于源系統和目標系統數據庫不同，數據質量不高，需要注意之間不同數據庫之間的字段類型、長度、精度的轉換，為后續數據加工做好清洗：

????????1）源系統字段沒有明確精度和長度時，如Oracle中字段類型為number,沒有定義精度，使用DATASTAGE時，當大于15位的number型數字接近最大值時會自動進位，所以在目標表設計字段精度時需要考慮這種異常情況。

????????2）字符字段的全角和半角是否都統一為半角；

????????3）字符字段左右空格是否都統一去掉；

????????在開發抽取加載作業時，需要配置以下主要信息，這些信息需要在數據調研和需求分析時提前確定：

（2）全表字段自動加載

?????? 一般開發時會采用固定字段抽取加載的方式，但由于源系統的表結構會經常變化，比如增加字段，字段長度變長，如果每次變化都要隨之修改，許多時間會耗費在這些小修小改中，因此在進行抽取和加載時，需要根據源系統表結構自動生成對應的抽取腳本、目標表結構、加載腳本，自動適應源系統的表結構變化。

?（3）源系統數據表變化通知和監控

????????雖然抽取和加載作業可以適應源系統表結構變化，但字段長度、精度變化、字段刪除、代碼值變化和字段含義變化會對后續數據加工作業帶來影響。因此源系統需要將這些變更提前告知數據倉庫或目標系統，否則就會產生生產問題，但源系統開發同事往往會產生遺漏，因此在公司數據治理制度中明確開發分工、數據問題責任界定。如在每次版本需求分析時需要考慮數據變化對數據倉庫及其它系統的影響，并在測試階段提前進行影響測試。在上線前也需要檢查下系統表結構變化的DDL文件，分析影響并通知影響系統。

????????由于源系統字段的變化會影響到后續的數據流向的所有系統，因此在數據倉庫的模型設計時需要提前設計冗余，減少字段長度、精度變化的影響，比如源系統字段長度是128，在數據倉庫主數據模型中可以設計為500。減少對后續數據使用系統的影響。具體影響分析工具會在后續的“元數據管理”中詳細說明。

????????由于只靠源系統的通知并不完全可靠，還需要做好源數據表結構變化和代碼值變化的監控，每天對抽取的表結構和上一日進行比對，代碼值與代碼值映射表中比對，對發現未告知的情況進行郵件告警，并評估影響、及時處理，以免問題積累，需耗費大量精力修復。

?（4）自動化腳本生成及執行

?????? 對于抽取加載作業需要做成標準化程序，即一個程序處理所有的抽取加載作業，根據不同的配置信息來完成所有作業，在調度工具中的所有抽取加載作業指向的是同一個程序，由這個程序根據傳入的作業名和日期自動化生成腳本并執行。這樣對于開發只是進行配置信息的確認和導入即可，不需要涉及代碼開發。

?????? 許多ETL工具需要開發腳本再執行，特別一些商用的軟件如DATASTAGE還提供了可視化的開發界面，但這樣開發也比較耗時，對于使用的ETL工具如DATASTAGE、SQOOP也支持編程和腳本調用作業，所以可以用統一的程序來調用ETL工具進行抽取加載數據。提高開發效率，以下是供參考的流程。

（5）監控及異常處理

????????數據抽取和加載作業是數據倉庫每天第一批作業，如果發生問題往往對整個批處理時效產生較大影響，甚至影響監管報送時效。因此需要對作業進行監控，及時預警。

?????? 因此在開發抽取和加載作業時，需要注意：

????????1）統一返回碼并提供錯誤信息；

????????2）抽取和加載作業必須支持重跑，也就是在作業任何階段發生異常時可直接重做，需要設計時考慮異常中斷下，如何恢復初始數據；

????????3）調度平臺需要根據抽取加載作業返回碼判斷作業是否成功，是否可以繼續，對于異常情況需要及時與行內監控預警系統對接，按預警級別發送作業錯誤告警信息；

????????4）調度平臺需要獲取到作業的日志，對于一些ETL工具，這部分需要進行集成，以便減少后臺日志查看的工作量，直接在調度平臺進行問題定位。

（6）開發分工

????????ETL作為全行或全公司的批量數據交互基礎架構，需要在全行或全公司進行規范和開發流程培訓。ETL服務器及工具、抽取加載的標準程序由統一團隊來維護，需要進行權限分配并提供培訓及技術支持。那對于抽取加載作業具體由源系統還是目標系統來開發不同的公司有不同的做法，

????????１）由源系統開發，如果源系統是將數據加工結果給到目標系統，由于比較熟悉數據，一般由源系統加工完后直接開發抽取加載作業將數據提供給目標系統；

????????２）由目標系統開發，目標系統比較熟悉數據用途及優先級，如果全表抽取的話數據加工主要在目標系統，由目標系統來開發抽取加載作業，源系統只需要做好數據權限分配即可。

????????３）由數據倉庫團隊統一開發，一般公司較小時可以由統一團隊來開發，但隨著開發項目增多，會出現瓶頸，影響效率，需要由各數據使用方來開發抽取加載作業。