Partition深度解析&一致性hash

Hadoop中Partition深度解析

http://www.tuicool.com/articles/uaQVjqm

旧版 API 的 Partitioner 解析

Partitioner 的作用是对 Mapper 产生的中间结果进行分片，以便将同一分组的数据交给同一个 Reducer 处理，它直接影响 Reduce 阶段的负载均衡。旧版 API 中 Partitioner 的类图如图所示。它继承了JobConfigurable，可通过 configure 方法初始化。它本身只包含一个待实现的方法 getPartition。 该方法包含三个参数， 均由框架自动传入，前面两个参数是key/value，第三个参数 numPartitions 表示每个 Mapper 的分片数，也就是 Reducer 的个数。

MapReduce 提供了两个Partitioner 实 现：HashPartitioner和TotalOrderPartitioner。其中

HashPartitioner 是默认实现，它实现了一种基于哈希值的分片方法，代码如下：

TotalOrderPartitioner 提供了一种基于区间的分片方法，通常用在数据全排序中。 在MapReduce 环境中，容易想到的全排序方案是归并排序，即在 Map 阶段，每个 Map Task进行局部排序；在 Reduce 阶段，启动一个 Reduce Task 进行全局排序。由于作业只能有一个 Reduce Task，因而 Reduce 阶段会成为作业的瓶颈。为了提高全局排序的性能和扩展性， MapReduce 提供了 TotalOrderPartitioner。它能够按照大小将数据分成若干个区间（分片），并保证后一个区间的所有数据均大于前一个区间数据， 这使得全排序的步骤如下：

步骤 3：Reduce 阶段。每个 Reducer 对分配到的区间数据进行局部排序，最终得到全排序数据。

但是不同于数值型的数据，字符串的查找和比较不能按照数值型数据的比较方法。mapreducer采用的Tire tree（关于Tire tree可以参考《字典树(Trie Tree)》）的字符串查找方法。查找的时间复杂度o(m)，m为树的深度，空间复杂度o(255^m-1)。是一个典型的空间换时间的案例。

Tire tree的构建

假设树的最大深度为3，划分为【aaad ，aaaf， aaaeh，abbx】

转 一致性hash和solr千万级数据分布式搜索引擎中的应用

/article/3503891.html

一致性hash就是在这种应用背景提出来的，现在被广泛应用于分布式缓存，比如memcached。下面简单介绍下一致性hash的基本原理。最早的版本 http://dl.acm.org/citation.cfm?id=258660。国内网上有很多文章都写的比较好。如： /article/8400318.html

下面简单举个例子来说明一致性hash。

准备：1、2、3 三台机器

还有待分配的9个数 1、2、3、4、5、6、7、8、9

一致性hash算法架构

步骤

一、构造出来 2的32次方 个虚拟节点出来，因为计算机里面是01的世界，进行划分时采用2的次方数据容易分配均衡。另 2的32次方是42亿，我们就算有超大量的服务器也不可能超过42亿台吧，扩展和均衡性都保证了。

二、将三台机器分别取IP进行hashcode计算（这里也可以取hostname，只要能够唯一区别各个机器就可以了），然后映射到2的32次方上去。比如1号机器算出来的hashcode并且mod (2^32)为 123（这个是虚构的），2号机器算出来的值为 2300420，3号机器算出来为 90203920。这样三台机器就映射到了这个虚拟的42亿环形结构的节点上了。

三、将数据（1-9）也用同样的方法算出hashcode并对42亿取模将其配置到环形节点上。假设这几个节点算出来的值为 1：10，2：23564，3：57，4：6984，5：5689632，6：86546845，7：122，8：3300689，9：135468。可以看出 1、3、7小于123， 2、4、9 小于 2300420 大于 123， 5、6、8 大于 2300420 小于90203920。从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个Cache节点上。如果超过2^32仍然找不到Cache节点，就会保存到第一个Cache节点上。也就是1、3、7将分配到1号机器，2、4、9将分配到2号机器，5、6、8将分配到3号机器。

这个时候大家可能会问，我到现在没有看见一致性hash带来任何好处，比传统的取模还增加了复杂度。现在马上来做一些关键性的处理，比如我们增加一台机器。按照原来我们需要把所有的数据重新分配到四台机器。一致性hash怎么做呢？现在4号机器加进来，他的hash值算出来取模后是12302012。 5、8 大于2300420 小于12302012 ，6 大于 12302012 小于90203920 。这样调整的只是把5、8从3号机器删除，4号机器中加入 5、6。

大家应该明白一致性hash的基本原理了吧。不过这种算法还是有缺陷，比如在机器节点比较少、数据量大的时候，数据的分布可能不是很均衡，就会导致其中一台服务器的数据比其他机器多很多。为了解决这个问题，需要引入虚拟服务器节点的机制。如我们一共有只有三台机器，1、2、3。但是实际又不可能有这么多机器怎么解决呢？把 这些机器各自虚拟化出来3台机器，也就是 1a 1b 1c 2a 2b 2c 3a 3b 3c，这样就变成了9台机器。实际 1a 1b 1c 还是对应1。但是实际分布到环形节点就变成了9台机器。数据分布也就能够更分散一点。如图：

java的hashmap随着数据量的增加也会出现map调整的问题，必要的时候就初始化足够大的size以防止容量不足对已有数据进行重新hash计算。

疫苗：Java HashMap的死循环 http://coolshell.cn/articles/9606.html

一致性哈希算法的优化—-关于如何保正在环中增加新节点时，命中率不受影响 （原拍拍同事scott）http://scottina.iteye.com/blog/650380