大数据面试题

hive内部外部表的区别？

答：
内部表
先有表 后有数据，数据被存储到hdfs目录下表对应的文件夹进行管理。
使用Hive命令删除表相关的操作时HDFS上对应的文件就会被删掉。
外部表
先有数据后有表，hive表关联到该位置管理其中的数据。
Hive的一切命令都不能够对外部文件造成影响。

Hadoop和spark区别？

答：hadoop核心包括Hadoop分布式文件系统(HDFS)，Hadoop YARN，Hadoop MapReduce。Spark包括sparkcore，sparksql,sparkstreaming，sparkcore可以用来做离线处理，sparksql可以用来交互式查询，sparkstreaming用来进行实时处理。

相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。MapReduce和Spark的主要区别在于，MapReduce使用持久存储，而Spark使用弹性分布式数据集(RDDS)。

Spark是在借鉴了MapReduce之上发展而来的，继承了其分布式并行计算的优点并改进了MapReduce明显的缺陷，具体如下：
首先，Spark把中间数据放到内存中，迭代运算效率高。MapReduce中计算结果需要落地，保存到磁盘上，这样势必会影响整体速度，而Spark支持DAG图的分布式并行计算的编程框架，减少了迭代过程中数据的落地，提高了处理效率。
其次，Spark容错性高。Spark引进了弹性分布式数据集RDD (Resilient Distributed Dataset) 的抽象，它是分布在一组节点中的只读对象集合，这些集合是弹性的，如果数据集一部分丢失，则可以根据“血统”（即允许基于数据衍生过程）对它们进行重建。另外在RDD计算时可以通过CheckPoint来实现容错。MapReduce和Spark从两个不同的方向来解决问题。MapReduce使用nodemanager节点，它为 Appmaster节点提供了心跳(heartbeat)。如果没有心跳，那么Appmaster节点重新调度所有将执行的操作和正在进行的操作，交 给另一个nodemanager节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。
最后，Spark更加通用。不像Hadoop只提供了Map和Reduce两种操作，Spark提供的数据集操作类型有很多种，大致分为：Transformations和Actions两大类。Transformations包括Map、Filter、FlatMap、Sample、GroupByKey、ReduceByKey、Union、Join、Cogroup、MapValues、Sort和PartionBy等多种操作类型，同时还提供Count, Actions包括Collect、Reduce、Lookup和Save等操作。另外各个处理节点之间的通信模型不再像Hadoop只有Shuffle一种模式，用户可以命名、物化，控制中间结果的存储、分区等。
Spark还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapReduce没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapReduce来得容易一点。

Spark和storm的区别？

对于Storm来说：
1、建议在那种需要纯实时，不能忍受1秒以上延迟的场景下使用，比如实时金融系统，要求纯实时进行金融交易和分析
2、此外，如果对于实时计算的功能中，要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm
3、如果还需要针对高峰低峰时间段，动态调整实时计算程序的并行度，以最大限度利用集群资源（通常是在小型公司，集群资源紧张的情况），也可以考虑用Storm
4、如果一个大数据应用系统，它就是纯粹的实时计算，不需要在中间执行SQL交互式查询、复杂的transformation算子等，那么用Storm是比较好的选择

对于Spark Streaming来说：
1、如果对上述适用于Storm的三点，一条都不满足的实时场景，即，不要求纯实时，不要求强大可靠的事务机制，不要求动态调整并行度，那么可以考虑使用Spark Streaming
2、考虑使用Spark Streaming最主要的一个因素，应该是针对整个项目进行宏观的考虑，即，如果一个项目除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，那么就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性

Kafka怎么保持数据一致性的？

