數據交換過程詳解

?轉載本文需注明出處：微信公眾號EAWorld，違者必究。

前言：

本文主要介紹數據交換過程中常用的數據交換方法和方式以及數據交換在新技術下所面對的“挑戰”，方便大家深入理解數據交換過程。普元實施數據交換項目已有多年成功經驗，本文也將分享大數據時代數據交換所遇到的問題和應對策略。

目錄：

1、為什么要進行數據交換

2、數據交換存在的問題

3、數據交換面臨的挑戰

4、數據交換破解“數據孤島”

5、總結

1.為什么要進行數據交換

企業大量的IT投資建立了眾多的信息系統，但是隨著信息系統的增加，各自孤立工作的信息系統將會造成大量的冗余數據和業務人員的重復勞動。企業急需通過建立底層數據集成平臺來聯系橫貫整個企業的異構系統、應用、數據源等，完成在企業內部的ERP、CRM、SCM、數據庫、數據倉庫，以及其它重要的內部系統之間無縫的共享和交換數據。

數據是在流通、應用中創造價值的，這就涉及“數據共享”和“數據交換”。在實施數據交換的過程中，不同的數據內容、數據格式和數據質量千差萬別，有時甚至會遇到數據格式不能轉換或數據轉換格式后丟失信息等棘手問題，嚴重阻礙了數據在各部門和各應用系統中的流動與共享。因此，對企業內各系統異構底層數據進行有效的整合已成為增強企業商業競爭力的必然選擇。

2.數據交換存在的問題

企業對數據服務的需求日趨迫切，如何有效的管理數據、高效的提供數據服務是目前企業對所面臨的關鍵挑戰。目前集團層面客戶信息分散，各子公司之間的客戶信息無共享。內部系統獲取客戶數據來源系統分散，方式多樣難以管理，且獲取客戶數據時效性較低，供數標準不統一，缺乏統一的客戶數據服務平臺。

1. 數據平臺中數據內容繁多，難以全面掌控。

通過多年的信息化建設和運營，企業已經建立了完善的業務應用系統，有效的支撐了核心業務的創新和發展，但隨著應用系統的增多，數據量和數據應用環境增大，在對這些數據進行使用的過程中逐漸存在不合理、不統一的問題。

2. 數據平臺中數據的流轉和邏輯過程復雜，難以追溯數據來源。

許多企業目前沒有統一的數據資產標準，各業務系統中數據質量參差不齊，存在信息孤島現象，不同部門同一名稱數據可能有不同的含義，同一個數據可能又有不同的命名，數據有效交互和共享存在問題。存在部分系統數據更新不及時的問題，核心業務數據無法朔源，數據的準確性和及時性較低，現有報表在建模時幾乎每個報表都要重復建模，人為參與工作過多且層次復雜，無法高效的對流程及指標進行精確監控及分析，數據的利用效率和模型重復使用率較低。

3. 業務部門對數據結構和質量無法管控

目前數據管控的發展方向和需求是由業務部門提出，但業務人員對公司復雜的系統無法進行全面深入掌握，特別是技術層面。為了使業務部門從數據結構到數據質量上更好的管控，梳理業務系統與數據庫結構關系，成為目前急需解決的問題之一。

3.數據交換面臨的挑戰

隨著互聯網以及大數據等諸多新技術的發展，傳統的數據交換面臨著許多挑戰。

1. 傳統方式一般是以單表數據交換作為單位進行作業開發，隨著企業中數據庫以及表的增多這種方式的開發效率低下、容易出錯。整庫數據交換時工作量巨大

2. 傳統方式下開發交換模型只能手工一個一個進行，任務多、易出錯。需要一種能夠在同一種業務下批量進行開發的模式

3. 在進行實時數據同步時需要許多額外的操作配合才能完成，過程復雜，對人員技術要求高，

4. 在進行PB級數據交換時傳統交換方式效率較低，需要很長時間才能完成。

5. 傳統的數據交換工具不具備業務化的開發能力，遇到相同的數據交換需求需要重頭開發。

6. 在安全保障上傳統的方式是手工編寫加密、脫敏的腳本來實現

