| 比較維度\產品 |
DataPipeline |
kettle |
Oracle Goldengate |
informatica |
talend |
DataX |
| 設計及架構 |
適用場景 |
主要用於各類數據融合、數據交換場景，專為超大數據量、高度復雜的數據鏈路設計的靈活、可擴展的數據交換平台 |
面向數據倉庫建模傳統ETL工具 |
主要用於數據備份、容災 |
面向數據倉庫建模傳統ETL工具 |
面向數據倉庫建模傳統ETL工具 |
面向數據倉庫建模傳統ETL工具 |
| 使用方式 |
全流程圖形化界面，應用端采用B/S架構，Cloud Native為雲而生，所有操作在瀏覽器內就可以完成，不需要額外的開發和生產發布 |
C/S客戶端模式，開發和生產環境需要獨立部署，任務的編寫、調試、修改都在本地，需要發布到生產環境，線上生產環境沒有界面，需要通過日志來調試、debug，效率低，費時費力 |
沒有圖形化的界面，操作皆為命令行方式，可配置能力差 |
C/S客戶端模式，開發和生產環境需要獨立部署，任務的編寫、調試、修改都在本地，需要發布到生產環境；學習成本較高，一般需要受過專業培訓的工程師才能使用； |
C/S客戶端模式，開發和生產環境需要獨立部署，任務的編寫、調試、修改都在本地，需要發布到生產環境； |
DataX是以腳本的方式執行任務的，需要完全吃透源碼才可以調用，學習成本高，沒有圖形開發化界面和監控界面，運維成本相對高。 |
| 底層架構 |
分布式集群高可用架構，可以水平擴展到多節點支持超大數據量，架構容錯性高，可以自動調節任務在節點之間分配，適用於大數據場景 |
主從結構非高可用，擴展性差，架構容錯性低，不適用大數據場景 |
可做集群部署，規避單點故障，依賴於外部環境，如Oracle RAC等； |
schema mapping非自動；可復制性比較差；更新換代不是很強 |
支持分布式部署 |
支持單機部署和集群部署兩種方式 |
| 功能 |
CDC機制 |
基於日志、基於時間戳和自增序列等多種方式可選 |
基於時間戳、觸發器等 |
主要是基於日志 |
基於日志、基於時間戳和自增序列等多種方式可選 |
基於觸發器、基於時間戳和自增序列等多種方式可選 |
離線批處理 |
| 對數據庫的影響 |
基於日志的采集方式對數據庫無侵入性 |
對數據庫表結構有要求，存在一定侵入性 |
源端數據庫需要預留額外的緩存空間 |
基於日志的采集方式對數據庫無侵入性 |
有侵入性 |
通過sql select 采集數據，對數據源沒有侵入性 |
| 自動斷點續傳 |
支持 |
不支持 |
支持 |
不支持，依賴ETL設計的合理性（例如T-1），指定續讀某個時間點的數據，非自動 |
不支持，依賴ETL設計的合理性（例如T-1），指定續讀某個時間點的數據，非自動 |
不支持 |
| 監控預警 |
可視化的過程監控，提供多樣化的圖表，輔助運維，故障問題可實時預警 |
依賴日志定位故障問題，往往只能是后處理的方式，缺少過程預警 |
無圖形化的界面預警 |
monitor可以看到報錯信息，信息相對籠統，定位問題仍需依賴分析日志 |
有問題預警，定位問題仍需依賴日志 |
依賴工具日志定位故障問題，沒有圖形化運維界面和預警機制，需要自定義開發。 |
| 數據清洗 |
圍繞數據質量做輕量清洗 |
圍繞數據倉庫的數據需求進行建模計算，清洗功能相對復雜，需要手動編程 |
輕量清洗 |
支持復雜邏輯的清洗和轉化 |
支持復雜邏輯的清洗和轉化 |
需要根據自身清晰規則編寫清洗腳本，進行調用（DataX3.0 提供的功能）。 |
| 數據轉換 |
自動化的schema mapping |
手動配置schema mapping |
需手動配置異構數據間的映射 |
手動配置schema mapping |
手動配置schema mapping |
通過編寫json腳本進行schema mapping映射 |
| 特性 |
數據實時性 |
實時 |
非實時 |
實時 |
支持實時，但是主流應用都是基於時間戳等方式做批量處理，實時同步效率未知 |
實時 |
定時 |
| 應用難度 |
低 |
高 |
中 |
高 |
中 |
高 |
| 是否需要開發 |
否 |
是 |
是 |
是 |
是 |
是 |
| 易用性 |
高 |
低 |
中 |
低 |
低 |
低 |
| 穩定性 |
高 |
低 |
高 |
中 |
中 |
中 |
| 其他 |
實施及售后服務 |
原廠實施和售后服務 |
開源軟件，需自客戶自行實施、維護 |
原廠和第三方的實施和售后服務 |
主要為第三方的實施和售后服務 |
分為開源版和企業版，企業版可提供相應服務 |
阿里開源代碼，需要客戶自動實施、開發、維護 |
