Apache HBase + Apache Hadoop + Xceivers

Úvod

Některé konfigurační vlastnosti nalezené v Apache Hadoop mají přímý vliv na klienty, jako je Apache HBase. Jedna z těchto vlastností se nazývá „dfs.datanode.max.xcievers“ a patří do podprojektu HDFS. Definuje počet vláken na straně serveru a – do určité míry – soketů používaných pro datová připojení. Nastavení příliš nízkého čísla může způsobit problémy s růstem nebo zvýšením využití vašeho clusteru. Tento příspěvek vám pomůže pochopit, co se děje mezi klientem a serverem, a jak určit přiměřený počet pro tuto vlastnost.

Problém

Vzhledem k tomu, že HBase ukládá vše, co potřebuje, uvnitř HDFS, tvrdá horní hranice stanovená konfigurační vlastností „dfs.datanode.max.xcievers“ může vést k tomu, že HBase bude mít k dispozici příliš málo zdrojů, což se projeví jako IOExceptions na obou stranách připojení. Zde je příklad z mailing listu HBase [1], kde byly na straně RegionServeru původně protokolovány následující zprávy:

2008-11-11 19:55:52,451 INFO org.apache.hadoop.dfs.DFSClient: Výjimka v createBlockOutputStream java.io.IOException:Nelze číst ze streamu
2008-11-11 19:55:52,451 INFO org.apache.hadoop.dfs.DFSClient: Opuštění bloku blk_-5467014108-325863<508/325863 11 19:55:58,455 WARN org.apache.hadoop.dfs.DFSClient: Výjimka DataStreamer:java.io.IOException:Nelze vytvořit nový blok.
2008-11-11 19:55:58,455 WARN org.apache .hadoop.dfs.DFSClient:Chyba Obnovení pro blok blk_-5467014108758633036_595771 špatný datový uzel[0]
2008-11-11 19:55:58,482 vyžadováno FATALoregion opplayhache.FATAL region org.applayhache. . Vynucení vypnutí serveru

Porovnání s protokoly Hadoop DataNode odhalilo následující záznam:

CHYBA 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:xcie thevers2556 conception:xciexceiverscurrent

V tomto příkladu způsobila nízká hodnota „dfs.datanode.max.xcievers“ pro DataNodes vypnutí celého RegionServeru. To je opravdu špatná situace. Bohužel neexistuje žádné pevné pravidlo, které by vysvětlovalo, jak požadovaný limit vypočítat. Obvykle se doporučuje zvýšit číslo z výchozích 256 na něco jako 4096 (viz [1], [2], [3], [4] a [5] pro referenci). Toho se dosáhne přidáním této vlastnosti do souboru hdfs-site.xml všech DataNodes (všimněte si, že je napsána chybně):

    dfs.datanode.max.xcievers
4096

Poznámka:Po provedení této změny v konfiguračním souboru budete muset restartovat své DataNodes.

To by mělo pomoci s výše uvedeným problémem, ale přesto byste možná chtěli vědět více o tom, jak to všechno funguje dohromady, a co HBase s těmito prostředky dělá. Budeme o tom diskutovat ve zbytku tohoto příspěvku. Než to však uděláme, musíme si ujasnit, proč nemůžete jednoduše nastavit toto číslo velmi vysoko, řekněme 64 kB, a skončit s tím.

Horní hranice má svůj důvod, a to dvojí:za prvé, vlákna potřebují svůj vlastní zásobník, což znamená, že zabírají paměť. Pro současné servery to ve výchozím nastavení znamená 1 MB na vlákno[6]. Jinými slovy, pokud využijete všech 4096 vláken DataXceiver, potřebujete k jejich uložení přibližně 4 GB haldy. Tím se omezí prostor, který jste přidělili pro memstore a blokové mezipaměti, stejně jako všechny ostatní pohyblivé části JVM. V nejhorším případě můžete narazit na OutOfMemoryException a proces RegionServer je toast. Tuto vlastnost chcete nastavit na přiměřeně vysoké číslo, ale ne příliš vysoké.

