讨论一： 我感觉基本的监控要做，然后字段类型，命名统一可以做，ip转地址也可以做。复杂的 不太容易做，数据源的接入不一定都可控。

　　讨论二： 看数据的规整性吧。有的公司业务方数据很规整。ODS层只用做简单的砍字段即可，有的业务数据不规整比如埋点类的那么不做清洗就肯定不行了。有公司是从业务库直接到ODS，那么需要做备份， 有的是从业务库到汇总库再到ODS。那么汇总库就可以看作是备份了。

　　讨论三： 个人觉得ODS层的数据还是需要清洗并存入到数据仓库比较合适。如果不清洗，是ETL任务的计算资源和计算时间的浪费。除非是有特殊需要，规定要原汁原味的“原始数据”。

　　补充

　　这个问题，从本质上来看，其实是和分层的设计以及公司的业务场景相关的。

　　先抛开公司的业务场景来看ODS的设计，我们其实是希望ODS的数据尽量“原汁原味”，但又相对干净。那么，这个尺度或者说标准怎么来把握?简单来看，我们会让ODS层的数据内容和粒度与原始数据一致，然后我们会做表命名统一、字段命名统一、数据落地监控等内容。

　　然后对于数据清洗，居士个人建议是尽量少做清洗，如果在这一层做清洗，建议只在几种情况下做清洗：

　　简单的数据标准化，比如表和字段命名

　　默认值填充，比如性别为空的都补0

　　清洗规则十分明确，比如说说字段拆解：

　　接收到的json数据拆成多个明确字段

　　其余情况下不是不能做清洗，而是说尽量少做清洗，因为一旦对原始数据稍作破坏，以后追查数据的成本会十分巨大。

　　当我们明确ODS的职责后，再来看不同公司的ODS设计。如果说数据源很干净，那么直接拿来就可以，基本不用处理。如果说数据源很混乱，而且清洗的规则十分明确，不会出现返工的情况，那么就可以在入ODS之前做一部分的清洗。

上一篇

大数据面试题汇总(续)---实施方案场景题

下一篇

算法题（力扣）-删除链表的倒数第N个节点