Kaptár válaszfalak és vödrök példával

A táblák, partíciók és vödrök a Hive adatmodellezésének részei. Egy tábla határozza meg a sémát, egy partíció a táblát a lemezen található könyvtárakra osztja, és egy vödrök a könyvtárban lévő adatokat rögzített számú fájlra osztják.

Mi az a partíciók?

A Hive partíciók egy módja a táblák partíciókba rendezésének a partíciós kulcsok alapján különböző részekre osztásával. Fizikailag minden partíció egy külön alkönyvtár a HDFS táblamappája alatt, ami lehetővé teszi a Hive számára, hogy kihagyja a nem szükséges adatokat.

A partíció akkor hasznos, ha a tábla egy vagy több partíciós kulccsal rendelkezik. A partíciós kulcsok alapvető elemek annak meghatározására, hogy hogyan tárolódnak az adatok a táblában. A partíciós kulcs nem magukban az adatfájlokban tárolódik – az értéke a könyvtár nevében van kódolva, így egy erre a kulcsra szűrt lekérdezés teljes könyvtárakat dobhat el, mielőtt bármelyik sor beolvasásra kerülne. Ezt partíciótisztításnak nevezik.

Például: –

„Az ügyfél rendelkezik néhány e-kereskedelmi adattal, amelyek indiai műveletekhez tartoznak, ahol minden állam (38 állam) műveletet egészében említenek. Ha az állapot oszlopot vesszük partíciós kulcsként, és particionálást végzünk az indiai adatok egészén, akkor megkaphatjuk a partíciók számát (38 partíció), ami megegyezik az Indiában jelen lévő államok számával (38). Így minden államadat külön megtekinthető a partíciós táblázatokban.”

Minta Code Kódrészlet a partíciókhoz

Az alábbi hat utasítás sorrendben fut a Hive shellben. Mindegyik egy különálló lépés, és az azt követő képernyőképek ugyanazt a sorozatot mutatják egy élő fürtön végrehajtva.

1. Az allstates tábla létrehozása

   create table allstates(state string, District string,Enrolments string)
   
   row format delimited
   
   fields terminated by ',';
   

2. Adatok betöltése a létrehozott allstates táblába

   Load data local inpath '/home/hduser/Desktop/AllStates.csv' into table allstates;

3. Partíciós tábla létrehozása

   create table state_part(District string,Enrolments string) PARTITIONED BY(state string);

4. A partícióhoz be kell állítanunk ezt a tulajdonságot

   set hive.exec.dynamic.partition.mode=nonstrict

5. Adatok betöltése partíciós táblába

   INSERT OVERWRITE TABLE state_part PARTITION(state)
   SELECT district,enrolments,state from  allstates;

6. A partíciós táblák tényleges feldolgozása és kialakítása partíciós kulcsként állapot alapján

A HDFS tárolóban 38 partíciós kimenet lesz, a fájlnévvel mint állapotnévvel. Ezt fogjuk ellenőrizni ebben a lépésben.

A következő képernyőképek a fent említett kód végrehajtását mutatják be.

Az első képernyőn az 1. lépés a következő helyen fut: kaptár> felszólít és létrehozza a minden állam tábla három oszloppal és vesszővel a mezőelválasztóként.

A következő képernyő a 2. és 3. lépést mutatja be: az AllStates.csv fájl betöltődik a minden állam, és a particionált tábla állam_része létrejön, a partíciós kulcsként deklarált állapottal.

Ezután a 4. és 5. lépés jelenik meg. A dinamikus partíciós mód nem szigorú értékre van állítva, és az INSERT OVERWRITE utasítás elindít egy MapReduce feladatot, amelynek naplósorai minden egyes állapotértékhez egy partíció betöltését mutatják.

A HDFS-ben a raktárkönyvtár listázása megerősíti a 6. lépés eredményét – a shell 38 elemet jelent, egyet állapot_rész/állapot= könyvtár államonként.

A fenti kódból a következőket tesszük

