hadoop学习;自己定义Input/OutputFormat;类引用mapreduce.mapper;三种模式

hadoop切割与读取输入文件的方式被定义在InputFormat接口的一个实现中。TextInputFormat是默认的实现,当你想要一次获取一行内容作为输入数据时又没有确定的键。从TextInputFormat返回的键为每行的字节偏移量,但眼下没看到用过

曾经在mapper中曾使用LongWritable(键)和Text(值),在TextInputFormat中,由于键是字节偏移量。能够是LongWritable类型,而当使用KeyValueTextInputFormat时,第一个分隔符前后都是Text类型,所以你必须改动mapper的实现以及map()方法来适应这个新键类型



一个MapReduce的输入不一定是外部数据,经常是一些其它MapReduce的输出数据,还能够自己定义输出格式,默认的输出格式与KeyValueTextInputFormat能够读取的的数据格式保持一致(记录中的每行均为一个由制表符分隔的键和值),只是Hadoop提供了更加有效的二进制压缩文件格式。称为序列文件,这个序列文件为hadoop处理做了优化。当连接多个MapReduce作业时,它是首选,读取序列文件的类为SequenceFileInputFormat,序列文件的键和值对象能够由用户自己定义。输出和输入类型必须匹配

自己定义InputFormat,实现两个方法:

getSplit()确定全部用于输入数据的文件,并将输入数据切割为输入分片,每一个map任务处理一个分片

getRecordReader()循环提取给定分片中的记录,并解析每一个记录为提前定义类型的键和值

在实际情况中一个分片总是以数据块为大小,在HDFS中默认一个块为64MB

FileInputFormat中isSplitable()方法。检查你能否够将给定文件分片,默认返回为true。有时你可能想要一个文件为其自身的分块,这时能够设定返回为false

LineRecordReader实现RecordReader,基于实现的封装,大多数操作存放在next中

我们通过扩展FileInputFormat生成我们的InputFormat类,并实现一个factory方法来返回recordreader

除了类的构建之外,TimeUrlRecordReader会在RecordReader实现6种方法,它主要在KeyValueInputFormat之外的一个封装,但吧记录的Text类型转换为URLWritable

输出数据到文件时,使用的是OutputFormat。由于每一个reducer仅需将它的输出写入自己的文件里,输出不须要分片。

输出文件放在一个公用文件夹中。通常命名为part-nnnnn。这里的nnnnn是reducer的分区ID。RecordWriter对输出结果进行格式化。而RecordReader对输入格式进行解析

NullOutPutFormat简单的实现了OutputFormat,无输出。并不须要继承FileOutputFormat。更基本的是OutputFormat(InputFormat)处理的是数据库。并不是文件

个性化输出能够在继承了FileOutputFormat的类中的封装的继承RecordReader类中的write()方法。假设不仅仅想输出到文件里


jar -xvf  ../example.jar  解压jar包

向hdfs迁移本地文件能够,程序中地址别写错了,别写成其它不关联的机子上的


在eclipse中写完程序,打成jar包。放到hadoop目录下,执行hadoop指令能够查看结果

若运用第三方插件fatjar,将mapreduce的jar包和jedis的jar包整合到一起放入hadoop。这样不须要改动manifest配置信息


我们导出jar包(不用包括hadoop的jar包)放入hadoop目录下,执行hadoop命令,类用长名

package com.kane.hdfs;


import java.io.IOException;


import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.BlockLocation;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.hdfs.DistributedFileSystem;
import org.apache.hadoop.hdfs.protocol.DatanodeInfo;


public class FindFileOnHDFS {


/**
* @param args
* @throws IOException 
*/
public static void main(String[] args) throws IOException {
// TODO Auto-generated method stub
getHDFSNodes();
getFileLocal();
}
public static void getHDFSNodes() throws IOException {
//HDFS集群节点数
Configuration conf=new  Configuration();
FileSystem fs=FileSystem.get(conf);
//获取分布式文件系统
DistributedFileSystem hdfs=(DistributedFileSystem)fs;
//获取全部的节点数
DatanodeInfo[] dataNodeStats=hdfs.getDataNodeStats();
//循环打印
for (int i = 0; i < dataNodeStats.length; i++) {
System.out.println("DataNode_"+i+"_Name:"+dataNodeStats[i].getHostName());
}
}
/**
* 查找某个文件在HDFS集群的位置
* @throws IOException 
*/
public static void getFileLocal() throws IOException {
Configuration conf=new Configuration();
FileSystem hdfs=FileSystem.get(conf);

Path fPath=new Path("user/hadoop/20120722");//word.txt
//获取文件系统里面的文件信息
FileStatus fileStatus=hdfs.getFileStatus(fPath);
//获取文件的块信息
BlockLocation[] blkLocations=hdfs.getFileBlockLocations(fileStatus, 0, 1000);
int blockLen=blkLocations.length;
for (int i = 0; i < blockLen; i++) {
String[] hosts=blkLocations[i].getHosts();
System.out.println("block_"+i+"_location"+hosts[0]);
}
}


}



 搭建三种模式,一般默认单机模式:不使用HDFS,也不载入不论什么守护进程,主要用于开发调试

伪分布模式在“单节点集群”上执行hadoop,当中全部守护进程都在一台机子上,添加了代码调试功能。同意检查内存使用情况,HDFS输入输出。以及其它的守护进程交互

全分布模式。真实情况用这样的模式。强调分布式存储和分布式计算,明白声明了NameNode和JobTracker守护进程所在的主机名。

增大了HDFS备份參数发挥分布式存储优势

原文地址:https://www.cnblogs.com/lcchuguo/p/5065527.html