1.小文件合并：如果文件有一定的规律或者是在同一个文件夹下，可以采用获取文件夹下所有的文件，通过流进行合并，然后再存到hdfs上。
2.mapreduce的优点：1.离线计算、2.高容错性，一个节点挂了可以将计算转移到另一个节点、3.易扩展，廉价机器随便加。缺点就是做不到实时计算。
3.链接mapreduce有三种方式：迭代式，就是上一个的输出数据为下一个的输入数据，依赖式，一个mapreduce可能依赖于多个mapreduce，线性式，可以链接过多个mapper，一个mapreduce可以有多个mapper，但是只能有一个reduce。
4.Hadoop文件压缩能否支持分片的原理：
在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否支持分割是很重要的。考虑存储在HDFS中的未压缩的文件，其大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块，将此文件用作输入的MapReduce作业会创建1个输人分片（split ,也称为“分块”。对于block，我们统一称为“块”。）每个分片都被作为一个独立map任务的输入单独进行处理。
现在假设。该文件是一个gzip格式的压缩文件，压缩后的大小为1GB。和前面一样，HDFS将此文件存储为16块。然而，针对每一块创建一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独立于其他分块只读取一个分块中的数据。gzip格式使用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始位置，而是其自身与数据流同步。因此，gzip不支持分割(块)机制。
在这种情况下，MapReduce不分割gzip格式的文件，因为它知道输入是gzip压缩格式的(通过文件扩展名得知)，而gzip压缩机制不支持分割机制。这样是以牺牲本地化为代价:一个map任务将处理16个HDFS块。大都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从而导致运行时间变长。
在我们假设的例子中，如果是一个LZO格式的文件，我们会碰到同样的问题，因为基本压缩格式不为reader提供方法使其与流同步。但是，bzip2格式的压缩文件确实提供了块与块之间的同步标记(一个48位的PI近似值)，因此它支持分割机制。
5.Hadoop压缩方式比较：gzip：高压缩率和压缩速度，缺点是不支持split，就是说不支持分片，文件压缩后小于130m的可以考虑；lzo：高压缩率和压缩速度，支持split，但需要自行安装，文件压缩后大于200m的可以考虑，文件越大，优势越明显。snappy：高压缩率和压缩速度，支持split，但需要自行安装，适用mapper或者任务输出压缩；bzip2：需要高压缩率且不要求压缩时间的可以考虑。