1. Az allstates tábla létrehozása 3 oszlopnévvel, például állam, kerület és beiratkozások
2. Adatok betöltése az allstates táblába
3. Partíciós tábla létrehozása partíciókulcsként állapottal
4. Ebben a lépésben a partíciós módot nem szigorúra kell állítani (ez a mód aktiválja a dinamikus partíciós módot)
5. Adatok betöltése a state_part partíciós táblába
6. A partíciós táblák tényleges feldolgozása és kialakítása partíciós kulcsként állapot alapján
7. A HDFS tárolóban 38 partíciós kimenet lesz, ahol az állapotnév a fájlnév lesz. Ebben a lépésben a 38 partíciós kimenetet látjuk a HDFS-ben.

Statikus vs. dinamikus particionálás a Hive-ban

A fenti kidolgozott példa dinamikus particionálást használ, de a Hive két betöltési stílust támogat, és a különbség határozza meg, hogy mennyi typing – és hogy mekkora kockázatot hordoz – minden egyes rakomány.

Statikus particionálás magában az utasításban nevezi meg a partíció értékét, tehát az értéket ismerni kell a betöltés futtatása előtt, és egy utasítás pontosan egy partíciót tölt ki. Dinamikus particionálás lehetővé teszi a Hive számára, hogy a SELECT lista utolsó oszlopából olvassa ki a partíció értékét, és futásidőben hozza létre a könyvtárakat, ezért a példának csak egyetlen INSERT utasításra van szüksége 38 könyvtár létrehozásához.

Aspect	Statikus particionálás	Dinamikus particionálás
Partícióérték	Kézzel szállítva a PARTITION záradékban	Futásidőben beolvas a SELECT oszlopból
Partíciók utasításonként	egy	Sok
Configuration	Az alapértelmezett szigorú módban működik	A hive.exec.dynamic.partition.mode fájlt nem szigorú értékre kell állítani.
Terhelési sebesség	Gyorsabb, mert nincs szükség értékszkennelésre	Lassabb, mert a feladat kulcsok szerint csoportosítja a sorokat
A legalkalmasabb	Kis, ismert készletek, például napi adag	Nagy vagy ismeretlen kulcskészletek, például 38 állapot

A dinamikus betöltések is korlátozottak. A Hive korlátozza, hogy hány partíciót hozhat létre egy feladat – alapértelmezés szerint 100 leképezőnként vagy reduktoronként és 1000 a teljes utasításra vonatkozóan –, és a feladat meghiúsul, ha bármelyik határértéket átlépik, így egy nagyon magas kardinalitású kulcshoz ezeket a korlátokat meg kell emelni, vagy más kialakításra van szükség.

Mi az a Buckets?

A Hive-ban a vödrök a Hive táblaadatok több fájlba vagy könyvtárba történő szétválasztására szolgálnak. Hatékony lekérdezésre szolgálnak, és a partíciókkal ellentétben a vödrök száma a tábla létrehozásakor rögzített, így soha nem növekszik az adatokkal.

• Az ezekben a partíciókban található adatok tovább oszthatók vödrökre
• A felosztást a táblázatban kiválasztott oszlopok hash-e alapján végezzük.
• A vödrök valamilyen hashelési algoritmust használnak a háttérben az egyes rekordok beolvasásához és a vödrökbe helyezéséhez.
• Egy sor melyik vödörbe érkezzen, attól függ, hogy hash_function(vödröző_oszlop) mod vödrök_száma, így az azonos értékek mindig ugyanabba a fájlba kerülnek
• A Hive 0.x és 1.x verzióin a bucketinget engedélyezni kellett a következővel: set hive.enforce.bucketing=true; a beillesztés előtt

Ez az utolsó beállítás az aktuális klaszter előzményei: az Apache Hive kézikönyve megjegyzi, hogy a Hive 2.x verziójától kezdve nincs rá szükség, mivel a motor mostantól automatikusan kiválasztja a tábla definíciójából a redukálók számát és a fürtök szerinti oszlopot.

Step 1) Vödör létrehozása az alábbiak szerint.

Az alábbi képernyő a CREATE TABLE utasítást mutatja a következőhöz: mintavödör, ahol az alsó CLUSTERED BY záradék rögzíti a vödrök számát.

A fenti képernyőképből

• Samplebucket-et hozunk létre olyan oszlopnevekkel, mint a first_name, job_id, department, salary és country
• Négy vödröt készítünk itt.
• Miután az adatok betöltődtek, automatikusan 4 tárolóba helyezi azokat.
• Az ország oszlop a klaszterezési oszlop, tehát egy ország minden sora ugyanabba a tárolófájlba kerül.

