文章目录SPARK & YARN计费后记

背景

大数据平台早期是野蛮生长的，作业直接在终端提交运行，处于一种完全无管理的自由状态。在17年上线了内部的大数据平台后，用户开始逐渐在平台上进行数据管理，代码编写，作业管理等工作，但是资源治理依旧缺失。

随着业务及数据量的不断增加，集群扩容，存储和计算资源达到一定规模后，对大数据平台进行资源治理就非常必要了，本文是基于 HADOOP 生态的一个总结。

该项目大部分完成于18年，由于内容较多（人比较懒），几次提笔都搁置了，全文主要围绕 为什么做/要做什么 来展开，至于具体怎么做，方法有很多，大家就见仁见智了。

组件 HDFS 为什么需要治理

财务预算高

数据增长非常快，不干预的情况下日增能达到100T。在计算与存储没有分离的情况下，存储资源的不足就意味着需要购买新的机器，不仅成本非常高，还会造成计算资源使用率低下。

集群负载高

HDFS 虽然支持水平扩展，但是当集群到了一定规模，NameNode 就会成为瓶颈，其一为 NN 的内存瓶颈，其二为大量DN的心跳RPC请求带来的网络瓶颈，同时重启恢复时间也会变长。

运维压力大

频繁的扩容，即使有自动化工具的支持，也会给工程师带来一些低价值的工作。

为什么难以推动 在集群数据量级较小的情况下，以优先解决业务需求为主，增加机器远比开发一整套资源分析系统的成本要低。平台需要推动业务部门删除一些”僵尸数据“，但业务部门人数较多，以开发业务为核心，删除数据在他们看来优先级非常低。 需要做什么

核心思想：控制增量，优化存量

冷数据

长期没有访问的数据，包括一些分析建模留下的中间数据，无用数据等。针对这部分数据，设计了一个资源浪费分的概念，根据数据目录大小绝对值和最后一次访问时间进行计算，该分数达到一定阈值后会对用户进行提醒，不操作则进行删除。

碎片文件

通过计算目录下每个文件的平均大小，平均大小小于某个阈值时会触发，进行合并压缩处理，可以参考 Spark 小文件合并优化实践

异常增长

数据目录增长异常，可能是业务存在较大的变动或是用户的误操作导致，这种情况需要对用户进行预警。

空间占用绝对值高

使用更高压缩率的压缩算法，例如zstd。统计出日增长绝对值最高或者月环比 / 季环比较高的 team ，发送邮件给相应 team leader，要求给出解决方案。

集群容量评估

根据集群历史数据增长情况，评估目前的容量多久后需要进行扩容。

数据生命周期

所有的数据进行表化，上大数据平台，强制填写生命周期，例如物化的临时表生命周期为7天，到期后会自动删除，不需要主动进行管理。普通的数据表/分区生命周期到之前7天给用户发邮件/钉钉，用户可以选择续期或者直接过期删除。

部分效果图

容量评估

用户资源使用趋势

用户数据日增量

SPARK & YARN 为什么需要治理

资源使用不平衡

比较常见的情况是集群中内存被申请满了，但是 CPU 还有剩余。

运行时间不稳定

同个作业多次运行时间波动幅度大。

资源滥用

每个业务方都希望自己的作业能尽可能快的完成，导致资源被滥用，带来一些不必要的资源紧张。

需要做什么

作业资源统计分析

现实的情况是大多数作业直接运行在大数据平台上，少数作业因为历史原因还在终端运行。

对于独享的任务，直接计算整个 application 运行期间消耗的 mem_seconds/core_seconds ，共享的任务资源使用则是通过该任务结束时间获得的 mem_seconds/core_seconds 减去开始时间的值获得。

对于 Spark 作业，还可以通过 Listener 对 task 做进一步的分析，帮助优化应用资源使用。

集群资源统计分析

根据统计信息能获取当前 cpu/mem 使用较高的一些作业及用户，根据历史资源使用趋势可以更合理的安排作业的调度时间。

内存及 cpu 使用控制

spark on yarn cgroup 资源隔离(cpu篇)

使用 jvm-profiler 分析 spark 内存使用

作业数量/资源池限制

在平台层面对用户/应用账号不同类型作业（schedule/dev/etc.）进行提交数量限制，对不同的应用分资源池进行约束。

部分效果图

集群资源使用及作业 Top

集群当前状态

Spark任务诊断

计费

对于普通用户来说，提供诸如 core_hour / mem_gb_hour / disk_gb_day 之类的单位过于抽象，很难意识到自己真正使用了多少资源，所以根据算法直接将物理资源折算成人民币，可以具体到每个任务运行花了多少钱。

Spark 计算时会同时申请 mem 和 cpu 资源，如果一台物理机内存被申请完了，cpu 资源也是无法使用的，所以根据物理机的配置折算成计算单元更为合理 1cu = (1C,5G)，最后会根据 cu 和存储占用进行综合计费。

通过计费的方式可以对资源进行更直观的展现：

从用户的角度，可以知道自己的某个任务计算花了多少钱，某个表存储花了多少钱。

从公司的角度，能清晰的从报表上看到哪几个部门用了多少钱，哪个Team用了多少钱。

从业务的角度，根据资源的使用可以更好的评估投入产出比以及业务价值，让其更有动力去优化业务代码。

任务维度的计费

后记

18年上线后进行了四个月的跟踪观察，存量数据绝对值降低了20%，文件数量降低了 35%，增量数据增速降低了80%，集群整体的内存使用率提升了20%，同一作业的多次运行时间波动范围下降了50%。

在整个治理过程中，技术只是其中的一小部分，同时还需要从行政上进行辅助，否则效果将会大打折扣。