小研非現場審計系統業務的ETL

時間：2024-05-23 09:55:06 MBA畢業論文

小研非現場審計系統業務的ETL

　　
　　1．引言
　　在商業銀行中，用戶對數據實時性的要求很高。在商業銀行的一些系統中，如非現場審計系統，用戶需要在很短的時間內對交易數據進行分析、統計，并把可疑數據上報，以盡量減少損失。這就要求系統所需數據必須在短時間內到達，但是這些系統的數據源十分繁多。

　　審計系統中，審計人員需要的信息很全面，既包括個貸業務、信貸業務、私金業務，還要包括國際業務、資金業務和中間業務等，這些業務都有各自的系統，其中有一部分數據還取自于核心系統。而且數據存儲在異構的環境中，比如它們使用不同的數據庫，不同的操作系統環境等等，如何在眾多系統中快速的提取數據和快速的形成一個系統所需的數據集市，這對我們是一個挑戰。

　　針對上述問題，本文提出了一個ETL模型。與其他商業銀行常用的模型相比，本模型基于業務設計和實現，具有高效的錯誤恢復機制，能夠利用基礎任務和業務任務的劃分，根據任務號單獨執行出錯的任務，而不用將整個ETL過程重新執行一遍，大大縮短了恢復錯誤的時間，從而可以更好地滿足客戶對于時間上的要求；與傳統成熟的商業ETL工具相比，基于業務的模型設計與實現，可以根據每天的審計目標去創建ETL任務，減少了工作量。同時，此模型部分實現直接采用代碼，針對性更強，靈活性更好，可以處理商業銀行復雜系統中清洗和轉換任務，最重要的是可以減少商業工具一些不必要的執行步驟，縮短了時間。中國碩士論文網提供大量免費mba碩士論文，如有業務需求請咨詢網站客服人員！

　　2．審計系統的ETL
　　目標ETL 過程的最終目標是在合理的時間內實現了高質量的審計系統數據集市，以供客戶審計業務數據。圍繞此目標，本文必須合理、靈活、高效的設計ETL 過程，才能滿足用戶的需求。在此過程中，存在以下幾個問題：

　　1.靈活的ETL 控制過程。
　　因為本審計系統涉及的數據源比較多，包括信貸系統、票據系統、核心系統等，根據客戶要求，有的業務數據可能需要每天更新，而有的業務數據可能需要每兩天更新一次。對于這種數據更新頻率不統一的要求，本論文需要設計靈活的ETL過程，可以實現針對單數據源的操作。

　　2.統一安全的抽取平臺。
　　由于數據源的繁多，而且數據存儲在異構的環境中，比如它們使用不同的數據庫，不同的操作系統環境等。這就要求本文要實現一個統一的抽取平臺，以應對不同的數據承載平臺、數據源和數據格式，同時要求在抽取構成中不能破壞源數據。

　　3.快速的處理過程。
　　由于用戶要求數據的準實時性，要求在盡量短的時間內（比如兩個小時）便可以審計業務，所以本文還要解決如何快速在眾多數據源中提取數據和快速的形成一個系統所需的數據集市，這對本文是一個巨大的挑戰。

　　4.自動化的處理流程，可定制的服務。
　　由于商業銀行的特殊性，要求數據抽取必須在午夜進行，所以本系統必須實現自動化的處理流程，盡量減少人工干預，降低服務成本。此外，還要實現客戶定制任務，包括時間和頻率等。

　　5.高質量的數據集市。
　　同樣由于商業銀行業務的特殊性，審計系統的數據一定要高質量，只有高質量的數據作為保證，整個數據集市項目所提供的數據才能體現出高價值，這就要求本系統在ETL 過程中一定要建立合理的質量保證和錯誤恢復機制。

　　3．ETL 模型結構設計
　　主要分為四個部分：控制臺、ODS、ETL過程和審計系統數據集市。

　　首先開發人員必須利用控制臺初始化任務，建立源數據和目標數據集市中的映射關系。

　　根據數據源的不同，建立不同的任務類型，以供用戶選擇。然后用戶就可以利用控制臺管理任務了，包括初始化任務、任務調度、異常處理和記錄日志等。

