Минимальные требование для кластера Hadoop(with Spark)
Есть 4 типы ролей в базовом Hadoop кластере: NameNode (и Standby NameNode), JobTracker,TaskTracker, и DataNode. (node - это машина выполняющая конкретную задачу). Большинство машин в Вашем кластере могут выполнять две из этих ролей, функионируя как DataNode (хранилище данных) и TaskTracker (Для обработки данных).
Далее приведена рекомендательная спецификация для DataNode/TaskTrackers в Hadoop кластере:
Приблизительно эти конфигурации стоят от $2000 до $3000. C бюджетом в $100 000 вы получите 2 кластера с 25 нодами в каждом. В очень больших реализациях таких как Yahoo можно увидеть 4000 ноды работающих с 16 PB дискового пространства, 64 ТB ОЗУ(8GB на одну ноду), 32К ядер(по 4 ядра на каждую ноду).
Можно начать с одной датаноды, запустить MapReduce задачи и мониторить использование ресурсов. Увеличте объем данных и добавьте ещё одну ноду чтобы увидеть как смасштабировался кластер и распределилась нагрузка. Приблизительно нужно "4 dual core с 4 GB памяти" datanod-у для 100GB кластера.
Для Hadoop кластера, также можно взять 4GB оперативки и 1 диск на одно ядро CPU. Для задач с большой нагрузкой на диски нужно добавлять больше дисков на 1 СPU. Для операций з большой нагрузкой CPU вычисления можно ставить меньше дисков на 1 CPU. Для задач з нагрузкой на ОЗУ нужно добавлять побольше оперативки. Профилируйте свои приложения для того чтобы узнать какой фактор для вас является лимитирующим.
Очень часто приложения создают очень большие объемы промежуточных данных. Рекомендуется сетевая карта с 2-мя портами или 2 сетевые карты со связанным каналом для обеспечения 2Gbps для одного сервера. Такая конфигурация является более менее терпимой для 12 ТБ данных на 1 ноду. Если объем превышает 12 ТБ, будет полезным связать 4Gbps каннал(4x1Gbps). Кроме того, для тех, кто уже перешел на 10Gigabit локалюную сеть или на Infiniband, это решение может быть полезным для решения сетевых нагрузок. Убедитесь, что ваша операционная система и BIOS поддерживают переключение на 10 Gigabit локалюную сеть.
Когда вычисления требовательны к оперативной памяти, помните, что Java использует 10% для обслуживания виртуальной машины. Рекомендуется сконфигурировать Hadoop с жестким ограничением для того чтобы избежать swap-а на диск. Swap-инг очень сильно влияет на производительность MapReduce задач. Этого можно избежать путём конфигурации серверов с большим количеством оперативной памяти а также настройки соответствующих параметров ядра в большинстве дистрибутивов Linux.
Также очень важно оптимизировать ширину каналов ОЗУ. Например, когда используются dual-channel память, каждая машина должна быть сконфигурирована с парой DIMM. С трёхканальной памятью каждая машина должна именть утроенные модули DIMM. Аналогично, 4-х канальная память должна быть в группах из 4-х DIMM.
Более чем MapReduce
Hadoop намного больше чем HDFS и MapReduce, это всеохватывающая платформа для данных. Он включает много разных продуктов(по факту только MapReduce используется редко). Дополнительные програмные компоненты тоже нужно учитывать при масштабированиии кластера. Apache Hbase, Cloudera Impala, Hive и т.д. должны быть запущены на DataNode для локальной обработки данных.
Hyper-Threading и QPI - желательно. Тесты показывают что Hadood выигривает от обоих.
Dual CPU материнская карта считается стандартом. Общее количество виртуальных ядер должно быть не меньше 16.
Следующая диаграмма показывает как должны быть сконфигурированы сервера в зависимости от рабочих нагрузок:
Далее приведена рекомендательная спецификация для DataNode/TaskTrackers в Hadoop кластере:
- 12-24 1-4TB жерстих диска в JBOD (Just a Bunch Of Disks) конфигурации
- 2 quad-/hex-/octo-core CPUs, 2-2.5GHz
- 64-512GB ОЗУ
- Локальная Гигабитная сеть или 10Gigabit сеть (чем большая плотность хранения тем большая пропускная способность необходима)
- 4–6 1TB жерсткие диски в JBOD конфигурации (1 для OS, 2 для FS [RAID 1], 1 для Apache ZooKeeper, и 1 для Journal ноды)
- 2 quad-/hex-/octo-core CPUs, 2-2.5GHz
- 64-128GB of RAM
- Локальная Гигабитная сеть или 10Gigabit сеть
Рассмотрим ещё одну классификацию конфигурации железа для разных нагрузок:
- Конфигурация для легковесной обработки(1U/сервер): 2 hex-core CPUs, 24-64GB оперативки, и 8 дисков (1TB или 2TB)
- Сбалансированная вычислительная конфигурация (1U/сервер): 2 hex-core CPUs, 48-128GB оперативки, и 12 – 16 дисков (1TB или 2TB) напрямую подключённые с помощью контроллера материнской платы. Они часто доступны как сдвоенные с двумя материнскими платами и 24 дисками в одном корпусе высотой 2U.
- Конфигурация для тяжёлого хранилища (2U/сервер): 2 hex-core CPUs, 48-96GB оперативки, и 16-24 диска (2TB – 4TB). Эта конфигурация вызовет высоких сетевой трафик в случае падений нод или сетевых колизий.
- Конфигурация для интенсивных вычислений(2U/сервер): 2 hex-core CPUs, 64-512GB оперативки, и 4-8 диска (1TB или 2TB)
Также можно посмотреть на эту(более простую) классификацию:
| Medium | High End | |
| CPU | 8 physical cores | 12 physical cores |
| Memory | 16 GB | 48 GB |
| Disk | 4 disks x 1TБ = 4 ТБ | 12 disks x 3TB = 36 TB |
| Network | 1 GB Ethernet | 10 GB Ethernet |
Приблизительно эти конфигурации стоят от $2000 до $3000. C бюджетом в $100 000 вы получите 2 кластера с 25 нодами в каждом. В очень больших реализациях таких как Yahoo можно увидеть 4000 ноды работающих с 16 PB дискового пространства, 64 ТB ОЗУ(8GB на одну ноду), 32К ядер(по 4 ядра на каждую ноду).
Можно запустить кластер(минимум 3 машины) с общим дисковым объемом 500 GB и приблизительно 40GB памяти менее чем за 400 usd/месяц.
Для небольшого кластера можете расположить все head процессы на одной ноде:
NameNode + SecondaryNameNode + JobTracker + Zookeeper + HBaseMaster. Это не сильно хорошое решение потому, что у Вас не будет избыточности ресурсов на этой ноде.
Для старта можете также начать с 2 ядер CPU, 8 GB оперативки и 1 диска на одного Spark воркера(или на 1 СPU). Чем больше оперативки вы дадите ему, тем более счастлив он будет.
Для небольшого кластера можете расположить все head процессы на одной ноде:
NameNode + SecondaryNameNode + JobTracker + Zookeeper + HBaseMaster. Это не сильно хорошое решение потому, что у Вас не будет избыточности ресурсов на этой ноде.
На кластере по больше вы можете разнести head процессы на 3-5 нод. К примеру на одной ноде Вы можете запустить NameNode + Zookeeper. На другой Standby Namenode + Zookeeper + HBaseMaster или JobTracker + Zookeeper + HBaseMaster или Zookeeper + HBaseMaster и т.д.
Можно начать с одной датаноды, запустить MapReduce задачи и мониторить использование ресурсов. Увеличте объем данных и добавьте ещё одну ноду чтобы увидеть как смасштабировался кластер и распределилась нагрузка. Приблизительно нужно "4 dual core с 4 GB памяти" datanod-у для 100GB кластера.
Для Hadoop кластера, также можно взять 4GB оперативки и 1 диск на одно ядро CPU. Для задач с большой нагрузкой на диски нужно добавлять больше дисков на 1 СPU. Для операций з большой нагрузкой CPU вычисления можно ставить меньше дисков на 1 CPU. Для задач з нагрузкой на ОЗУ нужно добавлять побольше оперативки. Профилируйте свои приложения для того чтобы узнать какой фактор для вас является лимитирующим.
Очень часто приложения создают очень большие объемы промежуточных данных. Рекомендуется сетевая карта с 2-мя портами или 2 сетевые карты со связанным каналом для обеспечения 2Gbps для одного сервера. Такая конфигурация является более менее терпимой для 12 ТБ данных на 1 ноду. Если объем превышает 12 ТБ, будет полезным связать 4Gbps каннал(4x1Gbps). Кроме того, для тех, кто уже перешел на 10Gigabit локалюную сеть или на Infiniband, это решение может быть полезным для решения сетевых нагрузок. Убедитесь, что ваша операционная система и BIOS поддерживают переключение на 10 Gigabit локалюную сеть.
Если Hadoop кластер предположительно увеличиться более чем на 20 машин, то рекомендуется распределить его на 2 стойки с 10Gigabit свичом. Если кластер вырастёт более 2-х стоек, то стоит их объединять 40GigE свичом.
После настройки Hadoop клаcтера нужно анализировать рабочие нагрузки для определения узких мест в оборудовании(диск I/O, CPU, Network, ОЗУ). Это даст понимание какие именно дополнительные машины должны быть собраны.
Когда вычисления требовательны к оперативной памяти, помните, что Java использует 10% для обслуживания виртуальной машины. Рекомендуется сконфигурировать Hadoop с жестким ограничением для того чтобы избежать swap-а на диск. Swap-инг очень сильно влияет на производительность MapReduce задач. Этого можно избежать путём конфигурации серверов с большим количеством оперативной памяти а также настройки соответствующих параметров ядра в большинстве дистрибутивов Linux.
Также очень важно оптимизировать ширину каналов ОЗУ. Например, когда используются dual-channel память, каждая машина должна быть сконфигурирована с парой DIMM. С трёхканальной памятью каждая машина должна именть утроенные модули DIMM. Аналогично, 4-х канальная память должна быть в группах из 4-х DIMM.
Более чем MapReduce
Hadoop намного больше чем HDFS и MapReduce, это всеохватывающая платформа для данных. Он включает много разных продуктов(по факту только MapReduce используется редко). Дополнительные програмные компоненты тоже нужно учитывать при масштабированиии кластера. Apache Hbase, Cloudera Impala, Hive и т.д. должны быть запущены на DataNode для локальной обработки данных.
HBase это надёжное, колончасто-ориентированная хранилище. HBase пользователи должны быть осведомлены о ограничении по памьяти связанные с таймаутамы сборщика мусора(GC). Другие JVM колончастые хранилища тоже встречаются с этим. Потому рекомендуется использовать максимум ~16GB памяти в рамках сервера. HBase не требует очень много других ресурсов для запуска на Hadoop, но для поддержки real-time SLAs Вы должны использовать планировщики такие как, fair и capacity вместе с контрольными групами
Linux(cgroup).
Impala использует оперативную память для большинства своих операций, потребляя до 80% доступной памяти от дефолтной конфигурации, так что рекомендуется как минимум 96GB оперативной памяти или более на одну ноду. Пользователи, которые используют Impala рядом с MapReduce задачами могут почитать про "Конфигурацию Impala и MapReduce многопользовательского режима"
Оптимизация под Spark
Оптимизация под Spark
- Если это возможно, то лучше запускать Spark на той же ноде что и HDFS. Самый простой способ, это настроить Spark в standalone mode cluster на той же ноде и правильно настроить использование памяти Spark-ом и Hadoop-ом для избежания проблем(Для Hadoop это опция
mapred.child.java.opts для каждой таски иmapred.tasktracker.map.tasks.maximumandmapred.tasktracker.reduce.tasks.maximum для всех тасок). Как вариант, Вы можете запустить Hadoop и Spark на менеджере ресурсов кластера таких как Mesos, Hadoop YARN. - Если это не возможно, то запускайте Spark на отдельных нодах в той самой сетке что и HDFS.
- Для таких хранилищ данных как HBase, будет предпочительней запускать вычислительные таски на отдельных нодах чтобы избежать проблем с взаимным использованием ресурсов ОЗУ.
Локальный диск
Не смотря на то, что Spark может выполнять много вычислений в памяти, он всё ещё использует диск для сохранения данных, что не вмещаются в ОЗУ так же как и для сохранения промежуточных данных между этапами работы. Рекомендуется иметь 4-8 дисков на 1 ноду, сконфигурированных без RAID(просто отдельные точки монтирования JBOD). Махинации на подобии single-disk-RAID-0 не дают ощутимой производительности. Тесты показывают, что RAID конфигурация даже медленней чем JBOD конфигурация.
Для NameNode желательно использовать RAID 10. Популярные диски: 1TB+SATA 7200RPM.
Они дешевле и больше чем SAS диски. Недостаток в IOPS компенсируется за счёт архитектуры кластера.
В Linux монтируйте диски с параметром noatime для уменьшения ненужных записей. В Spark-е параметре spark.local.dir указывается список локальных дисков. Также нормальным считается, если Вы используете диски на которых работает HDFS.
Память
24GB считается абсолютным минимумом для Hadoop-a. HBase для кластера оказываеться большой неожиданностью и поглощает всю доступную память. Типичный размер 48GB и вплоть до 96GB на воркер. Нужно много места для кеширования блоков в памяти на уровне OS что позволит получить значительно ускорить HBase.
Head nodes требуют часто больше так как они обслуживают весь кластер. 96GB и более желательно использовать. Name Nodes и Secondary Name Nodes обычно используюют больше памяти. Для них желательно использовать 128GB и более. 96GB для них уже не часто используют. Выделяйте память для того чтобы получить приемущество от трёх и четырёх канальной конфигурации.
Также желательно использовать ECC память. Hadoop ганяет терабайты памяти и иногда non-ECC память может порождать ошибки в битах в терабайтных массивах. Отдебажить это очень тяжело.
В вообщем, Spark может быть запущен от 8GB и до сотен гигабайт памяти на одну машину. Лучше выделить почти 75% памяти для Spark-а а остальное оставить для операционной системы.
Также нужно помнить, что JAVA VM не всегда хорошо работает с более чем 200GB ОЗУ. Если у Вас есть возможность приобрести машины с памятью большего объема чем этот, то Вы можете запустить несколько задач JVM на ноду.
Сеть
По опыту, если данные в памяти, то скорость Spark приложений зависит от сети.
Общепринятым является 1GbE на ноду с свичем в стойке и агрегирующим свичом между стойками. Это хорошо работает для небольших кластеров (менее 40 нод). Когда нужно делать тяжелые операции I/O(такие как ETL) то сеть становиться узким местом. 12+дисков с 100MB/s очень легко перенасыщают сеть. Лучше попробывать связать интерфейсы. Это не так просто, но позволит почти удвоить пропускную способность между нодами.
Использование 10Gigabit сети или более является лучшим способом сделать Ваши Spark приложения быстрее. Это особенно важно для "Распределённых групировок" и SQL Join-ов.
Стоимость утраивается на порт. HBase также получает свои бонусы от меньшей задержки.
В целом сеть является наиболее проблемной и трудозатратной частью кластера.
Для Spark приложений есть возможность мониторить нагрузку на сеть с помощью UI (http://<driver-node>:4040).
Для NameNode желательно использовать RAID 10. Популярные диски: 1TB+SATA 7200RPM.
Они дешевле и больше чем SAS диски. Недостаток в IOPS компенсируется за счёт архитектуры кластера.
В Linux монтируйте диски с параметром noatime для уменьшения ненужных записей. В Spark-е параметре spark.local.dir указывается список локальных дисков. Также нормальным считается, если Вы используете диски на которых работает HDFS.
Память
24GB считается абсолютным минимумом для Hadoop-a. HBase для кластера оказываеться большой неожиданностью и поглощает всю доступную память. Типичный размер 48GB и вплоть до 96GB на воркер. Нужно много места для кеширования блоков в памяти на уровне OS что позволит получить значительно ускорить HBase.
Head nodes требуют часто больше так как они обслуживают весь кластер. 96GB и более желательно использовать. Name Nodes и Secondary Name Nodes обычно используюют больше памяти. Для них желательно использовать 128GB и более. 96GB для них уже не часто используют. Выделяйте память для того чтобы получить приемущество от трёх и четырёх канальной конфигурации.
Также желательно использовать ECC память. Hadoop ганяет терабайты памяти и иногда non-ECC память может порождать ошибки в битах в терабайтных массивах. Отдебажить это очень тяжело.
В вообщем, Spark может быть запущен от 8GB и до сотен гигабайт памяти на одну машину. Лучше выделить почти 75% памяти для Spark-а а остальное оставить для операционной системы.
Также нужно помнить, что JAVA VM не всегда хорошо работает с более чем 200GB ОЗУ. Если у Вас есть возможность приобрести машины с памятью большего объема чем этот, то Вы можете запустить несколько задач JVM на ноду.
Сеть
По опыту, если данные в памяти, то скорость Spark приложений зависит от сети.
Общепринятым является 1GbE на ноду с свичем в стойке и агрегирующим свичом между стойками. Это хорошо работает для небольших кластеров (менее 40 нод). Когда нужно делать тяжелые операции I/O(такие как ETL) то сеть становиться узким местом. 12+дисков с 100MB/s очень легко перенасыщают сеть. Лучше попробывать связать интерфейсы. Это не так просто, но позволит почти удвоить пропускную способность между нодами.
Использование 10Gigabit сети или более является лучшим способом сделать Ваши Spark приложения быстрее. Это особенно важно для "Распределённых групировок" и SQL Join-ов.
Стоимость утраивается на порт. HBase также получает свои бонусы от меньшей задержки.
В целом сеть является наиболее проблемной и трудозатратной частью кластера.
Для Spark приложений есть возможность мониторить нагрузку на сеть с помощью UI (http://<driver-node>:4040).
10 GigE Vs 1GigE
Ноды относительно очень быстро могут насытить канал связи посколько каждый диск может выдавать скорость 80 MБ/с последовательного чтения и если на ноде у Вас 8 дисков, то вы можете читать данные со скоростью 640 MБ/с, но с 1 GigE Вы теоретически можете пропускать всего лишь 125 MB/с.
Ноды относительно очень быстро могут насытить канал связи посколько каждый диск может выдавать скорость 80 MБ/с последовательного чтения и если на ноде у Вас 8 дисков, то вы можете читать данные со скоростью 640 MБ/с, но с 1 GigE Вы теоретически можете пропускать всего лишь 125 MB/с.
Ядра СPU
Spark хорошо масштабируется до десятка ядер CPU на одну машину за счёт минимального обмена между потоками. Вероятней всего Вам подойдёт 8-16 ядер на ноду. В зависимости от нагрузки на CPU Ваших задач, возможно, Вам понадобится больше ядер. Если данные в памяти, то в большинстве случаев узким местом стаёт CPU или сеть. Если Вы имеете 500-1000 записей в секунду и нагрузки достаточно просты, то 10-20 ядер будет вполне достаточно.Hyper-Threading и QPI - желательно. Тесты показывают что Hadood выигривает от обоих.
Dual CPU материнская карта считается стандартом. Общее количество виртуальных ядер должно быть не меньше 16.
Коментарі
Дописати коментар