6.1 Hvem opfandt HBase og hvorfor

I dette foredrag vil vi tale om et så vidunderligt værktøj som Hbase, som for nylig har vundet stor popularitet: Facebook bruger det for eksempel som grundlag for sit beskedsystem, og det siger allerede en del.

Foredraget vil tale om konceptet Big Table og dets gratis implementering, funktioner i arbejde og forskel fra både klassiske relationsdatabaser (såsom MySQL og Oracle) og nøgleværdi-lagring såsom Redis, Aerospike og memcached. Lad os som sædvanlig starte med historien om problemet. Som mange andre BigData-projekter blev Hbase født ud fra et koncept, der blev udviklet af Google. Principperne bag Hbase blev beskrevet i Bigtable: A Distributed Storage System for Structured Data artiklen .

Som vi diskuterede i tidligere forelæsninger, er almindelige filer ganske velegnede til batchdatabehandling ved hjælp af MapReduce-paradigmet. På den anden side er oplysninger, der er gemt i filer, ret ubelejlige at opdatere; Filer er også frataget muligheden for tilfældig adgang. For hurtigt og bekvemt arbejde med tilfældig adgang er der en klasse af nosql-systemer såsom nøgleværdilagring, såsom Aerospike, Redis, Couchbase, Memcached. Batchbehandling er dog normalt meget ubelejligt i disse systemer. Hbase er et forsøg på at kombinere bekvemmeligheden ved batchbehandling med bekvemmeligheden ved opdatering og tilfældig adgang.

6.2 Datamodel

HBase er en distribueret, kolonneorienteret, multiversion nøgleværdidatabase.

  • Dataene er organiseret i tabeller indekseret af en primær nøgle kaldet RowKey i Hbase.
  • For hver RowKey-nøgle kan et ubegrænset sæt attributter (eller kolonner) gemmes.
  • Kolonner er organiseret i grupper af kolonner kaldet Kolonnefamilie. Som regel kombineres kolonner, der har samme brugs- og lagermønster, til én kolonnefamilie.
  • For hver egenskab kan der gemmes flere forskellige versioner. Forskellige versioner har forskellige tidsstempel.

Poster gemmes fysisk i RowKey-sorteret rækkefølge. I dette tilfælde lagres dataene svarende til forskellige kolonnefamilier separat, hvilket gør det muligt, om nødvendigt, kun at læse data fra den ønskede kolonnefamilie.

Når en bestemt attribut slettes, slettes den ikke fysisk med det samme, men markeres kun med et særligt gravstensflag. Den fysiske sletning af dataene vil ske senere, når den store komprimering udføres.

Attributter, der tilhører samme kolonnegruppe og svarer til samme nøgle, gemmes fysisk som en sorteret liste. Enhver attribut kan være fraværende eller til stede for hver nøgle, og hvis attributten er fraværende, forårsager dette ikke overhead ved lagring af tomme værdier.

Liste- og kolonnegruppenavnene er faste og har et overskueligt layout. På kolonnegruppeniveau indstilles parametre som time to live (TTL) og det maksimale antal lagrede versioner. Hvis forskellen mellem tidsstemplet for en bestemt version og det aktuelle tidspunkt er større end TTL, markeres posten til sletning. Hvis antallet af versioner for en bestemt attribut overstiger det maksimale antal versioner, markeres posten også til sletning.

Java webinar

Hbase-datamodellen kan huskes som et nøgleværdi-match:

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

6.3 Understøttede operationer

Listen over understøttede operationer i hbase er ret enkel. 4 hovedfunktioner understøttes:

  • Put : tilføje en ny post til hbase. Tidsstemplet for denne post kan indstilles manuelt, ellers indstilles det automatisk til det aktuelle tidspunkt.
  • Hent : Hent data for en specifik RowKey. Du kan angive kolonnefamilien, som vi vil tage dataene fra, og antallet af versioner, vi ønsker at læse.
  • Scan : læs poster én efter én. Du kan angive den post, som vi begynder at læse fra, den post, der skal læses til, antallet af poster, der skal læses, kolonnefamilien, hvorfra læsningen skal udføres, og det maksimale antal versioner for hver post.
  • Slet : Marker en specifik version til sletning. Der vil ikke være nogen fysisk sletning, den vil blive udskudt til næste større komprimering (se nedenfor).

