App Engine Mapreduce API是否根据最终reduce工作中自己的逻辑决定计算分片大小?
我正在使用App Engine mapreduce API并提供了shard_size
kwarg设置我的mapreduce分片大小。
碎片大小在我的mapreduce作业中特别重要,因为我不希望在执行reduce函数的最后一步时执行任何一个批处理过多的结果。换句话说,我正在硬编码分片大小,以根据系统上的外部约束将用户平均分配。
地图作业看起来很好,但是reducer只使用了我指定的一小部分碎片。
以下是我正在处理的代码的大致轮廓:
SHARD_SIZE = 42
def map_fun(entity):
shard_key = random.randint(1, SHARD_SIZE)
yield (
shard_key,
db.model_to_protobuf(entity).SerializeToString().encode('base64')
)
def reduce_fun(key, entities):
batch = []
for entity in entities:
#check for stuff
batch.append(entity)
expensive_side_effect(batch)
class MyGreatPipeline(base_handler.PipelineBase):
def run(self, *args, **kw):
yield mapreduce_pipeline.MapreducePipeline(
'label'
'path.to.map_fun',
'path.to.reduce_fun',
'mapreduce.input_readers.DatastoreInputReader',
'mapreduce.output_writers.BlobstoreOutputWriter',
mapper_params={
'entity_kind': 'path.to.entity',
'queue_name': 'coolQueue'
},
reducer_params={},
shard_size = SHARD_SIZE
)
map_fun
专门为每个实体分配一个根据分片大小随机确定的分片。我很困惑为什么我的reducer会有比SHARD_SIZE
更少的分片,因为有很多实体,并且重复拾取相同的整数的可能性极小。
答案 0 :(得分:0)
我对你在这里做的事感到困惑。使用地图阶段将内容分组到一个小的分片键上,稍后在缩短时间处理这些键看起来很奇怪。你最终会为每把钥匙做太多的工作,即使你和绘图工作者一样吸引了多少减少工人。
正在处理的“批处理”是随机任意的,因此我假设expensive_side_effect()
不依赖于批处理的内容。为什么不在映射时执行该操作,发出减少的内容可以传递给输出编写器?