文 |劉瀚林 DataPipeline後端研發負責人 交流微信 | datapipeline2018 一、關於數據融合和企業數據融合平臺 數據融合是把不同來源、格式、特點性質的數據在邏輯上或物理上有機地集中，從而為企業提供全面的數據共用。 企業數據融合平臺，通常的表現形態為運行著大量數據同步和轉換任 ...
文 |劉瀚林 DataPipeline後端研發負責人
交流微信 | datapipeline2018
一、關於數據融合和企業數據融合平臺
數據融合是把不同來源、格式、特點性質的數據在邏輯上或物理上有機地集中，從而為企業提供全面的數據共用。
企業數據融合平臺，通常的表現形態為運行著大量數據同步和轉換任務的分散式系統。其源端一般為各類偏實時的業務數據存儲系統，目的端為各類數據倉庫/對象存儲。
二、企業數據融合平臺的典型架構
下圖為數據融合平臺的典型架構，源端是不同的數據存儲系統，另一端是各種類型的數據倉庫，關係型資料庫或者文件存儲等。中間為數據融合平臺的簡單架構，組件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。但是要求目的地可以支持事務性，並且會在目的地有額外的數據存儲。
