Блог

Я хотел бы использовать appengine mapper для перебора диапазона дат (начиная с даты и до даты, передаваемых в качестве свойств конфигурации). Для каждой даты в диапазоне я бы извлекал объекты, которые имеют эту дату в качестве свойства, и работал с этим набором.

Например, если у меня есть следующий набор объектов:

 Key  Date           Value
a    2011/09/09     323
b    2011/09/09     132
c    2011/09/08     354
d    2011/09/08     432
e    2011/09/08     234
f    2011/09/07     423
g    2011/09/07     543
  

Я хотел бы указать диапазон дат 2011/09/09 — 2011/09/07, который создаст три экземпляра mapper для 2011/09/09, 2011/09/08 и 2011/09/07. В свою очередь, они будут запрашивать объекты a b, c d e и f g соответственно и выполнять некоторые операции со значениями. (Каждый из картографов также будет выполнять другие запросы хранилища данных для получения дополнительных данных, отсюда и «бонусный вопрос» ниже)

Предположительно, мне нужно создать пользовательский InputFormat класс, однако я новичок в mapreduce / hadoop, и я надеялся, что у кого-нибудь есть примеры?

Бонусный вопрос: является ли «плохим тоном» использовать dao для загрузки данных в mapper? Другие распределенные вычислительные платформы, с которыми я работал (например, DataSynapse), потребовали бы, чтобы вы распределили все входные данные и предоставили задачу, чтобы предотвратить слишком много конфликтов на сервере данных. Однако с хранилищем данных appengine HR, я полагаю, это не вызывает беспокойства?

В настоящее время невозможно выполнить итерацию по подмножеству объектов заданного типа в реализации mapreduce App Engine. Если объекты составляют большую часть данных, вы можете просто перебирать все и игнорировать нежелательные объекты; если они составляют лишь небольшую часть, вам придется выполнить собственную процедуру обновления с использованием очереди задач.

Основываясь на ответе Ника Джонсона, вам нужно будет извлечь свой диапазон дат из контекста, используя пользовательские параметры. Затем mapper отфильтровывает (игнорирует) объект, который выпадает из диапазона, перед его обработкой.

Но если вы настаиваете на сопоставлении всех объектов данного типа, тогда существует обходное решение, которое в зависимости от ваших требований может быть или не быть осуществимым. Предположим, что вы довольно фиксированы в диапазонах дат (звучит маловероятно, но просто возможно). Затем для каждого ожидаемого диапазона вы создаете соответствующий дочерний вид объекта с родительским ключом (или просто ссылкой, но родительский ключ лучше работает для согласованности — подумайте о транзакции по группе объектов), указывающей на основной объект.

Таким образом, каждая сущность из диапазона получает дочернюю сущность вида, соответствующего этому диапазону. Затем настройте mapper для дочернего вида объекта, соответствующего диапазону, и извлеките его родительский элемент для работы с ним.

Я делаю что-то похожее, но в противоположном направлении и для одного дочернего вида объекта при заполнении моих данных для шаблона объекта индекса отношения. Следовательно, ответ на ваш бонусный вопрос — продолжайте использовать dao или что-то еще, из чего состоит ваш уровень данных.

Хотя первый подход более обоснован, последний может быть осуществим в тех случаях, когда ваши диапазоны не очень динамичны и управляемы. Учитывая бессхемный характер хранилища данных, создание новых типов сущностей не является ни дорогостоящей, ни плохой практикой.