數據交換平台架構

一、數據交換平台定義（百度百科）

數據交換平台是指將分散建設的若干應用信息系統進行整合，通過計算機網絡構建的信息交換平台，它使若干個應用子系統進行信息/數據的傳輸及共享，提高信息資源的利用率，成為進行信息化建設的基本目標，保證分布異構系統之間互聯互通，建立中心數據庫，完成數據的抽取、集中、加載、展現，構造統一的數據處理和交換。

二、Why數據交換平台?

1.分布式的需要

PS：(分布式出現的兩個驅動要素：1.業務場景越來越復雜，需要進行系統拆分；2.性能的需要)

場景舉例一：EDA

通過數據交換平台，把數據庫Log事件（如Mysql的binlog）發送到MQ，驅動后續流程（如:刷新緩存，構造搜索引擎，業務流程驅動<如:下單之后發短信>等）

場景舉例二：CQRS

【命令、查詢分離】的思想本質上就是同一份數據建立兩套視圖：一套是模型清晰的Domain-Mode，代表業務實體，滿足復雜業務邏輯的需要；另一套是查詢視圖，主要面向查詢場景，不關心數據庫范式，只關心查詢最優最快

2.容災備份的需要

場景舉例一：多機房

多中心、多備份、異地多活等是很多大公司正在實踐或者已經實踐過的技術難題，這中間的核心便是一整套完整的數據同步方案

場景舉例二：數據鏡像

通過數據交換平台，可以創建各種類型的DB鏡像，滿足不同場景下的使用需要

場景舉例三：數據歸檔

通過增量交換，可以實現實時歸檔

3.異構、重構的需要

場景舉例一：DB升級換代

通過數據交換平台解決升級過程中的版本兼容性問題

場景舉例二：資產復用

任何一個公司都有大大小小的各種IT資產，通過數據交換平台，可以實現這些核心資產的整合、復用

場景舉例三：遷庫、拆庫

系統進行重構，業務應用要拆分為兩個子系統，對應的數據庫由一個拆成兩個，需要數據交換平台先進行全量Copy，再進行增量同步，然后配合系統完成遷移對接，如下所示

三、(神州優車)數據交換平台總體架構

總體架構圖如下所示，整個平台由三個子系統組成

ucar_datalink（增量同步子系統）

ucar_datalink是優車技術團隊自研的一套數據同步中間件，主要滿足各異構數據源之間的實時增量同步需求，具有高伸縮性、高擴展性和高性能等優點

ucar_dataX（全量同步子系統）

ucar_datax是對Alibaba開源的datax進行了深度定制和改造，滿足集團內的全量數據同步需求

Admin（管理監控子系統）

管理子系統對整個增量和全量集群進行運維管理，包括：HA、同步申請自動處理、延遲監控、異常監控、機器監控等等

四、Datalink產品介紹

Datalink借鑒了數個開源產品的設計

• 借鑒了Kafka-Connect的基礎設施：分組、HA、Rebalance協議、Task模型等
• 借鑒了Otter的諸多功能模型：領域模型抽象、雙向同步、數據壓縮合並、數據權重算法等
• 參與了Linkedin的Databus的一些設計思想

1.Datalink的基礎設施模型

Manager

整個Datalink集群的大腦，負載均衡協調器、配置管理、集群監控

Group

分組是一個核心邏輯概念，通過分組實現組內自治、組間隔離，便於進行拆分管理

Worker

Worker是Task的運行容器，一個Worker節點運行一系列同步任務，Worker歸屬於某個分組

Task

數據同步任務實例，由一個reader和至少一個writer組成，歸屬於某個分組，在一個分組內Task通過一定的負載均衡策略，被分配到不同的Worker上執行

Rebalance

Rebalance單位：分組；
Rebalance時機：Manager主備切換、Worker加入分組、Worker離開分組、新增Task、刪除Task

2.Datalink的領域模型

Contract