　　客戶啟動任務后，ETL過程會根據本次任務需要的數據信息從相應的數據源中抽取數據到ODS中。為什么要先將數據抽取到ODS中，而不直接進行清洗，裝載到目標數據集市中呢？ODS是目標數據集市與外部源數據的接口，并且ODS在ETL中有著緩沖和保護的作用，在業務系統和數據集市之間形成一個隔離層，避免外部源數據直接向目標數據集市寫數據。

　　將數據抽取到ODS中，開發人員就可以對ODS中的數據進行多次清洗和轉換，即是在清洗和轉化過程中發生錯誤，開發人員也不需要直接從數據源再次抽取，而只要使用ODS中的數據即可，為審計系統提供一定的容錯能力。清洗和轉換完畢后，將數據裝載到審計系統數據集市中。

　　4. ETL 的功能設計
　　4.1 控制臺
　　控制臺中又包括了任務管理、元數據管理、異常處理和系統日志。任務管理實現了任務的初始化、任務調度、任務執行等功能。元數據管理則為開發人員提供了源數據（ODS 中）和數據集市映射關系的管理。

　　4.1.1 元數據管理目前，元數據存在多種不同的描述，Luo Agostas 說元數據是一種比喻，因為它抽象了看起來完全不同的事物。在數據倉庫領域元數據被定義為：描述數據及其環境的數據。在本文里，筆者采用常用的一種描述，將本系統的元數據分為技術元數據和業務元數據。

　　所謂技術元數據主要是用來描述數據實體和數據處理過程中的技術細節和處理規則。比如數據源接口（數據庫名、端口、數據庫類型、用戶名、密碼等）、ETL 任務表（任務編號、任務名稱、任務粒度、任務號、后序任務、狀態等）、業務元數據則主要是對IT 系統的數據實體和數據處理的業務化描述，包括業務規則、業務術語、統計口徑、信息分類等。如某商業商業銀行審計系統中的企業基本信息（企業名稱、客戶類型、企業隸屬、企業類型、行業類型、主營業務、經濟類型等）、財務報表數據（報表月份、客戶名稱、報表種類、幣種等）、小額擔保貸款貼息統計（借據號、合同號、小額擔保貸款類型、客戶姓名、貸款金額、期限年、期限月、貸款發放日等）等。

　　考慮到保證系統的執行效率。元數據管理主要為數據集市的形成提供基礎數據映射分析，并且在以后的維護中提供支持。

　　4.1.2 任務管理
　　在本文中，任務的劃分按照客戶審計目標而定，一個任務即是一個審計業務數據的ETL過程，這是本文的重點。在一個數據集市的形成過程中，會涉及到很多的業務系統，因此審計系統的數據集市由很多任務組成。本系統中任務分為兩種類型：基礎任務和業務任務。基礎任務是指實現形成該審計系統數據集市所必須的所有數據，比如審計系統中客戶的基本信息，賬戶信息，企業信息等，這些都是基礎數據，無論哪個業務都必須采用的數據，所以基礎任務也是每次ETL 過程所必須完成的任務。而業務任務則是可以選擇的，依據本次審計人員的要求而決定是否導入審計系統數據集市，比如信貸業務，如果本次審計要求中不包括此業務，那么本次ETL 任務便可不處理該業務數據。基礎任務是形成數據集市的必選任務，每天只需執行一次。而業務任務則是根據每天的審計目標而選擇的可選任務。

　　在此基礎上又引入了優先級、執行時間和任務號的概念。優先級是在任務創建的同時就會確定的，優先級有三等：重要，一般，不重要。執行時間就是執行任務的時間先后。任務號是若干任務執行先后順序的依據。

　　在描述功能前，我們有必要先描述任務的生命周期。在本審計系統中，任務有五種狀態：

　　新建，就緒，執行，成功，失敗。狀態之間的轉換。

　　新建狀態：創建一個任務即添加一個新的 ETL 任務，任務的信息包括目標子任務信息和任務的創建信息（包括創建者和創建時間等等）。

　　就緒狀態：任務在被調度后，初始化其狀態為就緒，等待執行。

　　執行狀態：任務占用系統資源，同一時刻，處于“執行”狀態的只有一個任務，另外的任務處于“就緒”狀態。

　　成功狀態：任務執行完畢，并且執行過程中沒有發生異常，或者發生異常后又重新執行完畢。

　　失敗狀態：任務執行過程中發生異常，非正常結束。

　　任務狀態之間的轉換主要包括以下幾種：

