Jeg holdt for nylig et foredrag i LA Hadoop User Group om Apache HBase Do's and Don'ts. Publikum var fremragende og havde meget informerede og velformulerede spørgsmål. Jody fra Shopzilla var en fremragende vært, og jeg skylder ham en stor tak for at have givet muligheden for at tale med over 60 LA Hadoopers. Da ikke alle bor i LA eller kunne komme til mødet, har jeg opsummeret nogle af de vigtigste punkter her. For dem af jer med en travl dag, her er tl;dr:
- HBase er god, men ikke en RDBMS- eller HDFS-erstatning
- God konfiguration betyder god drift
- Monitor monitor monitor monitor monitor
Vi hos Cloudera er store fans af HBase. Vi elsker teknologien, vi elsker fællesskabet, og vi har fundet ud af, at det passer godt til mange applikationer. Succesfuld brug af HBase er blevet veldokumenteret, og som følge heraf overvejer mange organisationer, om HBase passer godt til nogle af deres applikationer. Drivkraften til mit foredrag og dette opfølgende blogindlæg er at tydeliggøre nogle af de gode applikationer til HBase, advare mod nogle dårlige applikationer og fremhæve vigtige skridt til en vellykket HBase-implementering.
Hvornår skal du bruge HBase
Den vigtigste overvejelse, når man ser på HBase er, at selvom det er en god løsning på mange problemer, er det ikke en sølvkugle. HBase er ikke optimeret til klassiske transaktionsapplikationer eller endda relationelle analyser. Det er heller ikke en komplet erstatning for HDFS, når du laver MapReduce i store partier. Tag et kig på nogle af use cases i dette indlæg for at få en fornemmelse af, hvilke applikationer der passer godt til HBase, og hvis du har spørgsmål, så gå videre og skriv på listerne. Har jeg nævnt, at fællesskabet er fantastisk?
Med det forbehold ude af vejen – hvorfor skulle du bruge HBase? Hvis din applikation har et variabelt skema, hvor hver række er lidt anderledes, så bør du se på HBase. Som et eksempel, laver en modelleringsøvelse ved hjælp af et standard relationsskema; Når du ikke kan tilføje kolonner hurtigt nok, og de fleste af dem er NULL i hver række, bør du overveje HBase. Hvis du opdager, at dine data er gemt i samlinger, for eksempel nogle metadata, beskeddata eller binære data, der alle er indtastet på samme værdi, så bør du overveje HBase. Hvis du har brug for nøglebaseret adgang til data ved lagring eller hentning, så bør du overveje HBase.
Understøttende tjenester
Forudsat at du er overbevist om, at HBase passer godt til din applikation, er her nogle tips, du skal overveje, når du implementerer den. Der er et par understøttende tjenester, der er vigtige og en, der er påkrævet. Hvis du ikke har kigget på ZooKeeper før, er det nu. HBase bruger ZooKeeper til forskellige distribuerede koordinationstjenester såsom mastervalg. Efterhånden som HBase udvikler sig og vokser, fortsætter den med at stole på ZooKeeper for yderligere funktionalitet, hvilket gør det til en vigtig del af systemet. Derudover bør du have ordentlige netværkstjenester på plads, såsom NTP og DNS. HBase afhænger af, at alle noder i klyngen har tæt synkroniserede ure og refererer konsekvent til hinanden. Brug af NTP og DNS sikrer, at du ikke løber ind i mærkelig adfærd, når en node A tror, at tiden er i morgen, og node B tror, det er i går. Du vil også forhindre situationer, hvor masterknudepunktet fortæller node C at betjene en region, men node C ikke kender sit eget navn og ikke svarer. Brug af NTP og DNS vil spare en masse hovedpine, når du kommer i gang.
Jeg har sagt, at den vigtigste overvejelse, når du vælger HBase, er at sikre, at du har en use case, der passer. Det vigtigste at gøre, når du bruger HBase, er at overvåge systemet. Overvågning er nøglen til vellykket HBase-drift. Som det er tilfældet med mange distribuerede systemer, er HBase modtagelig for kaskadefejl. Hvis en node begynder at bytte, kan den miste kontakten med masteren, hvilket får en anden server til at samle belastningen op og blive overbebyrdet. Den anden server vil fejle, og fejlen vil kaskade. Du skal overvåge hukommelsen, CPU'en, I/O'en og netværkets latens og båndbredde på hver af dine HBase-noder for at sikre, at de fungerer inden for sunde parametre. Overvågning er den vigtigste praksis for at drive en sund HBase-klynge.
God praksis for HBase-arkitektur
Spol frem til din velovervågede HBase-klynge kører en perfekt use case, her er nogle gode fremgangsmåder. Brug et nøglepræfiks, der fordeler sig godt baseret på din use case. Hvis du præfikser din nøgle med tidsstempel eller en lignende værdi, der, når den er sorteret, gemmes eller forespørges i en batch, vil du sandsynligvis overbelaste hver regionsserver på skift i stedet for at fordele belastningen jævnt. Du bør også holde antallet af regioner på et rimeligt antal baseret på memstore størrelse og mængden af RAM, og RegionServer JVM bør begrænses til 12 GB java heap for at minimere lange GC pauser. For eksempel kunne en maskine med 36 GB RAM, der også kører en DataNode-dæmon, håndtere cirka 100 regioner med aktive skrivninger og et memstore på hver 48 MB. Det giver plads nok til DataNode- og RegionServer-hukommelseskrav, Linux-filbufferplads og en rimelig flush-størrelse for hver RegionServer.
Nogle få konfigurationsanbefalinger omfatter deaktivering af automatisk komprimering (det sker som standard hver 24. time fra det tidspunkt, du starter HBase) og planlæg den til at køre hver dag uden for spidsbelastningstidspunktet. Du bør også konfigurere komprimering (såsom LZO) og udtrykkeligt placere den korrekt konfigurerede HBase conf-mappe i din CLASSPATH.
HBase GØR IKKE
Vi har dækket en bred vifte af god praksis for HBase. Der er også et par brugsmønstre, der skal undgås. Forvent for eksempel ikke at bruge HBase som en grosserstatning for hver eneste af dine relationelle databaser. HBase er fantastisk til mange ting, men det erstatter ikke relationelle databaser. Til at begynde med taler den ikke SQL, har en optimering, understøtter krydsregistrering af transaktioner eller joins. Hvis du ikke bruger nogen af disse i din databaseapplikation, kan HBase meget vel være den perfekte pasform.
Vær forsigtig, når du kører blandede arbejdsbelastninger på en HBase-klynge. Når du har SLA'er på HBase-adgang uafhængigt af eventuelle MapReduce-job (f.eks. en transformation i Pig og serveringsdata fra HBase), så kør dem på separate klynger. HBase er CPU- og hukommelsesintensiv med sporadisk stor sekventiel I/O-adgang, mens MapReduce-job primært er I/O-bundet med fast hukommelse og sporadisk CPU. Kombineret kan disse føre til uforudsigelige ventetider for HBase og CPU-strid mellem de to. En delt klynge kræver også færre opgavepladser pr. node for at imødekomme HBase CPU-krav (generelt halvdelen af de pladser på hver node, som du ville allokere uden HBase). Hold også øje med memory swap. Hvis HBase begynder at bytte, er der en god chance for, at den vil gå glip af et hjerteslag og blive tabt fra klyngen. På en travl klynge kan dette overbelaste en anden region, hvilket får den til at skifte og en kaskade af fejl.
Sidste tanker
Et sidste råd inden vi opsummerer. Når du indlæser HBase, skal du bruge HFileOuputFormat, hvis du indlæser via et MapReduce-job eller en samling af servere, der bruger batch-puts. Indlæsning med en enkelt klient vil have en flaskehals på denne klient og ikke drage fordel af den skalerbarhed, som HBase tilbyder.
Sammenfattende kan du overveje HBase, når du indlæser data efter nøgle, søger data efter nøgle (eller område), serverer data efter nøgle, forespørger data efter nøgle eller når du gemmer data efter række, der ikke er i overensstemmelse med et skema.
Use Cases
- Apache HBase:Drevet af HBase Wiki
- Mozilla:Flytter Socorro til HBase
- Facebook:Facebooks nye realtidsmeddelelsessystem:HBase
- StumbleUpon:HBase hos StumbleUpon