Apache HBase + Apache Hadoop + Xceivers

Въведение

Някои от конфигурационните свойства, открити в Apache Hadoop, имат пряк ефект върху клиентите, като Apache HBase. Едно от тези свойства се нарича „dfs.datanode.max.xcievers“ и принадлежи към подпроекта HDFS. Той определя броя на нишките от страна на сървъра и – до известна степен – гнездата, използвани за връзки за данни. Задаването на този номер твърде ниско може да причини проблеми, докато разраствате или увеличавате използването на вашия клъстер. Тази публикация ще ви помогне да разберете какво се случва между клиента и сървъра и как да определите разумен брой за това свойство.

Проблемът

Тъй като HBase съхранява всичко, от което се нуждае, в HDFS, твърдата горна граница, наложена от конфигурационното свойство „dfs.datanode.max.xcievers“, може да доведе до твърде малко ресурси, достъпни за HBase, което се проявява като IOExceptions от двете страни на връзката. Ето пример от пощенския списък на HBase [1], където следните съобщения първоначално бяха регистрирани от страната на RegionServer:

2008-11-11 19:55:52,451 ИНФОРМАЦИЯ org.apache.hadoop.dfs.DFSClient: Изключение в createBlockOutputStream java.io.IOException:Не можа прочетено от поток
2008-11-11 19:55:52,451 ИНФОРМАЦИЯ org.apache.hadoop.dfs.DFSClient: Изоставяне на блок blk_-546701410875>2008-11-11 19:55:52,451 ИНФОРМАЦИЯ org.apache.hadoop.dfs.DFSClient: Изоставяне на блок blk_-546701410875>2008-11-11 19:55:52,451 11 19:55:58,455 WARN org.apache.hadoop.dfs.DFSClient: Изключение на DataStreamer:java.io.IOException:Не може да се създаде нов блок.
2008-11-11 19:55:58,455 WARN WARN .hadoop.dfs.DFSClient:Грешка Възстановяване на блок blk_-5467014108758633036_595771 bad datanode[0]
2008-11-11 19:55:58,482 FATAL се изисква Reserve. . Принудително изключване на сървъра

Корелирането на това с регистрационните файлове на Hadoop DataNode разкри следния запис:

ГРЕШКА org.apache.hadoop.dfs.DataNode: DatanodeRegistration(10.10.10.53:50010,storageID=DS-1570581820-10.10.10.53-50010-1224117842339,infoPort=50075, ipcPort=50020):DataXceiver:java.io.IOException надвишава лимита на xevers6P>2xcei8

В този пример ниската стойност на “dfs.datanode.max.xcievers” за DataNodes доведе до изключване на целия RegionServer. Това е наистина лоша ситуация. За съжаление, няма твърдо и бързо правило, което обяснява как да се изчисли необходимата граница. Обикновено се препоръчва да увеличите числото от 256 по подразбиране до нещо като 4096 (вижте [1], [2], [3], [4] и [5] за справка). Това става чрез добавяне на това свойство към файла hdfs-site.xml на всички DataNodes (обърнете внимание, че е изписано неправилно):

    dfs.datanode.max.xcievers
4096

Забележка:Ще трябва да рестартирате своите DataNodes, след като направите тази промяна в конфигурационния файл.

Това би трябвало да помогне с горния проблем, но все пак може да искате да знаете повече за това как всичко това играе заедно и какво прави HBase с тези ресурси. Ще обсъдим това в останалата част от тази публикация. Но преди да го направим, трябва да сме наясно защо не можете просто да зададете това число много високо, да речем 64K и да приключите с него.

Има причина за горна граница и тя е двойна:първо, нишките се нуждаят от собствен стек, което означава, че заемат памет. За текущите сървъри това означава 1MB на нишка[6] по подразбиране. С други думи, ако използвате всички 4096 нишки на DataXceiver, имате нужда от около 4 GB памет, за да ги поберете. Това намалява пространството, което сте задали за memstore и блокове, както и всички други движещи се части на JVM. В най-лошия случай може да срещнете изключение OutOfMemoryException и процесът на RegionServer е тост. Искате да зададете това свойство на сравнително високо число, но не и твърде високо.

