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

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

В предишния ми блог на Урок за HBase , Обясних какво е HBase и неговите характеристики. Също така споменах казуса на Facebook messenger, за да ви помогне да се свържете по-добре. Сега продължаваме напред в нашата , Ще ви обясня модела на данни за HBase и HBase Architecture.Преди да продължите напред, трябва също да знаете, че HBase е важна концепция, която представлява неразделна част от за сертифициране на големи данни Hadoop.

Важните теми, през които ще ви преведа в този блог за архитектурата на HBase, са:

• Модел на данни за HBase
• HBase Architecture и това са компоненти
• Механизъм за запис на HBase
• Механизъм за четене на HBase
• Механизми за оптимизиране на ефективността на HBase

Нека първо разберем модела на данни за HBase. Помага на HBase за по-бързо четене / писане и търсене.

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

Както знаем, HBase е ориентирана към колони база данни NoSQL. Въпреки че изглежда подобно на релационна база данни, която съдържа редове и колони, но не е релационна база данни. Релационните бази данни са ориентирани към редове, докато HBase е ориентирана към колона. И така, нека първо разберем разликата между базирани на колони и базирани на редове бази данни:

Бази данни, ориентирани към редове срещу колони:

• Базите данни, ориентирани към редове, съхраняват записи на таблици в последователност от редове. Докато базирани на колони бази даннисъхранявайте записи на таблици в последователност от колони, т.е.записите в колона се съхраняват в съседни места на дискове.

За да го разберем по-добре, нека вземем пример и да разгледаме таблицата по-долу.

Ако тази таблица се съхранява в база данни, ориентирана към редове. Той ще съхранява записите, както е показано по-долу:

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

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

В бази данни, ориентирани към редове, данните се съхраняват на базата на редове или кортежи, както можете да видите по-горе.

Докато базирани на колони бази данни съхраняват тези данни като:

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

В бази данни, ориентирани към колона, всички стойности на колоните се съхраняват заедно, както стойностите на първата колона ще се съхраняват заедно, след това стойностите на втората колона ще се съхраняват заедно и данните в други колони се съхраняват по подобен начин.

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

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

• Маси : Данните се съхраняват във формат на таблица в HBase. Но тук таблиците са във формат, ориентиран към колони.
• Ред Ключ : Редовите клавиши се използват за търсене на записи, които правят търсенето бързо. Би ви било любопитно да знаете как? Ще го обясня в частта за архитектурата, движеща се напред в този блог.
• Колона Семейства : Различни колони се комбинират в семейство колони. Тези семейства колони се съхраняват заедно, което прави процеса на търсене по-бърз, защото данните, принадлежащи към едно и също семейство колони, могат да бъдат достъпни заедно в едно търсене.
• Колона Квалификации : Името на всяка колона е известно като нейния квалификатор на колона.
• Клетка : Данните се съхраняват в клетки. Данните се изхвърлят в клетки, които са конкретно идентифицирани от квалификаторите на ред и колона.
• Клеймо за време : Timestamp е комбинация от дата и час. Винаги, когато данните се съхраняват, те се съхраняват със своя клеймо за време. Това улеснява търсенето на определена версия на данните.

По по-прост и разбираем начин можем да кажем, че HBase се състои от:

• Комплект маси
• Всяка таблица със семейства колони и редове
• Редовият ключ действа като първичен ключ в HBase.
• Всеки достъп до таблици HBase използва този първичен ключ
• Всеки квалификатор на колона, присъстващ в HBase, означава атрибут, съответстващ на обекта, който се намира в клетката.

След като вече знаете за HBase Data Model, нека видим как този модел на данни попада в съответствие с HBase Architecture и го прави подходящ за голямо съхранение и по-бърза обработка.

HBase Architecture: Компоненти на HBase Architecture

HBase има три основни компонента, т.е. Сървър на HMaster , HBase регион сървър, региони и Зоопарк .

Фигурата по-долу обяснява йерархията на архитектурата HBase. Ще говорим за всеки един от тях поотделно.

размита логика в изкуствения интелект

Сега, преди да отидем в HMaster, ще разберем регионите, тъй като всички тези сървъри (HMaster, регионален сървър, Zookeeper) са поставени да координират и управляват региони и да извършват различни операции в регионите. Така че би ви било любопитно да знаете кои са регионите и защо са толкова важни?

HBase архитектура: Регион

Регионът съдържа всички редове между началния ключ и крайния ключ, присвоени на този регион. Таблиците HBase могат да бъдат разделени на няколко региона по такъв начин, че всички колони от семейство колони да се съхраняват в един регион. Всеки регион съдържа редовете в сортиран ред.