7. 進行跨區域數據同步時需要多種技術配合，實現方案復雜。

4.數據交換破解“數據孤島”

4.1 數據標準

為保證各應用系統中的代碼表對同一業務信息定義一致，確保數據消費系統可以根據業務代碼辨別數據的確切業務含義，應提供可配置的功能，基于一定的標準對數據供應系統代碼進行轉換，使數據存儲和數據消費系統按照統一標準來理解數據。

數據交換離不開數據標準，數據未動標準先行是構建優質數據交換的前提。但現實中許多企業沒有做好數據標準，導致這些標準是在進行數據交換或數據采集的時候進行，影響了數據的質量。一旦出現數據被篡改、被泄露等安全性問題，輕的影響業務開展，嚴重的泄露核心機密造成企業重大損失。拷貝的數據難以控制準確性和合規性，拷貝的數據流向哪里也無法控制，是誰拷貝了信息也無法掌控。一旦出現信息泄露，無法追責。

統一指標數據標準，可以規范業務統計分析語言，幫助企業提升分析應用和監管報送的數據質量，進而提高全行數據質量和數據資產價值。

4.2 自動采集元數據

數據交換依托于元數據，數據交換的本質是基于元數據的交換。對半結構化和結構化數據自動采集。

元數據是關于數據、操縱數據的數據和數據庫系統的結構和意義的描述信息，重要目標就是提供數據資源的全面指南。元數據不僅定義了數據交換中的數據模式、來源以及抽取轉換規則等，而且整個數據交換系統的運行都應該是基于元數據的，是元數據把數據交換系統中各個松散的組件聯系起來，組成了一個有機的整體。

通過自動化的元數據采集完成部門核心職能的業務梳理及其對應的信息資源梳理，編制部門信息資源目錄，摸清信息資源有什么、在哪里，提高信息資源共享程度，建立信息資源共享機制和管理制度。結合企業內部信息系統中的數據現狀和企業業務屬性、技術屬性的要求形成企業數據標準的業務屬性和技術屬性，制定有效合理的指標數據規范要求。

4.3 數據交換方式和方法

4.3.1 不同類型數據交換方式

新的數據交換平臺提供數據、報文文件等多種數據交換服務，能夠快速建立跨硬件平臺、數據庫和操作系統的可交互操作的數據交換與信息共享平臺，交換平臺提供了一個開放的環境，支持多樣的客戶機、數據庫、網絡和通訊協議，通過可視化配置實現與數據庫、文件以及web接口的數據交互。使得數據交換與業務邏輯的個性有機結合，快速響應數據集成和外部數據交換的需求。

數據交換的方式一般是根據數據的類型來進行區分，如結構化或半結構化的數據可通過ETL的數據交換方式進行，非結構化的數據像壓縮文件、電影、圖片等采用文件傳輸的方式進行交換，而對于一些實時性較高的交換一般采用接口形式進行。例如：restfull、webservice等。

結構化數據交換方法

結構化和半結構化數據交換主要有：時間戳同步、全文比對同步、觸發器同步、CDC增量同步、全量同步。

這里我們對幾種做一個比較：

全量同步

全量抽取一般適用于統計分析或無需進行二次更新的業務需求，通過全量抽取一次或多次將業務系統數據源在不做任何操作的情況下直接抽取過來，全量數據抽取方式雖然較簡單、直接、快速。通過系統中的采集組件，無需增加過濾條件，即可對數據庫中的全量文件進行一次性采集。全量采集比較適合于數據業務量小的業務需求。這種方式不能增量的進行數據同步，對于大數據量下的同步并不適用。

時間戳同步

使用這種方式進行增量數據抽取的前提是源數據庫與目標數據庫都必須有時間戳字段。先讀取目標數據庫中的最大時間，然后以這個時間作為參數從源數據庫中讀取大于這個時間的所有數據。

基于時間戳的方法需要相關應用系統中的每個表中都有一個時間戳字段，以記錄每個表的修改時間。這種方法不影響原有應用的運行效率，但如果表中沒有時間戳的字段卻需要對原有系統做較大的調整，這種方式不能捕獲到那些并非通過應用系統引起的操作數據變化。

