隨著高校各項管理活動、服務事項的規(guī)范化、高效化，跨部門工作流程普遍增多，用戶對工作流程的連貫性、時效性要求也越來越高，這就涉及到多個管理系統之間的業(yè)務交互問題。例如，我們在與高?？蛻艚涣髦谐１粏柕溃航虅蘸蛯W工、教務和財務的數據如何交換、如何實時共享。
由于高校信息化發(fā)展的歷程特點，難以采用其他行業(yè)廣泛使用的應用集成、業(yè)務集成等架構，而是更多的使用數據集成方式實現業(yè)務交互。例如，通過周期性ETL接口推送數據到中間表的方式，就是高校信息化環(huán)境中最常見的數據集成方法。但是，這種方法在一些對實時性要求非常高的場合會面臨一些技術困難。
在3月12日一期的線上技術沙龍中，我們曾為大家介紹了一些高校常見的實時數據交換場景及解決方案，引起不少技術老師的共鳴。應老師們的熱情邀約，我們特將報告內容做了文字整理，下面就從幾個案例入手，看看解決高校數據實時問題應該從哪些方面考慮，采用什么樣的解決方案，以及方案的技術實現原理如何。
?
高校常見數據交換方案及特點
?
在談實時場景之前，我們先來看一下目前高校常見的數據交換方案都有哪些。首先是線下電子文檔。在相當長的一段歷史時間里，它都占據舉足輕重的地位，即便是現在，每個學校也都肯定存在這樣的數據交換方式。高等教育質量監(jiān)測國家數據平臺，就是一個典型的例子。后來，隨著信息化的發(fā)展，線上數據交換開始出現，基于應用間程序接口的交換，數據庫遠程訪問和利用ETL工具進行數據交換等方式開始進入高校。再后來，隨著三大平臺之一的數據交換平臺建設，數據共享庫建設，數據交換由原先點對點無法管理的方式向集中式可管理的方式轉變，最終形成了目前高校數據交換方式百花齊放的現狀。
這些數據交換方式的實時性怎么樣呢？我們大致做了一些疏理。
?
綜上我們可以認為，使用ETL工具或者集中式數據接口這兩種方式，在能夠保證實時性的前提下，可以滿足高校保障數據安全、管理數據、對外提供數據服務的需求。其中，使用ETL工具的實時性是不確定的，具體與所使用的交換方案有關。那么，都有哪些ETL工具或集中式數據接口的交換方案呢？在需要達成保障數據安全管理和對外提供服務的前提下，我們如何使用ETL工具，或者數據接口的方案，滿足高校例如新生報道、學生離校、新教工入職、一卡通充值消費記錄實時查詢等場景。下面我們將從三個案例入手，看看能否從案例中找到問題的答案。
?
?
案例1? 高校常見數據交換方案及特點
?
高校A已建設統一數據開放平臺（希嘉數據交換平臺產品，可以基于源庫封裝數據接口供數據使用方調用，以下簡稱“開放平臺”），共享庫使用數據庫的只讀賬號，通過ETL任務從一卡通前置庫每日定時采集數據，并且在開放平臺上根據共享庫發(fā)布了數據接口，移動校園通過封裝的數據接口獲取數據。移動校園中的一卡通消費流水查詢功能上線后，學生普遍反饋：為什么一卡通終端上可以查詢到實時的消費流水，但手機端卻只能查詢到一天前的消費流水，該問題被校領導得知，要求信息部門解決該問題。
步驟一
直接通過開放平臺將一卡通流水表封裝成API，讓移動校園調用開放平臺的API接口進行數據的實時查詢。該方案的本質是由數據交換變成了數據轉發(fā)，從而由原來的需要時間變?yōu)椴恍枰獣r間，轉發(fā)與交換的差異點見下圖。
?
陷阱規(guī)避
選對表。實際在一卡通數據庫里面存在有兩張記錄流水信息的表，一張表記錄當天實時的記錄，叫做未結賬流水表，另一張表記錄除過今天的所有歷史記錄，叫做已結賬流水表。所有當天的流水記錄每天需要經過財務入賬才能進進入一結賬流水表，如果只將歷史表封裝成數據接口供移動校園調用，則無法解決消費流水實時查詢問題。
?
步驟二
將未結賬流水表封直接裝成數據接口，供移動校園查詢當天的流水記錄，已結賬的流水表每日定時ETL進入數據倉庫后封裝成數據接口，供移動校園查詢歷史的流水記錄。至于為什么選擇已結賬流水表進入數倉，是因為已結賬流水表是經過財務確認過的數據，既然不需要高實時，自然需要盡可能保證數據的準確。
?
同時，針對已結賬的流水表，我們需要采用增量同步方式。下面我們具體看一下時間和增量的具體實現的過程。這里有兩張表，源表跟目標表，它們都會有刷卡時間的字段，目標表是有3月1日、2日、3日的三條數據，源表有四條數據。第一步我們會在目標表中取刷卡時間的最大值，得到的是3月3日的時間，接下來對源表數據進行過濾，篩選出大于目標表刷卡時間最大的3月3日的時間，得到了3月4日這一條記錄。最后就是對差異的數據進行同步，找到3月4日的數據，把他抽取到目標表中。
?
這是在一卡通場景當中具體的實現，如果不是基于特定的場景，這種增量的交換方式有一定的條件限制。能夠實現這種方式，首先因為一卡通流水表只會對數據做插入的操作，不會對歷史的數據做修改。還有刷卡的時間能夠真實反映數據插入的時間。除了同步插入的操作以外，時間戳的增量的方式沒有辦法同步對數據的刪除操作，如果這條記錄被刪除了，通過取最大值去過濾的方式沒有辦法找到這條數據，所以刪除操作是沒有辦法進行同步的。
?
此處我們再延伸介紹一下，除了一卡通基于刷卡時間的方式之外，如果在源表中，時間戳的字段除了反映數據的插入時間，還能反應數據的更新時間，那么數據的更新操作也可以被增量同步，這完全取決于你的時間戳所能夠代表的插入或更新的時間。下面我們看一下能夠實現插入更新的情況是怎么實現的。
?
首先還是要取到時間戳目標表的最大值，對源表做過濾操作，找到變化的數據。因為時間戳無論做插入操作還是做更新的操作，都會進行變化。所以找到差異的數據，然后跟目標表對應的數據進行對比。這里面變化的數據從過濾條件大于3月3日，3月4日的數據就有兩條，目標表中需要對比的是先找主鍵為3的記錄，發(fā)現它原來的值是趙六，這個數據肯定是發(fā)生了變化。再有主鍵為4的記錄我在目標表中并沒有找到，我可以認為它是一條新增的記錄。完成對比之后針對于剛才識別出來的差異情況做一個同步操作，將主鍵為3的數據進行更新將它替換成現有的狀態(tài)，對主鍵為4的新增記錄進行插入的操作，這就是基于時間戳增量交換實現插入和更新的基本原理。
?
陷阱規(guī)避
注意使用基于時間戳的增量交換方案，避免選擇全表對比方式。由于已結賬流水表存放的數據量很大，在一天的周期中無法完成數據的對比，將導致數據同步任務不能完成，無法查詢前一天的結賬數據。此處通過一張圖片簡單了解一下全量與增量的差異。
?
?
案例2??教工數據的實時同步
?
高校B在疫情期間，建設線上教職工每日健康信息上報的應用，要求應用建設方從開放平臺中獲取人員相關數據，但由于業(yè)務部門對人員狀態(tài)、手機號等維護的不準確，導致很多教職工反饋自己無法填報或手機號碼錯誤，信息部門也想借此機會提高數據質量，但是疲于跟業(yè)務部門溝通、跟反饋問題的教職工溝通，無法抽身專注于數據問題本身，導致忙中出亂，連本職的同步數據的工作也出現問題，進而擴大矛盾，造成業(yè)務部門和教職工用戶兩邊都不討好的局面。
?
針對于這個場景，我們發(fā)現主要矛盾集中在上圖中左邊的部分，數據交換采取了全表對比的方式。那么，我們可以通過轉發(fā)代替交換解決問題嗎？還是通過全量和增量的轉換？
?
案例2與案例1的最大差異在于，所要共享的數據既非單一來自于人事系統，也非單一來自于教務系統，而是對兩個數據庫的多張表進行了轉換，最終形成了需要共享的教職工基本信息數據。然而，轉換的方案是無法解決跨庫、異構場景問題的，所以我們無法使用轉換的方案解決案例2的問題。
?
那么基于時間戳的增量解決方案可行嗎？也不行，原因是人事、教務系統關于人員的數據表沒有時間戳字段。那還有其他的增量數據同步的方案么？
?
結合學校使用ODI作為ETL工具的實際情況，我們可以直接利用ODI中的同步CDC方式，利用觸發(fā)器的原理來識別變化數據，減少數據交換量，做到數據的高實時同步。我們來看一下ODI同步CDC的實現原理及步驟。
?
除了同步CDC方式，ODI中還提供了一種異步CDC模式，是一種基于日志識別變化數據的增量交換模式。但只有ODI企業(yè)版中才有，需單獨購買?；谌罩镜腃DC需要的權限較高，甚至要求源庫開啟最小補全日志、歸檔日志及強制歸檔模式，增加了源業(yè)務庫的存儲及維護壓力，但對源系統的性能影響幾乎沒有。
?
?
案例3??減輕源庫壓力的據實時同步
?
高校C隨著信息化建設程度的日益深入，各式各樣的分析型應用、微應用、微服務的建設，對人員數據的實時性要求越來越高，但采用傳統的高實時方案對源庫的性能已造成較大影響，影響了實際業(yè)務的正常運行。
?
?
要解決性能影響的問題，首先要減少對源業(yè)務庫直接的訪問。我們去掉從數據交換平臺到源庫的訪問，所有的交換平臺的訪問都基于數據中心的數據倉庫。第二步減少觸發(fā)操作對于源庫的性能影響。之前采用ODI的CDC方式，這種方式如果說業(yè)務數據的變化情況比較頻繁，對源庫的性能影響是比較高的。第三步是既然沒有用觸發(fā)的方式實現數據增長交換，這個空缺由誰進行補充呢？我們采用的方案是使用基于日志的存量交換方式就是OGG
OGG是一種基于日志進行結構化數據和備份的軟件，通過解析數據庫的在線日志或者歸檔日志獲得數據的增量變化，再將這些變化應用到目標數據庫，從而實現源數據庫與目標數據庫的同步。具體實現過程及優(yōu)劣勢見下圖。
?
OGG與傳統的ETL方式，數據轉換的差異。OGG方式是基于配置文件，傳統ETL是通過SQL語句。OGG配置較繁瑣，且對于復雜映射及轉換，甚至需要通過配合觸發(fā)器實現。
?
?
回顧
?
實際上數據的實時性并不是越高越好，實時性越高勢必會造成對源系統入侵性的增加，或者是對源庫運維壓力的加大，再有可能是對源庫的性能造成一定影響。所以我們在選擇使用數據交換的時候，應該在最大限度滿足業(yè)務場景要求的前提下，綜合考慮數據的體量，變化頻率，基礎環(huán)境、成本等因素，給出具體適用于特定場景的解決方案，最終能解決實際問題的方案都是好方案，不必一味追求高實時性。
?
實現數據實時交換的解決方案和具體的方法