DataPipeline丨新型企業數據融合平臺的探索與實踐

一、關于數據融合和企業數據融合平臺

數據融合是把不同來源、格式、特點性質的數據在邏輯上或物理上有機地集中，從而為企業提供全面的數據共享。

企業數據融合平臺，通常的表現形態為運行著大量數據同步和轉換任務的分布式系統。其源端一般為各類偏實時的業務數據存儲系統，目的端為各類數據倉庫/對象存儲。

二、企業數據融合平臺的典型架構

下圖為數據融合平臺的典型架構，源端是不同的數據存儲系統，另一端是各種類型的數據倉庫，關系型數據庫或者文件存儲等。中間為數據融合平臺的簡單架構，組件Source connectors負責做數據的采集。

將數據采集之后，會將其做成格式化數據放到Transport Channel，Transport Channel一般會用Source隊列或其它流式數據框架，負責做中間的緩存，包括分布式的支持，數據的分發， sink connectors去負責把數據分別寫入不同的數據目的地。

三、企業數據融合需要解決的關鍵問題

1. 數據異構問題

面臨繁瑣的數據源和目的地適配以及異構數據源的轉換問題。

2. 隨時變化的數據結構

數據源結構會隨時發生變化，造成下游寫入失敗。當數據結構發生改變時，需要保證數據像正常一樣，不會出現任何問題。

3. 數據平臺的擴展性

需要根據業務驅動做水平拓展，甚至需應對一對多的分發要求，另外也需要處理和解決多任務并行的QoS。

4. 數據一致性

在任何情況下都需要保證數據是一致的，這也是在生產過程中需要保證的問題。

四、消息隊列在數據融合平臺的作用

首先是解耦，消息隊列可以將源端的數據采集跟移動端的數據完全進行解耦。如果數據寫入端出現任何問題，不會影響數據采集的穩定型。

Schema Mapping幫助我們做到了數據源和目的地結構的解耦，減少開發新的connector的復雜度。

同時消息隊列提供了水平拓展和高可用的性質，當需要接入更多數據且系統不能支撐時，我們可以輕易的做水平拓展，支持更大的數據量。

另外，對消息隊列和數據同步一致性的問題做了保證，至少能保證數據同步的順序性。

五、DataPipeline現有架構

下圖為DataPipeline基于Kafka connect消息隊列所做的架構，Kafka本身是一個非常成熟的消息隊列，Kafka connect是其下面的一個子項目，相當于給kafka consumer 和 kafka producer提供了一個封裝，它實現了分布式和高可用，同時幫助我們負責和kakfa進行交互。

六、Kafka connect-offset管理

消費者會有一個offset的概念，用來記錄消費進度，Kafka connect會自動化地做消息offset的管理，它可以等我們消費完一些數據之后，自動提交消費進度，然后在Kafka中做存儲。

在讀取數據的時候， connector會將數據從數據源抽取出來寫到data topic，用來做數據中間的緩存。同時connector在同步過程中也會周期性的將offset提交到offset Topic，相當于每讀取一段時間，存一個存檔點。

周期性的offset提交如果失敗的話，會導致數據任務重啟恢復時無法完全恢復到最后寫入的offset點。這種情況就會導致數據的重復讀取和重復寫入，會出現數據一致性的問題，以下解決方案可以從一定程度上避免這個問題：

1. 依賴目的地的特性進行去重達到數據的最終一致性，例如: RDBMS用主鍵進行去重。

2. 依賴消息隊列的事務信息避免源端重復，保證數據寫入和offset寫入的事務性提交。

3. 目的端在寫入后記錄單獨的offset到redis緩存，并在任務恢復之后根據offset進行過濾，避免重復寫入。減少offset rewind帶來的數據重復，但是由于寫入數據和記錄offset并不是事務操作，所以也不保證exactly once delivery。

4. 依賴目的地的事務性，在目的地建立臨時空間記錄寫入的offset，并在任務恢復之后根據offset進行過濾，避免重復寫入，可以保證exactly once delivery。但是要求目的地可以支持事務性，并且會在目的地有額外的數據存儲。