Hadoop常见问题①

1、Hadoop的shuffle过程

即为从MAP端输出到REDUCE端输入之间的过程。因为涉及到Hadoop中最珍贵的网络资源，所以shuffle过程中有很多可以调节的参数，也有很多策略可以研究。
MAP端
此过程的输出是写入到本地磁盘而不是HDFS，但是一开始数据并不是直接写入磁盘而是缓冲在内存里。缓存的好处就是减少磁盘I/O的开销，提高合并和排序的速度。默认的内存缓冲大小为100M，所以在写MAP函数的时候要尽量减少内存的使用，为shuffle过程预留更多的内存，因为该过程是最耗时的过程。
当缓冲的内存大小使用超过一定的阈值（默认80%），一个后台的线程就会启动把缓冲区中的数据写入（spill）到磁盘中，往内存中写入的线程继续写入直到缓冲区满，缓冲区满后线程阻塞直至缓冲区被清空。
在数据spill到磁盘的过程中会有一些额外的处理，调用partition函数、combine函数（如果设置）、对数据进行排序（按key排序）。如果发生多次磁盘的溢出写，会在磁盘上形成几个溢出写文件，在map过程结束时，要将这些文件进行合并生成一个大的分区的排序的文件（比较绕）。
另外在写磁盘的时候才用压缩的方式将map的输出结果进行压缩是减少网络开销很有效的方法。

REDUCE端
reduce端可能从n多map的结果中获取数据，而这些map的执行速度不尽相同，当其中一个map运行结束时，reduce就会从job tractor中获取该信息。map运行结束后task tractor会得到消息，进而将消息汇报给job tractor，reduce定时从job tractor获取该信息，reduce端默认有5个线程从map端拖拉数据。
同样从map端拖来的数据（pull）先写到reduce端的缓存中，同样缓存占用到达一定阈值后会将数据写到磁盘中，同样会进行partition、combine、排序等过程。如果形成多个磁盘文件还会进行合并最后一次合并的结果作为reduce的输入而不是写入到磁盘中。
reduce的结果将会写入到HDFS，如果执行任务的节点也是HDFS的一个节点，本地会保存一个副本。

2、hadoop对于实时在线处理有优势吗？

直接使用hadoop进行实时处理时没有优势的，因为Hadoop主要解决的是海量批处理作业计算问题，但是可以使用基于Hadoop的分布式NOSQL系统HBase系统以及相关实时处理系统：
1. 基于Hadoop的HBase可以做到实时处理以及相关需求的实时计算，主要解决海量

3、Hadoop存储海量数据没有问题，但是如何能够做到海量数据的实时检索？

1,可以结合开源的搜索引擎Apache Lucene，Solr 或ElasticSearch
2,海量数据的实时检索可以考虑HBase，建议可以使用hadoop将数据构建成以查询key为键的数据集，然后将

4、 大的文件拆分成很多小的文件后，怎样用Hadoop进行高效的处理这些小文件？以及怎样让各个节点尽可能的负载均衡？

1. 怎样用Hadoop进行高效的处理这些小文件？
   hadoop在处理大规模数据时是很高效的，但是处理大量的小文件时就会因为系统资源开销过大而导致效率较低，针对这样的问题，可以将小文件打包为大文件，例如使用SequcenFile文件格式，例如以文件签名为key，文件内容本身为value写成SequcenFile文件的一条记录，这样多个小文件就可以通过SequcenFile文件格式变为一个大文件，之前的每个小文件都会映射为SequcenFile文件的一条记录。
2. 怎样让各个节点尽可能的负载均衡？
   在hadoop集群中负载均衡是非常关键的，这种情况的导致往往是因为用户的数据分布的并不均衡，而计算资源槽位数确实均衡分布在每个节点，这样在作业运行时非本地任务会有大量的数据传输，从而导致集群负载不均衡，因此解决不均衡的要点就是将用户的数据分布均衡，可以使用hadoop内置的balancer脚本命令。
   对于因为资源调度导致的不均衡则需要考虑具体的调度算法和作业分配机制。

5、现在企业中使用Hadoop版本主要是1.x还是2.x？

目前百度，腾讯，阿里为主的互联网公司都是以hadoop 1.X为基准版本的，当然每个公司都会进行自定义的二次开发以满足不同的集群需求。
2.X在百度内部还没有正式使用，还是以1.X为主，不过百度针对1.X的问题开发了HCE系统（Hadoop C++ Expand系统）

补充，Hadoop2.x在其他公司应用的很多，比如京东等

6、数据倾斜

1,好多数据都集中在一个reduce里 其他reduce里分配的数据比较少 默认情况下决定哪些数据分配到哪个reduce是由reduce个数和partiiton分区决定的 默认是对key进行hash运算 一般情况下用mapreuce倾斜很少 除非你用的HIVE
2,reduce分为3个子阶段：shuffle、sort和reduce，如果reduce整个过程耗时较长，建议先看一下监控界面是卡在哪个阶段，如果是卡在shuffle阶段往往是网络阻塞问题，还有就是某reduce数据量太大，也就是数据倾斜问题，这种问题往往因为某个key的value太多，解决方法是：第一，默认的partiiton可能不适合你的需求，你可以自定义partiiton；第二就是在map端截断，尽量让达到每个reduce端的数据分布均匀。