Seminarska NBnPiX Column family HBase (PDF)

Универзитет „Св. Кирил и Методиj“ - Скопjе
Факултет за Информатички Науки и Компjутерско Инженерство

Column-family бази на податоци
HBase

Атанас Димитровски, Иван Гиновски, Виктор Лукови´
к
14 jануари, 2016 година

1

Содржина
1 Вовед
1.1 Недостатоци каj релационите бази на податоци
леми податоци . . . . . . . . . . . . . . . . . . .
1.2 NoSql бази на податоци . . . . . . . . . . . . . .
1.3 Опис на проблемот коj к
´е биде решаван . . . .

3
при користење на
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

го. . .
. . .
. . .

2 Анализа на податоците
3 Практична примена
3.1 Column Family бази на податоци . . . . . . . . . . .
3.2 HBASE . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Aрхитектура на HBase . . . . . . . . . . . . .
3.3 Инсталациjа . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Инсталациjа на Hadoop . . . . . . . . . . . . .
3.3.2 Инсталациjа на HBase . . . . . . . . . . . . .
3.4 Подготовка на модел за внес на податоци во HBase
3.5 Внесување на податоците . . . . . . . . . . . . . . . .
3.6 Користење на податоците . . . . . . . . . . . . . . .
3.6.1 Hbase Shell . . . . . . . . . . . . . . . . . . . .
3.6.2 JAVA API . . . . . . . . . . . . . . . . . . . . .
3.6.3 Apache Drill . . . . . . . . . . . . . . . . . . .
4 Заклучок

3
3
4
4

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

6
6
6
8
10
10
14
15
18
21
21
22
28
28

2

1 Вовед
Big data претставува широко дефиниран израз, коj опишува големо количество на
податоци, чиjа големина наjчесто оневозможува нивно менаџирање, семплирање и
процесирање со помош на често користените софтверски алатки[1][2]. Податочните
множества се зголемуваат со невероjатна брзина како резултат на брзото и едноставно креирање на информации од страна на мобилни уреди, сензори, софтверски
програми, социjални мрежи, камери, микрофони и наjразлични други уреди. Се
проценува дека вкупната големина на сите податоци во светот во 2015 изнесувала
7.9 зетабаjти, а се очекува до 2020 година оваа броjка да порасне до 35 зетабаjти[3].
Проблемот коj произлегува е како брзо да се стигне до потребната информациjа.
Иако капацитетот за складирање податоци на податочните дискови е драстично
зголемен, брзината со коjа се пристапуваат или пак запишуваат податоците многу
малку се има подобрено. Решение на ваквиот проблем преставува поделба на податоците во различни складови, при што истите к
´е се пристапуваат паралелно. Ваквиот
начин, значително го намалува времето потребно за превземање и запишување податоци. Проблеми на кои што треба да се адресираат при ваквата имплементациjа
се: откажување на хардвер, сигурност на податоци и комбинирање на податоците
од различните складови.

1.1 Недостатоци каj релационите бази на податоци при
користење на големи податоци
Релационите бази на податоци претставуваат доминантна технологиjа за чување на
податоци. Tие промовираат ефикасност, конзистентност и сигурност. Трансакциите
се атомични, изолирани и постоjани. Ваквиот модел е докажан и треба да се користи доколку: податоците треба да се во конзистентна состоjба во секое време, има
стриктна шема на моделот коj што треба да се мапира во базата, големината на
податоци овозможува да се извршуваат прашања врз базата во време прифатливо
за целта на апликациjата. Проблемот каj ваквиот начин на чување се jавува кога
количината на податоците е значително поголема. Ригорозните мерки кои што ги
следат релационите бази на податоци наjчесто не одговараат кога имаме голем броj
на податоци. Потребно е пове´
ке време за да се извршат прашања. Друг проблем коj
се jавува е начинот на кои се чуваат податоците. Релационите бази налагаат тие да
бидат структурирани, додека во big data голем броj од податоците не се во таква
форма. Исто така тие се пове´
ке дизаjнирани за постоjани податоци, додека во big
data има рапидно зголемување на истите. Ваквите проблеми налагаат користење на
нов тип на бази на податоци нарачени NoSql бази на податоци.[4][5]

1.2 NoSql бази на податоци
NoSql базите на податоци овозможуваат механизам за складирање и превземање
податоци кои се моделирани на начин различен од табеларни релации кои се користат во релационите бази на податоци[6]. Тие се нерелациони бази на податоци

3

