1.HDFS起源：GFS 1.1分布式文件系统起源 在1990年前，信息技术不够普及，对于文件的存储，往往都是一整个文件存储到单台机器。随着互联网技术的发展，互联网也可以将成千上万的计算机作为存储连接在一起。 同时，对于企业而言，其文件越来越大，越来越多，导致单台机器没有空间存储这种大文件；同时，这种大文件读取和写入变得非常耗时。 分布式文件系统的提出就是为了解决这类问题： 将大文件条带化地存储到多台服务器上。理论上来说，只要有足够的存储服务器，单个文件可以无限大。 由于大文件被切分成多个数据块，在写入时，以块为单位向不同服务器写入，可以并发地向不同服务器中写，提高写入速度；在读取文件时，可...

1.背景 随着业务的增长，Yarn集群也不断扩展。节点数增多、请求增多、队列增多，造成调度性能线性下降。如下是三个集群的性能数据： 集群 队列数量 平均调度耗时 最大每秒调度数量CPS 集群A 2706 3.8ms 483 集群B 620 940微秒 1150 集群C 399 676微秒 1013 对于集群A，其调度耗时已经非常高了，吞吐量也是腰斩。最大内存使用率72%，平均内存使用率45%；最大vcore使用率66%，平均vcore使用率40%。 为了避免由于队列的增加导致调度性能下降，无法通过打label的方式进行缓解，这是因为即使有label，依然是全队列排序...

1.背景 对于大数据组件，经常需要进行扩缩容的服务，例如Yarnnodemanager、AlluxioWorker。往往需要频繁的人工操作上线下线，非常繁琐，耗费较高的人力成本。 为了降低这种人工操作的成本，可以考虑将这些服务部署到kubernets中进行管理。本文通过介绍kubernets启动容器的过程，介绍期间经历的所有组件，帮助提升对kubernets的认知。 2.kubernets架构 一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件。 master：集群的控制平面，负责集群的决策(管理) ApiServer:资源...

1.背景 场景一 对于运行在AWS上的nodemanager，为了节省成本，选择了不定期回收的机器类型。在这些节点上运行的作业会失败重试，对于一些重要作业而言，这种行为不可接受。而CapacityScheduler提供NodeLabel节点标签功能，可以给一些不可回收节点上的nodemanager打上标签，让重要作业运行在打过特定标签的节点上，保证作业顺利运行完成。 场景二 对于实时集群，其taskMananger会在不同节点间产生大量的流量通信。如果实时集群跨机房，机房间的流量会非常高，甚至打满带宽，导致其他正常使用贷款的服务产生延迟，发生严重后果。这种可以将不同机房的节点打上不同的标签，实...

