Архитектура HBase: модель данных HBase и механизм чтения / записи HBase

Архитектура HBase

В моем предыдущем блоге на Учебник HBase , Я объяснил, что такое HBase и его особенности. Я также упомянул пример использования мессенджера Facebook, чтобы помочь вам лучше общаться. Теперь продвигаемся дальше в нашем , Я объясню вам модель данных HBase и HBase Architecture.Прежде чем двигаться дальше, вы также должны знать, что HBase - важная концепция, составляющая неотъемлемую часть для сертификации Big Data Hadoop.

Важные темы, которые я расскажу вам в этом блоге об архитектуре HBase:

• Модель данных HBase
• Архитектура HBase и ее компоненты
• Механизм записи HBase
• Механизм чтения HBase
• Механизмы оптимизации производительности HBase

Давайте сначала разберемся с моделью данных HBase. Это помогает HBase в более быстром чтении / записи и поиске.

Архитектура HBase: Модель данных HBase

Как мы знаем, HBase - это база данных NoSQL, ориентированная на столбцы. Хотя это похоже на реляционную базу данных, которая содержит строки и столбцы, но это не реляционная база данных. Реляционные базы данных ориентированы на строки, а HBase - на столбцы. Итак, давайте сначала поймем разницу между столбцовыми и строковыми базами данных:

Строковые и столбцовые базы данных:

• Строковые базы данных хранят записи таблиц в последовательности строк. В то время как базы данных, ориентированные на столбцыхранить записи таблицы в последовательности столбцов, то есть записи в столбце хранятся в смежных местах на дисках.

Чтобы лучше это понять, давайте возьмем пример и рассмотрим таблицу ниже.

Если эта таблица хранится в строковой базе данных. Он будет хранить записи, как показано ниже:

один,Пол Уокер,НАС,231,Галантный,

2, Вин дизель,Бразилия,520,Мустанг

В строковых базах данных данные хранятся на основе строк или кортежей, как вы можете видеть выше.

В то время как базы данных, ориентированные на столбцы, хранят эти данные как:

один,2, Пол Уокер,Вин дизель, НАС,Бразилия, 231,520, Галантный,Мустанг

В базах данных, ориентированных на столбцы, все значения столбцов хранятся вместе, например, значения первого столбца будут храниться вместе, затем значения второго столбца будут храниться вместе, а данные в других столбцах сохранятся аналогичным образом.

• Когда объем данных очень велик, например, в петабайтах или эксабайтах, мы используем подход, ориентированный на столбцы, поскольку данные одного столбца хранятся вместе, и к ним можно получить доступ быстрее.
• В то время как строковый подход сравнительно эффективно обрабатывает меньшее количество строк и столбцов, поскольку строковая база данных хранит данные, это структурированный формат.
• Когда нам нужно обработать и проанализировать большой набор полуструктурированных или неструктурированных данных, мы используем подход, ориентированный на столбцы. Например, приложения, работающие с Онлайн-аналитическая обработка например, интеллектуальный анализ данных, хранилища данных, приложения, включая аналитику и т. д.
• В то время как, Обработка транзакций онлайн такие как банковское дело и финансы, которые обрабатывают структурированные данные и требуют транзакционных свойств (свойств ACID), используют строковый подход.

Таблицы HBase имеют следующие компоненты, показанные на изображении ниже:

как использовать Microsoft Visual Studio

• Столы : Данные хранятся в формате таблицы в HBase. Но здесь таблицы имеют формат столбцов.
• Ряд Ключ : Ключи строк используются для поиска записей, что ускоряет поиск. Вам было бы любопытно узнать, как? Я объясню это в этой части блога, посвященной архитектуре.
• Столбец Семьи : Различные столбцы объединяются в семейство столбцов. Эти семейства столбцов хранятся вместе, что ускоряет процесс поиска, поскольку к данным, принадлежащим одному семейству столбцов, можно получить доступ вместе за один поиск.
• Столбец Отборочные : Имя каждого столбца называется квалификатором столбца.
• Ячейка : Данные хранятся в ячейках. Данные выгружаются в ячейки, которые специально идентифицируются квалификаторами rowkey и column.
• Отметка времени : Отметка времени - это комбинация даты и времени. Всякий раз, когда данные сохраняются, они сохраняются с их меткой времени. Это упрощает поиск определенной версии данных.

