最近一段時間，在做數據ETL相關的事，結合實踐以及自己的思考，記錄下來，以做參考。

?

概述

?一般來說，數據團隊自己是很少生產數據的，一般都是對業務線的數據進行分析加工，從而讓數據產生價值。一方面，業務線的數據會存到關系數據（如mysql），磁盤（日志）等存儲介質；另一方面，基于大數據的分析一般會將數據存儲到hdfs，hbase，es。因此，不可避免地我們需要在這些不同的存儲介質間同步數據。
從同步時效性來說，可以分為離線同步和實時同步。離線同步，相當于某個時候對源數據做一個快照。而實時同步，一般是通過監控源數據變更操作，通過在目標端實時重放操作，從而達到實時同步的目的（如通過Binlog，EditLog）。

離線同步

?離線數據同步目前已經有開源的實現，比較流行的主要是sqoop和datax，關于她們的歷史，這里不做介紹。本文主要說一下使用sqoop和datax以及自研的一些實踐。

背景

組里最原始的數據同步主要由以下部分組成：
1，用sqoop從mysql導入到hdfs。
2，用自研的工具從hdfs導出到mysql（至于為什么不用sqoop？主要是導出需要做一些ETL處理，sqoop不能滿足需求）。
3，另一套自研的工具從分庫mysql導出到hbase。
通過這個三個獨立的系統，基本能夠滿足日常的數據同步需求。但是存在一些問題：
a, 工具太分散，好幾套獨立的系統不太好維護。
b, 擴展性很差，當初設計時，沒有考慮考慮擴展性，字眼的系統嵌入到了調度系統，很難抽象出來，作為獨立的服務。
c, 服務服務：告警監控不完善等。

?

改造

隨著處理數據量以及任務的越來越大，越來越多，針對以上問題，決定基于開源的datax做深度定制。從而將數據同步服務統一起來。主要的改造點如下：
1，將導入導出服務統一到datax，包括對失敗任務重試，刪除增量刪除等。
2，監控指標和日志統一接入數據平臺。
3，數據質量處理：臟數據告警，默認的類型轉換。
4，schema檢驗等。

實時同步

目標

實現可配置實時同步

設計

輸入和輸出變化很大，但是實時數據同步的核心卻只有兩個問題：
a, 數據不能丟失
b, 對數據亂序進行處理，不能出現舊的數據把新的數據覆蓋了

設計思路主要基于以下兩點：
1，針對不通的輸入和輸出，則必須和核心的處理單元進行解耦，因此源端和目標端因不同的系統，差異很大，所以提供各自的實現。但是必須通過定義好的接口和消息格式，實現統一。
2，核心處理引擎，主要基于storm，然后通過外部存儲系統來保存中間狀態。

小結

總的來說，基于datax改造還是蠻順利的，簡單有效。而基于實時同步系統的設計，可以說也借助了離線同步系統的開源設計思想，通過source和sink分離，核心引擎共享的設計來實現。目前兩套系統已經成功上線，并且效果不錯。

?

轉載于:https://www.cnblogs.com/superhedantou/p/6832340.html

總結

以上是生活随笔為你收集整理的数据同步这点事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。