本文主要是介绍数据仓库五层架构，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1. 数据仓库五层架构规范

1.1 数据仓库为什么要分层

1. 把复杂问题简单化，每一层只处理简单的任务，方便定位问题；
2. 减少重复开发，规范数据分层，通过中间层数据能够减少重复计算，且增加计算结果的复用性；
3. 隔离原始数据，不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

1.2 DW五层架构的特点

• 细化DW建模，对DW中各个主题业务建模进行了细分，每个层次具有不同的功能。保留了最细粒度数据，满足了不同维度、不同事实的信息；
• 满足数据重新生产，不同层次的数据支持数据重新生成，无需备份恢复，解决了由不同故障带来的数据质量问题，消除了重新初始化数据的烦恼；
• 减少应用对DW的压力，以业务应用驱动为向导建模，避免直接操作基础事实表，降低数据获取时间；
• 快速适应需求变更和维度变化，明细基础数据层稳定，适应前端应用层业务需求变更，所有前端应用层模型之间不存在依赖，需求变更对DW整个模型影响范围小，能适应短周期内上线下线需求。
  

1.3 ODS（Operational Data Store）原始数据层

数据准备区，也称为贴源层。数据仓库源头系统的数据表通常会原封不动的存储一份，以此减少对业务系统的影响，也是后续数据仓库加工数据的来源。业务DB基本上是直接同步过来，LOG主要做结构化。

1.3.1 ODS层数据的来源方式

业务库

• 可使用Sqoop来抽取，例如每天定时抽取一次；
• 实时接入，考虑用canal监听MySQL的binlog；
• Flume、Sqoop、Kettle等ETL工具导入到HDFS，并映射到HIVE的数据仓库表中。

埋点日志

• 日志一般以文件的形式保存，可以选择用Flume定时同步；
• 可以用Spark Streaming或者Flink来实时接入；
• Kafka。

消息队列

• 来自ActiveMQ、Kafka的数据等。

1.3.2 建模方式及原则

• 从业务系统增量抽取；
• 保留时间由业务需求决定；
• 可分表进行周期存储；
• 数据不做清洗转换与业务系统数据模型保持一致；
• 按主题逻辑划分。

针对HDFS上的用户行为数据和业务数据，我们如何规划处理？

• 保持数据原貌不做任何修改，起到备份数据的作用；
• 数据采用压缩，减少磁盘存储空间；
• 创建分区表，防止后续的全表扫描。

1.4 DWD（Data Warehouse Detail）明细数据层

DWD是业务层与数据仓库的隔离层，主要对ODS数据层做一些数据清洗（去除空值、脏数据、超过极限范围的数据）、规范化、维度退化、脱敏等操作。

1.4.1 建模方式及原则

• 需要构建维度模型，一般采用星型模型，呈现的状态一般为星座模型（由多个事实表组合，维表是公共的，可被多个事实表共享）；
• 为支持数据重跑可额外增加数据业务日期字段，可按年月日进行分表，用增量ODS层数据和前一天DWD相关表进行merge处理；
• 粒度是一行信息代表一次行为，例如一次下单。

1.4.2 维度建模步骤

1. 选择业务过程：在业务系统中，挑选感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。如果是中小公司，尽量把所有业务过程都选择。如果是大公司（1000多张表），选择和需求相关的业务线。
2. 声明粒度：数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。典型的粒度声明如下：订单当中的每个商品项作为下单事实表中的一行，粒度为每次。每周的订单次数作为一行，粒度为每周。每月的订单次数作为一行，粒度为每月。如果在DWD层粒度就是每周或者每月，那么后续就没有办法统计细粒度的指标了。所以建议采用最小粒度。
3. 确定维度：维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。确定维度的原则是：后续需求中是否要分析相关维度的指标。例如，需要统计，什么时间下的订单多，哪个地区下的订单多，哪个用户下的订单多。需要确定的维度就包括：时间维度、地区维度、用户维度。维度表：需要根据维度建模中的星型模型原则进行维度退化。
4. 确定事实：此处的“事实”一词，指的是业务中的度量值（次数、个数、件数、金额，可以进行累加），例如订单金额、下单次数等。在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

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

1.5 DWS（Data Warehouse Service）服务数据层

DWB：data warehouse base 数据基础层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。
以DWD为基础，按天进行轻度汇总。粒度是一行信息代表一天的行为，例如一天下单次数。

1.5.1 功能

• DWB是根据DWD明细数据经行清晰转换，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等；
• DWS是根据DWB层数据按各个维度ID进行粗粒度汇总聚合，如按交易来源，交易类型进行汇合。

1.5.2 建模方式及原则

• 聚合、汇总增加派生事实；
• 关联其它主题的事实表，DW层可能会跨主题域；
• DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据；
• 数据模型可能采用反范式设计，合并信息等。