Говоря более простым и понятным языком, HBase состоит из:

• Набор столов
• Каждая таблица с семействами столбцов и строками
• Ключ строки действует как первичный ключ в HBase.
• Любой доступ к таблицам HBase использует этот первичный ключ
• Каждый квалификатор столбца, присутствующий в HBase, обозначает атрибут, соответствующий объекту, который находится в ячейке.

Теперь, когда вы знаете о модели данных HBase, давайте посмотрим, как эта модель данных соответствует архитектуре HBase и делает ее пригодной для хранения больших объемов данных и более быстрой обработки.

Архитектура HBase: компоненты архитектуры HBase

HBase состоит из трех основных компонентов: Сервер HMaster , Сервер региона HBase, регионы и Работник зоопарка .

Рисунок ниже объясняет иерархию архитектуры HBase. О каждом из них поговорим индивидуально.

Теперь, прежде чем перейти к HMaster, мы разберемся с регионами, поскольку все эти серверы (HMaster, Region Server, Zookeeper) размещены для координации и управления регионами и выполнения различных операций внутри регионов. Итак, вам было бы любопытно узнать, что такое регионы и почему они так важны?

Архитектура HBase: Область, край

Область содержит все строки между начальной и конечной клавишами, назначенными этой области. Таблицы HBase можно разделить на несколько регионов таким образом, чтобы все столбцы семейства столбцов хранились в одном регионе. Каждый регион содержит строки в отсортированном порядке.

Многие регионы отнесены к Сервер региона , который отвечает за обработку, управление, выполнение операций чтения и записи в этом наборе регионов.

Итак, резюмируя проще:

• Таблицу можно разделить на несколько регионов. Регион - это отсортированный диапазон строк, в которых хранятся данные между начальным и конечным ключами.
• Размер региона по умолчанию составляет 256 МБ, который можно настроить в соответствии с потребностями.
• Группа регионов обслуживается клиентами сервером регионов.
• Сервер регионов может обслуживать клиенту около 1000 регионов.

Теперь, начиная с вершины иерархии, я сначала хотел бы объяснить вам о HMaster Server, который действует аналогично NameNode в HDFS . Затем, двигаясь вниз по иерархии, я проведу вас через ZooKeeper и Region Server.

Архитектура HBase: HMaster

Как показано на изображении ниже, вы можете видеть, что HMaster обрабатывает набор серверов региона, который находится в DataNode. Давайте разберемся, как HMaster это делает.

• HBase HMaster выполняет операции DDL (создание и удаление таблиц) и назначает регионы серверам регионов, как вы можете видеть на изображении выше.
• Он координирует и управляет сервером региона (аналогично тому, как NameNode управляет DataNode в HDFS).
• Он назначает регионы серверам регионов при запуске и повторно назначает регионы серверам регионов во время восстановления и балансировки нагрузки.
• Он отслеживает все экземпляры сервера региона в кластере (с помощью Zookeeper) и выполняет действия по восстановлению, когда любой сервер региона не работает.
• Он предоставляет интерфейс для создания, удаления и обновления таблиц.

HBase имеет распределенную и огромную среду, в которой одного HMaster недостаточно для управления всем. Итак, вам может быть интересно, что помогает HMaster управлять этой огромной средой? Именно здесь на сцену выходит ZooKeeper. После того как мы поймем, как HMaster управляет средой HBase, мы поймем, как Zookeeper помогает HMaster в управлении средой.

Архитектура HBase: ZooKeeper - координатор

Это изображение ниже объясняет механизм координации ZooKeeper.

