Hadoop «стиль» - Chunking против тысяч (k, v) пар

Question

Я работаю с несколькими большими файлами, которые содержат матрицы данных, соответствующие сетке MODIS НАСА - сетка разбивает поверхность Земли на массив 21 600 x 43 200 пикселей. Этот конкретный набор данных дает одно целочисленное значение на пиксель.

У меня около 200 файлов, один файл в месяц, и мне нужно создать временные ряды для каждого пикселя.

Мой вопрос: для задачи карты, которая принимает один из этих файлов - если я нарезаю сетку на куски, скажем, 24 000 пикселей, и излучать те, которые значения (с местоположением и периодом времени в качестве ключей) или просто излучение Ключ, пара значений для каждого отдельного пикселя, обрабатывая пиксель, как слово в примере подсчета канонического слова?

Чункин будет работать нормально, он просто вводит в мою программу произвольную переменную «размера куски». Я чувствую, что это сэкономит немного времени на iO, но это просто чувство, и я с нетерпением жду реальных информированных мнений!

Answer 1

В проекте Hadoop, над которым я работал, я могу подтвердить, что количество пар, V, V оказывает прямое влияние на нагрузку, время процессора и IO. Если вы сможете ограничить количество кусков и при этом сохранить достаточно масштабируемости для вашей ситуации, я бы, безусловно, попытался бы пойти туда.