计算reducer id用int所带来的问题

	最近在为某行的数据进行构建cube过程中，遇到5亿的数据丢失一条数据导致构建失败的情况，让人摸不着头脑，该条数据为"539019926",刚开始并没有考虑到是数字的特殊性导致的问题，但是在实验室中无论用多大基数的数据量都无法复现此问题，实在是让人摸不着头脑。
	慢慢的我开始怀疑这个数字是特殊的，为啥构建这么多次只有它出错了，只保留一条这一条数据来进行验证。验证结果是，通过该条数据的hashcode来计算的reducerID竟然是负数，

什么鬼，
int reduceId = begin + Math.abs(hash) % span;
这是我们算reduceID的公式，我abs了啊，没有理由为负数。但是很巧合的是，这个数字的hashcode竟然等于Integer.MIN_VALUE,abs(Integer.MIN_VALUE)=Integer.MIN_VALUE。理由如下（负数等于取反码加1）：
-2147483648的二进制正码：10000000000000000000000000000000
-2147483648的二进制反码：01111111111111111111111111111111
-2147483648的二进制反码+1：10000000000000000000000000000000
解决方法很简单，转换成long，或者是& Integer.MAX_VALUE;
所以以后还是要注意，通过hashcode去算reduceId或者partitionId时，要谨防此类问题