• Zookeeper действует как координатор внутри распределенной среды HBase. Это помогает поддерживать состояние сервера внутри кластера, взаимодействуя через сеансы.
• Каждый сервер региона вместе с сервером HMaster отправляет непрерывное контрольное сообщение с регулярными интервалами в Zookeeper, и он проверяет, какой сервер активен и доступен, как указано на изображении выше. Он также предоставляет уведомления о сбоях сервера, чтобы можно было выполнить меры по восстановлению.
• Ссылаясь на изображение выше, вы можете видеть, что существует неактивный сервер, который действует как резервная копия для активного сервера. Если активный сервер выходит из строя, он приходит на помощь.
• Активный HMaster отправляет тактовые импульсы Zookeeper, в то время как неактивный HMaster ожидает уведомления, отправленного активным HMaster. Если активный HMaster не может отправить контрольный сигнал, сеанс удаляется, и неактивный HMaster становится активным.
• Если же серверу региона не удается отправить контрольный сигнал, сеанс истекает, и все слушатели уведомляются об этом. Затем HMaster выполняет подходящие действия по восстановлению, которые мы обсудим позже в этом блоге.
• Zookeeper также поддерживает путь к серверу .META, который помогает любому клиенту в поиске любого региона. Клиент сначала должен проверить с .META сервером, какому серверу региона принадлежит регион, и получить путь к этому серверу региона.

Когда я говорил о сервере .META, позвольте мне сначала объяснить вам, что такое сервер .META? Таким образом, вы можете легко связать работу ZooKeeper и .META Server вместе. Позже, когда я объясню вам механизм поиска HBase в этом блоге, я объясню, как они работают в сотрудничестве.

Архитектура HBase: Мета-таблица

• Таблица META - это специальная таблица каталога HBase. Он поддерживает список всех серверов регионов. в системе хранения HBase, как вы можете видеть на изображении выше.
• Глядя на рисунок, можно увидеть, .МЕТА файл поддерживает таблицу в виде ключей и значений. Ключ представляет собой начальный ключ региона и его идентификатор, тогда как значение содержит путь к серверу региона.

Как я уже говорил, сервер региона и его функции, пока я объяснял вам регионы, теперь мы движемся вниз по иерархии, и я сосредоточусь на компоненте сервера региона и его функциях. Позже я расскажу о механизме поиска, чтения, записи и пойму, как все эти компоненты работают вместе.

Архитектура HBase: Компоненты сервера региона

На этом изображении ниже показаны компоненты сервера региона. Теперь я остановлюсь на них отдельно.

Сервер регионов поддерживает различные регионы, работающие поверх . Компоненты сервера региона:

• WAL: Как вы можете заключить из приведенного выше изображения, Write Ahead Log (WAL) - это файл, прикрепленный к каждому серверу региона в распределенной среде. WAL хранит новые данные, которые не были сохранены или сохранены в постоянном хранилище. Он используется в случае невозможности восстановления наборов данных.
• Блокировать кеш: Из приведенного выше изображения ясно видно, что кэш блоков находится в верхней части сервера региона. Он хранит часто читаемые данные в памяти. Если данные в BlockCache использовались не так давно, эти данные удаляются из BlockCache.
• MemStore: Это кеш записи. Он сохраняет все входящие данные перед их записью на диск или в постоянную память. Для каждого семейства столбцов в регионе существует одно хранилище MemStore. Как вы можете видеть на изображении, для региона существует несколько MemStores, поскольку каждый регион содержит несколько семейств столбцов. Перед сохранением на диск данные сортируются в лексикографическом порядке.
• HFile: Из рисунка выше видно, что HFile хранится в HDFS. Таким образом, на диске хранятся фактические ячейки. MemStore передает данные в HFile, когда размер MemStore превышает.

Теперь, когда мы знаем основные и второстепенные компоненты архитектуры HBase, я объясню механизм и их совместные усилия в этом. Будь то чтение или запись, сначала нам нужно найти, откуда читать или куда записывать файл. Итак, давайте разберемся в этом процессе поиска, так как это один из механизмов, который делает HBase очень популярным.

Архитектура HBase: Как инициализируется поиск в HBase?

Как вы знаете, Zookeeper хранит местоположение таблицы META. Всякий раз, когда клиент обращается с запросами чтения или записи к HBase, происходит следующая операция:

1. Клиент получает расположение таблицы META из ZooKeeper.
2. Затем клиент запрашивает расположение на сервере региона соответствующего ключа строки из таблицы META для доступа к нему. Клиент кэширует эту информацию, указав местоположение таблицы META.
3. Затем он получит местоположение строки, запросив соответствующий сервер региона.