KafKa将分区的集合都维护在一个叫做AR的表中表中含有所有分区的副本编号，AR表中的分区（也就是所有的分区）在逻辑上又会分到两个子表中一个是ISR，另一个是OSR，即AR=ISR + OSR。
其中ISR为同步列表，也就是说当我们写入一条消息之后只要ISR中的各个节点都得到同步就可以，OSR中为非同步列表我们在写入数据的时候无需关注他们，但是也会发生同步只是不作为判定条件而已。为什么会有这样的策略呢？原因就是ISR中的同步速度较快，而OSR中的同步速度较慢以至于超越了我们规定的阈值（replica.lag.time.max.ms）。这样的话KafKa集群就避免了Zookeeper集群的不过半无法启动集群的问题，即使只有一台KafKa主机就可以启动，但是牺牲了一部分可靠性。当然这对于KafKa消息队列来说是非常有意义的。
HW截断机制
LEO - LogEndOffset - 分区的最新的数据的offset
HW - HighWatermark - 只有写入的数据被 同步到 所有的ISR中的 副本后，数据才认为已提交，HW更新到该位置，HW之前的数据才可以被消费者访问，保证 没有 同步完成的数据不会被消费者 访问到
在leader宕机后，只能从ISR列表中选取新的leader，无论ISR中哪个副本被选为 新的leader都知道HW之前的数据，可以保证在切换了leader后，消费者可以继续看到 之前已经 提交的数据
如果leader宕机 选出了新的leader 而新的leader并没有完全同步之前leader的所有数据，之后接受了后续新的数据，此时旧的leader恢复，则会发现新的leader中的数据和自己持有的数据不一致，此时旧的leader会将自己的数据截断到之前宕机之前的hw位置，之后同步新leader的数据
如果ISR中的follower同步了leader中的部分数据，之后leader宕机，follower也宕机，此时选出新的leader可能同步了部分之前 leader的数据，之后接受新的数据，此时follower恢复过来，发现 自己持有的 数据和新 的leader的数据不一致，此时阶段数据到 之前的 hw位置，然后和 新的leader同步 数据

缓存三大问题及解决方案

一. 缓存穿透
指查询一个一定不存在的数据，因为缓存中也无该数据信息，请求会直接到达数据库，在数据库中查询，从系统层面来看像是穿透了缓存层直接到达数据库。
没有了缓存层的保护，如果有人频繁的查询这种一定不存在的数据来攻击系统，就会引起数据库瘫痪，从而导致系统故障。
解决方案：
1) bloom filter：类似于哈希表的一种算法，在进行数据库查询之前，进行过滤操作，对不存在的数据直接过滤，从而减轻数据库层面的压力。
2) 空值缓存：将在第一次查询不到的数据（该key与对应的空值）放入缓存，并设置短的失效时间，可以在一定时间内，应对攻击者的攻击。
二 . 缓存雪崩
在一般的缓存系统中，加入redis、memcache等缓存系统，缓存会设置失效时间，如果所有的缓存在同一时间失效，系统所有的请求会直接到达数据库，数据库无法承受压力，会导致系统奔溃。
解决方案：
（1）线程互斥：每个时刻只让一个线程构建缓存，其他线程等待执行，从而减轻数据库的压力。缺点是降低了系统的qps（每秒处理完请求的次数）。
（2）交错失效时间：在某个适当的值域随机一个时间作为失效时间。
三 . 缓存击穿
缓存击穿是缓存雪崩的一个特例。缓存击穿是对于热点数据，雪崩是全部数据。
解决方案：
（1）二级缓存：对于热点数据进行二级缓存，对于不同级别的缓存设置不同的实效时间。
LRU算法：使用链表存放数据。

Hbase行键设计规范？

• 字符串类型
设置成string类型，保证其通用性。
• 有明确意义
• 具有有序性，RowKey是按照字典序存储，因此，设计RowKey时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
• 具有定长性，行键具有有序性的基础便是定长
• rowkey长度原则
Rowkey是一个二进制码流，rowkey的长度被开发者建议在10-100个字节，不过建议越短 越好，不要超过16个字节
• RowKey唯一原则

Hbase列族不能过多的真相

答：①HRegionServer内部管理了一系列HRegion对象，每个HRegion对应了table中的一个region，HRegion中由多个HStore组成。每个HStore对应了Table中的一个column family的存储，可以看出每个columnfamily其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个column family中，这样最高效。
②由于不同的列族会共享region，所以有可能出现，一个列族已经有1000万行，而另外一个才100行。当一个要求region分割的时候，会导致100行的列会同样分布到多个region中。这样就出现了基数问题。（如果表存在多个列族，列族A有100万行，列族B有10亿行，那么列族A可能会被分散到很多个Region上，这会导致扫描列族A的性能低下）
③(某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O)
所以，一般建议不要设置多个列族。

hbase中如何防止数据倾斜