Второ, като имате тези много нишки активни, вие също ще видите, че вашият процесор става все по-натоварен. Ще има много превключвания на контекста, за да се справят с цялата едновременна работа, което отнема ресурси за реалната работа. Както при притесненията относно паметта, вие искате броят на нишките да не нараства безкрайно, а да осигури разумна горна граница – и за това е „dfs.datanode.max.xcievers“.

Подробности за файловата система на Hadoop

От страна на клиента HDFS библиотеката предоставя абстракцията, наречена Path. Този клас представлява файл във файлова система, поддържана от Hadoop, представена от класа FileSystem. Има няколко конкретни реализации на абстрактния клас FileSystem, един от които е DistributedFileSytem, ​​представляващ HDFS. Този клас от своя страна обхваща действителния клас DFSClient, който обработва всички взаимодействия с отдалечените сървъри, т.е. NameNode и многото DataNode.

Когато клиент, като HBase, отвори файл, той прави това, например чрез извикване на методите open() или create() на класа FileSystem, тук най-опростените превъплъщения

  public DFSInputStream open(String src) хвърля IOException
public FSDataOutputStream create(Path f) хвърля IOException

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

Върнатият екземпляр на поток е специализиран клас DFSOutputStream или DFSInputStream, който обработва цялото взаимодействие с NameNode, за да разбере къде се намират копията на блоковете и комуникацията на данни за блок за DataNode.

От страна на сървъра DataNode обвива екземпляр на DataXceiverServer, който е действителният клас, който чете горния конфигурационен ключ и също така хвърля горното изключение, когато ограничението е надвишено.

Когато DataNode стартира, той създава група нишки и стартира споменатия екземпляр DataXceiverServer по следния начин:

  this.threadGroup =new ThreadGroup(“dataXceiverServer”);
this.dataXceiverServer =нов Daemon( threadGroup,
нов DataXceiverServer(ss, conf, това));
this.threadGroup.setDaemon(true); // автоматично унищожаване, когато е празно

Обърнете внимание, че нишката DataXceiverServer вече заема едно място от групата нишки. DataNode също има този вътрешен клас за извличане на броя на текущо активните нишки в тази група:

  /** Брой едновременни xceivers на възел. */
int getXceiverCount() {
return threadGroup ==null? 0 :threadGroup.activeCount();
}

Блоковете за четене и запис, инициирани от клиента, причиняват осъществяване на връзка, която е обвита от DataXceiverServer нишката в DataXceiver екземпляр. По време на това изключване се създава нишка и се регистрира в горната група нишки. Така за всяка активна операция за четене и запис се проследява нова нишка от страна на сървъра. Ако броят на нишките в групата надвишава конфигурирания максимум, тогава споменатото изключение се хвърля и се записва в регистрационните файлове на DataNode:

  if (curXceiverCount> dataXceiverServer.maxXceiverCount) {
throw new IOException(“xceiverCount ” + curXceiverCount
+ ” надвишава ограничението за едновременни xcievers ”
+ dataXceiverServer.maxXceiverCount);
}

Последствия за клиентите

Сега въпросът е как четенето и писането на клиента са свързани с нишките от страна на сървъра. Преди да навлезем в подробностите обаче, нека използваме информацията за отстраняване на грешки, която класът DataXceiver регистрира, когато е създаден и затворен

  LOG.debug(“Броят на активните връзки е:” + datanode.getXceiverCount());
…
LOG.debug(datanode.dnRegistration + “:Броят на активните връзки е:”     + datanode.getXceiverCount());

и наблюдавайте по време на стартиране на HBase какво е регистрирано в DataNode. За простота това се прави на псевдо разпределена настройка с един екземпляр на DataNode и RegionServer. По-долу е показан горната част на страницата за състоянието на RegionServer.

Важната част е в секцията „Показатели“, където пише „storefiles=22“. Така че, ако приемем, че HBase има поне толкова много файлове за обработка, плюс някои допълнителни файлове за дневника с предварителна запис, трябва да видим горното съобщение за регистрационни файлове, че имаме поне 22 „активни връзки“. Да стартираме HBase и да проверим регистрационните файлове на DataNode и RegionServer:

