Jag höll nyligen ett föredrag på LA Hadoop User Group om Apache HBase Do’s and Don’ts. Publiken var utmärkt och hade mycket informerade och välartikulerade frågor. Jody från Shopzilla var en utmärkt värd och jag är skyldig honom ett stort tack för att han fick möjligheten att prata med över 60 LA Hadoopers. Eftersom inte alla bor i LA eller kan ta sig till träffen har jag sammanfattat några av de viktigaste punkterna här. För er som har en hektisk dag, här är tl;dr:
- HBase är bra, men inte en RDBMS- eller HDFS-ersättning
- Bra konfiguration betyder bra funktion
- Monitor monitor monitor monitor monitor
Vi på Cloudera är stora fans av HBase. Vi älskar tekniken, vi älskar samhället och vi har upptäckt att det passar bra för många applikationer. Framgångsrik användning av HBase har dokumenterats väl och som ett resultat överväger många organisationer om HBase är en bra passform för vissa av deras applikationer. Drivkraften för mitt föredrag och det här uppföljningsblogginlägget är att förtydliga några av de bra applikationerna för HBase, varna för några dåliga applikationer och lyfta fram viktiga steg för en framgångsrik HBase-distribution.
När ska HBase användas
Det viktigaste att tänka på när man tittar på HBase är att även om det är en bra lösning på många problem, är det inte en silverkula. HBase är inte optimerad för klassiska transaktionsapplikationer eller ens relationsanalys. Det är inte heller ett komplett substitut för HDFS när man gör MapReduce i stora partier. Ta en titt på några av användningsfallen i det här inlägget för att få en känsla av vilka applikationer som passar bra för HBase och om du har frågor, gå vidare och posta på listorna. Har jag nämnt att samhället är fantastiskt?
Med den varningen ute – varför ska du använda HBase? Om din applikation har ett variabelt schema där varje rad är något annorlunda, bör du titta på HBase. Som ett exempel, gör en modelleringsövning med ett standardmässigt relationsschema; När du inte kan lägga till kolumner tillräckligt snabbt och de flesta av dem är NULL i varje rad, bör du överväga HBase. Om du upptäcker att din data är lagrad i samlingar, till exempel vissa metadata, meddelandedata eller binär data som alla är inskrivna på samma värde, bör du överväga HBase. Om du behöver nyckelbaserad åtkomst till data när du lagrar eller hämtar, bör du överväga HBase.
Stödtjänster
Förutsatt att du är övertygad om att HBase är en bra passform för din applikation, här är några tips du måste tänka på när du distribuerar den. Det finns några stödtjänster som är viktiga och en som krävs. Om du inte har tittat på ZooKeeper tidigare är det dags nu. HBase använder ZooKeeper för olika distribuerade samordningstjänster som masterval. Allt eftersom HBase utvecklas och växer fortsätter den att förlita sig på ZooKeeper för ytterligare funktionalitet, vilket gör det till en viktig del av systemet. Dessutom bör du ha ordentliga nätverkstjänster på plats som NTP och DNS. HBase är beroende av att alla noder i klustret har nära synkroniserade klockor och konsekvent hänvisar till varandra. Att använda NTP och DNS säkerställer att du inte stöter på konstiga beteenden när en nod A tror att klockan är imorgon och nod B tror att det är igår. Du kommer också att förhindra situationer där huvudnoden säger åt nod C att betjäna en region men nod C inte vet sitt eget namn och inte svarar. Att använda NTP och DNS kommer att spara mycket huvudvärk när du kommer igång.
Jag har sagt att det viktigaste när du väljer HBase är att se till att du har ett användningsfall som passar. Det viktigaste att göra när du använder HBase är att övervaka systemet. Övervakning är nyckeln till framgångsrik HBase-verksamhet. Som är fallet med många distribuerade system är HBase känsligt för kaskadfel. Om en nod börjar byta kan den tappa kontakten med mastern, vilket gör att en annan server tar upp lasten och blir överbelastad. Den andra servern kommer att misslyckas och felet kommer att överlappa. Du måste övervaka minnet, CPU:n, I/O och nätverkslatens och bandbredd på var och en av dina HBase-noder för att se till att de fungerar inom sunda parametrar. Övervakning är den viktigaste metoden för att driva ett hälsosamt HBase-kluster.
Bra metoder för HBase-arkitektur
Snabbspolning framåt till ditt välövervakade HBase-kluster som kör ett perfekt användningsfall, här är några bra metoder. Använd ett nyckelprefix som fördelar sig väl baserat på ditt användningsfall. Om du prefix din nyckel med tidsstämpel eller något liknande värde som, när det sorteras, lagras eller frågas i en batch, kommer du sannolikt att överbelasta varje regionserver i sin tur istället för att fördela belastningen jämnt. Du bör också hålla antalet regioner till ett rimligt antal baserat på memstore-storlek och mängd RAM och RegionServer JVM bör begränsas till 12 GB Java-hög för att minimera långa GC-pauser. Till exempel kan en maskin med 36 GB RAM som också kör en DataNode-demon hantera cirka 100 regioner med aktiva skrivningar och ett memlager på 48 MB vardera. Det ger tillräckligt med utrymme för DataNode- och RegionServer-minneskrav, Linux-filbuffertutrymme och en rimlig flushstorlek för varje RegionServer.
Några konfigurationsrekommendationer inkluderar att inaktivera automatisk komprimering (som standard sker det var 24:e timme från det att du startar HBase) och schemalägg den att köras varje dag vid lågtrafik. Du bör också konfigurera komprimering (som LZO) och uttryckligen lägga in den korrekt konfigurerade HBase conf-katalogen i din CLASSPATH.
HBase GÖR INTE
Vi har täckt ett brett utbud av god praxis för HBase. Det finns också några användningsmönster att undvika. Förvänta dig till exempel inte att använda HBase som en ersättning i grossistledet för var och en av dina relationsdatabaser. HBase är bra på många saker men det ersätter inte relationsdatabaser. Till att börja med pratar det inte SQL, har en optimerare, stödjer korsregistrerade transaktioner eller går med. Om du inte använder någon av dessa i din databasapplikation kan HBase mycket väl passa perfekt.
Var försiktig när du kör blandade arbetsbelastningar på ett HBase-kluster. När du har SLA på HBase-åtkomst oberoende av eventuella MapReduce-jobb (till exempel en transformation i Pig och serveringsdata från HBase) kör dem på separata kluster. HBase är CPU- och minnesintensiv med sporadisk stor sekventiell I/O-åtkomst medan MapReduce-jobb primärt är I/O-bundna med fast minne och sporadisk CPU. Kombinerade dessa kan leda till oförutsägbara latenser för HBase och CPU-strid mellan de två. Ett delat kluster kräver också färre uppgiftsplatser per nod för att tillgodose HBase CPU-krav (i allmänhet hälften av platserna på varje nod som du skulle allokera utan HBase). Håll även ett öga på minnesbyte. Om HBase börjar byta finns det en god chans att den missar ett hjärtslag och tappas från klustret. På ett upptaget kluster kan detta överbelasta en annan region, vilket gör att den byter och en kaskad av fel.
Sluta tankar
Ett sista råd innan vi summerar. När du laddar HBase, använd HFileOuputFormat om du laddar via ett MapReduce-jobb eller en samling servrar som använder batchputs. Att ladda med en enskild klient kommer att flaskhalsa den klienten och inte dra fördel av skalbarheten som HBase erbjuder.
Sammanfattningsvis, överväg HBase när du laddar data per nyckel, söker data efter nyckel (eller intervall), visar data per nyckel, frågar data per nyckel eller när du lagrar data per rad som inte stämmer väl överens med ett schema.
Användningsfall
- Apache HBase:Drivs av HBase Wiki
- Mozilla:Flytta Socorro till HBase
- Facebook:Facebooks nya meddelandesystem i realtid:HBase
- StumbleUpon:HBase på StumbleUpon