作为数据部门，这是必然要经历的过程，但只是经历不能一直深陷其中，如果你所在的部门一直处于接巨量的取数需求的状态，说明部门的数据建设的方向可能是不对的，那就让我们来看看有哪些破解之法吧，当然这次分享的破解之法，也不是让这些需求排期，或者通过需求价值过滤需求等“行政”管理的方法，而是从技术与架构设计的角度给你一个全新的解决此类问题的视角。

主要内容包括以下几个部分：

1. 问题产生的原因

2. 数据建设的错误方向

3. 问题解决办法

4. OLAP 多维报表体系

01问题产生的原因

1. 思维方式

在平常的业务运营中，产品运营经理需要大量的数据辅助运营，正所谓“无数据不运营”，业务的运营者永远离不开数据，但初级的运营者在需要数据的时候，第一个想到的就是找工程师导数据，他们的思维方式就是：要数据找工程师，而不会自己想办法去解决，他们巴不得有一个数据秘书，当他们需要什么数据时，工程师可以随时取出来送到面前。当然工程师肯定也不想只做一个“取数机”，因为对他们来说，“取数机”没有任何成长。

2. 需求方式

当工程师无法作为数据秘书，让运营者提需求时，运营者就会开始提需求，但是需求永远是从问题出发的，也就是说，现在我只需要这些字段的数据或者报表，就只会提这些字段和指标的需求，等拿到数据看了之后，发现不能解决问题，还想要看更多字段才能解决，然后又只能继续提需求，进入死循环。

数据需求与功能需求是有非常大的区别，数据需求呈现量多且变化快的特点，如“急诊”，但功能需求则更像“挂号”，所以数据需求不能像功能需求一样去提去完成，这么多变化快的需求，非常需要一个产品经理来全局设计成数据产品再提，如果放任这样的想到什么字段就提什么字段的需求泛滥下去，那工程师会陷入永无止境的需求陷阱之中。

3. 工具缺失

当运营者大量取数需求不能满足时，就会想到自己解决，但平台能取数的地方可能只有报表，没有什么其它工具可以提供。现有报表零零星星也有一些，但每个报表都只是几个字段的组合，完全不能满足需求，不是少字段就是字段的组合没有，或者数据不全，一个报表只能解决当时的一个问题，新问题还要做新报表，而工程师排期总是很满，要很长时间才能满足需求，所以运营也只能先这样了。

如果报表不是做成多维的方式，只是按不同需求做不同维度和指标的报表，那么因为维度与指标的组合是无穷无尽的，所以报表也是无穷无尽的，很难一直满足千变万化的运营需求

02数据建设的错误方向

1. 完全面向需求开发

需求没有经过数据产品经理设计成通用的数据产品，工程师的开发方式为：需求要什么字段就做什么报表，一个需求一张 RPT 表；工程师到处打听到表就直接取用，逻辑都堆在 RPT 层；偶尔也做些 dws 中间表，但好像也只能用在这个需求，和直接一张 RPT 表没有什么区别。这种就是完全面向需求的开发，是一种错误的数据建设方向，此种方式会让数据工程师陷入无穷无尽的需求迭代的陷阱中。

2. 没有模型表概念

数据建设的精髓在于数据模型的创建（一般是维度建模），有部分新手或者部分数据分析师、后端工程师转行做数据建设较为容易走向这个错误的方向。有些人不了解建模知识，SQL 能实现就行，用 SQL 实现了很多没有模型概念的 DWD/DWS/DIM 表；有些人对建模有些了解，但理解不透彻，开发了一些中间表但通用性较差，没有系统性的全局建模。当这些所谓中间表（DWD/DWS/DIM 层）不好用的时候，迭代的效率就会降低，需要花费大量的人力用 SQL 打补丁以支撑需求的开发，把自己搞成了“SQLBOY”。

3. 没有 OLAP 建设概念

如果主题域、数据域抽象不好，业务过程理解不到位，表会拆得又多又散，很容易进入无穷迭代陷阱，比如在基于事件埋点的数据建设中，将一个事件做一张事实表，或者把几个事件做一张事实表都会有问题，因为事件太多了，所以表就会很多，表太多，使用起来就会很困难，浪费大量人力堆叠复杂 SQL，口径也难以统一和维护，如图一所示的普通方法：

图一 数据建设普通方法

4. “挖矿石”行为