Step 2) Adatok betöltése a samplebucket táblába

Feltételezve, hogy az „employees” tábla már létre van hozva a Hive rendszerben, ebben a lépésben az adatok betöltését fogjuk látni az employees táblából a samplebucket táblába.

Mielőtt elkezdenénk az alkalmazottak adatait vödrökbe helyezni, győződjünk meg arról, hogy azok oszlopneveket tartalmaznak, például keresztnév, munkaköri azonosító, részleg, fizetés és ország.

Itt töltünk adatokat a samplebucket mappába az employees táblából – az alábbi képernyőkép az INSERT OVERWRITE utasítást mutatja, amely a másolást végzi.

Step 3) Az 1. lépésben létrehozott 4 vödör megjelenítése

A HDFS táblakönyvtárának listázása a fizikai eredményt mutatja: négy számozott adatfájl egy helyett.

A fenti képernyőképen láthatjuk, hogy az alkalmazottak táblájából származó adatok átkerülnek az 1. lépésben létrehozott 4 vödörbe.

Kaptár particionálás vs. vödrözés: Főbb különbségek

Mindkét funkció kisebb darabokra vágja a táblázatot, de ezt a fájlrendszer különböző szintjein teszik, és különböző problémákra adnak választ. Az alábbi táblázat egymás mellé helyezi őket.

Összehasonlítási pont	Particionálás	Vödrösítés
Egység létrehozva	Egy könyvtár kulcsértékenként	Egy fájl hashvödörönként
Kijelentve a következővel:	PARTÍCIÓK SZERINT	… n VÖDÖRBE CSOPORTOSÍTVA
Darabszám	A különböző értékek számával növekszik	Javítva a tábla létrehozásakor
Adatfájlokban tárolt oszlop	Nem – az érték a könyvtár nevében található	Igen – az oszlop normál oszlop marad
Legjobb oszloptípus	Alacsony kardinalitás, például állam, év vagy ország	Magas kardinalitás, például user_id vagy transaction_id
Fő előny	A partíciók metszése kihagyja a felesleges könyvtárakat	Egyenletes fájlméretek, olcsó mintavételezés és térképoldali illesztések

A kettő nem rivális. Egy gyakori éles elrendezés dátum szerint particionálja a ténytáblát, majd a join kulcs alapján naponta csoportosítja a tárolókat, így a lekérdezés egyetlen könyvtárra metszi a tárolókat, majd azon belül csoportosítja a tárolókat.

Mikor használjunk particionálást, vödrözést vagy mindkettőt?

A választás az oszlop kardinalitásával és a táblázatot olvasó lekérdezések alakjával kezdődik.

• Feloszt amikor a lekérdezések szinte mindig ugyanazon az alacsony számosságú oszlopon szűrnek, és amikor a különböző értékek száma több százban, nem pedig milliókban marad
• Vödör amikor a hasznos oszlop túl sok különböző értékkel rendelkezik ahhoz, hogy könyvtár legyen, vagy amikor a táblát ismételten összekapcsolják vagy mintavételezik az adott oszlop alapján
• Használja mindkettőt nagyméretű ténytáblák esetén: particionálás dátum szerint, majd gyűjtőként bontás minden partíción belül a csatlakozási kulcs szerint

A figyelendő hibamód a kis fájlok problémája. Egy nagyon magas kardinalitású oszlop – időbélyeg vagy ügyfél-azonosító – alapján történő particionálás több ezer apró könyvtárat hoz létre, amelyek mindegyike egy, a HDFS blokkméretnél jóval kisebb fájlt tartalmaz. Ez felfújja a NameNode memóriáját, és minden vizsgálatot lelassít, ami pontosan az eredmény particionálásának célja volt. A bucketelés ezt elkerüli, mert a fájlok számát a tábladefiníció korlátozza.

A tárolókba rendezésnek (bucketing) megvan a maga fenntartása: az elrendezés csak akkor helyes, ha minden író tiszteletben tartja azt. A létrehozáskor deklarált tárolók száma metaadat, így egy olyan feladat, amely helyes fürtözés nélkül ír a táblába, olyan fájlokat hagyhat maga után, amelyek nem felelnek meg a deklarált elrendezésnek, és a későbbi mintavételezés vagy tárolócsatlakozások rossz sorokat fognak olvasni.

GYIK