【数仓建模】传统建模与宽表建模有何差异?基于宽表建模实践

  • 一、业务背景
    • 1.1 数据建模现状:
    • 1.2 当前业务特性与趋势
  • 二、面临的问题
    • 2.1 在数据驱动业务越来越重要的大趋势下,面临的问题
    • 2.2 思考
  • 三、技术方案
    • 3.1 大宽表模型替代经典数仓维度模型
      • 3.1.1 大宽表模型架构
      • 3.1.2 大宽表建设方案
      • 3.1.3 大宽表建设原理
      • 3.1.4 宽表优点及性能
      • 3.1.5 宽表带来的挑战
  • 四、总结与规划

来源:百度Geek说

一、业务背景

1.1 数据建模现状:

互联网企业往往存在多个产品线,每天源源不断产出大量数据,这些数据服务于数据分析师、业务上的产品经理、运营、数据开发人员等各角色。为了满足这些角色的各种需求,业界传统数仓常采用的是经典分层模型的数仓架构,从ODS>DWD>DWS>ADS逐层建模,重点支持BI分析,如下图:

1.2 当前业务特性与趋势

互联网产品快速迭代,业务发展越来越快,跨业务分析越来越多,数据驱动业务越来越重要。

数据服务的主要群体正在从数据研发转向产品人员,使用门槛需要进一步降低。

二、面临的问题

2.1 在数据驱动业务越来越重要的大趋势下,面临的问题

面临着如下问题,如下图:

2.2 思考

那么在生产实践中如何解决上述面临的问题及痛点呢,在对业务线进行调研和对具体用户访谈后,根据调研和访谈结论,得出以下想法:

  1. 节约数仓整体存储,数仓不分层,用更少的表满足业务需求,比如一个主题一张宽表;

  2. 明确数据表使用方式,确保口径清晰统一,避免业务方线下拉会沟通,降低沟通成本,提高沟通效率;

  3. 加速数据查询,快速满足业务需求,助力数据驱动业务。

三、技术方案

根据上述的想法,经过可行性分析后,提出一层大宽表模型替代经典数仓维度模型的技术方案,来解决数仓存储大量冗余、表多且口径不清晰和查询性能低的问题。

3.1 大宽表模型替代经典数仓维度模型

3.1.1 大宽表模型架构

用一层大宽表在数仓层内替换使用维度模型建的表,在数仓层间替换传统的ODS>DWD>DWS>ADS逐层建模的分层架构,最终报表和adhoc场景可直接使用大宽表,如下图:

3.1.2 大宽表建设方案

根据产品功能和业务场景的不同,把日志分为不同主题,在各个主题内按各个业务使用的细节程度和业务含义进行宽表建设,建设时统一ods层与dwd层的表粒度,覆盖下游业务所有字段需求,包含明细表所有字段,也覆盖各层的维度字段及指标列,用来满足上层的业务指标分析等各种需求,主要支持报表分析adhoc场景查询,具体如下图:

3.1.3 大宽表建设原理

  1. 采用Parquet列式存储,可支持宽表数百列,超多字段,再经过按列的高效压缩和编码技术,降低了数仓整体存储空间,提高了IO效率,起到了降低上层应用延迟的效果

  2. 将各层之间的事实表复杂嵌套字段打平后与各个维度表、指标等进行join生成宽表,宽表的列最终分为公共属性、业务维度属性和指标属性

3.1.4 宽表优点及性能

1、一层大宽表替换维度模型,通过极少的冗余,做到了表更少,口径更清晰,同时业务使用上更方便,沟通更流畅,效率更高

在同一主题内,建设宽表时将维度表join到事实表中后,事实表列变多,原以为会增加一些存储,结果经过列式存储中按列的高效压缩和编码技术,降低了存储空间,在生产实践场景中,发现存储增加极少。

替换后在数仓层内只有一张宽表,且表结构清晰明了,使得沟通效率大大提升,如下图:

2、经典数仓层与层存在大量冗余,一层大宽表替换多层数仓,数仓总存储下降 30% 左右,节约了大量存储

经典数仓架构中,同一主题在数仓间存在大量冗余存储,比如业务上经常从ODS层抽取字段生成DWD层数据,抽取的字段在这两层间就会出现大量冗余,同理,主题内其他层与层之间也存在大量冗余。