Команден ред:

$ bin/start-hbase.sh
…

Регистър на DataNode:

2012-03-05 13:01:35,309 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Броят на активните връзки е:1
2012-03-05 13:01:35,315 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010-, storageID=DS 1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Броят на активните връзки е:2
12/03/05 13:01:35 глобален сървър35 глобален сървър. globalMemStoreLimitLowMark=347.1m, maxHeap=991.7m
12/03/05 13:01:39 ИНФОРМАЦИЯ http.HttpServer:Портът, върнат от webServer.getConnectors()[0].getLocalPort() преди open() е -1 е -1 е -1. . Отваряне на слушателя на 60030
2012-03-05 13:01:40,003 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:1
12/03/05 13:01:40 INFO regionserver.HRegionServer:Получена заявка за отваряне на регион:-ROOT-,,0.70236052
2012-03-05 13:01:40,882 DEBUG org.apache.hadoop.hdfs.de.datade.data :Броят на активните връзки е:3
2012-03-05 13:01:40,884 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:5004-14 storageID86 -10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Броят на активните връзки е:4
2012-03-05 13:01:40,888 DEBUG org.f.server.a. datanode.DataNode:Броят на активните връзки е:3
…
12/03/05 13:01:40 INFO regionserver.HRegion:Onlined -ROOT-,,0.70236052; next sequenceid=63083
2012-03-05 13:01:40,982 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:3
2012-03-05 13 :01:40,983 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-10.0.0.604-13017pc=10.0.0.604-132510pc=13017000000000000000000000000000000000000000000000 Броят на активните връзки е:4
…
12/03/05 13:01:41 INFO regionserver.HRegionServer:Получена заявка за отваряне на регион:.META.,,1.1028785192
2012-03 -05 13:01:41,026 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:3
2012-03-05 13:01:41,027 DEBUG org.apache.hadoop. hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=127.0.0.1:50010, storageID =DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=502/500 порта е активно:ipcPort<500/500/5000/502 …
12/03/05 13:01:41 INFO regionserver.HRegion:Онлайн .META.,,1.1028785192; next sequenceid=63082
2012-03-05 13:01:41,109 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:3
2012-03-05 13 :01:41,114 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:4
2012-03-05 13:01:41,117 DEBUG org.apache.hadoop.server.hdfs .datanode.DataNode:Броят на активните връзки е:5
12/03/05 13:01:41 ИНФО regionserver.HRegionServer:Получена заявка за отваряне на 16 регион(и)
12/03/05 13 :01:41 INFO regionserver.HRegionServer:Получена заявка за отваряне на регион:usertable,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.
12/03/05 13:03/05 12/03/04 13:03:12/03/05 13:03:00 13:00:00:00:00 11HR12:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 1330944810191.90d287473fe223f0ddc137020efda25d.
…

