Course All lectures for BG purposes - Lecture: BigData: HBase

6.1 Кой е изобретил HBase и защо

В тази лекция ще говорим за такъв прекрасен инструмент като Hbase, който наскоро придоби голяма популярност: например Facebook го използва като основа на своята система за съобщения и това вече говори много.

В лекцията ще говорим за концепцията на Big Table и нейната безплатна реализация, характеристиките на работа и разликата Howто от класическите релационни бази данни (като MySQL и Oracle), така и от хранorщата за ключ-стойност като Redis, Aerospike и memcached. Както обикновено, нека започнем с историята на проблема. Подобно на много други BigData проекти, Hbase е роден от концепция, разработена от Google. Принципите зад Hbase бяха описани в статията Bigtable: Разпределена система за съхранение на структурирани данни .

Както обсъдихме в предишни лекции, обикновените файлове са доста подходящи за пакетна обработка на данни с помощта на парадигмата MapReduce. От друга страна, информацията, съхранявана във файлове, е доста неудобна за актуализиране; Файловете също са лишени от възможността за произволен достъп. За бърза и удобна работа с произволен достъп има клас системи nosql като съхранение на ключ-стойност, като Aerospike, Redis, Couchbase, Memcached. Пакетната обработка обаче обикновено е много неудобна в тези системи. Hbase е опит да се комбинира удобството на пакетната обработка с удобството на актуализирането и произволния достъп.

6.2 Модел на данни

HBase е разпределена, ориентирана към колони, мултиversion ключ-стойност база данни.

Данните са организирани в таблици, индексирани от първичен ключ, наречен RowKey в Hbase.
За всеки клавиш RowKey може да се съхранява неограничен набор от атрибути (or колони).
Колоните са организирани в групи от колони, наречени семейство колони. По правило колоните, които имат еднакъв модел на използване и съхранение, се комбинират в едно семейство колони.
За всеки атрибут могат да се съхраняват няколко различни версии. Различните версии имат различно времево клеймо.

Записите се съхраняват физически в ред, сортиран по RowKey. В този случай данните, съответстващи на различно семейство колони, се съхраняват отделно, което позволява, ако е необходимо, да се четат данни само от желаното семейство колони.

Когато определен атрибут бъде изтрит, той не се изтрива физически веднага, а само се маркира със специален надгробен флаг. Физическото изтриване на данните ще се извърши по-късно, когато се извърши операцията за основно уплътняване.

Атрибутите, принадлежащи към една и съща група колони и съответстващи на един и същ ключ, се съхраняват физически като сортиран списък. Всеки атрибут може да липсва or да присъства за всеки ключ и ако атрибутът липсва, това не води до излишни разходи за съхраняване на празни стойности.

Имената на списъка и групите колони са фиксирани и имат ясно оформление. На ниво група колони се задават параметри като време за живот (TTL) и максимален брой съхранени версии. Ако разликата между клеймото за определена version и текущия час е по-голяма от TTL, записът се маркира за изтриване. Ако броят на версиите за даден атрибут надвишава максималния брой версии, записът също се маркира за изтриване.

Моделът на данните Hbase може да бъде запомнен като съвпадение на ключ-стойност:

<table, RowKey, Column Family, Column, timestamp> -> Value

6.3 Поддържани операции

Списъкът с поддържаните операции в hbase е доста прост. Поддържат се 4 основни операции:

Поставете : добавете нов запис към hbase. Часовото клеймо на този запис може да бъде зададено ръчно, в противен случай автоматично ще бъде зададено на текущия час.
Get : Вземете данни за конкретен RowKey. Можете да посочите семейството на колоните, от което ще вземем данните и броя версии, които искаме да прочетем.
Сканиране : четете записите един по един. Можете да посочите записа, от който да започнем да четем, записа, към който да четем, броя на записите за четене, семейството на колоните, от което ще се извършва четенето, и максималния брой версии за всеки запис.
Изтриване : Маркирайте конкретна version за изтриване. Няма да има физическо изтриване, то ще бъде отложено до следващото голямо уплътняване (вижте по-долу).

6.4 Архитектура

HBase е разпределена база данни, която може да работи на десетки or стотици физически сървъри, като гарантира непрекъсната работа дори ако някои от тях се повредят. Следователно архитектурата на HBase е доста сложна в сравнение с класическите релационни бази данни.

HBase използва два основни процеса за своята работа:

1. Регионален сървър - Обслужва един or повече региони. Регионът е диапазон от записи, съответстващи на конкретен диапазон от последователни RowKeys. Всеки регион съдържа:

