初识数据仓库和维度建模的一些理解和感悟

校招面试的时候面的是java后台，收到的职位offer是大数据相关的东西，虽然啥也不会，不过想到这也是一个比较火的领域，就毅然决然的接受了这个offer。

在来实习之前预习了一下大数据相关的东西，知道了像Hadoop，hive，storm这些底层都是java些的，就算是现在特别流行的spark系，也对java提供了很好的支持，所以以为来了之后还是继续做java，想着应该不会差太多。

不过来实习以后才发现，做的是数据仓库，和java关系不大，最开始老大就说，我们的工作代码量是比较少的，重点在思考，开始还不以为然，也不知道是什么意思，现在真真正正明白了这个意思。哈哈哈，我们的工作重心在于分析如何建模，如何建设数据仓库，如果产出有价值的数据，而这些多在分析，真正想法确定以后，ETL和sql的代码其实非常少，一个任务多了也就两三百行。

有的同学问我来了美团以后做什么工作，我说转行做了数据仓库，他们的第一反应都以为我做了DBA，每次都要解释一番，哈哈

数据仓库

数据仓库与数据库区别

如上图所示，其实数据库和数据仓库的建设过程和管理过程还是有很大区别的，

• 传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。常用的存储主要是，mysql，oracle这些RDBMS的数据库
• 数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。常用的存储是es，hive，sparksql 等基于分析的数据库，并且由于存储的是历史型数据，一般不会做update操作，而是做insert和select操作。提供的功能也是非常多，hive可以支持数组，字典，甚至是类似于c的struct结构体存储

上面说了很多数据仓库与数据库的对比，以及数据仓库的一些概念，但是具体怎么建设数据仓库还没有提，正所谓世间万物皆套路，数据仓库也不例外，也是有章可循的，我理解的，维度建模就是用来建设数据仓库的一种手段。

干巴巴的概念我就不写了，下面引用《数据仓库工具箱》一书中两个我觉得特别生动形象的类比来说明什么是维度建模

1.类比一 以出版发行社为例来说明DW/BI管理者的工作职责

（DW/BI： Data Warehouse/Business Intelligence ：数据仓库与商业智能）

出版社

DB/BI管理者

2.类比二 以餐厅为例描述Kimball架构

（Kimball 是一套业界公认的维度建模的架构）

1

2

3

通过上面的两个类比，以及这段时间工作中的体会，其实我觉得维度建模落地以后说白了和我们在开发一个网站或者app应用时候建立数据库的过程是很相似的，只是很多原则不一样，但是大体思路都是先从领域模型抽象业务，然后形成逻辑模型，最后落地到物理模型（表）

维度就是描述了谁，如何，在哪，为什么，什么样的这些定语的词，而事实就是一个用户行为（比如谁谁谁浏览了一个app的首页，这就是一个行为事实）或者一个可以用来计算的数字（某商店今天卖了一个避孕套，净利润50元，这个50也是事实）

维度建模就是围绕如果抽象维度和事实展开的，具体的我总结了一下几点规则（后面会继续补充）：

1.涉及计算的数据应该放入事实表中（sql中用来count，sum等聚合查询的字段） 2.涉及约束，查询条件，分组条件（又叫行头指针，因为他在select部分的最前面）的应该放入维度表中 3.维度表中的内容应该尽可能全面，详细，在用一个code字段标识后，应该跟一个desc描述字段，解释前面的code的含义，比如 code：1，desc：男 4.维度表不宜为了遵守3NF规范而进一步建立维度（雪花模型），比如一个产品表有类别字段，不宜再将类别建立一张表，因为这样会使查询性能降低（连表查询），并且也省不了多少空间（维度表的大小相比事实表要小的多） 5.相同系列的维度应该放在一个维度表，而不应该建立多个维度表和事实表关联，比如上面4中提到以后，有人可能会在销售事实表中添加类别字段，关联类别维度，但是产品维度和类别维度属于同一系列，所以应该统一放在一个维度表中

下面给出一张零售业务中的维度建模图方便理解

以上是我最近三个礼拜在新工作中的一些感悟和理解，还有很多不完善，不到位，不合理的地方，后面会一一改正，也请大神在评论区多多指教