優點：處理速度快，數據處理邏輯相對簡單。

缺點：源數據庫沒有時間戳字段的表需要更改表結構，而且需要源數據庫來維護時間戳字段；無法實現數據同步，因為使用時間戳字段無法獲取刪除后的數據。

CDC增量同步

通過分析數據庫日志的信息來捕獲復制對象的變化序列。這種方法不僅方便，也不會占用太多額外的系統資源，對任何類型的復制都適合，不但能提高效率和保證數據的完整性，還能在對等式復制時提供詳細的控制信息。但由于數據庫日志的格式是不公開的，因而不得不基于某一固定的數據庫日志分析工具或接口，這給異構數據庫復制帶來了問題。

優點：可靠性強，對源系統沒有影響。

缺點：各數據庫系統的日志文件絕大部分都是私有的，并且日志格式都不一樣，因此捕獲這些日志需要有專門有針對性的組件來進行，個別數據庫還需要管理員權限進行配合才能實現。對于沒有提供日志分析接口的數據源，開發的難度比較大

觸發器同步

在業務數據表中創建相應的觸發器，當提取、復制對象進行變更（插入、修改、刪除）時，由觸發器觸發提數程序，將變化寫入目標數據庫中。這種方案可用于同步復制、增量復制。

優點：借助數據庫本身的機制，可靠性強。

缺點：對源系統有影響，需要建立觸發器以及臨時表或臨時數據存儲文件

全文比對同步

對前后兩個時間點取業務數據表的全量進行數據比對，比對出來有差異的部分就是數據增量的部分。此法可以用于一段時間后進行數據的強制同步，但由于消耗資源較大，因此一般建議用于業務空閑期使用。

優點：對源系統沒有任何影響。

缺點：面對海量數據（千萬級、萬萬級）進行比對時有一定的性能問題。

這些同步方式除了全量同步，其他幾種都需要業務表有主鍵。這些同步的方式各有優缺點，在實際使用中應根據企業系統自身實際情況來采取適合的交換方法。網上有許多人推薦使用CDC的方式，CDC這種架構下數據寫入主存儲后會由主存儲再向輔存儲進行同步，對應用層是最友好的，只需要與主存儲打交道。主存儲到輔存儲的數據同步，則可以再利用異步隊列復制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支持CDC技術。另外這種方式在一些數據庫中需要有DBA的權限配合才能夠完成，所以在進行CDC同步的時候首先就需要考慮數據庫的環境是否有條件能夠完成CDC的配置。

觸發器、時間戳、全文比對以及方式都能夠支持斷點續傳，所使用的方式各不相同。

觸發器數據同步的過程是先將增量數據同步到臨時表中，這個臨時表會增加兩個字段，一個是所做操作的標識(標識有：insert、update和delete),另一個是自增的列。在進行同步時是查詢這張臨時表來進行的，再查臨時表時會使用自增的列進行排序進行查詢，檢查尋到的增量數據通過組件到目標庫中根據操作標識進行相應的操作，操作完成后如果成功執行則會去臨時表把已經同步的增量數據按照自增列的值進行刪除。如果這個過程中在向目標同步數據時出現異常，則這張臨時表中的數據不會被刪除掉。而我們在進行作業觸發時一般使用的都是按照頻度、計劃去定期執行，當前這次同步失敗后，在下一次計劃觸發執行時由于上一次所執行的作業最后并沒有將臨時表中的作業刪除，在這次作業執行時上一次沒有同步的數據還在。所以這次執行時就會從斷點位置開始再次進行同步。