6.4 Arkitektur

HBase er en distribueret database, der kan køre på snesevis eller hundredvis af fysiske servere, hvilket sikrer uafbrudt drift, selvom nogle af dem fejler. Derfor er arkitekturen i HBase ret kompleks sammenlignet med klassiske relationsdatabaser.

HBase bruger to hovedprocesser til sit arbejde:

1. Regionsserver - Betjener en eller flere regioner. En region er en række poster, der svarer til en specifik række af på hinanden følgende RowKeys. Hver region indeholder:

  • Persistent Storage er den vigtigste datalagring i HBase. Dataene gemmes fysisk på HDFS, i et særligt HFile-format. Data i HFile lagres i RowKey sorteret rækkefølge. Et par (region, søjlefamilie) svarer til mindst én HFIle.
  • MemStore - skrivebuffer. Da dataene er lagret i HF-fil d i sorteret rækkefølge, er det ret dyrt at opdatere HF-filen pr. I stedet kommer data ind i et særligt MemStore-hukommelsesområde, når de skriver, hvor de akkumuleres i nogen tid. Når MemStore er fyldt til en eller anden kritisk værdi, skrives dataene til en ny HFile.
  • BlockCache - cache til læsning. Giver dig mulighed for betydeligt at spare tid på data, der læses ofte.
  • Write Ahead Log (WAL) . Da data er skrevet til memstore, er der en vis risiko for datatab på grund af et nedbrud. For at forhindre dette i at ske, falder alle operationer før den faktiske implementering af manipulationerne ind i en speciel logfil. Dette giver dig mulighed for at gendanne data efter enhver fejl.

2. Master Server - hovedserveren i HBase-klyngen. Mesteren administrerer fordelingen af ​​regioner blandt regionsservere, vedligeholder et register over regioner, administrerer lanceringen af ​​almindelige opgaver og udfører andet nyttigt arbejde.

For at koordinere handlinger mellem tjenester, bruger HBase Apache ZooKeeper, en speciel tjeneste designet til at administrere konfigurationer og synkronisere tjenester.

Når mængden af ​​data i regionen stiger, og den når en vis størrelse, starter Hbase split, en operation, der deler regionen med 2. For at undgå konstante opdelinger af regioner, kan du forudindstille grænserne for regionerne og øge deres maksimum størrelse.

Da data for en region kan gemmes i flere HFiles, flettes dem med jævne mellemrum sammen for at fremskynde arbejdet. Denne operation kaldes komprimering i Hbase. Komprimeringerne er af to typer:

  • Mindre komprimering . Starter automatisk, kører i baggrunden. Har en lav prioritet sammenlignet med andre Hbase operationer.
  • Større komprimering . Den startes manuelt eller ved forekomsten af ​​visse triggere (for eksempel af en timer). Det har høj prioritet og kan bremse klyngen betydeligt. Større komprimeringer udføres bedst på et tidspunkt, hvor belastningen på klyngen er lille. Major Compaction sletter også fysisk data, der tidligere er markeret med gravsten.

6.5 Måder at arbejde med HBase på

HBase Shell

Den nemmeste måde at komme i gang med Hbase på er at bruge hbase shell-værktøjet. Den er tilgængelig umiddelbart efter installation af hbase på enhver hbase-klyndeknude.

Hbase shell er en jruby-konsol med indbygget understøttelse af alle grundlæggende Hbase-operationer. Det følgende er et eksempel på at oprette en brugertabel med to kolonnefamilier, udføre nogle manipulationer på den og slippe tabellen til sidst i 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'

Native API

Som de fleste andre hadoop-relaterede projekter er hbase implementeret i java, så det oprindelige api er tilgængeligt i Java. Native API er ret godt dokumenteret på den officielle hjemmeside. Her er et eksempel på brug af Hbase API taget derfra:

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();
 	}
  }
}

