Для практического обучения дата-инженеров и архитекторов Big Data систем сегодня рассмотрим трудности изоляции и распределения в кластере Apache HBase и способы их обхода. С какими проблемами изоляции и сбалансированного распространения данных столкнулись инженеры индийской e-commerce компании Flipkart при организации мультиарендного кластера Apache HBase и как их решили.
Изоляция данных и балансировка нагрузки в Apache HBase
Мы уже писали, что Apache HBase, как многие NoSQL-СУБД, по-своему реализуют ACID-требования к транзакциям. В частности, это отказоустойчивое колоночно-ориентированное мультиверсионное хранилище типа «ключ-значение», которое работает поверх HDFS и обеспечивает возможности Google’вской BigTable для Hadoop, обеспечивает только уровень изоляции «чтение подтверждено». Можно вручную понизить уровень изоляции до «чтения незафиксированных значений», изменив исходный код HBase. Изначально все строки, возвращаемые через любой API доступа, будут состоять из полной строки, которая существовала в какой-то момент в истории таблицы. Это верно для семейств столбцов, т. е. получение полной строки, происходящее одновременно с набором мутаций вернет полную строку, которая существовала в некоторый момент времени между мутациями из этого набора. А состояние строки будет двигаться вперед только по истории ее изменений.
Напомним, HBase хранит данные в строках и столбцах таблиц, но они хранятся принципиально иначе, чем в реляционных базах данных. Каждая таблица разделена на регионы — непересекающиеся смежные подмножества. Регион представляет собой независимую единицу данных, размещенная на узлах кластера, называемых региональными серверами. В памяти регионального сервера размещены регионы, которые обслуживают клиентские вызовы удаленных процедур (RPC) и хранят данные в HDFS. Главный узел в HBase, который координирует работу регионального сервера для назначение региона, балансировки и других операций в кластере, называется HMaster. А узлы, на которых фактические данные хранятся в HDFS, называются узлы данных. Узлы пространства имен (NameNode) создают новые блоки и поддерживают метаданные файловой системы, а также обслуживают вызовы RPC при обнаружении данных с помощью сохраненной метаинформации.
Избранный узел (FavoredNode) – это конструкция HDFS, которая указывает распределенной файловой системе Apache Hadoop, где должны быть размещены блоки для определенного файла. Это влияет на политику размещения блоков HDFS для конкретных создаваемых блоков.
Группа региональных серверов (RSGroup), которые логически сгруппированы для обслуживания несвязанного набора таблиц в HBase, обеспечивают изоляцию на уровне обслуживания RPC. Журнал опережающей записи (WAL, Write Ahead Log) записывает все изменения данных в HBase в последовательном порядке.
В индийской компании Flipkart хранилище HBase активно используется для OLTP-нагрузок с более чем 1,6 петабайтами данных, 8000+ виртуальных ядер и выделенной емкостью RAM 40 ТБ. Из-за многочисленных сценариев использования собственные кластера Apache HBase использовались неоптимально. Возникла потребность в консолидированном, централизованно управляемом многопользовательском кластере HBase с более надежными гарантиями изоляции. Исходное развертывание Apache HBase в Flipkart представлено следующим образом:
- около 100 арендаторов с разной нагрузкой;
- примерно 1300 инстансов с выделенной емкостью более 8000 виртуальных ядер, 40 ТБ ОЗУ, емкость диска 1,6 ПБ с размещенными данными 650 ТБ;
- порядка 1 млн операций чтения и записи в секунду;
- десятки миллионов запросов в секунду с очень низкой задержкой.
В случае мультиарендного кластера сервер одного региона принадлежит одному арендатору и обслуживает регионы из таблиц, принадлежащих этому арендатору. Один региональный сервер и соответствующий узел данных (совместная установка) размещают блоки данных, принадлежащие регионам, из таблиц, принадлежащих одному и тому же арендатору. А ресурсы узлов данных и регионального сервера, такие как ЦП, память, диск и сеть, выделяются арендатору, которому они выделены.
Постановку задачи по изоляции данных в мультиарендном кластере дата-инженеры и администраторы Flipkart сформулировали следующим образом: для каждого региона таблицы, принадлежащего арендатору, все реплики этого региона должны находиться на узлах HBase, принадлежащих этому арендатору. Это важно по следующим причинам:
- Каждый арендатор хочет, чтобы оборудование (ядра ЦП, память, тип хранилища, пропускная способность сети и пр.) соответствовало его потребностям. HBase решает проблемы с ядром и памятью через группы региональных серверов. Это реализует изоляцию уровней обслуживания, но не изолирует данные для арендаторов, особенно для с различным оборудованием для хранения данных (SAN, HDD, SSD и прочие категории дисков).
- Предоставление различного оборудования для обслуживания и данных (региональные сервера и узлы данных) приводит к недостаточно эффективной утилизации оборудования и может снизить производительность. В частности, выборка между узлами сильно зависит от пропускной способности сети.
Решить эту проблему можно с помощью балансировщика нагрузки, который балансирует все регионы на региональных серверах в кластере для оптимального использования ресурсов и помогает выровнять нагрузку на них через равномерное назначение регионов. Есть несколько сценариев назначения региона региональному серверу. Например, при создании таблицы создается и назначается один или несколько регионов, при объединении или разделении регионов, а также когда кластер Apache HBase переходит в состояние дисбаланса. К закрытию или открытию регионов приводят изменения, связанные с репликацией данных и изменения топологии кластера, когда какой-то региональный сервер выходит из строя.
Балансировщиков нагрузки в HBase может быть несколько:
- FavoredNodeLoadBalancer — реализация LoadBalancer, которая назначает предпочтительные узлы для каждого региона. В настоящее время информация об избранных узлах используется при создании файлов HDFS — первичный региональный сервер передает адреса первичных, вторичных и третичных узлов в качестве подсказок API-интерфейсу DistributedFileSystem для создания файлов в файловой системе. Эти узлы рассматриваются HDFS как подсказки для размещения блоков файла. Это устраняет проблему, связанную с чтением с удаленных узлов, позволяя сделать дополнительный региональный сервер основным после восстановления региона. Это обеспечивает постоянную задержку чтения для регионов, даже если их основные региональные серверы перестанут работать.
- RSGroupBasedLoadBalancer — GroupBasedLoadBalancer, используемый, когда настроена группировка региональных серверов. Он балансирует регион на основе членства в группе таблицы. Большинство методов назначения содержат два эксклюзивных пути кода: Online — когда групповая таблица находится в сети и Offline — когда она недоступна. В автономном режиме назначения назначаются на основе кэшированной информации в сервисе синхронизации метаданных Apache Z Если он недоступен, регионы назначаются случайным образом. Как только таблица GROUP назначена, балансировщик переключается в режим Online и затем начинает предоставлять соответствующие назначения для пользовательских таблиц.
- StochasticLoadBalancer – оптимальный балансировщик нагрузки на основе функции затрат, которая зависит от нагрузки на регион и на таблицу, местоположения данных, а также размера MemStore и хранилища файлов.
- SimpleLoadBalancer — принимает решения о размещении и перемещении регионов по серверам регионов. Балансировка нагрузки в кластере будет происходить только при отсутствии переходных регионов и в соответствии с фиксированным периодом времени с использованием BaseLoadBalancer.balanceCluster(Map). При запуске кластера можно использовать массовое назначение для определения расположения всех регионов в кластере, создавая планы выполнения назначения регионов.
Однако, вместо использования готовых классов балансировки нагрузки в кластере Apache HBase, инженеры Flipkart реализовали собственный пользовательский балансировщик нагрузки, основанный на FavoredStochasticBalancer и RSGroupBasedLoadBalancer. Он сохраняет избранные узлы, принадлежащие к одной и той же группе региональных серверов, в метаданных HBase во время назначения региона. Поскольку HBase уже имеет поддержку узлов, то при создании нового H-файла, избранные узлы из метаданных HBase передаются клиенту HDFS. Затем все блоки, созданные для этого H-файла, размещаются в этих избранных узлах, что контролируется уровнем HDFS. Этот подход имеет следующие ограничения, связанные с неравномерным распределением данных, которое может произойти при изменении топологии кластера из-за технического обслуживания, сбоев оборудования и прочих непредвиденных случаев, приводящих к неравномерному распределению назначений избранных узлов. Поскольку FavoredNode — это размещение блока с наилучшими усилиями с помощью слоев HDFS, оно гарантирует размещение блока только при исправном узле данных. Иначе блоки данных могут быть размещены на любом другом узле данных, включая другие узлы данных арендатора. Как обойти эти ограничения, мы рассмотрим далее.
Код курса
NOSQL
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Как обеспечить равномерное распределение данных по регионам и узлам
Когда узел выходит из строя или регионы перемещаются по разным причинам, балансировщик без предпочтительных узлов, рассматривает только основные регионы в операции балансировки для переназначения. Другие регионы, для которых отказавший узел является вторичным или третичным предпочтительным узлом, останутся без назначения. Это вызывает дисбаланс в назначении избранного узла во время работы балансировщика и может привести к неравномерному использованию диска. Кроме того, отказавшие узлы данных, являющиеся предпочтительными, могут привести к распространению данных за пределы арендатора. Про механизмы обеспечения отказоустойчивости кластера Apache HBase мы писали здесь.
Как уже было отмечено выше, в Apache HBase балансировщик StochasticLoadBalancer выполняет балансировку с помощью функции стоимости (RegionCountCostFunction, LocalityCostFunction и др), которая дает значение стоимости от 0 до 1. Это значение умножается на настроенный вес, присвоенный каждой из функций, и суммируется для получения общей стоимости. Генераторы кандидатов, такие как RandomCandidateGenerator, LocalityBasedCandidateGenerator и пр., при вызове возвращают действия перемещения регионов между региональными серверами или их изменения. Как только начинается балансировка, вычисляется первоначальная стоимость, а затем балансировщик идентифицирует кандидатов с помощью генераторов и перемещает заранее определенное количество раз, а затем вычисляет новую стоимость. Если стоимость снижается по сравнению с предыдущим шагом, балансировщик применяет ее к представлению кластера в памяти и повторяет процесс.
Как только балансировщик находит новый региональный спред, называемый планом балансировщика, мастер просит менеджера по назначениям выполнить планы. Таким образом, в этом сценарии распределения данных используется эффективная политика размещения блоков HDFS по предпочтительным узлам FavoredNode. Причем она применяется во время создания блока. Блоки могут быть перенесены из определенных избранных узлов в любые другие узлы данных, если избранный узел неисправен, не работает или находится на обслуживании, входит в состав исключенных узлов, жесткий диск узла данных доступен только для чтения или сам узел данных определяется узлом имен как неработоспособный по разным причинам.
Функции стоимости FavoredDeadNodeCostFunction дает более высокую стоимость, если среди избранных узлов для любых регионов есть отказавшие узлы: увеличивается начальная стоимость и его вероятность срабатывания. Функция стоимости FavoredNodeImbalanceCostFunction дает более высокую стоимость, если существует высокий дисбаланс с точки зрения назначения предпочтительных узлов: увеличивается начальная стоимость балансировщика и его вероятность срабатывания. Сбалансированный сценарий означает, что каждый узел данных является предпочтительным узлом для равного количества регионов.
Генератор кандидатов FavoredNodeIgnoreDeadNodeCandidateGenerator выбирает регион в качестве кандидата, который имеет отказавший узел в качестве одного из избранных узлов. Когда балансировщик берет этот регион и перемещается на другой региональный сервер, это приведет к тому, что отказавший узел не станет одним из предпочтительных узлов, что снизит общую стоимость. Генератор кандидатов FavoredNodeImbalanceCandidateGenerator выбирает регион в качестве кандидата, который может уменьшить дисбаланс среди разброса избранных узлов за счет снижения общей стоимости, т.к. в каждом узле данных предпочтение отдается узлу для равного количества регионов.
Такой подход имеет следующие ограничения:
- количество регионов на региональных серверах, от 10 и более. Если размещено очень мало регионов, вес каждого региона слишком велик для любого расчета асимметрии и не дает хороших результатов.
- основное сжатие данных – распределение данных восстанавливается в соответствии с назначением избранного узла только после основного сжатия, которое перезаписывает файлы и восстанавливает правильные назначения.
- работоспособность узла данных с точки зрения кластера HDFS, например, нахождение в списке исключенных узлов имен, переполнение диска, вывод из эксплуатации и пр, тогда как HBase видит, что региональный сервер работает на совмещенном узле данных, что приводит к утечке данных.
Освойте администрирование и эксплуатацию Apache HBase и других NoSQL-решений для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
