數據稽核可以理解為數據質量管理的一部分，當然也是屬于數據治理的大框架范疇。在主數據管理平臺的建設和實踐中，往往會構建數據質量管理模塊進行相關的數據質量檢查等工作。

由于數據管控和治理工作本身是各個企業信息化建設中都相當關注的內容，而且大部分的業務協同，流程斷點等問題往往都和數據一致性和準確性密切相關，因此數據稽核平臺的建設也逐漸從主數據管理平臺剝離出來，形成一個獨立的系統。在講數據稽核前，還是給IT系統建設中的數據稽核一個簡單的定義。在IT應用建設中的數據稽核往往是指對分散在多個業務系統中的同一類數據進行的數據檢查和核對過程，以解決數據準確性和一致性問題。?

數據稽核概述

數據稽核是企業進行數據質量管理的一個關鍵舉措。即首先建設數據質量管理部門和管理結構，并設置明確的質量標準和質量管控體系，并基于質量管控體系和管控流程，對數據展開稽查，稽核，比對等各種質量管理工作。同時對發現的數據質量問題，通過流程驅動進行數據的修改和修復，在修復后進一步觸發后續的持續檢查和迭代，以形成一個完整的數據質量管控閉環流程。而數據數據稽核系統作為數據質量管控中重要的環節提供技術和數據平臺支撐。

數據稽核是數據質量管控的一個核心內容，重點就是實現數據的完整性和一致性檢查，提升數據質量，數據稽核是一個從數據采集，預處理，比對，分析，預警，通知，問題修復的完整數據質量管控鏈條。 我在前面也談到過，在當前的應用和架構下，企業業務系統間的數據集成模式導致了核心的主數據和跨系統共享的動態數據全部落地，由于本身數據集成的問題或者由于數據源頭管理不善等原因導致了大量的數據不一致性。雖然一直在做數據清理工作，但是這種不一致性和問題將持續存在于整個應用架構體系里面。

數據稽核的核心過程說明

數據稽核平臺核心實現邏輯并不復雜，簡單來說就是采集各個業務系統的數據進行分析和比對，得出最終的稽核結果和報表，然后觸發問題修改和修正，持續迭代和閉環。因此數據集合核心過程可描述如下：

數據稽核的整個流程首先是數據的采集和適配。這個常見方式是通過ETL工具來完成，ETL工具采集到的數據做初步的數據清理和預處理。在這個步驟完成后根據預定義的數據稽核和校驗規則，對數據進行差異分析和異常分析，對于分析的結果，一方面是實時的預警和通知，一方面是根據預先定義的報表模版生產數據稽核統計報表。

以上完全可以配置為一個自動化的流程，當然對于核心的業務對象或實體，我們還可以定義稽核的時間范圍，稽核的業務規則進行實時的數據比對工作。其次是跨系統的數據比對數據比對本身是一個由粗到細的過程，首先是數據表級別的比較，但是這個往往并不需要；然后是數據表中記錄層級的數據比較，A系統同步了一條數據到B系統，是否正常成功同步到，首先要比對的就是兩個數據表的key值關聯是否存在。行記錄級別比較完成后是字段級別的數據比對工作，字段級的比對分為兩個層面，一個是數據表表結構和字段結構元數據的一致性，如相同的表兩邊字段數量不一致，相同的字段的字段類型或長度不一致等；其次是字段內數據和內容的一致性比對。

還有些數據稽核工具會提供數據參考完整性和通用性業務規則校驗的功能，但是這個不是數據稽核的重點，更多還是應該是業務系統自身去做好參照完整性控制工作。最后談下數據稽核應該是一個高度可靈活配置的產品平臺，其中包括了稽核流程可以配置，ETL和元數據定義，字段映射可配置；數據稽核規則可配置，報表模版可以預定義和配置；預警和通知規則和配置。有了這些靈活的可配置能力后，數據稽核平臺基本就可以應用到很多類似數據稽核和比對的場景中。大數據相關技術在數據稽核中應用

接著談下大數據或海量數據處理技術在數據稽核整個解決方案中可能的應用場景。

對于數據采集和ETL部分

這部分可以基于傳統的ETL工具或模式來完成，對于非結構化文件或日志的采集可以通過Flume等分布式開源數據采集平臺來完成。對于數據采集部分主要是數據采集和傳輸效率的提升問題。對于數據采集，可以搭建分布式的數據采集集群，如果對于單個ETL不拆分，那么可以對多個數據庫，多個數據表的數據采集均衡分配到多臺數據采集和處理服務器上，實現數據的并行采集處理，加快數據的采集速度和降低IO瓶頸。

