DataPipeline可以幫企業資料整合解決哪些核心難題？

DataPipeline已經完成了很多最佳化和提升工作，可以很好地解決當前企業資料整合面臨的很多核心難題。

1. 任務的獨立性與全域性性。

從Kafka設計之初，就遵從從源端到目的的解耦性。下游可以有很多個Consumer，如果不是具有這種解耦性，消費端很難擴充套件。企業做資料整合任務的時候，需要源端到目的端的協同性，因為企業最終希望把握的是從源端到目的端的資料同步擁有一個可控的週期，並能夠持續保持增量同步。在這個過程中，源端和目的端相互獨立的話，會帶來一個問題，源端和目的端速度不匹配，一快一慢，造成資料堆積現象嚴重。所以，企業使用者在建立一個資料任務之後，我們希望對任務進行緩衝的控制，避免資料丟失。

2. 任務並行化的方式。

如果企業客戶有1000張資料表需要建立資料整合的任務，就要考慮用什麼方式進行任務切分最佳。其中一種方式是把1000張表切分成若干個任務。這種情況下，Source Task的負載很難做到均衡，Sink Task可以消費多個Topics，依然存在負載不均的問題，每個任務負載多少張表其實是很難均衡的。每增加一個任務都會觸發Rebalance機制。可以想象，每一張表都透過Source Connector和Sink Connector初始化一個源端和目的端任務，會大大增加Rebalance的開銷。

3. 異構資料的對映。

在給企業客戶做資料整合的時候，50%機率都會遇到一些髒活累活——異構資料來源的對映（Mapping）。這個對映對很多網際網路公司來說不是那麼嚴重什麼事兒，因為資料庫設計的都比較符合規範，對欄位的命名方式等都會比較“優雅”（統一）。但是在傳統企業裡，由於很多業務系統都會外包，還有一些意識的原因，導致資料庫設計的沒有那麼規範和統一。用Kafka Connect做資料整合的時候，需要儘可能做到異構資料精準的還原，尤其金融行業客戶對此要求比較高。另外，當確實遇到資料之間不匹配的情況時，可以在業務資料之間進行比較合理的對映。

另外，源端的Source Record包含了每一列的基本資料型別（INT16、STRING等）以及可選的meta資訊（例如“name”）。目的端處理Sink Record的時候，需要依據基本資料型別以及meta資訊決定對映關係。

4. Schema變化的處理策略。

給企業做資料整合的時候，需要根據資料來源Schema的變化給出對應的處理策略。基於Kafka Connect框架，我們提供了以下幾種處理策略：

（1）Backward Compatibility：可使用最新的Schema一致訪問所有資料，e.g. 刪除列、新增具有預設值的列。

（2）Forward Compatibility：可使用最舊的Schema一致訪問所有資料，e.g. 刪除具有預設值的列。

（3）Full Compatibility：可任意使用新舊Schema訪問所有資料。

Kafka Connect推薦使用Backward Compatibility，這也是Schema Registry的預設值。另外，企業使用者還會提出源端刪除列，目的端需要忽略，源端新增具有預設值列，目的端需要跟隨等需求，都以Task為單位進行配置和實現。

更多關於實時資料整合的問題，歡迎直接訪問官方網址申請試用：