Тази публикация първоначално беше публикувана чрез blogs.apache.org, ние я публикуваме отново тук в леко променена форма за ваше удобство:
На пръв поглед архитектурата на Apache HBase изглежда следва модел главен/подчинен, при който главният получава всички заявки, но истинската работа се извършва от подчинените. Това всъщност не е така и в тази статия ще опиша какви задачи всъщност се изпълняват от главен и подчинен.
Региони и регионални сървъри
HBase е мениджърът за съхранение на Hadoop, който осигурява произволно четене и запис с ниска латентност върху HDFS и може да обработва петабайти данни. Една от интересните възможности в HBase е автоматичното разделяне, което просто означава, че таблиците се разпределят динамично от системата, когато станат твърде големи.
Основната единица за хоризонтална мащабируемост в HBase се нарича Регион . Регионите са подмножество от данните на таблицата и по същество представляват последователен, сортиран диапазон от редове, които се съхраняват заедно.
Първоначално има само един регион за маса. Както е показано по-долу, когато регионите станат твърде големи след добавяне на още редове, регионът се разделя на две при средния ключ, създавайки две приблизително равни половини.
В HBase подчинените се наричат Регионални сървъри . Всеки регионален сървър е отговорен да обслужва набор от региони, а един регион (т.е. диапазон от редове) може да се обслужва само от един регионален сървър.
Архитектурата HBase има две основни услуги:HMaster който отговаря за координирането на клъстера и изпълнението на административни операции, и HRegionServer отговаря за обработката на подмножество от данни на таблицата.
HMaster, присвояване на регион и балансиране
Както беше споменато по-горе, HBase Master координира HBase клъстера и отговаря за административните операции.
Регионалният сървър може да обслужва един или повече региони. Всеки регион се присвоява на регионен сървър при стартиране и главният може да реши да премести регион от един регион сървър в друг в резултат на операция за балансиране на натоварването. Главният също се справя с грешките на регионалния сървър, като присвоява региона на друг Регионален сървър.
Картографирането на регионите и регионалните сървъри се съхранява в системна таблица, наречена META. Като прочетете META, можете да определите кой регион е отговорен за вашия ключ. Това означава, че за операциите за четене и запис, главният въобще не участва и клиентите могат да отидат директно до регионалния сървър, отговорен да обслужва исканите данни.
Намиране на ключ на ред:Кой регионен сървър е отговорен?
За да поставят или получат ред, клиентите не трябва да се свързват с главния, клиентите могат директно да се свържат с регионалния сървър, който обработва посочения ред, или в случай на клиентско сканиране, могат директно да се свържат с набора от регионални сървъри, отговорни за обработката на набора на ключове:
За да идентифицира регионалния сървър, клиентът прави заявка към META таблицата.
META е системна таблица, използвана за проследяване на регионите. Той съдържа името на сървъра и идентификатор на региона, включващ име на таблица и начален ключ за ред. Разглеждайки стартовия ключ и следващия регион, клиентите с начален ключ могат да идентифицират диапазона от редове, съдържащи се в конкретен регион.
Клиентът съхранява кеш за регионалните местоположения. Това избягва клиентите да удрят META таблицата всеки път, когато се издава операция в същия регион. В случай на разделяне на регион или преместване на друг регионен сървър (поради политики за балансиране или присвояване), клиентът ще получи изключение като отговор и кешът ще бъде обновен чрез извличане на актуализираната информация от META таблицата:
Тъй като META е таблица като другите, клиентът трябва да идентифицира на кой сървър се намира META. META местоположенията се съхраняват в възел ZooKeeper при присвояване от Главния и клиентът чете директно възела, за да получи адреса на регионалния сървър, който съдържа META.
Оригиналният дизайн на HBase беше базиран на BigTable, с друга таблица, наречена -ROOT-, съдържаща META местоположенията и Apache ZooKeeper, сочещ към нея. HBase 0.96 премахна това подреждане само в полза на ZooKeeper, тъй като META не може да се раздели и следователно се състои от един регион.
Приложен програмен интерфейс (API) на клиента:Главни и регионални отговорности
Клиентският API на HBase Java има два основни интерфейса:
- HBaseAdmin позволява взаимодействие със „схемата на таблицата“ чрез създаване/изтриване/модифициране на таблици и позволява взаимодействие с клъстера чрез присвояване/отмяна на присвояване на региони, сливане на региони заедно, извикване на flush и т.н. Този интерфейс комуникира с Главния.
- HTtable позволява на клиента да манипулира данните от определена таблица, като използва get, put, delete и всички други операции с данни. Този интерфейс комуникира директно с регионалните сървъри, отговорни за обработката на искания набор от ключове.
Тези два интерфейса имат отделни отговорности:HBaseAdmin се използва само за изпълнение на административни операции и комуникация с главния, докато HTable се използва за манипулиране на данни и комуникация с регионите.
Заключение
Както видяхме тук, наличието на Master/Slave архитектура не означава, че всяка операция минава през главния. За да чете и записва данни, HBase клиентът всъщност отива директно към конкретния регионен сървър, отговорен за обработката на ключовете на редовете за всички операции с данни (HTable). Главният се използва от клиента само за операции по създаване, модифициране и изтриване на таблица (HBaseAdmin).
Въпреки че съществува концепция за главен, клиентът HBase не зависи от него за операциите с данни и клъстерът може да продължи да обслужва данни, дори ако главният се свали.
Матео Бертоци е софтуерен инженер в екипа на платформата и HBase Committer.
Ако се интересувате от HBase, не забравяйте да се регистрирате за HBaseCon 2013 (13 юни, Сан Франциско) – събитието на общността за сътрудници на HBase, разработчици, администратори и потребители. Мястото е ограничено!