對于實時采集方面，可以考慮直接采用類似BinLog日志采集模式，可以實時的采集到變更數據。對于ETL而言，首先對于數據的unLoad和Load過程，最好的方法就是采用適配數據庫的原始批量數據文件導出和導入接口，例如Oracle的SqlLoader，Sybase和SqlServer數據庫的BCP工具等，這種原生接口對于大數據批量導出性能最好，而且導出的文件還可以在ETL處理過程中進行壓縮傳輸。

對于上億條記錄的大表，那么單個表的導出本身也是一個相當耗時的工作。在這里我們可以考慮對這種大型表進行行拆分和列拆分操作，將一個任務作業拆分為多個子任務，每個子任務分配到集群中的多個節點機去運行，最好進行數據的匯總處理。在這塊暫時沒有做過具體的試驗，無法預估實際的效果和性能提升情況。對于ETL中的Transfer部分，在Oracle的ODI工具中我們看到，已經將ETL更多轉換為了ELT模式，即在數據采集完成后在目標端數據庫再做具體的數據轉換和處理等相關工作。在這種情況下將比傳統的ETL方法獲取到更高的性能。如果仍然是采用類似ELT模式的數據采集和處理，可以考慮將轉換規則進行分步驟的拆解，將步驟分解到多臺節點機器進行處理再進行最終結果的歸并，類似MapReduce的并行計算模式?？傊?，對于數據采集部分我們期望達到的就是并行采集，并行寫入，同時在處理環節進行數據分流和數據轉換。在傳輸過程中做好數據的壓縮，提升數據采集和寫入的性能和速度。

對于數據處理和分析部分

對于數據分析部分是另一個很重要的內容，在大數據總體解決方案中也經常談到數據分析部分的性能問題。在這里有商用的GreenPulm，開源的Hive，也有針對MySQL數據庫的開源Infobright等。在這里的幾個重點是分布式數據庫集群，內存數據庫，列式數據庫，MPP大規模并行處理，數據庫DaaS層，數據查詢任務分解和匯聚等關鍵詞。對于數據分析部分最關心的還是在海量數據下面的查詢效率問題。對于數據稽核中存在基于某種規則的實時性的數據分析和一致性比對工作，而這種是典型的海量數據下實時查詢和匯總統計過程。因此在我們對目標數據庫的考慮上不再是簡單的單數據庫模式，而應該是一種支撐高性能和線性擴展的數據庫集群模式，在這種模式下可以很好的解決數據查詢的性能問題。對于定時處理的數據稽核任務，也存在數據處理的效率問題，對于電信行業話單和計費結算數據的比對分析往往需要7，8個小時才能夠完成。說明在數據處理過程中還有很多具體的性能提升點。包括數據稽核規則本身的分解，將稽核任務分配到多個節點去運行然后再進行數據的聚合。個人認為在數據稽核中的數據處理部分MapReduce有很多具體的用武之地，而我們更多的是需要考慮如何對MapReduce框架根據典型的數據稽核規則場景進行更好的二次封裝，能夠方便規則更加靈活的配置和調度。

對于實時數據分析和比對

對于這個有明確的需求場景，即實時采集數據并動態的監控數據差異化和比對情況。這個將是后續數據稽核平臺的一個重要發展點。在這種場景下基本基于一種持續的不落地的數據流處理方式。實時流處理打破了傳統的數據分析和處理的模式，即數據最終積累和落地后再針對海量數據進行拆分處理，然后進行分析統計，傳統的模式很難真正達到實時性和速 度要求。而實時流處理模型的重點正是既有類似Hadoop中MapReduce和PIG一樣的數據處理和調度引擎，解決了直接通過輸入適配接駁到流的入 口，流實時達到實時處理，實時進行分組匯聚等增量操作。在這種模式下一個重點就是前面談到過的對于數據稽核規則需要進行拆分，形成多個可以并行處理的PE任務，對實時達到的數據流進行處理，形成某種結果信息后再向后續節點推送，最終實時的監控和查詢數據比對結果。這是一種實時動態監控的模式，對于在實時性要求高的數據質量監控中可以使用。

數據稽核平臺構建

對于數據稽核出現的場景，最主要的可以理解為兩個方面：其一是同樣一個基礎數據或共享數據在多個業務系統中各自維護，出現數據不一致或者說無法映射的問題；其二是在我們數據集成的實現過程中，將同樣一份數據分發和同步到多個業務系統中，同時由于數據集成本身出現問題，或者說目標業務系統本身允許了對數據的CUD操作都會導致隨著時間的變化同樣的數據變來不一致。

對于數據不一致或數據缺失帶來的最大問題就是影響到跨多個IT系統的流轉。類似的場景有很多，類似項目信息從項目管理系統同步到采購系統后，可能發現項目類型本身不對導致無法根據項目下達采購訂單?；蛘哒f一個完整的采購訂單從采購系統同步到ERP的時候會發現因為ERP缺失了某個物料而同步失敗。這些都直接影響到我們的業務協同，而我們往往經常的應對就是出了問題才通過IT系統手工從后臺修復數據或者進行數據清理后重新導入或同步。

