Apache HBase е базата данни Hadoop и е базирана на разпределената файлова система на Hadoop (HDFS ). HBase дава възможност за произволен достъп и актуализиране на данни, съхранявани в HDFS, но файловете в HDFS могат да се добавят само към и са неизменни след като са създадени. Така че може да попитате как HBase осигурява четене и запис с ниска латентност? В тази публикация в блога ние обясняваме това, като описваме пътя на запис на HBase – как данните се актуализират в HBase.
Пътят за запис е как HBase завършва операции за поставяне или изтриване. Този път започва от клиент, премества се към сървър на региона и завършва, когато данните в крайна сметка бъдат записани във файл с данни на HBase, наречен HFile . В дизайна на пътя за запис са включени функции, които HBase използва, за да предотврати загуба на данни в случай на повреда на регионалния сървър. Следователно разбирането на пътя на запис може да даде представа за естествения механизъм за предотвратяване на загуба на данни на HBase.
Всяка таблица на HBase се хоства и управлява от набори сървъри, които попадат в три категории:
- Един активен главен сървър
- Един или повече резервни главни сървъри
- Много регионални сървъри
Регионалните сървъри допринасят за обработката на HBase таблиците. Тъй като HBase таблиците могат да бъдат големи, те се разбиват на дялове, наречени региони. Всеки регионален сървър обработва един или повече от тези региони. Имайте предвид, че тъй като регионалните сървъри са единствените сървъри, които обслужват HBase таблици, сривът на главния сървър не може да причини загуба на данни.
Данните от HBase са организирани подобно на сортирана карта, като пространството за сортирани ключове е разделено на различни части или региони. HBase клиент актуализира таблица чрез извикване на команди за поставяне или изтриване. Когато клиент поиска промяна, тази заявка се насочва към сървър на региона веднага по подразбиране. Въпреки това, програмно, клиентът може да кешира промените в клиентската страна и да изтрие тези промени на регионалните сървъри в пакет, като изключи автоматичното изтриване. Ако автоматичното изтриване е изключено, промените се кешират, докато не се извикат flush-commits или буферът е пълен в зависимост от размера на буфера, зададен програмно или конфигуриран с параметър „hbase.client.write.buffer“.
Тъй като ключът на реда е сортиран, лесно е да се определи кой регион сървър управлява кой ключ. Заявката за промяна е за конкретен ред. Всеки ключ на ред принадлежи на конкретен регион, който се обслужва от сървър на региона. Така че въз основа на ключа за поставяне или изтриване, клиент на HBase може да намери подходящ регионен сървър. Първоначално намира адреса на регионалния сървър, хостващ региона -ROOT- от кворума на ZooKeeper. От сървъра на основния регион клиентът открива местоположението на сървъра на региона, който хоства -META- региона. От сървъра на мета региона, най-накрая намираме действителния сървър на региона, който обслужва заявения регион. Това е процес от три стъпки, така че местоположението на региона се кешира, за да се избегне тази скъпа серия от операции. Ако кешираното местоположение е невалидно (например получаваме изключение за неизвестен регион), време е да преместим региона и да актуализираме кеша.
След като заявката бъде получена от правилния регионален сървър, промяната не може да бъде записана в HFile незабавно, тъй като данните в HFile трябва да бъдат сортирани по ключа на реда. Това позволява ефективно търсене на произволни редове при четене на данните. Данните не могат да бъдат вмъкнати на случаен принцип в HFile. Вместо това промяната трябва да бъде записана в нов файл. Ако всяка актуализация беше записана във файл, ще бъдат създадени много малки файлове. Такова решение не би било мащабируемо или ефективно за сливане или четене по-късно. Следователно промените не се записват веднага в нов HFile.
Вместо това всяка промяна се съхранява на място в паметта, наречено memstore , който евтино и ефективно поддържа произволно записване. Данните в memstore се сортират по същия начин като данните в HFile. Когато memstore натрупа достатъчно данни, целият сортиран набор се записва в нов HFile в HDFS. Извършването на една голяма задача за запис е ефективно и се възползва от силните страни на HDFS.
Въпреки че записването на данни в memstore е ефективно, то също така въвежда елемент на риск:информацията, съхранявана в memstore, се съхранява в непостоянна памет, така че ако системата се повреди, цялата информация за memstore се губи. За да помогне за смекчаване на този риск, HBase запазва актуализации в дневник с предварителна запис (WAL ), преди да напишете информацията в memstore. По този начин, ако сървърът на региона се повреди, информацията, която е била съхранена в memstore на този сървър, може да бъде възстановена от неговия WAL.
Забележка:По подразбиране WAL е активиран, но процесът на запис на WAL файла на диск консумира някои ресурси. WAL може да бъде деактивиран, но това трябва да се прави само ако рискът от загуба на данни не е проблем. Ако решите да деактивирате WAL, помислете за внедряване на собствено решение за възстановяване след бедствие или бъдете готови за възможността от загуба на данни.
Данните в WAL файл са организирани различно от HFile. WAL файловете съдържат списък с редакции, като една редакция представлява едно поставяне или изтриване. Редактирането включва информация за промяната и региона, за който се отнася промяната. Редакциите се записват хронологично, така че за постоянство, допълненията се добавят в края на WAL файла, който се съхранява на диска. Тъй като WAL файловете са подредени хронологично, никога не е необходимо да се записва на произволно място във файла.
С нарастването на WAL те в крайна сметка се затварят и се създава нов, активен WAL файл, който да приема допълнителни редакции. Това се нарича "превъртане" на WAL файла. След като WAL файлът бъде прехвърлен, не се правят допълнителни промени в стария файл.
По подразбиране WAL файлът се прехвърля, когато размерът му е около 95% от размера на HDFS блока. Можете да конфигурирате множителя, като използвате параметър:“hbase.regionserver.logroll.multiplier” и размера на блока, като използвате параметър:“hbase.regionserver.hlog.blocksize”. WAL файлът също се прехвърля периодично въз основа на конфигуриран интервал „hbase.regionserver.logroll.period“, един час по подразбиране, дори размерът на WAL файла е по-малък от конфигурирания лимит.
Ограничаването размера на WAL файла улеснява ефективното възпроизвеждане на файла, ако е необходимо възстановяване. Това е особено важно по време на възпроизвеждане на WAL файл на даден регион, тъй като докато файлът се възпроизвежда, съответният регион не е наличен. Намерението е евентуално да се запишат всички промени от всеки WAL файл на диск и да се запази това съдържание в HFile. След като това бъде направено, WAL файлът може да бъде архивиран и в крайна сметка да бъде изтрит от демонната нишка на LogCleaner. Имайте предвид, че WAL файловете служат като защитна мярка. WAL файловете трябва да се възпроизвеждат само, за да се възстановят актуализациите, които иначе биха били загубени след срив на регионалния сървър.
Регионалният сървър обслужва много региони, но няма WAL файл за всеки регион. Вместо това един активен WAL файл се споделя между всички региони, обслужвани от регионалния сървър. Тъй като WAL файловете се прехвърлят периодично, един сървър на региона може да има много WAL файлове. Имайте предвид, че има само един активен WAL на сървър за регион в даден момент.
Ако приемем, че HBase root по подразбиране е „/hbase“, всички WAL файлове за екземпляр на регионалния сървър се съхраняват в същата основна папка, която е както следва:
/hbase/.logs/<host>, <port>,<startcode>
Например:
/hbase/.logs/srv.example.com,60020,1254173957298
WAL регистрационните файлове се именуват както следва:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Например:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Всяка редакция във файла WAL има уникален идентификатор на последователността. Този идентификатор се увеличава, за да се запази реда на редакциите. Всеки път, когато се прехвърля регистрационен файл, следващият идентификатор на последователност и старото име на файл се поставят в карта в паметта. Тази информация се използва за проследяване на максималния идентификатор на последователност на всеки WAL файл, за да можем лесно да разберем дали даден файл може да бъде архивиран в по-късен момент, когато някое memstore бъде прехвърлено на диск.
Редакциите и техните последователни идентификатори са уникални в рамките на даден регион. Всеки път, когато се добави редакция към дневника на WAL, идентификаторът на последователността на редакцията също се записва като последния записан идентификатор на последователност. Когато memstore се изчисти на диск, последният идентификатор на последователността, написан за този регион, се изчиства. Ако последният идентификатор на последователност, записан на диск, е същият като максималния идентификатор на последователност на WAL файл, може да се заключи, че всички редакции в WAL файл за този регион са записани на диск. Ако всички редакции за всички региони в WAL файл са записани на диск, е ясно, че няма да се изисква разделяне или повторно възпроизвеждане и WAL файлът може да бъде архивиран.
Преместването на WAL файл и изтриването на memstore са две отделни действия и не е необходимо да се случват заедно. Въпреки това, ние не искаме да съхраняваме твърде много WAL файлове на сървър на региона, за да избегнем отнемащо време възстановяване в случай на повреда на регионалния сървър. Следователно, когато WAL файл се прехвърля, HBase проверява дали има твърде много WAL файлове и решава кои региони трябва да бъдат изтрити, за да могат някои WAL файлове да бъдат архивирани.
В тази публикация обясняваме пътя за запис в HBase, който е начинът, по който данните в HBase се създават и/или актуализират. Някои важни части от него са:
- Как клиент намира регионен сървър,
- Memstore, който поддържа бързо произволно записване,
- WAL файлове като начин за избягване на загуба на данни в случай на повреда на регионалния сървър.
Ще говорим за HFile формати, разделяне на WAL файлове и така нататък в следващите публикации.