1.背景 默认情况下，FairScheduler对资源进行调度时，会使用FSParentQueue.assignContainer先对队列进行排序，然后再调度应用： TreeSet<FSQueue>sortedChildQueues=newTreeSet<>(policy.getComparator()); readLock.lock(); try{ longstartDuration=System.nanoTime(); sortedChildQueues.addAll(childQueues); scheduler.fsOpDurations.addACSortFo...

1.背景 在https://blog.51cto.com/u_15327484/7894282文章中，介绍了Yarn的两种调度器。在https://blog.51cto.com/u_15327484/7920197文章中，介绍了FairScheduler迁移CapacityScheduler的迁移实践。 在实际迁移之前，必须要确保CapacityScheduler能够达到足够的收益，即吞吐率或调度时间等指标都有所优化，才能开启迁移操作。 而为了评估迁移收益，很难直接通过搭建1k+个NodeManager的Yarn集群来测试调度器性能，这样太浪费成本。为了解决这个问题，Hadoop官方提供了Sc...

1.背景 在https://blog.51cto.com/u_15327484/7920197文章中，将调度器从FairScheduler迁移到CapacityScheduler。 CapacityScheduler在默认情况下，当接受到NodeManager心跳请求时，会调用nodeUpdate方法开始进行资源调度，这种调度方式称为心跳调度，也称同步调度。 心跳调度实现起来简单，但是有很大的弊端。它及其依赖NodeManager心跳的稳定，一旦NodeManager和ResourceManager网络产生波动，那么ResourceManager的调度也会发生延迟，这种调度方式十分不稳定。 C...

1.背景 NodeManager中，将机器的CPU资源抽象为vcore，将内存资源抽象为memory。例如机器为102核、256GB内存，希望赋予NodeManager196GB内存和72核CPU，用于给container分配资源。其配置如下： <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>200704</value> </property> <property> <name>yarn.nodemanager.r...

1.背景 在Yarn中，资源调度是最核心的功能。在https://blog.51cto.com/u_15327484/7835300文章中，介绍了Yarn调度的核心接口ResourceScheduler通过nodeUpdate方法调度资源，通过allocate方法获取调度结果。 ResourceScheduler常用的ResourceScheduler实现就是FairScheduler和CapacityScheduler，它们的调度流程都非常长。本文会围绕源码介绍调度流程，一些细节会忽略。 2.调度器结构 队列：在FairScheduler和CapacityScheduler中，都维护了队列...

1.Yarn组件起源 文章概要：在Hadoop1.x版本中，主要有HDFS和MapReduce两个组件。Mapreduce组件的jobtracker既要负责资源管理，又要负责作业调度。当集群规模到达10000台时，jobtracker每秒只能给10台tasktracker分配task任务，存在严重的调度性能瓶颈；在Hadoop2.x版本中，将作业调度功能从jobtrack中剥离出去。ResourceManager负责资源管理，ApplicationMaster负责作业调度。 1.Hadoop1.xMapreduce框架 1.1框架初了解 在Hadoop1.x中，只有HDFS和mapreduce...

💡文章概要：上一篇文章介绍了几种内存分析工具，在工作过程中，使用了这些工具解决很多线上的问题。本篇文章中使用了MAT工具，帮助分析出了resourcemanager泄漏的原因。 1.背景 2021年线上Hadoop升级到了Hadoop3.3.0版本。运行了6个月，发现resourcemanager监控面板中，堆内存一直缓慢增长，每隔一段时间服务都要重启一次，十分影响服务稳定性，因此需要排查出来内存泄漏原因。 2.分析 2.1分析思路 面对内存泄漏的问题，首先要知道哪些对象泄漏了，其次分析为什么代码没有将这些对象清理。查看泄漏的对象，一般需要使用VisualVM或者MAT打开hprof，看看对...

💡文章概要：上一篇文章介绍了几种内存分析工具，在工作过程中，使用了这些工具解决很多线上的问题。本篇文章中使用了jstack工具，帮助分析出了sparkdriver线程死锁导致作业卡住的原因。 1.背景 spark执行sql时，出现卡住的情况。 2.分析 对于线程卡住，可以先看看CPU和内存的使用情况，发现正常。 此时需要查看main线程是不是卡住了，因此使用jstack工具查看线程状态，发现了线程死锁的情况： FoundoneJava-leveldeadlock: = "DataStreamerforfile/tmp/spark-events/application_162262243005...

💡阻碍阅读Hadoop源码的重要一环就是HadoopRPC，当阅读这一块代码时，往往有各种proto文件。当我们想要寻找Hadoop服务端的API实现时，可能会直接跳转到protobuf生成的代码，这里面并不是业务代码的真正实现，往往会讲阅读者思路打乱。本文会介绍并实践RpcWritable和Rpcprotobuf，对protobuf的概念有一定了解；下一篇文章会详细介绍HadoopRPC的实现。 1.RPC基本流程 在早期，本人就写过netty中rpc的实现：https://blog.51cto.com/u_15327484/5406288。先回顾下RPC的基本调用流程： 客户端调用客户...

1.背景 在Hadoop的性能指标中，rpc是最核心的一类指标，它标志着Hadoop服务的性能。通过该指标能够判断服务此时是否正常。如下所示： 同时，在配置文件中，还有很多rpc相关的重要配置，例如： ipc.server.handler.queue.size ipc.server.read.threadpool.size dfs.namenode.handler.count 作为Hadoop开发运维人员，一定要对HadoopRPC有深入的了解，否则根本不懂上面的配置和指标具体含义，也无法对集群进行优化。 2.Reactor模型 在多路复用模型之前，如果只使用nonBlockingIO，...

1.背景 之前写过Yarn状态机的两篇文章。 https://blog.51cto.com/u_15327484/4940200介绍了AsyncDispatcher线程，它提供以下机制： 通过调用它的register()方法注册不同类型事件对应的处理器，放入Map中。 通过调用它的handle()方法将具体的事件放入到事件队列BlockingQueue中。 内部eventHandlingThread线程负责消费BlockingQueue中的事件，它匹配事件对应的Handler，执行Handler的handle()方法。 https://blog.51cto.com/u_15327484/5...

1.背景 在上一篇文章中：https://blog.51cto.com/u_15327484/7790888，介绍了ResourceManager从接受用户提交用户的请求，到ResourceManager向Nodemanager发送startContainer请求启动applicationMaster程序的部分重要流程。 本文将继续查看Nodemanager中，如何启动Container。 2.Container定义 在启动Container前，首先要清楚Container是什么。在Yarn中，Container是抽象类，具体资源由其实现类ContainerPBImpl表示。 publiccl...

1.背景 此前写过两篇文章，分别介绍了应用提交到ResourceManager的事件流程，Resourcemanager命令Nodemanager启动container流程。 其中，https://blog.51cto.com/u_15327484/7790888介绍了应用提交到ResourceManager的事件流程。其中包含存储application信息到zk中，将application信息存放到scheduler中，发送LAUNCH事件命令Nodemanager启动容器。 后面，https://blog.51cto.com/u_15327484/7815432介绍了Nodemanager...

1.背景 在上一篇文章中：https://blog.51cto.com/u_15327484/7834523，介绍了applicationmaster申请资源流程： 注册applicationmaster。 发送资源分配请求。 获取资源，启动container。 发送剩余所需资源的分配请求。 然而，虽然是通过ApplicationMasterProtocolallocate进行资源分配，但实际上并不是由该接口直接从资源池里面获取资源，它只是获取分配结果，具体分配逻辑是由nodemanager的心跳进行触发的。本文将介绍nodemanager通过心跳请求，触发resourcemanager资...

1.背景 一年前写过的一篇文章：https://blog.51cto.com/u_15327484/5046768，介绍了ResourceManager的启动流程。文章中介绍了ResourceManager的选举流程，但是行文逻辑较混乱。本文在此基础上，更清晰地介绍了resourcemanager的高可用原理，希望能够达到小白也能看懂的程度。 2.Zookeeper相关背景知识 2.1Watcher通知 使用场景：客户端通过注册watcher，当zookeeper的某一路径状态发生变化时，会向客户端发送watcher事件，客户端中，通过Watcherprocess处理该通知。 Watcher使...

1.背景 内存分析指MAT，即memoryanalysistool，通常使用eclipse提供的MemoryAnalyzer的工具包解析dump文件。可通过MAT解析内存泄漏、查看内存中变量大小。 2.生成dump文件 dump一般译作转储,有动词和名词两种场景。动词场景：因为程序在计算机中运行时，在内存、CPU、I/O等设备上的数据都是动态的（或者说是易失的），也就是说数据使用完或者发生异常就会丢掉。如果我想得到某些时刻的数据（有可能是调试程序Bug或者收集某些信息），就要把他转储（dump）为静态（如文件）的形式。否则，这些数据你永远都拿不到。名词场景：dump作为名词一般就是指dump(...