對于做IT系統日常運維的人員來說，運維中本身硬件環境或服務器宕機的時候往往很少，而更多的時間都在手工后臺修改數據，同步數據，解決數據不一致的問題。前面剛好談到過我們經常的思維都是解決問題應該從源頭抓起，類似數據不一致的問題應該嚴格的控制住數據源頭并制定相關的數據管理和治理規范，但是實際的情況確是從根源上解決問題的方法看起來很完美，但是短期有諸多業務本身方面的原因而無法落地。

那么在徹底從根源解決問題和出了問題再手工解決之間就有一個更好的解決方案，即我們可以提前的發現數據不一致的問題并預警，而不是真正到了業務協同出現問題再去臨時應急。而一個優秀的數據稽核平臺就是基于以上背景條件產生的。一個最小化的數據稽核系統核心應該包括三個方面的內容：其一是數據采集和存儲，其二是規則引擎，其三是數據分析和展示。而一個高效的數據稽核系統必須具備數據不一致的準實時預警能力，對于準實時的實現本身又包括了數據采集的準實時和數據分析的高效性能。

首先來談下數據采集和存儲，前面談到過基于ETL技術來實現數據采集，在ETL方式下要實現數據本身的準實時采集是相當困難的。而真正可以考慮的方式則是類似數據實時復制和同步技術，對于Oracle數據庫我們可以采用Logminer實時捕獲增量歸檔日志信息，對于Mysql數據庫可以采用Binlog日志分析等。但是這里面一個重點就是需要對業務系統本身的DB數據庫開放相關的權限和初始化參數，能否推動業務系統去做這個調整本身存在困難。采集回來的數據存儲在哪里？常規做法是仍然存儲在關系型數據庫里面，那么我們可以想象下如果對于兩張相關結構的有50個字段的數據庫表。

兩張表如果都有1000萬條數據，如果我們要比較出兩張表存在的數據差異，對于這種大量的全部掃描和比對，性能本身是存在大問題的。正是由于這個原因，我們可以考慮將采集來的數據直接導入到HDFS庫里面，然后采用大數據分析方法和技術進行數據比對。而數據入到HDFS，當前的Sqoop組件是支持增量數據采集的，即可以通過我們制定的關鍵字段對源表數據進行增量采集。這種采集方式雖然比不上實時的數據同步復制，但是滿足準實時性的要求基本不會有太大的問題。

其次，我們來談下數據分析，對于這種數據稽核本身的數據量如果在大數據環境里面本身就是小數據了，你當然可以采用Hive進行數據比對分析，但是性能估計也很難好太多。更好的方法則是采用Spark進行相應的數據比對分析，由于Spark本身是基于內存計算的，對于這種量級在內存中進行分析是最合適不過的。同時當前Spark本身就已經支持Spark Sql和Hive集成，也支持直接的JDBC集成等。這些都為數據比對分析上提供了相當的方便性。還有一種設想就是是否可以將數據庫的變更日志信息直接送到類似kafka的消息中間件中，采用通過spark和kafka的集成即可以實現類似數據采集的流處理和后續的內存計算分析，整個過程中由于數據本身不會二次落地都直接在內存中完成，整體性能的提升應該更大。

最后，談下數據稽核平臺里面另外一個重要的內容即規則引擎，規則引擎本身就是需要將數據稽核的各種校驗方式和規則全部做到可配置化，即任何一個稽核流程都可以通過規則配置出來。比如我們需要檢查三個業務系統中三張表數據的一致性，具體的檢驗規則是如何的，轉換規則是如何的，當發現不一致的時候預警規則是如何的都需要做到靈活可配置?？膳渲玫臄祿艘巹t最終需要動態來生成數據稽核算法，或者說動態來生成稽核SQL語句等，這個也是整個稽核平臺里面最難的部分，只有實現了該點整個數據稽核系統才談得上是一個可以靈活可擴展的稽核平臺。

對于數據稽核的結果，稽核平臺本身應該提供上層分析報表能力，但是如果考慮到稽核結果的實時性，即數據稽核的結果應該可以通過消息發布訂閱的方式向外部發布。只要訂閱了某類數據稽核結果的訂閱方，都可以實時收集到最終的數據稽核結果信息。將Spark和流處理，消息中間件，規則引擎等技術應用到數據稽核系統絕對不是大材小用，而是大數據技術能夠更好的服務于傳統業務系統，解決業務系統問題的重要嘗試。即并不是我們的業務系統必須到了海量數據存儲后才談得上用大數據技術，而是在業務需求本身在實時性，效率，架構可擴展性等多個方面都可以采用大數據技術來解決真實業務場景下的業務問題。