時間戳數據同步的過程是首先到目標表去根據時間戳使用數據庫中的獲取最大值的函數(一般數據庫使用MAX函數)來查找時間戳里的最大值，然后使用這個最大值去源表找大于這個值的數據(同時需要根據這個時間戳進行排序)，這些查找到的數據就是我們需要同步的增量數據，時間戳這種方式不能區分這些數據是插入還是更新的操作。那么接下來使用的是數據平臺提供的插入更新組件，這個組件會在執行操作前先根據主鍵到數據庫中查尋一下數據如果有則執行更新，如果沒有則執行插入。這樣進行數據同步，如果在執行過程中出現異常那么目標數據庫就沒有同步這些增量數據。同樣我們在進行作業觸發時使用的都是按照頻度、計劃去定期執行，當前這次同步失敗后，在下一次計劃觸發執行時由于上一次所執行的作業沒有進入目標表，在這次執行作業時從目標表查找的最大值就沒有變化。所以這次執行時就會從斷點位置開始再次進行同步。

全文比對的過程是先從源和目標中將數據按照排序字段先進行排序然后抽取出來，經過比對組件計算得到變化的狀態(insert、update和delete),最后根據得到的變化狀態將數據同步到目標表。如果在這一過程中發生異常，那么這次同步的數據就沒有進入目標表，在下一次計劃觸發執行時由于上一次所執行的作業沒有進入目標表，在這次執行作業時又會重新進行比對得到斷點位置又會再次進行數據同步。

CDC數據同步的執行過程是根據日志記錄的偏移來從日志中找出需要同步的增量數據，然后到目標表根據操作標識進行數據同步完成后修改日志記錄的偏移，那么作業在執行過程中出現異常時，這個日志的偏移量沒有改變。在進行性下一次數據交換時還會從這個偏移量的位置進行，從而實現斷點續傳。

非結構化數據交換

以前的非結構化的數據交換，常常使用網盤或者FTP傳輸文件時，尤其是大文件，容易出現中斷，嚴重影響工作效率和業務。

數據交換平臺中采用了數字簽名、時間戳、報文加密的方式對傳輸的消息進行完整性驗證，防止消息在傳輸過程中被篡改。通過數據交換平臺可以驗證消息確實來自于其真正的發送者而非假冒；確保消息的內容沒有被修改；防止以插入、刪除、調換或修改等方式篡改消息。

交換平臺中的文件傳輸具有以下特點：

數據包裹傳輸方式防止數據被篡改

采用全新數字包裹數據傳輸方式，有效防止數據被惡意篡改。

加密傳輸和存儲保障數據安全性

提供文件安全交換加密傳輸和存儲。采用私有文件傳輸協議和SSL安全協議訪問。提供文件效期控制，支持文件自動清除銷毀。

支持斷點續傳錯誤重傳確保數據高效流轉

采用超高速傳輸協議，支持超大文件和海量文件傳輸。支持斷點續傳，錯誤重傳，文件秒傳和文件校驗。

下面列舉了平臺中文件傳輸中所使用到的技術：

文件校驗

平臺采用單向散列算法用于文件的完整性驗證，在文件傳輸之前會使用單向散列算法生成文件唯一摘要信息，在文件傳輸后會將收到的文件再次使用單向散列算法生成摘要信息和之前的摘要信息進行比較。

斷點續傳：

斷點續傳是在下載或上傳時，將下載或上傳任務（一個文件或一個壓縮包）人為的劃分為幾個部分，每一個部分采用一個線程進行上傳或下載，如果碰到網絡故障，可以從已經上傳或下載的部分開始繼續上傳下載未完成的部分，而沒有必要從頭開始上傳下載。用戶可以節省時間，提高速度。

壓縮傳輸：

在文件傳輸時先將文件進行壓縮，然后傳送壓縮文件到目標，最后進行解壓和清除工作，壓縮傳輸能有效減小文件體積節省傳輸帶寬。

文件切片：

切片傳輸是將文件進行切片，每一片形成一個傳輸線程進行傳輸。采用并行的數據流傳輸管道，有效地將傳輸速率最大化。

4.3.2 實時數據交換

打破信息壁壘和信息孤島，實現統一高效、互聯互通、安全可靠的數據資源體系，實時數據交換是推動信息跨部門跨層級共享共用數據中心的重要環節。實時數據交換適用于對于數據時效要求快速、高頻度、少量數據傳輸的場景。實時數據交換通過將數據中心庫中的數據快速的發布出來提供給外部系統共享調用，同時能夠監控外部調用數據的情況提升數據的價值。

