作者 | Alice菌
责编 | 王晓曼
出品 | CSDN博客
数据仓库纬度模型设计
1. 纬度建模基本概念
维度模型是数据仓库领域大师Ralph Kimall所倡导&＃xff0c;他的《数据仓库工具箱》&＃xff0c;是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型&＃xff0c;构建的数据模型为分析需求服务&＃xff0c;因此它重点解决用户如何更快速完成分析需求&＃xff0c;同时还有较好的大规模复杂查询的响应性能。
维度建模是专门应用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。
1.1事实表
发生在现实世界中的操作型事件&＃xff0c;其所产生的可度量数值&＃xff0c;存储在事实表中。从最低的粒度级别来看&＃xff0c;事实表行对应一个度量事件&＃xff0c;反之亦然。
事实表表示对分析主题的度量。比如一次购买行为我们就可以理解为是一个事实。
图中的订单表就是一个事实表&＃xff0c;可以理解他就是在现实中发生的一次操作型事件&＃xff0c;每完成一个订单&＃xff0c;就会在订单中增加一条记录。
事实表的特征&＃xff1a;表里没有存放实际的内容&＃xff0c;他是一堆主键的集合&＃xff0c;这些ID分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键&＃xff0c;可与维度表关联。事实表的度量通常是数值类型&＃xff08;条/个/次&＃xff09;&＃xff0c;且记录数会不断增加&＃xff0c;表数据规模迅速增长。
1.2维度表
维度表示要对数据进行分析时所用的一个量&＃xff0c;比如你要分析产品销售情况&＃xff0c;你可以选择按类别进行分析,或按区域分析。这样的按…分析就构成一个维度。上图中的用户表、商家表、时间表这些都属于维度表。这些表都有一个唯一的主键&＃xff0c;然后在表中存放了详细的数据信息。
例如&＃xff1a;交易金额分析分析
男性用户的订单金额、联想商品的订单金额、第一季度的订单金额、手机的订单金额、家里下单的订单金额。
例如&＃xff1a;学生分析
姓张的同学有多少、男性的同学有多少、江苏的同学有多少、身高小于170cm的同学有多少、年龄小于23岁的同学有多少。
维度表的特征&＃xff1a;每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键&＃xff0c;当然&＃xff0c;维度表行的描述环境应与事实表行完全对应。维度表通常比较宽&＃xff0c;是扁平型非规范表&＃xff0c;包含大量的低粒度的文本属性。
总的说来&＃xff0c;在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析&＃xff0c;以查询为主&＃xff0c;不涉及数据更新操作。
需要强调的是:
2. 维度建模三种模式
2.1星形模型
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心&＃xff0c;所有的维度表直接连接在事实表上&＃xff0c;像星星一样。
星形模式的维度建模由一个事实表和一组维度表成&＃xff0c;且具有以下特点&＃xff1a;
a. 维表只和事实表关联&＃xff0c;维表之间没有关联&＃xff1b;
b. 每个维表主键为单列&＃xff0c;且该主键放置在事实表中&＃xff0c;作为两边连接的外键&＃xff1b;
c. 以事实表为核心&＃xff0c;维度表围绕核心呈星形分布&＃xff1b;
2.2雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的&＃xff0c;虽然这种模型相比星型更规范一些&＃xff0c;但是由于这种模型不太容易理解&＃xff0c;维护成本比较高&＃xff0c;而且性能方面需要关联多层维表&＃xff0c;性能也比星型模型要低。所以一般不是很常用。
2.3星座模式
星座模式是星型模式延伸而来&＃xff0c;星型模式是基于一张事实表的&＃xff0c;而星座模式是基于多张事实表的&＃xff0c;而且共享维度信息。
前面介绍的两种维度建模方法都是多维表对应单事实表&＃xff0c;但在很多时候维度空间内的事实表不止一个&＃xff0c;而一个维表也可能被多个事实表用到。在业务发展后期&＃xff0c;绝大部分维度建模都采用的是星座模式。
数据仓库分层架构
1. 为什么要分层
分层的主要原因是在管理数据的时候&＃xff0c;能对数据有一个更加清晰的掌控&＃xff0c;详细来讲&＃xff0c;主要有下面几个原因&＃xff1a;
清晰数据结构&＃xff1a;
每一个数据分层都有它的作用域&＃xff0c;这样我们在使用表的时候能更方便地定位和理解。
方便数据血缘追踪&＃xff1a;
简单来说&＃xff0c;我们最终给业务呈现的是一个能直接使用业务表&＃xff0c;但是它的来源有很多&＃xff0c;如果有一张来源表出问题了&＃xff0c;我们希望能够快速准确地定位到问题&＃xff0c;并清楚它的危害范围。
减少重复开发&＃xff1a;
规范数据分层&＃xff0c;开发一些通用的中间层数据&＃xff0c;能够减少极大的重复计算。
把复杂问题简单化&＃xff1a;
将一个复杂的任务分解成多个步骤来完成&＃xff0c;每一层只处理单一的步骤&＃xff0c;比较简单和容易理解。而且便于维护数据的准确性&＃xff0c;当数据出现问题之后&＃xff0c;可以不用修复所有的数据&＃xff0c;只需要从有问题的步骤开始修复。
屏蔽原始数据的异常:
屏蔽业务的影响&＃xff0c;不必改一次业务就需要重新接入数据。
2.数仓分层思想
数据分层&＃xff0c;每个企业根据自己的业务需求可以分成不同的层次&＃xff0c;但是最基础的分层思想&＃xff0c;理论上数据分为三个层&＃xff0c;数据运营层、数据仓库层、数据服务层。基于这个基础分层之上添加新的层次&＃xff0c;来满足不同的业务需求。
数据运营层&＃xff08;ODS&＃xff09;
Operatedata store&＃xff08;操作数据-存储&＃xff09;&＃xff0c;是最接近数据源中数据的一层&＃xff0c;数据源中的数据&＃xff0c;经过抽取、洗净、传输&＃xff0c;也就说传说中的ETL之后&＃xff0c;装入ODS层。本层的数据&＃xff0c;总体上大多是按照源头业务系统的分类方式而分类的。
例如&＃xff1a;MySQL里面的一张表可以通过sqoop之间抽取到ODS层。
ODS层数据的来源方式&＃xff1a;
经常会使用sqoop来抽取&＃xff0c;比如我们每天定时抽取一次。在实时方面&＃xff0c;可以考虑用canal监听mysql的binlog&＃xff0c;实时接入即可。
线上系统会打入各种日志&＃xff0c;这些日志一般以文件的形式保存&＃xff0c;我们可以选择用flume定时抽取&＃xff0c;也可以用用spark streaming或者Flink来实时接入&＃xff0c;当然&＃xff0c;kafka也会是一个关键的角色。
来自ActiveMQ、Kafka的数据等。
数据仓库层&＃xff08;DW&＃xff09;
Datawarehouse&＃xff08;数据仓库&＃xff09;。在这里&＃xff0c;从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中&＃xff0c;便可以结合航空公司的登机出行信息&＃xff0c;以及银联系统的刷卡记录&＃xff0c;进行结合分析&＃xff0c;产生数据集。在这里&＃xff0c;我们需要了解四个概念&＃xff1a;维&＃xff08;dimension&＃xff09;、事实&＃xff08;Fact&＃xff09;、指标&＃xff08;Index&＃xff09;和粒度&＃xff08; Granularity&＃xff09;。
DW数据分层&＃xff0c;由下到上为 DWD,DWB,DWS&＃xff1a;
DWD&＃xff1a;data warehouse detail细节数据层&＃xff0c;是业务层与数据仓库的隔离层。
DWB&＃xff1a;data warehouse base 基础数据层&＃xff0c;存储的是客观数据&＃xff0c;一般用作中间层&＃xff0c;可以认为是大量指标的数据层。
DWS&＃xff1a;data warehouseservice 服务数据层&＃xff0c;基于DWB上的基础数据&＃xff0c;整合汇总成分析某一个主题域的服务数据&＃xff0c;一般是宽表。
数据服务层/应用层&＃xff08;ADS&＃xff09;&＃xff1a;
ApplicationData Service(应用数据服务)。该层主要是提供数据产品和数据分析使用的数据&＃xff0c;一般会存放在ES、MySQL等系统中供线上系统使用。
例如&＃xff1a;我们经常说的报表数据&＃xff0c;或者说那种大宽表&＃xff0c;一般就放在这里。
下面为大家介绍一下阿里巴巴的数据仓库分层架构&＃xff1a;
3. 阿里巴巴数据仓库分层架构
&＃xff08;1&＃xff09;ODS 数据准备层
功能&＃xff1a;
ODS层是数据仓库准备区&＃xff0c;为DWD层提供基础原始数据&＃xff0c;可减少对业务系统的影响。
建模方式及原则&＃xff1a;
从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分。
&＃xff08;2&＃xff09;DWD 数据明细层
功能&＃xff1a;
为DW层提供来源明细数据&＃xff0c;提供业务系统细节数据的长期沉淀&＃xff0c;为未来分析类需求的扩展提供历史数据支撑。
建模方式及原则&＃xff1a;
数据模型与ODS层一致&＃xff0c;不做清洗转换处理&＃xff0c;为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理。
&＃xff08;3&＃xff09;DW(B/S) 数据汇总层
功能&＃xff1a;
为DW、ST层提供细粒度数据&＃xff0c;细化成DWB和DWS&＃xff1b;
建模方式及原则&＃xff1a;
聚合、汇总增加派生事实&＃xff1b;
关联其它主题的事实表&＃xff0c;DW层可能会跨主题域&＃xff1b;
DWB保持低粒度汇总加工数据&＃xff0c;DWS保持高粒度汇总数据&＃xff1b;
数据模型可能采用反范式设计&＃xff0c;合并信息等。
&＃xff08;4&＃xff09;DataMarket(数据集市)层
功能:
建模方式及原则&＃xff1a;
尽量减少数据访问时计算(优化检索)
维度建模&＃xff0c;星型模型
事实拉宽&＃xff0c;度量预先计算
分表存储
&＃xff08;5&＃xff09;ST 数据应用层&＃xff08;ADS层&＃xff09;
功能&＃xff1a;
ST层面向用户应用和分析需求&＃xff0c;包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析&＃xff0c;面向最终结果用户&＃xff1b;
适合作OLAP、报表模型&＃xff0c;如ROLAP , MOLAP&＃xff1b;
联机事务处理OLTP、联机分析处理OLAP。
OLTP是传统的关系型数据库的主要应用&＃xff0c;主要是基本的、日常的事务处理&＃xff0c;例如银行交易。OLAP是数据仓库系统的主要应用&＃xff0c;支持复杂的分析操作&＃xff0c;侧重决策支持&＃xff0c;并且提供直观易懂的查询结果。
OLAP联机分析处理的用户是企业中的专业分析人员及管理决策人员&＃xff0c;他们在分析业务经营的数据时&＃xff0c;从不同的角度来审视业务的衡量指标是一种很自然的思考模式。例如分析销售数据&＃xff0c;可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量。
根据DW层经过聚合汇总统计后的粗粒度事实表
建模方式及原则&＃xff1a;
版权声明&＃xff1a;本文为CSDN博主「Alice菌」的原创文章&＃xff0c;遵循CC 4.0 BY-SA版权协议&＃xff0c;转载请附上原文出处链接及本声明。
原文链接&＃xff1a;
https://blog.csdn.net/weixin_44318830/article/details/105956712
【END】
6月3日20:00&＃xff0c;CSDN 创始人&董事长、极客帮创投创始合伙人蒋涛携手全球顶级开源基金会主席、董事&＃xff0c;聚焦中国开源现状&＃xff0c;直面开发者在开源技术、商业上的难题&＃xff0c;你绝不可错过的开源巅峰对谈&＃xff01;立即免费围观&＃xff1a;
更多精彩推荐☞AI 看脸算命&＃xff0c;3 万张自拍揭露&＃xff1a;颜值即命&＃xff1f;
☞5 月编程语言排行榜&＃xff1a;C 重回第一&＃xff0c;今年编程语言名人堂冠军还会是它吗&＃xff1f;| 原力计划
☞芯片供应被掐断&＃xff0c;华为能否安全渡劫&＃xff1f;
☞来了来了&＃xff01;趋势预测算法大PK
☞附代码 | OpenCV实现银行卡号识别&＃xff0c;字符识别算法你知多少&＃xff1f;
☞15 岁黑进系统&＃xff0c;发挑衅邮件意外获 Offer&＃xff0c;不惑之年捐出全部财产&＃xff0c;Twitter CEO 太牛了
你点的每个“在看”&＃xff0c;我都认真当成了喜欢
京公网安备 11010802041100号