Zadruhé, když je aktivních těchto mnoho vláken, uvidíte, že se váš procesor stále více zatěžuje. Dojde k mnoha přepnutím kontextu, aby zvládly veškerou souběžnou práci, což odebere zdroje pro skutečnou práci. Stejně jako v případě obav o paměť chcete, aby počet vláken nerostl neomezeně, ale poskytoval rozumnou horní hranici – a k tomu slouží „dfs.datanode.max.xcievers“.

Podrobnosti o souborovém systému Hadoop

Na straně klienta poskytuje knihovna HDFS abstrakci nazvanou Path. Tato třída představuje soubor v souborovém systému podporovaném Hadoopem, reprezentovaný třídou FileSystem. Existuje několik konkrétních implementací abstraktní třídy FileSystem, jednou z nich je DistributedFileSytem, ​​představující HDFS. Tato třída zase obaluje skutečnou třídu DFSClient, která zpracovává všechny interakce se vzdálenými servery, tj. NameNode a mnoha DataNodes.

Když klient, jako je HBase, otevře soubor, udělá to tak, že například zavolá metody open() nebo create() třídy FileSystem, zde jsou nejjednodušší inkarnace

  public DFSInputStream open(String src) vyvolá IOException
veřejné FSDataOutputStream create(Path f) vyvolá IOException

Vrácená instance streamu potřebuje soket a vlákno na straně serveru, které se používají ke čtení a zápisu bloků dat. Jsou součástí smlouvy o výměně dat mezi klientem a serverem. Všimněte si, že mezi různými počítači se používají jiné protokoly založené na RPC, ale pro účely této diskuse je lze ignorovat.

Vrácená instance streamu je specializovaná třída DFSOutputStream nebo DFSInputStream, která zpracovává veškerou interakci s NameNode, aby zjistila, kde jsou kopie bloků, a datovou komunikaci na blok na DataNode.

Na straně serveru DataNode zabalí instanci DataXceiverServer, což je skutečná třída, která čte výše uvedený konfigurační klíč a také vyvolá výše uvedenou výjimku, když je překročen limit.

Když se DataNode spustí, vytvoří skupinu vláken a spustí zmíněnou instanci DataXceiverServer takto:

  this.threadGroup =new ThreadGroup(“dataXceiverServer”);
this.dataXceiverServer =new Daemon( threadGroup,
new DataXceiverServer(ss, conf, this));
this.threadGroup.setDaemon(true); // automatické zničení při prázdném

Všimněte si, že vlákno DataXceiverServer už zabírá jedno místo ve skupině vláken. DataNode má také tuto interní třídu pro načtení počtu aktuálně aktivních vláken v této skupině:

  /** Počet souběžných xceiverů na uzel. */
int getXceiverCount() {
return threadGroup ==null ? 0 :threadGroup.activeCount();
}

Čtení a zápis bloků iniciovaných klientem způsobí navázání spojení, které je zabaleno vláknem DataXceiverServer do instance DataXceiver. Během tohoto předání se vytvoří vlákno a zaregistruje se do výše uvedené skupiny vláken. Takže pro každou aktivní operaci čtení a zápisu je na straně serveru sledováno nové vlákno. Pokud počet vláken ve skupině překročí nakonfigurované maximum, je vyvolána zmíněná výjimka a zaznamenána do protokolů DataNode:

  if (curXceiverCount> dataXceiverServer.maxXceiverCount) {
hodit novou IOException(“xceiverCount ” + curXceiverCount
+ ” překračuje limit souběžných xcievers ”
+ dataXceiverServer.maxXceiverCount);
}

Důsledky pro klienty

Nyní je otázkou, jak souvisí čtení a zápis klienta s vlákny na straně serveru. Než se však pustíme do podrobností, použijme informace o ladění, které třída DataXceiver zaznamená, když je vytvořena a uzavřena

  LOG.debug(“Počet aktivních připojení je:” + datanode.getXceiverCount());
…
LOG.debug(datanode.dnRegistration + “:Počet aktivních připojení je:”     + datanode.getXceiverCount());

a během spuštění HBase sledovat, co je přihlášeno na DataNode. Pro jednoduchost se to děje na pseudo distribuovaném nastavení s jedinou instancí DataNode a RegionServer. Následující ukazuje horní část stavové stránky RegionServeru.

