
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
数据建模是大多数软件编程开发程序员都需要熟练掌握的一个编程技术,而本文我们就通过案例分析来简单了解一下,宽表建模需要注意哪些问题。
宽表建模在提升数据易用性及查询性能的同时,也带来了一些挑战:
1)开发成本:宽表为了尽可能多的满足业务需求,封装了大量的ETL处理逻辑及关联计算,这会使宽表代码更加复杂,开发迭代维护成本更高。
2)回溯成本:在业务迭代过程中,往往伴随着指标口径的升级、日志打点的变动,需要宽表回溯历史数据。而宽表本身数据量较大,计算逻辑复杂,回溯时会额外消耗较多的计算资源,存在较高的回溯成本。
3)产出时效:由于宽表本身上游数据源多、数据量大,当多个上游数据就绪时间不尽相同时,宽表的产出时效会出现木桶效应。
针对以上,结合实际应用我们探索了一些解决思路:
开发成本增加,主要原因是宽表进行了更多的ETL操作和封装了更多的指标口径计算,这本质上其实是研发成本和使用成本之间的权衡,将一部分下游用户使用时再计算的成本提前封装到宽表中。而如果宽表的下游用户越多,这种研发成本的提升对整体业务成本实际上是下降的,也就是我们说的降低使用门槛、提升自助化率。因此在当前数据分析平民化的背景下,实际总成本是下降的。
回溯成本的增加,体现在原来只需回溯一个dws或ads层的小表,现在可能要回溯整张宽表。这里在实际生产中,我们在技术上可以探索一些优化方案,包括:
(1)将宽表设置不同的业务分区,回溯时只更新对应的分区数据;
(2)基于宽表作为输入,回溯所需字段,避免重新执行生成宽表的复杂计算逻辑;
(3)利用在线服务夜间空余的潮汐资源,进一步降低回溯资源开销。
上游多个数据源产出时效不同步的问题,这里可以考虑2种方式:
(1)通过上游数据流批一体化改造,提升上游数据时效性
(2)当上游数据无法提速时,可以考虑分批产出不同分区的数据,这种方式需要meta系统和调度系统同步支持,会提升系统复杂度。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。