最近一段時間，在做數據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分離，核心引擎共享的設計來實現。目前兩套系統已經成功上線，並且效果不錯。