1. 加随机数,在rowkey前面增加随机数,具体就是给rowkey分配一个随机前缀,以使得它和之前排序不同,
2. 哈希,哈希会使同一行永远使用同一个前缀,哈希也可以使负载分散到整个集群,但是读取是可以预测的,使用确定的哈希可以让客户端重构完成的rowkey,使用Get操作获取正常的获取某一行数据.
3. 反转,反转固定长度或者数字格式的rowkey,这样可以使rowkey中经常改变的部分(最没有意义的部分)放在前面,这样可以有效的随机rowkey,但是牺牲了rowkey的有序性.
4. 时间戳反转,一个常见的数据处理问题是快速获取数据的最近版本,使用反转的时间戳作为rowkey的一部分对这个问题十分有用.

hadoop中需要配置哪些配置文件其作用是什么？

hadoop-env.sh：配置hadoop的环境变量,主要修改hadoop的java_home路径
core-site.xml：配置hdfs的老大及运行时产生的文件目录及其zookeeper的地址
hdfs-site .xml ：配置namenode的地址，高可用失败恢复，副本的数量以及hdfs的操作权限等
mapred-site.xml :配置mapreduce运行在哪个资源管理器上
yarn-site.xml：配置resourcemanage的地址及高可用失败恢复等配置
slaves：配置datanode节点信息

Memstore Flush触发条件

HBase会在如下几种情况下触发flush操作，需要注意的是MemStore的最小flush单元是HRegion而不是单个MemStore。可想而知，如果一个HRegion中Memstore过多，每次flush的开销必然会很大，因此我们也建议在进行表设计的时候尽量减少ColumnFamily的个数。
1. Memstore级别限制：当Region中任意一个MemStore的大小达到了上限（hbase.hregion.memstore.flush.size，默认128MB），会触发Memstore刷新。
2. Region级别限制：当Region中所有Memstore的大小总和达到了上限（hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默认 2* 128M = 256M），会触发memstore刷新。
3. Region Server级别限制：当一个Region Server中所有Memstore的大小总和达到了上限（hbase.regionserver.global.memstore.upperLimit ＊ hbase_heapsize，默认 40%的JVM内存使用量），会触发部分Memstore刷新。Flush顺序是按照Memstore由大到小执行，先Flush Memstore最大的Region，再执行次大的，直至总体Memstore内存使用量低于阈值（hbase.regionserver.global.memstore.lowerLimit ＊ hbase_heapsize，默认 38%的JVM内存使用量）。
4. 当一个Region Server中HLog数量达到上限（可通过参数hbase.regionserver.maxlogs配置）时，系统会选取最早的一个 HLog对应的一个或多个Region进行flush
5. HBase定期刷新Memstore：默认周期为1小时，确保Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题，定期的flush操作有20000左右的随机延时。
6. 手动执行flush：用户可以通过shell命令 flush ‘tablename’或者flush ‘region name’分别对一个表或者一个Region进行flush。

hadoop的运行原理

1、Map过程简述：
1）读取数据文件内容，对每一行内容解析成<k1,v1>键值对，每个键值对调用一次map函数
2）编写映射函数处理逻辑，将输入的<k1,v1>转换成新的<k2,v2>
3）对输出的<k2,v2>按reducer个数和分区规则进行分区
4）不同的分区，按k2进行排序、分组，将相同的k2的value放到同一个集合中
5）（可选）将分组后的数据重新reduce归约
2、reduce处理过程：
1）对多个Map的输出，按不同分区通过网络将copy到不同的reduce节点
2）对多个map的输出进行排序，合并，编写reduce函数处理逻辑，将接收到的数据转化成<k3,v3>
3）将reduce节点输出的数据保存到HDFS上
说明：
1）Mapper Task 是逻辑切分。因为Maper记录的都是block的偏移量，是逻辑切分，但相对于内存中他确实是物理切分，因为每个Mapper都是记录的分片段之后的数据。
2）shuffle是物理切分。MapReduce的过程是俩过程需要用到Shuffle的，1个mapper的Shufflle,1个多个reduce的Shuffle,一般每个计算模型都要多次的reduce，所以要用到多次的Shuffle。.
正常HDFS存储3份文件，Jar包默认写10份，NameNode通过心跳机制领取HDFS任务，运行完毕后JAR包会被删除。
Map端处理流程分析：

