Тази публикация в блога е публикувана на Hortonworks.com преди сливането с Cloudera. Някои връзки, ресурси или препратки може вече да не са точни.
За тази публикация правим технически задълбочено потапяне в една от основните области на HBase. По-конкретно, ще разгледаме как Apache HBase разпределя натоварването между регионите и управлява разделянето на региони. HBase съхранява редове с данни в таблици. Таблиците са разделени на части от редове, наречени „региони“. Тези региони се разпределят в клъстера, хостват се и се предоставят на клиентските процеси от процеса RegionServer. Регионът е непрекъснат диапазон в ключовото пространство, което означава, че всички редове в таблицата, които се сортират между началния и крайния ключ на региона, се съхраняват в един и същ регион. Регионите не се припокриват, т.е. ключ от един ред принадлежи точно на един регион във всеки момент от време. Регионът се обслужва само от един сървър на региона във всеки момент от време, което е начинът, по който HBase гарантира силна последователност в рамките на един ред#. Заедно с -ROOT- и .META. региони, регионите на таблицата ефективно образуват 3-степенно B-дърво за целите на намиране на ред в таблица.
Регион от своя страна се състои от много „магазини“, които съответстват на семейства колони. Магазинът съдържа един memstor и нула или повече файлове в магазина. Данните за всяко семейство колони се съхраняват и достъпват отделно.
Една таблица обикновено се състои от много региони, които от своя страна се хостват от много регионални сървъри. По този начин регионите са физическият механизъм, използван за разпределение на натоварването при запис и заявка между сървърите на региона. Когато таблицата е създадена за първи път, HBase по подразбиране ще разпредели само един регион за таблицата. Това означава, че първоначално всички заявки ще отидат до един сървър на региона, независимо от броя на регионалните сървъри. Това е основната причина, поради която първоначалните фази на зареждане на данни в празна таблица не могат да използват целия капацитет на клъстера.
Предварително разделяне
Причината, поради която HBase създава само един регион за таблицата, е, че не може да знае как да създаде точките на разделяне в ключовото пространство на реда. Вземането на такива решения се основава силно на разпределението на ключовете във вашите данни. Вместо да правите предположения и да ви оставя да се справяте с последствията, HBase ви предоставя инструменти за управление на това от клиента. С процес, наречен предварително разделяне, можете да създадете таблица с много региони, като предоставите точките на разделяне в момента на създаване на таблицата. Тъй като предварителното разделяне ще гарантира, че първоначалното натоварване е по-равномерно разпределено в целия клъстер, винаги трябва да обмисляте използването му, ако предварително знаете разпределението на ключовете си. Въпреки това, предварителното разделяне също има риск от създаване на региони, които не разпределят наистина равномерно натоварването поради изкривяване на данните или при наличие на много горещи или големи редове. Ако първоначалният набор от точки на разделяне на регионите е избран неправилно, може да се окажете с хетерогенно разпределение на натоварването, което от своя страна ще ограничи производителността на клъстерите ви.
Няма кратък отговор за оптималния брой региони за дадено натоварване, но можете да започнете с по-малко кратно на броя на регионалните сървъри като брой разделяния, след което оставете автоматичното разделяне да се погрижи за останалото.
Един проблем с предварителното разделяне е изчисляването на точките на разделяне за таблицата. Можете да използвате помощната програма RegionSplitter. RegionSplitter създава точките на разделяне, като използва включаем SplitAlgorithm. HexStringSplit и UniformSplit са два предварително дефинирани алгоритма. Първият може да се използва, ако ключовете на редовете имат префикс за шестнадесетични низове (например, ако използвате хешове като префикси). Последният разделя ключовото пространство равномерно, като приема, че са произволни байтови масиви. Можете също да внедрите своя персонализиран SplitAlgorithm и да го използвате от помощната програма RegionSplitter.
$ hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f f1
където -c 10, определя искания брой региони като 10, а -f определя семействата колони, които искате в таблицата, разделени с „:“. Инструментът ще създаде таблица с име “test_table” с 10 региона:
13/01/18 18:49:32 DEBUG hbase.HRegionInfo: Current INFO from scan results = {NAME => 'test_table,,1358563771069.acc1ad1b7962564fc3a43e5907e8db33.', STARTKEY => '', ENDKEY => '19999999', ENCODED => acc1ad1b7962564fc3a43e5907e8db33,}
13/01/18 18:49:32 DEBUG hbase.HRegionInfo: Current INFO from scan results = {NAME => 'test_table,19999999,1358563771096.37ec12df6bd0078f5573565af415c91b.', STARTKEY => '19999999', ENDKEY => '33333332', ENCODED => 37ec12df6bd0078f5573565af415c91b,}
... Ако имате под ръка точки на разделяне, можете също да използвате обвивката HBase, за да създадете таблицата с желаните точки на разделяне.
hbase(main):015:0> create 'test_table', 'f1', SPLITS=> ['a', 'b', 'c']
или
$ echo -e "anbnc" >/tmp/splits hbase(main):015:0> create 'test_table', 'f1', SPLITSFILE=>'/tmp/splits'
За оптимално разпределение на натоварването трябва да помислите за своя модел на данни и за разпределението на ключовете, за да изберете правилния алгоритъм за разделяне или точки на разделяне. Независимо от метода, който сте избрали за създаване на таблицата с предварително определен брой региони, сега можете да започнете да зареждате данните в таблицата и да видите, че натоварването се разпределя във вашия клъстер. Можете да позволите на автоматичното разделяне да поеме контрола, след като започне поглъщането на данни, и непрекъснато да наблюдавате общия брой региони за таблицата.
Автоматично разделяне
Независимо дали се използва предварително разделяне или не, след като даден регион достигне определен лимит, той автоматично се разделя на два региона. Ако използвате HBase 0.94 (която се предлага с HDP-1.2), можете да конфигурирате кога HBase реши да раздели регион и как изчислява точките на разделяне чрез pluggable RegionSplitPolicy API. Има няколко предварително дефинирани политики за разделяне на региони:ConstantSizeRegionSplitPolicy, IncreasingToUpperBoundRegionSplitPolicy и KeyPrefixRegionSplitPolicy.
Първата е стандартната и единствена политика за разделяне за версии на HBase преди 0.94. Той разделя регионите, когато общият размер на данните за едно от магазините (съответстващи на семейство колони) в региона стане по-голям от конфигурирания „hbase.hregion.max.filesize“, който има стойност по подразбиране от 10 GB. Тази политика за разделяне е идеална в случаите, когато сте приключили с предварителното разделяне и се интересувате от получаване на по-малък брой региони на сървър на региона.
Политиката за разделяне по подразбиране за HBase 0.94 и trunk е IncreasingToUpperBoundRegionSplitPolicy, която извършва по-агресивно разделяне въз основа на броя на регионите, хоствани в същия сървър на региона. Политиката за разделяне използва максималния размер на файла на магазина въз основа на Min (R^2 * „hbase.hregion.memstore.flush.size“, „hbase.hregion.max.filesize“), където R е броят на регионите на едно и също таблица, хоствана на същия регионен сървър. Така например, при стандартния размер за изтриване на memstore от 128MB и максималния размер на магазина по подразбиране от 10GB, първият регион на сървъра на региона ще бъде разделен веднага след първото изчистване на 128MB. С увеличаването на броя на регионите, хоствани в сървъра на региона, той ще използва нарастващи размери на разделяне:512MB, 1152MB, 2GB, 3.2GB, 4.6GB, 6.2GB и т.н. След достигане на 9 региона, размерът на разделянето ще надхвърли конфигурирания „hbase .hregion.max.filesize”, в който момент оттогава ще се използва разделен размер от 10 GB. И за двата алгоритъма, независимо от това кога се случва разделянето, използваната точка на разделяне е клавишният ред, който съответства на средната точка в „индекса на блока“ за най-големия файл на магазина в най-големия магазин.
KeyPrefixRegionSplitPolicy е любопитно допълнение към арсенала на HBase. Можете да конфигурирате дължината на префикса за вашите ключове на редове, за да ги групирате, и тази политика на разделяне гарантира, че регионите не се разделят в средата на група от редове със същия префикс. Ако сте задали префикси за вашите ключове, тогава можете да използвате тази политика за разделяне, за да гарантирате, че редовете с един и същ префикс на rowkey винаги се озовават в един и същи регион. Това групиране на записи понякога се нарича „Групи на обекти“ или „Групи на редове“. Това е ключова функция, когато обмисляте използването на функцията „локални транзакции“ (алтернативна връзка) в дизайна на вашето приложение.
Можете да конфигурирате политиката за разделяне по подразбиране, която да се използва, като зададете конфигурацията “hbase.regionserver.region.split.policy” или като конфигурирате дескриптора на таблицата. За вас, смели души, можете също да внедрите своя собствена персонализирана политика за разделяне и да я включите в момента на създаване на таблицата или като промените съществуваща таблица:
HTableDescriptor tableDesc = new HTableDescriptor("example-table");
tableDesc.setValue(HTableDescriptor.SPLIT_POLICY, AwesomeSplitPolicy.class.getName());
//add columns etc
admin.createTable(tableDesc); Ако правите предварително разделяне и искате ръчно да управлявате разделянето на региони, можете също да деактивирате разделянето на региони, като зададете „hbase.hregion.max.filesize“ на голямо число и зададете политиката за разделяне на ConstantSizeRegionSplitPolicy. Въпреки това, трябва да използвате защитна стойност от 100 GB, така че регионите да не надхвърлят възможностите на сървъра на региона. Можете да обмислите деактивирането на автоматичното разделяне и да разчитате на първоначалния набор от региони от предварителното разделяне, например, ако използвате еднакви хешове за ключовите си префикси и можете да гарантирате, че четенето/записването се зарежда за всеки регион, както и неговия размер е еднакво в регионите в таблицата.
Принудително разделяне
HBase също така позволява на клиентите да принудително разделят онлайн таблица от страна на клиента. Например, обвивката HBase може да се използва за разделяне на всички региони на таблицата или за разделяне на регион, по избор чрез предоставяне на точка на разделяне.
hbase(main):024:0> split 'b07d0034cbe72cb040ae9cf66300a10c', 'b' 0 row(s) in 0.1620 seconds
С внимателно наблюдение на разпределението на натоварването на HBase, ако видите, че някои региони получават неравномерно натоварване, може да помислите за ръчно разделяне на тези региони, за да изравните натоварването и да подобрите пропускателната способност. Друга причина, поради която може да искате да направите ръчно разделяне, е, когато видите, че първоначалното разделяне за региона се оказва неоптимално и сте деактивирали автоматизираните разделяния. Това може да се случи например, ако разпределението на данните се промени с течение на времето.
Как се прилагат разделянето на региони
Тъй като заявките за запис се обработват от сървъра на региона, те се натрупват в система за съхранение в паметта, наречена „memstore“. След като мемсторът се запълни, съдържанието му се записва на диск като допълнителни файлове за съхранение. Това събитие се нарича „флъш в memstore“. Тъй като файловете на магазина се натрупват, RegionServer ще ги „компактира“ в комбинирани, по-големи файлове. След приключване на всяко изчистване или уплътняване, заявка за разделяне на регион се поставя в опашка, ако RegionSplitPolicy реши, че регионът трябва да бъде разделен на две. Тъй като всички файлове с данни в HBase са неизменни, когато се случи разделяне, новосъздадените дъщерни региони няма да пренапишат всички данни в нови файлове. Вместо това те ще създадат малки символни връзки като файлове, наречени Референтни файлове, които сочат към горната или долната част на файла на родителския магазин според точката на разделяне. Референтният файл ще се използва точно като обикновен файл с данни, но само половината от записите. Регионът може да бъде разделен само ако няма повече препратки към неизменните файлове с данни на родителския регион. Тези референтни файлове се почистват постепенно чрез уплътняване, така че регионът да спре да препраща към своите родителски файлове и да може да бъде разделен допълнително.
Въпреки че разделянето на региона е местно решение, взето в RegionServer, самият процес на разделяне трябва да се координира с много участници. RegionServer уведомява Главния преди и след разделянето, актуализира .META. таблица, така че клиентите да могат да открият новите дъщерни региони, и пренарежда структурата на директориите и файловете с данни в HDFS. Разделянето е процес с множество задачи. За да активира връщане назад в случай на грешка, RegionServer поддържа дневник в паметта за състоянието на изпълнение. Стъпките, предприети от RegionServer за изпълнение на разделянето, са илюстрирани от Фигура 1. Всяка стъпка е обозначена с номера на стъпката. Действията от RegionServers или Master се показват в червено, докато действията от клиентите се показват в зелено.
1. RegionServer решава локално да раздели региона и подготвя разделянето. Като първа стъпка, той създава znode в zookeeper под /hbase/region-in-transition/region-name в състояние на РАЗДЕЛЯНЕ.
2. Господарят научава за този znode, тъй като той има наблюдател за родителския регион в преход znode.
3. RegionServer създава поддиректория с име „.splits“ под директорията на родителския регион в HDFS.
4. RegionServer затваря родителския регион, принуждава изчистване на кеша и маркира региона като офлайн в неговите локални структури от данни. В този момент клиентските заявки, идващи в родителския регион, ще хвърлят NotServingRegionException. Клиентът ще опита отново с известно отстъпление.
5. RegionServer създава регионалните директории в директорията .splits, за дъщерните региони A и B, и създава необходимите структури от данни. След това разделя файловете на магазина, в смисъл, че създава два референтни файла за файл на магазин в родителския регион. Тези референтни файлове ще сочат към файловете на родителските региони.
6. RegionServer създава действителната регионална директория в HDFS и премества референтните файлове за всяка дъщеря.
7. RegionServer изпраща заявка за поставяне към .META. таблица и задава родителя като офлайн в .META. таблица и добавя информация за дъщерните региони. В този момент няма да има отделни записи в .META. за дъщерите. Клиентите ще видят, че родителският регион е разделен, ако сканират .META., но няма да знаят за дъщерите, докато не се появят в .META.. Също така, ако това се постави на .META. успее, родителят ще бъде ефективно разделен. Ако RegionServer се провали преди този RPC да успее, главният и следващият сървър на региона, който отваря региона, ще изчистят мръсното състояние за разделянето на региона. След .META. актуализация обаче, разделянето на региона ще бъде преместено от Master.
8. RegionServer отваря дъщерни паралелно, за да приема записи.
9. RegionServer добавя дъщерите A и B към .META. заедно с информация, че е домакин на регионите. След този момент клиентите могат да откриват новите региони и да подават заявки към новия регион. Клиентите кешират .META. записи локално, но когато направят заявки към сървъра на региона или .META., техните кешове ще бъдат анулирани и те ще научат за новите региони от .META..
10. RegionServer актуализира znode /hbase/region-in-transition/region-name в zookeeper до състояние SPLIT, така че капитана да може да научи за него. Балансьорът може свободно да пренасочва дъщерните региони към други регионални сървъри, ако избере така.
11. След разделянето, meta и HDFS все още ще съдържат препратки към родителския регион. Тези препратки ще бъдат премахнати, когато уплътненията в дъщерните региони пренапишат файловете с данни. Задачите за събиране на боклук в главната програма периодично проверяват дали дъщерните региони все още се отнасят към родителските файлове. Ако не, родителският регион ще бъде премахнат.
Обединяване на региони
За разлика от разделянето на региони, HBase в този момент не предоставя използваеми инструменти за сливане на региони. Въпреки че има инструменти HMerge и Merge, те не са много подходящи за обща употреба. Понастоящем няма поддръжка за онлайн таблици и функция за автоматично сливане. Въпреки това, с проблеми като OnlineMerge, Master инициира автоматично сливане на региони, ZK-базирани заключвания за четене/запис за операции с таблици, ние работим за стабилизиране на разделянето на региони и осигуряване на по-добра поддръжка за сливане на региони. Останете на линия!
Заключение
Както можете да видите, HBase под капака прави много домакинство, за да управлява разделянето на региони и да извършва автоматизирано разделяне през региони. Въпреки това, HBase предоставя и необходимите инструменти за управление на региона, така че да можете да управлявате процеса на разделяне. Можете също така да контролирате точно кога и как се случват разделянето на региони чрез RegionSplitPolicy.
Броят на регионите в таблицата и начинът, по който тези региони са разделени, са решаващи фактори за разбирането и настройката на натоварването на клъстера на HBase. Ако можете да оцените разпределението на ключовете си, трябва да създадете таблицата с предварително разделяне, за да получите оптимална първоначална производителност на натоварване. Можете да започнете с по-малко кратно на броя на регионалните сървъри като отправна точка за първоначалния брой региони и да оставите автоматичното разделяне да поеме. Ако не можете правилно да оцените началните точки на разделяне, по-добре е просто да създадете таблицата с един регион и да започнете първоначално натоварване с автоматично разделяне и да използвате IncreasingToUpperBoundRegionSplitPolicy. Имайте предвид обаче, че общият брой региони ще се стабилизира с течение на времето и текущият набор от точки на разделяне на региони ще бъде определен от данните, които таблицата е получила досега. Може да искате да наблюдавате разпределението на натоварването в регионите по всяко време и ако разпределението на натоварването се промени с течение на времето, използвайте ръчно разделяне или задайте по-агресивни размери на разделяне на региони. И накрая, можете да изпробвате предстоящата функция за онлайн сливане и да допринесете за вашия случай на употреба.
