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

2020 年 7 月 17 日

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

一、引言


1.1 背景


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



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


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


1.2 整体思路


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


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


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

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

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

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

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



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


二、成本量化


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



数据的成本在于硬件资源消耗(本文不考虑人力),存储需要磁盘,计算需要 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 消耗资源


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


  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和内存消耗



其中 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=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天,成本变化趋势,可以看不同资源的成本趋势,未来有预期

  • 必要的榜单,负责的数据里,哪些高成本或者高耗时的,关注和优化有抓手

  • 降本信息,累计节省多少成本,剩余多少不必要的浪费,感受动力和压力

  • 价值信息,数据服务了多少业务,被多少人使用,体现价值



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)。


原文链接


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


2020 年 7 月 17 日 10:07962

评论

发布
暂无评论
发现更多内容

Week3 代码重构

贺志鹏

极客大学架构师训练营

第七周 性能优化 作业二

应鹏

极客大学架构师训练营

架构师训练营第 1 期 -Week7 - 性能优化一学习总结

鲁小鲁

极客大学架构师训练营

装饰器模式

猴子胖胖

golang 设计模式

架构师训练营第一期 - 第七周学习总结

卖猪肉的大叔

极客大学架构师训练营

第七周作业

Geek_ac4080

架构师训练营 1 期 - 第七周总结(vaik)

行之

极客大学架构师训练营

第七周 性能优化 作业一

应鹏

极客大学架构师训练营

week3- 请在草稿纸上手写一个单例模式的实现代码,拍照提交作业

科技与产业革命的历史性交汇期,光华工程科技奖名单上的AI排面

脑极体

架构师训练营week07作业

IT老兵重开始

第3周作业

伊灵

第七周总结

Geek_ac4080

【架构师训练营第 1 期 07 周】 作业

Bear在挨踢

极客大学架构师训练营

Week_07 作业

golangboy

极客大学架构师训练营

架构师训练营第 1 期 -Week7 - 课后练习

鲁小鲁

极客大学架构师训练营

第 7 周 作业

Pyr0man1ac

Week 7 學習總結

--------世界中心---------

架构师训练营第七周学习笔记

一马行千里

学习 极客大学架构师训练营

第 7 周 听说你有好几个线程

Pyr0man1ac

架构师训练营第七周课后练习

第三周-课后练习

jizhi7

架构师训练营 1 期 - 第七周作业(vaik)

行之

极客大学架构师训练营

#链表# #快慢指针#

玉皇大亮

链表 快慢指针

Week 7 作業

--------世界中心---------

架构师训练营第 1 期第 7 周作业

好吃不贵

极客大学架构师训练营

策略模式

猴子胖胖

golang 设计模式

架构师训练营第 1 期 - 第 7 周 - 命题作业

wgl

第三周-总结

jizhi7

极客大学架构师训练营

架构师训练营1期 - week07- 作业

lucian

极客大学架构师训练营

week3-作业二:根据当周学习情况,完成一篇学习总结

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