1. 每个输入分片会交给一个Map任务（是TaskTracker节点上运行的一个Java进程），默认情况下，系统会以HDFS的一个块大小作为一个分片（hadoop2默认128M，配置dfs.blocksize）。Map任务通过InputFormat将输入分片处理成可供Map处理的<k1,v1>键值对。
2. 通过自己的Map处理方法将<k1,v1>处理成<k2,v2>，输出结果会暂时放在一个环形内存缓冲（缓冲区默认大小100M，由mapreduce.task.io.sort.mb属性控制）中，当缓冲区快要溢出时（默认为缓冲区大小的80%，由mapreduce.map.sort.spill.percent属性控制），会在本地操作系统文件系统中创建一个溢出文件(由mapreduce.cluster.local.dir属性控制，默认${hadoop.tmp.dir}/mapred/local)，保存缓冲区的数据。溢写默认控制为内存缓冲区的80%，是为了保证在溢写线程把缓冲区那80%的数据写到磁盘中的同时，Map任务还可以继续将结果输出到缓冲区剩余的20%内存中，从而提高任务执行效率。
3. 每次spill将内存数据溢写到磁盘时，线程会根据Reduce任务的数目以及一定的分区规则将数据进行分区，然后分区内再进行排序、分组，如果设置了Combiner，会执行规约操作。
4. 当map任务结束后，可能会存在多个溢写文件，这时候需要将他们合并，合并操作在每个分区内进行，先排序再分组，如果设置了Combiner并且spill文件大于mapreduce.map.combine.minspills值（默认值3）时，会触发Combine操作。每次分组会形成新的键值对<k2,{v2…}>。
5. 合并操作完成后，会形成map端的输出文件，等待reduce来拷贝。如果设置了压缩，则会将输出文件进行压缩，减少网络流量。是否进行压缩，mapreduce.output.fileoutputformat.compress，默认为false。设置压缩库，mapreduce.output.fileoutputformat.compress.codec，默认值org.apache.hadoop.io.compress.DefaultCodec。
   Reduce端处理流程分析：
   1)Reduce端会从AM那里获取已经执行完的map任务，然后以http的方法将map输出的对应数据拷贝至本地（拷贝最大线程数mapreduce.reduce.shuffle.parallelcopies，默认值5）。每次拷贝过来的数据都存于内存缓冲区中，当数据量大于缓冲区大小（由mapreduce.reduce.shuffle.input.buffer.percent控制，默认0.7）的一定比例（由mapreduce.reduce.shuffle.merge.percent控制，默认0.66）时，则将缓冲区的数据溢写到一个本地磁盘中。由于数据来自多个map的同一个分区，溢写时不需要再分区，但要进行排序和分组，如果设置了Combiner，还会执行Combine操作。溢写过程与map端溢写类似，输出写入可同时进行。
   2 ）当所有的map端输出该分区数据都已经拷贝完毕时，本地磁盘可能存在多个spill文件，需要将他们再次排序、分组合并，最后形成一个最终文件，作为Reduce任务的输入。此时标志Shuffle阶段结束，然后Reduce任务启动，将最终文件中的数据处理形成新的键值对<k3,v3>。
   3） 将生成的数据<k3,v3>输出到HDFS文件中。

MapReduce的优化

