Hadoop技术细节遗珠

最新推荐文章于 2019-12-23 22:33:37 发布

剑儒

最新推荐文章于 2019-12-23 22:33:37 发布

阅读量771

点赞数 1

分类专栏： BigData_ 软件利器文章标签： mapreduce hadoop

本文链接：https://blog.csdn.net/suixinsuoyuwjm/article/details/22984187

版权

BigData_ 软件利器专栏收录该内容

17 篇文章 0 订阅

订阅专栏

细节1：正确输出中文！（Hadoop正确输出UTF-8格式的中文，而不支持GBK格式的中文）

曾经有次需要输出中文，但是在Hadoop中打印出来的却是乱码。一开始以为Hadoop的设计者当初设计Hadoop时就不支持输出中文，后来通过查看TextOutputFormat的源代码，发现Hadoop仅仅是不支持以GBK格式输出中文罢了。

Hadoop默认的输出均继承自FileOutputFormat，它有两个常用子类：一个是基于二进制流的输出；另一个是基于文本的输出TextOutputFormat。（源代码如下）

publicclass TextOutputFormat<K, V> extends FileOutputFormat<K, V> {

protected static classLineRecordWriter<K, V> implements RecordWriter<K, V> {

privatestatic final String utf8 = “UTF-8″;//这里被写死成了UTF-8格式
     private static final byte[] newline;//定义静态字节数组
    static {//静态代码块，初始化静态字节数组
          try {
                         newline= “\n”.getBytes(utf8);//字节数组按照UTF-8编码方式
          }catch (UnsupportedEncodingException uee) {
                throw new IllegalArgumentException(“Can’tfind ” + utf8 + ” encoding”);
          }
      }
    …//LineRecordWriter构造函数，它将最终结果写成纯文件文件
      publicLineRecordWriter(DataOutputStream out, String keyValueSeparator) {
          this.out= out;
          try {//keyValueSeparator代表键值对的分隔符
              this.keyValueSeparator =keyValueSeparator.getBytes(utf8);
          }catch (UnsupportedEncodingException uee) {
              throw new IllegalArgumentException(“Can’tfind ” + utf8 + ” encoding”);
          }
      }
     …
     private void writeObject(Object o) throwsIOException {
          if (oinstanceof Text) {
              Text to = (Text) o;
              out.write(to.getBytes(), 0,to.getLength());//这里也需要修改
          } else{
              out.write(o.toString().getBytes(utf8));
          }
    }
   …
}

}

通过阅读TextOutputFormat源代码，发现Hadoop默认的输出被写死成为UTF-8格式，因此若想正确解析中文，需要将字符集设置为UTF-8格式（省力的办法）

