cochon incliné rejoindre avec une grande table provoque "taille des métadonnées Split dépassé 10000000"

Nous avons une jointure de porc entre une petite table distincte (16M rangées) et une grande table inclinée (6B lignes). Une jointure régulière se termine en 2 heures (après quelques ajustements). Nous avons essayé using skewed et été en mesure d'améliorer la performance à 20 minutes.cochon incliné rejoindre avec une grande table provoque "taille des métadonnées Split dépassé 10000000"

Cependant, lorsque nous essayons une plus grande table en biais (19B lignes), nous obtenons ce message du travail SAMPLER:

Split metadata size exceeded 10000000. Aborting job job_201305151351_21573 [ScriptRunner] 
at org.apache.hadoop.mapreduce.split.SplitMetaInfoReader.readSplitMetaInfo(SplitMetaInfoReader.java:48) 
at org.apache.hadoop.mapred.JobInProgress.createSplits(JobInProgress.java:817) [ScriptRunner]

Ceci est reproductible à chaque fois que nous essayons using skewed, et ne se produit pas lorsque nous utilisons la jointure régulière.

nous avons essayé de définir mapreduce.jobtracker.split.metainfo.maxsize=-1 et nous pouvons voir qu'il est là dans le fichier job.xml, mais cela ne change rien!

Que se passe-t-il ici? Est-ce un bug avec l'exemple de distribution créé par using skewed? Pourquoi ne pas aider à changer le param à -1?

Source

2013-06-18 ihadanny

a décidé de déposer un bug jira: https://issues.apache.org/jira/browse/PIG-3411, mettra à jour – ihadanny

, nous avons constaté que changer mapreduce.jobtracker.split.metainfo. maxsize est connu pour ne pas fonctionner au niveau du job, seulement au niveau jobTracker, voir ici: https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/UWBMKplvGkg – ihadanny

jamais trouver une solution à ce problème? Nous sommes confrontés à un problème similaire. – KennethJ

La petite table de 1 Mo est suffisamment petite pour tenir dans la mémoire, essayez la jointure répliquée. La jointure répliquée est uniquement Map, ne provoque pas l'étape Réduire comme les autres types de jointure, donc est immunisée contre l'inclinaison dans les clés de jointure. Ça devrait être rapide.

big = LOAD 'big_data' AS (b1,b2,b3); 
tiny = LOAD 'tiny_data' AS (t1,t2,t3); 
mini = LOAD 'mini_data' AS (m1,m2,m3); 
C = JOIN big BY b1, tiny BY t1, mini BY m1 USING 'replicated';

La grande table est toujours la première dans l'instruction.

MISE À JOUR 1: Si une petite table dans sa forme originale ne rentre pas dans la mémoire, que comme une œuvre autour de vous aurait besoin de partitionner votre petite table en partitions qui sont suffisamment petits pour tenir dans la mémoire et que d'appliquer la Même partitionnement à la grande table, j'espère que vous pourriez ajouter le même algorithme de partitionnement au système qui crée une grande table, de sorte que vous ne perdiez pas de temps à le repartitionner. Après le partitionnement, vous pouvez utiliser la jointure répliquée, mais il faudra exécuter le script pig pour chaque partition séparément.

Source

2013-06-18 09:16:01 alexeipab

bonne idée, mais la petite table n'est pas 1MB (question éditée) et ne rentre pas dans le cache hadoop (essayé) – ihadanny

Mis à jour la réponse. Voir la mise à jour 1. – alexeipab

Merci encore, mais je cherche une explication pour le problème original. Ceci est une solution de contournement cool mais je ne vais pas jusqu'à ce que je comprenne ce qui ne va pas avec la jointure conventionnelle – ihadanny

Dans les versions les plus récentes de Hadoop (> = 2.4.0 mais peut-être même plus tôt), vous devriez être en mesure de définir la taille de répartition maximale au niveau de l'emploi en utilisant la propriété de configuration suivante:

mapreduce.job.split .metainfo.maxsize = -1

Source

2014-09-29 14:11:36

cochon incliné rejoindre avec une grande table provoque "taille des métadonnées Split dépassé 10000000"

Répondre

Questions connexes