針對每種類型的數據庫，我們會抽象一套契約類型，有了這套契約便可實現Reader和Writer的任意組合
比如我們針對關系型數據庫抽象一個契約，契約的核心類名為RdbEventRecord，代表一條數據庫log事件變更，圍繞這個契約，我們可以開發若干插件 如果是Reader插件，這個插件的一個核心功能就是做數據類型轉換，如MysqlReader、SqlserverReader、OracleReader分別會把自己對應數據庫的底層log-event轉換為RdbEventRecord即可 如果是Writer插件，需要的是針對每一種契約實現一個處理器，如HbaseWriter，其主要目的是往hbase寫數據，但是在不同的Task中，它對接的Reader是隨機的，所以需要的是對不同類型契約的數據做適配

Business Model

領域模型借鑒了Aalibaba-Otter的一些思想，針對數據同步領域的一些常見功能，我們進行了深度分析和抽象
* MediaSource： 是對數據源的抽象，所有類型的數據源都會保存到這個模型，神州內部已經支持的數據源有 MYSQL, SQLSERVER, ORACLE, HDFS, HBASE, ELASTICSEARCH, ZOOKEEPER,POSTGRESQL * Media： 是對數據存儲單元的抽象，可以是關系型數據庫的表、Hbase的表、ElastaicSearch的索引等等 * MediaMapping： 是對數據交換協議的抽象，所有類型的Media之間的數據同步關系都保存到這個模型 * 支持的功能 依托這套領域模型，可以實現的一些主要功能特性如下所示  庫別名  表別名  列別名  列白名單  列黑名單  多表合一  多表聚合  主鍵跳過  同步攔截器  按權重同步

3.Datalink的插件模型

Task&Plugin

* Task是Datalink中的一個核心概念，一個運行中的Task就是一個數據同步任務 * Task由一個Reader和若干個Writer組成，即可以實現一對多的數據同步 * Task的數據同步流程：由Reader端取數據，然后放到內存隊列，Writer端消費數據，成功的話執行Ack操作，失敗的話執行Rollback操作 * Task提供了插件機制，一個Task只有在運行時才知道自己組裝的Reader和Writer是什么 * Task的Reader和Writer插件在運行時有自己獨立的ClassLoader，以解決同一進程中jar包沖突的問題 * 通過這套插件模型我們可以實現最大程度的基礎設施復用：一套框架支持各種數據源之間的增量同步需求，框架穩定之后，后期關注重點只需要放到插件開發上即可，目前我們內部實現的插件有：  MysqlReader  FlexibleQReader（FlexibleQ：內部消息中間件）  RdbmsWriter  HbaseReader（建設中）  ElasticSearchWriter  HdfsWriter  FlexibleQWriter  HbaseWriter(建設中)

（神州優車內部）Datalink同步場景舉例

1.Mysql同步到RDBMS

簡介

* 該場景下的數據同步主要分為兩種：一種是線上各個系統間的基礎參數表同步，另外一種是線上數據同步到OLAP系統（主要是BI） * 支持多種同步模式  全局有序同步：完全按照源端binlog的執行順序進行重放  局部有序同步：以表為單位進行聚合，保證單表內同步是有序的  完全並發：當開啟merger功能的時候，在merge合並完之后，能保證同一張表的同一條數據只有一條binlog事件，此時可以完全打亂順序，保證最終一致即可

2.Mysql同步到ElasticSearch

簡介

* 訂單庫(Mysql)為應對線上的各種交易請求已經足夠忙碌，查詢操作必須放到二級系統中去做，所以實現了Mysql到ES的同步，所有查詢走ES * 在同步過程中，可以實現多表聚合，即將Mysql中多張有外鍵關系的表，在同步過程中進行聚合，到ES端，多張表的數據合並成一條

3.Mysql同步到Hadoop

簡介

* 作為大數據平台的第一層，datalink負責把線上生產庫的binlog變更同步到Hadoop * 數據處理平台每天凌晨對T-1的數據進行清洗、去重，把同步過去的binlog數據更新到spark-hive

4.Mysql同步到MQ

簡介

* 目前我們內部主要是通過監聽binlog事件實現【緩存刷新】和【業務通知】功能

5.分布式DB同步

簡介

* 類似於電商平台【買家和賣家】的划分，神州專車平台對應的划分為【乘客和司機】，為應對性能壓力，我們對DB進行了分庫處理，這樣就產生了兩個維度，主維度是乘客，子維度是司機 我們需要把主維度產生的數據進行Re-Sharding操作同步到司機維度的分庫，以滿足司機數據查詢的需求

主要列舉這些，后續梳理完之后再進行補充