《分布式数据仓库最佳实践》学员答疑实录（1)：ETL异常情况下载，数据重载策略和机制

69 阅读 0 评论 46 点赞

我是靠谱客的博主震动白羊，最近开发中收集的这篇文章主要介绍《分布式数据仓库最佳实践》学员答疑实录（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
非常感谢上面几位的分享建议，我都参考一下想一想