Постоянното съхранение е основното хранorще на данни в HBase. Данните се съхраняват физически на HDFS, в специален HFile формат. Данните в HFile се съхраняват в ред, сортиран по RowKey. Една двойка (регион, семейство колони) съответства на поне един HFI-файл.
MemStore - буфер за запис. Тъй като данните се съхраняват в HFile d в сортиран ред, актуализирането на HFile на запис е доста скъпо. Вместо това при запис данните влизат в специална област на паметта MemStore, където се натрупват за известно време. Когато MemStore се запълни до няHowва критична стойност, данните се записват в нов HFile.
BlockCache - кеш за четене. Позволява ви значително да спестите време за данни, които се четат често.
Дневник за предварително записване (WAL) . Тъй като данните се записват в memstore, съществува известен риск от загуба на данни поради срив. За да не се случва това, всички операции преди реалното изпълнение на манипулациите попадат в специален лог файл. Това ви позволява да възстановите данни след всяка грешка.

2. Master Server - основният сървър в клъстера HBase. Главният управлява разпределението на региони между регионалните сървъри, поддържа регистър на регионите, управлява стартирането на редовни задачи и върши друга полезна работа.

За да координира действията между услугите, HBase използва Apache ZooKeeper, специална услуга, предназначена за управление на конфигурации и синхронизиране на услуги.

Когато количеството данни в региона се увеличи и достигне определен размер, Hbase започва разделяне, операция, която разделя региона на 2. За да избегнете постоянни разделения на региони, можете предварително да зададете границите на регионите и да увеличите техния максимум размер.

Тъй като данните за един регион могат да се съхраняват в няколко HFiles, Hbase периодично ги обединява, за да ускори работата. Тази операция се нарича уплътняване в Hbase. Уплътненията са два вида:

Незначително уплътняване . Стартира автоматично, работи във фонов режим. Има нисък приоритет в сравнение с други Hbase операции.
Основно уплътняване . Стартира се ръчно or при възникване на определени тригери (например от таймер). Има висок приоритет и може значително да забави клъстера. Основните уплътнения се извършват най-добре във време, когато натоварването на клъстера е малко. Основното уплътняване също физически изтрива данни, които преди са бor маркирани с надгробен камък.

6.5 Начини за работа с HBase

HBase Shell

Най-лесният начин да започнете с Hbase е да използвате помощната програма hbase shell. Той е достъпен веднага след инсталиране на hbase на всеки клъстерен възел на hbase.

Hbase shell е jruby конзола с вградена поддръжка за всички основни операции на Hbase. Следното е пример за създаване на потребителска table с две семейства колони, извършване на някои манипулации върху нея и изпускане на tableта в края в hbase shell:

create 'users', {NAME => 'user_profile', VERSIONS => 5}, {NAME => 'user_posts', VERSIONS => 1231231231} 
put 'users', 'id1', 'user_profile:name', 'alexander' 
put 'users', 'id1', 'user_profile:second_name', 'alexander' 
get 'users', 'id1' 
put 'users', 'id1', 'user_profile:second_name', 'kuznetsov' 
get 'users', 'id1' 
get 'users', 'id1', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
put 'users', 'id2', 'user_profile:name', 'vasiliy' 
put 'users', 'id2', 'user_profile:second_name', 'ivanov' 
scan 'users', {COLUMN => 'user_profile:second_name', VERSIONS => 5} 
delete 'users', 'id1', 'user_profile:second_name' 
get 'users', 'id1' 
disable 'users' 
drop 'users'

Роден API

Подобно на повечето други проекти, свързани с hadoop, hbase е имплементиран в java, така че собственият api е наличен в Java. Native API е доста добре documentиран на официалния уебсайт. Ето пример за използване на Hbase API, взет от там:

import java.io.IOException;

import org.apache.hadoop.hbase.*;
import org.apache.hadoop.hbase.client.*;
import org.apache.hadoop.hbase.util.Bytes;

