Définition de la taille de fragment mapreduce d'App Engine

Question

L'API Mapreduce d'App Engine décide-t-elle de calculer la taille de partition en fonction de sa propre logique dans le travail final de réduction? J'utilise l'API mapreduce App Engine et j'ai fourni le shard_size kwarg pour définir ma taille de fragment mapreduce.

La taille de la partition est particulièrement importante dans mon travail mapreduce car je ne veux pas traiter trop de résultats dans une exécution donnée de l'étape finale de ma fonction de réduction. En d'autres termes, je suis en train de coder en dur la taille de la partition pour diviser les utilisateurs de façon égale en fonction d'une contrainte externe sur le système.

Le travail de mappage semble très clair, mais le réducteur n'utilise qu'une fraction des fragments que j'ai désignés.

Voici une esquisse du genre de code que je traite avec:

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 attribue spécifiquement chaque entité un tesson qui est déterminée au hasard, selon la taille de tesson. Je suis confus au sujet de pourquoi mon réducteur aurait moins d'éclats que SHARD_SIZE étant donné qu'il y a beaucoup d'entités et il est extrêmement peu probable que les mêmes nombres entiers aient été choisis plusieurs fois.

Answer 1

Je suis curieux de savoir ce que vous faites ici. En utilisant la phase de la carte pour regrouper les éléments sur une petite clé fragmentée, le traitement ultérieur de ces touches à un temps réduit semble étrange. Vous allez vous retrouver avec trop de travail à faire par clé, même si vous engagez autant de travailleurs que vous le faites. Le 'lot' en cours de traitement est arbitrairement arbitraire, donc je suppose que expensive_side_effect() ne dépend pas du contenu du lot. Pourquoi ne pas faire ce travail au lieu de la carte, en émettant quelque chose qu'un réducteur pourrait transmettre à l'écrivain de sortie?