Categories
程式開發

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


一、引言

1.1 背景

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

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

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

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

1.2 整体思路

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

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

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

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

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

二、成本量化

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

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

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

2.1 资源单价

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

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

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

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

有以上变量,可以估算出单价:

  • 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 存储空间采集

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

占用存储资源: 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和内存消耗

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

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

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

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

2.2.3 分时计费

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

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

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

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

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

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

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

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

对于权重,要求:0.6*w1+0.3*w2+0.1*z=1w1>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天,成本变化趋势,可以看不同资源的成本趋势,未来有预期
  • 必要的榜单,负责的数据里,哪些高成本或者高耗时的,关注和优化有抓手
  • 降本信息,累计节省多少成本,剩余多少不必要的浪费,感受动力和压力
  • 价值信息,数据服务了多少业务,被多少人使用,体现价值

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

3.2 数据模型

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

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

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

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

四、成本优化

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

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

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

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

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

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

系统上我们做了很多配套服务,方便降本,也保障过程安全可控。同时对于哪些自主发起,系统监控不到的降本行为,也提供了“登记”功能,便于追踪和分析效果。

五、降本运营

降本的一切准备就绪,好像天衣无缝,但是我们发布了功能,反应平平啊,导演有点慌。不行,得想办法让机制运转起来,我们总结了四词真言:宣导、骚扰、反馈、奖惩。

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

首先是宣导,宣传成本意识,引导降本行动。

  • 在系统数据的详情页、个人工作台等地方,呈现成本相关信息,引起关注
  • 日常工作中,月会周会强调成本浪费问题
  • 发送成本账单给个人和TL等

其次是骚扰,主动出击推动降本。

  • 抓成本大户,给予足够的“关怀”
  • 对于高耗能数据,着重关注和优化
  • 建立迭代项目,以周为单位把相关人员聚集,集中开展优化

再次是反馈,平台与用户互动起来。

  • 注重降本过程体验,保证便利性,兼顾安全性
  • 行为可跟踪,体现降本成果,平台监控之外的降本动作,也可以登记
  • 推进过程中,探索和收集更多降本点,逐步完善覆盖面

最后是奖惩,鼓励减少浪费。

  • 必不可少的是榜单,“降本之星”和“降本潜力股”,分别作为红黑榜
  • 给每月降本top3的小伙伴发放有赞币
  • 公共场所秀成果,表扬和激励
  • 限制数据开发、任务发布(这条属于惩罚性措施,小伙伴们都比较积极,目前还没用到)

总之:降本意识靠 宣导 ,成本大户要 骚扰 ,既要用户多 反馈 ,也要 奖惩 做到位。

以上之外,平台本身也需要对降本做全方面的统计监控,我们有专门的看板辅助运营。

六、总结展望

6.1 总结

经过半年的努力,我们建立起完善的离线数据降本机制。

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

半年以来,参与到降本行动的小伙伴有40人,降本行为660次,累计节省约17%离线集群成本。更可喜的是,有超过20%的节省是自主自发完成的。

机制的有效性得以验证,并可以持续产生效益,后续我们会更关注运营,让整个过程更高效。

6.2 展望

在降本方面,我们迈出了第一步,未来有几个重点事情:

  • 解决已知问题,精细化运营,提升效率和效益
  • 扩大战线,跳出离线集群,扩大成本运营覆盖面
  • 将成本归属至业务,知道钱花在哪,“对外”算账
  • 建立数据价值评估体系,知道投入,也要知道“产出”,这也是一个充满未知和挑战的方向

本文转载自公众号有赞coder(ID:youzan_coder)。

原文链接

https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760987&idx=1&sn=79825b1062ae8e6584adaa4e87975eda&chksm=8c68767ebb1fff680248ff941004290060a2d39a0880bd370456a025d30042bea0363125dc63&scene=27#wechat_redirect