hadoop的压缩解压缩,reduce端join,map端join

hadoop的压缩解压缩

    hadoop对于常见的几种压缩算法对于我们的mapreduce都是内置支持,不需要我们关心.经过map之后,数据会产生输出经过shuffle,这个时候的shuffle过程特别需要消耗网络资源,它传输的数据量越少,对作业的运行时间越有意义,在这种情况下,我们可以对输出进行一个压缩.输出压缩之后,reducer就要接收,然后再解压,reducer处理完之后也需要做输出,也可以做压缩.对于我们程序而言,输入的压缩是我们原来的,不是程序决定的,因为输入源就是这样子,reduce输出的压缩这个事可以决定的.
    map输出压缩以后,在往reduce这块传输的过程中,传输数据量就少了.如果map输出量很大,可以采用map端的输出压缩,对我们的整个输出作业是有好处的,
选择压缩算法关注点:
      1.是否支持分隔.如果不支持分隔,那么整个 一个输入文件就会作为数据的一个输入源处理.不能分隔的意思就是一个T的数据交给一个map处理.
      2.压缩解压缩速度如何.通常情况下,hadoop操作的都是磁盘/IO密集型操作.运算的瓶颈一般都是在磁盘IO上,CPU这块利用率是不高的,由算法决定的,mapreducer这种算法一般都没有什么递归这种操作.CPU占用其实不高,并且mapreduce适合处理海量数据,所以数据量一般都是超大,就需要读磁盘,所以我们的mapareduce一般都是磁盘IO密集型的这种操作.
      MapReduce的输出进行压缩:
      //map端输出进行压缩
      conf.setBoolean("mapred.compress.map,output",true);
      //reduce端进行压缩
      conf.setBoolean("mapred.output.compress",true);
      //reduce端输出压缩使用的类:
      conf.setClass("mapred.output.compression.codec".GzipCodec.class,CompressionCodec.class);

reduce端join:

    数据处理过程中,处理的文件不是来自于一批文件,可能来自于多批文件,这两批文件之间是有联系的,这时候就涉及join
    在map阶段,map函数同时读取两个文件File1和File2,为了区分两种来源的key/value数据对,对每一条数据打个标签(tag),比如tag=0表示来自于file1,tag=2的来自于file2.即map阶段的主要任务就是对不同文件中的数据打标签.
    在reduce阶段,reduce函数就会获取key相同的来与file1和file2文件的value list,然后对于同一个key,对于file1和file2中的数据进行join(笛卡尔积).即:reduce 进行实际的连接操作.
      当map读取原始文件时,能不能区分出是file1还是file2?
      能. FileSplit fileSplit = (FileSplit)context.getInputSplit();
         String path= fileSplit.getPath().toString();
      map输出的时候,如何打标记?
      当我们判断出是file1时,对v2做标记,让v2的值是#zhangsan 如果是file2时,让v2的值是*45

map端join:

    之所以存在reduce端的join,是因为map阶段不能获取所有需要的join字段,即同一个key对应的字段可能位于不同map中,reduce端join是非常低效的,因为shuffle阶段要进行大量的数据传输.
    reduce端虽然是低效的,但并不能完全代替reduce端,因为map端适应于特定的场景,
    map端的join是针对以下场景进行的优化:

      在两个连接的表中,有一个表非常大,而另一个表非常小,以至于小表可以直接放在内存中.这样我们就可以.
    将小表的记录放在map端的内存中,只需要在map端读取进来的文件是大表就可以了,在map端对这个记录进行join操作.两张表的信息都读进去,数据就又混了,我们的用户信息表文件不大,可以单独划分一个文件的路径,不使用map读,可以使用在setup(..)中,使用FileSystem把记录读进来,解析出来的数据放到全局变量Map<Integer,String>,然后在map中读取进来的都是销售金额,就可以根据金额表的id去map中去找数据,做join操作.
    适用场景:

      小表可以完全读取到内存中,两个在内存中装不小的大表,不适合map端join.
    在一个TaskTracker中可以运行多个map任务,每个map任务都是一个java进程,
    map阶段通过setup()读取HDFS中的数据这种做法没有任何问题,但是如果有很多的map,意味着每一次都要建立setup()读取,每一次都要从HDFS中读取,建立很多文件,这样的话就有点浪费了.
    如果每个map从HDFS中读取相同的小表内容,就有点浪费了,使用DistributedCache,小表内容可以加载在TaskTracker的linux磁盘上.每个map运行时只需要从linux磁盘加载数据就行了,不必每次从HDFS加载.
    (1),作业提交之前,用户使用静态方法DistributedCache.addCacheFile()指定要复制的文件,它的参数是文件的URI.JobTracker在作业启动之前会获取这个URI列表,并将相应的文件拷贝到各个TaskTracker的本地磁盘上.
    (2),在Mapper类的setup(),用户使用DistributedCache.getLocalCacheFiles()方法获取文件目录,读取文件内容,缓存到内存中就可以加载数据了.
写入磁盘的过程是在运行之前执行的.

时间: 2024-10-12 13:41:05

hadoop的压缩解压缩,reduce端join,map端join的相关文章

