基於Kafka Connect框架DataPipeline能夠更好地解決哪些企業數據集成難題?

1. 任務的獨立性與全局性。數據庫

從Kafka設計之初,就聽從從源端到目的的解耦性。下游能夠有不少個Consumer,若是不是具備這種解耦性,消費端很難擴展。企業作數據集成任務的時候,須要源端到目的端的協同性,由於企業最終但願把握的是從源端到目的端的數據同步擁有一個可控的週期,並可以持續保持增量同步。在這個過程當中,源端和目的端相互獨立的話,會帶來一個問題,源端和目的端速度不匹配,一快一慢,形成數據堆積現象嚴重。因此,企業用戶在創建一個數據任務以後,咱們但願對任務進行緩衝的控制,避免數據丟失。api

 

2. 任務並行化的方式。app

若是企業客戶有1000張數據表須要創建數據集成的任務,就要考慮用什麼方式進行任務切分最佳。其中一種方式是把1000張表切分紅若干個任務。這種狀況下,Source Task的負載很難作到均衡,Sink Task能夠消費多個Topics,依然存在負載不均的問題,每一個任務負載多少張表實際上是很難均衡的。每增長一個任務都會觸發Rebalance機制。能夠想象,每一張表都經過Source Connector和Sink Connector初始化一個源端和目的端任務,會大大增長Rebalance的開銷。框架

 

3. 異構數據的映射。數據庫設計

在給企業客戶作數據集成的時候,50%概率都會遇到一些髒活累活——異構數據源的映射(Mapping)。這個映射對不少互聯網公司來講不是那麼嚴重什麼事兒,由於數據庫設計的都比較符合規範,對字段的命名方式等都會比較「優雅」(統一)。可是在傳統企業裏,因爲不少業務系統都會外包,還有一些意識的緣由,致使數據庫設計的沒有那麼規範和統一。用Kafka Connect作數據集成的時候,須要儘量作到異構數據精準的還原,尤爲金融行業客戶對此要求比較高。另外,當確實遇到數據之間不匹配的狀況時,能夠在業務數據之間進行比較合理的映射。設計

 

另外,源端的Source Record包含了每一列的基本數據類型(INT1六、STRING等)以及可選的meta信息(例如「name」)。目的端處理Sink Record的時候,須要依據基本數據類型以及meta信息決定映射關係。ip

 

4. Schema變化的處理策略。同步

給企業作數據集成的時候,須要根據數據源Schema的變化給出對應的處理策略。基於Kafka Connect框架,咱們提供瞭如下幾種處理策略:it

(1)Backward Compatibility:可以使用最新的Schema一致訪問全部數據,e.g. 刪除列、添加具備默認值的列。pip

(2)Forward Compatibility:可以使用最舊的Schema一致訪問全部數據,e.g. 刪除具備默認值的列。

(3)Full Compatibility:可任意使用新舊Schema訪問全部數據。

 

Kafka Connect推薦使用Backward Compatibility,這也是Schema Registry的默認值。另外,企業用戶還會提出源端刪除列,目的端須要忽略,源端添加具備默認值列,目的端須要跟隨等需求,都以Task爲單位進行配置和實現。

更多關於實時數據集成的問題,歡迎直接訪問官方網址申請試用:www.datapipeline.com

相關文章
相關標籤/搜索