从量化到优化，详解有赞离线数据降本之路

作者：见风

部门：数据中台

‍

一、引言

1.1 背景

年初，一个月黑风高的夜晚，数据中台的TL独自坐在工位上，左手托着下巴，右手搭着键盘，指尖缓动，眉头紧锁。面对下边这张图，本可以下班的他，迟迟不愿离开。

过去的半年，有赞的业务高速增长，可喜可贺。但是数据中台的计算资源消耗也水涨船高，半年翻一番，甚至超过业务涨幅。再这么下去，部门恐怕要凉凉，想到这，不禁打了个寒颤。

数据是我们的重要资产，随着业务的发展以及历史的积累，所需存储和计算不断增长在所难免。但是“大”数据意味着大成本，如何有效控制成本合理增长？这个问题，值得深思。

1.2 整体思路

很直接的，找到无用的数据进行下线处理，找到可优化的任务进行改造……这些点都可以省资源。但是仅仅这样是不够的，因为做这些事情本身也需要成本，很琐碎也很费事，还需要各种推动讨人嫌。

我们需要是一种长效的，自运转的降本机制，让小伙伴们感知到成本，感受到浪费，自发地关注成本，节约成本。那么就需要做到这几点：

成本可量化，细到每个数据的成本以及它的构成
浪费可感知，能发现并提示出有多少浪费存在
降本便捷性，知道了浪费，还要知道如何优化，高效地降本
过程可跟踪，做的降本动作，需要被记录和跟踪，反应成本变化
机制运营，如何设计奖惩措施，激发自主降本，保持良性循环

于是，摆在眼前的几座大山，需要一一翻跃：怎么量化数据成本；怎么算清帐有没有浪费或者优化点；怎么降本和支持降本；怎么跟踪降本过程；怎么持续运营产生效益。

二、成本量化

合理地量化出直观的数据成本，是第一步。因此，首先要聊到我们的成本模型。

数据的成本在于硬件资源消耗（本文不考虑人力），存储需要磁盘，计算需要cpu和内存等。基于此，我们的核心做法其实很简单：数据成本=资源单价*消耗资源，下面我们来一一解释。

2.1 资源单价

根据实际情况，判断我们硬件的核心资源：cpu、内存、磁盘，需要估算各自的单价。

以猪价类比，影响因素有很多，关键几个是：

全社会投入养猪的成本就是总成本。那么我们用于数据产出的所有机器的总投入就是我们的总成本。记为total_cost。
猪有多少就是总资源量（准确得说，应该是总共有多少猪蹄、猪排、猪头、猪肉等）。对于机器也是，总的cpu（total_cpu）、内存（total_memory）、磁盘大小（total_disk）是多少。
不同部位稀缺性不一样，根据整猪单价按不同比例分配，各个部位的总价。机器资源，是cpu贵还是内存贵（根据供需关系），每类资源的成本占比是多少。分别记为：cpu_ratio、memory_ratio、disk_ratio。
出栏的猪量占比是一个水位，过多过少都会影响市场价格，同一时间应该是一个相对稳定的比例。用于计算的机器资源负载应该有个合理比例，过高需要扩容，过低考虑缩容。换句话说，机器资源用不到100%，空闲资源也是成本，把合理的资源水位记为load_factor。

有以上变量，可以估算出单价：

cpu单价，cpu_price= total_cost*cpu_ratio/(total_cpu*load_factor)
内存单价，memory_price= total_cost*memory_ratio/(total_memory*load_factor)
磁盘单价，disk_price= total_cost*disk_ratio/(total_disk*load_factor)

2.2 消耗资源

数据消耗的资源分为三类：

存储使用的磁盘，这里要注意的是，数据的备份也会占用空间。如存在hdfs集群上的数据，一般是3备份。
计算使用的cpu、内存等，通常跟占用时长也有关，这个可以想办法采集到。
时间，这里特指产出数据对应的任务的运行时段。由于不同时段，集群的资源紧缺程度不一样，从供需角度，应该考虑分时计费。

2.2.1 存储空间采集

这个比较简单，定时采集即可，这里就不赘述了。

占用存储资源：disk= data_size*replicator，其中data_size是数据名义大小，replicator是备份数。

2.2.2 资源消耗采集

首先，我们有yarn资源利用率监控，可以采集到分钟级的集群负载情况。但是这个是整体的，如何才能精确到每个计算任务的消耗呢？有两个关键的服务：

spark thrift server（以下简称sts），用于采集spark sql类任务的cpu和内存消耗，记为cpu_seconds（cpu占用秒数）和memory_seconds（内存占用秒数）
spark monitor（以下简称smnt，基于yarn的资源采集服务），用于采集非spark sql类任务的cpu和内存消耗

其中sts采集的结果是实际需要消耗的，但是yarn在分配资源时，会有一定的损耗（可以理解为资源分配、回收环节，占用了资源，但是不做实际计算）。这个系数记为loss_factor，它是一个经验值，可以通过大量任务测试对比得出。

为了统一公式，对于smnt的采集结果，loss_factor=0。这样，就可以算出每个任务消耗的资源：

cpu= cpu_seconds*(1 loss_factor)
memory= memory_seconds*(1 loss_factor)

2.2.3 分时计费

集群的负载随时间变化，看监控，可以发现夜间负载很高，白天负载偏低。同样的资源消耗，在白天跑和在夜间跑，如果计费相同，有违“市场规律”。

