前言
數據時代，企業對技術創新和服務水准的要求不斷提高，數據已成為企業極其重要的資產，數據同步也成為企業數據開發和使用一個繞不過去的技術需求。可能某一天會上，一項數據同步的需求就從產品同學或者領導口里蹦出來，然后加到你的工作任務里邊。那么，什么時候我們需要進行數據同步，甚至是實時同步呢？目前又有什么實時同步方案？
Tapdata產品合伙人徐亮有着豐富的大數據產品及項目經驗，本次為我們分享了實時同步的5大典型應用場景以及目前的4種實現方案，並對實現方案進行了解讀和考慮要點。在此基礎上，分享了新一代異構實時數據同步產品Tapdata Cloud （小重點：免費開放使用）的實現方案，我們也把研討會PPT分享出來，有需要的同學可以點擊下載。
典型的實時同步應用場景
1 數據庫異地災備
以傳統金融機構數據中心為例，單數據中心由於地理約束等不能抵抗不可預知與控制的風險，已不能滿足金融監管要求和企業業務敏捷的訴求，災備甚至雙活成為一個典型的剛性需求。實時數據同步是實現異地災備的核心能力。早期我們更多是基於DB2的hadr技術，或者oracle的data guard技術，應用在數據庫災備的這樣一些場景。當然我們會發現，基於這樣一些產品，要做整個數據中心的戰略，會是一個非常高成本的投入，今天我們遇到越來越多的用戶在考慮數據庫災備的建設，考慮投入產出比，實時數據同步工具或許是一個不錯的選擇。
2 不停機遷移數據庫
系統升級遷移是運維同事的日常工作之一。傳統的方式，需要對存量的數據庫做一個遷移，耗時非常久。舉個例子，在2010年左右，當時某行sap系統，數據量也不大，大概500G到一個T的樣子，進行數據同步的時候，需要先把應用新部署一套，然后數據庫在新的服務器上裝好，基於原來的數據庫做一個全量的備份，此后在目標機器上做一個全量的恢復，同時把一些對應數據庫的歸檔日志拷貝到目標機器上，然后在特定的時間窗口，進行停機恢復。
聽起來這個事情特別復雜。做這樣一個規模的數據庫遷移，整個的進程安排的時間窗口需要12小時。這對於做離線的管理系統可能還好，而對於正常的在線業務是不可接受的，但又沒有特別好的方式來解決這個問題。
如果基於這種實時同步這種模式，且有相應的產品去做支撐，就能保證我們的數據在遷移和做應用切換的時候，可以進行平滑的調整，把窗口盡量壓縮，從小時級縮短到分鍾級。
3 數據實時入倉/湖
在做數據倉庫建設時，我們需要將大量業務系統數據持續集成到數據倉庫/數據湖。我們要把數據從原有的各種各樣的數據庫里面，就像這張圖上列出來的，把它能夠放到數據倉庫里面去。目前我們大多數都是用的各種各樣的數據集成工具，比如說開源的kettle。我們做了大量的工作，使用SQL寫了編寫數據處理的業務邏輯，通過定時的調度，來完成數據的轉移。
這種方式最大的一個問題是對原系統的壓力會特別大，當年在某行的時候，我們整個跑一個調度數據入倉，比如說主機的交易數據，用戶的數據，我們通常是安排在晚上的9點甚至更晚一點，為什么要這么做？因為它對原系統會造成壓力，我們抽取數據就會產生很大的壓力，於是只能安排在低峰期。
此外，整個數據同步的時間會非常久。正常情況一個用戶的交易記錄數據表，完成抽取可能要到第二天凌晨甚至早上，才能夠加載完成。如果數據要被用到分析和應用場景，延遲不是一個小時兩個小時，而是以天計，極大限制了數據價值的發揮。
因此數據倉庫更多是用來出報表，而不是去支持在線業務，這也是為什么近幾年企業會越來越希望通過數據中台或者這種類似的實時數據能力，去加速整個數據在企業內的應用和流轉。
4 讀寫分離
數據讀寫分離為什么需要數據同步？舉個銀行賬單系統的例子。我們平常去刷信用卡，我們刷一筆，銀行同時會記錄一筆，同時我們可能還會不定期的去查詢交易記錄，這樣的話從技術角度上來說，讀和寫我們需要能夠分離，去保證整個系統的效率最大化。
這種情況下，我們能不能用數據庫的從庫來去實現它的讀寫分離，甚至基於一些新興的數據檢索技術，例如es這種檢索查詢效率更高的技術，是不是可以放到第三方的數據存儲？當然可以。實時同步可以幫助我們解決更多類似的實際的業務問題。
5 業務異步解耦
以某智慧校園場景為例。現在學校的信息化也挺發達的，校園里方方面面的事務，會去變成線上化的系統。一個典型的問題就是所有的系統都會形成一個個孤島，但業務是需要聯通的，這個時候需要打通不同的系統之間的數據。但是我們發現，系統是由不同的服務商開發的，需要找相關的服務商來去處理系統間的擴展，這樣成本非常高。大家現在多會怎么做呢？
比較簡單的方式，使用一些腳本，比如用Python從人事系統里面抽取數據，然后做一些加工計算的規則去處理數據，之后再寫到工資系統或者審批系統，再寫一個定時觸發器來定期運行腳本。這個是我們常見的，寫一個類似同步的工具的方式。
這種方式在一定程度上可以滿足簡單的需求，但當需處理的范圍越來越廣時，你會發現這樣的鏈路在業務處理中變得越來越多，而且這個過程並不可控。所以我們就會發現是不是可以用實時數據同步，再加上一定的數據開發的能力，就可以很好的來管理和解決這些問題。
實時同步實現方案
那目前有哪些方案可以支撐我們做這樣一些事情呢？這里分享4種實現方案。
1 基於時間戳
基於時間戳或者自增字段的識別方式，應該我們平常在做數據開發或者數據處理里面最簡單的一種方式，通過周期性的比較找到最新的數據去做這種增量。它的優勢在於簡單，劣勢是我們會發現它不能記錄刪除操作的數據，也不能識別周期內多次更新的。這種基於調度的方式，也無法實時去捕獲發生變化的數據。
2 基於快照
基於快照是基於時間戳或自增字段的一個相對優化的方式。基於快照簡單理解就是可以把原表或者原庫的這種狀態數這種當前的數據做一個快照（會占用額外的存儲），拿到快照之后，將快照表和當前表做一個比較，然后去發現當前哪些數據被刪除了，哪些數據是新增的，甚至是做了更改的。
從實現方式上，基於快照的模式優於基於時間戳的模式，對於數據的增刪改可以完全覆蓋到，但是有帶來新的問題：它會占用更多的存儲，並且會消耗我們額外的計算資源，因為它要去計算差異點在哪里，因此在大數據量的情況下，不是一個特別好的實現方案。
3 基於觸發器
基於觸發器的方式更多是使用數據庫本身的機制，這種機制就像我這張圖上大家可以看到的，當我們在源端做一個數據庫DML操作的時候，我們會在數據庫里面增加相應的數據修改，或者刪除相應的數據。
利用數據庫的觸發器的機制，我們可以捕獲到數據產生的變化，然后可以把變化的數據存儲起來。這樣的好處是利用了數據庫的機制在數據庫引擎層面可以去發現數據的變化，可以做到實時同步。但從dba同學的角度，不建議在生產系統上使用觸發器，否則會帶來系統額外的開銷從而容易產生性能問題。
4 基於數據庫日志
目前在主流的商業化數據同步軟件里面最常用的一種方式就是基於數據庫日志的方式。做過數據恢復或者做過DBA的同學應該比較清楚，數據庫都有一個日志來記錄數據庫的事務操作，這種日志在數據庫恢復上非常有幫助。
基於數據庫的日志，加上一些解析的能力，可以做到數據的實時讀取，實時的在異地回放和落地。現在常見的一些商業化產品，基本上都會基於這樣的能力做更多的開發。
綜合比較下來，不管是從開發的角度，還是從技術實現的角度，我們會發現每一種方式都有自己的優劣勢。比如說時間戳是最簡單的，很容易實現但不支持增量數據捕獲。基於觸發器的方式，或者基於數據庫日志的方式，實時性足夠高，但是觸發器不是一種性能特別好的方式。基於數據庫日志，如果說我們有技術實力，或者有更可靠的這種商業軟件來支撐，是我們目前最適合去做實時數據同步的一種方式。
技術選型考量因素
我們自己在做產品的時候也在思考一個問題，選用哪種底層技術可以更好地保證用戶用好數據同步的能力，能夠保證它的業務能夠持續穩定的運轉？需要考慮的因素有哪些？這里我簡單列了幾個問題，在大家日常的工作中，我覺得大家肯定會碰得到：
1. 如何在多樣化數據源的情況下，降低同步管理的復雜度？
生產環境里我們有很多不同類型的數據庫，比如Oracle、MySQL,DB2，有PG，MongoDB等。如果需要對這些數據同時做不同的同步處理的話，按照現有的開源軟件的方式，可能每一種數據庫都有自己的一套軟件來去實現，我們需要分開去做管理。商業化的數據同步產品可能支持的也不是很全面的，比如說像MongoDB,其實很多傳統的數據同步軟件支持不是特別好。
2. 如何實現異構數據庫之間的實時同步？
DBA同學可能清楚一點，很多時候做遷移，其實是做了一個同構到同構的遷移，但現在我們會遇到一些很多新的場景，比如像剛才我也提到做讀寫分離加速的場景，我們希望把數據庫里的比如說MySQL的數據，我希望把它同步到我的ES里面去做這種更高效的檢索和查詢。或者說一些傳統的MySQL等關系型數據庫，我覺得它的查詢性能不好，也不方便我去做管理，我要把它放到MongoDB里面。用傳統的備份和恢復的方式基本是不可行的，因為數據的結構，字段類型，甚至一些關鍵的配置都是有差異的。像我們最近在接觸的一些客戶，從MySQL遷移到達夢里面去，這個東西如果說我們要手工去做，DBA同學會很崩潰的。
3. 如何保證穩定性和可靠性？
當我們解決了前面兩個功能性的問題，我們又會有進一步的需求：任務如果是在跑，我怎么能夠保證它穩定在運行？如果出了錯誤，我能不能及時知道？之前有一個同學在跟我們去聊這個話題的時候，他就提到說他們現在用的產品功能上應該是ok，但是穩定性不是特別好，出了問題也不知道，需要人工去檢查巡檢。但是這個功能又不太容易做二次開發，所以就用起來很麻煩。這個特性其實企業級產品一個非常關鍵的特性。
4. 如何驗證數據的質量？
好了，我們做了數據同步，從MySQL同步到MongoDB里面，從MySQL同步到ES里面，我怎么保證數據在同步過程中不會出現偏差呢？我有沒有辦法去驗證，甚至說再往下我是不是如果真的出現了偏差，我是不是可以去糾正的？這都是我們一系列在真正去解決這個問題的時候，我們需要去考慮的點。
5. 同步實現是否需要復雜的代碼處理？在同步的過程中，需要做些處理，如何來實現？
我們在同步的過程中是不是要花大量的時間，比如說我要不要去寫SQL(這個可能還算簡單的)? 是不是在這個過程中我還有需要去寫處理業務邏輯的東西？我們的工具是不是很好的去來支撐這個事情？
我們雖然有了非常值得信賴的一些底層的技術方式和一些開源的產品去做這個事情，但是當我們希望把變得穩定、可靠、可用，甚至能夠極大提升我們在做利用數據實時同步來去完成我們的業務場景和目標的工作效率時候，我們還需要解決更多的問題。
下面我介紹下我們正在做的一個實時異構數據同步工具。
Tapdata Cloud如何來解決以上問題？
支持多樣化的數據源，完美支持SQL->NOSQL
Tapdata Cloud是我們今年推出的一個免費的在線實時異構數據同步工具，現在已經支持了多種數據類型，包括我們常見的一些關系數據庫，比如Oracle，MySQL；也支持一些常見的NoSQL 數據庫，比如MongoDB，ES,還有消息中間件Kafka等,也都在我們的支持范圍之內。
這張圖上我們大家可以看到我們現在已經支持的一些數據源，還有一部分是我們正在開發即將上線的一些能力，如果說我們同學如果有測試的需求，比如說這里面我有些數據源是沒有的，希望我們加進來的，非常歡迎大家給我們提更多的意見和建議，也歡迎大家來做更多的嘗試。
低代碼配置操作，可視化任務運行監控
我們通過一些簡單配置的操作方式，統一的操作流程和和體驗能夠幫助用戶實現同構和異構數據庫同步。
Tapdata Cloud整個配置過程非常簡單，除了建數據源之外它只有4步，第一步是我們可以去選我們的源和目標，第二步就是設置我們整個任務的屬性，比如說是做全量還是做增量，然后在全量和增量里面是不是還有一些特殊的配置，比如說我是不是有可能會出現這種無主鍵的情況，這個是我們在很多客戶場景里面非常典型的一些場景。
第三步就是我們可以選我們要去做同步的表，比如說哪些表我們是希望同步到目標端去，同時我們也支持在選擇表的過程中對表去做一些改名。第四步就是針對我們選擇的字段，選擇的表，我們可以做一些這種調整。為什么會有這樣一個環節？當我們在做這種異構數據同步的時候，我們會發現不同的數據庫它的字段類型之間會存在很大的差異的。我們做了大量的工作，去保證數據模型的准確性，同時我們也把推演能力開放出來，能夠讓用戶及時准確的去糾正調整字段轉換映射。
具體的操作大家可以看直播演示，也可以登錄cloud.tapdata.net直接上手操作，我們也提供了產品操作文檔給大家。
SQL作為CDC補充，滿足多樣化同步場景
前面我們介紹了4種數據同步方式，不管是基於時間戳，基於快照，還是基於觸發器或者基於日志的CDC的方式，總會在一些實際場景里面會遇到以下情況：我們的數據庫其實是沒有日志可以用的。我們之前遇到一個客戶，他的數據庫是跑在阿里雲上，數據庫使用主從架構，但是不允許我們從主節點訪問數據庫日志。但我們發現在阿里雲上的從節點，即使打開了binlog的設置，也不會去記錄相應的操作。這個時候我們會提供一種基於SQL的方式，在數據表對象設置上，我們會提供這樣的一個配置，讓用戶可以通過SQL來實現數據的增量。而這種場景我們在蠻多的用戶場景里面遇到。
任務可用性監控
剛才我們也提到了，我有一個工具，我能保證它能解決我基本的問題，但是我們如果希望它能夠真正在我們的生產環境真正發揮它的價值，我們除了對它的功能性有要求，穩定性和可用性也是非常關鍵的考量點。任務出現了問題，同步節點也出現了問題，我能夠及時知道並且處理。這樣的話我們的工具產品才有可能幫到實際的用戶，能夠成為它的真正的生產力的工具。現在我們已經支持了短信、郵件和系統通知的監控通知，不過現在我們還不能自主關閉，這個功能已經在排期，在最近的1~2個迭代我們會把它加上去。
數據校驗
最后我們再看數據校驗的能力，剛剛我提到的一個話題就是數據校驗。為什么要數據校驗？在同步過程中，很有可能會出現偏差，如何解決這個問題？一方面我要保證我的數據同步不會出現偏差，這個是從同步的能力上我們要一直加強的核心功能，但另一方面，我們也必須能夠提供到一個讓用戶確認說我確實是沒問題的能力。
Tapdata Cloud 提供的數據校驗的能力有三種，比如說我的快速統計數量的校驗，源表100萬，我可以在目標端做一個測試，我發現它是99萬多一點，我們就可以發現它的差異，至少我知道它是有差異的，這個是第一種快速count方式。第二種方式就是就是我們所說的這種表全字段的校驗，我可以需要展開做各種各樣的這種全字段校驗，當然這種校驗的效率會比較低，需要比較長的時間。第三種就是我們的關聯字段值的校驗，其實它類似於全自動，但是它可以提取部分自動去做這樣的事情。
創新的實時數據同步技術
彩蛋—— Streaming ETL
最后給大家一個彩蛋。大家都知道傳統的ETL：我們要去做數據開發，要抽取不同的數據，在抽取的過程中要做一些轉換和計算，這個就是我們常見的ETL。ETL加上這種CDC的能力變成這種流的方式，它可以解決什么問題？
Streaming ETL是我們正在設計開發的功能，這個功能在剛剛介紹數據業務解耦的場景里會遇到的比較多，我們計划是在10月底在雲版上跟大家見面。
關於Tapdata
再簡單介紹一下團隊。Tapdata團隊是2019年成立於深圳。在19年成立的時候，我們就獲得了變量資本等千萬級的投資，然后到今年初我們獲得了五源資本的投資，我們也是國家流數據庫標准委員會的成員，今年也獲得了最佳數字中台品服務品牌的獎項。
我們在打造未來企業首選的一個實時數據服務平台，同時我們最核心的最強大的骨干研發力量都是來自於像MongoDB、百度等BAT這樣的公司。這里我也打個小廣告，如果說對我們做的事情有興趣，能夠跟我們一起來去提升我們整個在數據實時同步，甚至數據服務這塊能力的同仁，我們非常歡迎大家來投遞簡歷加入我們。 查看詳細崗位介紹
掃描下方二維碼，訂閱最新 Tapdata 技術博客 ↓↓