1、配置调优
调优总的原则给shuffle过程尽量多提供内存空间，在map端，可以通过避免多次溢出写磁盘来获得最佳性能(相关配置io.sort.*，io.sort.mb)，在reduce端，中间数据全部驻留在内存时，就能获得最佳性能，但是默认情况下，这是不可能发生的，因为一般情况所有内存都预留给reduce含函数(如需修改 需要配置mapred.inmem.merge.threshold，mapred.job.reduce.input.buffer.percent)
如果能够根据情况对shuffle过程进行调优，对于提供MapReduce性能很有帮助。
一个通用的原则是给shuffle过程分配尽可能大的内存，当然你需要确保map和reduce有足够的内存来运行业务逻辑。因此在实现Mapper和Reducer时，应该尽量减少内存的使用，例如避免在Map中不断地叠加。
运行map和reduce任务的JVM，内存通过mapred.child.java.opts属性来设置，尽可能设大内存。容器的内存大小通过mapreduce.map.memory.mb和mapreduce.reduce.memory.mb来设置，默认都是1024M。
2、Map/Reduce端调优
通用优化
Hadoop默认使用4KB作为缓冲，这个算是很小的，可以通过io.file.buffer.size来调高缓冲池大小。
map端优化
避免写入多个spill文件可能达到最好的性能，一个spill文件是最好的。通过估计map的输出大小，设置合理的mapreduce.task.io.sort.*属性，使得spill文件数量最小。例如尽可能调大mapreduce.task.io.sort.mb。
reduce端优化
如果能够让所有数据都保存在内存中，可以达到最佳的性能。通常情况下，内存都保留给reduce函数，但是如果reduce函数对内存需求不是很高，将mapreduce.reduce.merge.inmem.threshold（触发合并的map输出文件数）设为0，mapreduce.reduce.input.buffer.percent（用于保存map输出文件的堆内存比例）设为1.0，可以达到很好的性能提升。在TB级别数据排序性能测试中，Hadoop就是通过将reduce的中间数据都保存在内存中胜利的。

hadoop1中partition和combiner作用

Partiton
　　把map任务的输出的中间结果按照key的范围进行划分成r份，r代表reduce任务的个数。hadoop默认有个类HashPartition实现分区，通过key对reduce的个数取模(key%r),这样可以保证一段范围内的key交由一个reduce处理。以此来实现reduce的负载均衡。不至于使有些reduce处理的任务压力过大，有些reduce空闲。

Combiner
　　在Partiton之前，我们还可以对中间结果进行Combiner,即将中间结果中有着相同key 的（key，value）键值对进行合并成一对，Combiner的过程与reduce的过程类似，很多情况下可以直接使用reduce，但是Combiner作为Map任务的一部分，在Map输出后紧接着执行，通过Combiner的执行，减少了中间结果中的（key，value）对数目，reduce在从map复制数据时将会大大减少网络流量，每个reduce需要和原许多个map任务节点通信以此来取得落到它负责key区间内的中间结果，然后执行reduce函数，得到一个最中结果文件。有R个reduce任务，就有R个最终结果，这R个最终结果并不需要合并成一个结果，因为这R个最终结果又可以作为另一次计算的输入，开始另一次计算。

hadoop集群搭建步骤

1.修改主机名
2.配置免密登录
3.关闭防火墙
4.安装zookeeper集群,并启动
5.配置jdk
6.安装hadoop并配置环境变量
hadoop-env.sh：配置hadoop的环境变量,主要修改hadoop的java_home路径
core-site.xml：配置hdfs的老大及运行时产生的文件目录及其zookeeper的地址
hdfs-site .xml ：配置namenode的地址，高可用失败恢复，副本的数量以及hdfs的操作权限等
mapred-site.xml :配置mapreduce运行在哪个资源管理器上
yarn-site.xml：配置resourcemanage的地址及高可用失败恢复等配置
slaves：配置datanode节点信息
7.将配置文件复制到hadoop02和hadoop03
scp -r $HADOOP_HOME/etc/hadoop root@hadoop02:/home/software/hadoop-2.7.1/etc/
scp -r $HADOOP_HOME/etc/hadoop root@hadoop03:/home/software/hadoop-2.7.1/etc/
8.格式化
在主节点hadoop下执行：
hadoop namenode -format
9.集群的启动
Start-all.sh

Hadoop五个进程的作用和联系

1.NameNode:
相当于一个领导者，负责调度 ，比如你需要存一个1280m的文件
如果按照128m分块 那么namenode就会把这10个块（这里不考虑副本）
分配到集群中的datanode上并记录对于关系 。当你要下载这个文件的时 候namenode就知道在那些节点上给你取这些数据了。它主要维护两个 map 一个是文件到块的对应关系 一个是块到节点的对应关系。
2. secondarynamenode：
它是namenode的一个快照，会根据configuration中设置的值来
决定多少时间周期性的去cp一下namenode，记录namenode中
的metadata及其它数据
3. NodeManager（NM）:
是YARN中每个节点上的代理，它管理Hadoop集群中单个计算节点
包括与ResourceManger保持通信，监督Container的生命周期管理，
监控每个Container的资源使用（内存、CPU等）情况，追踪节点健
康状况，管理日志和不同应用程序用到的附属服务（auxiliary service）