Много региони са присвоени на Регионален сървър , който е отговорен за обработката, управлението, изпълнението на операции за четене и запис на този набор от региони.

И така, завършвайки по по-опростен начин:

• Таблица може да бъде разделена на няколко региона. Регионът е сортиран диапазон от редове, съхраняващи данни между начален ключ и краен ключ.
• Регионът има размер по подразбиране 256MB, който може да бъде конфигуриран според нуждите.
• Група региони се обслужва на клиентите от регионален сървър.
• Регионалният сървър може да обслужва приблизително 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 Server, изпраща непрекъснато сърдечен ритъм на редовен интервал до Zookeeper и той проверява кой сървър е жив и наличен, както е споменато в горното изображение. Той също така предоставя известия за грешки на сървъра, така че да могат да бъдат изпълнени мерки за възстановяване.
• Позовавайки се на горното изображение, което можете да видите, има неактивен сървър, който действа като резервно копие за активен сървър. Ако активният сървър се провали, той идва за спасяване.
• Активният HMaster изпраща сърдечни удари на Zookeeper, докато неактивният HMaster слуша известието, изпратено от активен HMaster. Ако активният HMaster не успее да изпрати сърдечен ритъм, сесията се изтрива и неактивният HMaster става активен.
• Докато ако регионален сървър не успее да изпрати сърдечен ритъм, сесията е изтекла и всички слушатели са уведомени за това. След това HMaster извършва подходящи действия за възстановяване, които ще обсъдим по-късно в този блог.
• Zookeeper поддържа и пътя на .META Server, който помага на всеки клиент при търсене на който и да е регион. Клиентът първо трябва да провери с .META Server, в кой регионален сървър принадлежи регион, и той получава пътя на този регионален сървър.

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

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

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

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

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

Това изображение по-долу показва компонентите на регионален сървър. Сега ще ги обсъдя отделно.

Регионалният сървър поддържа различни региони, работещи в горната част на . Компонентите на регионален сървър са:

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

Сега, след като познаваме основните и второстепенни компоненти на HBase Architecture, ще обясня механизма и техните съвместни усилия в това. Независимо дали става въпрос за четене или писане, първо трябва да търсим от къде да четем или къде да напишем файл. Така че, нека разберем този процес на търсене, тъй като това е един от механизмите, които правят HBase много популярен.

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

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

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

За бъдещи справки клиентът използва кеша си, за да извлече местоположението на META таблицата и преди това прочетения регион на сървъра за ключ на ред. Тогава клиентът няма да се позовава на META таблицата, докато и освен ако няма пропуск, защото регионът е изместен или преместен. След това отново ще поиска до META сървъра и ще актуализира кеша.

Както всеки път, клиентите не губят време в извличането на местоположението на регионалния сървър от META сървъра, като по този начин това спестява време и ускорява процеса на търсене. Сега, нека ви разкажа как се пише в HBase. Какви са компонентите, участващи в него и как са включени?

разлика между заменяне и претоварване в java

HBase архитектура: HBase Write Механизъм

Това изображение отдолу обяснява механизма за запис в HBase.

Механизмът за запис преминава през следния процес последователно (вижте горното изображение):

Етап 1: Всеки път, когато клиентът има заявка за запис, клиентът записва данните в WAL (Write Ahead Log).

• След това редакциите се добавят в края на файла WAL.
• Този WAL файл се поддържа във всеки регионален сървър и регионалният сървър го използва за възстановяване на данни, които не са ангажирани на диска.

Стъпка 2: След като данните бъдат записани в WAL, те се копират в MemStore.

Стъпка 3: След като данните бъдат поставени в MemStore, клиентът получава потвърждение.

Стъпка 4: Когато MemStore достигне прага, той изхвърля или записва данните в HFile.

Сега нека да се потопим дълбоко и да разберем как MemStore допринася в процеса на писане и какви са неговите функции?

HBase Write Механизъм- MemStore

• MemStore винаги актуализира данните, съхранявани в него, в лексикографски ред (последователно в речник) като сортирани KeyValues. Има едно MemStore за всяко семейство колони и по този начин актуализациите се съхраняват по сортиран начин за всяко семейство колони.
• Когато MemStore достигне прага, той изхвърля всички данни в нов HFile по сортиран начин. Този HFile се съхранява в HDFS. HBase съдържа множество HFiles за всяко семейство колони.
• С течение на времето броят на HFile нараства, тъй като MemStore зарежда данните.
• MemStore също запазва последния записан пореден номер, така че Master Server и MemStore и двамата знаят, какво е извършено до момента и откъде да започнем. Когато регионът се стартира, се чете последният пореден номер и от този номер започват нови редакции.

