带你了解什么是数仓宽表

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

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

① 可以统一指标口径

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

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

② 可以提升开发效率

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

③ 可以提升数据质量

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

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

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

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

① 宽表到底多宽

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

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

② 宽表字段如何设计

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

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

· 深挖日常业务需求；

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

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

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

① 性能不高

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

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

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