6.1 Ki találta fel a HBase-t és miért

Ebben az előadásban egy olyan csodálatos eszközről lesz szó, mint a Hbase, amely az utóbbi időben nagy népszerűségre tett szert: például a Facebook ezt használja üzenetküldő rendszerének alapjául, és ez már sokat mond.

Az előadás a Big Table koncepciójáról és annak ingyenes megvalósításáról, a munka jellemzőiről és a klasszikus relációs adatbázisoktól (például MySQL és Oracle), valamint a kulcsérték-tárolóktól, mint például a Redis, az Aerospike és a memcached közötti különbségekről lesz szó. Szokás szerint kezdjük a probléma történetével. Sok más BigData projekthez hasonlóan a Hbase is a Google által kidolgozott koncepció alapján született. A Hbase alapelveit a Bigtable: A Distributed Storage System for Structured Data cikk ismerteti .

Amint azt az előző előadásokban tárgyaltuk, a közönséges fájlok meglehetősen alkalmasak kötegelt adatfeldolgozásra a MapReduce paradigmával. Másrészt a fájlokban tárolt információk frissítése meglehetősen kényelmetlen; A fájlokat a véletlenszerű hozzáférés lehetőségétől is megfosztják. A véletlen hozzáférésű gyors és kényelmes munkavégzéshez a nosql rendszerek egy osztálya létezik, mint például a kulcsértékek tárolása, mint például az Aerospike, Redis, Couchbase, Memcached. A kötegelt feldolgozás azonban általában nagyon kényelmetlen ezekben a rendszerekben. A Hbase a kötegelt feldolgozás kényelmét a frissítés és a véletlenszerű hozzáférés kényelmével ötvözi.

6.2 Adatmodell

A HBase egy elosztott, oszloporientált, több verziójú kulcsérték adatbázis.

  • Az adatok a Hbase-ben a RowKey nevű elsődleges kulcs által indexelt táblázatokba vannak rendezve.
  • Minden RowKey kulcshoz korlátlan számú attribútum (vagy oszlop) tárolható.
  • Az oszlopok oszlopcsaládokba vannak rendezve. Általános szabály, hogy az azonos használati és tárolási mintával rendelkező oszlopok egy oszlopcsaládba vannak egyesítve.
  • Minden attribútumhoz több különböző verzió is tárolható. A különböző verziók eltérő időbélyeggel rendelkeznek.

A rekordok fizikailag RowKey rendezett sorrendben vannak tárolva. Ebben az esetben a különböző Oszlopcsaládokhoz tartozó adatok külön kerülnek tárolásra, ami lehetővé teszi, hogy szükség esetén csak a kívánt oszlopcsaládból lehessen kiolvasni az adatokat.

Egy adott attribútum törlésekor az fizikailag nem törlődik azonnal, hanem csak egy speciális sírkő zászlóval van megjelölve. Az adatok fizikai törlésére később, a fő tömörítési művelet végrehajtásakor kerül sor.

Az azonos oszlopcsoporthoz tartozó és ugyanannak a kulcsnak megfelelő attribútumok fizikailag rendezett listaként tárolódnak. Bármely attribútum hiányozhat vagy jelen lehet minden kulcsnál, és ha az attribútum hiányzik, ez nem okoz többletköltséget az üres értékek tárolására.

A lista- és oszlopcsoportnevek rögzítettek, és egyértelmű elrendezésűek. Az oszlopcsoport szintjén olyan paraméterek vannak beállítva, mint az élettartam (TTL) és a tárolt verziók maximális száma. Ha egy adott verzió időbélyege és az aktuális idő közötti különbség nagyobb, mint a TTL, a bejegyzés törlésre kerül. Ha egy adott attribútum verzióinak száma meghaladja a verziók maximális számát, a rekord is törlésre kerül.

A Hbase adatmodell kulcs-érték egyezésként jegyezhető meg:

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

6.3 Támogatott műveletek

A hbase támogatott műveleteinek listája meglehetősen egyszerű. 4 fő művelet támogatott:

  • Put : új bejegyzés hozzáadása a hbase-hez. Ennek a bejegyzésnek az időbélyegzője kézzel beállítható, ellenkező esetben automatikusan az aktuális időre lesz beállítva.
  • Get : Adatok lekérése egy adott RowKey-hez. Megadható, hogy melyik oszlopcsaládból vesszük az adatokat, és hány verziót szeretnénk olvasni.
  • Szkennelés : a rekordok egyenkénti olvasása. Megadhatja, hogy melyik rekordtól kezdjük az olvasást, melyik rekordot olvassa el, hány rekordot olvasson, melyik oszlopcsaládból történik a kiolvasás, és az egyes rekordok maximális verziószáma.
  • Törlés : Egy adott verzió megjelölése törlésre. Fizikai törlés nem lesz, a következő nagy tömörítésig elhalasztják (lásd lent).

