优化了du性能的hadoop 2.8.1

性能提升1000+倍。 原理是使用df 代替du, wget https://www.strongd.net/dl/hadoop-common-2.8.1.jar -C /usr/local/hadoop-2.8.1/share/hadoop/common/   wget https://www.strongd.net/dl/mydu -C /usr/bin/ chmod a+x /usr/bin/mydu   然后重启hadoop就可以了。

搭建 Hadoop 伪分布式环境

软硬件环境 CentOS 7.2 64位 OpenJDK-1.7 Hadoop-2.7 关于本教程的说明 云实验室云主机自动使用root账户登录系统,因此本教程中所有的操作都是以root用户来执行的。若要在自己的云主机上进行本教程的实验,为了系统安全,建议新建一个账户登录后再进行后续操作。 安装 SSH 客户端 任务时间:1min ~ 5min 安装SSH 安装SSH: sudo yum install openssh-clients openssh-server 安装完成后,可以使用下面命令进行测试: ssh localhost 输入root账户的密码,如果可以正常登录,则说明SSH安装没有问题。测试正常后使用exit命令退出ssh。 安装 JAVA 环境 任务时间:5min ~ 10min 安装 JDK 使用yum来安装1.7版本OpenJDK: sudo yum install java-1.7.0-openjdk java-1.7.0-openjdk-devel 安装完成后,输入java和javac命令,如果能输出对应的命令帮助,则表明jdk已正确安装。 配置 JAVA 环境变量 执行命令: 编辑 ~/.bashrc,在结尾追加: export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk 保存文件后执行下面命令使JAVA_HOME环境变量生效: source ~/.bashrc 为了检测系统中JAVA环境是否已经正确配置并生效,可以分别执行下面命令: java -version $JAVA_HOME/bin/java … Continue reading "搭建 Hadoop 伪分布式环境"

Facebook针对hbase的优化方案分析

使用hbase的目的是为了海量数据的随机读写,但是在实际使用中却发现针对随机读的优化和gc是一个很大的问题,而且hbase的数据是存储在Hdfs,而Hdfs是面向流失数据访问进行设计的,就难免带来效率的下降。下面介绍一下Facebook Message系统在HBase online storage场景下的一个案例(《Apache Hadoop Goes Realtime at Facebook》, SIGMOD 2011),最近他们在存储领域顶级会议FAST2014上发表了一篇论文《Analysis of HDFS Under HBase: A Facebook Messages Case Study》分析了他们在使用HBase中遇到的一些问题和解决方案。该论文首先讲了Facebook的分析方法包括tracing/analysis/simulation,FM系统的架构和文件与数据构成等,接下来开始分析FM系统在性能方面的一些问题,并提出了解决方案。 FM系统的主要读写I/O负载 Figure 2描述了每一层的I/O构成,解释了在FM系统对外请求中读占主导,但是由于logging/compaction/replication/caching导致写被严重放大。 HBase的设计是分层结构的,依次是DB逻辑层、FS逻辑层、底层系统逻辑层。DB逻辑层提供的对外使用的接口主要操作是put()和get()请求,这两个操作的数据都要写到HDFS上,其中读写比99/1(Figure 2中第一条)。 由于DB逻辑层内部为了保证数据的持久性会做logging,为了读取的高效率会做compaction,而且这两个操作都是写占主导的,所以把这两个操作(overheads)加上之后读写比为79/21(Figure 2中第二条)。 相当于调用put()操作向HBase写入的数据都是写入了两份:一份写入内存Memstore然后flush到HFile/HDFS,另一份通过logging直接写HLog/HDFS。Memstore中积累一定量的数据才会写HFile,这使得压缩比会比较高,而写HLog要求实时append record导致压缩比(HBASE-8155)相对较低,导致写被放大4倍以上。    Compaction操作就是读取小的HFile到内存merge-sorting成大的HFile然后输出,加速HBase读操作。Compaction操作导致写被放大17倍以上,说明每部分数据平均被重复读写了17次,所以对于内容不变的大附件是不适合存储在HBase中的。由于读操作在FM业务中占主要比例,所以加速读操作对业务非常有帮助,所以compaction策略会比较激进。 HBase的数据reliable是靠HDFS层保证的,即HDFS的三备份策略。那么也就是上述对HDFS的写操作都会被转化成三倍的local file I/O和两倍的网络I/O。这样使得在本地磁盘I/O中衡量读写比变成了55/45。 然而由于对本地磁盘的读操作请求的数据会被本地OS的cache缓存,那么真正的读操作是由于cache miss引起的读操作的I/O量,这样使得读写比变成了36/64,写被进一步放大。    另外Figure 3从I/O数据传输中真正业务需求的数据大小来看各个层次、各个操作引起的I/O变化。除了上面说的,还发现了整个系统最终存储在磁盘上有大量的cold data(占2/3),所以需要支持hot/cold数据分开存储。 总的来说,HBase stack的logging/compaction/replication/caching会放大写I/O,导致业务逻辑上读为主导的HBase系统在地层实际磁盘I/O中写占据了主导。 FM系统的主要文件类型和大小   FM系统的几种文件类型如Table 2所示,这个是纯业务的逻辑描述。在HBase的每个RegionServer上的每个column family对应一个或者多个HFile文件。FM系统中有8个column family,由于每个column family存储的数据的类型和大小不一样,使得每个column family的读写比是不一样的。而且很少数据是读写都会请求的,所以cache all writes可能作用不大(Figure 4)。 对于每个column family的文件,90%是小于15M的。但是少量的特别大的文件会拉高column family的平均文件大小。例如MessageMeta这个column family的平均文件大小是293M。从这些文件的生命周期来看,大部分FM的数据存储在large,long-lived files,然而大部分文件却是small, … Continue reading "Facebook针对hbase的优化方案分析"