кои решаваат проблеми на скалабилност и достапност. Следат по слободен модел
за разлика од релационите бази на податоци. Таквиот модел е дизаjниран од Eric
Brewer и се нарекува BASE[7].
• Basic Availability - гарантираат дека за секое барање к
´e има позитвен или негативен одговор
• Soft - состоjбата на базата може да се смени со тек на време
• Eventual - Базата к
´е стане конзистента во некоj момент
NoSql базите на податоци можат да се поделат на четири типа:
• Key-value – секоj запис во базата е зачуван како име на атрибут ( или клуч )
заедно со неговата вредност
• Document - бази каде што секоj клуч е во пар со сложена податочна структура
наречена документ. Документите можат да содржат многу различни key-value,
key-array парови или вгнездени документи
• Column family – бази како Cassandra и HBase кои се оптимизирани за прашања врз големи податочни множества и наместо редици, чуваат колони од
податоци
• Graph – бази кои се користат за зачувување на информации за мрежи од
податоци, како социjални врски (Neo4J,Giraph)

´ биде решаван
1.3 Опис на проблемот коj ке
Проблемот коj к
´е биде разгледан во оваа семинарска е инсталациjа на column family
NoSql база на податоци. Внесување на пре-дефинирано множество податоци во базата. Користење на податоците преку преземање на истите од базата со помош на
прецизно одбрани прашања. NoSql базата на податоци коjа што к
´e биде разгледувана
се нарекува Apache HBase, развиена од Apache организациjата.