2012-03-05 13:01:41,246 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Броят на активните връзки е:6
2012-03-05 13:01:41,248 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:7
…
2012-03-05 13:01:41,257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-142364025-1423640250-142364040-1200-142364040-12040-142364020-1200-142364040-1200-142364040-1200-2000 , infoPort=50075, ipcPort=50020):Броят на активните връзки е:10
2012-03-05 13:01:41,257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode.DataNode:Datanode(17 0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Броят на активните връзки е:9
12…03:01:41 INFO regionserver.HRegion:Онлайн потребителска таблица,user1120311784,1330944810191.90d287473fe223f0ddc137020efda25d.; next sequenceid=62917
12/03/05 13:01:41 INFO regionserver.HRegion:Онлайн потребителска таблица,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.; next sequenceid=62916
…
12/03/05 13:01:41 INFO regionserver.HRegion:Онлайн потребителска таблица,user1361265841,1330944811370.80663fcf291e3ce009640; next sequenceid=62919
2012-03-05 13:01:41,474 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:6
2012-03-05 13 :01:41,491 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:7
2012-03-05 13:01:41,495 DEBUG org.apache.hadoop.server.hdfs .datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50075, ipcPort=50075, ipcPort=50075, ipcPort=0umber20br=5> активна връзка:ipcPort=0u0202-5> -05 13:01:41,508 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:7
…
12/03/05 13:01:41 INFO regionserver .HRegion:Онлайн потребителска таблица,user1964968041,1330944848231.dd89596e9129e1caa7e07f8a491c9734.; next sequenceid=62920
2012-03-05 13:01:41,618 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:6
2012-03-05 13 :01:41,621 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-10.0.0.604-13317pc=10.0.0.604-13250pc=130170000000000000000000000000000000000000000000000000 Броят на активните връзки е:7
…
2012-03-05 13:01:41,829 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010 storageID =DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Броят на активните връзки е:7
12/03/05 13:01:01:00:00:00 потребител Онлайн таблица:HR. ,user515290649,1330944849739.d23924dc9e9d5891f332c337977af83d.; next sequenceid=62926
2012-03-05 13:01:41,832 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:6
2012-03-05 13 :01:41,838 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-10.0.0.604-13750pc=13201000000000000000000000000000000000000000000000000) Броят на активните връзки е:7
12/03/05 13:01:41 INFO regionserver.HRegion:Онлайн потребителска таблица,user757669512,1330944850808.cd0d6f16d8ae9cf0c9277f6b9c; next sequenceid=62929
…
2012-03-05 14:01:39,711 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Броят на активните връзки е:4
2012 -03-05 22:48:41,945 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=DS-1423642448-1423642448-1423642448-10.02010, info=10.030305000000000000000000 ipcPort=50020):Броят на активните връзки е:4
12/03/05 22:48:41 ИНФО regionserver.HRegion:Онлайн потребителска таблица,user757669512,1330944850808.cd0d6f16d8c9c96f6f0c9c96f7cd9cd6f7cd6cd9cd7dcd6cd6cd6cd6cd6dc9cd7cdcdcdcdcdcd=50020):следващ идентификатор на последователност=62929
2012-03-05 22:48:41,963 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID=6.0644) -50010-1321352233772, infoPort=50075, ipcPort=50020):Броят на активните връзки е:4

Можете да видите как регионите се отварят един след друг, но това, което също може да забележите, е, че броят на активните връзки никога не се изкачва до 22 – той едва достига дори 10. Защо така? За да разберем това по-добре, трябва да видим как файловете в HDFS се съпоставят с екземпляра на DataXceiver от страна на сървъра – и действителните нишки, които представляват.

Дълбоко гмуркане на Hadoop

Споменатите по-горе DFSInputStream и DFSOutputStream са наистина фасади около обичайните концепции за поток. Те обгръщат комуникацията клиент-сървър в тези стандартни Java интерфейси, докато вътрешно насочват трафика към избран DataNode – който е този, който държи копие на текущия блок. Той има свободата да отваря и затваря тези връзки, ако е необходимо. Тъй като клиентът чете файл в HDFS, класовете на клиентската библиотека се превключват прозрачно от блок на блок и следователно от DataNode към DataNode, така че той трябва да отваря и затваря връзки, ако е необходимо.

 DFSInputStream има екземпляр на клас DFSClient.BlockReader, който отваря връзката с DataNode. Екземплярът на потока извиква blockSeekTo() за всяко извикване на read(), което се грижи за отварянето на връзката, ако вече няма такава. След като блокът бъде напълно прочетен, връзката се затваря. Затварянето на потока има същия ефект, разбира се.

 DFSOutputStream има подобен помощен клас, DataStreamer. Той проследява връзката със сървъра, която се инициира от метода nextBlockOutputStream(). Той има допълнителни вътрешни класове, които помагат при изписването на блоковите данни, които пропускаме тук за краткост.

И блоковете за запис и четене изискват нишка, която да държи гнездото и междинните данни от страна на сървъра, увити в екземпляра на DataXceiver. В зависимост от това какво прави вашият клиент, ще видите, че броят на връзките варира около броя на файловете, достъпни в момента в HDFS.

