共计 2997 个字符，预计需要花费 8 分钟才能阅读完成。
导读：本文介绍了在互联网产品疾速迭代的趋势下，一层数仓宽表模型代替经典数仓的技术计划，并从互联网业务变动个性、经典数仓模型存在的问题、宽表模型原理及优缺点、宽表利用成果等角度进行了较为全面的剖析，最终通过宽表建模实现了节约数仓存储、晋升查问性能的指标，升高了用户的数据应用老本。
全文 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 的分布式事务调度落地
