DataTalk：ODS层的数据需要做数据清洗吗？

最新推荐文章于 2024-06-14 11:20:52 发布

weixin_33725239

最新推荐文章于 2024-06-14 11:20:52 发布

阅读量489

点赞数

文章标签： python 大数据人工智能

原文链接：https://my.oschina.net/leejun2005/blog/82706

版权

2019独角兽企业重金招聘Python工程师标准>>>

DataTalk：ODS层的数据需要做数据清洗吗？

0x00 前言

本篇的主题是数据分层中的ODS的作用，关于数据分层可以参考本篇博客:如何优雅地设计数据分层。

下面直接进入讨论的主题。

0x01 讨论

问题： ODS 有的公司说几乎不处理，有的说这一层要做第一次数据清洗，大家怎么看？

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

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

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

0x02 补充

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

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

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

简单的数据标准化，比如表和字段命名
默认值填充，比如性别为空的都补0
清洗规则十分明确，比如说说字段拆解：接收到的json数据拆成多个明确字段

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

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

0xFF 总结

感谢 rorovic 和其他朋友的回答。感谢木东居士的整理和总结。

——————————————————————————————

DataTalk：是一个宽表好还是多个维表好？

0x00 前言

本篇的主题是关于数据模型的规范化和反规范化的讨论，其实也是一种常见的维度建模的设计和业务使用便捷性的冲突。

0x01 讨论

问题：

在设计数据表的时候，是一个宽表好，还是多个维度表好？

回答一：

数据仓库每张表的搭建，主要依赖于这个表在整个数据仓库中的作用和相关意义。首先要清楚这个表的存在是为了解决那些问题，什么角色使用，怎么保证使用者尽可能好的体验解决问题。从以上所提到的角度去看待问题，拆解以下几点因素：

拆表情况下多张数据表的查询SQL的编写难度有多大，是否会出现为了数据提取需要关联多张表，并且需要提前知道各个表之间的关联关系。如果使用这个数据的人员较多，每个人都需要先了解所需要多张表的关联关系，然后才进行数据查询，这样是不是维度沟通成本较高，查询体验下降，影响使用者的工作效率？
多表关联查询的使用频次有多高，将重复高频的事情简化，是不是更好？
查询体验上需要考虑多表关联之后的查询性能问题，如果一张表的内容过度，是否影响查询速度？
多表关联的合理性，不同的数据维度和内容与订单表关联，是不是会存在违背常理的坑存在。比如，数据字段的对应关系是一对一，还是多对多，是否会让使用者忽略查询数据时候的过滤限制条件。
数据的安全问题，每张数据表的安全范围不同，合并成同一张表是面临的是更大的权限开放。比如订单表可能仅需要让一部分人员知晓订单信息，并不想让他们知道供应商信息。

回答二：

结合我司的一些经验来说说哈，我司会将数据用于各种各样不同主题和纬度的报表,也会将数据用于数据挖掘做模型的，因此数据分成肯定是必要的，针对报表类的数据根据报表的不同反向划分出不同的纬度表,这种方式其实就是将mysql业务库的数据经过sql语句之后重新生成一张或者多张维度表,在这之中根据经验会抽取出一个经常用的字段作为公共字段放入公共层数据中,一些经常需要用到的度量值也会抽取到度量表中,那么一些非开发人员来看数据的时候只要在页面上简单写几个sql语句就可以统计出数据来,比如月销量,周销量,日销量这些。

若是机器学习模型的同学要数据的话,我们就只需要从维度表,度量表,事实表中抽取数据做成大宽表给他们了,由于模型做的比较少,对于大宽表的经验比较少,暂时只能来一个模型数据的需求,单独写sql语句去抽取。

0x02 补充

这个问题，从本质上来讲。想讨论是数据模型设计里面的规范化和反规范化的问题。

从规范化的角度来讲，数据仓库的设计者是希望越规范越好，因为这样会减少数据的冗余，而且也便于模型的扩展。从反规范化的角度来讲，数据仓库的使用者是希望使用越方便越好，他们并不太关系规范不规范冗余不冗余，只要用着方便就好。

这种情况在工作中是十分常见的，那么该怎样来解决它？下面有两个思路：

两种方式都存。虽然，这样看起来会占用更多的存储空间，但不失为一种合适的解决方案，因为宽表是通过别的表拼接而成的，因此宽表的存储周期是可以短一些。
只存多个维度表，通过视图来创建宽表。这种方式适合于宽表的查询次数较少的情况。比如在Hive中，宽表其实只是为了计算出来之后导入Es等系统中供其它系统查询，那么久没必要存储一份宽表，直接通过视图来封装就可以。

另外，数据仓库的设计，往往不能是以计算出几张表就结束了，我们更应该提供的是数据服务，让使用方都通过服务的方式来访问我们的数据，而不是简单地将表暴露出去。当我们以数据服务的方式提供数据的时候，不管是易用性还是安全性都更容易得到满足。