点击关注“有赞coder”
获取更多技术干货哦~
成本可量化,细到每个数据的成本以及它的构成
浪费可感知,能发现并提示出有多少浪费存在
降本便捷性,知道了浪费,还要知道如何优化,高效地降本
过程可跟踪,做的降本动作,需要被记录和跟踪,反应成本变化
机制运营,如何设计奖惩措施,激发自主降本,保持良性循环
全社会投入养猪的成本就是总成本。那么我们用于数据产出的所有机器的总投入就是我们的总成本。记为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)
存储使用的磁盘,这里要注意的是,数据的备份也会占用空间。如存在hdfs集群上的数据,一般是3备份。
计算使用的cpu、内存等,通常跟占用时长也有关,这个可以想办法采集到。
时间,这里特指产出数据对应的任务的运行时段。由于不同时段,集群的资源紧缺程度不一样,从供需角度,应该考虑分时计费。
data_size*replicator
,其中data_size是数据名义大小,replicator是备份数。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)
0-8 点是黄金时段,业务数据赶着在上班前跑出,任务繁重,资源负载接近极限
8-13 点是白银时段,负载没那么高,相对次要点的数据和数据重刷任务会集中在这个时段
13-24 点是青铜时段,集群相对空闲
0.6*w1+0.3*w2+0.1*z=1
且 w1>w2>w3
。为了更好的效果,w1和w2、w2与w3之间,要拉开差距。(cs1*w1+cs2*w2+cs3*w3)/cpu_seconds
,同理可以算出memory_weight。cpu_cost= cpu_price*(cpu*cpu_weight)
memory_cost= memory_price*(memory*memory_weight)
disk_cost= disk_price*disk
数据对应的任务,可能同时产出多个数据,那成本怎么分摊(简化模型,等比分摊)
数据的成本归属给谁,谁来负责关注和优化(确保每个数据有唯一的owner)
成本总览,负责数据的总成本、变化及其排名,心中有数
成本趋势,过去n天,成本变化趋势,可以看不同资源的成本趋势,未来有预期
必要的榜单,负责的数据里,哪些高成本或者高耗时的,关注和优化有抓手
降本信息,累计节省多少成本,剩余多少不必要的浪费,感受动力和压力
价值信息,数据服务了多少业务,被多少人使用,体现价值
摊:一个计算任务只属于一个人,可能产出多张表,此时会将平均成本分摊到表。
合:粗粒度的成本,通过细粒度聚合而来,不做重复计算。比如,单表有唯一的owner,可以汇总到人;另外,有专门的业务域管理,表和业务域是多对多的关系。
联:由于很多数据无法直接关联到表或者人,在算粗粒度的时候,需要额外关联到对应实体。比如目前有许多临时查询任务,消耗资源,但是并非表的成本,但是应该算到人头上。
一脉:下线。对于无用的数据,直接下线,最直截了当。那么如何判定“无用”呢,这依赖于我们强大的“血缘”追踪能力。系统会自动采集数据的链路流转以及使用情况,结合一定规则,判定疑似无用的数据,并区分中高低档。当然,最终是否可下线,还需要人确认。因此,这点可以总结为人机结合。
二脉:延迟启动。前面我们讲过分时计费,那么自然地想到“错峰执行”,利用闲暇时段执行不重要的任务,还能获得“折扣”。系统会挑出在黄金时段运行的非重要任务,推荐延迟启动(这个可以分阶段做)。
三脉:高频转低频。很典型的例子,小时级任务一天运行24次,是否有必要,能否降低频率,是不是天级就够了。有些任务甚至不需要每天跑,隔三差五就行。实际推进过程中,我们发现了不少这样的例子。
四脉:替换。比如,有许多数据由于历史原因,已经不再维护,可以用另一个替换(成本更低);有多个功能相似的任务,可以合为一个。这类优化不仅可以降本,还能节省运维、答疑成本。
五脉:任务调优。对于hive任务,是否有任务倾斜?使用的数据量能否减少?语法使用能否优化?等等,这类优化需要具体问题具体分析。
六脉:小文件合并。目前我们的任务支持spark和hive引擎执行,spark不能自动进行文件合并,有些任务并行度高,会产生过多小文件。对于这类case,hive有文件合并策略,能大幅减少文件数,提高task的利用率,节省资源。
首先是宣导,宣传成本意识,引导降本行动。
在系统数据的详情页、个人工作台等地方,呈现成本相关信息,引起关注
日常工作中,月会周会强调成本浪费问题
发送成本账单给个人和TL等
其次是骚扰,主动出击推动降本。
抓成本大户,给予足够的“关怀”
对于高耗能数据,着重关注和优化
建立迭代项目,以周为单位把相关人员聚集,集中开展优化
再次是反馈,平台与用户互动起来。
注重降本过程体验,保证便利性,兼顾安全性
行为可跟踪,体现降本成果,平台监控之外的降本动作,也可以登记
推进过程中,探索和收集更多降本点,逐步完善覆盖面
最后是奖惩,鼓励减少浪费。
必不可少的是榜单,“降本之星”和“降本潜力股”,分别作为红黑榜
给每月降本top3的小伙伴发放有赞币
公共场所秀成果,表扬和激励
限制数据开发、任务发布(这条属于惩罚性措施,小伙伴们都比较积极,目前还没用到)
总之:降本意识靠宣导,成本大户要骚扰,既要用户多反馈,也要奖惩做到位。
以上之外,平台本身也需要对降本做全方面的统计监控,我们有专门的看板辅助运营。
解决已知问题,精细化运营,提升效率和效益
扩大战线,跳出离线集群,扩大成本运营覆盖面
将成本归属至业务,知道钱花在哪,“对外”算账
建立数据价值评估体系,知道投入,也要知道“产出”,这也是一个充满未知和挑战的方向