#48 浅谈数据仓库（DW & BI）

Posted 2021-04-24 沉默是金 话唠是银

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

历史文章：

#42 浅谈数据仓库（DW & BI）（一）：

#43 浅谈数据仓库（DW & BI）（二）：

#44 浅谈数据仓库（DW & BI）（三）：

#45 浅谈数据仓库（DW &BI）（四）：

       我这个人挺无聊的，有时会想，怎样的公司是伟大的？怎样的公司是强大的？在一些特定行业，某些公司可能会因为一些资源的垄断而蓬勃生长，但在寡头垄断市场、完全竞争市场，一个公司到底要依托于什么去超越其他同行业的公司？是管理、技术、战略、产品、服务、运营吗？还是说只要有一样顶尖，其余不拖后腿就足够了？

       很早之前参加过一次培训，有个词很喜欢，叫“业务改进”，数据的作用就在于业务改进吧，不管是发现业务风险、销售激励、商机挖掘、竞对分析、赋能生产等等，其核心就是业务改进，提供决策支持。可以说，在一个比较传统产品公司内，数据主要是解决运营问题的吧。

 

 上一篇讲到OLAP相关概念，一个简单的产品销售的业务过程，其实就可以观察到谁（用户）在哪里（渠道）在什么时候（时间）购买（行为）了什么多少产品（产品），付了多少钱等等。但是这样一条数据里面，我们有了不同的维度（括号内的可以理解为是一个维度），这样的数据多了以后，我们就可以勾画出这个企业这条业务线的基本内容：包含产品、用户、渠道、时间等维度下销售量、销售额相关信息。传统的数仓建模会将这个过程复杂化（优点是很统一），可能一个销售量的OLAP数据应用发布要花上5-10个工作日（甚至更长）的时间来完成，但是这样一个业务流水的信息业务运营人员是很急切的，维度建模就是针对这类敏捷数据应用的工具。

       KIMBALL维度建模是根据一些业务过程，快速实现应用的一套建模方法，绕开了复杂的主题、域设计，是自下而上的，比较敏捷，十分便于理解。核心在于快速构建基于事实表与维表的星型模型，实现快速数据发布。建模步骤：

1、选择业务过程：业务过程是由组织完成的微观活动，可能是销售订单、采购订单、用户注册这类事件，一般来说是可以用动词描述的行为、在操作源系统中完成、存在一些关键的度量。

2、声明粒度：精准定义数据表中一行代表的含义，是要什么细节程度的数据。（一般来说越细节越有用，越能应对后续的数据需求，但是也存在过于细致的细节对数据库性能和存储产生的影响，且可能对后续维度和事实的确认引起问题）

3、确认维度：应尽可能的采用健壮的维度，确认数据使用人员关注的点。

4、确认事实：业务过程的度量是什么？例如销售额、订单量相关事实。

 

 不同的业务过程均采用类似的模式建立，那么在一些核心维度上（例如时间、渠道、产品），我们需要做的是构建强壮且合适的维表，即可满足整个企业重要业务生产活动的经营状况透视与分析了。维表提供了观察数据的不同角度，以最简单的时间维度为例，我们可以构建这样的时间维表：日期（yyyymmdd）|日期2（yyyy-mm-dd）|具体日期（yyyy年mm月dd日）|周天（周一）|日（DD）|月（MM）|年（YYYY）|季度（Q1）|财月（FYYYY-01）|是否节假日（Y/N）|是否工作日（1/0）|周数（第12周）|是否是今天（1/0）|是否是最近30天（1/0）|是否是最近90天（1/0）|是否今年（1/0）|……

 这样，在实现OLAP的时候，就可以自由选择想观察的时间维度了，同理，构建层次分明的产品、渠道维表，就可以快速观察某一经销商、某一城市、某一片区的相关业务发展情况了。

 

 当然，维表和事实表还有很多其他的技术，下次再说啦。

---

好看的皮囊千篇一律

有趣的灵魂一成不变

浮夸的人生别有风味

沉默是金 话唠是银

或搜索ID im-wudi 添加关注