浅谈数据仓库体系(2)

如上文所说，一个基本的数据仓库分为贴源层，历史层，数据模型层

本文主要来讲一下贴源层(ODS），重点是如下三个方面

1.贴源层的数据清洗

2.贴源层的数据存储

3.贴源层的数据校验

一.数据清洗

贴源层，一般来说抽取的是源系统的数据，是一个数据缓冲区，和源系统保持一致，但并不是说贴源层的数据就可原来的一模一样不变了

贴源层也要做基本的数据清洗，数据清洗时贯穿整个数据仓库的全流程的。

贴源层的数据清洗主要包括两方面

1.数据类型

我们一般搭建大型的数据仓库，目前来说主要是搭建在hadoop 大数据集群上，当然以前可能也搭建oracle的数据仓库，但我们的业务系统的数据则可能来自oracle，mysql，sql server 等不同类型的数据库，虽然这些数据库在大体上都遵从通用的数据类型，但也存在细微的差别，如果对数据类型不处理好，就可能导致进到数据仓库的数据和源系统的不一样。

      举一个简单的例子，在mysql 中的double 类型，进入到hive 里面，可能有适合对double类型的支持不一定很好，这时候，可能就需要改变相关的数据类型，比如用decimal 来代替，举一个我遇到的情况，0.0001 在hive里用double 类型，可能存储的就是科学计数法的数据了，那这样的数据类型如果不处理，到后面得到的就是错误的数据了。

2.明显的差错数据

明显的差错数据简单讲两个方面的：

1>.是空数据，可能源系统因为是事务性的，在做某些操作时，存在误操作在所难免，可能就导致空数据等明显的脏数据进到数据库中，其实空数据一般来说不影响我们的统计不清洗也可以，但有时候这样的脏数据过多，我们也需要做一个基本的清洗

2>.是有特殊字符的错误数据，如果不清洗对数据导入数据仓库会造成影响的，比如某些字段中有换行符号，如果不进行处理，可能导致数据进入数据仓库错位

当然另外一种观点贴源层，数据不做任何清洗，错也错的一样。当然也有他一定的道里。

二.数据存储

数据存储这里指以什么样的方式导入数据仓库存储。

通常导入数据的方法无非两种，1.增量切片，2.全量

这里介绍两个选择存储的方法

1.数据量级，如果数据量都比较小，通常选择全量导入，因为这样导入是最安全，最简单，最高效的，当然这样的数据进ods容易，以后在历史层的存储可能能就会复杂点，这里以后再讲

2.如果数据量级比较大，那这个时候我们就要考虑增量的方式了，一方面大量的数据需要耗费很多的存储空间，另一方面在抽取数据的时候需要很多的时间。在这种情况下，对于按照时间等维度每天增量更新的数据，且历史数据不再改变的或者变化的是近期数据的，我们可以选择增量导入1天或者一段时间的数据，保证新增的数据都进入ODS，当然对于大数据量的有时候也会遇到比较坑的存储数据，比如源库只对源表进行update操作，并且update的时间字段无法使用的，这样就只能全部导入了。

还有一种比较特殊的情况，这里举一个我在工作中遇到的可能一个比较经典的情况吧：在我呆的上家公司，客户表每天在源库是update的，就是有新的客户进来就会增一条记录，客户信息有变化就会改一条记录，但是，也行是系统原因还是不知道什么原因，以源库的updatetime 时间字段去增量导入新数据，总会漏部分数据，每天都这样，开始以为updatetime 时间字段可能延迟了，就取前1个月更新的数据，最后发现还是会有部分更新的数据没拿进来，导致报表出错，后天想了一个办法，客户的客户号是唯一的，用客户号大于多少，小于多少去取源数据，这样就能够把所有的数据都拿进来了。

3.在系统空间允许的情况下，一般建议拿到ODS的数据保留3个月以上，如果存储空间比较紧张的建议最少保存7天的，在oracle中如果空间不够，可以考虑把7天之前拿过来的数据进行压缩存储。

三.数据校验

一般来说数据贴源层的数据校验不说说要保证贴源层的数据一定正确，而是要保证和源业务库一致，错也要错得一样。所以这一层的校验主要在1.数据条目 2.数量类字段的求和值

数据条目，这个肯定是要核对的，但每天源系统一般抽取的数据表会非常多，建议最好写出自动化的脚本自动比对。数量类的核对主要怕中间的数据导致错误，比如漏了一条新数据，但是某个数据插入了两遍等，如果源表有金额字段，可以sum（金额）看下源库和ODS库是否相同。

这里有一点要注意的是，因为此步的核对涉及到对源库的操作，可能不一定是所有的公司都会开发这种权限给数据仓库，还有一点，自动化的脚本对源库操作要适度，不能影响源库的正常工作使用。

四 总结

其实关于ODS这一层我们感觉很简单，就把数据拿过来吧，这个过程很容易出一些低级的错误，一定要保持数据敏感性，在源头上把好数据这一关，不然后面都白搭。看似最无用，其实最关键，这就是贴源层