6.4 Építészet

A HBase egy elosztott adatbázis, amely több tucat vagy több száz fizikai szerveren futhat, biztosítva a zavartalan működést még akkor is, ha egyesek meghibásodnak. Ezért a HBase architektúrája meglehetősen bonyolult a klasszikus relációs adatbázisokhoz képest.

A HBase két fő folyamatot használ a munkájához:

1. Region Server – Egy vagy több régiót szolgál ki. A régió az egymást követő sorkulcsok meghatározott tartományának megfelelő rekordok tartománya. Minden régió a következőket tartalmazza:

  • A Persistent Storage a HBase fő adattárolója. Az adatokat fizikailag HDFS-en tárolják, speciális HFile formátumban. A HFile-ben tárolt adatok RowKey rendezett sorrendben kerülnek tárolásra. Egy pár (régió, oszlopcsalád) legalább egy HFIle-nek felel meg.
  • MemStore - írási puffer. Mivel az adatok rendezett sorrendben tárolódnak a HFile d-ben, a HFile rekordonkénti frissítése meglehetősen költséges. Ehelyett írás közben az adatok egy speciális MemStore memóriaterületre kerülnek, ahol egy ideig felhalmozódnak. Amikor a MemStore valamilyen kritikus értékre megtelt, az adatok egy új HFile-be íródnak.
  • BlockCache - gyorsítótár az olvasáshoz. Lehetővé teszi, hogy jelentősen időt takarítson meg a gyakran olvasott adatokkal.
  • Írjon előre naplót (WAL) . Mivel az adatok a memstore-ba íródnak, fennáll az adatvesztés veszélye egy összeomlás miatt. Ennek elkerülése érdekében a manipulációk tényleges végrehajtása előtt minden művelet egy speciális naplófájlba kerül. Ez lehetővé teszi az adatok helyreállítását bármilyen hiba után.

2. Master Server – a fő szerver a HBase-fürtben. A Mester irányítja a régiók elosztását a Régiószerverek között, vezeti a régiók nyilvántartását, irányítja a rendszeres feladatok elindítását és egyéb hasznos munkát végez.

A szolgáltatások közötti műveletek összehangolására a HBase az Apache ZooKeeper nevű speciális szolgáltatást használja, amely a konfigurációk kezelésére és a szolgáltatások szinkronizálására szolgál.

Amikor a régióban lévő adatmennyiség növekszik, és elér egy bizonyos méretet, a Hbase elkezdi a felosztást, egy műveletet, amely a régiót 2-vel osztja fel. A régiók állandó felosztásának elkerülése érdekében előre beállíthatja a régiók határait, és növelheti a maximális értéküket. méret.

Mivel egy régió adatai több HFile-ben is tárolhatók, a Hbase rendszeresen egyesíti őket a munka felgyorsítása érdekében. Ezt a műveletet tömörítésnek nevezik a Hbase-ben. A tömörítések két típusból állnak:

  • Kisebb tömörítés . Automatikusan indul, fut a háttérben. Más Hbase műveletekhez képest alacsony prioritású.
  • Jelentős tömörítés . Kézzel vagy bizonyos triggerek (például időzítő) hatására indul el. Magas prioritású, és jelentősen lelassíthatja a klasztert. A főbb tömörítéseket legjobb olyan időszakban végezni, amikor a fürt terhelése kicsi. A Major Compaction fizikailag is törli a korábban sírkővel megjelölt adatokat.

6.5 A HBase használatának módjai

HBase Shell

A Hbase használatának legegyszerűbb módja a hbase shell segédprogram használata. A hbase bármely hbase fürtcsomópontra történő telepítése után azonnal elérhető.

A Hbase shell egy jruby konzol, amely beépített támogatja az összes alapvető Hbase műveletet. A következő példa egy felhasználói tábla létrehozására két oszlopcsaláddal, néhány manipuláció elvégzésére, és a tábla eldobására a hbase shellben:

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'

Natív API

A legtöbb más, hadooppal kapcsolatos projekthez hasonlóan a hbase is Java nyelven van megvalósítva, így a natív api elérhető Java nyelven. A Native API elég jól dokumentált a hivatalos weboldalon. Íme egy példa a Hbase API használatára onnan vettük:

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

Takarékosság, REST és más programozási nyelvek támogatása

