漫谈大数据中的资源管理

资源管理 Resource Manager，简称为 RM。最早 Hadoop 中用 Yarn 做 RM，各种计算引擎也纷纷默认支持 Yarn 做调度，后来随着云计算和容器技术的兴起，逐渐诞生了 k8s 和 Mesos 这两款做容器编排的产品服务在线业务，随着技术的演进也逐渐用来调度离线任务。

随后，Mesos 社区逐渐失去了活力，Yarn 也随着 Hadoop 的没落逐渐变成技术债，k8s 变成了事实上的标准。与此同时，除了开源界的产品外，各大云厂商也推出了自己 emr 产品，全称就是 elastic map reduce。推出此类产品的目的也很明确，就是想让用户在自己的云上使用大数据套件，但也不得不说对于离线 ETL 业务来说在云上使用还挺合适的，ETL 负载很明显有潮汐特点的，一般零点之后开始，上午会把任务跑完，同时要消耗大量资源，如果固定一批机器会造成大量的闲置，而不买的话要用的时候又不够，云弹性的特点刚好能满足这个需求。

这篇文章和存储、计算篇不太一样， 不会大讲特讲各种技术的优劣和历史，因为只有 Yarn、Mesos、k8s 这三个产品可写，这次重点讲一下产品背后的设计逻辑，鉴于我（techinstitute）没怎么用过 Mesos，且已经几乎退出历史舞台了，所以能讲的就是 Yarn 和k8s。

## Vol.1

其实大数据技术最开始要解决的问题很简单，如何让用户简单的使用分布式系统，处理单机无法处理的数据，同时又能对用户屏蔽分布式的复杂度。所以单机上有的模块，在分布式场景下也要解决，分布式文件系统对应单机文件系统，计算引擎技术把单机版升级为分布式版本，而 RM 就对应着单机操作系统中的调度器，单机操作系统的调度器调度是 cpu 时间分片，而分布式的调度器则要给程序合理地分配 cpu 和内存数量。

无论是Yarn还是k8s第一步都是把物理资源管理起来，需要把节点的CPU、Memory、GPU、Storage 容量记录到 master 节点，在 worker 节点启动一个守护进程监控资源用量。需求看起来容易，实际落地就很考验工程能力。

就拿 k8s 的 kubelet 来说：

- 资源管理：kubelet 需要有效地管理节点上的资源，包括 CPU、内存和存储。难点在于确保资源的合理分配和利用，以及避免资源的浪费和拥塞。

- 网络配置：kubelet 需要与其他节点和服务进行网络通信，因此需要正确配置网络以确保容器之间的通信和外部访问。难点在于处理复杂的网络拓扑和跨节点通信。

- 安全性：kubelet 需要保证节点和容器的安全，防止未经授权的访问和恶意攻击。难点在于确保节点和容器的隔离性，以及监控和应对安全漏洞。

- 监控：kubelet 需要对节点和容器的运行状态进行监控和报告，以便及时发现和解决问题。难点在于处理大规模集群的监控数据和实现全面的监控覆盖。

一般来说物理资源在 1k 以内的时候不太容易出问题，超过一定的规模，基本上就会天天报警。

## Vol.2

在数据领域如果做数据库或者存储引擎一般不太会和资源管理组件打交道，而做 ETL 离线任务就是资源管理的重要用户。一个数据工程师，日常最重要的工作就是合理的规划资源把数据从 A 搬到 B，一个大型的 ETL 任务占用几百 core、上 TB 的内存是很正常的，在一些大型的互联网公司一天处理的数据量就有在 PB 级别，动辄上万的任务，几十个不同的业务。

任务调度层面，需要考虑的问题比较复杂，一是离线任务有大有小，比如日活百万和千万的业务，数据量肯定也是数量级的差别，二是任务之间还有依赖关系，比如数仓分层，下游表依赖上游跑完才能触发，三是任务优先级有区别，老板关注的数据和普通分析师关注的报表重要程度自然是不同的，四是不同业务的任务成本核算，离线任务需要的计算资源大，是很重的成本中心，有效的统计不同业务使用的资源量，在年终核算成本、年初报预算时是很重要的指标，五是如何高效的利用资源，数据开发工程师的水平参差不齐，帮助数据开发写出好的 ETL 代码也是降本增效的重要一环，这里涉及到高效调度算法、调度引擎、任务监控、profiling 等能力。

Yarn 的设计初衷就是为了解决上述问题存在的，其中调度、队列、租户、监控等逻辑很完备，在几年前各大公司基本上就是把 Hadoop 的 yarn 拿过来改一改就能用。很长一段时间以来 k8s 更多的是服务在线业务，Yarn 负责离线业务彼此相安无事，而且 k8s 自带的调度逻辑也比较弱，很难满足上万个离线任务复杂业务场景的需求，真正能起到调度作用的是 k8s 的扩展调度器 Volcano。

Volcano 和 Yarn 对比起来，功能层面差不多，也没什么好对比的，如果公司的技术栈在 k8s 自然会选择 Volcano，如果是 Hadoop 天然就自带 Yarn。只考虑 Data 领域的话 Yarn 的优势比 Volcano 还更大一些，毕竟 Yarn 迭代了十几年，Volcano 在其面前还是小弟，但是如果加入其他因素的考量，例如对 AI 框架的支持、在离线混部的场景，Yarn 就显得无能为力了。这也是很多新的公司 infra 技术栈全面使用 k8s 的原因。

## Vol.3

资源换成财务视角的话就是成本，没有一家公司不想节省成本。对于有在线业务的公司来讲，在线的业务一定是有峰值和谷值的，离线任务更是如此，而且离线任务的灵活性更高，如果能充分利用在线业务谷时的资源把离线任务跑完，那无疑是最省成本的。理想很丰满但真实落地的就充满了挑战。

资源管理层面，在线业务是延迟敏感，而离线作业更在意吞吐量，需要根据实际情况调度资源

优先级和容错，在线业务优先级无疑是大大高于离线作业的，当在线流量增加时，会把离线作业驱逐掉。所以在开发离线任务时做好充足的容错很有必要

调度器的性能，混部意味着要调度的 pod 更多，高效的调度更重要

监控和调优，混部是一个实践出真知的过程，没有人能一上来设计一个天衣无缝的调度策略，所以要做好打持久战的心理准备，持续优化系统。

## Vol.4

可以看到调度器其实不只是大数据在使用，而是全业务线都影响的组件，在系统架构中处于更关键的位置，牵一发而动全身，一旦选定不到万不得已一定不会改。选择业界主流的方案无疑是最优的选择，很少有自研的需求，如果公司规模和业务复杂度已经是业界数一数二的，肯定会自研或基于开源魔改。哪怕是大厂魔改的调度器与开源版比起来并不会有本质的差别，除非技术迭代了新版本，对于大多数开发者来说，学好主流的 Volcano 和 Yarn，弄清楚背后的设计逻辑、不踩坑就可以了。