前言
”三分靠技术，七分靠管理“这句话可能大家都听说过，事实上背后是涉及到了一系列的方法论，可能业界听过什么程序猿到了一定年龄就转管理岗这个其实是事实。放到大数据平台治理上，这个完全适用的。我们做一个平台化的治理，需要的衡量清楚局部和整体的关系，做到优化的整体化，而不是追求局部优化。所以不管在任何时候，我们都需要看到我们全局的状况，找出资源大头，再精准打击，首要条件的事情便是资源成本化。
大数据平台资源成本衡量
成本的消耗其实来源很多，涉及到网络带宽，交换机，路由器等器材，机柜租用，以及本身的CPU价格，内存价格都有。但是我们需要怎么去衡量我们的平台成本呢，实际情况是，我们不需要真正把实际确定花费多少钱算得那么精准，而是给平台上面可用于优化和治理的信息进行量化就可以，对于一个大数据平台而言，主要针对两个资源就可以，那就是存储和计算。得到一个资源模型，再按照总的成本去进行分摊即可。
存储成本计算
成本=(存储r1+计算r2)
r1和r2是用来分摊时候的资源系数，也就是可以拿到比例值即可
存储成本
存储成本比较直接，物理表对应的存储即可,比如一个TB=100块钱，那么1GB就是10块钱。需要注意的点有下问题:
1.hdfs上面的存储会出现类似多副本*10或者3的存储，也会出现eccode编码之后的1.5倍的存储，那么这种时候怎么去计算呢？
2.视图是不占用存储的，这种时候是不是存储是0呢？
3.我的是外部表这种时候如果很多表都怪在同一个目录下面，那么这种时候共享一份存储，那么这个时候怎么计算呢？
4.我的表cache到了ssd上面，也是占用存储，那么这两个介质上面的是不是都算呢？
仔细一想，就发现计算存储这个事情好像也没那么直接，所以这个时候我们要明白这个时候本身的目标是什么，我们的目标其实是期望反应到资产成本的存储积数，本身的一生就是我们其实期望未来用户是可以下线掉资产的，在一套干净，整齐的资产范围之外，我不希望乱七八糟的资产也进来，所以这种时候我们其实会需要把这种不占用存储的资产也计算成本，未来可以看到的是哪怕下线一个无用的视图，那么也是可以看到成本在下降。面对一系列的问题，我的回答是 一份存储即可，不管是多副本还是单副本，我们都期望是资产占用的成本是相同的单位存储价格 去治理的，所以即使你有10个副本，我依然按照一份存储单位进行计算。
计算成本
计算成本其实在我们实践中被挑战过很多，因为涉及到引擎的不一样，所以资源计算有点不一样,在Yarn的计算体系下，CPU和内存的消耗其实就是核心关注的事情，另一个角度来说，不管是Hive、Spark、Flink等部署在Yarn上，对应资源分配来说，我们都是可以统一到对内存的分配上来，所以核心的考量是关注以上两者的消耗情况。对于资源来说，我们直接是采用资源占用多久来进行衡量，所以是 资源消耗= Core*时间，换算之后我们叫做CU，我们根据CU进行定价。
Hive成本的计算
Hive的任务其实最后的转换成了mapreduce的模型，我们分析一下资源模型:
根据资源消耗分析，我们按照如下公式进行换算
作业消耗
cpu消耗=map个数x时间+reduce个数x时间 ，
内存消耗=mapreduce.map.memory.mbxtask个数+
mapreduce.reduce.memory.mbxreduce个数
Master需要占用一份，则+1即可
yarn中的内存配置如下
mapreduce.map.memory.mb=256m
mapreduce.reduce.memory.mb=256m
当然实际情况会被任务内部配置做调整改变，但是总体是这个逻辑，每个任务配置从log中进行提取，我们就得到了hive的资源模型
Spark作业成本计算
Spark计算本身也是按照内存和CPU的消耗计算， Spark的作业模型我们分解如下
,Spark资源成本计算模型如下：
作业消耗
cpu消耗=task个数*时间，
内存消耗=Worker个数xexecutor-memory
Master需要占用一份，则+1即可
但是，有些问题！！！
最开始的话确实是这样去做的，在Hive的任务比较多的时候问题不大，但是随着平台做优化升级，整个平台逐步把任务切换到Spark引擎下，这个时候资源计算发生改变。
首先一点，hive作业对内存消耗其实不大，平台默认也就1g,后面资源升级，调整成了2g，资源消耗也还好，作业对资源的控制还是维系在一个正比关系。但是加了Spark之后，由于内存是executor-memory参数控制的，这个到了Spark默认配置一度上调6g->8g，有的干到了20g，25g，因为内存和成本就是一个系数，所以原有的成本体系一度崩塌了。
基于这种情况，考虑到实际的成本和引擎不一样，所以并没有去统一去进行对待。而是按照实际的消耗去评估作业的切换方式。
写在后面的话
实际情况来说，对于Yarn来说，本身的Vcore占用的时间和Memory消耗是准确些的，但是实际没有落地这样去实施，原因是平台间隔离比较大，yarn中打印的日志量缺少关联信息，所以其实是一个开发工作量，并没有直接使用。
另外，资源成本换算的成本目标是业务口径，用于知道使用团队的资源使用情况，进行换算是可以满足实际场景的。
最后一点，实际作业成本还有一些资源消耗比较难输出资源情况，例如adhoc的查询，spark sts作业，presto 等，还有一些因素是调度成本和数据扫描成本，综合的下来业务方本身不感知，而且会导致用户使用被很大程度限制！综合考量才是符合实际要求的解法。