在同一主题内按业务使用的细节程度和具体业务含义,将表粒度精简后统一成一个粒度,按该粒度并包含下游业务所需字段,生成宽表,可避免数仓层间的大量冗余。

也就是整个数仓无需分层,只有一层大宽表,一个主题有一到两个宽表。在生产实践中建设大宽表后,数仓总存储下降30%左右,大大节约了存储成本,如下图:

3、性能对比

到这里可能会有疑问,宽表数据量既然变多了,在查询上会不会有性能损失呢?

可分为三类场景:

  • 场景1:经典数仓表和一层宽表存储相近的情况下,宽表使用了列式存储和统计滤波,简单查询,尤其是简单聚合查询会更快

  • 场景2:依然是经典数仓表和一层宽表存储相近的情况下,经典数仓中需要使用explode等函数进行的复杂计算场景,在宽表中绝大部分需求通过count、sum即可完成,因为宽表会将业务指标下沉,复杂字段拆分打平,虽然行数变多了,但避免了explodeget_json_object等耗时操作,查询性能极高

  • 场景3:经典数仓表和一层宽表存储相差较大的情况下,宽表性能有一定的损失,但在业务接受范围内,影响不大,如下图:

3.1.5 宽表带来的挑战

宽表建模在提升数据易用性及查询性能的同时,也带来了一些挑战:

1、开发成本:宽表为了尽可能多的满足业务需求,封装了大量的ETL处理逻辑及关联计算,这会使宽表代码更加复杂,开发迭代维护成本更高。

2、 回溯成本:在业务迭代过程中,往往伴随着指标口径的升级、日志打点的变动,需要宽表回溯历史数据。而宽表本身数据量较大,计算逻辑复杂,回溯时会额外消耗较多的计算资源,存在较高的回溯成本。

3、产出时效:由于宽表本身上游数据源多、数据量大,当多个上游数据就绪时间不尽相同时,宽表的产出时效会出现木桶效应。

针对以上,结合实际应用我们探索了一些解决思路:

  • 开发成本增加,主要原因是宽表进行了更多的ETL操作和封装了更多的指标口径计算,这本质上其实是研发成本和使用成本之间的权衡,将一部分下游用户使用时再计算的成本提前封装到宽表中。

    而如果宽表的下游用户越多,这种研发成本的提升对整体业务成本实际上是下降的,也就是我们说的降低使用门槛、提升自助化率。因此在当前数据分析平民化的背景下,实际总成本是下降的。

  • 回溯成本的增加,体现在原来只需回溯一个dws或ads层的小表,现在可能要回溯整张宽表。这里在实际生产中,我们在技术上可以探索一些优化方案,包括:

    (1)将宽表设置不同的业务分区,回溯时只更新对应的分区数据;

    (2)基于宽表作为输入,回溯所需字段,避免重新执行生成宽表的复杂计算逻辑;

    (3)利用在线服务夜间空余的潮汐资源,进一步降低回溯资源开销。

  • 上游多个数据源产出时效不同步的问题,这里可以考虑2种方式:

    (1)通过上游数据流批一体化改造,提升上游数据时效性

    (2)当上游数据无法提速时,可以考虑分批产出不同分区的数据,这种方式需要meta系统和调度系统同步支持,会提升系统复杂度。

四、总结与规划

1、宽表建模更适合面向快速迭代的数据驱动型业务,能够提升业务效率

2、基于当前的业务实践,宽表在存储和查询性能方面相比于传统数仓更优

3、在业务效率提升的同时,宽表的建设会对数据生产和维护成本有所提升,还需结合实际应用进一步优化探索

