[已解决]
说清楚数据仓库为什么要分层以及具体怎么分层?
问题求助
1450 人阅读
|
2 人回复
|
2021-03-30
|
讲清楚数据仓库为什么要分层以及具体怎么分?
從未改變已获得悬赏 2 K豆+5 K豆最佳答案
作为一名数据分析人员,肯定希望自己的数据能够有秩序地流转,数据的整个生命周期能够清晰明确地被设计者和使用者感知到。但是,随着业务的发展,频繁迭代和跨部门的业务变得越来越多。这就容易导致数据仓库出现如下问题:1) 缺乏统一的业务和技术标准 ,如: 开发规范、指标口径不统一。2) 缺乏统一数据质量监控 ,如: 字段数据不完整和不准确等。3) 业务知识体系散乱 ,导致数据研发人员开发成本增加。4) 数据架构不合理,数据层之间分工不明显 ,数据流向混乱。5)缺失统一维度和指标管理 。因此,需要一套行之有效的方法来让自己 ...
|
|
|
|
|
|
|
鸿归
发表于 2021-3-30 19:09:04
|
显示全部楼层
数仓分层
000概述
数仓分层是数据仓库设计中十分重要的一个环节,优秀的分层设计能够让整个数据体系更容易理解和使用
本文的大纲
001,介绍数据分层的作用
002,分层设计的原则以及介绍一种通用的数据分层设计
003,具体案例
004,落地实践意见
005,思考
001,数据分层的作用
我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序,这就是数据分层。数据分层的好处有
①,清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解
②,减少重复开发:规范数据分层,开发一些通用的中间层数据,能减少极大的重复计算
③,统一数据口径:通过数据分层提供统一的数据出口,同意对外输出的数据口径
④,复杂问题简单化:将一个复杂的任务分解成多个步骤来完成,每一层解决特定的问题
002,分层设计的原则以及介绍一种通用的数据分层设计
一般情况下,将数据模型分为3层
①,数据运营层ODS:存放的是接入的原始数据。经过ETL之后装入本层,大多是按照源头业务系统的分类方式而分类的。为了考虑后续可能追溯数据为题,因此对这一层不建议做过多的数据清洗工作,原封不动接入源数据即可,至于数据的去噪,去重,异常值处理等过程可以放在后面的DW层
②,数据仓库层DW:重点设计的数据仓库中间层数据,在这里ODS层获得的数据按照主题建立各种数据模型,DW又细分
Ⅰ,数据明细层:DWD(Data WareHouse Detail)
该层一般保持和ODS层一样的数据粒度,并且提供给一定的数据质量保证。同时为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化到事实表中,减少事实表和维度表的关联。另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性
Ⅱ,数据中间层:DWM(Data WareHouse Middle)
在DWD层的数据基础上,对数据做轻度的聚合操作,生成一系列的中间表提升公共指标的复用性,减少重复加工,直观来说,就是对通用的核心维度进行聚合操作,算出相应的统计指标
Ⅲ,数据服务层:DWS(Data WareHouse Service)
又称为数据集市或者宽表,按照业务划分,例如流量,订单,用户等,生成字段比较多的宽表,用于后续的业务查询,OLAP分析,数据分析等。
在实际计算中,如果直接从DWD或者ODS计算宽表的统计指标,会存在计算量太大并且维度太少的问题。一般做法是。在DWM层先计算出多个小的中间表,再拼接成一张DWS的大宽表。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只保留DWS层,将所有的数据放在DWS亦可
一般采用维度模型方法作为理论基础,更多的采用一些维度退化手法,将维度退化至事实表中,减少维度表与事实表的关联,提高明细数据表的易用性;同时在汇总数据层要加强指标的维度退化,采用更多的宽表化手段构建公共指标数据层,提升公共指标的复用性,减少重复加工
例如:
表1:
姓名,城市,年龄
表2:
姓名,订单,订单金额
退化成宽表:
姓名,城市,年龄,订单,订单金额
维度退化感觉就是把维度对应的描述直接放在事实表中,使用时不再关联维度表,把表做宽,查询更方便
③,数据应用层APP:面向业务定制的应用数据
主要提供给数据铲平和数据分析使用的数据,一般会放在ES,MYSQL,Redis等系统供线上系统使用,也可以放在Hive中供数据分析和数据挖掘使用
④,维表层 Dimension
最后补充一个维表层
1,高基数维度数据:一般是用户资料表,商品资料表类似的资料表。数据量可能是千万级或者上亿级别
2,低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万
003具体案例
电商网站的用户访问日志:
1,在ODS层中,由于各端的开发团队不同或者其他问题,用户的访问日志被分成了好几张表,上报到ODS层中
2,为了方便大家的使用,我们在DWD层做了一张用户访问行为天表,在这里,我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面,统一字段名,提升数据质量,这样就有了一张可供大家方便使用的明细表了
3,在DWM层,从DWD层中选取业务关注的核心维度来做聚合操作,比如只保留人、商品、和页面区域维度。类似的 需要做很多歌DWM的中间表
4,然后再DWS层,将一个人在整个网站中的行为数据放到一张表中,这就是我们的大宽表。可以快速满足大部分的通用型业务需求
5,最后在APP层,根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可
004,落地实现
1,DataSouce:数据源一般是公司的业务数据库和埋点数据,当然也有可能是第三方购买数据等多种数据来源方式,一般是mysql
2, ODS:数据量很大,大多数公司选择放在HDFS上,HIVE或者hbase,HIVE居多
3,DW:与ODS存储一致
4,APP:应用层的数据,要求响应快:放在mysql中
005,思考
数据分层的原则是什么?为什么这样分?每层的界限是什么?
1,从对应用的支持来说,越靠上的层次,对应用越友好。比如APP层,基本是完全为应用设计。DWS层的话,相对来讲就会有一点点理解成本,然后DWM和DWD层就比较难理解了,因为它的维度可能比较多,而且一个需求可能要多张表经过很复杂的计算才能完成
2,从能力范围上来讲,我们希望80%的数据可以由20%的表来支持
3,从数据聚合程度来讲,越上层的聚合程度越高
原文链接:https://blog.csdn.net/weixin_42656794/article/details/91818113
|
|
|
|
|
|
|
從未改變
发表于 2021-3-30 19:53:21
|
显示全部楼层
本帖最后由 從未改變 于 2021-3-30 20:04 编辑
作为一名数据分析人员,肯定希望自己的数据能够有秩序地流转,数据的整个生命周期能够清晰明确地被设计者和使用者感知到。但是,随着业务的发展,频繁迭代和跨部门的业务变得越来越多。这就容易导致数据仓库出现如下问题: 1) 缺乏统一的业务和技术标准 ,如: 开发规范、指标口径不统一。 2) 缺乏统一数据质量监控 ,如: 字段数据不完整和不准确等。 3) 业务知识体系散乱 ,导致数据研发人员开发成本增加。 4) 数据架构不合理,数据层之间分工不明显 ,数据流向混乱。 5)缺失统一维度和指标管理 。 因此,需要一套行之有效的方法来让自己的数据仓库更有秩序,这就需要对数据进行分层。
详见word附件及参考资料
|
-
-
一.docx
191.83 KB, 下载次数: 10
数据仓库分层
|
机器精于计算,而我们善于思考,BI助力决策!!!
|
|
|
|