快乐程序员的专栏

Impala和Hive野史提到Impala就不得不提Google的Dremel，处理PB级数据规模的基于SQL的交互式、实时数据分析系统。Dremel是Google推出的PaaS数据分析服务BigQuery的后台。Google已经有了MapReduce，为什么还要开发Dremel呢？Dremel/Impala类系统和MapReduce有什么区别呢？Hadoop现在已经成为BigDa

转载地址：http://dj1211.com/?cat=10&paged=2Hadoop 2.0 Datanode 更加细分，将结构分为两个大部分。DataNode相当于一个包装转发器，将请求发送给相应的处理单元。DataNode 分为以下两部分：1、与NameNode汇报的逻辑，block report，heartbeat2、底层与文件

最近在支持业务部门将数据从hadoop0.20.203迁移到hadoop2.4.0的时候，distcp报了几个错误，在这里记录一下：

HDFS Federation是为解决HDFS单点故障而提出的NameNode水平扩展方案，该方案允许HDFS创建多个Namespace以提高集群的扩展性和隔离性。在Federation中新增了block-pool的概念，block-pool就是属于单个Namespace的一组block,每个DataNode为所有的block-pool存储block，可以理解block-pool是一个重新将blo

reduce端缓存数据过多出现FGC，导致reduce生成的数据无法写到hdfs：搜索推荐有一个job，1000多个map，200个reduce，运行到最后只剩一个reduce（10.39.6.130上）的时候，出现以下异常，导致job失败。

我们hadoop2,4集群默认不支持snappy压缩，但是最近有业务方说他们的部分数据是snappy压缩的（这部分数据由另外一个集群提供给他们时就是snappy压缩格式的）想迁移到到我们集群上面来进行计算，但是直接运行时报错：

大牛同事的博客转载一下，方便查阅转载地址：http://dj1211.com/?p=178#more-178一、说明Hadoop 2.x相比较于1.x有了较大的改变，像MapReduce层面架构以及代码基本上是完全重写的，在HDFS层面加入了HA，Federation等特性，代码更加层次化和易读，同时加入的PB初期可能给阅读带来障碍，熟悉之后就没有太大问题了。Pipeline一

hdfs raid从facebook移植过来很久了，包括hadoop0.20.203和hadoop2.4.0版本，但是最近才准备上线hadoop2.4.0版本的hdfs raid，上线前准备在好好测试测试，确保上线顺利，hdfs raid代码分成两部分，一部分是hdfs下面的代码，这部分代码上一次和其他patch一起已经上线，另外一部分是raid自己比较独立的代码，按照之前的计划，后一部分代码准备只部署在RaidNode节点和gateway上面，这样对集群的影响是最小的，不需要重启hadoop进程，在测试R

转载地址：http://www.educity.cn/se/619890.html引言　　Hadoop生态圈的基石有两个，一个是HDFS文件系统，一个是MR编程框架。第一弹中提到应用MR编程框架实现大规模多机联合负载压测场景的方案，则突出了MR的能力，实际上HDFS作为这一切的基础，所起的作用是不容忽视的。　　HDFS分布式文件系统与一般的文件系统，从本质构成上来说并没有太

本文介绍了Facebook公司数据分析系统中的RCFile存储结构，该结构集行存储和列存储的优点于一身，在MapReduce环境下的大规模数据分析中扮演重要角色。Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）会议上介绍了数据仓库Hive。Hive存储海量数据在Hadoop系统中，提供了一套类数据库

Hive的三种文件格式：TEXTFILE、SEQUENCEFILE、RCFILE中，TEXTFILE和SEQUENCEFILE的存储格式都是基于行存储的，RCFILE是基于行列混合的思想，先按行把数据划分成N个row group，在row group中对每个列分别进行存储。另：Hive能支持自定义格式，详情见：Hive文件存储格式基于HDFS的行存储具备快速数据加载和动态负载的高适应能力，

在测试环境和线上运行相同的hql，而且表对应的数据量都是95G左右，但是发现在测试环境和线上的counter：HDFS RAED不一致，而且差一个数量级，线上只有8G左右，而测试环境达到95G，基本上就是全文件扫描，没有体现出RCFile的优势。

今天在帮业务方优化mapreduce作业时遇到一个用字符串拼接的问题。

由于之前远程桌面不好使，集群出现了missing block的时候没法登陆远程桌面查看是那些节点由于重启导致DataNode进程挂掉。同时简单的用命令hdfs dfsadmin -report查看又不方便，信息量太多，以下是一个用sed和awk实现的简单的脚本：

转载地址：http://dj1211.com/?p=51#more-51相对于1.x版本的Hadoop，2.x版本的Hadoop采用了Protocol Buffer作为序列化反序列化工具，以及RPC通讯工具。这样当我们对Hadoop源码进行修改之前，就需要了解Hadoop 2.x的代码结构和修改方法。    几个结构，以DatanodeProtocol举列子：    Datan

