数仓分层建设

为什么要分层

在实际的工作中,我们都希望自己的数据能够有顺序地流转,设计者和使用者能够清晰地知道数据的整个声明周期。优秀可靠的数仓体系,需要良好的数据分层结构。合理的分层,能够使数据体系更加清晰,使复杂问题得以简化。合理的分层概括就是:清晰的数据结构与依赖,提高开发效率,合理的数据权限。具体具有以下优点:

数据结构与依赖关系:如果没有清晰的分层,可能会做出一套表依赖结构混乱,且出现循环依赖的数据体系,让流程越走越越死。

减少重复开发的成本:建立一个或者多个模型,可以为支业务撑建立多个指标。规范数据分层,开发通用的中间层,可以极大地减少重复计算的工作。

统一数据口径:通过数据分层,提供统一的数据出口,统一输出口径。

数据一致性:对于公共下沉数据,下游使用的时候不再重新计算,可以保证一定是数据一致性问题。

数据权限:通过分层,可以更方便地对不同层,不同的数据模型进行权限管理,特定业务场景下,对不同的开发人员和业务人员屏蔽一些敏感的数据。

怎么分层

ODS(原始数据层)

存放最原始的数据,结构和源系统保持一致,减少对业务系统的影响。

DWD(明细数据层)

在维度建模的理论上进行构建,存放维度模型中的事实表,保存各业务过程最小粒度的操作记录。有时候,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。

DIM(公共维度层)

在维度建模的理论上进行构建,存放维度模型中的维度表,保存一致性维度信息。维度类分两种类型(自己概括的):

大维度数据:比如用户维度等等

小维度数据:比如配置表,日期表,地区表等等

DWS(汇总数据层)

基于上层的指标需求,以分析的主题对象作为建模驱动,构建公共统计粒度的汇总表。该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。主要作用就是提升指标的复用性,减少重复加工。单维度下的轻度汇总表维度单一,统计指标丰富,迭代更灵活;多维度的轻度汇总表,维度丰富,统计指标有限,迭代相对复杂。

ADS(数据应用层)

存放各项统计指标结果。

分层的误区

数仓层内部的划分不是为了分层而分层,分层是为了解决数据 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。对于上面分层罗列,是种通用的建设分层逻辑。可能你也看到有四层的,有六层的,甚至更多的,比如DWD,DWB,DIM,DWM,MID......虽然每层你知道什么意思,但是有时候不是很清楚这些层之间的分割线是什么,出现复杂的业务反而让我们无法下手。所以各个业务不同,需要合适自己的就好。

所谓的宽表

经历几家公司,也听过好多公司,通常做法是把很多的维度、事实相关联后形成一个所谓的宽表。可能刚开始维度数据比较少,但是跟着业务的增长冗余维度增加,宽表足够的事实,足够的维度宽。带来影响就是没有清晰的表结构和随意增长的宽度。

所以,一些人开始强调划分主题,按照某一主题事实去扩展维度。也即宽表的涉及不依赖具体的业务需求而是根据整体业务线相匹配。

分层规则与规范

ODS

(1) 根据源业务系统表的情况以增量或全量方式抽取数据。

(2) 以统计日期和时间进行分区保存。

(3) 数据基本不做清洗和转换,数据的表结构和数据粒度与原业务系统保持一致。

DWD

(1)对数据做清洗、转换,脱敏等等处理,可以对表结构进行裁剪和汇总等操作。

(2)不是所有的数据都要永久保存,根据业务周期去做出决定。

DWD层中主要的事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。

事务型事实表

是什么

事务事实表用来记录各业务过程,跟踪时间上某点的度量事件,它保存的是各业务过程的原子操作事件,即最细粒度。

场景

事务型事实表可用于分析与各业务过程相关的各项统计指标,由于其保存了最细粒度的记录,可以提供最大限度的灵活性,可以支持无法预期的各种细节层次的统计需求。

不适合干什么

(1)存量型指标不适合

比如说商品库存,账户余额... 对于这种存在进进出出(加或减操作)不适合。一张存储商品的进货的原子操作事件,一张存储商品出库的原子操作事件。如果要统计当日的库存有多少,这就需要对进货表和出库表进行操作,需要一正一反地区分对库存的影响。所以在写代码或者sql过程还是执行效率都会打折扣。

(2)多事务关联统计不适合

比如在订单中,建立了下单事务事实表和支付事务事实表,现在指标统计某个时间内用户下单到支付的时间间隔的平均值,这就需要这两个表的Join操作,然而,订单在大型公司属于大表,大表 Join 大表 你可想而知。

周期型快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,一般周期可以是每天、每周、每月、每年等。主要用于分析一些存量型或者状态型指标

场景

存量型:例如对于商品库存、账户余额这些存量型指标,业务系统中通常就会计算并保存最新结果,所以定期同步一份全量数据到数据仓库,构建周期型快照事实表,就能轻松应对此类统计需求。

状态型:例如对于空气温度、行驶速度这些状态型指标,由于它们的值往往是连续的,我们无法捕获其变动的原子事务操作,所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样,构建周期型快照事实表。

