数据仓库建设原则规范

一、数据模型架构原则

1. 数仓分层原则

优秀可靠的数仓体系,往往需要清晰的数据分层结构,即要保证数据层的稳定又要屏蔽对下游的影响,并且要避免链路过长。那么问题来了,一直在讲数仓要分层,那数仓分几层最好?

目前市场上主流的分层方式眼花缭乱,不过看事情不能只看表面,还要看到内在的规律,不能为了分层而分层,没有最好的,只有适合的。

分层是以解决当前业务快速的数据支撑为目的,为未来抽象出共性的框架并能够赋能给其他业务线,同时为业务发展提供稳定、准确的数据支撑,并能够按照已有的模型为新业务发展提供方向,也就是数据驱动和赋能。

一个好的分层架构,要有以下好处:

  1. 清晰数据结构;

  2. 数据血缘追踪;

  3. 减少重复开发;

  4. 数据关系条理化;

  5. 屏蔽原始数据的影响。

数仓分层要结合公司业务进行,并且需要清晰明确各层职责,一般采用如下分层结构:

数仓建模在哪层建设呢?我们以维度建模为例,建模是在数据源层的下一层进行建设,在上图中,就是在DW层进行数仓建模,所以DW层是数仓建设的核心层。

1. 数据源层:ODS(Operational Data Store)

ODS 层,是最接近数据源中数据的一层,为了考虑后续可能需要追溯数据问题,因此对于这一层就不建议做过多的数据清洗工作,原封不动地接入原始数据即可,至于数据的去噪、去重、异常值处理等过程可以放在后面的 DWD 层来做。

2. 数据仓库层:DW(Data Warehouse)

数据仓库层是我们在做数据仓库时要核心设计的一层,在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。

DW 层又细分为 DWD(Data Warehouse Detail)层、DWM(Data WareHouse Middle)层和 DWS(Data WareHouse Servce) 层。

1) 数据明细层:DWD(Data Warehouse Detail)

该层一般保持和 ODS 层一样的数据粒度,并且提供一定的数据质量保证。DWD 层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。

同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。

另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性 。

2) 数据中间层:DWM(Data WareHouse Middle)

该层会在 DWD 层的数据基础上,数据做轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。

直观来讲,就是对通用的核心维度进行聚合操作,算出相应的统计指标。

在实际计算中,如果直接从 DWD 或者 ODS 计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在 DWM 层先计算出多个小的中间表,然后再拼接成一张 DWS 的宽表。由于宽和窄的界限不易界定,也可以去掉 DWM 这一层,只留 DWS 层,将所有的数据再放在 DWS 亦可。

3) 数据服务层:DWS(Data WareHouse Servce)

DWS 层为公共汇总层,会进行轻度汇总,粒度比明细数据稍粗,基于 DWD 层上的基础数据,整合汇总成分析某一个主题域的服务数据,一般是宽表。DWS 层应覆盖 80% 的应用场景。又称数据集市或宽表。

按照业务划分,如主题域流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP 分析,数据分发等。

一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。

3. 数据应用层:APP(Application)

在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据,一般就放在这里。

4. 维表层(Dimension)

如果维表过多,也可针对维表设计单独一层,维表层主要包含两部分数据:

高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。 数据量可能是个位数或者几千几万。

2. 主题域划分原则

1) 按照业务或业务过程划分

业务容易理解,就是指的功能模块/业务线。

业务过程:指企业的业务活动事件,如下单、支付、退款都是业务过程。不过需要注意的是,一个业务过程是一个不可拆分的行为事件,通俗的讲,业务过程就是企业活动中的事件。

2) 按照数据域划分

数据域是指面向业务分析,将业务过程或者维度进行抽象的集合。其中,业务过程可以概括为一个个不可拆分的行为事件,在业务过程下,可以定义指标,维度是指度量的环境,如买家下单事件,买家是维度。为保障整个体系的生命力,数据域是需要抽象提炼,并且长期维护和更新的,但不轻易变动。在划分数据域时,既能涵盖当前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。

3. 数据模型设计原则

1) 高内聚、低耦合

即主题内部高内聚、 不同主题间低耦合。明细层按照业务过程划分主题,汇总层按照“实体+ 活动”划分不同分析主题,应用层根据应用需求划分不同应用主题。

2) 核心模型和扩展模型要分离

建立核心模型与扩展模型体系,核心模型包括的字段支持常用的核心业

  • 2
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据仓库模型命名规范是为了保持数据仓库中各个对象(如表、列、视图等)的命名一致性和可读性而制定的一套规则。以下是一些常见的数据仓库模型命名规范: 1. 表名: - 使用有意义的名词或名词短语来描述表的内容。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 2. 列名: - 使用有意义的名词或名词短语来描述列的内容。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 3. 视图名: - 使用描述性的名词或名词短语来表示视图的内容。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 4. 存储过程和函数名: - 使用动词+名词的形式来描述存储过程或函数的功能。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 5. 约束名: - 使用有意义的名词或名词短语来描述约束的类型和作用。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 6. 索引名: - 使用有意义的名词或名词短语来描述索引的内容。 - 使用下划线或驼峰命名法来分隔单词。 - 避免使用特殊字符或缩写,尽量使用完整的单词。 以上是一些常见的数据仓库模型命名规范,具体的规范可以根据实际情况和团队约定进行调整和补充。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值