而如果想让Hadoop可以正确输出编码格式为GBK的中文，则需要重新定义FileOutputFormat的子类（GBKTextOutputFormat），并将其编码格式设置为GBK！
public class GBKTextOutputFormat<K, V> extends FileOutputFormat<K,V> {//自定义子类
    protected static classLineRecordWriter<K, V> implements RecordWriter<K, V> {
         private static final String gbk = “gbk”; //写成gbk即可
        private static final byte[] newline;
         static {
             try{
                 newline = “\n”.getBytes(gbk);
             }catch (UnsupportedEncodingException uee) {
                 throw new IllegalArgumentException(“Can’tfind ” + gbk + ” encoding”);
          }
    }
   …
    public LineRecordWriter(DataOutputStream out, StringkeyValueSeparator) {
          this.out= out;
         try {
              this.keyValueSeparator =keyValueSeparator.getBytes(gbk);
          }catch (UnsupportedEncodingException uee) {
              throw new IllegalArgumentException(“Can’tfind ” + gbk + ” encoding”);
          }
    }
…
    private void writeObject(Object o) throws IOException {
        if (oinstanceof Text) {
             out.write(o.toString().getBytes(gbk));
        }
    }
…
}

在需要使用TextOutputFormat的地方用GBKTextOutputFormat代替！即在MapReduce的作业配置时，conf.setOutputFormat(GBKTextOutputFormat);即可

简单代码解决输入数据是GBK编码问题：

String line=newString(value.getBytes(),0,value.getLength(),"GBK"); //value是Text类型。

其实Stringline = value.toString();之所以会将GBK编码的输入变成乱码，一个关键因素是Text这个Writable类型造成的。Text是一种UTF-8格式的Writable，而Java中的String是Unicode字符，因此直接使用Text类型value的value.toString();会默认其中的字符都是UTF-8编码的。因此原本GBK编码的数据使用Text读入后直接使用该方法会造成乱码！

正确方法：将输入的Text类型的value转换为字节数组，使用String的构造函数：

String(byte[] bytes, int offset,int length, Charset charset);通过使用指定的charset解码指定的byte子数组，构造一个新的String即可！Text类型的UTF-8特性在TextOutputFormat的源代码中已经确定，因此若希望输出非UTF-8格式数据，需要自定义FileOutputFormat的子类，而不应该使用默认的TextOutputFormat！

细节2：运行一段时间后Hadoop无法stop-all.sh的问题，显示报错！

问题主要原因：Hadoop在stop时会依据Datanode上的mapred和dfs进程号，而默认的进程号保存在/tmp文件夹下，linux默认会每隔一段时间（可能一个月也可能七天）就删除该目录下的文件。因此删除了hadoop-hadoop-jobtracker.pid和hadoop-hadoop-namenode.pid这两个文件后，Namenode自然就无法找到Datanode上的这两个进程了！

细节3：Hadoop中一种非典型两表Join的处理方法

Hadoop中两表Join一直以来是很困扰我的一个问题，如果是两个大表Join更是如此！比如说有一件商品，收藏者有100万，而这件商品同时有100万个类目(虽然这是不可能的)，我的要求是把每个用户和每一个类目关联起来，对于同一个商品，就需要在内存中存放所有的收藏者100万和类目100万，再来遍历这两个数组，将其关联。注意，由于是同一个key,因此，这个做法和单机上处理一个100万阶层的循环没有两样，程序跑死是非常正常的！

当然类目不可能是100万，但按照正常需求来看，100万用户对1个类目，在单机上处理，也会耗费很多的时间和空间，实际测算来看，20分钟都不能跑出这个关联结果！

根据剑英的一个想法，和志远讨论以后，这个问题现在看来已经可以被一种不典型做法解决了，现详述如下：

实际案例就如上所说：一张表是商品和用户的关系，一张表是商品和类目的关系，一件商品最多可能被几百万用户收藏，而其对应的类目则是唯一。现在的要求就是把用户和类目关联起来，结果为用户和类目的对应关系。

问题：表1<商品，用户>；表2<商品，类目>，将表1和表2进行Join操作，最终返回表3<用户，类目>！其中一个商品对应众多用户，而商品具有唯一类目。

a.将同一个商品和其对应的百万用户按照HASH进行区分，也就是说，如果一件商品A，对应的有100万用户，我们人为的将这100万用户拆成N份，分别丢进N个reduce中去处理。这样做的好处就是，原来一个reduce中要处理100万的数据量，现在则变成了只要处理100/n个，降低了每个reduce的压力。（hash划分同一个商品对应的用户，例如一个商品由100万人收藏，则将这100万条数据进行hash划分，比如人为分成10份，一份约10万）
       b.由于将商品进行了拆分，所以其对应的类目我们要COPY N份给每个reduce,保证所有的用户都可以和其商品类目关联到。（拷贝商品及其类目信息，并发送到Reduce端）
        c.这样做，在map阶段其实是增加了数据量，由于原来只要1份类目表就可以了，但是现在需要N份类目表，因此，在map阶段的时间明显增加.
        d.原先没有按照HASH分布，20分钟整个程序都不能跑完，现在分开处理以后(HASH分布成5个)，6分钟可以跑完，但是原先MAP只要1分钟，现在MAP用了有4分钟，整个程序用在MAP上的时间超过了REDUCE.

（以增加Map阶段的时间为代价，来降低Reduce阶段的时间，使得总时间下降！）

对于我这个实例，经过几次实验后，发现HASH分成5个的时候时间最短，是6分钟。原因在于如果HASH分的多的话，类目表的拷贝也会多，由于类目表有2000万条数据，拷贝一遍就是2000万，现在5个HASH，也就是要多出1亿条数据！
当然，这是一个特殊情况，对于同一个key来说，是“一组”极大的数据和“一条”数据进行关联，对于多对多，目前还没想出什么很好的办法！

问题：表1对应的条目是：<商品，用户>；表2对应的条目是：<商品，类目>，要求将表1和表2进行join操作，返回<用户，类目>条目。注意：表1和表2的条目数量很多。。。。。。

核心思想：由于一个商品对应多个用户，因此可以通过hash函数按照用户进行划分。假如一个商品有100万用户，可以人为地将其划分为N份；同时将<商品，类目>复制并发送到Reduce上。在Reduce上产生满足条件的<用户，类目>条目！！！

细节4：数据倾斜总结

在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，map处理数据量的差异取决于上一个stage的reduce输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后，总结如下。

1数据倾斜的原因

1.1操作：

关键词	情形	后果
Join	其中一个表较小，但是key集中	分发到某一个或几个Reduce上的数据远高于平均值
Join	大表与大表，但是分桶的判断字段0值或空值过多	这些空值都由一个reduce处理，灰常慢
group by	group by 维度过小，某值的数量过多	处理某值的reduce灰常耗时
Count Distinct	某特殊值过多	处理此特殊值的reduce耗时

1.2原因：1)、key分布不均匀；2)、业务数据本身的特性；3)、建表时考虑不周；4)、某些SQL语句本身就有数据倾斜

