在遇到跨庫或者異庫數(shù)據(jù)同步時，我們一般都會借助ETL工具來實現(xiàn)數(shù)據(jù)同步功能。比如目前大家較為熟知的Kettle和Datax。但是，這兩個需要定時去查詢數(shù)據(jù)庫的數(shù)據(jù)，會存在一定的延遲，而且，默認采用全量同步的方式，想要增量，需要自己做特殊的處理。那么，有沒有開源的工具，既能滿足全量和增量，又能達到相對比較實時的呢？接下來，我們繼續(xù)往下看。

Kettle

在ETL行列中，kettle算是人氣比較旺的一款工具，功能多且強大，開源，可視化。使用方便、簡潔，但是，體量越來越大，性能一般。

可以自己下載源碼編譯，要求Maven 3+、Java JDK 11。

??https://github.com/pentaho/pentaho-kettle.git??

DataX

DataX 是阿里云 DataWorks數(shù)據(jù)集成 的開源版本，在阿里巴巴集團內(nèi)被廣泛使用的離線數(shù)據(jù)同步工具/平臺。DataX 實現(xiàn)了包括 MySQL、Oracle、OceanBase、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、Hologres、DRDS, databend 等各種異構數(shù)據(jù)源之間高效的數(shù)據(jù)同步功能。

??https://github.com/alibaba/DataX.git??

DataX-Web

前面提到DataX,那么就不得不提一下DataX-Web,DataX沒有可視化界面，不過目前，已經(jīng)有熱心開基于DataX開發(fā)了對應的Web界面。DataX Web是在DataX之上開發(fā)的分布式數(shù)據(jù)同步工具，提供簡單易用的 操作界面，降低用戶使用DataX的學習成本，縮短任務配置時間，避免配置過程中出錯。用戶可通過頁面選擇數(shù)據(jù)源即可創(chuàng)建數(shù)據(jù)同步任務，支持RDBMS、Hive、HBase、ClickHouse、MongoDB等數(shù)據(jù)源，RDBMS數(shù)據(jù)源可批量創(chuàng)建數(shù)據(jù)同步任務，支持實時查看數(shù)據(jù)同步進度及日志并提供終止同步功能，集成并二次開發(fā)xxl-job可根據(jù)時間、自增主鍵增量同步數(shù)據(jù)。

任務”執(zhí)行器”支持集群部署，支持執(zhí)行器多節(jié)點路由策略選擇，支持超時控制、失敗重試、失敗告警、任務依賴，執(zhí)行器CPU.內(nèi)存.負載的監(jiān)控等等。后續(xù)還將提供更多的數(shù)據(jù)源支持、數(shù)據(jù)轉換UDF、表結構同步、數(shù)據(jù)同步血緣等更為復雜的業(yè)務場景。

??https://github.com/WeiYe-Jing/datax-web.git??

Airbyte

一款開源的可視化ETL功能，支持很多數(shù)據(jù)源，并且支持全量及增量同步。

??https://github.com/airbytehq/airbyte.git??

benthos

Benthos 是一個開源的、高性能和彈性的數(shù)據(jù)流處理器，支持多種方式的數(shù)據(jù)接入、加工、轉換。

??https://github.com/benthosdev/benthos.git??

canal

阿里巴巴開源的MySQL binlog 增量訂閱&消費組件，基于日志只能做增量同步,很多工作需要自己處理。

??https://github.com/alibaba/canal.git??

Maxwell

也是監(jiān)聽MySQL binlog，并將數(shù)據(jù)更解析為JSON寫入到Kafka等其他流媒體平臺。

??https://github.com/zendesk/maxwell.git??

debezium

Debezium是一個捕獲數(shù)據(jù)更改(CDC)平臺，并且利用Kafka和Kafka Connect實現(xiàn)了自己的持久性、可靠性和容錯性。每一個部署在Kafka Connect分布式的、可擴展的、容錯性的服務中的connector監(jiān)控一個上游數(shù)據(jù)庫服務器，捕獲所有的數(shù)據(jù)庫更改，然后記錄到一個或者多個Kafka topic(通常一個數(shù)據(jù)庫表對應一個kafka topic)。Kafka確保所有這些數(shù)據(jù)更改事件都能夠多副本并且總體上有序(Kafka只能保證一個topic的單個分區(qū)內(nèi)有序)，這樣，更多的客戶端可以獨立消費同樣的數(shù)據(jù)更改事件而對上游數(shù)據(jù)庫系統(tǒng)造成的影響降到很小(如果N個應用都直接去監(jiān)控數(shù)據(jù)庫更改，對數(shù)據(jù)庫的壓力為N，而用debezium匯報數(shù)據(jù)庫更改事件到kafka，所有的應用都去消費kafka中的消息，可以把對數(shù)據(jù)庫的壓力降到1)。另外，客戶端可以隨時停止消費，然后重啟，從上次停止消費的地方接著消費。每個客戶端可以自行決定他們是否需要exactly-once或者at-least-once消息交付語義保證，并且所有的數(shù)據(jù)庫或者表的更改事件是按照上游數(shù)據(jù)庫發(fā)生的順序被交付的。

??https://github.com/debezium/debezium.git??

Flink CDC

Apache Flink?的CDC連接器集成了Debezium作為捕獲數(shù)據(jù)更改的引擎。雖然功能強大，但是比較重。

??https://github.com/ververica/flink-cdc-connectors.git??

目前，異構數(shù)據(jù)ETL同步，一般基于兩種方式：查詢和日志，基于查詢做全量同步，基于日志做增量同步，日志方式延遲會比較小，查詢來做增量，延遲會比較大，查詢頻率越高，對數(shù)據(jù)庫性能也會有影響。隨著各種熱門技術的興起，在Github中也有越來越多的解決方案，我們可以根據(jù)自己的實際情況選擇合適自己的工具。