《分佈式數據倉庫最佳實踐》學員答疑實錄(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
非常感謝上面幾位的分享建議,我都參考一下想一想

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章