1.3表现：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多，最长时长远大于平均时长。

2数据倾斜的解决方案

2.1参数调节：hive.map.aggr= true；Map端部分聚合(Combiner)；hive.groupby.skewindata=true

有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个MRJob。第一个MRJob中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；第二个MRJob再根据预处理的数据结果按照GroupBy Key 分布到Reduce 中（这个过程可以保证相同的Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

2.2 SQL语句调节：

如何Join：关于驱动表的选取，选用joinkey分布最均匀的表作为驱动表,做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。

大小表Join：使用mapjoin让小的维度表（1000条以下的记录条数）先进内存。在map端完成reduce.

大表Join大表：把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。

countdistinct大量相同特殊值：count distinct时，将值为空的情况单独处理，如果是计算countdistinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行groupby，可以先将值为空的记录单独处理，再和其他计算结果进行union。

groupby维度过小：采用sum()group by的方式来替换count(distinct)完成计算。

特殊情况特殊处理：在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。

3典型的业务场景

3.1空值产生的数据倾斜

场景：如日志中，常会有信息丢失的问题，比如日志中的user_id，如果取其中的user_id 和用户表中的user_id关联，会碰到数据倾斜的问题。

解决方法1： user_id为空的不参与关联（红色字体为修改后）

select * from log a join users b on a.user_id is not null and a.user_id = b.user_id

union all select * from log a where a.user_id is null;

解决方法2 ：赋与空值分新的key值

select * from log a left outer join users b

on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中log读取两次，jobs是2。解决方法2job数是1。这个优化适合无效id (比如-99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上,解决数据倾斜问题。

3.2不同数据类型关联产生数据倾斜

场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方法：把数字类型转换成字符串类型

select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string)

3.3小表不小不大，怎么用 map join 解决倾斜问题

使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到mapjoin会出现bug或异常，这时就需要特别的处理。以下例子:

select * from log a left outer join users b on a.user_id = b.user_id;

users表有600w+的记录，把users分发到所有的map上也是个不小的开销，而且mapjoin不支持这么大的小表。如果用普通的join，又会碰到数据倾斜的问题。

解决方法：

select /*+mapjoin(x)*/* from log a

left outer join (

select /*+mapjoin(c)*/d.*

from ( select distinct user_id from log ) c

join users d

on c.user_id = d.user_id

) x

on a.user_id = b.user_id;

假如，log里user_id有上百万个，这就又回到原来mapjoin问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

4总结

使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按keyHash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：

1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。

2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做mapjoin生成tmp2,把tmp2读到distributefile cache。这是一个map过程。

3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成<user_id,value>的key,value对，假如记录来自member,生成<user_id,value>的key,value对，进入reduce阶段。

4、最终把a文件，把Stage3reduce阶段输出的文件合并起写到hdfs。

如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：

1、对于join，在判断小表不大于1G的情况下，使用mapjoin

2、对于groupby或distinct，设定 hive.groupby.skewindata=true

3、尽量使用上述的SQL语句调节进行优化

细节5：一个cache的改造过程

