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.
![](https://cdn.codegym.cc/images/article/54d64a29-4642-4c59-8211-2b143dfcd48a/512.jpeg)
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.
![](https://cdn.codegym.cc/images/article/38a31201-f909-4a45-9792-a5d72225f060/512.jpeg)
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.
![](https://cdn.codegym.cc/images/article/5bae086c-b213-47db-be33-a23d854a1543/1024.jpeg)
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ő.![](https://cdn.codegym.cc/images/article/d13e20e1-fed9-444a-929c-15ab43d8209b/800.jpeg)
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
-
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.
-
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.
-
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
-
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
GO TO FULL VERSION