在新的Web服務共享下數據交換平能夠自助的、一鍵式將數據中心庫(包括常見的關系型數據庫MySQL、oracle、sqlserver等，或Hbase、Hive、MongoDB)中的數據通過標準的Web服務發布出來。用戶只需要配置發布數據中表和表之間的關系以及發布的字段就能夠實現單表、多表或數據實體的發布。發布出的服務帶有對輸入輸出以及調用url的詳細描述信息，消費方能夠很方便的對這些信息進行查看和訂閱。

服務方能夠對訂閱的信息進行審批，審批通過后消費方才能根據審批信息，配置服務調用參數調用服務。服務方通過對訂閱信息的管理和監控能更好的掌握和發掘數據的價值。

4.3.3 數據驅動的交換

變化數據捕獲簡稱CDC，這種方式主要應用于增量數據同步并且實時性要求較高的場景。這種架構下數據寫入主存儲后會由主存儲再向輔存儲進行同步，對應用層是最友好的，只需要與主存儲打交道。主存儲到輔存儲的數據同步，則可以再利用異步隊列復制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支持CDC技術。而目前每種數據庫實現CDC的方式和方法各不相同，于是就需要根據數據庫類型定制化的進行CDC的開發。

CDC的數據同步具有低影響、低延遲、高性能等特點。這里以mysql為例采用Canal來說明實現CDC數據同步。canal利用了mysql的slave協議將自己偽裝為mysql的一個子服務器，向mysql master發送dump協議mysql master收到dump請求，就會將記錄的日志信息給slave(也就是canal)，canal解析日志信息獲取需要同步的數據,數據交換平臺通過Canal組件監聽Canal服務獲取到變化數據交給之后的增量數據輸出組件根據CDC所捕獲的操作類型(類型有：insert,update,delete)對目標數據庫進行相同的操作來完成數據同步。

這里Canal通過對日志數據的監聽觸發。

4.3.4 指定周期的交換

數據交換平臺作為一個批量數據處理系統，每天都會進行大量的數據處理作業，這些作業之間可能存在復雜的時序關聯，因此必須有一個具備一定自動化程度的調度層，來實現作業有序、高效的執行。

作業在運行前都需要在統一調度系統中注冊，注冊成功后再由調度系統自身的調度管理根據配置的任務計劃決定作業的執行次序進行資源調配。

調度包含以下內容：

觸發方式：在調度管理中定期根據日歷、頻度進行作業觸發。
作業次序：觸發后作業會根據之前設定好的數據性進行作業排序調整作業次序。
任務計劃：任務計劃會按照配置好的任務執行周期來進行任務調度。
資源調配：在執行調度的時候會根據注冊的作業服務器的狀況進行資源分配執行傳輸任務。

4.3.5 事件驅動的交換

數據交換平臺在與用戶的系統進行集成式往往會遇到客戶系統需要直接運行交換作業的情況，為此數據交換平臺提供了一套基于事件觸發的作業運行機制。能夠通過文件監聽或者http調用來與用戶的系統進行集成。

交換服務能夠通過監聽文件目錄或端口，當目錄中有符合作業觸發規范的文件時或接口被調用時，對文件中描述的計劃按照之前設定好的數據性進行作業排序調整作業次序觸發執行，并刪除監聽到的文件。整個觸發執行過程都會進入日志信進行留痕。

4.4 新方式迎接數據挑戰

4.4.1 批量數據交換

在進行數據交換時往往遇到的情況是要將整個庫中所有的表進行遷移或同步，這些遷移或同步的大體邏輯往往相同，但庫中的表非常多，傳統的數據交換中是一張源表對一張目標表進行作業任務開發，造成開發人員巨大的工作量，表中的字段和和類型在進行配置時容易出錯，效率低下。

批量數據交換采用作業模板作為業務規格定義，結合資源目錄能夠通過簡單地可視化操作批量數據源，對數據源進行批量的數據交換處理。批量數據交換有以下特性：

