一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表 。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表 。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可 。三、数据应用层:APP(Application)在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、PostgreSql、redis等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用 。比如我们经常说的报表数据,一般就放在这里 。
四、维表层(Dimension)最后补充一个维表层,维表层主要包含两部分数据:
- 高基数维度数据:一般是用户资料表、商品资料表类似的资料表 。数据量可能是千万级或者上亿级别 。
- 低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表 。数据量可能是个位数或者几千几万 。

文章插图
03 举个栗子趁热打铁,举个栗子说明一下,如下图,可以认为是一个电商网站的数据体系设计 。我们暂且只关注用户访问日志这一部分数据 。
- 在ODS层中,由于各端的开发团队不同或者各种其它问题,用户的访问日志被分成了好几张表上报到了我们的ODS层 。
- 为了方便大家的使用,我们在DWD层做了一张用户访问行为天表,在这里,我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面,统一字段名,提升数据质量,这样就有了一张可供大家方便使用的明细表了 。
- 在DWM层,我们会从DWD层中选取业务关注的核心维度来做聚合操作,比如只保留人、商品、设备和页面区域维度 。类似的,我们这样做了很多个DWM的中间表
- 然后在DWS层,我们将一个人在整个网站中的行为数据放到一张表中,这就是我们的宽表了,有了这张表,就可以快速满足大部分的通用型业务需求了 。
- 最后,在APP应用层,根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可 。

文章插图
04 技术实践
既然谈到了数据分层,那不同的层次中会用到什么计算引擎和存储系统呢,本节来简单分享一下 。
数据层的存储一般如下:
- Data Source:数据源一般是业务库和埋点,当然也会有第三方购买数据等多种数据来源方式 。业务库的存储一般是MySQL 和 PostgreSql 。
- ODS 层:ODS 的数据量一般非常大,所以大多数公司会选择存在HDFS上,即Hive或者Hbase,Hive居多 。
- DW 层:一般和 ODS 的存储一致,但是为了满足更多的需求,也会有存放在 PG 和 ES 中的情况 。
- APP 层:应用层的数据,一般都要求比较快的响应速度,因此一般是放在 Mysql、PG、Redis中 。

文章插图
05 思考
本文将思考和总结一下数据分层的原则是什么?为什么要这样分层?每层之间的界限又是什么?
我个人从这几个角度来理解数据分层的划分:
- 从对应用的支持来讲,我们希望越靠上层次,越对应用友好 。比如APP层,基本是完全为应用来设计的,很易懂,DWS层的话,相对来讲就会有一点点理解成本,然后DWM和DWD层就比较难理解了,因为它的维度可能会比较多,而且一个需求可能要多张表经过很复杂的计算才能完成 。
- 从能力范围来讲,我们希望80%需求由20%的表来支持 。直接点讲,就是大部分(80%以上)的需求,都用DWS的表来支持就行,DWS支持不了的,就用DWM和DWD的表来支持,这些都支持不了的极少一部分数据需要从原始日志中捞取 。结合第一点来讲的话就是:80%的需求,我们都希望以对应用很友好的方式来支持,而不是直接暴露给应用方原始日志 。
推荐阅读
- RHEL7网络管理
- 直通车不给展现怎么办 直通车有展现量没有点击量怎么办
- 直通车时间折扣一般都设置多少 直通车时间折扣如何技巧化设置
- 店侦探可以获取店铺的详细销售数据 店侦探是干嘛用的
- 淘宝营销短信文案大全 淘宝短信营销有用吗
- 直通车智能计划点击率低 直通车标准计划和智能计划的区别
- 发生交通事故后,您的车会被扣留多久?
- 直通车投放地区和时间在哪里设置 直通车最好的投放时间
- 直通车是不是开了就不能停 直通车可以停吗
- 直通车智能推广有用吗 直通车投放平台有哪些
