数据仓库体系之贴源层、历史层

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

二、历史层

重点是如下三个方面

1.历史层的数据清洗

2.历史层的数据存储

3.历史层的数据校验

历史层，顾名思义，就是保存所有的历史数据，我们知道数据仓库的一个原则就是数据是不变的，就是说进来了的数据就不做更改，不做删除，那这个不做更改，不做删除，主要体现在的就是历史层。

数据仓库体系是一个OLAP体系，主要用来分析历史数据的，那么历史层数据的保存就显得异常的重要。

（一）历史层的数据清洗

到了历史层，其实对清洗的要求也不会很高，如果在ODS层做了基本的清洗，那么在历史层要做的清洗就更少了。历史层因为是保存历史的数据，简单的理解就是把ODS的数据全部都存一遍，历史层的粒度最好还是保持最细的粒度，在历史层来说，相对更为重要的应该是存储了。本文也主要讲述历史层的存储

（二）历史层的数据存储

历史层的数据存储主要有4种，1.全量，2.增量切片，3.全量切片，4.拉链。

1.全量

如前面ODS讲到的，如果我们是全量把数据导入到ODS的，我们会根据业务需要，如果是缓慢变化的，或者确认这种变化后对我们的业务作用基本可以忽略不计的，我们通常就采取全量的方式存储，这样的存储方式其实是和ODS里面一样的。

2.全量切片

如前面ODS讲到的，如果我们是全量把数据导入到ODS的，如果数据量不是很大的话，我们通常考虑全量切片的方式。就是把每一次全量抽取过来的数据都保存下来，然后在后面加一个操作时间字段

这里要讲一下选择全量存储，还是全量切片存储的问题：

对于数据仓库来说，因为要保存历史的数据，历史的变化，那么在这种原则下，我们肯定优先选择全量切片存储了。但是，我们还需要考虑其他的存储和实际的业务情况。

1）是存储空间的问题，假设一张很大的表从源体系全量抽取的，每天1个T，一年下来就365T，hive中再乘以3，那对存储空间的要求实在太多了。可能这张表变化的字段就是一个一年就用一次的字段。从存储和使用比来说，划不来。

2）是使用问题，在hive这种有分区的数仓体系中还好，如果是oracle，TD等数据仓库，如果这张表存储了1年的数据，我要查一个某一天的数据的某一部分，可能怎么样都没法查出来了

所以通常的原则是：

1）小表、变化比较频繁的表、变化的字段比较重要，经常要进行历史对比的表，考虑全量切片。

2）如果是变化比较慢，并且变化的字段基本不用的，全量存储即可。比如，一张地区维度表，把北京市统一改为北京存储了，其实就没有必要每天都存一遍了。

3）数据量大，变化的字段比较缓慢的，也考虑用全量表。

那么这里问题就来了，如果数据量大，变化的字段又比较重要呢？

也许这真的就是数据存储中的一个难题了，现在数据量大，变化又快的情况，可能主要使用的还是增量切片的方式。

3.增量切片

就是把新增的数据存储下来，或者说变化的数据存储下来，一般来说，这是当前一种主要的存储形态。

主要优点有2个：

1）增量数据相对全量数据来说，量级会少好多，会节省很多存储空间。

2）每天存储变化的值，在我们做相关使用时，效率会更高，总体的数据量级会少。

4.拉链表

拉链表对于很多人来说可能比较陌生，一般做数据仓库时间短的人，可能都不会接触到这种类型的表，并且目前考虑用这种表存储的情况，实际来说比较少，这里就说两点：1.拉链表本质上适合与缓慢变化的大量数据集，2.拉链表的使用不方便。

（三）历史层的数据校验

历史数据的准确性，是数据仓库分析的基础，对于历史数据的校验，其他也遵循通用的校验方法，因为多了历史数据缘故，还可以加一些趋势性的校验方法，比如同比，环比的数据总量，某一类指标的变化阈值，都可以根据历史数据做一定的预警。

中翰软件：专注数据治理17年（http://www.jobhand.cn）