Getting Started With Hubot

You will need node.js and npm. Joyent has an excellent blog post on how to get those installed, so we’ll omit those details here. Once node and npm are ready, we can install the hubot generator: % npm install -g yo generator-hubot This will give us the hubot yeoman generator. Now we can make a … Continue reading "Getting Started With Hubot"

用bash解决hadoop的磁盘空间检查性能问题

项目使用的hadoop已经存放了3000W+的文件, 为了节省成本,当时抢建平台时,使用了组装服务器+普通硬盘 hadoop每次做du操作都非常耗时,于是把hadoop代码改了一个 使用一个bash脚本替代原来du操作。 bash: #/bin/sh mydf=$(df $2 | grep -vE ‘^Filesystem|tmpfs|cdrom’ | awk ‘{ print $3 }’) echo -e “$mydf\t$2” java:hadoop\src\core\org\apache\hadoop\fs\DU.java:168行的toString()及getExecString()方法 public String toString() { return “mydu -sk ” + dirPath +”\n” + used + “\t” + dirPath; } protected String[] getExecString() { return new String[] {“mydu”, “-sk”, dirPath}; } 改造后,原来的du操作其他不耗时。 只是存在统计不准确的问题,不过并不影响hadoop运作。

Hadoop快速入门

目的 这篇文档的目的是帮助你快速完成单机上的Hadoop安装与使用以便你对Hadoop分布式文件系统(HDFS)和Map-Reduce框架有所体会,比如在HDFS上运行示例程序或简单作业等。 先决条件 支持平台 GNU/Linux是产品开发和运行的平台。 Hadoop已在有2000个节点的GNU/Linux主机组成的集群系统上得到验证。 Win32平台是作为开发平台支持的。由于分布式操作尚未在Win32平台上充分测试,所以还不作为一个生产平台被支持。 所需软件 Linux和Windows所需软件包括: JavaTM1.5.x,必须安装,建议选择Sun公司发行的Java版本。 ssh 必须安装并且保证 sshd一直运行,以便用Hadoop 脚本管理远端Hadoop守护进程。 Windows下的附加软件需求 Cygwin – 提供上述软件之外的shell支持。 安装软件 如果你的集群尚未安装所需软件,你得首先安装它们。 以Ubuntu Linux为例: $ sudo apt-get install ssh $ sudo apt-get install rsync 在Windows平台上,如果安装cygwin时未安装全部所需软件,则需启动cyqwin安装管理器安装如下软件包: openssh – Net 类 下载 为了获取Hadoop的发行版,从Apache的某个镜像服务器上下载最近的 稳定发行版。 运行Hadoop集群的准备工作 解压所下载的Hadoop发行版。编辑 conf/hadoop-env.sh文件,至少需要将JAVA_HOME设置为Java安装根路径。 尝试如下命令: $ bin/hadoop 将会显示hadoop 脚本的使用文档。 现在你可以用以下三种支持的模式中的一种启动Hadoop集群: 单机模式 伪分布式模式 完全分布式模式 单机模式的操作方法 默认情况下,Hadoop被配置成以非分布式模式运行的一个独立Java进程。这对调试非常有帮助。 下面的实例将已解压的 conf 目录拷贝作为输入,查找并显示匹配给定正则表达式的条目。输出写入到指定的output目录。 $ mkdir input $ … Continue reading "Hadoop快速入门"