- 博客(153)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 HDFS-2.0社区版的HA+Federation的实现解析
在Hadoop的1.x版本中,NN的单点处理能力成为HDFS的主要(容量扩展/性能/可用性)瓶颈,主要表现在:一.NN在管理大规模的命名空间时,所消耗的内存堆必定在10GB/100GB级别,无论是触发的Full Gc(32GB需要2min)还是重启时(元数据加载/操作日志回放/数据块汇报)时间消耗对高可用性来说都是无可忍受的;二是NN在内部用一把全局锁撸遍所有的元数据操作来保证数据的一致性;三是被
2015-03-29 17:01:23
3059
原创 内存代管理器TenuredGeneration对垃圾对象的回收
内存代管理器TenuredGeneration作为基于内存分代管理的内存堆管理器GenCollectedHeap默认的旧生代管理器,它对垃圾对象的回收算法要比年青代Gc要复杂的多,但其主体思路就是:标记-清除-压缩.本文主要围绕内存代Gc时的三个过程来详细讲解TenuredGeneration是如何进行垃圾回收的.一.Gc条件 可对 TenuredGeneration管理的旧生代进
2015-01-18 15:57:18
3471
原创 内存堆Gc时公认的根对象
内存堆的Gc就是回收内存堆中垃圾对象(非active对象),那么这里就有一个问题了,如何寻找垃圾对象?换个思路来解,就是如何找到所有的active的对象,那么剩下的就是垃圾对象了.HotSpot是通过首先找到所谓的根对象,然后根据这些根对象递归或迭代的搜索所有的引用对象,而找到的这些个对象就是所谓的active对象了.其实,Gc时的根对象是一个与运行时上下文相关的概念,以基于内存分代管理的内存代管
2015-01-10 18:25:14
7994
2
原创 内存代管理器DefNewGeneration对垃圾对象的回收(Minor Gc)
内存堆管理器GenCollectedHeap在执行Gc回收垃圾对象的时候,无论是它自己还是垃圾回收策略MarkSweepPolicy都没有具体去规定一个垃圾对象应该如何被回收,而只是在整体上决策这次的Gc应该回收那些内存代中的垃圾对象,至于这些内存代管理器是如何做的,GenCollectedHeap并不关心. 从前文分析内存堆管理器GenCollectedHeap执行Gc策略调度内存代管理器去回收
2014-12-14 20:39:02
2894
原创 GenCollectedHeap的Gc策略MarkSweepPolicy
当内存堆管理器响应应用线程的一次内存分配请求失败时(就是没有足够的空闲内存),就会触发一次Gc来回收部分或所有的垃圾对象好腾出足够的空间来满足应用的所需内存,如果还不够则抛出OOM. MarkSweepPolicy的大体思路就是标记active的对象, 清理未被标记(非active)的对象MarkSweepPolicy作为内存堆管理器GenCollectedHeap的默认配置Gc策略, 针对这种内
2014-12-13 15:48:58
2671
原创 内存代管理器TenuredGeneration的对象内存分配
内存代管理器TenuredGeneration是基于内存分代管理的内存堆管理器GenCollectedHeap默认的旧生代管理器,对于java对象的内存分配处理还是比较简单的,但在垃圾对象回收方面.它的实现可能要远比新生代管理器要复杂的多.前文在介绍GenCollectedHeap是如何响应对象内存申请时就涉及到了旧生代内存管理器的几个核心的抽象接口,所以本文将主要介绍TenuredGenerat
2014-11-30 17:18:28
4545
原创 内存代管理器DefNewGeneration的对象内存分配
内存代管理器DefNewGeneration是所有基于内存分代管理的内存堆管理器的默认年青代管理器,同时它也只能用于年青代的内存管理而不能用于旧生代的内存管理.它的基本思路就是将整个内存代分配为三个区: Eden区, From区, To区; 一般情况下,只在Eden区和From区分配对象创建时所需的内存,To区只在内存代进行垃圾对象回收用于存放转存储过来的非垃圾对象(active对象):
2014-11-23 16:38:10
2921
原创 内存堆管理器GenCollectedHeap的初始化
前文在介绍Java对象内存分配的上层接口CollectedHeap时就提过, GenCollectedHeap是一种基于内存分代管理的内存堆管理器实现. 它一方面负责java对象的内存分配, 另一方面还得负责垃圾对象的回收, 而GC策略CollectorPolicy则是它的核心组件.这里,内存堆管理器GenCollectedHeap配置的GC策略实现是GenCollectorPolicy的子类,
2014-11-16 17:17:31
3816
原创 Paxos算法与Zookeeper分析
1 Paxos算法1.1 基本定义算法中的参与者主要分为三个角色，同时每个参与者又可兼领多个角色:⑴proposer 提出提案，提案信息包括提案编号和提议的value;⑵acceptor 收到提案后可以接受(accept)提案;⑶learner 只能"学习"被批准的提案;算法保重一致性的基本语义:⑴决议(value)只有在被proposers
2013-09-02 21:31:18
66441
13
原创 HDFS集群的启动(8)——NameNode任务线程之FSNamesystem$SafeModeMonitor
HDFS集群启动之后并不能马上进入工作模式为用户提供服务，而是先要进入安全模式状态，因为主节点要确定当前集群中的绝大多数数据块Block处于安全可用的状态以确保为用户提供更可靠的读服务。这个工作主要是交由主节点上的FSNamesystem来完成的。FSNamesystem在初始化的时侯会首先进入安全模式状态并在之后开启一个后台工作线程——SafeModeMonitor来监控当前集群是否可以离开安全
2012-11-29 11:33:44
3197
1
原创 MapFile和BloomMapFile文件
一. MapFile文件 前面说过，SequenceFile文件是用来存储key-value数据的，但它并不保证这些存储的key-value是有序的，而MapFile文件则可以看做是存储有序key-value的SequenceFile文件。MapFile文件保证key-value的有序(基于key)是通过每一次写入key-value时的检查机制，这种检查机制其实很简单，就是保证当前正要写入
2012-07-24 11:04:06
4462
2
转载 Hadoop下join操作的几点优化意见
1. 概述 在传统数据库（如：MYSQL）中，JOIN操作是非常常见且非常耗时的。而在HADOOP中进行JOIN操作，同样常见且耗时，由于Hadoop的独特设计思想，当进行JOIN操作时，有一些特殊的技巧。本文首先介绍了Hadoop上通常的JOIN实现方法，然后给出了几种针对不同输入数据集的优化方法。 2. 常见的join方法介绍 假设要进行join的数据分
2012-07-12 09:34:12
3530
1
原创 SequenceFile文件
SequenceFile文件是Hadoop用来存储二进制形式的key-value对而设计的一种平面文件(Flat File)。目前，也有不少人在该文件的基础之上提出了一些HDFS中小文件存储的解决方案，他们的基本思路就是将小文件进行合并成一个大文件，同时对这些小文件的位置信息构建索引。不过，这类解决方案还涉及到Hadoop的另一种文件格式——MapFile文件。SequenceFile文件并不保证
2012-06-26 17:40:32
28085
5
原创 Facebook的公平份额调度器FairScheduler
FairScheduler是由Facebook公司提出的，为了解决Facebook要处理生产型作业(数据分析、Hive)、大型批处理作业(数据挖掘、机器学习)、小型交互作业(Hive查询)的问题。同时满足不同用户提交的作业在计算时间、存储空间、数据流量和响应时间都有不同需求的情况下，使用Hadoop mapreduce框架能够应对多种类型作业并行执行，使得用户具有良好的体验，所以Facebook提
2012-05-23 19:57:10
7821
14
原创 详谈计算能力调度器CapacityTaskScheduler
Hadoop中有一个默认的基于优先级的FIFO任务调度器JobQueueTaskScheduler，它的主要缺点就是对于在集群比较繁忙的情况，低优先级的作业将很难分配到集群的计算资源，这样对于那些低优先级同时又要求一定的响应时间的短作业来说是非常不利的。值得庆幸的是，Hadoop对作业的任务调度设计地相当灵活，即在它的任务调度器配置上开放了一个接口来允许用户根据自己的应用场景自定义一个合适的任务调
2012-05-16 20:25:16
5568
14
原创 Hadoop对计算节点TaskTracker的惩罚机制
在前面的一篇博文中，笔者详细的介绍了JobInProgress是如何给一个TaskTracker节点分配一个Map/Reduce任务的，但在讲述的过程中忽略了一个重要的细节，因为这个细节不是该博文所要讲述的重点，这个细节就是，JobInProgress在正式为TaskTracker节点分配一个任务之前，它都会先检查自己是否应该给该计算节点分配自己的计算任务。当这个计算节点满足要求时，JobInPr
2012-05-10 21:46:23
4209
2
原创 详谈JobInProgress中Map/Reduce任务分配
众所周知，JobTracker节点使用配置的任务调度器TaskScheduler来为某一个具体的TaskTracker节点分配任务，同时这个任务调度器只能决定给该TaskTracker节点分配哪一个Job或者那些Job的任务以及分配多少个任务，但是它却不能决定给当前的TaskTracker节点分配一个Job的具体的哪一个任务。另外，针对一个具体的TaskTracker节点而言，任何一个作业都可以判
2012-05-09 22:15:06
4772
6
转载 Linux proc/%d/stat文件详解
Linux stat文件。也终于弄明白了这一堆堆砌的数字的意思。 [root@localhost ~]# cat /proc/6873/stat 6873 (a.out) R 6723 6873 6723 34819 6873 8388608 77 0 0 0 41958 31 0 0 25 0 3 0 5882654 1409024 56 4294967295 134512640 1
2012-04-18 10:41:09
2191
原创 TaskTracker节点上的HttpServer
在前面的博文：TaskTracker节点的内部设计与实现中，我曾详细的概述了TaskTracker节点中的各个工作组件，而在本文，我将对其内部的Http服务组件展开详细的讨论。 TaskTracker节点的内部Http服务组件主要提供两个功能：1)./logtask，获取某一个Task的执行日志；2)./mapOutput，获取某一个Task的map输出数据。对于用户来说，Http
2012-04-17 21:43:05
1674
6
转载 linux内存中buffer与cache的区别
因为在一次面试中有人提到，在此引用他人整理好的文章做下详细说明，以供学习。============================================================== free 命令相对于top 提供了更简洁的查看系统内存使用情况： $ free total used free shared buffe
2012-04-16 20:54:41
1144
转载 Hadoop平台优化综述
1. 概述随着企业要处理的数据量越来越大，MapReduce思想越来越受到重视。Hadoop是MapReduce的一个开源实现，由于其良好的扩展性和容错性，已得到越来越广泛的应用。Hadoop作为一个基础数据处理平台，虽然其应用价值已得到大家认可，但仍存在很多问题，以下是主要几个：（1） Namenode/jobtracker单点故障。 Hadoop采用的是master/s
2012-04-14 21:15:22
1545
原创 TaskTracker节点上的内存管理器
Hadoop平台的最大优势就是充分地利用了廉价的PC机，这也就使得集群中的工作节点存在一个重要的问题——节点所在的PC机内存资源有限(这里所说的工作节点指的是TaskTracker节点)，执行任务时常常出现内存不够的情况，如：堆溢出错误；同时，该PC机也可能部署了其它集群的工作节点。针对这个问题，Hadoop专门在TaskTracker节点内部设计了一个后台线程——任务内存管理器(TaskMemo
2012-04-10 22:24:00
2321
原创 TaskTracker节点的内部设计与实现
众所周知，Hadoop采用master-slave的架构设计来实现Map-Reduce框架，它的JobTracker节点作为主控节点来管理和调度用户提交的作业，TaskTracker节点作为工作节点来负责执行JobTracker节点分配的Map/Reduce任务。整个集群由一个JobTracker节点和若干个TaskTracker节点组成，当然，JobTracker节点也负责对TaskTracke
2012-04-08 11:28:31
3222
2
原创 Job的任务执行流程之TaskCleanup
任何一个作业在Hadoop集群中执行主要包括四个阶段：setup、map、reduce、cleanup，但在这四个阶段都出现任务实例在TaskTracker节点执行失败的情况。当一个任务实例在TaskTracker节点的JVM中执行时除了成功执行意外，还有可能出现一些异常情况：1).在JVM中执行失败；2).JVM进程被操作系统stop；3).任务实例被JobTracker节点要求kill；这些异
2012-04-05 22:08:13
2976
原创 Job的任务执行流程之JobCleanup阶段
JobTracker节点给TaskTracker节点分配作业任务时是有优先级顺序的，JobTracker节点总是优先分配一个作业的辅助任务，然后在分配作业的正式任务。其中，作业的辅助任务包括：JobSetup、JobCleanup、TaskCleanup三种类型的任务，正式任务包括：Map、Reduce两种任务。当JobTracker节点为一个TaskTracker节点分配了辅助任务的时候就不会为
2012-04-04 20:28:45
2209
原创 Job的任务执行流程之Reduce阶段
JobTracker节点在给每一个TaskTracker节点分配作业的Map/Reduce任务时，可能会根据该TaskTracker节点的实际情况分配多个Map任务，但确顶多只分配一个Reduce任务，尽管此时该TaskTracker节点还有多的Reduce Slot(也就是说TaskTracker节点每一个任务分配请求最多会得到一个Reduce类型的任务)。当然，只有当一个作业的Map任务成功完
2012-03-30 20:53:59
5462
原创 Job的任务执行流程之Map阶段
一个作业的JobSetup任务被一个TaskTracker节点成功执行并报告到JobTracker节点之后，JobTracker节点就会更新对应的作业的状态为RUNNING，之后，这个作业的真正Map任务就可以被JobTracker调度分配给合适的TaskTracker节点来执行了。虽然本文的重点是讲述作业的Map任务在Hadoop集群中的执行过程，但JobTracker节点调度一个作业的Map任
2012-03-26 21:34:11
5993
2
原创 Job的任务执行流程之JobSetup阶段
客户端用户在成功提交Job之后，该Job并不会马上被JobTracker节点调度执行，因为这个Job还没有被初始化，至于JobTracker节点是如何初始化Job的，我在前面已经详细的谈到过。当一个提交的Job在被初始化之后，就可以正式地被JobTracker节点调度执行了，不过，JobTracker节点不会就此开始调度Job的Map/Reduce任务，而是调用该Job的SetupTask。因此，
2012-03-20 20:41:24
3206
转载 HDFS小文件问题及解决方案
1、 概述小文件是指文件size小于HDFS上block大小的文件。这样的文件会给hadoop的扩展性和性能带来严重问题。首先，在HDFS中，任何block，文件或者目录在内存中均以对象的形式存储，每个对象约占150byte，如果有1000 0000个小文件，每个文件占用一个block，则namenode大约需要2G空间。如果存储1亿个文件，则namenode需要20G空间（见参考资料[1]
2012-03-17 20:30:07
1622
原创 JobTracker节点对Task实例状态报告的处理
前面谈到过，每一个TaskTracker节点都要在它向JobTracker节点发送心跳包的时候顺带报告运行在其上的Task的状态信息，这些Task是指正在TaskTracker节点上运行的，或者从上一次报告到现在的时间间隔中完成的或者是失败的任务。JobTracker节点之所以需要收集这些正在执行或者刚完成的任务的状态信息，是因为它要及时掌握各个作业的执行进度，一方面将此报告给用户，一方面还调整作
2012-03-17 18:51:52
3045
原创 JobTracker节点上的作业恢复RecoveryManager
基于目前Hadoop的实现，在很多时候大家都会诟病于它的NameNode/JobTracker单点故障问题，特别是NameNode节点，一旦它发生了不可恢复的故障之后就意味着整个HDFS文件系统不在可用了。对于NameNode节点的单点故障问题，Hadoop目前采取的解决办法是冷备份，就是在HDFS集群中另外开启一个SecondaryNameNode节点，这个节点会定期地对NameNode节点上的
2012-03-14 20:27:00
3060
原创 Job的初始化—EagerTaskInitializationListener
客户端用户在向JobTracker节点成功地提交了一个Job之后，JobTracker节点并不会马上对这个作业进行调度，因为任何作业在被任务调度器TaskSchedule调度之前，都必须先被初始化，这一点笔者曾经在讲解Hadoop的默认调度器——JobQueueTaskSchedule时已经详细地谈到过了。而本文将要集中讨论的是Job是如何被初始化的，同时，Job的初始化又干了哪些事情。
2012-03-13 19:13:37
1466
原创 JobTracker节点后台线程之CompleteJobStatusStore
上一篇博文讲了JobTracker节点会在内存中缓存一部分已完成Jobs状态信息，其实JobTracker节点还可以持久化地保存这些已完成Jobs信息，即将每一个Job的状态信息保存在一个单独的文件中，这个文件可以属于本地文件系统，也可以属于分布式文件系统，如：HDFS。所以，JobTracker节点设计了一个组件——CompleteJobStatusStore，来负责读/写和管理这些作业状态文件
2012-03-12 21:52:15
1289
原创 JobTracker节点后台线程之RetireJobs
Hadoop中的用户作业在其整个生命周期中有5个状态，它们分别是：PREP、RUNNING、SUCCEEDED、FAILED、KILLED，而这其中的SUCCEEDED、FAILED、KILLED三个状态是互斥的，都可看做是Job的完成状态。当用户成功的提交了一个Job之后，这个Job就会进入PREP状态，然后这个Job的map启动任务会被首先交给一个TaskTracker节点来完成，当这个任务被
2012-03-11 20:10:41
2553
原创 JobTracker节点后台线程之ExpireLaunchingTasks
上一篇博文主要讲到了JobTracker节点的后台线程ExpireTrackers，其中谈到了TaskTracker节点要向JobTracker节点定时地发送心跳包，来报告它当前的状态信息(TaskTracker的第一个心跳包同时起到了向JobTracker注册的作用)，而JobTracker对TaskTracker发送过来的心跳包的响应主要内容是分配给该TaskTracker的任务，也就是Tas
2012-03-09 19:50:53
1447
原创 JobTracker节点后台线程之ExpireTrackers
在Hadoop的集群中，所有的TaskTracker在启动之后都会向Master节点JobTracker进行注册，通过TaskTracker的注册，JobTracker节点就知道集群中那些Slave节点可用，即可以给它们分配任务了。但是有时候某些TaskTracker节点会出现意外宕机的情况，而JobTracker节点也必须能及时的捕捉到该TaskTracker节点已经实现，然后不再给该节点分配任
2012-03-07 20:37:58
1402
2
原创 map任务执行中的Spill/Meger/Combiner
记得在以前的博文中已经比较详细地讲述了map在TaskTracker上的执行过程，但那只是我为了简化这种处理流程而假设map任务在理想情况下执行的，这种理想的假设条件是：TaskTracker是内存足够大，而能完全存储该map的任务的输出。很显然，这种情况在理想情况下是不太有可能的，但话又说回来，如果我们在TaskTracker上为Map Slot配置足够的内存，在某些作业的执行过程中上述的理想情
2012-03-05 17:44:46
2089
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人