Централизованное управление кэшем в HDFS¶
В данной главе приведены инструкции по настройке и использованию централизованного управления кэшем в HDFS. Централизованное управление кэшем позволяет указать пути к каталогам или файлам, которые будут кэшироваться HDFS, тем самым повышая производительность приложений, которые неоднократно обращаются к одним и тем же данным.
Обзор¶
Централизованное управление кэшем в HDFS – это точный механизм кэширования, который позволяет указывать пути к каталогам или файлам, которые будут кэшироваться HDFS. NameNode связывается с DataNodes, которые имеют требуемые доступные на диске блоки, и поручает DataNodes кэшировать блоки в кэшах.
Централизованное управление кэшем в HDFS дает много существенных преимуществ:
- Точный кэш предотвращает вытеснение часто используемых данных из памяти. Это особенно важно, когда размер рабочего набора превышает размер оперативной памяти, который является общим для многих рабочих нагрузок HDFS;
- Поскольку кэши данных DataNode управляются NameNode, приложения могут запрашивать набор местоположений кэшированных блоков при принятии решений о размещении задач. Совмещение задачи с кэшированной блочной копией повышает производительность чтения;
- Когда блок кэшируется с помощью DataNode, клиенты могут использовать новый, более эффективный API-интерфейс с нулевой копией. Поскольку проверка контрольных сумм кэшированных данных выполняется DataNode один раз, при использовании этого нового API клиенты могут понести практически нулевые расходы;
- Централизованное кэширование может улучшить общую эффективность использования памяти кластера. Когда используется ОС буферного кэша на каждом DataNode, повторные чтения блока приводят к тому, что все <n> копии блока перемещаются в буферный кэш. При централизованном управлении кэшем точно указывается только <m> копий <n>, тем самым сохраняя память <n-m>.
Кэширование¶
Централизованное управление кэшем полезно:
- Для файлов, к которым неоднократно обращаются. Например, небольшая таблица фактов в Hive, которая часто используется, является хорошим кандидатом для кэширования. И наоборот, кэширование запроса годовой отчетности менее полезно, так как подобные данные, вероятно, могут быть прочитаны только один раз;
- Для смешанной рабочей нагрузки с SLA-производительностью. Кэширование рабочего набора высокоприоритетной рабочей нагрузки гарантирует, что она не конкурирует с низкоприоритетными рабочими нагрузками для дискового ввода-вывода.
Архитектура кеширования¶
На рисунке показана централизованная кэшированная архитектура управления (Рис.72.).

