作者介绍

@图图

BAT数据产品经理

专注数据产品、持续学习中

“数据人创作者联盟”成员


1

什么是宽表?


从字面意义上讲就是宽表就是字段比较多的数据库表,多应用于DWD层或报表应用层,将很多维度、事实、指标等关联汇总成一张数据表。区别于DWS层,宽表往往是跨主题的,且字段较多(宽表之宽),所以非常适合用来查询和提升效率,缺点是数据冗余和存储要求较高。


2

为什么要建设宽表?


数据仓库建模大多数时候是要严格遵循建模要求的,星型模型或者雪花模型,而宽表的特点在于跨业务主题,所以很难遵循标准的建模要求和范式结构,而且宽表建模也没有严格的数仓分层概念,所以对于分层的好处管理方便、问题定位、节约资源等也是比较缺失的,那么我们建设宽表呢?


① 可以统一指标口径


这个问题对于大厂来说是非常常见的,大厂的特点是业务广泛,那对于做数据的同学来说面临的挑战就是数据源多、数据流复杂、口径统一困难。由于上述种种困难,就会带来报表口径不一致这种常见问题,然而这种问题是很难通过口径统一来去解决的,因为就算口径统一了,数据流各个环节的处理过程的差异,对于数据产品来说去定位也是很困难的。


如果我们的报表要是都能从宽表出,那么我们报表上的指标口径肯定是一样的,其实这一点很多人都深有体会,同一个指标的口径不一致,导致我们提供的数据在不同的出口不一样,是业务部门经常提出的一个问题。所以把核心逻辑下沉到宽表,收敛口径,这样可以解决大部分指标口径不统一的情况。


② 可以提升开发效率


如果报表层的需求都能从宽表处,那么除了上述统一指标口径的好处之外,也避免了我们从头开始计算,如果每一张报表都要从DWD甚至ODS开始加工,那么不仅开发效率很慢,数据流过于复杂对于问题排查也不是很友好。


③ 可以提升数据质量


宽表的准确性都需要经过逻辑及数据准确性的校验,对于开发来说人为开发,逻辑错误的可能性很小,可以直接使用,要是从头开发的话,很容易出现因为对业务理解不透彻或者导致取数逻辑有问题,进而导致数据质量问题。


④ 可以建设自助化查询工具


当上面讲了这么多建设宽表建设的好处,提到对应用层的好处其实不多,或者说更偏向于数仓为了解决各类统计问题给出的解决方案,但是对于数据产品来说应该思考现有的技术架构升级,为了我们数据产品的建设或者提升业务取数效率能够做些什么。那么除了报表层统一口径,数据产品可以基于宽表规划一些更多应用类形式,比如自助化查询工具、自定义生成查询SQL,自助报表建设等。


这么做的思想是:将宽表的维度和指标尽量透明化给业务,业务可以自取所需进行分析,这样就把业务提需给数据产品这种关系,转变成数据产品提供给业务我们能为你提供什么样的分析能力,业务按照自己的需求进行自助分析,这也就是实现了这个环节上数据产品的价值。


3

如何设计宽表?


① 宽表到底多宽


宽表到底要多宽?按照上面介绍的貌似什么字段都可以往宽表里装,但事实上并不如此,如果什么字段都放在宽表,那么数仓分层貌似也没什么意义了,所以这个问题的答案是:要从需求出发。


从需求出发的话,宽表设计虽然可以跨主题,但肯定不会跨域进行分析。可以先按照需求高频场景进行初版设计,后续慢慢扩充,但扩充并不是无原则扩充,一定要进行合理评估。


② 宽表字段如何设计


作为数据产品可以从日常需求出发,考虑哪些字段是常用且高频使用的,对以下字段明确口径和逻辑,这样就便于数仓进行开发了。最好输出一个表字段说明文档,其实也是一个数据产品和数仓对齐业务了解的好机会。

具体到设计过程应该如下:


· 深挖日常业务需求;

· 将业务需求进行分类,筛选出高频需求特点;

· 对高频需求进行拆解,落实到指标和维度,形成一个初版的表结构文档;

· 除了高频需求之外有哪些常用字段,如地域信息、用户标签等信息,丰富宽表属性;


4

宽表的局限性


① 性能不高


因为我们的宽表的计算逻辑往往很复杂,再加上宽表的数据输入是有大量依赖的,也就是说需要处理的数据量很大,在负载逻辑+大数据量的原因下,导致我们的宽表往往运行很慢,资源占用很多。


② 开发难度大/维护成本高


我们说了基于宽表做报表开发才是正确的姿势,但是宽表本身也是我们开发人员开发的,因为本身的逻辑很复杂设计的业务逻辑繁多,所以给我们的开发就带来了挑战,而且由于业务逻辑的变更我们也需要去维护着复杂的逻辑,并且如果涉及到数据回溯成本也非常大,所以宽表建设后一般是不做历史数据回溯的。

点赞(859) 打赏

评论列表 共有 0 条评论

暂无评论
立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部