在分布式的程序中，cache的合理使用可以带来性能上的极大提升，尤其是在资源创建需要昂贵的开销时。cache的设计最重要的是要保证线程安全和高效性。下面以代码为例，介绍了三种cache的写法。

1. 粗放的加锁

public class Cache1 {

privateHashMap<String, ServerGroup> route2SG = null;//HashMap：非线程安全容器

publicCache1() {//构造函数

route2SG= new HashMap<String, ServerGroup>();

}//粗放的加锁体现在对整个方法用关键字synchronized修饰！

publicsynchronized ServerGroup get(String routeKey) throws IOException {

ServerGroupsg = null;

sg= route2SG.get(routeKey);

if(sg == null) {

sg= getServerGroup(routeKey);

route2SG.put(routeKey,sg);

}

returnsg;

}

publicsynchronized void remove(String routeKey) {

route2SG.remove(routeKey);

}

privateServerGroup getServerGroup(String routeKey) throws IOException {

ServerGroupsg = null;

/**

* Construct ServerGroup here

returnsg;

}

2. 读写锁

public class Cache2 {//ConcurrentHashMap：线程安全类

privateConcurrentHashMap<String, ServerGroup> route2SG = null;

privatefinal ReadWriteLock lock = new ReentrantReadWriteLock();//读写锁

publicCache2() {//构造函数

route2SG= new ConcurrentHashMap<String, ServerGroup>();

}//读写锁相比于synchronized的粒度更细

publicServerGroup get(String routeKey) throws IOException {

ServerGroupsg = null;

try{

lock.readLock().lock();//读锁加锁

sg= route2SG.get(routeKey);

if(sg == null) {

lock.readLock().unlock();//读锁解锁

lock.writeLock().lock();//写锁加锁

sg= route2SG.get(routeKey);

if(sg == null) {

sg= getServerGroup(routeKey);

route2SG.put(routeKey,sg);//由于写锁加锁，只能一个线程写入数据

}

lock.readLock().lock();//读锁加锁

lock.writeLock().unlock();//写锁解锁

}

}catch (IOException e) {

lock.writeLock().unlock();

throw(e);

}

lock.readLock().unlock();//读锁解锁

returnsg;

}

publicvoid remove(String routeKey) {

try{

lock.writeLock().lock();

route2SG.remove(routeKey);

}finally {

lock.writeLock().unlock();

}

privateServerGroup getServerGroup(String routeKey) throws IOException {

ServerGroupsg = null;

/**

* Construct ServerGroup here

returnsg;

}

3. 无锁

public class Cache3 {

privateConcurrentHashMap<String, FutureTask<ServerGroup>> route2SGFT =null;

publicCache3() {

route2SGFT= new ConcurrentHashMap<String, FutureTask<ServerGroup>>();

}

public ServerGroup get(String routeKey)throws IOException, InterruptedException, ExecutionException {

FutureTask<ServerGroup>ft = route2SGFT.get(routeKey);//FutureTask：获取异步计算

if(ft != null) {

returnft.get();

}

FutureTask<ServerGroup> sft = newFutureTask<ServerGroup>(new ConstructSGTask(routeKey));

FutureTask<ServerGroup>old = route2SGFT.putIfAbsent(routeKey, sft);

if(old == null) {

old=sft;

old.run();

}

returnold.get();

}

publicvoid remove(String routeKey) {

route2SGFT.remove(routeKey);

}

classConstructSGTask implements Callable<ServerGroup> {

privatefinal String key;

publicConstructSGTask(String key) {

super();

this.key= key;

}

@Override

publicServerGroup call() throws Exception {

returngetServerGroup(key);

}

privateServerGroup getServerGroup(String routeKey) throws IOException {

ServerGroupsg = null;

/**

* Construct ServerGroup here

returnsg;

}

总结:从三份代码中可以看出，锁的粒度从粗放到无，这个就极大的提高了cache的并发性。

剑儒

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Hadoop技术细节遗珠

Hadoop使用细节总结细节1：正确输出中文！（Hadoop正确输出UTF-8格式的中文，而不支持GBK格式的中文）曾经有次需要输出中文，但是在Hadoop中打印出来的却是乱码。一开始以为Hadoop的设计者当初设计Hadoop时就不支持输出中文，后来通过查看TextOutputFormat的源代码，发现Hadoop仅仅是不支持以GBK格式输出中文罢了。 Ha
复制链接

扫一扫