《分佈式數據倉庫最佳實踐》學員答疑實錄（1)：ETL異常情況下載，數據重載策略和機制

守護撤回了一條消息
【潛水】 A 2019/1/15 8:50:46
之前的做法是先卸數到數據文件，如果調度出問題，第二天還可以從數據文件再重新把數據加載上去，還有什麼其他的方法嗎
【話嘮】B 2019/1/15 8:53:04
增量數據，還是全量
【話嘮】B 2019/1/15 8:54:27
源庫數據歸檔備份幾天呢，這方法可行？
【潛水】A 2019/1/15 9:08:21
有的增量有的全量，考慮在不動源庫的情況下，源庫可能已經有備份機制，在倉庫也考慮一下這個情況的處理～
【活躍】C  2019/1/15 9:26:16
ETL不應該都支持重跑歷史麼？
前一天掛了，第二天重跑一下就好了，只要調度工具支持重跑，ETL的代碼也要寫成支持重跑的。
【冒泡】D 2019/1/15 9:51:28
Indeed
貼源緩衝+作業重跑機制，一般是調度要支持N次自動失敗重跑。
【話嘮】B  2019/1/15 9:54:37
@C 它這是從源庫抽取到ods，正常業務系統源庫不保存歷史，只保留最新的，如果是ods到dwd，在倉庫裏，當然可以重跑。
【話嘮】B 2019/1/15 9:56:31
n次自動失敗重跑，作業預警，發短信，郵件？
【潛水】A 2019/1/15 10:04:03
@ 是的，只能支持庫內重跑，源庫只有最新
【潛水】A 2019/1/15 10:05:36
@ @ 現在確實沒有失敗自動重跑的機制，考慮加一下，請問下你們做etl一般會做卸數到數據文件，備份數據文件的操作嗎
【潛水】A 2019/1/15 10:08:05
其實可以直接不用卸數可以直接從源庫加載帶倉庫，但是考慮一個異常情況和數據的備份，爲了更安全，加上卸數到數據文件的操作，一般有沒有必要呢想了解一下
【冒泡】E 2019/1/15 10:11:48
@A 一般都是要卸載爲文件，源庫是不斷變化的，你的度量會丟失
【羣主】北京-胖子哥(1106110976) 2019/1/15 10:12:21
這個裏面就可以看到ODS的價值了。
ODS存儲短週期，貼源數據
【話嘮】B 2019/1/15 10:20:15
 @A 你們的源業務系統庫，都是啥數據庫啊，mysql還是oracle或者其它mongodb，redis，hbase啥的
【冒泡】K 2019/1/15 10:23:30
混雜，Ora、GP、TD都有
【活躍】G  2019/1/15 10:24:32
你講的是源庫到ods當天任務沒成功，第二天跑就丟掉了歷史變更？
【冒泡】K 2019/1/15 10:27:23
對
【潛水】A 2019/1/15 10:28:02
源是oracle
@ 對，第二天源業務庫數據就變了，已經無法從源庫取到前一天的數據了
【活躍】C 2019/1/15 10:42:11
你舉個場景，看看大家有什麼想法，我們很多時候中間狀態可以不要
【潛水】A  10:55:19
比如由於源庫的表結構變了，沒有同步修改倉庫；源庫有異常的數據加載到倉庫出錯了；或者源庫數據量太大數據加載時候出錯了。就是一些比較異常的情況，可能有的也不會發生，就是怕一旦發生什麼想象不到的情況，導致某些表的數據沒有加載過來，還沒有在當天及時處理。
【話嘮】B  10:58:53
你們數倉也是基於hive的嗎
【話嘮】B  11:00:55
我們這邊權限控制嚴格，普通用戶沒有刪表，刪字段權限。如果源庫做變更了增加字段了，必須發郵件，看看上下游是否有影響，再做同步變更。
【話嘮】B 11:02:42
etl報錯是難免的，及時的預警，處理，因爲各種問題，可以維護個問題集，後邊的人報錯了，也可以查看。
【潛水】J  11:04:05
源系統變更一般都會做影響分析的吧
【潛水】A  11:18:22
對  是基於hive的  
源庫的變化都會做影響分析 主要是考慮一些預想外的情況或者疏漏之類的
【潛水】A 11:23:10
非常感謝上面幾位的分享建議，我都參考一下想一想