4.DataNode:
a.DataNode的需要完成的首要任务是K-V存储
b.完成和namenode 通信 ，这个通过IPC 心跳连接实现。
此外还有和客户端 其它datanode之前的信息交换
c.完成和客户端还有其它节点的大规模通信，这个需要直接
通过socket 协议实现。

5.ResourceManager:
在YARN中，ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationManager）
RM与每个节点的NodeManagers (NMs)和每个应用的ApplicationMasters (AMs)一起工作。
a.NodeManagers 遵循来自ResourceManager的指令来管理单一节点上的可用资源。
b.ApplicationMasters负责与ResourceManager协商资源与NodeManagers合作启动容器

hadoop的调度器

FiFo schedular 默认,先进先出的原则。
Capacity schedular:计算能力调度器,选择占用最小、优先级高的先执行，以此类推。
Fair schedular：公平调度，所以的job具有相同的资源。

用mapreduce怎么处理数据倾斜问题

在mapreduce聚合key中所有values的时候，如果一个key对应了很多values，就会产生数据倾斜的问题。数据倾斜主要就是某个key下面对应的value太多，导致某个reduce节点执行的数据过多，然后产生某个或者某几个reduce节点的执行效率过低，导致整个集群中的任务执行效率较慢，可以使用partion对数据过多的节点进行再划分，划分成多个小的数据块，输入到reduce进行处理。

我们在开发分布式计算job的时候，是否可以去掉reduce阶段？

可以，例如我们的集群就是为了存储文件而设计的，不涉及到数据的计算，就可以将mapreduce都省略。

MapReduce优化经验

（1）设置合理的map和reduce的个数
（2）避免出现数据倾斜
（3）combine函数
（4）对数据进行压缩，避免大量的小文件

如何确认hadoop集群的健康状况

使用jps命令来查看各个节点运行的进程是否正常

描述一下hadoop中，有哪些地方用到了缓存机制，作用分别是什么？

缓存机制就是在job任务执行前，将需要的文件拷贝到Task机器上进行缓存，提高mapreduce的执行效率。

mapreduce的map和reduce数量怎么确定，怎么配置？

1、Map任务的个数
读取数据产生多少个Mapper？？
Mapper数据过大的话，会产生大量的小文件,过多的Mapper创建和初始化都会消耗大量的硬件资源
Mapper数太小，并发度过小，Job执行时间过长，无法充分利用分布式硬件资源

Mapper数量由什么决定？？
（1）输入文件数目（2）输入文件的大小（3）配置参数 这三个因素决定的。
输入的目录中文件的数量决定多少个map会被运行起来，应用针对每一个分片运行一个map，一般而言，对于每一个输入的文件会有一个map split。如果输入文件太大，超过了hdfs块的大小（128M）那么对于同一个输入文件我们会有多余2个的map运行起来。
2、reduce任务的个数
Reduce任务是一个数据聚合的步骤，数量默认为1。而使用过多的Reduce任务则意味着复杂的shuffle，并使输出文件的数量激增。

hadoop的TextInputFormat作用是什么，如何自定义实现?

InputFormat会在map操作之前对数据进行两方面的预处理
1是getSplits，返回的是InputSplit数组，对数据进行split分片，每片交给map操作一次
2是getRecordReader，返回的是RecordReader对象，对每个split分片进行转换为key-value键值对格式传递给map
常用的InputFormat是TextInputFormat，使用的是LineRecordReader对每个分片进行键值对的转换，以行偏移量作为键，行内容作为值
自定义类继承InputFormat接口，重写createRecordReader和isSplitable方法
在createRecordReader中可以自定义分隔符

Hadoop与Spark比较