累积型快照事实表

用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个时间字段来记录关键时间点,当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改。

场景

如交易流程中的下单、支付、发货、确认收货业务过程。会具体记录下单时间,支付时间,发货时间,收获时间。如果统计某个时间内用户下单到支付的时间间隔的平均值。这样就轻松搞定。

对比

DIM

(1) 维度在不同的业务表中的字段名称、数据类型、数据内容必须保 持一致。

(2)可以将维度与关联性强的字段进行整合,一种是水平整合:不同的表包含不同的数据,会使得维度本身的记录数变多,是对原有维度的记录数上的补充。另一种是垂直整合:不同的来源表包含相同的数据集,维度本身记录数不会变,只是会对维度属性进行补充。

(3)拆分针对重要性,业务相关性、源、使用频率等可分为核心表、扩展 表。一种是水平拆分:两个业务相关性低,整合在一起会对模型的稳定性和易用性产生影响。另一种是垂直拆分:维度属性从落库时间,使用频次,等等因素考虑上需要进行拆分放到子维度上。

DWS

(1)存放比较全的历史数据,业务发生变化时易于扩展,适应复杂的实际业务情况。

(2)尽量减少数据访问时的计算量,优化表的关联。

(3)可以有数据冗余。

(4)不要在同一个表中存储不同粒度的聚集数据。

ADS

(1)数据公用性。

(2)清晰明了的统计周期。

推荐阅读以往类似博文:

浅谈数仓建模_奔跑者-辉的博客-优快云博客

### 数据仓库分层架构 数据仓库分层架构是一种常见的设计理念,旨在通过将据按照不同的加工阶段划分为多个层次来提高系统的可维护性和灵活性。以下是典型的数仓分层架构及其作用: #### 1. **ODS (Operational Data Store)** 操作型据存储(ODS)位于数据仓库体系的第一层,主要负责接收来自各个业务系统的原始据并进行初步处理。这一层的特点是保留了接近实时的据状态,并可能包含一些简单的清洗逻辑。 - ODS 的核心功能是对源系统据进行轻量级转换和加载,以便后续更深层次的分析使用[^3]。 - 它能够提供准实时查询能力,满足部分对时效性要求较高的应用场景。 #### 2. **DWD (Data Warehouse Detail Layer)** 明细据层(DWD)作为第二层,承担着进一步规范化和标准化的任务。此层会基于 ETL 流程完成复杂的据清洗、去重以及格式统一等工作。 - DWD 中的据通常是高度结构化且贴近实际业务过程的事实表与维度表形式[^1]。 - 这一层的设计遵循第三范式(3NF),确保据的一致性和准确性。 #### 3. **DWS (Data Service Layer)** 服务据层(DWS)专注于构建面向特定主题域的宽表,这些宽表经过预聚合或关联计算后可以直接服务于下游应用的需求。 - 此处的据模型更加贴合最终用户的视角,减少了重复性的联接运算负担。 - 星型模式或雪花型模式常用于该层以优化性能表现。 #### 4. **ADS (Application Data Service Layer / Analysis Layer)** 应用/分析据层(ADS)是最靠近终端消费者的环节,在这里可以针对具体的商业问题定制个性化的指标统计报表或其他可视化展示内容。 - 开发者可根据不断演进的企业战略目标动态调整此处的内容配置。 - ADS 提供了一个灵活多变的空间让分析师探索未知领域的同时也保障既有成果不受干扰。 --- ### 数据仓库设计原则 为了实现高效稳定的储解决方案,需严格遵守如下几项基本原则: #### 1. **清晰的目标导向** 每一步建设都应围绕解决具体业务痛点展开规划,避免盲目堆砌技术组件造成资源浪费。 #### 2. **良好的扩展性支持** 考虑到未来可能出现的新需求变化情况,预先留有足够的接口余地使得新增模块易于接入整体框架之中而不影响现有运转秩序。 #### 3. **高质量元据管理** 建立健全完善的文档记录机制对于长期运维至关重要,它不仅有助于新人快速理解项目全貌还能促进跨团队协作效率提升。 #### 4. **安全性考量贯穿始终** 无论是物理层面还是逻辑层面都要采取必要的防护措施防止敏感信息泄露风险发生。 --- ### 数仓建模方法论对比 两种主流的方法分别是 Kimball 和 Inmon 架构,它们各自具备独特的优势适用于不同类型的组织环境: - **Kimball 方法**提倡自下而上的实施路径优先考虑如何迅速交付价值给前端使用者群体,因此特别适合那些希望尽快见到成效的小型企业或者是某些局部范围内的专项改进工程。 - 而相比之下,**Inmon 方法**则主张先搭建好全局视图再逐步填充细节内容的方式更适合大型跨国集团这类拥有众多分支机构需要统一对话语言的情况因为只有这样才能真正意义上达成全方位的信息共享目的。 ```sql -- 示例 SQL 查询语句演示如何从 DWD 层生成一张简单的产品销售汇总表至 DWS 层 SELECT product_id, SUM(sales_amount) AS total_sales FROM dwd_product_transaction_fact GROUP BY product_id; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值