Като начало ще предположа, че знаете как да свързвате работни места в MapReduce. Ако не, вижте http://developer.yahoo.com/hadoop/tutorial/module4.html#chaining за подробности.
Второ, предполагам, че разполагате с разпределено хранилище за ключ/стойност, като Cassandra.
Трето, вашата функция за точкуване няма смисъл за мен. Не бих си помислил, че "един запис оттук, един запис оттам" ще ви уведоми, че те са един и същ човек. Мога да повярвам, че „записите от тук в сравнение със записите от там = оценка дали е едно и също лице или не“. Така че ще предположа, противно на вашето описание, че това е начинът, по който вашата точкова функция всъщност работи.
Сега какъв би бил теоретично добър начин да разрешите проблема си?
Обработвайте регистрационни файлове, поставете в магазина си карта на уникален идентификатор на машината (IP адрес + бисквитка) + период от време за всички регистрирани събития.
Извлечете списък с всички уникални идентификатори на машини. Съхранявайте и това.
Изпълнете MapReduce, където картата взема идентификатор на машина, грабва списъка с всички останали и излъчва всички двойки различни идентификатори на машина, като първият е по-малък от втория. Заявките за редуциране за регистрираните събития на всеки, изчислява резултата и след това, ако резултатът е над прага, излъчва точката от данни, която идентификаторът на по-голямата машина преобразува в по-малката.
Изходът от 3 се предава по канал към редуктор на карта, чиято карта не прави нищо и чиято карта намира за всеки машинен идентификатор най-малкия машинен идентификатор, към който се преобразува.
Изходът от 4 се пренасочва към намаляване на картата, чиято карта взема двойка (идентификатор на машина, каноничен идентификатор на машина), грабва събития от магазина в #1 и ги пренасочва към (идентификатор на канонична машина, останалата част от събитието) и чието намаляване съхранява за каноничен машинен идентификатор (известен още като идентификатор на група), свързаните събития. (По дата, ако искате.)
Добре, това е хубава теория. Къде се обърка?
Проблемът е, че всички двойки идентификатори са твърде много. Този списък може да се окаже от порядъка на 1018, за всеки от които изтегляте регистрационни файлове. Освен ако нямате наистина феноменален хардуер, ще ви свърши процесорната мощност, за да го изчислите. Следователно трябва да намерите евристики, за да го намалите.
Първият и най-простият е, че всеки идентифициран „тези два идентификатора се съпоставят с един и същ“ трябва да се съхранява и използва повторно, когато е възможно.
Второ, след голяма първоначална работа вероятно ще можете да се измъкнете с въпроса „От всички наскоро създадени идентификатори към какво се отнасят?“ Това са кандидати за допълнение към вашето канонично картографиране, което не искате винаги да пресъздавате.
Трето, сигурен съм, че имате представа за "подобен запис". Така че картографирайте записите към някаква група записи и след това при редуциране накарайте всички "достатъчно малки" групи да картографират всички двойки към "евентуално еднакви". Изпратете тези двойки в редуциране на карта, което хваща „възможно едни и същи“ записи и след това създава идентификатор на машина за картографиране за търсене, за да всички „попаднат вероятно еднакви повече от X пъти“. Спестете това. Сега повторете горното, с изключение на това, че в стъпка 2 вие изпращате идентификатор на машината до всички двойки от себе си с друг „възможно е същият“. Този пряк път значително ще намали работата.
Това е обща стратегия, която изисква много работа. Късмет.
person
btilly
schedule
18.07.2013