【数仓建模】传统建模与宽表建模有何差异?基于宽表建模实践相关推荐

  1. mysql表 c#实体类,创建基于MySQL表中的C#类

    Is there anything built into .Net or visual studio that will allow my to create classes based off of ...

  2. 数仓建模,宽表是什么?如何设计?

    数仓建模,宽表是什么?如何设计? 宽表的设计 为什么要建设宽表 宽表的好处和不足 如何设计宽表 总结 宽表的设计 其实宽表是数仓里面非常重要的一块,宽表主要出现在dwd 层和报表层,当然有的人说dws ...

  3. 数仓建模,什么是宽表?如何设计?好处与不足

    宽表的设计 其实宽表是数仓里面非常重要的一块,宽表主要出现在dwd 层和报表层,当然有的人说dws 层也有宽表,从字面意义上讲就是字段比较多的数据库表, 通常情况下是将很多相关的数据包括维度表.实时. ...

  4. 谈笑间学会数仓—维度表概念及设计案例

    维度表 维度定义 从某个角度观察事实数据的窗口,存储的数据用来从某个角度描述事实.维度表可以看成是用户用来分析一个事实的窗口,它里面的数据应该是对事实的各个方面描述,比如时间维度表,它里面的数据就是一 ...

  5. 数据仓库系列文章一:浅谈数仓设计

    数仓设计指对数据仓库的各项组成进行规划,在正式建设数仓之前形成指导性建设方案. 数仓设计主要分为两部分:数据仓库同操作型业务系统的数据接口设计和数仓自身建设设计. 本文从多个方面探讨数仓的设计要点,给 ...

  6. 数仓中关于“维度” “粒度”的详细理解(转)

    一.维度是什么 不懂就问,维度是什么?我们学习的自然反应,自然是去查阅专业资料. 1)阿里dataphin产品简介--基本概念是这样介绍维度:人们观察事物的角度,是指一种视角,是确定事物的多方位.多角 ...

  7. 看这篇就明白大数据实时数仓、离线数仓、数据湖之间的关系

    数仓架构演变 20世纪70年代,MIT(麻省理工)的研究员致力于研究一种优化的技术架构,该架构试图将业务处理系统和分析系统分开,即将业务处理和分析处理分为不同层次,针对各自的特点采取不同的架构设计原则 ...

  8. 离线数仓与实时数仓的比较

    01数仓架构演变 20世纪70年代,MIT(麻省理工)的研究员致力于研究一种优化的技术架构,该架构试图将业务处理系统和分析系统分开,即将业务处理和分析处理分为不同层次,针对各自的特点采取不同的架构设计 ...

  9. 数仓系列第11篇:实时数仓

    目录 导读: 1.数据仓库简介 2.数据仓库的发展 3.数据仓库建设方法论 4.数据仓库架构的演变 5.实时数仓案例 6. 实时数仓与离线数仓的对比 导读: 本文将从数据仓库的简介.经历了怎样的发展. ...

最新文章

  1. c语言大数相乘的算法_MIT 算法导论(三)
  2. res里面的drawable(ldpi、mdpi、hdpi、xhdpi、xxhdpi)
  3. 模仿Spring实现一个类管理容器
  4. HashMap TreeMap专题
  5. kafka php 安装配置,kafka安装及Kafka-PHP扩展的使用,kafkakafka-php扩展_PHP教程
  6. application/x-www-form-urlencoded接口响应报文中文乱码
  7. 离子交换树脂工艺解决电脑印刷线路板废水镍超标
  8. 电工培训维修电工基础知识实训教学
  9. 【读书笔记】名创优品的101个新零售细节-张桓.杨永朋,品质和供应链是核心竞争力
  10. vbs编程-执行cmd命令
  11. 马克思主义概论(第二章)
  12. 深海探测机器人——“海洋一号”成功出航!
  13. 计算机桌面背景设成白色,电脑桌面背景变白色的了怎么处理啊?
  14. python3使用staf问题_python调用staf自动化框架的方法
  15. element ui 表格头部内容不换行
  16. 【多线程】初识多线程
  17. muduo网络库:09---多线程服务器之(单线程、多线程服务器的适用场合)
  18. 用VBA代码下载网络上的文件
  19. 国产化的接口测试、接口自动化测试工具apifox的介绍及使用
  20. 数据结构课程设计大作业——江大公交路线查询系统

热门文章

  1. 共享内存机制——mmap和shm
  2. psm倾向得分匹配法举例_倾向得分匹配法(PSM)举例和stata实现.pdf
  3. 怎样让孩子对你说心里话
  4. 24. DICOM图像显示-DCMTK-转换 DICOM 文件编码
  5. nucleo stm32 h743 FREERTOS CUBE MX配置小记录
  6. CC00023.elasticsearch——|HadoopElasticSearch.V23|——|ELK.v23|集群|QueryDSL|复合搜索|
  7. 解决IDEA警告:The file size exceeds configured limit (5.12MB). Code insight features are not available.
  8. 微软或停止开发Win10 Mobile 并关闭手机部门
  9. 【GamePlay】RPG中的战斗与技能系统
  10. 坚定的信念就是成功的一大半