背景

冷熱庫備份，熱庫保留最近七天的原始數(shù)據(jù)，其余的數(shù)據(jù)都備份到冷庫，平均每天約產(chǎn)生300G的原始數(shù)據(jù)。
熱庫采用業(yè)務上的id和時間每一天來分表，并且有一個分區(qū)的主表，冷庫只按業(yè)務id來分表，天的數(shù)據(jù)都聚合在一起。
使用kettle進行數(shù)據(jù)庫的數(shù)據(jù)備份轉移，有對歷史數(shù)據(jù)做全量備份和對增量數(shù)據(jù)做每天的增量數(shù)據(jù)的兩種方案。

如下所示：
熱庫：
分區(qū)主表： tableName_業(yè)務id
分區(qū)子表： tableName_業(yè)務id_日期
冷庫：
分區(qū)主表： tableName_業(yè)務id
分區(qū)子表： tableName_業(yè)務id_日期

對于某些數(shù)據(jù)量不是太大的表，在熱庫因為考慮性能的原因，依舊會按天進行分表，但是備份到冷庫之后會很少用到，一般都是原始的ods表，只有項目改了方案或者其他情況，需要重跑數(shù)據(jù)或者做數(shù)據(jù)清洗，才有可能使用到冷庫的數(shù)據(jù)。所以某些數(shù)據(jù)量不是太大的表可以在冷庫直接做主表存儲，不做按天分表（不分表或者按月分表）。天表數(shù)據(jù)達到幾百萬的，冷庫依舊是做按天分表。

單表對主表的全量備份

由于是全量備份，需要對所有熱庫的數(shù)據(jù)進行備份到冷庫，其中數(shù)據(jù)量會很大，可能需要很長的備份時長，備份過程可能會出現(xiàn)數(shù)據(jù)庫報錯或者連接數(shù)不足等非意料中的異常，為了方便排查未成功備份的數(shù)據(jù)，使用熱庫子表對冷庫主表備份的方式。當備份出現(xiàn)問題時，直接排查log或者郵件，直接重新備份發(fā)生錯誤的子表就行。

使用update_time的增量備份

增量備份，如果和全量備份一樣使用子表全量備份到主表的方式的話，因為熱庫會保留七天的數(shù)據(jù)，再加上前幾天的天表，可能會有歷史數(shù)據(jù)遺留的數(shù)據(jù)插入進去，那么可能就需要每一天做增量備份的時候，都將熱庫存在的七天的表都重新備份一次冷庫中去。但是前面六天絕大部分數(shù)據(jù)是不需要再次備份的，這樣會浪費比較多的性能。

一般是使用update_time這個字段來進行備份的，每次備份都會先查詢冷庫的表中最大的更新時間maxUpdateTime，然后根據(jù)這個時間去熱庫的表中查詢出所有update_time > maxUpdateTime的數(shù)據(jù)，再將其備份到冷庫中去，這樣用作同步備份的就只有新增和修改過的這一部分數(shù)據(jù)了。

使用Kettle Spoon

1、Kettle Spoon的循環(huán)，通過一個步驟來引入要循環(huán)的變量，另外后面跟一個步驟來循環(huán)執(zhí)行每一個變量

通過SQL獲取表名（上圖中的獲取表類型）：

表循環(huán)任務：

2、Insert/Update和Table Output
備份的時候一般就是選用這兩種方式備份，前面一種會插入數(shù)據(jù)或者更新數(shù)據(jù)（如果主鍵重復），后面一種就是直接插入數(shù)據(jù)，如果主鍵重復則會直接報錯。

需要注意的是，Insert/Update及其消耗CPU資源，而Table Output則性能會好很多，速度也會快很多。如果確定插入的數(shù)據(jù)完全沒有主鍵重復的數(shù)據(jù)的話，最好是使用Table Output進行備份。

3、對于容易出錯的地方都應該做異常處理機制（如與數(shù)據(jù)庫交互的所有操作），如果某些地方在執(zhí)行的地方報錯了而沒有異常處理機制，那么這個任務就會直接終止。

4、使用郵件，配置錯誤信息
有一個Mail的組件，可以拉出來直節(jié)配置，對于郵件地址、賬號密碼等配置就不多說了，主要是在程序發(fā)生錯誤的時候，將發(fā)生的錯誤信息附加在郵件的附件中。


配置好上面兩個步驟，當發(fā)生異常時，就會發(fā)送一個異常郵件出來，并且郵件會攜帶一個包含錯誤日志的附件過來。