导读：本文介绍了在互联网产品快速迭代的趋势下，一层数仓宽表模型代替经典数仓的技能计划，并从互联网事务变化特性、经典数仓模型存在的问题、宽表模型原理及优缺点、宽表运用作用等视点进行了较为全面的剖析，终究经过宽表建模实现了节省数仓存储、进步查询功能的方针，下降了用户的数据运用本钱。

全文2995字，预计阅览时间8分钟

一、事务背景

1.1 数据建模现状：

互联网企业往往存在多个产品线，每天连绵不断产出很多数据，这些数据服务于数据剖析师、事务上的产品经理、运营、数据开发人员等各角色。为了满意这些角色的各种需求，业界传统数仓常选用的是经典分层模型的数仓架构，从ODS>DWD>DWS>ADS逐层建模，要点支撑BI剖析，如下图：

△图1

1.2 当时事务特性与趋势

互联网产品快速迭代，事务开展越来越快，跨事务剖析越来越多，数据驱动事务越来越重要。

数据服务的首要集体正在从数据研制转向产品人员，运用门槛需求进一步下降。

二、面对的问题

2.1 在数据驱动事务越来越重要的大趋势下，面对的问题

面对着如下问题，如下图：

△图2

2.2 思考

那么在出产实践中怎么处理上述面对的问题及痛点呢，在对事务线进行调研和对具体用户访谈后，依据调研和访谈定论，得出以下主意：

1）节省数仓全体存储，数仓不分层，用更少的表满意事务需求，比如一个主题一张宽表；

2）明晰数据表运用方法，保证口径明晰一致，防止事务方线下拉会交流，下降交流本钱，进步交流效率；

3）加快数据查询，快速满意事务需求，助力数据驱动事务。

三、技能计划

依据上述的主意，经过可行性剖析后，提出一层大宽表模型代替经典数仓维度模型的技能计划，来处理数仓存储很多冗余、表多且口径不明晰和查询功能低的问题。

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

3.1.1 大宽表模型架构

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

△图3

3.1.2 大宽表建造计划

依据产品功能和事务场景的不同，把日志分为不同主题，在各个主题内按各个事务运用的细节程度和事务意义进行宽表建造，建造时一致ods层与dwd层的表粒度，覆盖下流事务一切字段需求，包括明细表一切字段，也覆盖各层的维度字段及目标列，用来满意上层的事务目标剖析等各种需求，首要支撑报表剖析和adhoc场景查询，具体如下图：

△图4

3.1.3 大宽表建造原理
1）选用Parquet列式存储，可支撑宽表数百列，超多字段，再经过按列的高效紧缩和编码技能，下降了数仓全体存储空间，进步了IO效率，起到了下降上层运用推迟的作用
2）将各层之间的现实表杂乱嵌套字段打平后与各个维度表、目标等进行join生成宽表，宽表的列终究分为公共特点、事务维度特点和目标特点

3.1.4 宽表长处及功能
1）一层大宽表替换维度模型，经过极少的冗余，做到了表更少，口径更明晰，一起事务运用上更便利，交流更流畅，效率更高
在同一主题内，建造宽表时将维度表join到现实表中后，现实表列变多，原以为会添加一些存储，成果经过列式存储中按列的高效紧缩和编码技能，下降了存储空间，在出产实践场景中，发现存储添加极少。
替换后在数仓层内只有一张宽表，且表结构明晰明晰，使得交流效率大大进步，如下图：

△图5

2）经典数仓层与层存在很多冗余，一层大宽表替换多层数仓，数仓总存储下降 30% 左右，节省了很多存储

经典数仓架构中，同一主题在数仓间存在很多冗余存储，比如事务上常常从ODS层抽取字段生成DWD层数据，抽取的字段在这两层间就会呈现很多冗余，同理，主题内其他层与层之间也存在很多冗余。在同一主题内按事务运用的细节程度和具体事务意义，将表粒度精简后一致成一个粒度，按该粒度并包括下流事务所需字段，生成宽表，可防止数仓层间的很多冗余。也便是整个数仓无需分层，只有一层大宽表，一个主题有一到两个宽表。在出产实践中建造大宽表后，数仓总存储下降30%左右，大大节省了存储本钱，如下图：