对于业务系统中的表，只抽取这个需求的部分字段，等下一个需求来了之后再抽取其他需求的字段，对源系统的表形成“挖矿”行为。对于埋点事件的数据建设，只做现在要的埋点事件，需求没用到的事件不管，对埋点事件的数据形成“挖矿”行为，这种行为危害非常大，因为表面上看工程师会一直有事做，一直很忙，有人对此乐此不疲，用这种方式“混”了公司好几年的工资，但其实这些比较忙的工作本应该可以没有。

5. 垄断 SQL 行为

一般取数的工程师，或者分析师手上都会有一些固定的 SQL脚本，如果他一直靠这些 SQL “活”下去，不发给别人，需要用时就拿出来改改以完成业务的需求，一直这样“混”公司的工资，就是所谓的垄断 SQL 行为，这些行为会导致大量公共逻辑维护在个人电脑中，口径是人为控制的，当然工程师通过对业务的理解也可以自行写出这些 SQL 来打破垄断，但如果团队形成这种氛围，对团队非常不好，公共逻辑应该要沉淀在数据模型中以供大家使用，共同维护才是合理的方式。

03问题解决办法

图二 解决巨量取数需求的方法

行政手段中的两个方法在一定程度上可以缓解问题，需求优先级排期是非常常见且合理的需求消耗方法，但如果诉求过多时，会有需求不能及时满足或者一直不能满足，对于运营策略的开展影响很大，供需矛盾会加剧却无法解决。而需求价值过滤更不好，如果要卷运营的需求价值，只会让运营挖空心思想法子应对此事，更进一步加剧矛盾。

取数工具是建立在数据模型之上的，如果数据模型的表没有设计好，需要开发大量的取数模板，取数人理解成本也巨大，即使有好的取数工具也是枉然，投入大量人力也只会收效甚微。

知识赋能也是建立在数据模型之上的，如果没有在数据模型的基础上设计好 OLAP 体系，那么表就又多又散又不好用，取数人学习成本高，取数难度大，赋能只会暴露自己的数据建设缺陷。

所以，要解决这个问题需要创建一套基于维度建模的数据体系，然后在此基础上开发 OLAP 多维分析报表，当这个基础建设做好做扎实了，问题几乎就解决了。当然如果要做得更好，可以把取数工具，报表工具做得更加完善健全，最后通过知识赋能培训指导大家如何使用，这样一套做下来，一定能取得非常好的效果。

04OLAP 多维报表体系

如图三所示的多维分析报表能解决 80%+ 的数据获取问题，另外 20% 的需求则通过其他功能事实表解决，如留存事实表，归因事实表等。其中报表平台上的其他报表有 70% 可以直接从这个 OLAP 报表中配置衍生出来，不需要开发代码，不需要发版本，而且运营也可以实现配置，拥有自己的个人报表看板，不需要工程师参与。

对于工程师来说大量报表的底层表都是 OALP 表，只需要维护一张OLAP 表即可，可维护性更好。对于更多的使用者来说，比如会写 SQL 的分析师、运营经理、开发工程师可以开发基于 Clickhouse 的交互查询，直接自助查询 CK 里的表，可以秒级出数据，查数效率提升几百倍。

1. 报表使用方法

图三 OLAP 报表界面

如图三所示是在报表平台上提供的 OLAP 报表的获取数据的界面，功能介绍如下：

维度：包含这个主题的所有常用维度，包含退化后的维度，非常齐全，一般几百个字段，使用时将需要的字段拖到右边维度栏即可

指标：包含常用的基础指标，尽量不要把过多的维度打平在指标中，以免指标膨胀，一般 50 个以上的字段，使用时将需要的字段拖到右边指标栏即可

过滤：过滤栏有两个必选字段，也是分区字段、日期和数据标志，其中的数据标志在这里实际上是事件的分类，，将维度和指标拖到过滤栏即可。

2. 报表建设方法

OLAP 多维报表体系基于数据仓库而创建，如果数据仓库不作为，那 OLAP 多维报表体系也无从谈起，而在数据仓库建设过程中，最核心的工作除了架构设计之外就是维度建模，维度建模需要经验丰富的模型设计师或者数据架构师才能胜任，并不是简简单单的随便搞一些表结构就可以解决的，关于维度建模的数据知识较多，在下一次的分享文章中再细讲。