我做数据需求的前世今生（看不懂标题就进来喵喵）

此文篇幅较长，估计要十分钟空闲时间。一个月没有更新文章了，主要是做毕业设计和赶公司新项目，文章其实一个月前就写好了初稿，现在拿出来改改就发了，封面图片来自公司附近大厦。...

实习几个月，做了几次数据分析需求。小白一个，很多东西都不懂，在数据需求沟通上走了不少坑，借此机会总结下。

指标和维度的区别

先说这两个的区别，便于了解后面的内容。我们在后台采集的数据包括两个方面，一是指标，二是维度，指标就是我们要统计对象，比如交易金额，交易笔数等（这里针对支付行业来举例）。维度是指我们要筛选出指标的条件，比如基于单位时间维度（时，日，月，季，年等）的交易金额，还有就是基于支付状态而筛选出的交易金额，正是因为如此，我们才可以整合出基于多维度的指标，比如在某段时间内成功支付的交易金额，从而对业务有更加精细化的统计和监控。

支付行业的数据统计指标和维度有如下（来源于自己工作和网络，仅供参考）

数据的统计过程

我自己概括统计过程为：数据采集到数据仓库-基于需求清洗过滤-前台筛选显示。

数据采集到数据仓库

什么样的数据才会采集取决于业务需求。程序通过对前端界面的一些用户交互行为和用户输入产生的数据进行采集。而数据仓库可以简单地理解为数据集市，里面会有各种业务需要的原始数据。

基于需求的清洗过滤

可以理解为从集市里寻找符合本需求的数据原材料（就像逛街买菜一样），会涉及到多个维度的数据清洗过滤。这就要引入数据立方体的概念，以下内容（斜体部分出自http://webdataanalysis.net/web-data-warehouse/features-of-olap/，版权属于原作者）

关于数据立方体（DataCube），这里必须注意的是数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维，但多维模型不仅限于三维模型，可以组合更多的维度，但一方面是出于更方便地解释和描述，同时也是给思维成像和想象的空间；另一方面是为了与传统关系型数据库的二维表区别开来，于是就有了数据立方体的叫法。所以本文中也是引用立方体，也就是把多维模型以三维的方式为代表进行展现和描述，其实上Google图片搜索“OLAP”会有一大堆的数据立方体图片，这里我自己画了一个：

多维分析操作包括：钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）以及旋转（Pivot），下面还是以上面的数据立方体为例来逐一解释下：



钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，如上图；当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。

 

上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据，如上图。

 

切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。

 

切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。

 

旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。前台筛选显示

业务人员选择满足其需求的维度和指标，作为数据输入信息传递给后台清洗过滤，比如我在统计后台系统中选择基于时间（日）和用户类型（新老用户）两个维度的支付成功金额，如下图所示。

我是如何接手并开展数据统计需求

第一:向数据统计需求方沟通，确定数据统计的目的，比如为了看一季度各条产品线的盈利情况，那么我们需要统计的指标有哪些，维度有哪些，指标和维度之间的关联，指标的统计周期（时间范围）以及数据的展示方式（表格，条形图，折线图，饼图等）

第二:确定需求所涉及的字段定义和数据仓库的底层表是否采集到该字段

统计周期比较容易弄清，但是有人会问字段定义和底层表是否采集到这两个如何确定的。

下面是个人做法，去公司主要的业务（交易管理，报表统计）平台，将每个平台的查询页面出现的字段以及对应的字段选项用Excel或Xmind列出来，出现的字段数据仓库基本都会采集到相关数据，至于字段定义，如果公司没有梳理出后台字段定义说明书，那么字段选项就会有助于你去了解或反推其定义。用微信公众号的后台字段举例，针对“全部来源”这个字段，可能刚开始看的时候会很陌生，但是打开看到下拉框你就会有所了解啦。



第三，制定好数据统计样例（可以理解为统计原型，一般用Excel做），将需求方的需求视觉化，发给需求方咨询是否可以满足。如果可以满足的话，那就给数据开发同事，这样就会减少一大部分和技术之间的沟通障碍（直接放图，可以少说好多废话）。下面是我在做两次相关需求用到的样例表



第四，进入开发阶段，一来要跟进开发进度，帮他协调资源，以尽快完成。二来要偶尔询问需求方C（C仅作为举例而已），以确认需求不会变更。针对这两点自己都深有体会（遇过坑）。

关于第一点，需求方C给我诉求，我整理成需求发给数据同事A开发处理，而A在开发过程中，由于有个字段的底层采集表需要数据库同事B协调。然而A仅仅邮件下B让其帮忙，并没有知会，这样B无法知道该需求背后的业务紧急和重要程度（见下图3、4步）。所以B就延后做，因此整个需求的延后效应传递到我和C那里。



其实我应该做的是询问A是否有需要帮忙的地方，而不是提交需求给他后就撒手不管。三角关系这么复杂，可能看图比较好点。

关于第二点，曾经试过将样例表输出给需求方C，得到其允可，最后开发输出结果（按照样例表）后C不满意，因为不是他想要的，只能替C挡开发的枪，毕竟需求评审通过后还是要做的。

在这里虽说C也会有责任，但是自己觉得最大的沟通失误还是在自己身上。一来没有做好需求开发中的需求方跟进沟通，二来对数据需求没有做可拓展性思考。

举例说明:C要统计风控各渠道方的总比对成功数，而其中渠道方D有D1，D2和D3三个规则，而我在输出样例表时如下图：

实际上满足C需求的统计样例是：



得到各规则的比对成功数后相加起来就是渠道方D的总比对成功数了，显然后者的可拓展性更好。

总结下文章的要点

一、数据包括两个方面，一是指标，二是维度，指标就是我们要统计对象，维度是指我们要筛选出指标的条件

二、数据统计过程：数据采集到数据仓库-基于需求清洗过滤-前台筛选-后台统计-前台显示

三、 如何接手并开展数据统计需求

3.1    :向数据统计需求方沟通，确定数据统计的目的

3.2    确定需求所涉及的字段定义和数据仓库的底层表是否采集到该字段

3.3    制定好数据统计样例

3.4    进入开发阶段，一来要跟进开发进度，协调资源。二来询问需求方C，以确认需求不会变更

以上是自己做过两次数据统计需求以及后台报表平台优化统计需求后的一点点感受，就当记下来流水账，以后自己也能回顾和吸取教训。

文章彩蛋

彩蛋一

推荐数据分析科普博客：http://webdataanalysis.net/，文章中的斜体内容来源此博客。点击阅读原文即可。

彩蛋二

部分图中的图标来源我最喜欢的图标网站（支持中文啊）：http://www.easyicon.net/

利益说明：因涉及公司机密，所以上面的图都只是做举例说明用途，仅供参考，别无他意。

    关注 PM训练营