Flink的實時同步(轉載官方文檔)
根據數據源的數據是否實時變化可以把數據同步分爲離線數據同步和實時數據同步，上面介紹的斷點續傳就是離線數據同步裏的功能，實時採集其實就是實時數據同步，當數據源裏的數據發生了增刪改操作，同步任務監聽到這些變化，將變化的數據實時同步到目標數據源。除了數據實時變化外，實時採集和離線數據同步的另一個區別是：實時採集任務是不會停止的，任務會一直監聽數據源是否有變化。
基於binlog的實時採集
目前FlinkX支持實時採集的插件有KafKa，binlog插件，binlog插件是專門針對mysql數據庫做實時採集的，如果要支持其它的數據源，只需要把數據打到Kafka，然後再用FlinkX的Kafka插件消費數據即可，比如oracle，只需要使用oracle的ogg將數據打到Kafka。
這裏我們專門講解一下mysql的實時採集插件binlog。
binlog
binlog是Mysql sever層維護的一種二進制日誌，與innodb引擎中的redo/undo log是完全不同的日誌；其主要是用來記錄對mysql數據更新或潛在發生更新的SQL語句，並以"事務"的形式保存在磁盤中。
binlog的作用主要有：
-
複製：MySQL Replication在Master端開啓binlog，Master把它的二進制日誌傳遞給slaves並回放來達到master-slave數據一致的目的；
-
數據恢復：通過mysqlbinlog工具恢復數據；
-
增量備份；
MySQL主備複製
有了記錄數據變化的binlog日誌還不夠，我們還需要藉助MySQL的主備複製功能：主備複製是指 一臺服務器充當主數據庫服務器，另一臺或多臺服務器充當從數據庫服務器，主服務器中的數據自動複製到從服務器之中。
主備複製的過程：
-
MySQL master 將數據變更寫入二進制日誌( binary log, 其中記錄叫做二進制日誌事件binary log events，可以通過 show binlog events 進行查看)；
-
MySQL slave 將 master 的 binary log events 拷貝到它的中繼日誌(relay log)；
-
MySQL slave 重放 relay log 中事件，將數據變更反映它自己的數據；
canal
有了binlog日誌數據和MySQL的主備複製功能，我們只需要模擬一臺Slave，將接收到的binlog數據解析出來就可以做到實時採集MySQL的數據變化，阿里巴巴貢獻的canal組件就實現了這樣的功能。
canal工作原理：
-
canal模擬 MySQL slave 的交互協議，僞裝自己爲 MySQL slave ，向 MySQL master 發送dump 協議
-
MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )
-
canal解析 binary log 對象(原始爲 byte 流)
寫入Hive
binlog插件可以監聽多張表的數據變更情況，解析出的數據中包含表名稱信息，讀取到的數據可以全部寫入目標數據庫的一張表，也可以根據數據中包含的表名信息寫入不同的表，目前只有Hive插件支持這個功能。
Hive插件目前只有寫入插件，功能基於HDFS的寫入插件實現，也就是說從binlog讀取，寫入hive也支持失敗恢復的功能。
寫入Hive的過程：
-
從數據中解析出MySQL的表名，然後根據表名映射規則轉換成對應的Hive表名；
-
檢查Hive表是否存在，如果不存在就創建Hive表；
-
查詢Hive表的相關信息，構造HdfsOutputFormat；
-
調用HdfsOutputFormat將數據寫入HDFS；