Рис. 72. Архитектура кэширования
В данной архитектуре NameNode отвечает за координацию всех кэш-файлов с неактивными данными в кластере. NameNode периодически получает кэш-отчет от каждого DataNode. Кэш-отчет описывает все блоки, кэшированные в DataNode. NameNode управляет кэшами DataNode с помощью кэш-копий и мгновенных команд uncache.
NameNode запрашивает набор Cache Directives, чтобы определить, какие контуры следует кэшировать. Cache Directives постоянно сохраняются в fsimage и журналах и могут быть добавлены, удалены и изменены с помощью Java и API-интерфейсов командной строки. В NameNode также хранится набор Cache Pools, являющийся административным объектом, который группирует Cache Directives для управления ресурсами, а также для обеспечения прав доступа.
NameNode периодически повторно сканирует пространство имен и актив Cache Directives, чтобы определить, какие блоки нужно кэшировать, а какие нет, и назначает задачи кэширования DataNodes. Повторное сканирование также может быть вызвано действиями пользователя, такими как добавление или удаление Cache Directives или удаление Cache Pools.
Блоки кэша, находящиеся в стадии разрабобтки, поврежденые или неполные, не кэшируются. Если Cache Directives содержит ссылку, адрес ссылки не кэшируется.
В настоящее время кеширование может применяться только к каталогам и файлам.
Терминология кэширования¶
Cache Directive¶
Cache Directive определяет контур для кэширования. Пути могут указывать либо каталоги, либо файлы. Каталоги кэшируются не рекурсивно, то есть кэшируются только файлы в листинге каталога первого уровня.
Cache Directives также указывают дополнительные параметры, такие как фактор репликации кэша и время окончания. Фактор репликации указывает количество блочных реплик в кэше. Если несколько Cache Directives относятся к одному файлу, применяется максимальный коэффициент репликации кэша.
Время окончания задается в командной строке как жизненный период (time-to-live - TTL), который представляет собой относительное время действия в будущем. После истечения срока действия Cache Directive больше не учитывается NameNode при принятии решений кэширования.
Cache Pool¶
Cache Pool - это административный объект, используемый для управления группами директив кэша. Кэш-пулы имеют UNIX-подобные разрешения, которые ограничивают доступ пользователей и групп к пулу. Разрешения на запись позволяют пользователям добавлять и удалять директивы кэша в пул. Разрешения на чтение позволяют пользователям просматривать директивы кэша в пуле и дополнительные метаданные. Execute-разрешение не используется.
Cache Pools также используются для управления ресурсами. Кэш-пулы могут обеспечить максимальный предел памяти, ограничивающий совокупное количество байтов, которые могут быть кэшированы директивами в пуле. Как правило, сумма лимитов пула приблизительно равна суммарной памяти, зарезервированной для кэширования HDFS в кластере. Кэш-пулы также мониторят ряд статистических данных, чтобы помочь пользователям кластера отслеживать, что в настоящее время кэшируется, и определить, что еще нужно кэшировать.
Cache Pools также могут обеспечить максимальный жизненный период, ограничив максимальное время истечения срока действия директив, добавляемых в пул.
Настройка централизованного кэширования¶
Собственные библиотеки¶
Для отгорождения блокировки файлов в памяти, DataNode использует собственный код JNI из libhadoop.so.
Important
Обязательно включите JNI, если используется централизованное управление кешем HDFS
Свойства конфигурации¶
Свойства конфигурации для централизованного кэширования указаны в файле hdfs-site.xml.
Требуемые свойства¶
В настоящее время требуется только одно свойство:
- dfs.datanode.max.locked.memory. Это свойство определяет максимальный объем памяти (в байтах), который будет использовать DataNode для кэширования. Также необходимо увеличить размер “заблокированного объема памяти” ulimit (ulimit -l) пользователя DataNode, чтобы превысить этот параметр (более подробно описано в следующем разделе “Дополнительные свойства”). При настройке данного значения необходимо помнить, что пространство в памяти также понадобится и для других целей, таких как JNM и DataNode, а также страниц кэша операционной системы.
Пример:
<property>
<name>dfs.datanode.max.locked.memory</name>
<value>268435456</value>
</property>
Дополнительные свойства¶
Следующие свойства не являются обязательными, но могут быть заданы в настройках:
dfs.namenode.path.based.cache.refresh.interval.ms число миллисекунд, которое NameNode использует между последующими повторными сканированиями кэша. По умолчанию этот параметр установлен на 300000, что составляет пять минут. Пример:
<property> <name>dfs.namenode.path.based.cache.refresh.interval.ms</name> <value>300000</value> </property>
dfs.time.between.resending.caching.directives.ms NameNode использует это значение как количество миллисекунд между повторным кэшированием директивов. Пример:
<property> <name>dfs.time.between.resending.caching.directives.ms</name> <value>300000</value> </property>
dfs.datanode.fsdatasetcache.max.threads.per.volume DataNode использует это значение как максимальное количество потоков на единицу объема для кэширования новых данных. По умолчанию этот параметр имеет значение 4. Пример:
<property> <name>dfs.datanode.fsdatasetcache.max.threads.per.volume</name> <value>4</value> </property>
dfs.cachereport.intervalMsec DataNode использует это значение как число миллисекунд между отправкой отчета о состоянии кэша в NameNode. По умолчанию этот параметр установлен на 10000, что составляет 10 секунд. Пример:
<property> <name>dfs.cachereport.intervalMsec</name> <value>10000</value> </property>
dfs.namenode.path.based.cache.block.map.allocation.percent Процент Java heap, распределенный по картам кэшированных блоков. Карта кэшированных блоков - это хеш-карта, которая использует связанное хэширование. Доступ к меньшим картам осуществляется медленнее, чем если количество кэшированных блоков велико; большие карты потребляют больше памяти. Значение по умолчанию равно 0,25%. Пример:
<property> <name>dfs.namenode.path.based.cache.block.map.allocation.percent</name> <value>0.25</value> </property>
Ограничения ОС¶
Если выдается сообщение об ошибке “Cannot start datanode because the configured max locked memory size… is more than the datanode’s available RLIMIT_MEMLOCK ulimit”, это означает, что операционная система накладывает более низкое ограничение на объем памяти, который можно заблокировать, чем настроено. Чтобы исправить это, необходимо настроить значение ulimit -l, с которым работает DataNode. Это значение обычно настраивается в файле /etc/security/limits.conf (может варьироваться в зависимости от используемой ОС и дистрибутива).
Вы узнаете, что значение настроено правильно, когда сможете запустить ulimit-l из оболочки и получить либо более высокое значение, чем настроенное, либо строку “unlimited”, что указывает на отсутствие ограничения.
Important
Для ulimit -l характерно выводить ограничение блокировки памяти в килобайтах (КБ), но при этом dfs.datanode.max.locked.memory должно быть указано в байтах.
Например, значение dfs.datanode.max.locked.memory установлено в 128000 байт:
<property>
<name>dfs.datanode.max.locked.memory</name>
<value>128000</value>
</property>
Лучше установить memlock (максимальное адресное пространство с закрытой памятью) на несколько большее значение. Например, чтобы установить memlock на 130 KB (130 000 байт) для пользователя hdfs, необходимо добавить следующую строку в /etc/security/limits.conf:
hdfs - memlock 130
Important
Информация в данном разделе не применяется к развертыванию в Windows. Windows не имеет прямого эквивалента ulimit -l.
Использование Cache Pools и Directives¶
Можно использовать интерфейс командной строки (CLI) для создания, изменения и перечисления Cache Pools и Cache Directives с помощью подкоманды hdfs cacheadmin.
Cache Directives идентифицируются уникальным не повторяющимся 64-битным ID. Идентификаторы не используются повторно, даже если Cache Directive удалена.
Cache Pools идентифицируются по уникальному именю строки.
Сначала следует создать Cache Pools, а затем добавить в него Cache Directives.
Команды Cache Pools¶
addPool¶
Команда добавления нового Cache Pool:
hdfs cacheadmin -addPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]
Функции команды addPool описаны в таблице.
Функция | Описание |
---|---|
<name> | Имя нового Cache Pool |
<owner> | Имя пользователя владельца Cache Pool. По умолчанию используется текущий пользователь |
<group> | Группа, которой назначен Cache Pool. По умолчанию используется имя основной группы текущего пользователя |
<mode> | Восьмеричные разрешения в стиле UNIX, назначенные Cache Pool. По умолчанию установлены 0755 |
<limit> | Максимальное количество байтов, которые в совокупности могут быть кэшированы директивами в Cache Pool. По умолчанию ограничение не установлено |
<maxTtl> | Максимальное допустимое время ожидания для директив, добавляемых в Cache Pool. Значение может быть указано в секундах, минутах, часах и днях, например, 120 s, 30 m, 4 h, 2 d. Допустимыми единицами являются [smhd]. По умолчанию максимальное значение не задано. Значение never указывает, что предела нет |
modifyPool¶
Команда изменения метаданных существующего Cache Pool:
hdfs cacheadmin -modifyPool <name> [-owner <owner>] [-group <group>]
[-mode <mode>] [-limit <limit>] [-maxTtl <maxTtl>]
Функции команды modifyPool описаны в таблице.
Функция | Описание |
---|---|
<name> | Имя требующего изменения Cache Pool |
<owner> | Имя пользователя владельца Cache Pool |
<group> | Группа, которой назначен Cache Pool |
<mode> | Восьмеричные разрешения в стиле UNIX, назначенные Cache Pool |
<limit> | Максимальное количество байтов, которые в совокупности могут быть кэшированы директивами в Cache Pool |
<maxTtl> | Максимальное допустимое время ожидания для директив, добавляемых в Cache Pool. Значение может быть указано в секундах, минутах, часах и днях, например, 120 s, 30 m, 4 h, 2 d. Допустимыми единицами являются [smhd]. По умолчанию максимальное значение не задано. Значение never указывает, что предела нет |
removePool¶
Команда удаления Cache Pool. Также удаляет пути, связанные с ним:
hdfs cacheadmin -removePool <name>
Функции команды removePool описаны в таблице.
Функция | Описание |
---|---|
<name> | Имя удаляемого Cache Pool |
listPools¶
Команда отображает информацию об одном или нескольких Cache Pool, например, имя, владельца, группу, разрешения и прочее:
hdfs cacheadmin -listPools [-stats] [<name>]
Функции команды listPools описаны в таблице.
Функция | Описание |
---|---|
<-stats> | Отображение дополнительной статистики по Cache Pool |
<name> | Если параметр задан, то выдается только упомянутый Cache Pool |
help¶
Отображает подробную информацию о команде:
hdfs cacheadmin -help <command-name>
Функции команды help описаны в таблице.
Функция | Описание |
---|---|
<command-name> | Отображение подробной информации по указанной команде. Если команда не указана, отображается подробная справка по всем командам |
Команды Cache Directives¶
addDirective¶
Команда добавления нового Cache Directive:
hdfs cacheadmin -addDirective -path <path> -pool <pool-name> [-force]
[-replication <replication>] [-ttl <time-to-live>]
Функции команды addDirective описаны в таблице.
Функция | Описание |
---|---|
<path> | Путь к каталогу кэша или файлу |
<pool-name> | Cache Pool, к которому добавляется Cache Directive. Необходимо разрешение для Cache Pool на запись, чтобы добавить новые директивы |
<-force> | Пропуск проверки ограничений ресурсов Cache Pool |
<-replication> | Восьмеричные разрешения в стиле UNIX, назначенные Cache Pool. По умолчанию установлены 0755 |
<limit> | Используемый коэффициент репликации кэша. По умолчанию установлено значение 1 |
<time-to-live> | Продолжительность действия директивы. Значение может быть указано в минутах, часах и днях, например, 30 m, 4 h, 2 d. Допустимыми единицами являются [smhd]. Значение never означает, что директива никогда не истекает. Если параметр не установлен, директива никогда не истекает |
removeDirective¶
Команда удаления Cache Directive:
hdfs cacheadmin -removeDirective <id>
Функции команды removeDirective описаны в таблице.
Функция | Описание |
---|---|
<id> | Идентификатор Cache Directive для удаления. Необходимо разрешение Write Cache Pool, к которому принадлежит директива. Можно использовать команду -listDirectives для отображения списка идентификаторов Cache Directive |
removeDirectives¶
Команда удаления всех Cache Directives по указанному пути:
hdfs cacheadmin -removeDirectives <path>
Функции команды removeDirectives описаны в таблице.
Функция | Описание |
---|---|
<path> | Путь Cache Directives для удаления. Необходимо разрешение Write Cache Pool, к которому относятся директивы. Можно использовать команду -listDirectives для отображения списка Cache Directives |
listDirectives¶
Команда возврата списка Cache Directives:
hdfs cacheadmin -listDirectives [-stats] [-path <path>] [-pool <pool>]
Функции команды listDirectives описаны в таблице.
Функция | Описание |
---|---|
<path> | Список Cache Directives данного пути. Если в <path>, принадлежащему Cache Pool, нет доступа Read, Cache Directive не указывается |
<pool> | Список Cache Directives, относящихся только к данному Cache Pool |
<-stats> | Статистика по Cache Directive указанного пути |