Както обсъждах няколко пъти, че HFile е основното постоянно съхранение в HBase архитектура. Най-накрая всички данни са ангажирани с HFile, който е постоянното хранилище на HBase. Затова нека разгледаме свойствата на HFile, което го прави по-бързо за търсене по време на четене и писане.

HBase архитектура: HBase Write Механизъм- HFile

• Записите се поставят последователно на диска. Следователно движението на главата за четене и запис на диска е много по-малко. Това прави механизма за писане и търсене много бърз.
• Индексите HFile се зареждат в паметта всеки път, когато се отваря HFile. Това помага при намирането на запис в едно търсене.
• Трейлърът е указател, който сочи към мета блока на HFile. Написано е в края на ангажирания файл. Той съдържа информация за времеви клеймо и филтри за цъфтеж.
• Bloom Filter помага при търсене на двойки ключови стойности, той пропуска файла, който не съдържа необходимия клавиш row. Timestamp също помага при търсене на версия на файла, помага при пропускане на данните.

След познаване на механизма за запис и ролята на различни компоненти за ускоряване на писането и търсенето. Ще ви обясня как работи механизмът за четене в HBase архитектура? След това ще преминем към механизмите, които увеличават производителността на HBase като уплътняване, разделяне на регион и възстановяване.

HBase архитектура: Прочетете Механизъм

Както е обсъдено в нашия механизъм за търсене, първо клиентът извлича местоположението на регионалния сървър от .META Server, ако клиентът го няма в кеш паметта си. След това преминава през последователните стъпки, както следва:

• За четене на данните скенерът първо търси клетката ред в кеша на блокове. Тук се съхраняват всички наскоро прочетени двойки ключови стойности.
• Ако Scanner не успее да намери необходимия резултат, той се премества в MemStore, тъй като знаем, че това е кеш паметта за запис. Там той търси най-скоро написаните файлове, които все още не са изхвърлени в HFile.
• Най-накрая той ще използва филтри за разцвет и кеш памет, за да зареди данните от HFile.

Досега съм обсъждал механизма за търсене, четене и запис на HBase. Сега ще разгледаме механизма на HBase, който прави търсенето, четенето и писането бързо в HBase. Първо, ще разберем Уплътняване , което е един от тези механизми.

HBase архитектура: Уплътняване

HBase комбинира HFiles, за да намали съхранението и да намали броя търсения на диска, необходими за четене. Този процес се нарича уплътняване . Compaction избира някои HFiles от регион и ги комбинира. Има два вида уплътняване, както можете да видите на горното изображение.

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

c срещу c ++ срещу java

Но по време на този процес входно-изходните дискове и мрежовият трафик могат да бъдат претоварени. Това е известно като напишете усилване . Така че, обикновено се планира по време на ниско време на пиково натоварване.

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

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

Фигурата по-долу илюстрира механизма за разделяне на региони.

Всеки път, когато даден регион стане голям, той се разделя на два дъщерни региона, както е показано на горната фигура. Всеки регион представлява точно половината от родителския регион. След това това разделяне се докладва на HMaster. Това се обработва от същия регионален сървър, докато HMaster ги разпредели към нов регионален сървър за балансиране на натоварването.

Придвижвайки се надолу по линията, не на последно място, ще ви обясня как HBase възстановява данни след неуспех. Както знаем това Възстановяване на неуспех е много важна характеристика на HBase, като по този начин ни уведомете как HBase възстановява данни след повреда.

HBase архитектура: HBase Crash и Възстановяване на данни

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

Надявам се, че този блог би ви помогнал да подцените HBase Data Model & HBase Architecture. Надявам се да ви е харесало. Сега можете да се свържете с характеристиките на HBase (което обясних в предишния си Урок за HBase блог) с HBase Architecture и разберете как работи вътрешно. След като вече знаете теоретичната част на HBase, трябва да преминете към практическата част. Имайки това предвид, следващият ни блог на ще обяснява проба HBase POC .

Сега, след като разбрахте архитектурата HBase, разгледайте от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение по сертифициране на големи данни Hadoop на Edureka помага на обучаващите се да станат експерти в HDFS, прежди, MapReduce, Pig, Hive, HBase, Oozie, Flume и Sqoop, като използват случаи в реално време за търговия на дребно, социални медии, авиация, туризъм, финанси.

Имате въпрос към нас? Моля, споменете го в раздела за коментари и ние ще се свържем с вас.