好吧，试着回答我自己的问题。
pig似乎没有办法确保将结果一致地分发到文件中。这部分基于文档，部分基于hadoop如何工作的信息，部分基于观察。
当pig执行分区order by（例如，使用parallel子句获取多个reducer）时，它似乎在order by之前的任何内容和order本身之间强制执行一个中间作业。据我所知，pig查看了1-10%的数据（基于中间作业中Map器的数量是加载步骤中Map器数量的1-10%），并获得了要排序的键的抽样分布。
我的猜测/想法是pig计算出密钥分布，然后使用一个从Map器到还原器的自定义分区器。partitioner将一系列键Map到每个reducer，因此它变成了一个简单的词汇比较——“这个记录是否大于我分配的end\u键？”？把它传给下一个减速机。”
当然，有两个因素需要考虑，这基本上意味着pig在不同的数据集上不一致，甚至在同一数据集的重新运行上也不一致。首先，由于pig是在中间工作中对数据进行采样的，所以我认为有可能得到不同的样本，从而得到不同的密钥分布。另外，考虑一个例子，两个不同的数据集具有广泛不同的密钥分布。pig必然会得到不同的分布，因此，如果某一天x键在r-00111部分中，它不一定会在第二天到达那里。
希望这能帮助其他人调查此事。
编辑
我从o'reilly那里找到了一些支持我假设的资源。
一个是关于map-reduce模式。它基本上描述了标准的总订单问题是可以解决的两个通过的方法，一个“分析”阶段和最后的排序阶段。
第二个是关于Pig的订单。上面写着（万一链接死了）：
正如前面在“组”中所讨论的，数据中的值的倾斜是非常常见的。这会影响顺序，就像它对组的影响一样，导致一些减速机比其他减速机花费的时间要长得多。为了解决这一问题，清管器通过减速器平衡输出。它首先对order语句的输入进行采样，以获得密钥分布的估计值。基于此示例，它然后构建一个分区器，该分区器生成一个平衡的总顺序。。。pig分发记录以最小化偏移的方法的一个重要副作用是，它打破了mapreduce约定，即将给定密钥的所有示例发送到同一分区。如果有依赖于此约定的其他处理，请不要使用pig的order语句为其排序数据。。。此外，pig还向管道添加了一个额外的mapreduce作业来执行采样。因为这种采样非常轻量级（它只读取每个块的第一条记录），所以它通常只占用不到总作业时间的5%。