【正文】 在 EDW 中，將由成千上萬的作業(yè)來完成數據整和的功能，這些作業(yè)由于復雜度不同，運行頻度不同，甚至是同一個作業(yè)，由于數據來源不同(例如不同的分行)，數據規(guī)模也是相差甚遠的，因此如果對所有的作業(yè)使用相同的配置文件，將對系統(tǒng)。服務端與客戶端作為daemon 進程，要求能夠長時間運行?？蛻舳伺c服務端采用 C/S 通信模式，通過 TCP 協(xié)議傳送信息，這樣做的好處是：? 避免工作節(jié)點直接訪問管理庫，訪問管理庫的工作統(tǒng)一ETL Server來完成，從而提高了應用部署的適應能力；４６ / 47? ETL Server可以據此檢測所有工作節(jié)點是否存在故障；客戶端負責采集信息發(fā)送到服務端，服務端接收信息，并寫到數據庫。４５ / 47 動態(tài)資源分配R e s o u r c e B r o k e rR e s o u r c eA g e n tN o d e 1R e s o u r c eA g e n tN o d e 2R e s o u r c eA g e n tN o d e NR e s o u r c eA g e n tD B S e r v e r. . . 節(jié)點資源實時信息T C P / I P T C P / I P T C P / I P T C P / I P更新E T L S e r v e rE T L C l i e n tE T L 域上圖為本系統(tǒng)的動態(tài)資源采集模塊的邏輯結構圖，其目的是實時采集整個ETL 域中各節(jié)點的系統(tǒng)資源使用情況，以及檢測節(jié)點運行狀態(tài)是否正常，以作為動態(tài)資源分配的主要依據。7. ETL SERVER 得到 ETL CLIENT 的反饋信息后，將其寫入日志，并設置JOB 的狀態(tài)，同時釋放結點的資源。然后根據運行配置文件，將 JOB 分配給各個 ETL CLIENT 執(zhí)行。5. ETL SERVER 在得到 JOB 運行的結點個數和能夠運行該 JOB 的結點列表后，根據本域的管理類數據庫中結點的使用情況表，按照一定的策略對能夠運行該 JOB 的結點列表進行排序，選出最優(yōu)的若干個 ETL CLIENT。４４ / 473. 3．ETL SERVER 對 JOB 的類型進行判斷，如果是普通的 SHELL JOB 或者EXEC JOB，則根據 JOB 實例表中的 NODES_LIST(該作業(yè)可使用的節(jié)點列表)，計劃在本域中分配一個 ETL CLIENT 給 JOB 運行，如果是 DS JOB，則根據 JOB 實例表中的 NODES_NEED(運行該作業(yè)所需節(jié)點數)和NODES_LIST(該作業(yè)可使用的節(jié)點列表)得到該 JOB 運行所需的結點個數以及所能夠運行該 JOB 的結點列表。管理庫的信息分為三類：? 系統(tǒng)參數和作業(yè)配置信息：靜態(tài)參數；? 狀態(tài)信息： 屬于控制類的動態(tài)信息；? 日志信息； ETL 流程設計系統(tǒng) ETL 設計流程如下圖：４３ / 47本系統(tǒng) ETL 處理流程順序概要描述如下：1. 調度程序在總行的調度服務器上面運行，當調度程序發(fā)現某個作業(yè)符合調度條件，就對其進行調度，將該 JOB 的 ID 發(fā)給該 JOB 所在域的ETL SERVER。無論是總行還是分行，數據庫都是由管理類數據庫和業(yè)務類數據庫組成。管理類數據庫存放的是作業(yè)運行控制相關的數據信息，如系統(tǒng)配置參數或作業(yè)配置信息、狀態(tài)信息和運行日志信息等。? 數據庫模塊統(tǒng)一架構中的數據庫模塊分為兩個部分：管理類數據庫和業(yè)務類數據庫。如果實際運行 JOB 的 ETL CLIENT 資源不足，經常處于高負荷狀態(tài)，則可以通過增加 ETL CLIENT 來提高運行效率。它可以根據本域上的作業(yè)情況增減 ETL CLIENT。４２ / 47ETL CLIENT 主要負責 ETL SERVER 分配的作業(yè)模塊的具體執(zhí)行，是作業(yè)的具體執(zhí)行者。其次根據作業(yè)運行資源需求，獲取所屬 ETL CLIENT 的資源情況，選擇最優(yōu)的若干臺 ETL CLIENT，分配作業(yè)給這些 ETL CLIENT 運行。ETL SERVER 主要負責 ETL JOB 的具體執(zhí)行。對于不同的域，它們的處理任務也是不一樣的。總行有一個或多個總行的 ETL 域，分行有本分行的 ETL 域。在實際部署中，調度模塊可以僅部署在總行，實施統(tǒng)一調度，也可能部署在分行，實施分布調度；而在每個 ETL 域的 ETL Server 上部署調度的Agent 模塊，調度 Server 負責任務的檢索、調度和分發(fā)，調度 Agent 接收到調度 Server 的調度指令，調用作業(yè)主控模塊(JCI)執(zhí)行具體的作業(yè)，并根據 JCI的退出碼將作業(yè)的執(zhí)行情況反饋給調度 Server。任務調度模塊在 EDWH+EDWB 統(tǒng)一模塊中，調度是由部署在總行的調度 SERVER 統(tǒng)一完成調度工作,或者由部署在分行的調度 Server 完成本分行作業(yè)的調度。 ? 物理作業(yè)：具體負責數據加工的程序執(zhí)行單元，各類存儲過程或者作業(yè)腳本(SHELL 腳本、用 C/C++/PROC 等開發(fā)的可執(zhí)行程序） 。? ETL 域：ETL 架構中基本的計算資源組合，是一個計算機群，由 JCI統(tǒng)一管理和控制，一個 ETL 域由一個 ETL Server 和多個 ETL ４１ / 47Client 組成。? 數據庫模塊：管理類數據庫：用于調度和作業(yè)主控，保存任務和作業(yè)的相關配置信息和運行信息。需要定義：源數據結構、目標數據結構、源和目標的映射(包括定制映射的方案、定制映射調用的函數、定制清洗的方案)、作業(yè)處理日志以及作業(yè)依賴關系。作業(yè)的監(jiān)控需要包括以下功能：監(jiān)控作業(yè)的當前執(zhí)行情況；查詢作業(yè)歷史執(zhí)行情況。 作業(yè)調度和監(jiān)控根據作業(yè)依賴關系的元數據進行 ETL 作業(yè)的調度，并對執(zhí)行過程進行監(jiān)控。 異常處理ETL 處理的異常主要包括：1) 硬件、操作系統(tǒng)、網絡導致異常；2) 數據源數據傳輸、質量導致異常；3) ETL 過程處理導致異常；4) 目標數據模型導致異常；5) 人工干預導致異常等；建議處理的方法包括：1) 手工干預，重新調整 ETL 過程；2) 終止流程,通知管理員；3) 拒絕數據，記錄原因；4) 清洗數據，部分入庫；5) 監(jiān)控資源，反復嘗試ETL 恢復策略包括有：1) 每條記錄中有數據 ETL 的時間戳，對小數據量的數據表，可以通過該４０ / 47時間戳清除掉本次加載的數據。錯誤的恢復策略：? 每條記錄中有數據 ETL 的時間戳，對小數據量的數據表，可以通過該時間戳清除掉本次加載的數據。ETL 管理調度利用作業(yè)調度控制可以處理各種異常錯誤情況。缺點是必須對業(yè)務數據庫進行改動，客戶不一定能接受。6. 循環(huán)校驗碼對于沒有時間戳的數據進行修改，還可以考慮采用循環(huán)校驗碼。一般數據庫均包括日志，通過分析數據庫的日志來判斷增量數據。4. 整表比較對于沒有時間戳的增量數據，數據量不大時，例如編碼表，可以采用使用數據庫的 SQL 操作語句（NOT IN，NOT Exists）的方法。2. 自增長的序列號源系統(tǒng)設置了自增長的序列號作為唯一主鍵。增量策略是正常的日常增量處理的策略，故障恢復策略是在日常增量處理出錯時的處理策略。對于歷史數據加載的策略，我們可以采用時間窗口的分段的方法來處理歷史數據量大的表的裝載，即我們可以一個一個時間段來加載歷史數據。我們認為只需要建立一套增量加載的 ETL 同樣處理歷史數據加載和日常數據加載，而不再開發(fā)另一套全量加載 ETL 程序處理歷史數據加載。歷史數據加載指在第一次加載數據到數據倉庫中，此時數據倉庫中不存在歷史數據。5. 作為 ETL 后續(xù)處理的統(tǒng)一接口建立 Staging Area 作為 ETL 每個處理階段的接口，對系統(tǒng)的靈活性和可擴展性非常有幫助。3. 對數據的格式進行轉換在 Staging Area 完成數據格式的轉換，例如日期格式、字符串右邊的空格、NULL 值的替換、數據類型轉換等。2. 應用于增量處理可以減少處理的記錄數量，使增量處理更加容易，例如應用于 SCD Type 2。Staging Area 的作用與實現：1. 減少對數據源的查詢壓力，有助于數據整合。 從業(yè)務系統(tǒng)抽取數據，采用 ETL 平臺直接從業(yè)務系統(tǒng)抽取數據，也可以先把業(yè)務系統(tǒng)的數據導出為文本文件再加載到臨時存儲區(qū)。 ETL 設計方案 ETL 關鍵設計環(huán)節(jié) 接口層設計策略將數據源環(huán)境下的數據裝載進入 EDW 環(huán)境，需要在兩個不同環(huán)境的記錄系統(tǒng)之間建立一個接口。提供數據存儲區(qū)的FDM層數據、ADM層數據。本模式提供EDW允許的相應時間段的歷史數據支持。? ETL5：屬于ETL目標數據裝載。從數據倉庫FDM層進行適量的維度、指標建模。ETL3處理是耗時最長，邏輯處理最復雜的階段，需要非常重視。? ETL3：屬于ETL轉換。對數據緩沖區(qū)數據標準化，統(tǒng)一數據表達格式，排序數據，篩選重復數據，合并或分割數據項，裝載入數據存儲區(qū)的基礎數據層。對源數據做數據平衡檢查、稽核數據有效性，報告數據質量問題。? ETL1：屬于ETL預處理。ETL 轉換清洗通過連接、合并、分割，按照清洗規(guī)則對數據緩沖區(qū)、數據存儲區(qū)的數據進行加工、匯總，最終裝載入數據存儲區(qū)。XX 銀行總行的 EDW 系統(tǒng)數據源環(huán)境復雜，應用系統(tǒng)數據需求旺盛，數據質量參差不齊，結合以上系統(tǒng)目標及設計原則，建議采用如下體系架構建設：３５ / 47ETL 邏輯結構按照處理過程可劃分為 ETL 預處理、ETL 轉換清洗、ETL 目標數據裝載。通過高效的 ETL 系統(tǒng)結構、層次化的應用功能劃分和標準的程序模板，EDW 系統(tǒng)能夠達到以下目標：? 支持在此框架下實現EDW項目所需要的ETL功能；? 支持在規(guī)定的批處理時間窗口（Batch Window）內能夠完成數據加載工作，即需要滿足日常數據加載的性能需求；? 能夠支持有效的應用程序開發(fā)模式，提高開發(fā)效率，盡量減少應用開發(fā)成本；? 減少系統(tǒng)維護的復雜性，支持后續(xù)增加新數據或功能的開發(fā)工作。３４ / 47第二章 ETL 體系建設 ETL 架構概述在商業(yè)銀行的 EDW 系統(tǒng)中，數據由數據源系統(tǒng)加載到 EDW 的各個數據層中，并通過供數接口提供給相關使用者系統(tǒng)。３３ / 47 應用服務基于數據分析功能和交易功能分離原則，為保證交易系統(tǒng)運行效率和數據分析功能日益增加的需求，新系統(tǒng)設計時，應該將數據分析功能和交易功能分離到不同系統(tǒng)中，或者至少為將來分離做好技術準備。? EDW 模型化各系統(tǒng)數據，可以滿足各應用系統(tǒng)對全量數據、增量數據的需求，減少對重要交易系統(tǒng)的干擾。EDW 數據采集、加工、發(fā)布的范圍包括：? 總行各應用系統(tǒng)之間? 總行與分行應用系統(tǒng)之間? 同一分行應用系統(tǒng)間? 不同分行應用系統(tǒng)間? 分布部署的同一應用系統(tǒng)間EDW 數據服務具備的能力有：? EDW 快速提供批量數據，可以滿足應用系統(tǒng)準實時的數據要求。應用架構應采用先進的理念和技術，并結合 XX 銀行科技規(guī)劃與現有的技術平臺。EDW 系統(tǒng)的應用架構應該能夠作為需求檢查列表，檢驗當前用戶需求是否被涵蓋，而不會發(fā)生遺漏。開放性：EDW 系統(tǒng)的應用架構設計必須考慮平臺、系統(tǒng)、功能的開放性，與XX 銀行的科技規(guī)劃相適應，能夠與周邊各系統(tǒng)進行良好的信息傳遞。數據集市中可存在操作型數據、匯總型數據和多維分析數據，根據應用的需要分別進行建立。加工匯總數據層的數據模型設計在有相應的匯總需求情況下才針對匯總需求進行數據表和數據匯總任務的擴展設計，逐步積累公共匯總指標，最后形成全行可共享的面向各個主題的中間匯３１ / 47總指標。加工匯總數據層下的匯總需求由“應用需要”來確定。EDW 對源系統(tǒng)客戶號進行統(tǒng)一，提供統(tǒng)一的客戶號（ECIF 客戶編號） 。在基礎據模型中按照八大主題對銀行全行數據進行整合、分類組織和存儲，這八大主題包括總帳(GL)、客戶(CI)、存款(DEP)、貸款(LN)、銀行卡(CRD)、中間業(yè)務(NIN)、渠道(CHN)、公用(CM)；每個主題下設計相應的數據模型，最后構成全行統(tǒng)一的基礎數據模型。為應用方便、查詢高效考慮，可以對源系統(tǒng)進行適當的整合、拆分，也可以裁減掉源系統(tǒng)中沒有必要整合的數據。? 標準化全量層? 基礎數據層數據模型基礎數據模型用于整合、存儲全行各業(yè)務系統(tǒng)的基礎業(yè)務數據。為了更好的管理這些數據，EDW 數據按層次進行劃分存放及管理，從邏輯模型上劃分為以下幾個數據層次：３０ / 47? 源數據緩沖層：數據層與業(yè)務源的數據結構一一對應，是數據存儲的臨時存儲區(qū)域，數據在其中只作暫時性保存，當新的數據到達緩儲區(qū)時，現有數據被刪除或覆蓋。因此數據和信息不能隨意堆積存放到數據庫中，需要對全行的數據和信息進行分層、分類存放，并制定相應的數據分層、分類的規(guī)范，EDW 系統(tǒng)上所有數據和應用的建設都應遵從統(tǒng)一的數據管理規(guī)范。因此在設計時必須考慮如何合理組織數據，以減小數據冗余。? 存儲空間合理性原則數據模型需要處理海量數據。? 實用性原則處理大量的源系統(tǒng)數據，將會占用大量的系統(tǒng)資源，因此必須仔細分析數據的實用性、指標的使用頻率，以業(yè)務需求驅動為原則，對業(yè)務提出的基礎數據和指標需求進行優(yōu)先級劃分，正確制定指標的匯總粒度。２８ / 47? 高效原則數據模型面臨海量數據的加工和存儲，隨著時間的推移，數據將不斷累積，因此效率問題是直接影響系統(tǒng)可用性的關鍵因素。特別是加工匯總層的數據架構必須符合“匯總指標可靈活增加”的技術要求，