性能
Spark之所以如此快速，原因在于它在内存中处理一切数据。没错，它还可以使用磁盘来处理未全部装入到内存中的数据。
Spark的内存处理为来自多个来源的数据提供了近乎实时分析的功能：营销活动、机器学习、物联网传感器、日志监控、安全分析和社交媒体网站。另 外，MapReduce使用批量处理，其实从来就不是为惊人的速度设计的。它的初衷是不断收集来自网站的信息，不需要这些数据具有实时性或近乎实时性。
易用性
支持Scala(原生语言)、Java、Python和Spark SQL。Spark SQL非常类似于SQL 92，所以几乎不需要经历一番学习，马上可以上手。
Spa6rk还有一种交互模式，那样开发人员和用户都可以获得查询和其他操作的即时反馈。MapReduce没有交互模式，不过有了Hive和Pig等附加模块，采用者使用MapReduce来得容易一点。
成本
“Spark已证明在数据多达PB的情况下也轻松自如。它被用于在数量只有十分之一的机器上，对100TB数据进行排序的速度比Hadoop MapReduce快3倍。”这一成绩让Spark成为2014年Daytona GraySort基准。
兼容性
MapReduce和Spark相互兼容;MapReduce通过JDBC和ODC兼容诸多数据源、文件格式和商业智能工具，Spark具有与MapReduce同样的兼容性。
数据处理
MapReduce是一种批量处理引擎。MapReduce以顺序步骤来操作，先从集群读取数据，然后对数据执行操作，将结果写回到集群，从集群读 取更新后的数据，执行下一个数据操作，将那些结果写回到结果，依次类推。Spark执行类似的操作，不过是在内存中一步执行。它从集群读取数据后，对数据 执行操作，然后写回到集群。
Spark还包括自己的图形计算库GraphX​​。GraphX让用户可以查看与图形和集合同样的数据。用户还可以使用弹性分布式数据集(RDD)，改变和联合图形，容错部分作了讨论。
容错
至于容错，MapReduce和Spark从两个不同的方向来解决问题。MapReduce使用TaskTracker节点，它为 JobTracker节点提供了心跳(heartbeat)。如果没有心跳，那么JobTracker节点重新调度所有将执行的操作和正在进行的操作，交 给另一个TaskTracker节点。这种方法在提供容错性方面很有效，可是会大大延长某些操作(即便只有一个故障)的完成时间。
Spark使用弹性分布式数据集(RDD)，它们是容错集合，里面的数据元素可执行并行操作。RDD可以引用外部存储系统中的数据集，比如共享式文件系统、HDFS、HBase，或者提供Hadoop InputFormat的任何数据源。Spark可以用Hadoop支持的任何存储源创建RDD，包括本地文件系统，或前面所列的其中一种文件系统。
RDD拥有五个主要属性：
• 分区列表
• 计算每个分片的函数
• 依赖其他RDD的项目列表
• 面向键值RDD的分区程序(比如说RDD是散列分区)，这是可选属性
• 计算每个分片的首选位置的列表(比如HDFS文件的数据块位置)，这是可选属性
RDD可能具有持久性，以便将数据集缓存在内存中。这样一来，以后的操作大大加快，最多达10倍。Spark的缓存具有容错性，原因在于如果RDD的任何分区丢失，就会使用原始转换，自动重新计算。
可扩展性
按照定义，MapReduce和Spark都可以使用HDFS来扩展。那么，Hadoop集群能变得多大呢?
据称雅虎有一套42000个节点组成的Hadoop集群，可以说扩展无极限。最大的已知Spark集群是8000个节点，不过随着大数据增多，预计集群规模也会随之变大，以便继续满足吞吐量方面的预期。
安全
Hadoop支持Kerberos身份验证，这管理起来有麻烦。然而，第三方厂商让企业组织能够充分利用活动目录Kerberos和LDAP用于身份验证。同样那些第三方厂商还为传输中数据和静态数据提供数据加密。
Hadoop分布式文件系统支持访问控制列表(ACL)和传统的文件权限模式。Hadoop为任务提交中的用户控制提供了服务级授权(Service Level Authorization)，这确保客户拥有正确的权限。
Spark的安全性弱一点，目前只支持通过共享密钥(密码验证)的身份验证。Spark在安全方面带来的好处是，如果你在HDFS上运行Spark，它可以使用HDFS ACL和文件级权限。此外，Spark可以在YARN上运行，因而能够使用Kerberos身份验证。
总结
Spark与MapReduce是一种相互共生的关系。Hadoop提供了Spark所没有的功能特性，比如分布式文件系统，而Spark 为需要它的那些数据集提供了实时内存处理。完美的大数据场景正是设计人员当初预想的那样：让Hadoop和Spark在同一个团队里面协同运行。