浅谈数据仓库

前言

写该篇文章有2个目的：
1、 输出倒逼输入，对工作学习做一个总结、查漏补缺
2、 帮助刚入行的同学建立对数仓的初步认识

一、 数仓是啥

要解释这个问题，首先先思考下"仓库"的含义。我们能够想到，仓库一般有一下几个特点：
1、 接受货物；
2、 存放货物；
3、 分发货物；
4、 。。。；

数仓的功能非常类似，核心也就是下面的功能：
1、 采集数据；
2、 存储数据；
3、 分发数据；
4、 。。。

地方

这样一看，数仓其实跟实体仓库从本质上看没啥区别，不同点在于：
1、 仓库存储有形物品，无法复制；
2、 数仓存储数据，而数据是可以被复制的；
3、 仓库看得见、摸得着，而数仓你是看不到数据在硬盘中如何存储的，但是你能通过数据模型从逻辑上感受。

其实，它们之间还有很多类似，比如说在仓库会划分不同区域，按照货物种类统一存储，（超市也一个道理），
数据同样也会分类存储，同时仓库的货物流（入-存-发）与数仓的数据流也基本是一个意思，只不过某个货物运走了就没了，而数据是永远存在的。
这里只是借助这个例子，让大家能够将过往的生活经验代入进来，更快的理解什么是数仓，毕竟思想永远是相通的。

二、 为啥要数仓

有很多理由说服我们搭建数仓，但核心就一个：取数成本太高。
先解释一下：
取数：说明公司已经认识到数据中的价值，想要从数据中获取更多有用的信息，这个			是前提；
成本高：
1、 需求很频繁、很急，不然也谈不上成本高；
2、 数据量很大，不然直接抽业务数据库不香吗；
3、 数据质量不高，数据分布在多个系统，部分数据缺失、重复且不一致，无法确定真实的数据源，用户难理解、不敢信；
是的，如果没有上述问题，基本不用考虑数仓，日常怎么方便怎么来。

三、 怎么搭建数仓

这个理论太多了，个人也没有深入去研究，一种说法是这样子的：
1、整理业务过程以及关联的维度、输出数据血缘；
2、抽象核心实体，进行实体-关系建模，输出概念模型；
3、归纳核心实体，如果该实体在多个业务过程均参与了业务且能够从特定视角描述业务过程，那么将这类实体归纳于维度数据；

第2步我们得到了所有的核心实体，且梳理出了它们之间的关系，第3步我们归纳这些实体为事实和维度；
4、填充属性，生成逻辑数据模型；

上面完事了，大头工作就差不多了，剩下的就是，数仓架构设计、模型设计（清洗、转码、标准化、生命周期、安全）、开发规范、ETL、调度等等。

业务过程: 业务操作层面不可分割的步骤, 例如我们网购一般有下面几步:
加入购物车、下单、支付、撤销、确认收货等等，其中每一步都是一个业务过程，一些列业务过程就组成了某个业务流程；

四、 怎么衡量产出

3.1 初期

做表就得了，初期的产出就看你做了多少张可用的表，至于什么业务流程图、维度建
模总线矩阵、数据资产目录、数据血缘等等，暂时不考虑。
为啥？因为没那么多的资源去梳理这一堆东西，用户的第一印象是你有没有，然后才
是好不好。理论永远得结合实际。数仓是一款不停迭代的产品，你别指望着它完美，
够用就行了。永远记得一句话：先有没有，再好不好。

3.2 中期

尽量让更多的人通过数仓使用数据，哪怕只是一个简单的查询，只要你能够提供他们
之前没有得到过的体验，就行了。大部分传统企业的业务想要分析数据，成本还是挺
高的，所以哪怕是一个简单的跨系统关联之后返回的数据，对一线业务来说，可能也
会带来很大的便利。有人用，才能体现价值，有价值才有资源的持续投入。

3.3 长期

这个具体的玩法我也接触不多，反正就是基于数据给业务带来了价值， 比如说：
1、 相对之前，我能更快看到企业的经营状态；
2、 相对之前，不同的部门之间的相同指标统计口径是一致的；
3、 库存成本相较于之前降低了。。。
4、 物流周期相较于之前减少了。。。
5、 业务现在能够及时根据市场效果调整营销方案。。
6、 。。。

五、 总结

数仓是一款产品，必须有任用才能体现价值，而且数仓无法为企业带来最直接的效益，小步快走，快速迭代是一个可行的选择，希望这篇文章能够为刚入行数仓从业者提供一点参考，也欢迎大家留言讨论。