public class MyLittleHBaseClient {
  public static void main(String[] args) throws IOException {
	Configuration config = HBaseConfiguration.create();
	Connection connection = ConnectionFactory.createConnection(config);
	try {
  	Table table = connection.getTable(TableName.valueOf("myLittleHBaseTable"));
  	try {
    	Put p = new Put(Bytes.toBytes("myLittleRow"));
    	p.add(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"),
    	Bytes.toBytes("Some Value"));
    	table.put(p);

    	Get g = new Get(Bytes.toBytes("myLittleRow"));
    	Result r = table.get(g);
    	byte [] value = r.getValue(Bytes.toBytes("myLittleFamily"),
      	Bytes.toBytes("someQualifier"));

    	String valueStr = Bytes.toString(value);
    	System.out.println("GET: " + valueStr);

    	Scan s = new Scan();
    	s.addColumn(Bytes.toBytes("myLittleFamily"), Bytes.toBytes("someQualifier"));
    	ResultScanner scanner = table.getScanner(s);
    	try {
       	for (Result rr = scanner.next(); rr != null; rr = scanner.next()) {
         	System.out.println("Found row: " + rr);
       	}
     	} finally {
       	scanner.close();
     	}
   	} finally {
     	if (table != null) table.close();
   	}
 	} finally {
   	connection.close();
 	}
  }
}

Thrift, REST и поддръжка за други езици за програмиране

За да работи от други езици за програмиране, Hbase предоставя Thrift API и Rest API. Въз основа на тях се изграждат клиенти за всички основни езици за програмиране: python, PHP, Java Script и др.

6.6 Някои характеристики на работа с HBase

Hbase се интегрира веднага с MapReduce и може да се използва като вход и изход с помощта на специалните TableInputFormat и TableOutputFormat.
Много е важно да изберете правилния RowKey. RowKey трябва да осигурява добро равномерно разпределение между регионите, в противен случай съществува риск от така наречените „горещи региони“ – региони, които се използват много по-често от други, което води до неефективно използване на системните ресурси.
Ако данните не се качват поотделно, а незабавно на големи партиди, Hbase поддържа специален механизъм BulkLoad, който ви позволява да качвате данни много по-бързо, отколкото да използвате единични Puts. BulkLoad по същество е операция в две стъпки:
- Формиране на HFile без участието на put с помощта на специално задание MapReduce
- Вмъкване на тези файлове директно в Hbase
Hbase поддържа извеждане на своите показатели към сървъра за мониторинг на Ganglia. Това може да бъде много полезно, когато администрирате Hbase, за да стигнете до дъното на проблемите с hbase.

ключ за ред

RowKey е потребителският идентификатор, който е GUUID, низ, специално генериран, за да бъде уникален в целия свят. GUUID се разпределят равномерно, което осигурява добро разпределение на данните между сървърите.

Колона Семейство

Нашето хранorще използва две семейства колони:

данни. Тази група от колони съхранява данни, които вече не са подходящи за рекламни цели, като например факта, че даден потребител е посетил определени URL addressи. TTL за това семейство колони е зададено на 2 месеца, ограничението за броя на версиите е 2000.
дълги данни. Тази група от колони съхранява данни, които не губят своята релевантност с течение на времето, като пол, дата на раждане и други „вечни“ потребителски характеристики.

високоговорители

Всеки тип потребителски факти се съхранява в отделна колона. Например колоната Data:_v съхранява URL addressите, посетени от потребителя, а колоната LongData:gender съхранява пола на потребителя.

Времевият печат на този факт се съхранява като времеви печат. Например в колоната Data:_v клеймото за време е времето, когато потребителят е посетил конкретен URL address.

Тази структура за съхранение на потребителски данни пасва много добре на нашия модел на използване и ви позволява бързо да актуализирате потребителските данни, бързо да получите цялата необходима информация за потребителите и, използвайки MapReduce, бързо да обработвате данни за всички потребители наведнъж.

6.7 Алтернативи

HBase е доста сложен за администриране и използване, така че преди да използвате HBase има смисъл да разгледате алтернативите:

Релационни бази данни . Много добра алтернатива, особено в случай, че данните се побират на една машина. Също така, на първо място, трябва да помислите за релационни бази данни в случай, когато транзакциите на индекси, различни от основния, са важни.
Съхранение на ключ-стойност . Хранorща като Redis и Aerospike са по-подходящи, когато е необходимо забавяне и груповата обработка е по-малко важна.
Файлове и тяхната обработка с MapReduce . Ако данните се добавят само и рядко се актуализират/променят, тогава е по-добре да не използвате HBase, а просто да съхранявате данните във файлове. За да опростите работата с файлове, можете да използвате инструменти като Hive, Pig и Impala.

Използването на HBase е оправдано, когато:

Има много данни и те не се побират на един компютър / сървър
Данните се актуализират и изтриват често
В данните има изричен „ключ“, към който е удобно да се обвърже всичко останало
Нуждаете се от групова обработка
Нуждаете се от произволен достъп до данни чрез определени ключове