Hadoop的SecondarySorting

这几天项目中使用Hadoop遇到一个问题，对于这样key-value的数据集合：id-biz object，对id进行partition（比如根据某特定的hash算法P），分为a份；使用数量为b的reducer，在reducer里面要使用第三方组件进行批量上传；上传成文件，文件数量为c，但是有两个要

这几天项目中使用Hadoop遇到一个问题，对于这样key-value的数据集合：id-biz object，对id进行partition（比如根据某特定的hash算法P），分为a份；使用数量为b的reducer，在reducer里面要使用第三方组件进行批量上传；上传成文件，文件数量为c，但是有两个要求：

最开始，想到的办法是，为了保证reducer中的批量上传，需要使得传入reducer的key变成一个经过hash算法A计算得到的index，这样就使得reducer中的value是一个包含了数个biz boject的集合的iterator，从而实现在一次reducer调用中批量上传并且提交。在批量上传提交的过程中，按照每上限个（例如1000个）文件提交一次的办法进行，以保证内存占用控制在一定范围内。

如何保证有序？

Hadoop在Reduce之前会自动对key排序，但是上述的情况实际是要根据id来给value排序（因为在map之后key已经变成index了），凡是涉及到要给value排序的，都要使用Hadoop的Secondary Sorting（见stackoverflow链接）。

这张图其实已经可以说明，把value要排序的关键属性放到key里面去，这样key就变成了natural key（上述的index）和secondary key（上述的id）这样两部分组成的一个composite key。

1. Partition：Partition的时候仅使用natural key，保证所有index的数据都分在同一个partition；

JobConf.setPartitionClass(...);

2. Sort：真正给key排序的比较算法要对natural key和secondary key两部分进行排序，从而保证了key在id维度上是有序的，而id和value是一一对应的，因此value也就是有序的。

JobConf.setOutputKeyComparatorClass(...);

3. Group：grouping的比较算法忽略掉secondary key，只对natural keygrouping，使得属于同一index的数据都走到同一个reducer中去。

JobConf.setOutputValueGroupingComparatorClass(...);

总结一下，这样一来，在reducer中，input key是上述这样一个composite key对象，包含了index和id，input value是一个可以遍历的元素为原始biz object类型的对象。

后话：这是Secondary Sorting的过程，可以解决我的问题，但是后来发现，实际上，我的问题并不需要要用这样啰嗦的方式来解决：

这样，既然对于每个partition的数据，都在同一个reducer中得到处理，而reducer中每次reduce方法彼此之间是根据id有序进行，那么就可以在每次调用时把数据放到p中，在p放满时提交一次即可。

测试通过。回头看看，真是刚开始的时候把问题想复杂了。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接《四火的唠叨》

你可能也喜欢：