Sparsommelighed, REST og support til andre programmeringssprog

For at arbejde fra andre programmeringssprog leverer Hbase Thrift API og Rest API. Baseret på dem er klienter bygget til alle større programmeringssprog: python, PHP, Java Script osv.

6.6 Nogle funktioner ved at arbejde med HBase

  1. Hbase integreres ud af boksen med MapReduce, og kan bruges som input og output ved hjælp af det specielle TableInputFormat og TableOutputFormat.

  2. Det er meget vigtigt at vælge den rigtige RowKey. RowKey skal give en god jævn fordeling på tværs af regioner, ellers er der risiko for såkaldte "hot regions" - regioner, der bruges meget oftere end andre, hvilket fører til ineffektiv brug af systemressourcer.

  3. Hvis dataene ikke uploades enkeltvis, men umiddelbart i store partier, understøtter Hbase en speciel BulkLoad-mekanisme, der giver dig mulighed for at uploade data meget hurtigere end at bruge enkelte Puts. BulkLoad er grundlæggende en to-trins operation:

    • Dannelse af HFile uden deltagelse af puts ved hjælp af et særligt MapReduce job
    • Indsættelse af disse filer direkte i Hbase

  4. Hbase understøtter udlæsning af sine metrics til Ganglia-overvågningsserveren. Dette kan være meget nyttigt, når du administrerer Hbase for at komme til bunds i hbase-problemer.

række nøgle

RowKey er bruger-id'et, som er et GUUID, en streng, der er specielt genereret til at være unik på verdensplan. GUUID'er er fordelt jævnt, hvilket giver en god fordeling af data på tværs af servere.

Søjlefamilie

Vores lager bruger to søjlefamilier:

  • data. Denne gruppe af kolonner gemmer data, der ikke længere er relevante til reklameformål, såsom det faktum, at en bruger har besøgt bestemte webadresser. TTL for denne kolonnefamilie er sat til 2 måneder, grænsen på antallet af versioner er 2000.
  • lange data. Denne gruppe af kolonner gemmer data, der ikke mister sin relevans over tid, såsom køn, fødselsdato og andre "evige" brugeregenskaber.

højttalere

Hver type brugerfakta er gemt i en separat kolonne. For eksempel gemmer kolonnen Data:_v de URL'er, som brugeren har besøgt, og kolonnen LongData:køn gemmer brugerens køn.

Tidsstemplet for dette faktum gemmes som et tidsstempel. For eksempel i kolonnen Data:_v er tidsstemplet det tidspunkt, hvor brugeren besøgte en bestemt URL.

Denne lagringsstruktur for brugerdata passer meget godt til vores brugsmønster og giver dig mulighed for hurtigt at opdatere brugerdata, hurtigt få alle nødvendige oplysninger om brugere og ved hjælp af MapReduce hurtigt behandle data om alle brugere på én gang.

6.7 Alternativer

HBase er ret kompleks at administrere og bruge, så før du bruger HBase, giver det mening at se på alternativerne:

  • Relationelle databaser . Et meget godt alternativ, især i det tilfælde, hvor dataene passer på én maskine. Først og fremmest bør du også tænke på relationelle databaser i det tilfælde, hvor transaktioner af andre indekser end de primære er vigtige.

  • Opbevaring af nøgleværdi . Lager som Redis og Aerospike er bedre egnet, når der er behov for latency, og batchbehandling er mindre vigtig.

  • Filer og deres behandling med MapReduce . Hvis data kun tilføjes og sjældent opdateres/ændres, så er det bedre ikke at bruge HBase, men blot gemme dataene i filer. For at forenkle arbejdet med filer kan du bruge værktøjer som Hive, Pig og Impala.

Brugen af ​​HBase er berettiget, når:

  • Der er mange data, og de passer ikke på én computer/server
  • Data opdateres og slettes ofte
  • Der er en eksplicit "nøgle" i dataene, som det er praktisk at binde alt andet til
  • Har brug for batchbehandling
  • Har brug for tilfældig adgang til data med specifikke nøgler