从产品的角度看数仓

背景:因为业务报表需求,需要高精准性,但是公司此前没有做数据产品,所有的数据报表都是从由业务系统直接去抽取。但我们做的是医院的业务系统,一个大三甲的医院三个月就有60多万条数据,导致精准度非常差,数据混乱,脏数据太多,没有办法只能下苦力来做个简单的数据产品做支撑了。

技术的角度:

很热的词:用Hadoop做底层,MapReduce来做存储,还有一些很技术的词

数据抽取工具:kafka、flume、sync

数据清洗:hive/tez、pig/tez、storm、spark

数据存储:hadoop、hbase,ES、redis

任务管理:azkaban、oozie

数据同步:datax、sqoop

如果你是一位技术转的数据产品经理,查一查应该能够理解,但是如果无技术根基,相信你此刻应该很懵逼。

产品的角度:

从产品的角度来梳理,就很好理解了,我们来上个图


详细的ETL流程

从底层向上解释一下

1 所有的数据都来源于业务系统、埋点,日志,但是这些数据很多是用不到的。比如我只需要分析上个月的不同地区、不同年龄段人群的平均下单金额,那么就不需要非相关的数据了。

2 所以第二步,我们只需要抽取需要的数据,这个过程即ETL,抽取我们需要的数据作为备份数据,这个过程是实时的,数据的结构与业务系统一致,可以说是完全一摸一样。我们把这个备份数据叫做ODS数据层。

这里其实是有些小问题的,比如某用户下单了,我们实时的存进ODS,但是过了一个小时,他又退单了,这个时候如何做呢,可以直接修改ODS吗?是不行的,为什么?

因为ODS一般是用hadoop去做的,那么修改所耗费的资源很大,数据量很多的时候就会很消耗资源。哪怕不是用hadoop的技术去实现的,比如MongoDB,修改的话也是很麻烦。

所以一般都用折中的方式,在每写一个数据时,都会添加额外的时间维度、时间刻度,数据来源。这里的ETL需要实时抽取

3 DW层 数据模型层  抽取到ODS后,一般采用每天统一做处理,将数据根据分析目的去做一个数据集市、或者数据仓库(多个数据集市联合)。


主题数据集市

数据集市由事实表和维表构成,这里会有星型模型(集市)、雪花模型(集市)、星座模型(数仓);这三种模型可以自行百度,比较好理解。

建立好事实表和维度表之后,数据集市或者数据仓库就初步搭建好了,接下来需要对这些数据做汇聚。

从ODS到数据模型一般是每天汇总一次

4 在多维数据模型上做数据聚合

我们做主题数据集市都是有目的的,我们举例的目的为:分析上个月的不同地区、不同年龄段人群的平均下单金额。


日期维

地区维:34各省

年龄段维:18岁以下,18-25,25-35,35-60,60以上

订单指标:下单金额,下单数量,平均下单金额

那么对应的多维数据模型如下


多维数据模型

这些对应的维度不是一个值,而是一个维度的值。

我们拿订单指标举例,取不同维度的任意一个值:它对应某一个地区,某一个年龄段,某一个天的(下单金额,下单数量,平均下单金额)。

这里有 30(30天)*34(34个省)*4(4个年龄段) *3(3个时间维度) = 12240个值。

如果我们需要考虑的维度很多呢,比如10个属性,每个属性有10个维度,那么就是10^10  =  10000000000的数据。

做数据聚合也是每天聚合一次。

用一个数据立方体的图来辅助理解


数据立方体

每个维度都去做聚合的好处在于,面对上PB、TB的数据时,能够快速的找到需要的数据,不需要再去跑一遍。

同时能够支撑业务部分或者分析部分的即席查询,也能支撑自定义报表。

但是是否需要用多维数据模型,需要你根据公司的业务来决定,如果没有大量的数据分析,那么只需要做简单的数据聚合即可。



在做数仓的时候,还需要考虑数据的补偿,异常数据的处理。



数仓是用于构建数据中台的,对于数据量小的业务,从业务数据库直接导出excel,再做数据分析也是可以的。


结尾:在做数据产品的时候,是需要搭建数仓的,但是对于大多数产品经理来说,做好数据指标体系,完成数据分析就可以了。

你可能感兴趣的:(从产品的角度看数仓)