基于作業模板實現業務能力定義
可批量進行整庫的數據交換
自動控制數據交換中的各種數據轉換
自動進行數據分批次交換傳輸
對交換的數據可配置數據脫敏

通過批量數據交換加強了大數據量的交換能力。配置、部署、運維簡單，能夠有效提升開發人員的開發效率和質量。

4.4.2 跨區域數據交換

跨域的數據交換在實際應用中，每個單位或部門從安全的角度考慮，都會設置前置機和防火墻，以及根據需求雙方商定通訊方式編制相應的交換策略。因此，實施難度會加大，實施進度也會拉長。

以前遇到跨區域數據同步往往是先將數據轉換為文件，然后通過p2p文件傳輸將文件發送到目標節點，最后目標節點拿到文件再將文件通過轉換導入到目標數據源中。

新的模式對下面幾個因素都要考慮周全。

簡單。交互的設計要簡單，這對調用雙方都有好處。
安全性。如何保證數據在交互過程中出現各種異常的情況下，數據不出錯、不丟失。
性能。在選擇的時候，要考慮數據量的大小，以決定一種合適的交換方式（比如：一次調用請求的數據量，請求調用的頻率）。

在新的交換模式下通過對節點的管理和注冊，結合了文件傳輸高效、安全、穩定的特性，在進行跨區域數據同步時只需要配置源和目標的數據庫信息按照既定的業務邏輯就能夠完成跨節點的數據交換，文件傳輸的過程自動交由數據交換平臺完成，減輕了跨域數據同步的復雜度。

4.4.3 應對大數據的挑戰

傳統 ETL 主要以 SQL 為主要技術手段，把數據經抽取、清洗轉換之后加載到數據倉庫。但是在如今移動互聯網大力發展的場景下，產生大量碎片化和不規則的數據。這中間的數據導入和 SQL ETL 的提取的過程，大量消耗 IO 性能和計算資源，在很多場景下已經是數據處理的瓶頸所在。

Spark通過在數據處理過程中成本更低的洗牌（Shuffle）方式，將MapReduce提升到一個更高的層次。利用內存數據存儲和接近實時的處理能力，Spark比其他的大數據處理技術的性能要快很多倍。

新的數據交換中我們開發了 FlumeOnYarn 的架構，基于 XML 描述的可編程的函數 ETL 轉換方法。這種方式充分利用了Spark對大數據的處理能力，通過XML文件描述源和目標以及中間的轉換過程就能夠控制Spark對數據進行ETL過程處理，在應對Hadoop、Hive以及Hbase等任務處理時能夠充分體現出大數據處理的優勢。

4.5 監控與管理

4.5.1 監控保證運行的穩定

交換平臺的監控需要獲取交換服務器的CPU、內存以及磁盤，在作業運行時首先根據負載算法將收集到的CPU、內存和磁盤信息進行負載運算，判斷那臺交換服務器的負載較低，將作業分發到負載較低的交換服務器上運行。

負載均衡解決了單臺作業服務器在進行多作業并發時數據ETL過程壓力過大的一種多節點負載方案。通過負載均衡將多個作業服務器節點組合，將作業通過負載算法分攤到這些節點上進行ETL過程。使這些作業服務器能以最好的狀態對外提供服務，這樣系統吞吐量最大，性能更高，對于用戶而言處理數據的時間也更小。而且，負載均衡增強了系統的可靠性，最大化降低了單個節點過載、甚至宕機的概率。

4.5.2 對各個運行環節的監控

在數據交換過程中，監控管理系統負責監控作業的運行和調度情況，統計交換的過程和數據，形成圖形化的報表進行統計的數據展現。能夠清晰地體現數據交換過程的各種狀態和數據量。

數據交換平臺提供了總攬全局的總體監控和明細型的計劃監控以及事件監控；可視化的多維度作業運行監控以及完善的資源監控功能，對作業以及和作業相關的節點進行數據監控和統計。可統計作業交換過程中的調度日志、作業執行日志、歷史日志、交換的數據量以及統計數據交換的成功失敗次數，可以保證在第一時間發現系統存在的問題，并且及時排除，保證系統的正常運行。