Для будущих ссылок клиент использует свой кеш для получения местоположения таблицы META и ранее прочитанного сервера региона ключа строки. Тогда клиент не будет обращаться к таблице META до тех пор, пока не произойдет промах из-за сдвига или перемещения области. Затем он снова запросит сервер META и обновит кеш.

Как и всякий раз, клиенты не тратят время на получение местоположения сервера региона с сервера META, таким образом, это экономит время и ускоряет процесс поиска. Теперь позвольте мне рассказать вам, как происходит написание в HBase. Какие компоненты в нем задействованы и как они задействованы?

Архитектура HBase: HBase Запись Механизм

Это изображение ниже объясняет механизм записи в HBase.

Механизм записи последовательно выполняет следующий процесс (см. Изображение выше):

Шаг 1: Всякий раз, когда клиент получает запрос на запись, клиент записывает данные в WAL (Write Ahead Log).

• После этого изменения добавляются в конец файла WAL.
• Этот файл WAL поддерживается на каждом сервере региона, и сервер региона использует его для восстановления данных, которые не сохраняются на диске.

Шаг 2: Как только данные записываются в WAL, они копируются в MemStore.

Шаг 3: Как только данные помещаются в MemStore, клиент получает подтверждение.

как реализовать хэш-карту

Шаг 4: Когда MemStore достигает порога, он сбрасывает или фиксирует данные в HFile.

Теперь давайте углубимся и поймем, какой вклад MemStore вносит в процесс написания и каковы его функции?

HBase Запись Механизм- MemStore

• MemStore всегда обновляет данные, хранящиеся в нем, в лексикографическом порядке (последовательно по словарю) как отсортированные значения KeyValues. Для каждого семейства столбцов существует одно хранилище MemStore, поэтому обновления хранятся в отсортированном виде для каждого семейства столбцов.
• Когда MemStore достигает порогового значения, он сбрасывает все данные в новый HFile в отсортированном виде. Этот HFile хранится в HDFS. HBase содержит несколько файлов HF для каждого семейства столбцов.
• Со временем количество HFile растет, поскольку MemStore сбрасывает данные.
• MemStore также сохраняет последний записанный порядковый номер, поэтому и Master Server, и MemStore знают, что зафиксировано на данный момент и с чего начать. При запуске региона считывается последний порядковый номер, и с этого номера начинаются новые правки.

Как я уже говорил несколько раз, этот HFile является основным постоянным хранилищем в архитектуре HBase. Наконец, все данные передаются в HFile, который является постоянным хранилищем HBase. Поэтому давайте посмотрим на свойства HFile, которые ускоряют поиск при чтении и записи.

Архитектура HBase: HBase Запись Механизм- HFile

• Записи размещаются на диске последовательно. Следовательно, движение головки чтения-записи диска очень мало. Это делает механизм записи и поиска очень быстрым.
• Индексы HFile загружаются в память всякий раз, когда открывается HFile. Это помогает найти запись за один поиск.
• Трейлер - это указатель, который указывает на мета-блок HFile. Он пишется в конце зафиксированного файла. Он содержит информацию о временных метках и фильтрах Блума.
• Bloom Filter помогает в поиске пар ключ-значение, он пропускает файл, который не содержит требуемого ключа строки. Отметка времени также помогает в поиске версии файла, помогает пропускать данные.

Зная механизм записи и роль различных компонентов в ускорении записи и поиска. Я объясню вам, как механизм чтения работает внутри архитектуры HBase? Затем мы перейдем к механизмам, которые увеличивают производительность HBase, таким как уплотнение, разделение области и восстановление.

Архитектура HBase: Читать механизм

Как обсуждалось в нашем поисковом механизме, сначала клиент получает местоположение сервера региона с сервера .META, если у клиента его нет в кэш-памяти. Затем он выполняет следующие последовательные шаги:

• Для чтения данных сканер сначала ищет ячейку строки в кэше блоков. Здесь хранятся все недавно прочитанные пары ключ-значение.
• Если Scanner не может найти требуемый результат, он перемещается в MemStore, поскольку мы знаем, что это кэш-память записи. Там он ищет самые недавно записанные файлы, которые еще не были выгружены в HFile.
• Наконец, он будет использовать фильтры Блума и блочный кеш для загрузки данных из HFile.

