-
计数器
-
内置计数器
-
-
排序
-
部分排序：默认情况下，mapreduce根据输入记录的键对数据集进行排序，保证输出的每个文件内部排序。
-
全排序
-
如果用Hadoop输出一个全局排序的文件？最简单的办法是使用一个分区。但是该方法在处理大型文件的时候无法发挥Hadoop分布式优势，效率很低。
-
替代办法
- 首先创建一系列内部排序的文件；其次，串联这些文件；最后，生成全局排序的文件。主要思路是使用一个分区来描述输出的全局排序。例如：可以为待分析文件创建3个分区，在第一分区中，记录单词首字母a-g，第二分区中记录单词首字母h-n，第三分区中记录单词首字母o-z。
- 该方法的关键点在于如何划分各个分区，使数据分部均匀，作业的总体执行时间不会受制于个别reducer。理论上可以通过遍历整个数据集来获取键值分布，但是十分耗时。我们还可以通过采样的方法来获取键值的近似分布。
- Hadoop内置了采样器InputSampler类，实现了sampler接口。该接口有一个成员方法getSample()，被InputSampler的静态方法writePartitionFile()调用，目的是创建一个顺序文件来定义分区的键；顺序文件由TotalOrderPartitioner使用，为排序作业创建分区。
-
-
辅助排序：Mapreduce框架在记录到达reducer之前按键对记录排序，但键所对应的值并没有被排序。甚至在不同的执行轮次中，这些值的排序也不固定，因为它们来自不同的map任务且这些map任务在不同轮次中完成时间各不相同。一般来说，大多数MapReduce程序会避免让reduce函数依赖于值的排序。但是，有时也需要通过特定的方法对键进行排序和分组等以实现对值的排序。
-
-
连接
-
map端连接
- 适用场景：一张表十分小、一张表很大。
- 用法：两份数据中，如果有一份数据比较小，小数据全部加载到内存，按关键字建立索引。大数据文件作为map的输入，对map()函数每一对输入，都能够方便的和已加载到内存的小数据进行连接。把连接结果按key输出，经过shuffle阶段，reduce端得到的就是已经按key分组的，并且连接好了的数据。这种方法，要使用Hadoop中的DistributedCache把小数据分布到各个计算节点，每个map节点都要把小数据加载到内存，按关键字建立索引。
- 注意：各map的输入数据必须先分区并且以特定的方式排序。
-
reduce端连接
- 适用场景：适合大表之间的join。map端按照连接字段进行hash，reduce端完成连接操作。
- 用法：在map阶段，把关键字(业务主键)作为key输出，并在value中标记出数据是来自data1还是data2，标记的目的是用于辅助排序，增加reduce join的效率。因为在shuffle阶段已经自然按key分组，reduce阶段，判断每一个value是来自data1还是data2，在内部分成两组，做填充即可。
-
-
边数据分布
边数据是作业所需的额外的只读数据，以辅助处理主数据集。所面临的挑战在于如何使所有的map或reduce任务都能够方便而高效地使用边数据。
-
分布式缓存
-
用法
- 使用 -files 选项指定待分发的文件，默认存放在本地。
- 使用 -archives 选项向自己的任务中复制存档文件(jar文件、zip文件、tar文件和gzipped tar文件等)，这些文件会被解档到任务节点。
- 使用 -libjars 选项会把jar文件添加到mapper和reducer任务的类路径中。如果作业jar文件并没有包含库jar文件，这点会很有用。
-
工作机制：当作业启动时，Hadoop会把由-files、-archives和-libjars指定的文件复制到HDFS中。在任务运行之前，node manager将文件从HDFS复制到本地缓存或磁盘使任务能够访问文件，称作“资源本地化”。node manager为缓存中的文件维护一个计数器来统计文件的使用情况。仅当文件不在使用中时，才能被删除。当节点缓存的容量超过一定范围（默认10GB）时，根据最近最少使用的原则删除文件来腾出空间。
-
分布式缓存api：如果没有使用GenericOptionsParser，则可以使用Job的api将对象放入分布式缓存中
-
-