△图6

3）功能对比

到这儿可能会有疑问，宽表数据量已然变多了，在查询上会不会有功能丢失呢？

可分为三类场景：

场景1：经典数仓表和一层宽表存储附近的情况下，宽表运用了列式存储和核算滤波，简略查询，尤其是简略聚合查询会更快

场景2：依然是经典数仓表和一层宽表存储附近的情况下，经典数仓中需求运用explode等函数进行的杂乱核算场景，在宽表中绝大部分需求经过count、sum即可完成，因为宽表会将事务目标下沉，杂乱字段拆分打平，虽然行数变多了，但防止了explode，get_json_object等耗时操作，查询功能极高

场景3：经典数仓表和一层宽表存储相差较大的情况下，宽表功能有必定的丢失，但在事务接受范围内，影响不大，如下图：

△图7

3.1.5 宽表带来的应战

宽表建模在进步数据易用性及查询功能的一起，也带来了一些应战：

1） 开发本钱：宽表为了尽可能多的满意事务需求，封装了很多的ETL处理逻辑及相关核算，这会使宽表代码更加杂乱，开发迭代保护本钱更高。

2） 回溯本钱：在事务迭代过程中，往往伴随着目标口径的晋级、日志打点的变化，需求宽表回溯历史数据。而宽表自身数据量较大，核算逻辑杂乱，回溯时会额外消耗较多的核算资源，存在较高的回溯本钱。

3） 产出时效：由于宽表自身上游数据源多、数据量大，当多个上游数据就绪时间不尽相一起，宽表的产出时效会呈现木桶效应。

针对以上，结合实践运用咱们探究了一些处理思路：

• 开发本钱添加，首要原因是宽表进行了更多的ETL操作和封装了更多的目标口径核算，这本质上其实是研制本钱和运用本钱之间的权衡，将一部分下流用户运用时再核算的本钱提前封装到宽表中。而如果宽表的下流用户越多，这种研制本钱的进步对全体事务本钱实践上是下降的，也便是咱们说的下降运用门槛、进步自助化率。因此在当时数据剖析平民化的背景下，实践总本钱是下降的。

• 回溯本钱的添加，体现在原来只需回溯一个dws或ads层的小表，现在可能要回溯整张宽表。这儿在实践出产中，咱们在技能上能够探究一些优化计划，包括：

  （1）将宽表设置不同的事务分区，回溯时只更新对应的分区数据；

  （2）根据宽表作为输入，回溯所需字段，防止从头履行生成宽表的杂乱核算逻辑；

  （3）利用在线服务夜间空余的潮汐资源，进一步下降回溯资源开销。

• 上游多个数据源产出时效不同步的问题，这儿能够考虑2种方法：

  （1）经过上游数据流批一体化改造，进步上游数据时效性

  （2）当上游数据无法提速时，能够考虑分批产出不同分区的数据，这种方法需求meta系统和调度系统同步支撑，会进步系统杂乱度。

更多的处理思路，欢迎咱们进一步探讨~

四、总结与规划

1）宽表建模更适合面向快速迭代的数据驱动型事务，能够进步事务效率

2）根据当时的事务实践，宽表在存储和查询功能方面相比于传统数仓更优

3）在事务效率进步的一起，宽表的建造会对数据出产和保护本钱有所进步，还需结合实践运用进一步优化探究

未来规划：根据宽表能够更便利的构建自助剖析平台，进一步进步事务剖析效率。

推荐阅览：

百度谈论中台的规划与探究

根据模板配置的数据可视化平台

怎么正确的评测视频画质

小程序发动功能优化实践

咱们是怎么穿过低代码 “⽆⼈区”的：amis与爱速搭中的要害规划

移动端异构运算技能-GPU OpenCL 编程（根底篇）

云原生赋能开发测试

根据Saga的分布式事务调度落地