До сих пор я обсуждал механизм поиска, чтения и записи HBase. Теперь мы рассмотрим механизм HBase, который ускоряет поиск, чтение и запись в HBase. Сначала разберемся Уплотнение , который является одним из таких механизмов.

Архитектура HBase: Уплотнение

HBase объединяет HFiles, чтобы уменьшить объем хранилища и уменьшить количество обращений к диску, необходимых для чтения. Этот процесс называется уплотнение . Сжатие выбирает несколько HFiles из региона и объединяет их. Как вы можете видеть на изображении выше, существует два типа уплотнения.

1. Незначительное уплотнение : HBase автоматически выбирает файлы HF меньшего размера и повторно перенаправляет их в файлы HF большего размера, как показано на изображении выше. Это называется незначительным уплотнением. Он выполняет сортировку слиянием для передачи меньших HF-файлов в более крупные HF-файлы. Это помогает в оптимизации места для хранения.
2. Основное уплотнение: Как показано на изображении выше, в основном сжатии HBase объединяет и повторно объединяет меньшие HFiles региона в новый HFile. В этом процессе одинаковые семейства столбцов помещаются вместе в новый HFile. В этом процессе удаляется удаленная и просроченная ячейка. Это увеличивает производительность чтения.

Но во время этого процесса диски ввода-вывода и сетевой трафик могут быть перегружены. Это известно как запись усиления . Таким образом, это обычно планируется в периоды низкой пиковой нагрузки.

Теперь еще один процесс оптимизации производительности, о котором я расскажу: Регион Сплит . Это очень важно для балансировки нагрузки.

Архитектура HBase: Регион Сплит

На рисунке ниже показан механизм разделения региона.

Когда регион становится большим, он делится на две дочерние области, как показано на рисунке выше. Каждый регион представляет ровно половину родительского региона. Затем этот разделение передается в HMaster. Это обрабатывается тем же сервером региона, пока HMaster не выделит их новому серверу региона для балансировки нагрузки.

И последнее, но не менее важное: я объясню вам, как HBase восстанавливает данные после сбоя. Как мы знаем, Восстановление после сбоя - очень важная функция HBase, поэтому дайте нам знать, как HBase восстанавливает данные после сбоя.

Архитектура HBase: Сбой HBase и восстановление данных

• Всякий раз, когда сервер региона выходит из строя, ZooKeeper уведомляет HMaster о сбое.
• Затем HMaster распределяет и выделяет области отказавшего сервера региона многим активным серверам региона. Чтобы восстановить данные MemStore отказавшего сервера региона, HMaster распространяет WAL на все серверы региона.
• Каждый сервер региона повторно выполняет WAL для создания MemStore для семейства столбцов этого отказавшего региона.
• Данные записываются в WAL в хронологическом порядке (в своевременном порядке). Следовательно, повторное выполнение этого WAL означает внесение всех изменений, которые были внесены и сохранены в файле MemStore.
• Итак, после того, как все серверы региона выполнят WAL, данные MemStore для всего семейства столбцов восстанавливаются.

Я надеюсь, что этот блог помог бы вам понять модель данных HBase и архитектуру HBase. Надеюсь, вам понравилось. Теперь вы можете познакомиться с функциями HBase (которые я объяснил в своем предыдущем Учебник HBase блог) с HBase Architecture и понять, как это работает внутри. Теперь, когда вы знаете теоретическую часть HBase, вам следует перейти к практической части. Имея это в виду, наш следующий блог будет объяснять образец HBase POC .

Теперь, когда вы разобрались с архитектурой HBase, ознакомьтесь с от Edureka, надежной компании по онлайн-обучению с сетью из более чем 250 000 довольных учащихся по всему миру. Учебный курс Edureka Big Data по сертификации Hadoop помогает учащимся стать экспертами в области HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, используя примеры использования в реальном времени в области розничной торговли, социальных сетей, авиации, туризма, финансов.

Есть вопрос к нам? Пожалуйста, отметьте это в разделе комментариев, и мы свяжемся с вами.