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备份參数发挥分布式存储优势
