Специально для обучения администраторов кластера Apache Hadoop сегодня рассмотрим, как улучшить производительность распределенной файловой системы. Зачем перемещать файлы на последний узел в кластере, как оптимизировать управление дисками, а также чем полезно централизованное кэширование в HDFS.
Оптимизация операций ввода-вывода на жестком диске
Преимущества HDFS – распределенной файловой системы Apache Hadoop по сравнению с другими файловыми системами заключаются в ее способности легко масштабироваться и эффективно обрабатывать большие файлы с небольшими метаданными. Однако, чтобы использовать возможности HDFS по максимуму, администратору кластера Apache Hadoop следует предварительно настроить некоторые параметры конфигурации этой распределенной файловой системы. В частности, рекомендуется улучшить производительность операций ввода-вывода, учитывая особенности программно-аппаратного окружения серверов, где развернута HDFS.
Например, операционная система Linux имеет контрольную точку для каждого файла, включая контрольную сумму, время последнего обращения, время создания, пользователя, создавшего файл и прочие метаданные. Приложения смогут получать доступ к данным в HDFS случайным образом. Чтобы избежать обновления метаданных на узле имен (NameNode) при каждом доступе к данным на узле данных (DataNode) точки монтирования для каталогов данных должны быть настроены с параметром noatime. Такое монтирование деактивирует отслеживание времени доступа, повышая производительность операций ввода-вывода.
Дополнительно следует настроить параметры конфигурации apReduce.local.dir и dfs.data.dir так, чтобы они указывали на один каталог на каждом из дисков. Это помогает наиболее эффективно использовать общую емкость ввода-вывода. Не рекомендуется логическое объединение физических областей жестких дисков через LVM (Logical Volume Manager) и RAID-массивы (Redundant Array of Independent Disks) на серверах DataNode или TaskTracker, так как это снижает производительность. Напомним, LVM – это подсистема операционных систем Linux, позволяющая использовать разные области физического жесткого диска или разных жестких дисков как один логический том. А RAID – это технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль для повышения отказоустойчивости и производительности.
Дисковый ввод-вывод является одним из основных узких мест в производительности, поэтому следует свести к минимуму переполнение диска. Для этого нужно убедиться, что Mapper для задания MapReduce использует 70 % памяти кучи для буфера сброса и сжимать его выходные данные с помощью методов сжатия LZO, BZIP, Snappy и пр. По умолчанию выходные данные этапа Map не сжимаются. Чтобы включить сжатие выходных данных шага Map, необходимо установить параметр конфигурации apReduce.map.output.compress в значение true. А параметр конфигурации apReduce.map.output.compress.codec должен быть задан согласно используемому методу сжатия: LZO, BZIP или Snappy. Хотя это сжатие чуть увеличивает накладные расходы на ЦП за счет дополнительного преобразования данных, оно сильно снижает количество операций ввода-вывода на диске и улучшает производительность. Например, при сжатии LZO каждый 1 ГБ выходных данных экономит примерно 3 ГБ операций записи на диск.
Если при выполнении задач Map на диск записывается огромное количество данных, поможет увеличение объема памяти буфера. Когда задача сопоставления не может удерживать данные в памяти, она сбрасывает их на локальный диск, что требует много времени из-за медленных операций ввода-вывода. Чтобы избежать этого, следует настроить параметры io.sort.mb и io.sort.factor для увеличения размера буферной памяти и достижения оптимальной производительности.
Размещение файлов на узлах данных
Если в кластер Apache Hadoop узел имен NameNode находится выше всех остальных в листинге (списке) узлов, все новые создаваемые файлы будут создаваться на узлах, которые находятся ниже, что может стать узким местом. Чтобы обойти это, можно вручную переместить файлы на последний узел. Кроме того, медленные узлы данных могут негативно повлиять на производительность всего кластера. HDFS предоставляет механизм обнаружения и сообщения о медленных узлах данных, которые негативно влияют на производительность кластера. Хотя отказоустойчивая архитектура HDFS предполагает надежность сохранения данных даже при сбое отдельных узлов, медленный DataNode снижает эффективность работы всего кластера. Он продолжает успешно отправлять тактовые импульсы, а потому NameNode перенаправляет клиентов на него. Если включено обнаружение медленных узлов данных, они собирают статистику задержек на своих одноранговых узлах во время конвейеров записи и используют периодическое обнаружение выбросов. NameNode собирает отчеты со всех DataNode и помечает потенциально медленные узлы. Обнаружение медленного DataNode отключено по умолчанию. Чтобы включить обнаружение медленных узлов данных, надо установить параметр конфигурации dfs.datanode.peer.stats.enabled значение true в файле hdfs-site.xml.
<property> <name>dfs.datanode.peer.stats.enabled</name> <value>true</value> </property>
Получить доступ к статистике медленного DataNode можно со страницы JMX NameNode по адресу http://<namenode_host>:50070/jmx или со страницы JMX DataNode по адресу http://<datanode_host>:50075/jmx.
Выделение памяти DataNode и повышение производительности чтения
HDFS поддерживает эффективную запись больших наборов данных в надежное хранилище, а также обеспечивает надежный доступ к данным. Это хорошо работает для пакетных заданий, которые записывают большие объемы постоянных данных. Но многие современные приложения используют память для записи небольших объемов временных данных. Запись блочных данных в память недолговечна, поскольку данные могут быть потеряны из-за перезапуска процесса до того, как они будут сохранены на диск. HDFS пытается своевременно сохранить данные реплики на диск, чтобы снизить риск возможной потери данных.
В DataNode ссылка на память осуществляется с использованием типа хранилища RAM_DISK и политики хранения LAZY_PERSIST. Тип хранилища, связанный с HDFS, идентифицирует базовый носитель данных. А политика хранения памяти LAZY_PERSIST используется для хранения блоков данных в настроенной памяти DataNode.
В HDFS операции чтения проходят через DataNode: когда клиент запрашивает DataNode прочитать файл, узел данных считывает этот файл с диска и отправляет данные клиенту через сокет TCP. Локальное чтение (short-circuit local read) позволяет обойти DataNode, чтобы клиент мог читать файл напрямую. Это возможно только в тех случаях, когда клиент находится рядом с данными. Такое чтение с коротким циклом значительно повышает производительность приложений. Чтобы включить short-circuit local read, следует активировать библиотеку libhadoop.so и внести изменения в конфигурационный файл hdfs-site.xml. Локальное чтение с коротким циклом надо настроить как на узле данных, так и на клиенте.
Централизованное управление кэшем в HDFS
Централизованное кэширование в HDFS включает явное закрепление (explicit pinning), запрос кэшированных блоков для размещения задач и улучшение использования памяти кластера. Явное закрепление предотвращает вытеснение часто используемых данных из памяти. Это пригодится, когда размер рабочего набора превышает размер основной памяти, что характерно для многих рабочих нагрузок HDFS.
Поскольку кэши DataNode управляются NameNode, приложения могут запрашивать набор местоположений кэшированных блоков при принятии решений о размещении задач. Совместное размещение задачи с репликой кэшированного блока повышает производительность чтения.
Когда блок кэшируется DataNode, клиенты могут использовать более эффективный API чтения с нулевым копированием. Поскольку узел данных проверяет контрольную сумму кэшированных данных всего один раз, клиенты почти не несут затрат при использовании этого нового API.
Централизованное кэширование улучшает общее использование памяти кластера. При использовании буферного кеша операционной системы на каждом узле данных повторные чтения блока приведут к тому, что все реплики блока помещаются в буферный кэш. А централизованное управление кэшем позволяет явно закрепить только несколько реплик, сэкономив память.
Директива кэша определяет путь к кэшу, а пул кэша управляет группами директив кэша. Пути могут указывать либо на каталоги, либо на файлы. Каталоги кэшируются нерекурсивно, то есть будут кэшироваться только файлы в списке первого уровня каталога. Директивы кэша также указывают дополнительные параметры, такие как коэффициент репликации кэша и время истечения срока действия. Коэффициент репликации указывает количество реплик блоков для кэширования. Если несколько директив кэша ссылаются на один и тот же файл, применяется максимальный коэффициент репликации кэша. Время истечения указывается в командной строке как время жизни (TTL), которое представляет собой относительное время истечения срока действия в будущем. После истечения срока действия директивы cache она больше не принимается во внимание узлом имен при принятии решений о кэшировании.
Пул кэша – это объект администрирования, который управляет группами директив кэширования. Пулы кэша имеют разрешения, подобные UNIX, которые ограничивают доступ пользователей и групп к пулу. Разрешения на запись позволяют пользователям добавлять и удалять директивы кэша в пул. Разрешения на чтение позволяют пользователям перечислять директивы кэша в пуле, а также дополнительные метаданные. Разрешения на выполнение не используются.
Пулы кэша также используются для управления ресурсами и могут устанавливать максимальный предел памяти, который ограничивает совокупное количество байтов для кэширования директив в пуле. Обычно сумма ограничений пула примерно равна объему совокупной памяти, зарезервированной для кэширования HDFS в кластере. Пулы также отслеживают ряд статистических данных, чтобы помочь пользователям кластера отслеживать, что в настоящее время кэшируется, и определять, что еще следует кэшировать. Пулы также могут устанавливать максимальное время жизни. Это ограничивает максимальное время действия директив, добавляемых в пул.
Для централизованного кэширования HDFS следует включить JNI и настроить конфигурации в файле hdfs-site.xml с учетом лимита заблокированной памяти. Чтобы блокировать блочные файлы в памяти, DataNode использует собственный код JNI в libhadoop.so. Администратор кластера Hadoop может использовать CLI-интерфейс для создания, изменения и перечисления пулов и директив кэша с помощью hdfs-команды cacheadmin. Директивы кэша идентифицируются уникальным неповторяющимся 64-битным целочисленным идентификатором. Идентификаторы не будут использоваться повторно, даже если директива Cache будет удалена. Пулы кэша идентифицируются уникальным строковым именем. Следует сперва создать пул кэша, а затем добавить к нему директиву, используя следующую команду:
hdfs cacheadmin -addPool <name> [-owner <owner>] [-group <group>] [-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]
Если вместо такой тонкой настройки просто добавлять узлы в кластер в рамках горизонтального масштабирования, это приведет к огромным эксплуатационным расходам. Как избежать этого, оптимизировав конфигурации кластера Apache Hadoop, читайте в нашей следующей статье. А освоить администрирование и эксплуатацию Apache Hadoop на практике для эффективного хранения и аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://asirihewage.medium.com/4-effective-tips-to-boost-hdfs-performance-e3a71d1f0a33
- https://www.projectpro.io/article/how-to-ensure-best-performance-for-your-hadoop-cluster/200
- https://docs.cloudera.com/runtime/7.2.8/scaling-namespaces/topics/hdfs-optimizing-performance.html
