Свинья - пытаясь избежать КРЕСТА

Я обращусь к моему предыдущему вопросу . В основном у меня есть эти два набора данных. И, используя названия мест, я хочу вывести, сколько раз каждое место встречалось в твитах. Ответ, который я получил, был хорош для небольших наборов данных, но представьте, что у меня есть 10 000 площадок и 20 000 сообщений в Твиттере с использованием CROSS, что даст мне связь с 200 млн записей, что довольно много.

Простой набор данных представлен в предыдущем вопросе, а сценарий PIG, который я использую в данный момент, предложен в ответе. Я ищу идеи, как сделать этот подсчет без продукта CROSS. Спасибо!

REGISTER piggybank.jar
venues = LOAD 'venues_mid' USING org.apache.hcatalog.pig.HCatLoader();
tweets = LOAD 'tweets_mid' USING org.apache.hcatalog.pig.HCatLoader();

tweetsReduced = foreach tweets generate text;
venuesReduced = foreach venues generate name;

/* Create the Cartesian product of venues and tweets */
crossed = CROSS venuesReduced, tweetsReduced;

/* For each record, create a regex like '.*name.*' */
regexes = FOREACH crossed GENERATE *, CONCAT('.*', CONCAT(venuesReduced::name, '.*')) AS regex;


/* Keep tweet-venue pairs where the tweet contains the venue name */
venueMentions = FILTER regexes BY text MATCHES regex;

venueCounts = FOREACH (GROUP venueMentions BY venuesReduced::name) GENERATE group, COUNT($1) as counter;
venueCountsOrdered = order venueCounts by counter;

STORE venueCountsOrdered INTO 'Pig_output/venueCountsOrdered_mid.csv'
USING org.apache.pig.piggybank.storage.CSVExcelStorage(',', 'NO_MULTILINE', 'WINDOWS');

tweets.csv

created_at,text,location
Sat Nov 03 13:31:07 +0000 2012, Sugar rush dfsudfhsu, Glasgow
Sat Nov 03 13:31:07 +0000 2012, Sugar rush ;dfsosjfd HAHAHHAHA, London
Sat Apr 25 04:08:47 +0000 2009, at Sugar rush dfjiushfudshf, Glasgow
Thu Feb 07 21:32:21 +0000 2013, Shell gggg, Glasgow
Tue Oct 30 17:34:41 +0000 2012, Shell dsiodshfdsf, Edinburgh
Sun Mar 03 14:37:14 +0000 2013, Shell wowowoo, Glasgow
Mon Jun 18 07:57:23 +0000 2012, Shell dsfdsfds, Glasgow
Tue Jun 25 16:52:33 +0000 2013, Shell dsfdsfdsfdsf, Glasgow

места проведения.csv

city,name
Glasgow, Sugar rush
Glasgow, ABC
Glasgow, University of Glasgow
Edinburgh, Shell
London, Big Ben

hadoop apache-pig cross-product
person Anton Belev    schedule 26.11.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Вместо CROSS вы можете сделать «СОЕДИНЯЙТЕ твиты ПО МЕСТОПОЛОЖЕНИЮ, местам проведения ПО ГОРОДАМ».

Еще одна попытка:

Лучшее, что я могу придумать, это «Написать UDF, который загружает все 10 КБ мест и компилирует один шаблон регулярного выражения для всех названий мест (должен поместиться в основной памяти = 10 КБ * 500 байт). UDF будет принимать твит-сообщение и выводить название места. соответствует. Для каждого твит-сообщения вы будете называть это UDF. Поскольку загрузка 10 000 мест в каждом картографе займет время, вы можете отправить больше твитов-сообщений каждому картографу, иначе вы будете тратить большую часть своего времени на загрузку мест. Я думаю что вы действительно получаете, делая это, так это не производя промежуточный результат в 200 миллионов.

person Bharat Jain    schedule 26.11.2013
comment
Да, но таким образом я буду засчитывать событие только в том случае, если место проведения упоминается в твите, опубликованном в том же городе, что и это место, чего не должно быть. - person Anton Belev; 26.11.2013
comment
Итак, похоже, что это будет мой первый UDF :) ваше решение звучит разумно. Однако, если кто-то придумает решение без UDF, более чем приветствуется поделиться им. - person Anton Belev; 26.11.2013

arrow_upward
1
arrow_downward

UDF может быть более производительным с фронтальной загрузкой ваших данных и прямым выводом мест. Но так как вы запросили решение без UDF. Вы можете выполнить соединение с репликацией фрагментов, так как ваша таблица мест проведения очень мала.

tweets = LOAD 'tweets';
venues = LOAD 'venues';
joined = JOIN tweets by location, venues by city using 'replicated';

Теперь вы можете спроецировать отношение joined с интересующими вас полями. Предлагаемый UDF в основном представляет собой оптимизацию алгоритма реплицированного соединения. Фактически, теперь, когда я думаю об этом, это может быть не более (или менее) производительно в UDF. Я предполагаю, что план выполнения останется точно таким же. Вы можете попробовать оба подхода и посмотреть, какой из них лучше.

person Pradeep Gollakota    schedule 27.11.2013