Обратно към гатанката на HBase по-горе:причината да не виждате до 22 (и повече) връзки по време на старта е, че докато регионите се отварят, единствените необходими данни са информационният блок на HFile. Този блок се чете, за да получи жизненоважни подробности за всеки файл, но след това отново се затваря. Това означава, че ресурсът от страна на сървъра се освобождава в бърза последователност. Останалите четири връзки са по-трудни за определяне. Можете да използвате JStack за изхвърляне на всички нишки в DataNode, което в този пример показва този запис:

„DataXceiver за клиент /127.0.0.1:64281 [изпращане на блок blk_5532741233443227208_4201]” 5 tib06 priemon nid=0x1178b4000 runnable [1178b3000]
java.lang.Thread.State:RUNNABLE
…

„DataXceiver за клиент /127.0.0.1:64172 [получаващ блок blk_-2005512129579433420_4199 client=4199.0.0.000_000000000000 ,60020,1330984111693_1330984118810]” daemon prio=5 tid=7fb966109000 nid=0x1169cb000 runnable [1169ca000]
java.lang.Th...read.lang.Th...

Това са единствените записи на DataXceiver (в този пример), така че броят в групата на нишките е малко подвеждащ. Припомнете си, че демонната нишка на DataXceiverServer вече отчита един допълнителен запис, който в комбинация с двата по-горе отчита трите активни връзки – което всъщност означава три активни нишки. Причината, поради която регистърът посочва четири вместо това, е, че регистрира броя от активна нишка, която е на път да завърши. И така, малко след като се регистрира броят от четири, то всъщност е едно по-малко, т.е. три и следователно съответства на нашия брой активни нишки.

Също така имайте предвид, че вътрешните помощни класове, като PacketResponder, заемат друга нишка в групата, докато са активни. Изходът на JStack показва този факт, изброявайки нишката като такава:

 „PacketResponder 0 за Block blk_-2005512129579433420_4199“ демон prio=5 tid=7fb96038 Object=7fb96030 ince. () [116acd000]
java.lang.Thread.State:TIMED_WAITING (на монитор на обект)
на java.lang.Object.wait(Native Method)
на org.apache.hadoop. hdfs.server.datanode.BlockReceiver$PacketResponder \
.lastDataNodeRun(BlockReceiver.java:779)
– заключен (a org.apache.hadoop.hdfs.server.datanode.PacketReceiver>на org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder.run(BlockReceiver.java:870)
на java.lang.Thread.run(Thread.java:680)

Тази нишка в момента е в TIMED_WAITING състояние и не се счита за активна. Ето защо броят, излъчван от регистрационните оператори на DataXceiver, не включва този вид нишки. Ако станат активни поради изпращане на данни от клиента, броят на активните нишки ще се увеличи отново. Друго нещо, което трябва да се отбележи, че тази нишка не се нуждае от отделна връзка или сокет между клиента и сървъра. PacketResponder е просто нишка от страната на сървъра за получаване на блокови данни и поточно предаване към следващия DataNode в конвейера за запис.

Командата Hadoop fsck също има опция да докладва кои файлове са отворени в момента за запис:

$ hadoop fsck /hbase -openforwrite
FSCK стартира от larsgeorge от /10.0.0.29 за път / hbase в понеделник, 05 март 22:59:47 CET 2012 г.
……/hbase/.logs/10.0.0.29,60020,1330984111693/10.0.0.29%3A60020.133094810 блок. …………………………………………..Състояние:HEALTHY
Общ размер:     2088783626 B
Общо директории:     54
Общо файлове:   45
…

Това не се отнася непосредствено до заета нишка от страна на сървъра, тъй като те се разпределят по ID на блок. Но можете да разберете от него, че има един отворен блок за писане. Командата Hadoop има допълнителни опции за отпечатване на действителните файлове и идентификатора на блока, от който се състоят:

$ hadoop fsck /hbase -files -blocks
FSCK стартира от larsgeorge от /10.0.0.29 за път /hbase в вторник, 06 март 10:39:50 CET 2012 г.

…
/hbase/.META./1028785192/.tmp