产品视角下的数仓

作为一名数据产品经理，看过很多关于数仓建设的文章，这些文章大多是数据工程师所写，旨在通过通俗易懂的语言告诉大家为什么要建数仓，建数仓的过程中需要注意哪些事项；今天希望站在数据产品经理的视角来和大家聊一聊数仓建设过程中的几点事项，视角不同，可能提出的观点也有所偏差，欢迎大家提出建议，多多交流。

数据产品经理中有一群专门负责数仓建设的产品经理，他们活跃在各个业务中，收集着各类数据需求，最后沉淀成一张张数据表，这一过程中，数据产品经理的需求方主要有（下文中所有数据产品经理均指负责数仓建设方向的数据产品）：

数据分析师作为业务线最懂数据的人，常年干着各种脏活累活，比如跑数、搭报表，他们直接面向业务，承接着来自产品、运营、市场等各个方向的各种需求，当他们需要跑某份数据的时候，如果数据表混乱，会降低他们取数的效率，因此数据分析师会经常给数据产品经理提需求，希望建标准数仓表，统一数据标准。

这是一群听起来比较高大上的存在，和数据分析师相比，他们在商业分析上更加专业，他们的需求主要来源于领导层，然后围绕某方向进行专题分析，构建商业分析框架，从而实现全维度商业分析；商业分析师进行分析所依赖的就是数仓建设的一张张表，尤其是上层的ADS（应用数据层）表，如果这些表说明不准确，存在歧义，会影响他们分分析结果，因此商业分析师也是数据产品经理的需求方；

作为产品的缔造者，每一个业务产品经理都想知道自己的产品怎么样，用户反馈如何，很多时候他们会直接向数据分析师提需求，同时也有一部分勤奋好学的业务产品经理会自己去进行跑数，此时他们对于数仓的诉求更多的是想弄清楚他们想要的数据在哪张表里，表里的每个字段代表什么意思；

随着信息技术的发展，运营这个岗位越来越细分，有产品运营、活动运营、用户运营、社区运营等等，不论哪种运营，他们工作中很重要的一个事情就是查看数据，通过数据对一次活动进行全方位分析，来评估本次活动的收益和效果如何，以便于制定后续的决策。

以上，是数仓主要面向的人群，在这里没有写研发工程师，主要是因为研发工程师也是因为业务产品经理或运营提的需求来向数据侧提需，其实最后都是面向产品、运营。

由于ods层表命名没有统一规范，数据格式混乱，业务产品经理、运营、数据分析师想要跑一份数的时候，需要咨询很多人，才能知道某个数据存储在哪个表里；然后还要多次确认各个字段的含义才能最后得到自己想要的数据，整个过程比较繁琐，存在一定门槛；

通过建设标准数仓，我们会统一数据标准，对每个标准给出准确释义，帮助用户快速定位字段，并了解字段的真实含义；同时将各业务系统数据互联互通，打破信息壁垒，降低取数门槛。

在没有标准数仓的时候，不论是数据分析师还是商业分析师，想要获取一份数据都需要耗费大量的时间，通过编写大量的SQL获取目标数据；

通过建设标准数仓，根据商分、数分的诉求，将数据按照既定的主题进行汇总，通过汇总表的建设，大大降低数据分析师、商业分析师、业务产品经理、运营的取数时间，让他们有更多的精力去进行数据分析，发现数据背后的问题并制定相应的策略去调整。

在没有数仓时，数据分析师的报表主要依赖于原始ods表，这时如果业务发生调整，此时对应的ods表也会发生变更，此时数据分析师也需要去调整依赖这些表的报表，后续维护成本较高；

通过建设标准数仓，我们将一些公共处理逻辑在dwd层处理掉，数分直接使用dwd层，降低ods层变化对上层报表的影响；

现有订单表和登录表，登录表中存储了用户ID，字段名为user_id，订单表中也存储了用户ID，字段名为uid。此时两个表中包含的用户ID均是同一内容，但是使用了两种不同的字段名进行描述，字段出现了歧义便需要人工介入理解进行确认。

所以在建设初期，我们就可以根据业务的梳理，明确数据标准，统一数据格式，在后续的建模过程中统一引用该标准。

字段一般有属性、维度、度量三种，我们需要根据每种字段的特性进行专门的释义；

（1）属性：主体的某种属性，假设主体是用户，那么用户姓名就是用户的一种属性，此时需要对这一属性进行说明，比如用户姓名是怎么获取的，代表什么意思，如果某属性是通过数据挖掘得来的，需要说明挖掘的规则是什么；

（2）维度：这是表中最常见的一种字段，比如用户性别、城市等；这类字段经常被用于对比分析；这时我们需要对这一字段进行解释说明，告知用户性别是什么字段，如果可枚举，需要给出具体的枚举值，方便后续分析师使用，比如性别，需要给出枚举值男、女、未知；

（3）度量：度量字段在汇总表中常见，度量也等同于指标，主要用于明确业务统计口径和逻辑；此时在该字段的释义中需要说明计算逻辑和口径，便于用户查看时可以明确对应的计算规则；比如活跃用户数，需要特别说明活跃的口径是什么，是否有过滤掉哪些数据，这些都需要在这里明确说明；或者将该字段和数据指标进行联动，能够让用户查看该字段对应的指标定义。

需要把该表的上下游依赖通过清晰的方式呈现出来，便于使用者了解该表的上下游依赖，尤其是上游依赖，当数据没在既定时间就绪时，可以快速进行问题的追踪定位；

当用户查看某表时，我们直接提供数据预览的功能，便于用户快速查看表中的数据样例，好确认数据是否和自己想象的一致。

当我们做好这一切，接下来就是持续建设了，作为一名数据基建的产品经理，旨在通过我们的工作，推动业务数据化和数据业务化，让数据发挥最大的价值。