一、概要 公司近期Storm清洗程序那边反应HDFS会出现偶发性的异常导致数据写不进HDFS,另外一些Spark作业在大规模往HDFS灌数据时客户端会出现各种“all datanode bad..”以及服务端出现各种timeout,值得注意的是出现这样的问题是各个datanode节点的负载并不高!二、故障分析 首先,当我们在HDFS客户端看到各种timeOut...什么wa
一、概述 上篇blog记录了些在用spark-sql时遇到的一些问题,今天继续记录用Spark提供的RDD转化方法开发公司第一期标签分析系统(一部分scala作业逻辑代码后面blog再给大家分享)遇到的一些SPARK作业错误信息。其中有些问题可能一些数据量或者shuffle量比较小的作业时不会遇到的,我们整套标签系统的初级输入数据大概是8T左右,这里也是个参考。(下面的Spark部署模
故障描述 前段时间在测试Spark的RDD转换的lazy特性是发现了一个Spark内部对taskSet在executor的运行分配不均匀问题。先上两张图出现问题时间点的图,大家估计就明白怎么回事了:再看看简单的测试代码:import org.apache.spark._ import org.apache.spark.storage
一、概述 Ha,已经有两个月没有更新blog了。由于近排公司需要引入Spark相关技术,我也是作为技术攻关人员之一,在这段时间使用Spark遇到了挺多问题,跌的坑也比较多,这篇blog主要总结一下这段时间使用Spark遇到的一些问题。二、遇到的"坑"和爬坑思路1、SparkSql on yarn-client模式遇到找不到mysql驱动包问题。解决方案
一、概述 之前写过一篇非常详细的,利用QJM在HDFS2.0部署HA策略的文章,主要说了利用QJM进行HA部署以及其原理(http://zengzhaozheng.blog.51cto.com/8219051/1441170 )。但是,其中没有详细描述HADOOP2.x通过QJM部署HA完毕之后,ActiveNamenode和StandbyN
一、概述 这2个月研究根据用户标签情况对用户的相似度进行评估,其中涉及一些推荐算法知识,在这段时间研究了一遍《推荐算法实践》和《Mahout in action》,在这里主要是根据这两本书的一些思想和自己的一些理解对分布式基于ItemBase的推荐算法进行实现。其中分两部分,第一部分是根据共现矩阵的方式来简单的推算出用户的推荐项,第二部分则是通过传统的
一、概述 Hadoop的版本更新挺快的,已经到了2.4,但是其周边工具的更新速度还是比较慢的,一些旧的周边工具版本对hadoop2.x的兼容性做得还不完善,特别是sqoop。最近,在为hadoop2.2.0找适合的sqoop版本时遇到了很多问题。尝试了多个sqoop1.4.x版本的直接简单粗暴的报版本不兼容问题,其中测了sqoop-1.4.4.bin_
1、概述 Hadoop2.X中的HDFS(Vsersion2.0)相比于Hadoop1.X增加了两个重要功能,HA和Federation。HA解决了Hadoop1.X Namenode中一直存在的单点故障问题,HA策略通过热备的方式为主NameNode提供一个备用者,并且这个备用者的状态一直和主Namenode的元数据保持一致
一、概述 本文将介绍ResourceManager在Yarn中的功能作用,从更细的粒度分析RM内部组成的各个组件功能和他们相互的交互方式。二、ResourceManager的交互协议与基本职能1、ResourceManager交互协议 在整个Yarn框架中主要涉及到7个协议,分别是ApplicationClientProtoc
一、概述 将公司集群升级到Yarn已经有一段时间,自己也对Yarn也研究了一段时间,现在开始记录一下自己在研究Yarn过程中的一些笔记。这篇blog主要主要从大体上说说Yarn的基本架构以及其各个组件的功能。另外,主要将Yarn和MRv1做详细对比,包括Yarn相对于MRv1的各种改进。最后,大概说说Yarn的工作流情况。二、Yarn和MRv1对比(1
一、概述 随着公司集群升级到2.x,hadoop周边的一些工具也进行了版本的更新。这次主要说说sqoop2的升级和部署,其中sqoop1和sqoop2基本框架和用法发生翻天覆地的改变,其对版本的向下兼容做的十分不好,接下来慢慢说,总之各种值得吐槽的地方。二、sqoop2的基本框架,以及部署(1)首先说说sqoop1和sqoop2区别 &nbs
一、概述 公司hadoop集群从1.2.1升级到2.2.0已经有一段时间,这篇blog将总结一下我前段时间在升级至hadoop2.2.0版本过程中遇到的一些问题,以及具体的升级步骤。二、升级过程(1)停掉hadoop1.x集群。(2)备份namenode原数据,即备份dfs.namenode.name.dir指向的路径。以免造成由于升级版本带来的风险。
前段时间遇到了一个很诡异的发生的Map阶段的OOM异常,花了些时间才找到原因,这个简要记录一下。 先看log。 节点一的TaskTracker的log:节点二的TaskTracker的log:节点三的TaskTracker的log:其他节点的TaskTracker中的log都和slave4的一样的:故障分析: OOM是
一、概述 本文将粗略讲述一下Hash算法的概念特性,里边会结合分布式系统负载均衡实例对Hash的一致性做深入探讨。另外,探讨一下Hash算法在海量数据处理方案中的通用性。最后,从源代码出发,具体分析一下Hash算法在MapReduce框架的中的应用。二、Hash算法 Hash可以通过散列函数将任意长度的输入变成固定长度的输出,也可以将不同的输入映
一、概述 本文将讲述Bit-Map算法的相关原理,Bit-Map算法的一些利用场景,例如BitMap解决海量数据寻找重复、判断个别元素是否在海量数据当中等问题.最后说说BitMap的特点已经在各个场景的使用性。二、Bit-Map算法先看看这样的一个场景:给一台普通PC,2G内存,要求处理一个包含40亿个不重复并且没有排过序的无符号的int整数,给出一个整数,问如果快速地判断这个整数是
一、概述 对于RDBMS中的join操作大伙一定非常熟悉,写sql的时候要十分注意细节,稍有差池就会耗时巨久造成很大的性能瓶颈,而在Hadoop中使用MapReduce框架进行join的操作时同样耗时,但是由于hadoop的分布式设计理念的特殊性,因此对于这种join操作同样也具备了一定的特殊性。本文主要对MapReduce框架对表之间的join操作的
一、概述 MapReduce框架对处理结果的输出会根据key值进行默认的排序,这个默认排序可以满足一部分需求,但是也是十分有限的。在我们实际的需求当中,往往有要对reduce输出结果进行二次排序的需求。对于二次排序的实现,网络上已经有很多人分享过了,但是对二次排序的实现的原理以及整个MapReduce框架的处理流程的分析还是有非常大的出入,而且部分分析
一、症状表现 前些时间公司在外省机房部署了一套新hadoop集群,所有机子都装的是centos,跑了一个礼拜莫名其妙的出现了计算节点的心跳间隔变得越来越大,最终导致计算节点挂掉,遇到问题第一时间就是看日志...二、解决思路(1)看NameNode日志,一切正常。(2)看心跳间隔大的节点上的taskTracker日志,转到计算节点一切正常。(3)看心跳间隔大的节点上的da
一、故障症状 最近公司一个集群跑大任务时,datanode日志报DataXceiveServer: Exiting due to:java.lang.OutOfMemoryError: unable to create new native thread异常,然后计算节点上的DataNode直接挂掉。DataNode异常日志截图如下:2014-03-06 03:41:05
一、概述 用hadoop1.x版本已经有一年多了,在使用的过程中发现hadoop1.X的资源管理机制存在诸多缺陷,甚至在这种资源管理机制下会造成服务器资源的严重浪费,负载过高或者过低。本文主要介绍hdaoop1.X的资源管理机制,这种机制的缺点,总结一下自己在这方面遇到的实际问题,最后是自己对改进hadoop资源管理机制的一些想法。二、hadoop 1.x资源管理机制&n
一、小概述 JobTracker端的心跳机制主要任务是处理TaskTracker发送过来的心跳信息,判断TaskTrakcer是否存活、及时让JobTracker获取到各个节点上的资源使用情况和任务运行情况和为TaskTracker下达各种命令等功能。二、心跳处理过程详解 JobTracker端的心跳机制处
1、概述 MapReduce框架中的master/slave心跳机制是整个集群运作的基础,是沟通TaskTracker和JobTracker的桥梁。TaskTracker周期性地调用心跳RPC函数,汇报节点和任务运行状态信息。MapReduce框架中通过心跳机制可以实现给TaskTracker分配任务、使JobTracker能够及时获取各个节点的资源使用情况和任务运行状态
一、概述 上一篇文章中了解了一下JobTracker的部分机制,如作业的恢复、作业权限管理、队列权限管理等。本文将继续探讨有关JobTracker的相关机制,其中主要介绍JobTracker中的各种线程功能以及他们具体的实现流程和jobTracker中的对象映射模型。二、JobTracker中各种线程的作用 JobTacker
(一)概述 我们在上一篇blog已经详细的分析了一个作业从用户输入提交命令到到达JobTracker之前的各个过程。在作业到达JobTracker之后初始化之前,JobTracker会通过submitJob方法,为每个作业都创建一个JobInProgress对象(本文以后简称JIP),用于维护作业的运行时信息以及监控正在运行作业的运行状态和进度。然后检查提交作业的用户是否
(一)概述 本文基于Hadoop1.0.0版本的源代进行分析,研究用户从输入作业提交命令到作业提交到jobTracker的整个流程,其中涉及到的组件JobClient和JobTracker的具体工作细节。(二)具体分析 从源代码来看,hadoop作业的提交过程是比较简单的,主要包含了几个过程:运行提交作业脚本、创建目录、上传作业文件以及产生Input
(一) Map输入数据块的切分算法(基于hadoop源码 1.0.1): (1)分片算法 MapTask的个数据主要取决于InputFormat通过对输入数据调用getSplit()方法分割为若干个分片数据,即InputSplit数。hadoop中切片大小主要由以下几个因素:blockSize:块大小minSize:最小分片大小,由参数ma
实践见真理懂的博客存储之道MIKE老毕的海贼船 在云端的追梦自动化运维竹叶青 的专栏 菜光光的博客美团技术团队BIGBIGBOAT
转载一下一篇不错的关于hadoop小文件的优化文章。英文原文来自:http://blog.cloudera.com/blog/2009/02/the-small-files-problem/ 翻译版本来源:http://nicoleamanda.blog.163.com/blog/static/749961072009111805538447/ 看完这篇文章结合自己之前用过HA
前部分请看:http://zengzhaozheng.blog.51cto.com/8219051/1438204 2、ApplicationMaster管理模块 ApplicationMaster的管理主要是用过ResouceManager内部的3个组件来完成:ApplicationMasterLauncher、AMLivelinessMo
(一)概述 JobTracker是整个MapReduce计算框架的核心组件,它在操作系统中独占一个主服务进程。一个MapReduce应用程序在hadoop中被抽象为一个作业,并且为了实现更好的分布式计算将作业分割为若干个task(分治算法思想)。其中在整个MapReduce框架中JobTracker在充当“管理者”角色,负责作业的控制和系统资源的管理工作,说
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号