Наскоро изнесох лекция в LA Hadoop User Group за Apache HBase, които трябва и не трябва. Публиката беше отлична и имаше много информирани и добре формулирани въпроси. Джоди от Shopzilla беше отличен домакин и му дължа голяма благодарност за възможността да говоря с над 60 LA Hadoopers. Тъй като не всички живеят в Ел Ей или биха могли да стигнат до срещата, аз обобщих някои от най-важните точки тук. За тези от вас с натоварен ден, ето tl;dr:
- HBase е добър, но не е заместител на RDBMS или HDFS
- Добрата конфигурация означава добра работа
- Монитор монитор монитор монитор монитор монитор
Ние от Cloudera сме големи фенове на HBase. Обичаме технологията, обичаме общността и открихме, че тя е чудесно подходяща за много приложения. Успешното използване на HBase е добре документирано и в резултат на това много организации обмислят дали HBase е подходящ за някои от техните приложения. Импулсът за моята беседа и тази последваща публикация в блога е да изясня някои от добрите приложения за HBase, да предупредя срещу някои лоши приложения и да подчертая важни стъпки за успешно внедряване на HBase.
Кога да използвам HBase
Най-важното съображение при разглеждането на HBase е, че макар да е чудесно решение на много проблеми, той не е сребърен куршум. HBase не е оптимизиран за класически транзакционни приложения или дори за релационни анализи. Освен това не е пълен заместител на HDFS, когато правите голяма партида MapReduce. Разгледайте някои от случаите на използване в тази публикация, за да получите представа кои приложения са подходящи за HBase и ако имате въпроси, продължете и публикувайте в списъците. Споменах ли, че общността е фантастична?
С това предупреждение – защо трябва да използвате HBase? Ако вашето приложение има променлива схема, където всеки ред е малко по-различен, тогава трябва да погледнете HBase. Като пример, правене на упражнение за моделиране, използвайки стандартна релационна схема; Когато не можете да добавяте колони достатъчно бързо и повечето от тях са NULL във всеки ред, трябва да помислите за HBase. Ако установите, че вашите данни се съхраняват в колекции, например някои метаданни, данни за съобщения или двоични данни, които всички са с една и съща стойност, тогава трябва да помислите за HBase. Ако имате нужда от достъп до данни, базиран на ключ, при съхранение или извличане, тогава трябва да помислите за HBase.
Поддържащи услуги
Ако приемем, че сте убедени, че HBase е подходящ за вашето приложение, ето няколко съвета, които трябва да имате предвид, когато го разгръщате. Има няколко поддържащи услуги, които са важни и една, която е необходима. Ако не сте гледали ZooKeeper преди, сега е моментът. HBase използва ZooKeeper за различни разпределени координационни услуги като главен избор. Тъй като HBase се развива и расте, той продължава да разчита на ZooKeeper за допълнителна функционалност, което го прави ключова част от системата. Освен това трябва да имате подходящи мрежови услуги като NTP и DNS. HBase зависи от всички възли в клъстера, които имат тясно синхронизирани часовници и се отнасят последователно един към друг. Използването на NTP и DNS гарантира, че няма да се сблъскате с странно поведение, когато един възел A смята, че времето е утре, а възел B смята, че е вчера. Вие също така ще предотвратите ситуации, при които главният възел казва на възел C да обслужва регион, но възел C не знае собственото си име и не отговаря. Използването на NTP и DNS ще спести много главоболия, когато започнете.
Казах, че най-важното съображение при избора на HBase е да се уверите, че имате подходящ случай на употреба. Най-важното нещо, което трябва да направите, когато използвате HBase, е да наблюдавате системата. Мониторингът е ключът към успешните операции на HBase. Както в случая с много разпределени системи, HBase е податлив на каскадни откази. Ако един възел започне да се разменя, той може да загуби контакт с главния, което води до друг раздел да поеме товара и да се натовари. Този втори сървър ще се провали и повредата ще се появи каскадно. Трябва да наблюдавате паметта, процесора, I/O и латентността на мрежата и честотната лента на всеки от вашите HBase възли, за да сте сигурни, че работят в рамките на здрави параметри. Наблюдението е най-важната практика за функциониране на здрав HBase клъстер.
Добри практики за HBase архитектура
Бързо напред към вашия добре наблюдаван HBase клъстер, работещ с перфектен случай на употреба, ето някои добри практики. Използвайте ключов префикс, който се разпространява добре въз основа на вашия случай на употреба. Ако поставите префикс на ключа си по времева марка или друга подобна стойност, която, когато е сортирана, се съхранява или запитва в пакет, тогава вероятно ще претоварите всеки регион сървър на свой ред, вместо да разпределите равномерно натоварването. Също така трябва да поддържате броя на регионите на разумен брой въз основа на размера на memstore и количеството RAM, а JVM на RegionServer трябва да бъде ограничен до 12GB java heap, за да се сведат до минимум дългите GC паузи. Например машина с 36 GB RAM, която също работи с демон DataNode, може да обработва приблизително 100 региона с активни записи и памет от 48 MB всеки. Това позволява достатъчно пространство за изискванията за памет на DataNode и RegionServer, буферно пространство за файлове на Linux и разумен размер за изтриване за всеки RegionServer.
Няколко препоръки за конфигурация включват деактивиране на автоматичното уплътняване (по подразбиране това се случва на всеки 24 часа от момента, в който стартирате HBase) и насрочете да работи всеки ден в непиково време. Трябва също да конфигурирате компресия (като LZO) и изрично да поставите правилно конфигурираната HBase conf директория във вашия CLASSPATH.
HBase НЕ ТРЯБВА
Обхванахме широк спектър от добри практики за HBase. Има и няколко модела на използване, които трябва да избягвате. Например, не очаквайте да използвате HBase като заместител на едро за всяка една от вашите релационни бази данни. HBase е страхотен в много неща, но не замества релационни бази данни. Като начало, той не говори за SQL, няма оптимизатор, поддържа транзакции с кръстосани записи или присъединявания. Ако не използвате нито едно от тях в приложението си за база данни, тогава HBase може да е идеалният вариант.
Бъдете внимателни, когато изпълнявате смесени натоварвания на HBase клъстер. Когато имате SLA за достъп до HBase, независим от каквито и да е задания на MapReduce (например трансформация в Pig и обслужване на данни от HBase), изпълнете ги на отделни клъстери. HBase е с интензивен процесор и памет със спорадичен голям последователен I/O достъп, докато заданията на MapReduce са предимно I/O свързани с фиксирана памет и спорадичен CPU. Комбинирани това може да доведе до непредвидими латентности за HBase и CPU спор между двете. Споделеният клъстер също изисква по-малко слотове за задачи на възел, за да посрещне изискванията на HBase CPU (обикновено половината от слотовете на всеки възел, които бихте разпределили без HBase). Също така внимавайте за смяната на паметта. Ако HBase започне да се разменя, има голям шанс да пропусне сърдечен ритъм и да бъде изхвърлен от клъстера. При натоварен клъстер това може да претовари друг регион, което ще доведе до размяната му и каскада от неуспехи.
Последни мисли
Един последен съвет преди да обобщим. Когато зареждате HBase, използвайте HFileOuputFormat, ако зареждате чрез задание MapReduce или колекция от сървъри, използващи пакетни пускания. Зареждането с един клиент ще доведе до тесничко на този клиент и няма да се възползва от мащабируемостта, предоставена от HBase.
В обобщение, помислете за HBase, когато зареждате данни по ключ, търсите данни по ключ (или диапазон), обслужвате данни по ключ, заявявате данни по ключ или когато съхранявате данни по ред, които не отговарят добре на схема.
Случаи на употреба
- Apache HBase:Осъществено от HBase Wiki
- Mozilla:Преместване на Socorro към HBase
- Facebook:Новата система за съобщения в реално време на Facebook:HBase
- StumbleUpon:HBase в StumbleUpon
