脚本宝典收集整理的这篇文章主要介绍了数仓分层架构，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

一.数仓为什么分层

1. 把复杂问题简单化 将复杂的任务分解成多层来完成,每层只处理一个简单的任务,方便定位问题

2. 减少重复开发 规范数据分层,通过中间层数据,能够减少极大的重复计算,增加以此计算结果的复用性

3. 隔离原始数据 不论是数据的异常还是数据的敏感性,使真实的数据与统计数据解耦开

二.数据分层理论

1. ods层也叫贴源层 针对HDFS上的用户行为数据和业务数据，我们如何规划处理？ （1）保持数据原貌不做任何修改，起到备份数据的作用。 （2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右） （3）创建分区表，防止后续的全表扫描

2. dwd层(轻度汇总) 对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）、脱敏等。 DWD 层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型 维度建模一般按照以下四个步骤： 选择业务过程 → 声明粒度 → 确认维度 → 确认事实 （1）选择业务过程 在业务系统中，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流 业务，一条业务线对应一张事实表。 如果是中小公司，尽量把所有业务过程都选择。 （2）声明粒度 数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。 声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以 此来应各种各样的需求。 典型的粒度声明如下： 订单事实表中一行数据表示的是一个订单中的一个商品项。 支付事实表中一行数据表示的是一个支付记录。 （3）确定维度 维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。 确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时 间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间 维度、地区维度、用户维度。 （4）确定事实 此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累 加），例如订单金额、下单次数等。 在 DWD 层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的 明细层事实表。事实表可做适当的宽表化处理。 事实表和维度表的关联比较灵活，但是为了应对更复杂的业务需求，可以将能关联上的 表尽量关联上。如何判断是否能够关联上呢？在业务表关系图中，只要两张表能通过中间表 能够关联上，就说明能关联上。

至此，数据仓库的维度建模已经完毕，DWD 层是以业务过程为驱动。 DWS 层、DWT 层和 ADS 层都是以需求为驱动，和维度建模已经没有关系了。 DWS 和 DWT 都是建宽表，按照主题去建表。主题相当于观察问题的角度。对应着维 度表。

3. DWS 层与 DWT 层(宽表层) （１）需要建哪些宽表：以维度为基准。 （２）宽表里面的字段：是站在不同维度的角度去看事实表，重点关注事实表聚合后的 度量值。 （３）DWS 和 DWT 层的区别：DWS 层存放的所有主题对象当天的汇总行为，例如每 个地区当天的下单次数，下单金额等，DWT 层存放的是所有主题对象的累积行为，例如每 个地区最近７天（15天、30天、60天）的下单次数、下单金额等。

4. ads层(应用层) 对各大主题指标分别进行分析

三.维度模型

1. 星型模型

雪花模型与星型模型的区别主要在于维度的层级，标准的星型模型维度只有一层，而雪花模型可能会涉及多级

2. 雪花模型

雪花模 型，比较靠近3NF，但是无法完全遵守，因为遵循3NF的性能成本太高

3. 星座模型

   

星座模型与前两种情况的区别是事实表的数量，星座模型是基于多个事实表。 基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多个事实表，他们之间是否共享一些维度表。

总结: 模型的选择

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。 星型还是雪花，取决于性能优先，还是灵活更优先。 目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤 其是Hadoop体系，减少Join就 是减少shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）

脚本宝典总结

以上是脚本宝典为你收集整理的数仓分层架构全部内容，希望文章能够帮你解决数仓分层架构所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。