数仓公共层，还有存在的必要吗？

自我接触数仓以来，数仓建模就是最为核心的工作，而数仓建模的主要目的是建立公共层，公共层主要起到两个作用，第一个是屏蔽底层的变动对上层应用的影响，第二个作用是通过复用沉淀的公共层来提升应用支撑的效率，但在长期的数仓公共层运营实践中中，我发现公共层的表现不总是沿着我们设想的轨迹演进。

 

1、无论数仓公共层开始的时候设计的多么完美，数仓公共层最后的使用比例2/8现象明显，大量的公共层模型是没人使用的，项目投入的80%都被浪费了。

 

2、当前的数仓公共层和5年前的数仓公共层差别不是很大，意味着新业务没必要用新的公共层去支撑，间接否认了公共层存在的必然性。

 

3、数据仓库公共层经常会由于积重难返而被推道重来，比如5年一次，对于公共层的投资似乎并不是很划算的生意。

 

我们当然不能否认公共层的价值，但其价值也许的确被高估了，设想一种场景，假如不预先做数仓公共层的建模，我们对业务的支持真的会变得很糟糕吗？恰好，我也有实践。

 

1、在遥远的报表时代，为了实现报表会做大量的临时汇总表，那个时候没怎么考虑复用，但似乎也没什么大问题。在报表时代过度到数据仓库时代的时候，其实并没有什么强烈的业务驱动要做什么公共层，但由于那个时候数仓关系建模已经兴起，大家都觉得做公共层成了理所当然的事情，毕竟复用是很先进的理念，但其实大多就是把临时汇总表搞成了公共层而已。

 

2、在大数据时代，我们在hadoop上开出了很多租户，虽然主租户做了大量公共层模型，但各个部门的租户基本上是随着应用的需要建立起的一堆中间表和宽表，复用主租户的公共模型并不是很多，但大多却活得很好，我们经常指责租户没用复用意识，导致大量的计算资源浪费，但要说浪费，我们80%的公共模型没人使用何尝不是更大的浪费呢？事实上，各个部门租户的资源是有限的，但各部门还是靠自己的运营保证了基本的生产需要。

 

数仓公共层的理想很好，但大多数据团队实际并不具备什么公共层的运营能力，为什么呢？

 

1、大多公司的业务团队比较强势，数据团队很难坚持一些数据架构的原则

 

2、业务部门提需求没有什么成本，大量低质量的需求把数据团队有限的资源耗光了，数据团队很难有时间去考虑公共层的优化

 

3、公共层的价值体现很慢，大家更多的精力还是投在了应用建模上

 

4、公共层对于业务、技术、数据的综合要求很高，数据团队普遍缺乏此类人才

 

与此同时，数据湖、湖仓一体等新技术的出现都对数仓公共层的建设必要性提出挑战，技术的趋势似乎都在朝着数仓公共层的反面进行，即强调原始数据分析的所见即所得，强调对不可知数据和不可知业务的探索分析。

 

数据仓库通常预先定义 schema，外部数据需要按照标准写入（比如清洗转化等）并对外提供数据服务查询接口，数仓公共层进一步延伸了这种设计思想，通过事先的生成和约束来确保良好的数据性能，所谓先建模再使用，强调的是未来的成长性。

 

数据湖则是反过来的，外部数据几乎不受限制的进入数据湖，只有在需要使用的时候才明确 schema来建模，数据湖也不存在所谓的公共层，应用需要就即席建模，强调的是灵活性。

 

10年前数据仓库是主流，因为业务需求主要就是循规蹈矩、按部就班的报表和BI，这种计划性很强的应用场景非常适合数据仓库的技术特点，数仓公共层更是让报表和BI如虎添翼。

 

灵活性和成长性，对于处于不同时期的企业来说，重要性也是不同的，数仓公共层对于业务成熟的企业来讲比较适用，对于初创企业或初创数据团队来讲必要性就很低了，想想自己也是这么过来的，只不过那个时候公司的数据量不是很大，数据结构简单，ORACLE就是那个时候的数据湖。

 

但现在是数字化时代，数据的应用场景逐渐向复杂数据（比如非结构化数据）的快速探索、分析、推荐和预测等方向延伸，这些场景不确定性很强，数据的维度很多，导致公共层很难提前准备，数据湖显然更适应了这些数据和应用的特点。

 

但我们也知道，数仓公共层必然还是需要的，因为稳定的报表不会消失，问题只在于度的问题，数仓公共层不要过度设计，也许30%的公共层比例是合理的，未来也许更低，当你家的公共层模型比例超过60%的时候，就要想想是否出现了问题。

 

那这个度在哪里呢？

 

至少不能简单的使用公共层模型覆盖度、复用度这种技术指标来指导公共层模型的建设，因为复用度高并不意味着全局价值最大，甚至较大影响业务的拓展，这里给出公共层模型建设的三个策略：

 

第一种是技术驱动，就是某些数据量特别大的表如果各个应用单独汇总会严重影响整个系统稳定的，这些表需通过汇总等手段构成公共层然后统一对外提供。

 

第二种是管理驱动，就是由于数据一致性等经营管理需要必需确保数据的源头唯一的，这个时候公共层的建设也很有必要。

 

第三种是业务驱动，就是那些被存量业务驯化出来的高复用公共模型（比如项目建设时期总结提炼出来的宽表），或者已经被业务多次投诉并确认为可以通过建立或优化公共层模型来解决的。

 

面对新的业务场景，当没法确认到底是优化公共层模型支撑好还是另起炉灶好的时候，可以先让子弹飞一会儿，直到以上三种情况的出现为止。当然如果你的团队有很厉害的架构师并且愿意做公共层模型的工作，那的确可以随心所欲，因为有足够的能力来进行全局最优的判断，但大多时候，我们并不具备这种条件。

 

我还有一种大胆的设想，就是除了严肃的报表，所有的应用支撑都不要搞什么公共层模型复用，自己管自己的就可以了，也许也可以活得很好。、

作者：傅一平

来源：与数据同行