背景

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

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

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

组件

HDFS

为什么需要治理

1. 财务预算高

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

2. 集群负载高

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

3. 运维压力大

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

为什么难以推动

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

需要做什么

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

1. 冷数据

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

2. 碎片文件

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

3. 异常增长

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

4. 空间占用绝对值高

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

5. 集群容量评估

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

6. 数据生命周期

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

部分效果图

容量评估

2020042314233829.png

用户资源使用趋势

20200423213916347.png

用户数据日增量

20200423142316184.png

SPARK & YARN

为什么需要治理

1. 资源使用不平衡

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

2. 运行时间不稳定

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

3. 资源滥用

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

需要做什么

1. 作业资源统计分析

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

   • 终端的作业都是独享一个 Spark Application ，从 submit 到 shutdown 有一个完整的生命周期。

   • 大数据平台作业则分为独享和共享 Application 两种，独享和终端类似，共享的方式是一个作业由 Spark 的几个 job 组成。

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

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

2. 集群资源统计分析

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

3. 内存及 cpu 使用控制
   spark on yarn cgroup 资源隔离(cpu篇)
   使用 jvm-profiler 分析 spark 内存使用

4. 作业数量/资源池限制

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

部分效果图

集群资源使用及作业 Top

20200423141941621.png

集群当前状态

2020042314184496.png

Spark任务诊断

20200423141331153.png

20200423141346851.png

计费

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

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

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

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

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

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

任务维度的计费

任务维度的计费

后记

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

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