一、引言
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 能将多个中间层表一次计算得出，降低数倍计算量。
系统上我们做了很多配套服务，方便降本，也保障过程安全可控。同时对于哪些自主发起，系统监控不到的降本行为，也提供了“登记”功能，便于追踪和分析效果。
五、降本运营
降本的一切准备就绪，好像天衣无缝，但是我们发布了功能，反应平平啊，导演有点慌。不行，得想办法让机制运转起来，我们总结了四词真言：宣导、骚扰、反馈、奖惩。
首先是宣导，宣传成本意识，引导降本行动。
在系统数据的详情页、个人工作台等地方，呈现成本相关信息，引起关注
日常工作中，月会周会强调成本浪费问题
发送成本账单给个人和TL等
其次是骚扰，主动出击推动降本。
抓成本大户，给予足够的“关怀”
对于高耗能数据，着重关注和优化
建立迭代项目，以周为单位把相关人员聚集，集中开展优化
再次是反馈，平台与用户互动起来。
注重降本过程体验，保证便利性，兼顾安全性
行为可跟踪，体现降本成果，平台监控之外的降本动作，也可以登记
推进过程中，探索和收集更多降本点，逐步完善覆盖面
最后是奖惩，鼓励减少浪费。
必不可少的是榜单，“降本之星”和“降本潜力股”，分别作为红黑榜
给每月降本top3的小伙伴发放有赞币
公共场所秀成果，表扬和激励
限制数据开发、任务发布（这条属于惩罚性措施，小伙伴们都比较积极，目前还没用到）
总之：降本意识靠 宣导 ，成本大户要 骚扰 ，既要用户多 反馈 ，也要 奖惩 做到位。
以上之外，平台本身也需要对降本做全方面的统计监控，我们有专门的看板辅助运营。
六、总结展望
6.1 总结
经过半年的努力，我们建立起完善的离线数据降本机制。
半年以来，参与到降本行动的小伙伴有 40 人，降本行为 660 次，累计节省约 17%离线集群成本。更可喜的是，有超过 20%的节省是自主自发完成的。
机制的有效性得以验证，并可以持续产生效益，后续我们会更关注运营，让整个过程更高效。
6.2 展望
在降本方面，我们迈出了第一步，未来有几个重点事情：
解决已知问题，精细化运营，提升效率和效益
扩大战线，跳出离线集群，扩大成本运营覆盖面
将成本归属至业务，知道钱花在哪，“对外”算账
建立数据价值评估体系，知道投入，也要知道“产出”，这也是一个充满未知和挑战的方向
本文转载自公众号有赞 coder（ID：youzan_coder）。
原文链接：
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论