hadoop编程小技巧(1)---map端聚合

测试hadoop版本:2.4 Map端聚合的应用场景:当我们只关心所有数据中的部分数据时,并且数据可以放入内存中. 使用的好处:可以大大减小网络数据的传输量,提高效率: 一般编程思路:在Mapper的map函数中读入所有数据,然后添加到一个List(队列)中,然后在cleanup函数中对list进行处理,输出我们关系的少量数据. 实例: 在map函数中使用空格分隔每行数据,然后把每个单词添加到一个堆栈中,在cleanup函数中输出堆栈中单词次数比较多的单词以及次数: package fz.inm

hadoop map端join

map端的联结比reduce端的联结实现起来复杂,而且限制也多,一般我们将小表置于内存中, 对于大表的一个纪录我们在内存中查找即可. 改例子摘自hadoop基础教程, 我们实现sales和accounts的联结, 其中sales记录的顾客的销售信息,accounts纪录的是用户的账户信息,我们的目的是统计每个用户消费的次数和消费总额. 数据如下: sales.txt 002 12.29   2004-07-02 004 13.42   2005-12-20 003 499.99  2010-12

Hadoop on Mac with IntelliJ IDEA - 10 陆喜恒. Hadoop实战(第2版)6.4.1(Shuffle和排序)Map端 内容整理

下午对着源码看陆喜恒. Hadoop实战(第2版)6.4.1  (Shuffle和排序)Map端,发现与Hadoop 1.2.1的源码有些出入.下面作个简单的记录,方便起见,引用自书本的语句都用斜体表示. 依书本,从MapTask.java开始.这个类有多个内部类: 从书的描述可知,collect()并不在MapTask类,而在MapOutputBuffer类,其函数功能是 1.定义输出内存缓冲区为环形结构2.定义输出内存缓冲区内容到磁盘的操作 在collect函数中将缓冲区的内容写出时会调用s

hadoop核心逻辑shuffle代码分析-map端

首先要推荐一下:http://www.alidata.org/archives/1470 阿里的大牛在上面的文章中比较详细的介绍了shuffle过程中mapper和reduce的每个过程,强烈推荐先读一下. 不过,上文没有写明一些实现的细节,比如:spill的过程,mapper生成文件的 partition是怎么做的等等,相信有很多人跟我一样在看了上面的文章后还是有很多疑问,我也是带着疑问花了很久的看了cdh4.1.0版本 shuffle的逻辑,整理成本文,为以后回顾所用. 首先用一张图展示下m

Hadoop学习笔记—10.Reduce阶段中的Shuffle过程

一.回顾Reduce阶段三大步凑 在第四篇博文<初识MapReduce>中,我们认识了MapReduce的八大步凑,其中在Reduce阶段总共三个步凑,如下图所示: 其中,Step2.1就是一个Shuffle操作,它针对多个map任务的输出按照不同的分区(Partition)通过网络复制到不同的reduce任务节点上,这个过程就称作为Shuffle. PS:Hadoop的shuffle过程就是从map端输出到reduce端输入之间的过程,这一段应该是Hadoop中最核心的部分,因为涉及到Had

大数据技术之压缩解压缩案例

7.10 压缩/解压缩案例 7.10.1 对数据流的压缩和解压缩 CompressionCodec有两个方法可以用于轻松地压缩或解压缩数据.要想对正在被写入一个输出流的数据进行压缩,我们可以使用createOutputStream(OutputStreamout)方法创建一个CompressionOutputStream,将其以压缩格式写入底层的流.相反,要想对从输入流读取而来的数据进行解压缩,则调用createInputStream(InputStreamin)函数,从而获得一个Compres

hadoop对于压缩文件的支持及算法优缺点

hadoop对于压缩文件的支持及算法优缺点   hadoop对于压缩格式的是透明识别,我们的MapReduce任务的执行是透明的,hadoop能够自动为我们 将压缩的文件解压,而不用我们去关心. 如果我们压缩的文件有相应压缩格式的扩展名(比如lzo,gz,bzip2等),hadoop就会根据扩展名去选择解码器解压. 压缩格式 工具 算法 文件扩展名 多文件 可分割性 DEFLATE 无 DEFLATE .deflate 不 不 gzip gzip DEFLATE .gz 不 不 ZIP zip

Hadoop2.4.1 MapReduce通过Map端shuffle(Combiner)完成数据去重

package com.bank.service; import java.io.IOException; import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.conf.Configured;import org.apache.hadoop.fs.Path;import org.apache.hadoop.io.LongWritable;import org.apache.hadoop.io.NullWrita

2016-8-28 压缩解压缩及归档 while脚本

文件管理命令――压缩解压缩及归档基本工具 压缩.解压缩命令 压缩格式:gz, bz2, xz, zip, Z 压缩算法:算法不同,压缩比也会不同: 早期    压缩:        compress(压缩比很小): FILENAME.Z ―― 压缩后的文件名    解压:        uncompress gzip.bzip2.xz只能压缩文件,并且默认压缩完成后删除源文件,zip可以压缩目录 gzip: .gz    gzip /PATH/TO/SOMEFILE:压缩完成后会删除原文件