Мы собираемся приобрести новое оборудование для использования только для кластера Hadoop, и мы застряли в том, что нам следует приобрести. Предположим, у нас есть бюджет в 5 тысяч долларов, стоит ли покупать две супер-хорошие машины по 2500 долларов за каждую, четыре по 1200 долларов за каждую или восемь по 600 долларов каждая? Будет ли hadoop лучше работать с более медленными машинами или с меньшим количеством более быстрых машин? Или, как и многие другие вещи, «от обстоятельств»? :-)
Если вы можете, я бы посмотрел на использование служб облачной инфраструктуры, таких как Amazon Web Services (AWS) Эластичное вычислительное облако (EC2), по крайней мере, до тех пор, пока вы не решите, что имеет смысл вкладывать средства в собственное оборудование. Легко увлечься покупкой блестящего снаряжения (мне приходится ежедневно сопротивляться). Попробовав перед покупкой в облаке, вы можете многому научиться и ответить на вопрос: подходит ли программное обеспечение моей компании X или структура сопоставления / сокращения с этим набором данных для небольшого, среднего или большого набора серверов. Я запустил несколько комбинаций на AWS, увеличивая, уменьшая, увеличивая и уменьшая их за копейки на доллар в течение нескольких дней. Мы были так довольны нашим тестированием, что решили остаться с AWS и отказаться от покупки большого кластера машин, которые нам нужно охлаждать, обеспечивать питание, поддерживать и т. Д. Типы экземпляров варьируются от:
Стандартные экземпляры
Экземпляры с высоким ЦП
Средний инстанс с высоким ЦП 1,7 ГБ памяти, 5 вычислительных блоков EC2 (2 виртуальных ядра по 2,5 вычислительных блока EC2 каждое), 350 ГБ хранилища экземпляров, 32-разрядная платформа
Экстра-большой инстанс с высоким ЦП 7 ГБ памяти, 20 вычислительных блоков EC2 (8 виртуальных ядер с 2,5 вычислительными блоками EC2 каждое), 1690 ГБ хранилища экземпляров, 64-разрядная платформа
Вычислительный блок EC2 (ECU) - один вычислительный блок EC2 (ECU) обеспечивает процессорную мощность, эквивалентную производительности процессора 1,0–1,2 ГГц 2007 Opteron или 2007 Xeon.
Стандартные экземпляры по требованию Использование Linux / UNIX Использование Windows
Маленький (по умолчанию) 0,10 доллара в час 0,125 доллара в час
Большой 0,40 доллара США в час 0,50 доллара США в час
Extra Large $ 0,80 в час 1,00 $ в час
Инстансы с высокой загрузкой ЦП Использование Linux / UNIX Использование Windows
Средняя 0,20 доллара США в час 0,30 доллара США в час
Extra Large $ 0,80 в час 1,20 $ в час
Извините, что ответ звучит как предложение поставщика, но если ваша среда позволяет вам пойти по этому пути, я думаю, вы будете счастливы и примете гораздо лучшее решение о покупке, если в будущем купите собственное оборудование.
Это полностью зависит от вашей загруженности. Ваша задача очень параллельна? Или у него большой серийный компонент? Если он хорошо масштабируется, вы должны попытаться получить как можно больше ядер за свои деньги. Если он плохо масштабируется, вы должны найти точку, в которой масштабирование нарушается. Затем попробуйте купить самый мощный процессор для такого количества ядер.
Это всего лишь общие рекомендации, но я не думаю, что в Hadoop есть что-то особенное, что предъявляет к нему какие-либо особые требования, выходящие за рамки любой другой структуры параллелизации.
Я не думаю, что вам следует думать о количестве серверов, а о количестве ядер ЦП и объеме памяти. Насколько я помню, hadoop любит память. Чем больше у вас ядер, тем больше рабочих процессов вы можете запускать одновременно.
Я думаю, это будет зависеть от вашей рабочей нагрузки. Насколько хорошо ваши рабочие места распределяются? Меньшее количество больших кусков, вероятно, приведет к меньшему количеству быстрых серверов, тогда как более мелкие задания могут отдать предпочтение более медленным машинам.
Помните также, что очень маленькие кластеры Hadoop просто не работают очень хорошо, особенно в сценариях сбоя. Проблема в том, что многие эвристики настраиваются с предположением, что в кластере будет> 20 машин. Некоторые из этих эвристик просто не работают на очень маленьких кластерах.
Хороший пример (который, возможно, еще не исправлен даже в самых последних выпусках) - это то, что происходит, когда вы пишете блок. Предполагая, что репликация = 3, случайным образом выбираются три узла для размещения реплик. Если один из узлов выходит из строя во время записи, то namenode запрашивается для различных случайных трех узлов. В большом кластере вероятность того, что новые три узла содержат отказавший узел, пренебрежимо мала, но в очень маленьком кластере, например, из 6 узлов, высока вероятность того, что отказавший узел будет в новом списке. Запись не удастся снова и, возможно, даже снова. Этого достаточно, чтобы закончить работу. Исправление очевидно, но вероятность его быстрой интеграции для большинства коммиттеров слишком мала.
У Hadoop пока нет дистрибутива корпоративного уровня, который бы охватывал весь диапазон масштабируемости, как вверх, так и вниз. Возможно, скоро, но еще нет.
Рекомендация использовать EC2 / EMR, пока вы не определитесь со своими потребностями, является отличной. Это не только позволит вам лучше понять ваши ограничения и потребности, но и позволит вам иметь значительно большие кластеры, чем вы говорите о покупке.