Důležitá část je v sekci „Metrics“, kde je napsáno „storefiles=22“. Takže za předpokladu, že HBase má alespoň tolik souborů ke zpracování, plus nějaké další soubory pro záznam napřed, měli bychom vidět výše uvedenou zprávu protokolů, že máme alespoň 22 „aktivních připojení“. Spusťte HBase a zkontrolujte soubory protokolu DataNode a RegionServer:

Příkazový řádek:

$ bin/start-hbase.sh
…

Protokol datového uzlu:

2012-03-05 13:01:35,309 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Počet aktivních připojení je: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):Počet aktivních připojení je:2
12/03/05 13:01:35 StemoremLimitlus3globalemserver6 globalMemStoreLimitLowMark=347,1m, maxHeap=991,7m
12/03/05 13:01:39 INFO http.HttpServer:Port vrácený webServer.getConnectors()[0].getLocalPort() před open() je -1 . Otevření posluchače na 60030
2012-03-05 13:01:40,003 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:1
12/03/05 13:01:40 INFO regionserver.HRegionServer:Přijatý požadavek na otevření regionu:-ROOT-,,0.70236052
2012-03-05 13:01:40,882 DEBUG org.apache.hadoop.hdfs.server.datadenode.Data :Počet aktivních připojení je:3
2012-03-05 13:01:40,884 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, storageID36DS-10 -10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Počet aktivních připojení je:4
2012-03-05 13:01:40,888 DEBUG org.aphached.hado datanode.DataNode:Počet aktivních připojení je: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:Počet aktivních připojení je:3
2012-03-05 13 :01:40,983 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště=DS-1423642448-10.0.0.64-522355pc=0525225570pc=0252355pc=0077223225570 Počet aktivních připojení je:4
…
12/03/05 13:01:41 INFO regionserver.HRegionServer:Přijatý požadavek na otevření regionu:.META.,,1.1028785192
2012-03 -05 13:01:41,026 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je: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, info055, iberport=50075 …
12/03/05 13:01:41 INFO regionserver.HRregion:Onlined .META.,,1.1028785192; next sequenceid=63082
2012-03-05 13:01:41,109 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:3
2012-03-05 13 :01:41,114 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:4
2012-03-05 13:01:41,117 DEBUG org.apache.hadoop.hdfs.server .datanode.DataNode:Počet aktivních připojení je:5
12/03/05 13:01:41 INFO regionserver.HRegionServer:Přijat požadavek na otevření 16 regionů
12/03/05 13 :01:41 INFO regionserver.HRegionServer:Přijatý požadavek na otevření regionu:usertable,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.
Re1eg,12/03/05 11HRerserver,11eg 2.tabulka regionserver:1117ved regionserver:4 open region:1117ved regionserver:4 open 1330944810191.90d287473fe223f0ddc137020efda25d.
…