　　創建新任務：創建一個新的任務，即確定一個檢測計劃，初始化任務的數據源和元數據等信息。

　　調度：準備執行任務，將其置為“就緒狀態”，隨時可以分派執行，由于同步機制的限制，系統在同一時刻只能執行一個任務。

　　分派：選擇任務并執行，進入執行狀態。

　　出現異常：任務在執行過程中，發生可恢復或者不可恢復的異常，中止執行，將其置為“失敗”狀態。

　　重置：解決異常后，重置失敗的任務，等待重新執行。

　　執行完成：任務執行過程中沒有出現異常情況，順利執行完畢。

　　任務管理模塊包括的功能主要有任務初始化、任務調度和任務執行。

　　任務初始化主要是創建任務，用戶根據本次審計目標的要求來建立一個 ETL 任務，包含任務信息和任務的創建信息。任務信息是指選擇符合本次審計目標的業務任務，基礎任務不用選擇，因為是必選的，在執行ETL 的時候，會首先執行基礎任務。

　　任務調度模塊是貫穿整個數據集市形成過程的，在此過程中監聽事件，并能夠根據事件啟用相應的任務。在此模塊啟動后，根據任務號順序執行，關于任務的任務號確定問題，本系統中采用一個較為簡單的原則來解決：在任務創建的同時已經確定了任務的優先級，結合任務的執行時間，先按照執行時間先后確定任務號，如果執行時間相同，再按照任務的重要性確定任務號，如果重要性也相同，則對二者（或者更多）隨機確定任務號。如果任務B的任務號是排在任務A 的任務號的下一位，則成任務B 是任務A 的后續任務。順序執行任務的同時要監聽觸發事件，此模塊監聽的事件可分為主要有兩種：①任務結束。在一個任務執行時，任務調度模塊會實時監控這個任務的狀態，當一個任務執行完畢后，將此任務的狀態置為完成，并將其后序任務狀態置為準備。而當錯誤發生后，首先將其狀態置為異常，然后調用異常處理模塊，處理好現場，并將該子任務的狀態置為“失敗”。并將錯誤記錄到日志中，順序執行下一個任務。②時間到達。對于一些任務，用戶希望它們定時執行，所以任務調度模塊必須實時比較它們的啟動時間和系統時間，一旦二者一致，就執行此任務。任務調度模塊一直執行到任務完成后關閉系統時才隨系統一起停止運行。

　　任務執行即是開始 ETL 處理過程。任務的執行方式分為兩種：手動和定時，手動方式隨時可以執行，定時方式則是在設定的時間自動啟動。具有管理員權限的用戶隨時可以執行任務。定時任務則要在系統內設置定時執行任務的時間，可以根據任務需求設置幾種頻率：

　　每月，每周，每天等。每天到零點時刻，系統就會添加所有在這一天內要執行的定時任務到隊列中，然后計算出到達下一個設定的執行時間的時間差，讓線程休眠相同時間，醒來后再執行。同一個任務可以多次重復執行。如果在執行任務過程中新添加了一個任務，系統會根據此任務的任務號插入到隊列中。每完成一個任務，系統就從執行隊列中選取一個優先級最高的執行。

　　4.1.3 異常處理
　　任何系統都會出現異常情況，所以異常處理模塊必不可少。在本模型中，異常處理模塊主要應對任務執行異常情況，比如數據出現亂碼，從而致使數據轉化任務出錯；正在執行抽取或導入任務時，網絡斷開，等等。

　　在出現錯誤后，本模塊會將該任務的狀態置為“異常”，然后調用相應的處理程序。對于一些任務執行過程中發生的錯誤，只需要重新執行該任務便可，比如網絡或電源斷開；而對于一些錯誤的處理則比較麻煩，比如抽取數據的時候一個表發生錯誤，并且ETL 過程已經執行完畢后發現的，這種情況下，重新執行一遍ETL 過程勢必要花費大量的時間，無論是用戶還是數據源系統都是不允許的，因此我們可以利用前面所述基礎任務和業務任務的劃分，根據任務號單獨執行出錯的任務，這種做法就大大節省了時間，從而提高了錯誤恢復的效率。

　　4.1.4 系統日志
　　系統日志模塊也是 ETL 過程中必不可少的一個模塊。它的作用在于記錄每一個任務完成情況，以及系統啟動時間和完成時間等詳細信息，以便技術人員在查看以往的記錄的時候有據可依，并且也可以從中查看一些異常情況，分析問題，解決系統無法自動解決的問題。