因此，为了调节供需关系，同时也鼓励不重要数据在空闲时段计算，我们考虑分时计费。

上图是我们集群某天cpu实际负载情况，可以发现三个时段：

0-8 点是黄金时段，业务数据赶着在上班前跑出，任务繁重，资源负载接近极限
8-13 点是白银时段，负载没那么高，相对次要点的数据和数据重刷任务会集中在这个时段
13-24 点是青铜时段，集群相对空闲

我们有必要对以上三个时段设定不同权重，来“调节市场”。那么，权重怎么设计呢？关键原则是：设定权重后，保持资源总量合理。

我们首先统计出过去一段时间不同时段需要消耗的计算资源总量，可以求出一个比例，如下表：

对于权重，要求：0.6*w1 0.3*w2 0.1*z=1且 w1>w2>w3。为了更好的效果，w1和w2、w2与w3之间，要拉开差距。

这样，就可以大概定一组权重（我们目前设定的是w1=1.2，w2=0.8，w3=0.4）。值得注意的是，对于可能跨越多个时段的任务，也要按比例加权求和。

定义好这三个权重，假设三个时段消耗的cpu_seconds分别是cs1、cs2、cs3，那么加权系数：

cpu_weight= (cs1*w1 cs2*w2 cs3*w3)/cpu_seconds，同理可以算出memory_weight。

2.3 数据成本

评估好资源单价，采集到资源消耗以及运行时段，就可以评估出一个较为合理的数据成本了。

cpu_cost= cpu_price*(cpu*cpu_weight)
memory_cost= memory_price*(memory*memory_weight)
disk_cost= disk_price*disk

当然，实际计算成本，还有许多细节需要考虑，比如：

数据对应的任务，可能同时产出多个数据，那成本怎么分摊（简化模型，等比分摊）
数据的成本归属给谁，谁来负责关注和优化（确保每个数据有唯一的owner）

这里不再展开。

三、成本账单

数据有了成本，总不能让它自我优化吧，哈哈，得有人。接下来是，如何让大家感知到成本情况呢？成本账单是必要的。

3.1 账单内容

目前我们提供的账单有全局、部门、个人粒度的。主要内容包含：

成本总览，负责数据的总成本、变化及其排名，心中有数
成本趋势，过去n天，成本变化趋势，可以看不同资源的成本趋势，未来有预期
必要的榜单，负责的数据里，哪些高成本或者高耗时的，关注和优化有抓手
降本信息，累计节省多少成本，剩余多少不必要的浪费，感受动力和压力
价值信息，数据服务了多少业务，被多少人使用，体现价值

3.2 数据模型

实现数据成本量化和账单，本身也需要数据开发。以数据为基础，为了实现多粒度账单，需要特别关注分层和复用。数据分层偏向数仓模型设计，此处不展开，着重讲一下复用。

上面这个图，表达了资源成本的核算过程。

摊：一个计算任务只属于一个人，可能产出多张表，此时会将平均成本分摊到表。
合：粗粒度的成本，通过细粒度聚合而来，不做重复计算。比如，单表有唯一的owner，可以汇总到人；另外，有专门的业务域管理，表和业务域是多对多的关系。
联：由于很多数据无法直接关联到表或者人，在算粗粒度的时候，需要额外关联到对应实体。比如目前有许多临时查询任务，消耗资源，但是并非表的成本，但是应该算到人头上。

四、成本优化

成本可以量化，又有了账单，台子搭好了，接下来要邀请大伙儿来唱戏了。等等，唱什么戏？还得有剧本。

我的成本高企，怎么优化呢？经过我们深入调研，总结出降本“六脉神剑”（其实不止六种）。

一脉：下线。对于无用的数据，直接下线，最直截了当。那么如何判定“无用”呢，这依赖于我们强大的“血缘”追踪能力。系统会自动采集数据的链路流转以及使用情况，结合一定规则，判定疑似无用的数据，并区分中高低档。当然，最终是否可下线，还需要人确认。因此，这点可以总结为人机结合。
二脉：延迟启动。前面我们讲过分时计费，那么自然地想到“错峰执行”，利用闲暇时段执行不重要的任务，还能获得“折扣”。系统会挑出在黄金时段运行的非重要任务，推荐延迟启动（这个可以分阶段做）。
三脉：高频转低频。很典型的例子，小时级任务一天运行24次，是否有必要，能否降低频率，是不是天级就够了。有些任务甚至不需要每天跑，隔三差五就行。实际推进过程中，我们发现了不少这样的例子。
四脉：替换。比如，有许多数据由于历史原因，已经不再维护，可以用另一个替换（成本更低）；有多个功能相似的任务，可以合为一个。这类优化不仅可以降本，还能节省运维、答疑成本。
五脉：任务调优。对于hive任务，是否有任务倾斜？使用的数据量能否减少？语法使用能否优化？等等，这类优化需要具体问题具体分析。
六脉：小文件合并。目前我们的任务支持spark和hive引擎执行，spark不能自动进行文件合并，有些任务并行度高，会产生过多小文件。对于这类case，hive有文件合并策略，能大幅减少文件数，提高task的利用率，节省资源。

除了以上优化点，其实还有很多，这里也不展开了。比如我们强大的数仓团队，使用hive cube能将多个中间层表一次计算得出，降低数倍计算量。