0x00 前言
本篇的主题是数据分层中的ODS的作用，关于数据分层可以参考本篇博客:如何优雅地设计数据分层
。
下面直接进入讨论的主题。
0x01 讨论
问题： ODS 有的公司说几乎不处理，有的说这一层要做第一次数据清洗，大家怎么看？
回答一： 我感觉基本的监控要做，然后字段类型，命名统一可以做，ip转地址也可以做。复杂的 不太容易做，数据源的接入不一定都可控。
回答二： 看数据的规整性吧。有的公司业务方数据很规整。ODS层只用做简单的砍字段即可，有的业务数据不规整比如埋点类的那么不做清洗就肯定不行了。有公司是从业务库直接到ODS，那么需要做备份， 有的是从业务库到汇总库再到ODS。那么汇总库就可以看作是备份了。
回答三： 个人觉得ODS层的数据还是需要清洗并存入到数据仓库比较合适。如果不清洗，是ETL任务的计算资源和计算时间的浪费。除非是有特殊需要，规定要原汁原味的“原始数据”。
0x02 补充
这个问题，从本质上来看，其实是和分层的设计以及公司的业务场景相关的。
先抛开公司的业务场景来看ODS的设计，我们其实是希望ODS的数据尽量“原汁原味”，但又相对干净。那么，这个尺度或者说标准怎么来把握？简单来看，我们会让ODS层的数据内容和粒度与原始数据一致，然后我们会做表命名统一、字段命名统一、数据落地监控等内容。
然后对于数据清洗，居士个人建议是尽量少做清洗，如果在这一层做清洗，建议只在几种情况下做清洗：
- 简单的数据标准化，比如表和字段命名
- 默认值填充，比如性别为空的都补0
- 清洗规则十分明确，比如说说字段拆解：接收到的json数据拆成多个明确字段
其余情况下不是不能做清洗，而是说尽量少做清洗，因为一旦对原始数据稍作破坏，以后追查数据的成本会十分巨大。
当我们明确ODS的职责后，再来看不同公司的ODS设计。如果说数据源很干净，那么直接拿来就可以，基本不用处理。如果说数据源很混乱，而且清洗的规则十分明确，不会出现返工的情况，那么就可以在入ODS之前做一部分的清洗。
0xFF 总结
感谢 rorovic 和 其他朋友的回答。感谢木东居士的整理和总结。
个人主页：http://www.mdjs.info
文章可以转载, 但必须以超链接形式标明文章原始出处和作者信息
网友评论