2012-03-05 13:01:41,246 DEBUG org.apache.hadoop.hdfs.server.datanode. DataNode:Počet aktivních připojení je:6
2012-03-05 13:01:41,248 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:7
…
2012-03-05 13:01:41,257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště=DS-1423642413.23020236402443.202 , infoPort=50075, ipcPort=50020):Počet aktivních připojení je:10
2012-03-05 13:01:41,257 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration.0 0.1:50010, storageID=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Počet aktivních připojení je:9
/…
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined usertable,,1330944810191.62a312d67981c86c42b6bc02e6ec7e3f.; další sekvenceid=62916
…
12/03/05 13:01:41 INFO regionserver.HRegion:Online uživatelská tabulka,uživatel1361265841,1330944811370.80663fcf291e3ce09064f6ba05; next sequenceid=62919
2012-03-05 13:01:41,474 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:6
2012-03-05 13 :01:41,491 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:7
2012-03-05 13:01:41,495 DEBUG org.apache.hadoop.hdfs.server .datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště=DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipc22br aktivní připojení =220:00:0000 -05 13:01:41,508 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:7
…
12/03/05 13:01:41 INFO regionserver .HRegion:Online uživatelská tabulka,uživatel1964968041,1330944848231.dd89596e9129e1caa7e07f8a491c9734.; next sequenceid=62920
2012-03-05 13:01:41,618 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je: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.64-525355pc=052522355pc=00772232550pc=0077 Počet aktivních připojení je:7
…
2012-03-05 13:01:41,829 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště =DS-1423642448-10.0.0.64-50010-1321352233772, infoPort=50075, ipcPort=50020):Počet aktivních připojení je:7
12/03/05 13:01:41 Online userserverd.HRegion region INFO ,uživatel515290649,1330944849739.d23924dc9e9d5891f332c337977af83d.; next sequenceid=62926
2012-03-05 13:01:41,832 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:6
2012-03-05 13 :01:41,838 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště=DS-1423642448-10.0.0.64-525355pc=052722355pc=0077223225570pc=00017) Počet aktivních připojení je:7
12/03/05 13:01:41 INFO regionserver.HRegion:Onlined usertable,user757669512,1330944850808.cd0d6f16d8ae9cf0c9277f5b9f.6; next sequenceid=62929
…
2012-03-05 14:01:39,711 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:Počet aktivních připojení je:4
2012 -03-05 22:48:41,945 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště=DS-1423642448-10.25230.60705752030.6705752030.605 ipcPort=50020):Počet aktivních připojení je:4
12/03/05 22:48:41 INFO regionserver.HRegion:Onlined usertable,user757669512,1330944850808.cd0d6f16006aef57c.c6 další sekvence id=62929
2012-03-05 22:48:41,963 DEBUG org.apache.hadoop.hdfs.server.datanode.DataNode:DatanodeRegistration(127.0.0.1:50010, ID úložiště 36048 DS-14. -50010-1321352233772, infoPort=50075, ipcPort=50020):Počet aktivních připojení je:4

Můžete vidět, jak se regiony otevírají jedna po druhé, ale také si můžete všimnout, že počet aktivních připojení nikdy nevyšplhá na 22 – sotva dosáhne 10. proč tomu tak je? Abychom tomu lépe porozuměli, musíme vidět, jak se soubory v HDFS mapují k instanci DataXceiveru na straně serveru – a skutečná vlákna, která představují.

Hluboký ponor Hadoop

Výše uvedené DFSInputStream a DFSOutputStream jsou skutečně fasádami kolem obvyklých konceptů streamů. Zabalí komunikaci klient-server do těchto standardních rozhraní Java a zároveň interně směrují provoz do vybraného DataNode – což je ten, který uchovává kopii aktuálního bloku. Má právo tato spojení otevírat a zavírat podle potřeby. Když klient čte soubor v HDFS, třídy klientských knihoven se transparentně přepínají z bloku do bloku, a tedy z DataNode na DataNode, takže musí podle potřeby otevírat a zavírat připojení.

DFSInputStream má instanci třídy DFSClient.BlockReader, která otevírá připojení k DataNode. Instance streamu volá blockSeekTo() pro každé volání funkce read() , která se postará o otevření připojení, pokud ještě žádné neexistuje. Jakmile je blok kompletně přečten, spojení je uzavřeno. Zavření streamu má samozřejmě stejný účinek.

DFSOutputStream má podobnou pomocnou třídu, DataStreamer. Sleduje připojení k serveru, které je zahájeno metodou nextBlockOutputStream(). Má další interní třídy, které pomáhají s vypisováním dat bloku, které zde pro stručnost vynecháváme.

Bloky zápisu i čtení vyžadují vlákno, které drží soket a mezilehlá data na straně serveru, zabalená do instance DataXceiver. V závislosti na tom, co váš klient dělá, uvidíte, že počet připojení kolísá kolem počtu aktuálně používaných souborů v HDFS.

Zpět k hádance HBase výše:důvod, proč nevidíte až 22 (a více) připojení během startu, je ten, že zatímco jsou regiony otevřené, jedinými požadovanými údaji je informační blok HFile. Tento blok se přečte, aby se získaly důležité podrobnosti o každém souboru, ale pak se znovu zavře. To znamená, že prostředek na straně serveru je uvolněn rychle za sebou. Zbývající čtyři spojení je těžší určit. JStack můžete použít k výpisu všech vláken na DataNode, což v tomto příkladu ukazuje tento záznam:

„DataXceiver pro klienta /127.0.0.1:64281 [blok pro odesílání blk_5532741233443227208_4201]“ 0dd70 prio=85 démon 0db06 nid=0x1178b4000 spustitelný [1178b3000]
java.lang.Thread.State:RUNNABLE
…

„DataXceiver pro klienta /127.0.0.1:64172 [blok příjmu blk_-2005512129579433420_4199_20bDFSC.lient_20bDFSC.0 ,60020,1330984111693_1330984118810]” démon prio=5 tid=7fb966109000 nid=0x1169cb000 spustitelný [1169ca000]
java.…NABLE.Tlang.

Toto jsou jediné položky DataXceiveru (v tomto příkladu), takže počet ve skupině vláken je trochu zavádějící. Připomeňme, že vlákno démona DataXceiverServer již představuje jednu položku navíc, která v kombinaci s výše uvedenými dvěma představuje tři aktivní připojení – což ve skutečnosti znamená tři aktivní vlákna. Důvod, proč místo toho protokol uvádí čtyři, je ten, že protokoluje počet z aktivního vlákna, které se blíží ke konci. Takže krátce poté, co se zaprotokoluje počet čtyř, je ve skutečnosti o jedno méně, tj. tři, a tudíž odpovídá našemu počtu aktivních vláken.

Všimněte si také, že interní pomocné třídy, jako je PacketResponder, zabírají jiné vlákno ve skupině, zatímco jsou aktivní. Výstup JStack tuto skutečnost naznačuje a uvádí vlákno jako takové:

 „PacketResponder 0 pro blok blk_-2005512129579433420_4199“ démon prio=5 tid=7fb96300x in16 Object=000. () [116acd000]
java.lang.Thread.State:TIMED_WAITING (na objektovém monitoru)
na java.lang.Object.wait (Nativní metoda)
na org.apache.hadoop. hdfs.server.datanode.BlockReceiver$PacketResponder \
.lastDataNodeRun(BlockReceiver.java:779)
– uzamčeno (org.apache.hadoop.hdfs.server.datanode.BlockReceiver)$PacketRespond>na org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder.run(BlockReceiver.java:870)
na java.lang.Thread.run(Thread.java:680)

Toto vlákno je aktuálně ve stavu TIMED_WAITING a není považováno za aktivní. To je důvod, proč počet vydávaný příkazy protokolu DataXceiver nezahrnuje tento druh vláken. Pokud se stanou aktivními, protože klient odesílá data, počet aktivních vláken se opět zvýší. Další věc, kterou je třeba poznamenat, je, že toto vlákno nepotřebuje samostatné připojení nebo soket mezi klientem a serverem. PacketResponder je pouze vlákno na straně serveru, které přijímá bloková data a streamuje je do dalšího DataNode v kanálu zápisu.

Příkaz Hadoop fsck má také možnost hlásit, jaké soubory jsou aktuálně otevřené pro zápis:

$ hadoop fsck /hbase -openforwrite
FSCK spustil larsgeorge z /10.0.0.29 pro cestu / hbase v pondělí 5. března 22:59:47 CET 2012
……/hbase/.logs/10.0.0.29,60020,1330984111693/10.0.0.29%3A60020.13309240118% 3A60020.13309240118 TE 4, OPPP13092401188 ………………………………..Stav:ZDRAVÝ
Celková velikost:     2088783626 B
Celkový počet adresářů:     54
Celkový počet souborů:   45
…

To se bezprostředně netýká obsazeného vlákna na straně serveru, protože ty jsou přiděleny podle ID bloku. Ale dá se z toho poznat, že je tam jeden otevřený blok pro psaní. Příkaz Hadoop má další možnosti pro tisk skutečných souborů a ID bloku, ze kterých se skládají:

$ hadoop fsck /hbase -files -blocks
FSCK spustil larsgeorge z /10.0.0.29 pro cesta /hbase v úterý 6. března 10:39:50 CET 2012

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