一、寫在前頭。
早先考慮到並且調研的架構師flume或者canel等讀取mysql的binlog，但是需要mysql開啓row模式存binlog，但是目前mysql庫是已經積攢了很多業務數據，舉個例子就是批量修改一萬條，僅記錄一條update語句，如果改成行，對服務器的磁盤空間要求很大。
但是不開啓行，就會造成，解析binlog的insert還好，我可以解析後放入kafka中，但是如果涉及到update，可能我只能存入到另一個groupid中了，回頭還要在觸發器端消費消息時，解析update後的where條件，反查表，反查的過程是漫長而不可控的，所以純粹的實時是做不到的。所以，flume+kafka+sparkstreaming，就需要捨棄flume了，至少暫時是不可實現的。
好消息是後期這些大表都要改掉，改成按照客戶分庫，那樣，數據庫binlog開啓row模式，就可以按行讀取binlog並且解析了，多好，或者自己寫工具實現。
好了，話不多說，開始說怎麼開發了。
二、思路
首先我們需要spark的jdbcRDD，來讀取mysql數據源，當然了，源表需要開啓createTime和updateTime索引，只要速度夠快，我們可以做小時級任務，10分鐘級任務。
數據源查到後，其實jdbcRDD的行是resultSet數據類型，可以作爲RDD行處理，當然了，這一步有挺多的坑的，國內外的網站找了很多資料才解決這個問題。
從RDD，我們轉換成dataFrame，最後寫入mysql數據庫即可。（這中間正在考慮是否需要引入kafka+sparkstreaming組件）
總體上的事兒是很簡單的，但是業務可不簡單，首先數據源是形形色色的很多個庫的，每個庫可能有20張表，每個表的字段，數據類型都不一樣，然後在我這裏統一組裝。這中間還有很多特別的公司、機構，在業務上需要處理，再者，還需要去目標庫中拿到各個系統的映射字段做系統間的打通工作。
每條記錄在插入之前還需要校驗目標數據該唯一數據是否用戶已修改。
最重要的是，要負責起來普通的hadoop、spark的搭建和運維工作。
三、目前已經克服的難點。
maven集成mysql的jdbc，並且可以完成spark環境的發佈，azkaban調度開發也已經調試完畢，且已經嘗試使用jdbcRDD完成sql語句的數據抽取，同時完成了10分鐘內增量數據的寫入工作。
四、列出來即將克服的問題
1.azkaban時間調度10分鐘準時不，因爲要獲取10分鐘增量的時間。拼接10分鐘區間作爲參數做爲數據源的查詢條件，千萬不能出現缺少時間的情況，否則缺了數據就完蛋了，在哪裏記錄這個時間的任務是否完成了。字段爲create_dt update_dt
2.update_dt要查目標表是否已經被用戶修改過了，要查看update時間在不爲空的情況下，且要大於創建時間，說明目標表中數據已經被更新過，那麼源數據過來就不能覆蓋。其餘的，是允許修改的。所以需要兩套方案，爲了提高效率，會用dataFrame的唯一標識id來做查詢條件，批量overwrite。
3.dataFrame關聯的字段管理，因爲要做各個系統兼容，所以還需要查詢目標庫中的幾張維表，需要全表掃描且轉換爲df。
4.確定幾個字段的讀寫，因爲很多業務數據做不同的用途，有的字段爲空，確定業務數據的接入。例如：業務類型、人數、付款碼、開戶行
5.失敗重跑功能，就像我說的，如果任務跑失敗了，或者azkaban任務排隊了，磁盤滿了等，需要提供一個功能，將一個時間段內的業務數據中的數據源爲數據抽取部分的數據清空情況下，給定時間參數，重新抽取並且插入。
6.5需要驗證數據量，如果全部加載進入內存是否會導致內存溢出，或者時間不可接受。
7.是否引入kafka+sparkStreaming來做數據接入，在消費端降壓。
8.配置中心的開發，做到參數可配置，運維簡單。
9.數據質量管理，數據告警的開發。
10.多種數據源接入，如何高效的、穩定的數據插入業務數據表。
11.多數據源需要創建create_time 和update_time索引，提高查詢效率。這個時間需要一天，運維同學幫忙加個班。後面做了分庫之後，應當做成binlog的方式，做成真真正正的實時。
12.以前的公司特殊處理的部分需要在代碼出寫死操作了。這種特殊情況比較噁心。
13.代碼模塊化，降低複雜度，編寫ut自測，解決bug。
14.獲取windwo與linux的路徑分隔符
暫時列以上幾點，後期可能會補充。