老板说数据成本太多了，有哪些“省钱”的思路？

? 目录

• 常见的数据成本的陷阱？
• 避免成本陷阱的一些建议

当数据中台运行了一段时间之后，我们得考虑一下精细化运营了，我们应该也是清楚领导不会给你无限的扩资源，即便当前给你扩了资源，也是需要你合理的使用这些资源，而不是随便用，然后又等到资源不够用的那天到来，苦逼地抱怨计算资源不够。

? 常见的数据成本的陷阱？

其实在我们平时的数据开发过程中，会存在着许多数据成本的陷阱，有些很明显可以察觉，但可能由于规范不够导致少数人没有合理执行，也有些不太明显，那么掉到陷阱里的人就更多了。只有我们了解了这些陷阱，做到有所防范，才不会出现成本爆炸的情况。

陷阱1：上线容易下线困难

有的时候，我们会很随意地就上线一张宽表，而这张表可能只是满足当时的需求而开发的，但是随着时间的推移，可能有些表就没人用了，但是调度任务还是会在跑，同样会消耗计算资源以及存储空间，而我们不敢说直接就下线了这个任务，指不定说哪天某个任务又需要用到，这就十分尴尬了。

所以，作为我们中台开发的表，肯定要慎重，尽量需要做好相关的使用监控以及优化我们的模型设计，绝不轻易就上线表。

陷阱2：低价值的数据应用却消耗着大量的资源

这个的意思就是说，某张宽表的生成需要消耗大量的计算资源，一般就是说这张宽表有好多列，然后加工链路也很长，但是呢，下游使用的对象却很少，极大的投入产出不匹配。这种现场虽然并不多见，但追查下来还是可能会发现的，如果发现了这类的情况，可以和业务部门进行沟通，看下是否有其他的优化方案，对数据应用的提供方式进行改造。

陷阱3：烟囱式开发

这个情况不用怎么解释大家应该都懂，那就是我们会对一张很大的宽表进行反复加工，只是为了满足当下的需求，但是我们回过头来看其实有蛮多共性的指标的，完全说可以做一张公共的UDL宽表来提供服务，只要被复用一次，就能节约这张宽表的生成成本一次，达到了省钱的效果。

陷阱4：数据倾斜

这个属于数据开发中的SQL优化问题了，不同人写的SQL代码有很大的区别，可能经验不太足够的人会容易写出一些数据倾斜的SQL代码，从而导致大量消耗高峰期的计算资源。

关于“数据倾斜”，之前我也写过一篇文章介绍，大家可以翻一翻来看看。《一文带你搞清楚什么是“数据倾斜”》

陷阱5：数据落地未设置生命周期

对于GDL、UDL或者DM层的数据，一般来说考虑到成本问题都不会进行全量的历史数据保存，通常来说可能保留一定时间内的数据（比如7天、30天）。但是如果没有设置，对于小表还好，如果是大表的话，存储的空间还是蛮大的。

陷阱6：调度时间分配不合理

其实我们把生成集群的计算资源拉出来看，会存在一些调度的高峰期和低谷期，而高峰期往往就是计算资源消耗的成本所在（因为集群计算资源的配置取决于高峰的使用量）。所以如果我们可以错峰使用我们的集群资源，就可以达到很好的利用率了。

✅ 避免成本陷阱的一些建议

针对以上的情况，郭忆老师也给出了自己的一些经验，主要是遵循以下的4个步骤来进行。

Step1：全局资产盘点

我们需要对当前所有的数据进行一次全面的盘点，基于元数据的血缘关系，从而来建立全局的数据资产视图。

当我们建立完成了以上的全局数据资产视图之后，我们就需要对末端数据的成本和价值进行衡量了（也就是图中的 Table A、Table G）。这里我就有疑问为什么不能把中间表也考虑进来，给出的解释就是说中间表对于价值的计算比较困难，所以一般都是从末端数据开始搞，搞完末端数据，“中间表”也就可能会变成“末端数据”了。

1）数据成本的计算方式。

针对上面的那张图，《报表：财务分析》涉及的上游链路中有3个任务（task a、task b和task c）以及6张表（Table A-F），那么它的成本就是：3个任务加工消耗的计算资源成本 + 6张表消耗的存储资源成本。

另外，需要注意的是如果某张表被多个应用使用的话，那么这个表的存储资源成本和产出成本需要被分摊。

2）数据价值的计算方式。

数据价值的计算，主要就是上面思维导图所示的，需要注意的是人数的计算上需要考虑权重，比如boss的权重可能会大很多。然后就是直接被业务系统使用的，就是这个系统的使用覆盖率和业务价值产出，比如通过我们的这个数据接口可以达到的效果，占比之类的。

Step2：问题发现

既然我们有了量化问题的手段，我们就需要去发现问题了。一开始我们需要重点关注的问题可以大致分成3类：

1）持续产生成本但末端没人使用的数据（没人使用：指的是近30天内没有访问）

2）数据应用的价值很低，但是产生的成本却很高

3）高峰时期的任务

前2点很好理解了，结合上一节里提到的陷阱1-2就可以明白。而第3点我理解就是模型设计的问题，包括维度、指标设计、SQL优化开发、调度时间重配置等。

Step3：治理优化

治理优化的话，通俗来说就是找到需要下线的表，进行下线操作，那么需要的步骤如下所示：

不过上面的图我觉得还是有点不够，毕竟只是简单停止了产出任务的调度，也不见得数据应用使用者会“察觉”的到，可能有些不太重要的应用，并没有设置一些监控的指标，或者说可能有些任务确实只是一个月看一次之类的（虽然说这类应用确实应该下线）。所以，应该加多一点就是通过所有任务的使用方我们的下线计划。

Step4：效果评估

那么做了这么多的事情，需要量化成果了，一般来说可以从下面几个维度来考虑：

• 下线了多少任务和数据表
• 这些任务每天消耗了多少资源
• 这些数据表占用了多少存储空间

任务 A 运行时长 3 个小时，在运行过程中，共消耗 5384503 cpu*s，37007892 GB *s, 假设我们 1 个 CU （1 cpu， 4g memeory）一年是 1300 元成本，折合每天为 3.5 元（计算公式为 1300/365）。 也就是，高峰时间段为 8 个小时，那折合每秒的费用为 0.00012153, 那该任务的费用为 max{5384503*0.00012153, 37007892/4 * 0.00012153} = max{654, 1124} = 1124 。那下线这个任务后，就节省 1124 元，再加上表 A 占用的存储空间大小乘以每 GB 的成本，就可以得出数据表 A 下线节省的费用。

这里有同学会问：怎么获取到高峰时期一个任务使用了多少核cpu，多少G内存资源的数据？

这可以通过yarn 上面的任务日志中都有相关的信息，通过解析日志可以获取的到任务每个application消耗的资源。

? 总结

其实总的来说，对于这些成本优化的问题，有3点很重要的工具是需要的：血缘链路关系解析、使用热度分析和资源消耗统计。前者的话可以解决很多问题，不止是我们现在的问题，对于我们定位到错误任务也很容易，是需要重点关注的。而第二点对于我们定位到低价值以及无用的数据表和任务有很大的辅助作用，第三点则是可能辅助我们分析重点关注的对象以及计算优化成果。

所以在开展以上的成本优化前，得先确定相关工具的开发，满足辅助作用，不然的话其实也很难进行下去的。