‍

点击关注“有赞coder”

获取更多技术干货哦～

一、引言

1.1 背景

1.2 整体思路

1. 成本可量化，细到每个数据的成本以及它的构成

2. 浪费可感知，能发现并提示出有多少浪费存在

3. 降本便捷性，知道了浪费，还要知道如何优化，高效地降本

4. 过程可跟踪，做的降本动作，需要被记录和跟踪，反应成本变化

5. 机制运营，如何设计奖惩措施，激发自主降本，保持良性循环

二、成本量化

2.1 资源单价

• 全社会投入养猪的成本就是总成本。那么我们用于数据产出的所有机器的总投入就是我们的总成本。记为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 消耗资源

1. 存储使用的磁盘，这里要注意的是，数据的备份也会占用空间。如存在hdfs集群上的数据，一般是3备份。

2. 计算使用的cpu、内存等，通常跟占用时长也有关，这个可以想办法采集到。

3. 时间，这里特指产出数据对应的任务的运行时段。由于不同时段，集群的资源紧缺程度不一样，从供需角度，应该考虑分时计费。

2.2.1 存储空间采集

2.2.2 资源消耗采集

• spark thrift server（以下简称sts），用于采集spark sql类任务的cpu和内存消耗，记为cpu_seconds（cpu占用秒数）和memory_seconds（内存占用秒数）

• spark monitor（以下简称smnt，基于yarn的资源采集服务），用于采集非spark sql类任务的cpu和内存消耗

• cpu= cpu_seconds*(1+loss_factor)

• memory= memory_seconds*(1+loss_factor)

2.2.3 分时计费

• 0-8 点是黄金时段，业务数据赶着在上班前跑出，任务繁重，资源负载接近极限

• 8-13 点是白银时段，负载没那么高，相对次要点的数据和数据重刷任务会集中在这个时段

• 13-24 点是青铜时段，集群相对空闲

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 展望

• 解决已知问题，精细化运营，提升效率和效益

• 扩大战线，跳出离线集群，扩大成本运营覆盖面

• 将成本归属至业务，知道钱花在哪，“对外”算账

• 建立数据价值评估体系，知道投入，也要知道“产出”，这也是一个充满未知和挑战的方向

1. Flink 滑动窗口优化
2. 有赞埋点实践
3. 有赞埋点质量保障
4. 基于时间加权的用户购买类目意愿计算
   
5. 有赞推荐系统关键技术
   
6. 有赞数据中台建设实践
   
7. 数据资产，赞之治理
   
8. SparkSQL在有赞大数据的实践（二）
9. HBase Bulkload 实践探讨