1.6 DWT（Data Warehouse Topic）数据主题层

以DWS为基础，按主题进行汇总。粒度是一行信息代表累积的行为，例如用户从注册那天开始至今一共下了多少次单。

1.6.1 功能

• 可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储；
• 满足一些特定查询、数据挖掘应用。

1.6.2 建模方式及原则

• 尽量减少数据访问时计算，优化检索；
• 维度建模，星型模型；
• 事实拉宽，度量预先计算；
• 分表存储。

1.7 ADS（Application Data Store）数据应用层

面向实际的数据需求，同步到关系型数据库服务RDS。该层主要是提供数据产品和数据分析使用的数据，一般会存储在ES、mysql等系统中供线上系统使用。我们通过说的报表数据，或者说那种大宽表，一般就放在这里。为应用层，这层数据是完全为了满足具体的分析需求而构建的数据，也是星形结构的数据。应用层为前端应用的展现提现数据，可以为关系型数据库组成。

1.7.1 功能

• ST层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户；
• 适合作OLAP、报表模型，如ROLAP、MOLAP；
• 根据DW层经过聚合汇总统计后的粗粒度事实表。

1.7.2 建模方式及原则

• 保持数据量小；
• 维度建模，星形模型；
• 各位维度代理键+度量；
• 增加数据业务日期字段，支持数据重跑；
• 不分表存储。

1.8 其他层

数据缓存层：用于存放接口方提供的原始数据的数据库层，此层的表结构与源数据保持基本一致，数据存放时间根据数据量大小和项目情况而定，如果数据量较大，可以只存近期数据，将历史数据进行备份。此层的目的在于数据的中转和备份。
临时数据表层：存放临时测试数据表（Temp表），或者中间结果集的表。

2. 补充点

2.1 事实表

是数据仓库结构中的中央表，它包含联系事实与维度表的数字度量值和键。事实数据表包含描述业务（例如产品销售）内特定事件的数据。
1)、事实表就是你要关注的内容；
2)、维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
例如，某地区商品的销量，是从地区这个角度观察商品销量的。事实表就是销量表，维度表就是地区表。

2.2 维度表

是维度属性的集合。是分析问题的一个窗口。是人们观察数据的特定角度，是考虑问题时的一类属性，属性的集合构成一个维。数据库结构中的星型结构，该结构在位于结构中心的单个事实数据表中维护数据，其它维度数据存储在维度表中。每个维度表与事实数据表直接相关，且通常通过一个键联接到事实数据表中。星型架构是数据仓库比较流向的一种架构。
星型模式的基本思想就是保持立方体的多维功能，同时也增加了小规模数据存储的灵活性。

2.3 主题表

主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域，因此这个数据仓库应用的主题就是“销售分析”。
面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。例如，一个生产企业的数据仓库所组织的主题可能有产品订货分析和货物发运分析等。而按应用来组织则可能为财务子系统、销售子系统、供应子系统、人力资源子系统和生产调度子系统。

2.4 宽表

含义：指字段比较多的数据库表。通常是指业务主体相关的指标、纬度、属性关联在一起的一张数据库表。
特点：宽表由于把不同的内容都放在同一张表，宽表已经不符合三范式的模型设计规范：
坏处：数据有大量冗余
好处：查询性能的提高和便捷
宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提供数据挖掘模型训练过程中迭代计算的消息问题。

2.5 数据库设计三范式

为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式时符合某一种设计要求的总结。
第一范式：确保每列保持原子性，即要求数据库表中的所有字段值都是不可分解的原子值。
第二范式：确保表中的每列都和主键相关。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
作用：减少了数据库的冗余
第三范式：确保每列都和主键列直接相关，而不是间接相关。

2.6 数仓命名规范

表命名

• ODS层命名为ods_表名
• DWD层命名为dwd_dim/fact_表名
• DWS层命名为dws_表名
• DWT层命名为dwt_表名
• ADS层命名为ads_表名
• 临时表命名为xxx_tmp
• 用户行为表，以log为后缀
• 数据源_to_目标_db/log.sh
• 用户行为脚本以log为后缀
• 业务数据脚本以db为后缀
• 数量类型为bigint
• 金额类型为decimal(16,2)，表示：16位有效数字，其中小数部分2位
• 字符串(名字，描述信息等)类型为string
• 主键外键类型为string
• 时间戳类型为bigint

脚本命名

• 数据源_to_目标_db/log.sh
• 用户行为脚本以log为后缀；业务数据脚本以db为后缀

表字段类型

• 数量类型为bigint
• 金额类型为decimal(16, 2)，表示：16位有效数字，其中小数部分2位
• 字符串(名字，描述信息等)类型为string
• 主键外键类型为string
• 时间戳类型为bigint

这篇关于数据仓库五层架构的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！