之前有一段时间，我们的hadoop2.4集群压力非常大，导致提交的job出现大量的reduce被kill掉，相同的job运行时间比在hadoop0.20.203上面长了很多，这个问题其实是reduce 任务启动时机的问题，由于yarn中没有map slot和reduce slot的概念，且ResourceManager也不知道map task和reduce task之间的依赖关系，因此MRAppMaster自己需要设计资源申请策略以防止因reduce task过早启动照成资源利用率低下和map task因分

文件租约就是将操作的文件和操作它的客户端进行绑定，若文件不存在一个租约，则说明该文件当前没有被任何客户端写，否则，就表示它正在被该文件租约中 的客户端holder写。这中间可能会发生一些意想不到的异常情况，比如正在对某个文件进行写操作的客户端突然宕机了，那么与这个文件相关的租约会迟迟得 不到客户端的续租而过期，那么NameNode会释放这些过期的租约，好让其它的客户端能及时的操作该租约对应文件。

1、机器IP及root用户     10.28.168.157root/cdyjs     10.28.168.158 root/cdyjs     10.28.168.159 root/cdyjshosts:     10.28.168.157 nn nn.360buy.com n1     10.28.168.158 slave1 salve1.360buy.com n

原文见：http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/

硬件配置：节点Iposcpu内存磁盘Jn-4810.31.72.48RH5.7E5620*2  16核24GSSD40G*2+2T*12master-4110.31.72.41RH5.8

YARN RM failover机制RM(ResourceManager)每次在启动之前都会进行初始化并执行一次recovery操作，然后才启动RM，对外提供服务。 RM启动流程如下图：RM启动流程图RM中的各种服务包括：(1)、ContainerAllocationExpirer：监控Containter是否到期。(2)、AmLivelinessMonitor：监控A

YARN是Hadoop新版中的资源控制框架。本文旨在深入剖析ResourceManager的调度器，探讨三种调度器的设计侧重，最后给出一些配置建议和参数解释。本文分析基于CDH4.2.1。调度器这个部分目前还在快速变化之中。例如，CPU资源分配等特性在不就的将来就会加入。为了方便查阅源代码，原代码位置使用[类名:行号]方式表示。名词解释：ResourceManage

HDFS ACLs测试!! Hadoop从2.4开始⽀持HDFS层⾯的ACLs，新的ACLs功能包含了新的api，使⽤⽅法以及使⽤场景，本测试探查ACLs与我们原先基于主机与组的ACLs的结合，以及ACLs使⽤⽅法等。!⼀、配置增加!! 为了使⽤ACLs，需要在NameNode增加⼀个配置选项，为:!!   !!!     dfs.namenode.acls.enabled

以下是分析ads的单⾏行数据量超过1000万时,map任务出现600s time out的问题:

YARN中实现了多个状态机对象，包括ResourceManager中的RMAppImpl、RMApp-AttemptImpl、RMContainerImpl和RMNodeImpl，NodeManager中的ApplicationImpl、ContainerImpl和LocalizedResource，MRAppMaster中的JobImpl、TaskImpl和TaskAttemptImpl等。为了

在hadoop2.0中，datanode数据副本存放磁盘选择策略有两种方式：第一种是沿用hadoop1.0的磁盘目录轮询方式，实现类：RoundRobinVolumeChoosingPolicy.java第二种是选择可用空间足够多的磁盘方式存储，实现类：AvailableSpaceVolumeChoosingPolicy.java

hadoop2.4生产集群已经运行一段时间了。由于大量的hadoop1.0上面的应用不断迁移过来，刚开始事hdfs这边还没有出现多少问题，随着时间的推移，最近发现个别的datanode节点上面的磁盘空间剩余严重不足，既集群数据存储严重不均衡，很多DN节点分明还有很多存储空间，而个别DN节点存储空间则出现严重不足的情况。后来经过分析，发现这些空间严重不足的节点上面，都运行了distcp作业的map任务，distcp是一个纯粹拷贝数据的job，一结合hdfs数据副本分配策略一分析，终于找到了问题所在：原来是因为

在这篇博客中，主要介绍了Yarn对MRv1的改进，以及Yarn简单的内存配置和Yarn的资源抽象container。我么知道MRv1存在的主要问题是：在运行时，JobTracker既负责资源管理又负责任务调度，这导致了它的扩展性、资源利用率低等问题。之所以存在这样的问题，是与其最初的设计有关，如下图：从上图可以看到，MRv1是围绕着MapReduce进行，并没有过多地考虑以后出现的

1 概述    为了增大并发性，Yarn采用事件驱动的并发模型，将各种处理逻辑抽象成事件和调度器，将事件的处理过程用状态机表示。什么是状态机？    如果一个对象，其构成为若干个状态，以及触发这些状态发生相互转移的事件，那么此对象称之为状态机。    处理请求作为某种事件发送到系统中，由一个中央调度器传递给对应的事件调度器，进而对事件进行处理，处理完成之后再次发送给中央调度

在测试环境准备测试FastCopy，因为之前只有一个NS，准备增加一个NS也便于测试，一切都准备妥当之后，重启DN，但是DN死活连接不上新的NN，报以下错误：