2 Анализа на податоците
Податочното множество кое што го користиме е создадено од податоци на Internet
Movie Database (http://www.imdb.com). IMDB претставува веб база на податоци коjа содржи податоци за филмови, телевизиски серии, актери и слично. Треба да се
напомене дека овие податоци не се од последно ажурираната верзиjа на IMDB, и
резултатите добиени од истата може да не се исти со последните податоци на IMDB.
Податоците ги добивме во sql датотка, коjа содржи наредба за внесување на податоците. За подобро разбирање на податоците со кои што треба да работиме превземавме неколку чекори. Наjпрво jа извршивме sql наредбата, и податоците ги внесовме
во MySql база на податоци. За подобар преглед, jа користиме ’MySql workbench’
алатката. Базата содржи податоци за филмови, актери и режисери. Дизаjнирана е
со помош на седум табели и тие се:

4

Фигура 2.1: EER диjаграм за IMDB базата на податоци

• Actors ( id, first_name, last_name, gender, film_count )
• Directors ( id, first_name, last_name )
• Directors_Genres ( director_id, genre, prob )
• Movies ( id, name, year, rank )
• Movies_Directors ( director_id, movie_id )
• Movies_Genres ( movie_id , genre )
• Roles ( actor_id, movie_id, role )
За филмовите се чуваат податоци за насловот, IMDB оценката и годината кога тоj е
излезен. Во посебна табела се чува жанрот на филмот. За актерите се чуваат податоци за нивното име и презиме, полот и броjот на филмови во коj глумеле. Улогите на
актерите се чуваат во табелата Roles. За Режисерите се чуваат податоци за нивното
име и презиме. Во табелата ’directors_genres’ се чуваат податоци за вероjатноста со
коjа што даден режисер режира одреден жанр.
Креиравме модел, користеj´
ки EER (extended entity–relationship) диjаграм за полесно да ги разбереме врските поме´гу табелите. Диjаграмот може да се види во фигура
2.1. Може да се забележи дека произлегуваат две табели од многу спрема многу врски. Првата таква табела е ’Roles’, коjа што произлегува од врската поме´гу
’movies’ и ’actors’ табелите и во неа се складира коj актер, во коj филм, каква улога

5

имал. Во другата таква табела, се чува коj режисер, коj филм го режирал. Табелите ’movies_genres’ и ’director_genres’ се во многу спрема еден врска со табелите
’movies’ и ’directors’ последователно.

3 Практична примена
´ биде претставен
Во овоj дел к
´е бидат обjаснети column family базите на податоци. Kе
процесот на инсталациjа на HBase column family базата на податоци и како таа
функционира.

3.1 Column Family бази на податоци
Column family NoSql базите се бази на податоци кои овозможуваат чување на податоците со помош на клучеви кои се мапирани до вредности, а вредностите се
групираат во пове´
ке фамилии од колони, каде секоjа фамилиjа од колони преставува мапа на податоци[8]. Податоците се пристапуваат во редици, каде секоj ред
има множество колони асоцирани за него. Редиците се пристапуваат со клуч, коj е
единствен за секоj ред. Една фамилиjа од колони, групира колони кои се слични по
природа и наjчесто се пристапуваат заедно. Предностите на користење ваков тип на
бази на податоци се[9]:
• Можност за додавање колони во било кое време, без притоа да треба да се
пополнат некои почетни вредности за сите постоечки колони
• Предности при работа со некое подмножество на податоци, каде к
´е бидат процесирани само податоците кои ги задоволуваат зададените услови на подмножеството
• Парциjално пристапување на податоците
Наjпознати бази на податоци кои го следат овоj модел сe: Apache HBase, Apache
Cassandra, Google Big Table, Hypertable и Amazon SimpleDB.

3.2 HBASE
HBase преставува дистрибуирана база на податоци базирана на колони, коjа што е
изградена врз основа на дистрибуираниот податочен систем на Hadoop. За подобро
разбирање на HBase наjпрво к
´е биде обjаснет Apache Hadoop.
Hadoop e развоjна околина со отворен код коjа овозможува зачувување и процесирање на големи податоци кои се распределени во пове´
ке кластери. Работи како
интерфеjс на HDFS (Hadoop Distributed File System) од каде овозможува запишување и читање на податоци. Hadoop e направен за да работи со големи податоци
чиjа структура може да се менува или пак да не постои. Потребата за NoSQL се
поjавила поради ограничувањата на релационите бази на податоци како што се недостигот да работат со големи податоци одржуваj´
ки добри перформанси и нивниот

6

статички модел на структурата. Hadoop, за разлика нуди брз пристап до податоци
и динамички модел на структурата, т.е. Hadoop e без одредена шема и е подложен
на промени. Истотака при пристап до податоци, релационите бази може да предизвикаат bottleneck (пренатрупаност) бидеj´
ки SQL прашањата може да бараат пове´
ке
споjувања на табели кои се нао´гаат во различни кластери. Апликациите, со помош
на Hadoop, имаат способност да вршат статистичка анализа на податоци во голем
обем[10]. Hadoop го користи Map Reduce алгоритмот за да ги спои податоците кои
се нао´гаат на различни кластери. Овоj алгоритам работи на тоj начин што процесирањето го разделува на две фази: мапирачка фаза и редуцирачка фаза. Во првата
фаза, податоците се групираат во клуч-вредност парови, додека во втората фаза,
податоците се сумаризираат. Податочните системи, кои менаџираат податоци кои се
нао´гаат на пове`
ке машини се наречени дистрибуирани податочни системи. Hadoop
доа´га со своj дистрибуиран податочен систем наречен HDFS (Hadoop Distributed
File System). HDFS следи пове´
ке концепти и тие се[11]:
• Блокови - Регуларните дискови се состоjат од блокови кои преставуваат минимална големина коjа што може да се запише или прочита. HDFS исто така го
следи овоj концепт, со тоа што блоковите тука се многу поголеми (предефинирано 64mb). Датотеките се делат на пове´
ке делови со големина на еден блок и
се запишуваат на независни единици. За разлика од регуларните дискови, доколку големината на датотеката е помала од блокот, таа не го окупира целиот.
Ваквиот концепт на складирање на податоците носи пове´
ке придобивки:
1. Една датотека може да биде поголема од големината на еден диск во
мрежата. Концептот на блокови овозможува таа да биде разделена на
пове´
ке дискови
2. Овозможуваат леснo копирање на податоците што резултира со голема
достапност и редундантност. Доколку даден блок е оштетен, податокот
к
´е биде прочитан од друг блок каде што се нао´га негова копиjа.
• Namenodes и Datanodes - HDFS jа користи master/slave архитектурата, каде
што namenode (именски jазел) е master, а постоjат пове´
ке datanodes (податочни
jазли) кои се нарекуваат workers. Namenode е задолжен за именскиот простор
(namespace) на податочниот систем. Го одржува дрвото на податочниот систем
и мета податоците за сите датотеки и директориуми во дрвото. Именскиот
jазел не чува податоци за локациjата на одредена датотека, туку комуницира
со податочните jазли за да jа добие таа информациjа. Податочните jазли се
работниците во овоj податочен систем. Тие складираат и преземаат податоци
од блоковите и периодично доставуваат листа со блокови на кои тие работат
до именскиот jазел. Доколку се оштети именскиот jазел, не постои начин да
се доjде до податоците и затоа треба да се прават копии од истиот.
• HDFS обединување - Како што се зголемува броjот на податоците, се зголемува и големината на именскиот jазел коj содржи референца до сите блокови во

7

податочниот систем. Мемориjата преставува ограничувачки фактор за скалирање. Со верзиjа 0.23 на Hadoop преставена е можноста за HDFS обединување,
односно можност за креирање пове´
ке именски jазли, каде што секоj jазел се
грижи за парциjален дел од именскиот простор на податочниот систем.
• Висока достапност - Со верзиjа 0.23 на Hadoop, претставен е начин на работа
при пад на именскиот jазел. Потребата од ваквиот пристап е поради времето
потребно за стартување на нов именски jазол при пад. HDFS креира именски
jазли кои се нао´гаат во пасивна состоjба, и се активираат при пад на главниот
именски jазел. Тие служат за опслужување на барања додека не се подигне
нов именски jазел.
Знаеj´
ки за дистрибуираниот податочен систем на Hadoop, можеме да продолжиме со анализа на HBase NoSql базата на податоци. Се користи кога е потребно да
се извршат наредби за читање или пак запишување со случаен пристап до големи
податочни множества во реално време. Постоjат голем броj на имплементации за
складирање и читање на податоци, но наjголемиот броj од нив не се изградени со
цел да можат да бидат скалирани и дистрибуирани. Многу организации нудат репликациjа и партиционирање на базите, но наjчесто тие решениjа преставуваат некакви
дополнителни поправки и додатоци на ве´
ке постоечките, и се премногу комплексни
и комплицирани за инсталациjа и одржување. HBase проблемот со скалирање го
решава со помош на додавање на пове´
ке jазли, со што скалирањето е линеарно.
3.2.1 Aрхитектура на HBase
Податоците се чуваат во именувани табели. Табелите се составени од редици и ко´
лони. Келиите
во табелата можат да имаат пове´
ке верзии. Наjчесто верзиjата се
гледа според времето кога податокот бил внесен во к
´елиjата. Податоците се чуваат
како низа од баjти. Секоj ред во табелата има единствен идентификациски клуч коj
исто така е низа од баjти, оттука следи дека секоj тип на податок може да биде
клуч. Редиците во табелите се сортирани според клучот. Сите пристапи до табелата се прават со помош на клучот. Колоните се групираат во фамилиjа од колони.
Колоните кои се нао´гаат во една фамилиjа наjчесто се слични ме´гу себе и се пристапуваат заедно. Името на една фамилиjа од колони како и името на табелата треба
да се состои од карактери кои можат да се печатат. Имињата на колоните во една
фамилиjа колони се составени од низа од баjти. При креирање на табелата, мора да
се специфицираат имињата на табелата и фамилиите колони. Колоните во фамилиите можат да бидат додадени во било кое време. Сите членови на една фамилиjа
физички се складираат заедно во податочниот систем, од каде произлегува името
на овие NoSql бази на податоци - column family[13].
Табелите се партицираат хоризонтално од страна на HBase во региони. Секоj регион
се состои од подмножество на редици од табела. Регионот се идентификува според
табелата за коj е задолжен, првиот ред коj го чува и последниот. Наjчесто табелите
зафа´
каат еден регион, но доколку нивната големина се зголеми значително тие се
делат во пове`
ке. Ажурирањето на редиците е атомично.

8

Фигура 3.1: Дизаjн на табела во HBase[12]

HBase се состои од 3 типа сервери (фигура 3.2) [14]:
1. Slave servers (регионски) служат за читање и запишување податоци, можат
да одржуваат пове´
ке региони. Регионските сервери се извршуваат на HDFS
податочни jазли и ги имаат компонентите:
а) Write Ahead Log - за нови податоци кои не се зачувани
б) Кеш на блок - за наjчесто пристапени податоци
в) Memstore - кеш мемориjа за пишување, сортирана мапа од клуч-вредност,
чува податоци кои се уште не се запишани на диск
г) Hfile датотека - за сортирани клуч-вредности на диск
Серверите може да се додаваат или бришат од кластер динамично, додека
Hadoop продолжува без прекин.
2. Master servers служат за креирање, бришење на табели и менаџирање на
slave серверите (им доделуваат региони, одговараат на нотификации)
3. Zookeper како дистрибуиран, координатен сервис за одржување на кластери.
Zookeper-от служи за проверка на податочните jазли, кoj прима сигнали преку краткотраjни т.н. пулсеви за проверка на функционалноста на регионите
и пра´
ка нотификации до Master серверот доколку има пад каj регионските
сервери. Истотака содржи Meta табела, коjа содржи листа од сите региони во
системот и служи за посочување кон соодветните региони, при даден клуч.

9