Más programozási nyelvek használatához a Hbase Thrift API-t és Rest API-t biztosít. Ezek alapján a kliensek minden nagyobb programozási nyelvre épülnek: python, PHP, Java Script stb.

6.6 A HBase alkalmazás néhány funkciója

  1. A Hbase azonnal integrálható a MapReduce-szal, és bemenetként és kimenetként használható a speciális TableInputFormat és TableOutputFormat segítségével.

  2. Nagyon fontos a megfelelő RowKey kiválasztása. A RowKey-nek jó egyenletes eloszlást kell biztosítania a régiók között, különben fennáll az úgynevezett "forró régiók" kockázata - olyan régiók, amelyeket sokkal gyakrabban használnak, mint mások, ami a rendszererőforrások nem hatékony felhasználásához vezet.

  3. Ha az adatokat nem külön-külön, hanem azonnal nagy kötegekben töltik fel, a Hbase egy speciális BulkLoad mechanizmust támogat, amely lehetővé teszi az adatok sokkal gyorsabb feltöltését, mint az egyszeri elhelyezések használata. A BulkLoad lényegében kétlépéses művelet:

    • HFile kialakítása putok részvétele nélkül egy speciális MapReduce job segítségével
    • A fájlok beszúrása közvetlenül a Hbase-be

  4. A Hbase támogatja metrikáinak a Ganglia megfigyelőkiszolgálóra történő kiadását. Ez nagyon hasznos lehet a Hbase adminisztrációja során, hogy a hbase-problémák mélyére jusson.

sor gomb

A RowKey a felhasználói azonosító, amely egy GUUID, egy speciálisan az egész világon egyedülálló karakterlánc. A GUUID-k egyenletesen vannak elosztva, ami jó adatelosztást biztosít a szerverek között.

Oszlopcsalád

Tárolónk két oszlopcsaládot használ:

  • adat. Ez az oszlopcsoport olyan adatokat tárol, amelyek már nem relevánsak hirdetési célokra, például azt, hogy a felhasználó felkeresett bizonyos URL-eket. Ennek az oszlopcsaládnak a TTL-je 2 hónapra van beállítva, a verziók számának korlátja 2000.
  • longdata. Ez az oszlopcsoport olyan adatokat tárol, amelyek idővel nem veszítik el relevanciájukat, például a nemet, a születési dátumot és más „örök” felhasználói jellemzőket.

hangszórók

A felhasználói tények minden típusa külön oszlopban tárolódik. Például a Data:_v oszlop a felhasználó által felkeresett URL-eket, a LongData:gender oszlop pedig a felhasználó nemét tárolja.

Ennek a ténynek az időbélyegzője időbélyegként kerül tárolásra. Például a Data:_v oszlopban az időbélyeg az az idő, amikor a felhasználó felkeresett egy adott URL-t.

Ez a felhasználói adattárolási struktúra nagyon jól illeszkedik használati mintánkhoz, és lehetővé teszi a felhasználói adatok gyors frissítését, a felhasználókról minden szükséges információ gyors megszerzését, valamint a MapReduce segítségével az összes felhasználó adatainak gyors feldolgozását egyszerre.

6.7 Alternatívák

A HBase kezelése és használata meglehetősen bonyolult, ezért a HBase használata előtt érdemes megvizsgálni az alternatívákat:

  • Relációs adatbázisok . Nagyon jó alternatíva, különösen abban az esetben, ha az adatok egy gépen elférnek. Szintén mindenekelőtt a relációs adatbázisokra kell gondolni abban az esetben, ha az elsődlegestől eltérő indexek tranzakciói fontosak.

  • Kulcsérték tárolása . Az olyan tárolók, mint a Redis és az Aerospike, jobban megfelelnek, ha késleltetésre van szükség, és a kötegelt feldolgozás kevésbé fontos.

  • Fájlok és feldolgozásuk a MapReduce segítségével . Ha az adatokat csak hozzáadjuk és ritkán frissítjük/módosítjuk, akkor jobb, ha nem használjuk a HBase-t, hanem egyszerűen fájlokban tároljuk az adatokat. A fájlokkal végzett munka egyszerűsítéséhez olyan eszközöket használhat, mint a Hive, Pig és Impala.

A HBase használata indokolt, ha:

  • Nagyon sok adat van, és nem férnek el egy számítógépen / szerveren
  • Az adatok gyakran frissülnek és törlődnek
  • Az adatokban van egy kifejezett „kulcs”, amelyhez kényelmes minden mást kötni
  • Kötegelt feldolgozásra van szükség
  • Véletlenszerű hozzáférésre van szüksége az adatokhoz meghatározott kulcsokkal
Java webinar