时光冉冉，转眼间，做数据仓库开发工作已经三年了，从最开始的懵懵懂懂跟着老师后面学习，到现在可以自己根据业务独立完成一套数据仓库的架构，中间趟过很多坑，也有很多收获，心得，对数据仓库也有了一个比较完整的认识，总结过去，让自己更快成长。
数据仓库，概念不细说了。在国内的发展也有十多年了，但真正的火爆可能还是因为进入了DT时代吧。当然主要是各种数据仓库理念的发展，数据技术的发展，和人们对数据价值的重视。
闲话不多说，目前，数据仓库，一般分为传统的数据仓库，和大数据数据仓库，主要底层的技术不同，到上层的数据存储，使用方面的理念基本一脉相承
说到数据仓库，首先肯定区分的是和数据库。一般比较普遍的说法：数据库 OLTP (联机事务处理) 数据仓库 OLAP(联机分析处理) ,数据库负责业务的及时处理。数据仓库侧重对已发生的数据的分析。举个简单的例子。存一笔钱，银行立马出来一条存钱的记录，存放在数据库里。如果要知道这个银行有多少客户，每天存进来多少钱，取走多少钱，这样的分析性数据，就是用数据仓库处理。
目前的数据仓库，国内通常按照维度建模的方式进行，按照分层理论进行数据的组织。因为一个数据仓库的数据通常来自很多不同的业务数据库，在存储方式，存储结构等各方面都有很多差异的地方。数据仓库作为一个统一的分析平台。要做到以下几点：
1.数据的前后一致。
在原来的业务数据库里，如果用户的名字是aaa,到数据仓库里绝对不能变成了aa
2.数据的通用性
可能在业务库A中日期格式是YYYY-MM-DD 到业务库B中日期格式是yyyymmdd。又或者在业务库中使用customer_id 表示唯一的客户编码，在业务库中可能使用customer_code作为客户的唯一标识，当把这些数据都汇总到数据仓库中的时候，使用起来就很麻烦。影响分析的效率，增加编码的复杂度
3.数据的存储
一般来说，数据仓库中的数据是历史数据，是已经发生过的事情，不会再改变了的。当我们把数据拉到数据仓库的时候要注意科学存储，我们是把业务表中的数据每天都全部拉过来存储，还是每天只把更新的数据拉过来存储，怎样得到这些每天更新的数据，都要综合考虑
4.考虑数据仓库的易用性
数据仓库的数据一般用来分析使用，怎样让下游的分析平台，业务分析人员能够快速的得到正确的结果，也是体系数据仓库架构的好坏的一个重要的判断标准。
5.数据的安全性
安全性包括3个方面：1.数据不会泄露，主要指数据仓库不被入侵，数据不被盗取
2.数据不会丢失，主要指不会因为内部人员的误操作，使数据被删除或者被改变而无法恢复 3.数据隐私保护，不会被无权限的人看到，这块主要是数据的权限控制。哪些数据对应哪个级别的人可以看。都要规划清楚。
本文主要讲述数据仓库中的分层搭建
正是在综合考虑了数据的存储，使用等各方面的关系后，数据仓库通常采用分层体系架构，一般来说，一个最简单的数据仓库分为三层，贴源层(ODS） ,历史存储层(HIS）,数据模型层(DM），当然大型公司复杂的数据仓库远远不只这些，可能还有根据业务划分的数据集市。数据分发等都统一构建在数据仓库里面。具体根据公司业务来定。本文主要讲述最基本的数据仓库的分层概念
1.贴源层，顾名思义，就是和源体系数据保持一致。一方面，能够保证我们数据仓库的数据来源是真实存在的，另一方面，在出了问题方便进行核对。举个最简单的例子，如果业务反馈说有个数据错了，认为你错了，你在贴源层中就可以去核对。因为一般来说，从安全角度，你是没法查看业务系统的数据库的。再说源数据系统的数据可能也发生了改变，因为业务库是根据事务来产生的。很多的历史操作如果是update的方式，不一定保存下来了。
对于贴源层抽取源系统的数据，一般两种方式：
1.全量抽取，对于数据量不是很大的业务表数据，我们可以每天全量抽取数据
2.增量抽取，对于数据量很大的业务数据，我们一般采取抽取一天或者一段时间的数据的方式吧数据拉到数据仓库中来。
贴源层的数据文件一般按照业务需要和存储空间规划，存储7天，1一个月，1年，永久不等。建议至少保存7天
2.历史层，就是要保存历史的数据。我们知道业务系统是联机事务处理的，好多数据是一直在变化的。而数据仓库是需要历史数据的。并且数据仓库分析用，比如我们要知道一个客户开户以来存钱最多的一次是哪个时候，这种数据就需要把所有的历史数据调出来。如果不把历史的记录保存，我们就没法处理这样的问题
对于历史层来说，主要涉及到的就是存储方式的问题。
因为要保存历史数据，通常数据量会非常大，如果我们直接把贴源层的数据移植到历史层，必然需要非常多的存储资源，特别是有些全量下载过来的数据表。所有对于历史数据存储要有一定的方案
历史数据存储一般有如下几种方式
1.增量切片
增量切片就是把增量的数据(通常按天)插入到历史表中
2.全量切片
把每天的数据都拉过来，一般适合比较小的表，且每天变化大的表
3.拉链表
拉链表相对全量切片而言，适合变化不是很快的表。比如一个客户余额表，可能一个客户10天才取一笔。余额变化信息如果我们每天都存储，10天要存储10遍，但是拉链表只需要增加一个字段，变成1条记录，存储一遍
具体拉链表的概念，自行百度，不过在考虑上面的存储方式的时候，除了了考虑存的空间，还是要考虑好用
综合考虑，历史的，现在的，静态的，动态的，做好存与用的平衡。这很考虑一个数据仓库架构师的经验和能力。
3.数据模型层，数据模型层一般遵循企业的业务体系进行维度建模，也可能会根据某块业务应用进行建模
因为数据模型层的数据一般都经过了一定的加工，数据粒度比较粗，也会存在很多统计性的字段。
在这一块的建议主要两点，1 尽量遵循维度建模，但不要局限在维度建模
2 要注意模型的鲁棒性，每一张表尽量不要针对单一的应用，要考虑可能的业务变化，逻辑统计口径的变化
如上就是一个最基本的数据仓库了，当然一般企业实际应用中不可能这么简单，但一般万变不离其宗，记住如上的几点，
1.数据准确可用，
2.数据历史可查
3.数据安全可控
一个基本能用的数据仓库就有了
网友评论