net网站开发学什么,网站建设88,检索标准的网站,网络营销策略案例分析目录
写在前面
一、为什么要进行数据仓库建模#xff1f;
二、四种常见模型
2.1 维度模型
2.1.1 星型模型
2.1.2 雪花模型
2.1.3 星座模型
2.2 范式模型
2.3 Data Vault模型
2.4 Anchor模型
三 数据模型的评价标准
小编有话 写在前面
大数据时代#xff0c;维度…目录
写在前面
一、为什么要进行数据仓库建模
二、四种常见模型
2.1 维度模型
2.1.1 星型模型
2.1.2 雪花模型
2.1.3 星座模型
2.2 范式模型
2.3 Data Vault模型
2.4 Anchor模型
三 数据模型的评价标准
小编有话 写在前面
大数据时代维度建模已成为各大厂的主流方式。
维度建模从分析决策的需求出发构建模型为分析需求服务。重点关注用户如何快速的完成数据分析可以直观的反应业务模型中的业务问题需要大量的数据预处理、数据冗余有较好的大规模复杂查询的响应性能。
系列文章详见「数仓系列文章- 传送门」
一、为什么要进行数据仓库建模
性能良好的模型能帮我们快速查询需要的数据减少数据的IO吞吐成本减少数据冗余、计算结果复用、从而降低存储和计算成本效率改善用户使用数据的体验提高使用数据的效率改善统计口径的不一致性减少数据计算错误的可能性
二、四种常见模型
2.1 维度模型
维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型。
Kimball老爷爷维度建模四个步骤
选择业务处理过程 定义粒度 选择维度 确定事实
2.1.1 星型模型
星型模型主要是维表和事实表以事实表为中心所有维度直接关联在事实表上呈星型分布。 2.1.2 雪花模型
雪花模型在星型模型的基础上维度表上又关联了其他维度表。这种模型维护成本高性能方面也较差所以一般不建议使用。尤其是基于hadoop体系构建数仓减少join就是减少shuffle性能差距会很大。
星型模型可以理解为一个事实表关联多个维度表雪花模型可以理解为一个事实表关联多个维度表维度表再关联维度表。 2.1.3 星座模型
星座模型是对星型模型的扩展延伸多张事实表共享维度表。
星座模型是很多数据仓库的常态因为很多数据仓库都是多个事实表的。所以星座模型只反映是否有多个事实表他们之间是否共享一些维度表。 2.2 范式模型
即实体关系ER模型数据仓库之父Immon提出的从全企业的高度设计一个3NF模型用实体加关系描述的数据模型描述企业业务架构在范式理论上符合3NF。此建模方法对建模人员的能力要求非常高。
特点设计思路自上而下适合上游基础数据存储同一份数据只存储一份没有数据冗余方便解耦易维护缺点是开发周期一般比较长维护成本高。
详见一篇文章搞懂数据仓库三范式与反范式_不吃西红柿-CSDN博客_数据仓库三范式 2.3 Data Vault模型
DataVault由Hub关键核心业务实体、Link关系、Satellite实体属性 三部分组成 是Dan Linstedt发起创建的一种模型方法论它是在ER关系模型上的衍生同时设计的出发点也是为了实现数据的整合并非为数据决策分析直接使用。
2.4 Anchor模型
高度可扩展的模型所有的扩展只是添加而不是修改因此它将模型规范到6NF基本变成了K-V结构模型。企业很少使用。 三 数据模型的评价标准
数据模型建设的怎么样极度依赖规范设计如果代码风格是“千人千面”那么恐怕半年下来业务系统就没法看了。没有什么比“数据系统”更看重“法制”了规范体系不仅能保障数据建设的一致性也能够应对业务交接的情况更能够为自动化奠定基础。
业务过程清晰ODS就是原始信息不修改DWD面向基础业务过程DIM描述维度信息DWS针对最小场景做指标计算ADS也要分层面向跨域的建设和面向应用的建设指标可理解按照一定业务事务过程进行业务划分明细层粒度明确、历史数据可获取汇总层维度和指标同名同义能客观反映业务不同角度下的量化程度核心模型相对稳定如果业务过程运行的比较久过程相对固定就要尽快下沉到公共层形成可复用的核心模型高内聚低耦合各主题内数据模型要业务高内聚避免在一个模型耦合其他业务的指标造成该模型主题不清晰和性价比低。
小编有话
在传统企业数仓中业务相对稳定以范式建模为主。 如电信、金融行业等在互联网公司业务变化快需求来来回回的改计算和存储也不是问题我们更关心快速便捷的响应业务需求所以以维度建模为主流。数仓系列传送门https://blog.csdn.net/weixin_39032019/category_8871528.html