　　日志模塊對于管理員的一些操作也要做詳細的記錄，比如某天某個管理員沒有按照要求擅自啟動了ETL 系統，導致了錯誤的發生，或者在發生異常后，管理員做出了一些解決措施。或者有管理員利用職權竊取數據，這些都將被記錄下來，為以后的責任的追究和工作表現提供證據。

　　4.2 ETL 過程
　　此模塊是 ETL 的主要實現過程,包含三個階段：數據抽取、清洗和轉換、轉載。

　　在數據抽取階段，我們根據用戶提供的數據源方式分為以下幾種處理方式：①抽數。針對此種數據源，我們在數據源接口表中定義好了數據源的地址、端口號、用戶名和密碼，以及抽取時間后，即可定時調用任務抽取數據。②送數。由于數據源保密性要求、時間上的不合適或者網絡隔絕等條件的限制，ETL 系統只能等待數據源送數過來，或者以備份文件，或者以文本文件的形式送達。這時，我們可以監聽送數事件，當查看到特定目錄中出現數據的時候，便啟動往ODS 導數任務。在抽取任務中，我們也必須描述清楚數據的增長方式：

　　增量或者全量。增量抽取往往適用于交易信息，這類數據的特點是每天的操作不會對以前的信息造成影響；全量則適用于客戶信息、票據信息等可能被更改的數據，這些信息在各個抽取任務中都會有所體現。

　　在清洗和轉化操作階段，我們根據處理的源數據的規模大小和相關性將幾個處理過程作為一個子任務，這樣做的好處是方便實時查看進度和減少任務失敗時重新執行的時間損失，同時也最大化地利用了數據庫的緩存池。這樣的一個任務提交時，比每個處理過程執行完畢后就提交節省很多時間，而每個任務完成后再提交則有可能導致數據庫緩存池溢出錯誤，從而導致任務提交失敗。即使沒有出現錯誤，實踐證明提交一個任務比子任務需要更多的時間。

　　在裝載階段，我們采用成熟的商業工具即可，因為這類工具具有穩定性和安全性，并且在此階段，沒有太多可以優化的地方。只是在裝載前我們會停去掉表的索引，在導完數據后再統一建立，這么做的好處是提高導入速度。

　　裝載完畢后，對存在于 ODS 中的歷史數據，我們也需要定時的清理，以減少整個ETL系統負擔。針對不同的數據，清理的要求也不同，有的數據需要保留一天，以便同以后的數據對比，有的數據則可以即時清理掉。在本模型中，我們可以設置表數據的清理范圍和時間，用戶只需根據具體要求設置好執行時間，則系統會在指定時間清理指定數據。

　　5．模型的應用
　　我們將此模型應用到某商業銀行的非現場審計系統中，針對審計系統的特點對各個模塊就行了本地化。系統實際運行情況表明，該系統具有很好的效率，可靠性比較強，同時具有一定的容錯性，能很好的滿足用戶的需求。

　　6．總結
　　本文針對商業銀行系統復雜的數據存儲環境設計了基于業務的 ETL 模型，該模型將商業工具和編程實現結合起來，可以靈活地實現用戶要求，同時保持了很高的效率。本模型在任務管理模塊將業務劃分為任務，既可以按照傳統ETL 流程處理數據，也可以在發生錯誤后按照任務的任務號單獨完成目標數據庫中出錯部分，這種靈活的處理方式大大節省了時間。異常處理模塊和系統日志模塊為系統的安全性、健壯性提供了保障，歷史數據的定時清理機制也保證了此ETL 系統可以高效的完成任務。本碩士論文來源于中國碩士論文網，參考文獻：http://www.lunwenad.com/wzlb-3.html，轉載敬請保留鏈接，謝謝。

　　本系統也還存在一些不足的地方，比如對于語義異構問題沒有有效提出有效的方法，希望將來能夠改進。

【小研非現場審計系統業務的ETL】相關文章：

利用非現場審計系統進行分析性復核03-23

淺談國有商業銀行非現場計算機審計04-01

小研多變量系統的解耦與控制03-01

非接觸測距系統03-07

小研三維虛擬場景漫游系統的設計與實現03-03