Differences between running MapReduce locally and in a distributed environment - MaxCompute

Le mode local vous permet de déboguer une tâche MapReduce sur votre machine avant de la soumettre à un cluster distribué. Au lieu de redéployer le code sur le cluster à chaque modification, exécutez la tâche localement avec l'indicateur -local et inspectez immédiatement les résultats.

Fonctionnement

Ajoutez l'indicateur -local à la commande jar pour exécuter la tâche localement. Le client MaxCompute :

Télécharge les métadonnées et les données de la table d'entrée, les métadonnées de la table de sortie ainsi que toutes les ressources requises depuis MaxCompute vers un répertoire local nommé warehouse.
Exécute plusieurs tâches map et reduce séquentiellement (et non en parallèle).
Écrit les résultats dans un fichier situé dans le répertoire warehouse.

Lors des exécutions suivantes, si la table d'entrée et les ressources sont déjà présentes dans warehouse, le client les lit directement sans nouveau téléchargement.

Remarque

Le téléchargement des données depuis MaxCompute n'est possible que pour les tâches MapReduce exécutées en mode local.

Mode local contre mode distribué

Dimension	Mode local	Mode distribué
Nombre de lignes d'entrée	Maximum de 100 lignes	Aucune limite
Taille des ressources	Aucune limite	Limitée (voir Limites de MapReduce)
Sécurité	Aucune restriction	Le bac à sable Java s'applique à MapReduce et aux fonctions définies par l'utilisateur (UDF)

Exécuter une tâche en mode local

L'exemple suivant exécute le programme WordCount sur la table wc_in et écrit la sortie dans wc_out.

Étape 1 : Exécuter la commande jar

odps:my_project> jar -l com.aliyun.odps.mapred.example.WordCount wc_in wc_out

Pour consulter l'intégralité du code exemple WordCount, reportez-vous à la rubrique WordCount.

Étape 2 : Vérifier la sortie

Une exécution réussie affiche un résumé avec des compteurs :

Summary:
counters: 10
    map-reduce framework
            combine_input_groups=2
            combine_output_records=2
            map_input_bytes=4
            map_input_records=1
            map_output_records=2
            map_output_[wc_out]_bytes=0
            map_output_[wc_out]_records=0
            reduce_input_groups=2
            reduce_output_[wc_out]_bytes=8
            reduce_output_[wc_out]_records=2
OK

Étape 3 : Vérifier les résultats dans le répertoire warehouse

La première exécution crée un répertoire warehouse dans le chemin actuel, avec la structure suivante :

<warehouse>
   |____my_project (project directory)
          |____ <__tables__>
          |       |__wc_in (table data directory)
          |       |      |____ data (file)
          |       |      |
          |       |      |____ <__schema__> (file)
          |       |__wc_out (table data directory)
          |               |____ data (file)
          |               |
          |               |____ <__schema__> (file)
          |
          |____ <__resources__>
                  |
                  |___table_resource_name (table resource)
                  |         |____<__ref__>
                  |
                  |___ file_resource_name (file resource)

Les répertoires situés au même niveau que my_project représentent les projets.
Les répertoires situés au même niveau que wc_in et wc_out représentent les tables de données. Les données de table lues ou écrites par la commande jar sont stockées à ce niveau.

Vérification des données d'entrée wc_in

Le fichier <__schema__> contient les métadonnées de la table. Pour wc_in :

my_project.wc_in,key:STRING,value:STRING

Le fichier data contient les lignes téléchargées :

0,2

Le client a téléchargé les métadonnées et une partie des données de la table depuis MaxCompute, puis les a enregistrées dans ces fichiers. Lors de la prochaine exécution, les données seront lues directement depuis wc_in sans nécessiter de nouveau téléchargement.

Vérification des données de sortie wc_out

Schéma de wc_out :

my_project.wc_out,key:STRING,cnt:BIGINT

Une fois la tâche terminée, le fichier data contient les résultats :

0,1
2,1

Format du fichier schema

Le fichier <__schema__> définit la structure de la table :

project=local_project_name
table=local_table_name
columns=col1_name:col1_type,col2_name:col2_type
partitions=p1:STRING,p2:BIGINT    -- optional

Règles de formatage :

Séparez le nom d'une colonne et son type par deux-points (:).
Séparez les colonnes par une virgule (,).
Déclarez project_name.table_name au début du fichier, séparé des définitions de colonnes par une virgule. Exemple : project_name.table_name,col1_name:col1_type,col2_name:col2_type

Notes d'utilisation

Modifiez directement les fichiers <__schema__> et data pour fournir des données de test personnalisées sans avoir à les télécharger depuis MaxCompute.
Si le client détecte qu'un répertoire de table existe déjà dans warehouse, il ignore le téléchargement pour cette table. Cela signifie qu'un répertoire de table local peut faire référence à une table qui n'existe pas dans MaxCompute.

Étapes suivantes

WordCount — code exemple complet pour l'exemple WordCount utilisé dans cette rubrique
Limites de MapReduce — taille des ressources et autres limites applicables en mode distribué