Hive bemutatója - Hive Architecture és a NASA esettanulmánya

Apache Hive oktatóanyag: Bevezetés

A Hive szigorúan az egész iparágban használt eszköz a Big Data Analytics számára, és remek eszköz a kezdethez val vel. Ebben a Hive oktató blogban az Apache Hive-ról fogunk mélyebben beszélgetni. Az Apache Hive egy adattárház eszköz a , amely SQL-szerű nyelvet biztosít a Big Data lekérdezéséhez és elemzéséhez. A Hive fejlesztésének motivációja az SQL fejlesztők és elemzők súrlódásmentes tanulási útja. A Hive nemcsak a nem programozási háttérrel rendelkező emberek megmentője, hanem csökkenti a programozók munkáját is, akik hosszú órákat töltenek a MapReduce programok megírásával. Ebben az Apache Hive bemutató blogban a következőkről fogok beszélni:

• Mi a Hive?
• Az Apache Hive története - A Facebook-tól az Apache-ig
• Az Apache Hive előnyei
• Apache Hive - NASA esettanulmány
• Apache kaptár építészet
• Metastore konfiguráció
• Hive adatmodell

Apache Hive bemutató: Mi a Hive?

Az Apache Hive egy Hadoop tetejére épített adattárház-rendszer, amelyet strukturált és félig strukturált adatok elemzésére használnak.A Hive a Hadoop MapReduce összetettségét vonja le. Alapvetően mechanizmust biztosít az adatok struktúrájának kivetítésére és HQL-ben (Hive Query Language) írt lekérdezések végrehajtására, amelyek hasonlóak az SQL-utasításokhoz. Belsőleg ezeket a lekérdezéseket vagy a HQL-t térképekké konvertálják, így a Hive fordítója csökkenti a munkákat. Ezért nem kell aggódnia, hogy összetett MapReduce programokat írjon az adatok feldolgozásához a Hadoop segítségével. Olyan felhasználóknak szól, akik jól érzik magukat az SQL-ben. Az Apache Hive támogatja az adatmeghatározási nyelvet (DDL), az adatkezelési nyelvet (DML) és a felhasználó által definiált funkciókat (UDF).

Hive oktatóanyag kezdőknek | A kaptár megértése mélységben Edureka

SQL + Hadoop MapReduce = HiveQL

Apache Hive oktatóanyag: A Hive története - a Facebook-tól az Apache-ig

Ábra : Hive Tutorial - Facebook használati eset

Kihívások a Facebook-on: Az adatok exponenciális növekedése

2008 előtt a Facebook összes adatfeldolgozási infrastruktúrája a kereskedelmi RDBMS-en alapuló adattárház köré épült. Ezek az infrastruktúrák eléggé képesek voltak kielégíteni a Facebook akkori igényeit. De mivel az adatok nagyon gyorsan növekedni kezdtek, hatalmas kihívássá vált ennek a hatalmas adatkészletnek a kezelése és feldolgozása. Egy Facebook-cikk szerint az adatok egy 2007-es 15 TB-os adattól a 2009-es 2 PB-adatig skálázódtak. Számos Facebook-termék magában foglalja az adatok elemzését, például a Közönség Insights, a Facebook Lexikon, a Facebook hirdetések stb. skálázható és gazdaságos megoldásra volt szüksége, hogy megbirkózzon ezzel a problémával, és ezért elkezdte használni a Hadoop keretrendszert.

Demokratizáló Hadoop - MapReduce

De az adatok növekedésével a Map-Reduce kódok bonyolultsága arányosan nőtt. Tehát a nem programozási háttérrel rendelkező emberek képzése MapReduce programok írására nehézzé vált. Az egyszerű elemzés elvégzéséhez száz sort kell írni a MapReduce kódból. Mivel az SQL-t mérnökök és elemzők, köztük a Facebook is széles körben használta, ezért az SQL felhelyezése a Hadoop tetejére logikus megoldásnak tűnt, hogy a Hadoop hozzáférhető legyen az SQL háttérrel rendelkező felhasználók számára.

Ezért az SQL azon képessége, hogy elegendő legyen az analitikai követelmények többségéhez, és Hadoop skálázhatósága Apache Hive amely lehetővé teszi SQL-lekérdezések végrehajtását a HDFS-ben található adatokon. Később a Hive projektet 2008 augusztusában nyitotta meg a Facebook, és ma szabadon elérhető Apache Hive néven.

Most nézzük meg a Hive jellemzőit vagy előnyeit, amelyek olyan népszerűvé teszik.

Apache Hive oktatóanyag: A Hive előnyei

• Hasznos azok számára, akik nem programozási háttérrel rendelkeznek, mivel így nincs szükség komplex MapReduce program írására.
• Kihúzható és méretezhető megbirkózni az adatok növekvő mennyiségével és változatosságával, anélkül, hogy befolyásolná a rendszer teljesítményét.
• Ez egy hatékony ETL (Extract, Transform, Load) eszköz.
• A Hive támogat minden Java, PHP, Python, C ++ vagy Ruby nyelven írt kliens alkalmazást azáltal, hogy kiteszi az alkalmazásokat Thrift szerver . (Ezeket az SQL-beágyazott ügyféloldali nyelveket használhatja az adatbázisok, például a DB2 stb. Eléréséhez.
• Mivel a Hive metaadat-információi RDBMS-ben vannak tárolva, ez jelentősen lerövidíti a szemantikus ellenőrzések végrehajtásának idejét a lekérdezés végrehajtása során.

Apache Hive bemutató: Hol használható az Apache Hive?

Az Apache Hive kihasználja mind a világ, azaz az SQL Database System és a keretrendszer. Ezért a vállalatok hatalmas sokasága használja. Leginkább adatraktározásra használják, ahol elemzéseket és adatbányászatokat végezhet, amelyek nem igényelnek valós idejű feldolgozást. Néhány olyan mező, ahol az Apache Hive alkalmazható, a következők:

• Adattárolás
• Ad-hoc elemzés

Mint mondják, nem tapsolhat csak egy kézzel, azaz nem oldhat meg minden problémát egyetlen eszközzel. Ezért összekapcsolhatja a Hive-ot más eszközökkel, hogy sok más területen is használhassa. Például a Tableau és az Apache Hive együtt használható adatmegjelenítésre, az Apache Tez integrálása a Hive-val valós idejű feldolgozási képességeket nyújt stb.
Ebben az Apache Hive bemutató blogban haladva tekintse át a NASA esettanulmányát, ahol megismerheti, hogyan oldotta meg Hive azt a problémát, amellyel a NASA tudósai szembesültek a klímamodellek értékelése során.

Kaptár oktatóanyag: NASA esettanulmány

Az éghajlati modell az éghajlati rendszerek matematikai ábrázolása, amely a Föld éghajlatát befolyásoló különféle tényezőkön alapul. Alapvetően az éghajlat különböző mozgatórugóinak, például az óceán, a nap, a légkör stb. Kölcsönhatását írja lebetekintést nyújt az éghajlati rendszer dinamikájába. Az éghajlati viszonyok vetítéséhez használják az éghajlatváltozásokat az éghajlatot befolyásoló tényezők alapján. A NASA sugárhajtómű laboratóriuma kifejlesztette a regionális klímamodell-kiértékelő rendszert (RCMES) az éghajlati kimeneti modell elemzéséhez és értékeléséhez a különféle külső tárolókban található távérzékelési adatokkal szemben.

Az RCMES (Regional Climate Model Evaluation System) két részből áll:

szolgáltatás már jegyrendszer-képzés

• RCMED (regionális klímamodell értékelési adatbázis):

Ez egy skálázható felhő adatbázis, amely az éghajlattal kapcsolatos távérzékelési adatokat és újranalízis adatokat tölti le olyan elszívók segítségével, mint az Apache OODT elszívók, az Apache Tika stb. Végül átalakítja az adatokat adatpont-modellként, amely a következő formátumú (szélességi , hosszúság, idő, érték, magasság) és tárolja a My SQL adatbázisban. Az ügyfél tér / idő lekérdezések végrehajtásával lekérheti az RCMED-ben lévő adatokat. Az ilyen lekérdezések leírása számunkra nem releváns.

• RCMET (regionális klímamodell-kiértékelő eszközkészlet):

Lehetővé teszi a felhasználó számára, hogy összehasonlítsa az RCMED-ben található referenciaadatokat a klímamodell kimeneti adataival, amelyek más forrásokból származnak, különféle elemzések és értékelések elvégzése céljából. Az RCMES architektúrájának megértéséhez hivatkozhat az alábbi képre.

Az RCMED referenciaadatai műholdas alapú távérzékelésből származnak, az éghajlati modell értékeléséhez szükséges különböző paraméterek szerint. Például - Az AIRS (légköri infravörös hangmérő) olyan paramétereket nyújt, mint a felszíni levegő hőmérséklete, hőmérséklete és geopotenciálja, a TRMM (trópusi csapadékmérési küldetés) havi csapadékmennyiséget stb.

A NASA által a MySQL adatbázis-rendszert használó problémák:

• Miután betöltötte a MySQL adatbázist 6 milliárd űrlappal (szélesség, hosszúság, idő, adatpontérték, magasság), a rendszer összeomlott, ahogy a fenti képen látható.
• Az egész tábla kisebb részhalmazokra történő felosztása után is hatalmas rezsit generált az adatok feldolgozása közben.

Szükségük volt egy skálázható megoldásra, amely képes tárolni és feldolgozni ezt a hatalmas mennyiségű adatot SQL-lel, például lekérdezési képességgel. Végül úgy döntöttek, hogy az Apache Hive-ot használják a fentebb említett problémák leküzdésére.

Hogyan képes az Apache Hive megoldani a problémát?

Most nézzük meg, melyek azok a funkciók, amelyek meggyőzték a NASA JPL csapatát arról, hogy az Apache Hive-ot beépítse megoldási stratégiájába:

• Mivel az Apache Hive a Hadoop tetején fut, skálázható és elosztott és párhuzamos módon képes feldolgozni az adatokat.
• Ez biztosítja a Hive Query nyelvet, amely hasonló az SQL-hez, és így könnyen megtanulható.

A kaptár telepítése:

A következő kép elmagyarázza az RCMES Architektust az Apache Hive integrációjával:

Ábra : Hive bemutatója - RCMES architektúra az Apache Hive-tal

A fenti kép az apache hive telepítését mutatja be az RCMES-ben. A NASA csapata az Apache Hive telepítése közben a következő lépéseket tette:

• Telepítették a Hive-ot a Cloudera és az Apache Hadoop segítségével a fenti képen látható módon.
• Apache Sqoop-ot használtak a MySQL adatbázisból a Hive-be történő adatok felvételére.
• Az Apache OODT csomagolót úgy hajtották végre, hogy lekérdezéseket hajtson végre a Hive-on, és visszakérje az adatokat az RCMET-be.

Kezdeti összehasonlító megfigyelések a kaptárral:

• Kezdetben 2,5 milliárd adatpontot töltöttek be egyetlen táblába, és számlálási lekérdezést hajtottak végre. Például, Hive> válassza a count (datapoint_id) elemet a dataPointból. Az összes rekord megszámlálása 5-6 percet vett igénybe (15–17 perc a teljes 6,8 milliárd rekordhoz).
• A redukciós fázis gyors volt, de a térképi fázis a teljes feldolgozási idő 95% -át vette igénybe. Hatot használtak ( 4x négymagos ) rendszerek 24 GB RAM (kb.) az egyes rendszerekben.
• Még több gép hozzáadása után is megváltoztatta a HDFS blokkméretet (64 MB, 128 MB, 256 MB) és sok más konfigurációs változót (io.fajta.tényező, azaz.fajta.mb), nem értek el sok sikert a számolás befejezéséhez szükséges idő csökkentésében.

A Hive közösség tagjainak adatai:

Végül a Hive közösség tagjai megmentették és különféle felismeréseket nyújtottak a problémák megoldására a Hive jelenlegi megvalósításával:

• Megemlítették, hogy a HDFS olvasási sebessége kb 60 MB / s összehasonlítva 1 GB / s helyi lemez esetén a hálózati kapacitástól és a NameNode munkaterhelésétől függően.
• A tagok ezt javasolták 16 leképező a jelenlegi rendszerükben megkövetelik, hogy megfeleljen a helyi, nem Hadoop feladat I / O teljesítményének.
• Javasolták továbbá a osztott méretű minden térképező számára a szám növelésenak,-nektérképeket, és ezért több párhuzamosságot biztosít.
• Végül a közösség tagjai azt mondták nekik felhasználás száma (1) ahelyett, hogy hivatkoznánk számol ( datapoint_id) . Ennek oka, hogy az (1) számolás esetén nincs referencia oszlop, ezért a számlálás végrehajtása során nem történik dekompresszió és deserializáció.

Végül a NASA a Hive közösség tagjai által adott összes javaslat figyelembevételével hangolhatja el Hive klaszterét elvárásaiknak megfelelően. Ezért a sorok milliárdjait mindössze 15 másodperc alatt tudták lekérdezni a fent említett rendszerkonfigurációk segítségével.

Apache Hive oktatóanyag: Hive architektúra és alkatrészei

Az alábbi kép leírja a kaptár felépítését és azt a folyamatot, amelyben a lekérdezés beküldikKaptárés végül a MapReduce keretrendszer segítségével dolgozták fel:

Ábra : Hive bemutatója - Hive Architecture

Amint a fenti képen látható, a Hive Architecture a következő összetevőkbe sorolható:

• Hive kliensek: A Hive számos nyelven írt alkalmazást támogat, például Java, C ++, Python stb., JDBC, Thrift és ODBC illesztőprogramokkal. Ezért mindig írhat kaptár kliens alkalmazást az általuk választott nyelven írva.
• Hive Services: Az Apache Hive különféle szolgáltatásokat nyújt, például CLI-t, webes felületet stb. Rövidesen mindegyiket felfedezzük ebben a Hive oktató blogban.
• Feldolgozási keretrendszer és erőforrás-kezelés: Belsőleg,A Hive a Hadoop MapReduce keretrendszert használja tényleges motorként a lekérdezések végrehajtásához. önmagában külön téma, ezért itt nem tárgyaljuk.
• Elosztott tárhely: Mivel a Hive telepítve van a Hadoop tetejére, az alapul szolgáló HDFS-t használja az elosztott tároláshoz. Hivatkozhat a HDFS blog hogy többet megtudjon róla.

Most pedig fedezzük fel a Hive Architecture első két fő elemét:

1. Hive kliensek:

Az Apache Hive különféle típusú ügyfélalkalmazásokat támogat lekérdezések végrehajtására a Hive-on. Ezek az ügyfelek három típusba sorolhatók:

• Takarékos ügyfelek: Mivel a Hive szerver Apache Thrift alapú, kiszolgálja a kérést mindazoktól a programozási nyelvektől, amelyek támogatják a Thrift programot.
• JDBC kliensek: A Hive lehetővé teszi a Java alkalmazások számára, hogy csatlakozzanak hozzá a JDBC illesztőprogram segítségével, amelyet az osztály osztály határoz meg.apache.hadoop.kaptár.jdbc.HiveDriver.
• ODBC kliensek: A Hive ODBC illesztőprogram lehetővé teszi, hogy az ODBC protokollt támogató alkalmazások csatlakozzanak a Hive-hoz. (A JDBC illesztőprogramhoz hasonlóan az ODBC illesztőprogram is a Thrift segítségével kommunikál a Hive szerverrel.)

2. Kaptárszolgáltatások:

A Hive számos szolgáltatást nyújt, amint az a fenti képen látható. Vessünk egy pillantást mindegyikre:

• Hive CLI (parancssori interfész): Ez a Hive által biztosított alapértelmezett héj, ahol közvetlenül végrehajthatja a Hive-lekérdezéseket és -parancsokat.
• Apache Hive webes interfészek: A parancssori felületen kívül a Hive webalapú grafikus felhasználói felületet is biztosít a Hive-lekérdezések és -parancsok végrehajtásához.
• Hive szerver: A Hive kiszolgáló az Apache Thriftre épül, ezért Thrift Server néven is emlegetik, amely lehetővé teszi a különböző ügyfelek számára, hogy kéréseket nyújtsanak be a Hive-hez, és lekérjék a végeredményt.
• Apache Hive illesztőprogram: Feladata az ügyfél által a CLI-n, a webes felhasználói felületen, a Thrift, az ODBC vagy a JDBC interfészeken keresztül benyújtott lekérdezések fogadása. Ezután az illesztőprogram továbbítja a lekérdezést a fordítónak, ahol az elemzés, a típusellenőrzés és a szemantikai elemzés történik a metastore-ban található séma segítségével. A következő lépésben egy optimalizált logikai tervet készítenek a térképcsökkentő feladatok és a HDFS feladatok DAG (Directed Acyclic Graph) formájában. Végül a végrehajtó motor ezeket a feladatokat a függőségük sorrendjében hajtja végre, a Hadoop segítségével.
• Metastore: Gondolhat metastoreközponti tárhelyként a Hive összes metaadat-információjának tárolásához. A kaptár metaadatai különféle típusú információkat tartalmaznak, például a táblák és a partíciók felépítéséta HDFS-ben található adatok olvasási / írási műveletéhez szükséges oszlop, oszloptípus, sorosító és deserializátor mellett. A metastorekét alapvető egységből áll:
  • Metastore szolgáltatást nyújtó szolgáltatáshozzáférés egyebekhezrKaptárszolgáltatások.
  • A metaadatok tárolása a HDFS-tárolástól elkülönítve.

Most pedig értsük meg a Hive metastore különböző megvalósítási módjaita Hive Tutorial következő szakaszában.

Apache Hive oktatóanyag: Metastore konfiguráció

A Metastore tárolja a metaadatokat az RDBMS és a Data Nucleus nevű nyílt forráskódú ORM (Object Relational Model) réteg segítségével, amely átalakítja az objektumábrázolást relációs sémává és fordítva. Az oka annak, hogy a HDFS helyett az RDBMS-t választja, az alacsony késés elérése. A metastore-t a következő három konfigurációban tudjuk megvalósítani:

1. Beágyazott metastore:

A metastore szolgáltatás és a Hive szolgáltatás alapértelmezés szerint ugyanabban a JVM-ben fut, beágyazott Derby Database példány használatával, ahol a metaadatokat a helyi lemezen tárolják. Ezt hívják beágyazott metastore konfigurációnak. Ebben az esetben egyszerre csak egy felhasználó csatlakozhat a metastore adatbázishoz. Ha elindítja a Hive illesztőprogram második példányát, hibaüzenetet kap. Ez jó az egység teszteléséhez, de nem a gyakorlati megoldásokhoz.

2. Helyi metasztár:

Ez a konfiguráció lehetővé teszi számunkra, hogy több Hive munkamenetet folytassunk, azaz több felhasználó is használhatja a metastore adatbázist egyszerre. Ezt bármely olyan JDBC-kompatibilis adatbázis használatával érhetjük el, mint a MySQL, amely külön JVM-ben vagy egy másik gépben fut, mint a Hive szolgáltatás és metastore szolgáltatásé, amelyek ugyanabban a JVM-ben futnak, mint fent. Általánosságban a legnépszerűbb választás egy MySQL szerver megvalósítása metastore adatbázisként.

3. Távoli metastore:

A távoli metastore konfigurációban a metastore szolgáltatás a saját külön JVM-jén fut, és nem a Hive szolgáltatás JVM-jén. Más folyamatok Thrift Network API-k segítségével kommunikálnak a metastore szerverrel. Ebben az esetben egy vagy több metastore-kiszolgálóval rendelkezhet, hogy nagyobb rendelkezésre állást biztosítson.A távoli metastore használatának fő előnye, hogy a metastore adatbázis eléréséhez nem kell megosztania a JDBC bejelentkezési adatokat minden Hive-felhasználóval.

Apache Hive oktatóanyag: Adatmodell

A kaptárban lévő adatok granulált szinten három típusba sorolhatók:

• asztal
• Partíció
• Vödör

Táblázatok:

A Hive-ben található táblázatok megegyeznek a Relációs adatbázisban található táblákkal. Szűrési, kivetítési, csatlakozási és egyesítési műveleteket hajthat végre rajtuk. Kétféle táblázat van a Hive-ban:

1. Kezelt táblázat:

Parancs:

CREATE TABLE (1. oszlop adattípus, 2. oszlop adattípus)

TÖLTSE BE AZ ADATOK BEÁLLÍTÁSÁT a táblába kezelt_tábla

Ahogy a neve is sugallja (felügyelt tábla), a Hive felelős a kezelt tábla adatainak kezeléséért. Más szavakkal, a „Hive kezeli az adatokat” kifejezéssel azt értem, hogy ha a HDFS-ben található fájlból az adatokat egy Hive-be tölti be Kezelt táblázat és adjon ki rajta egy DROP parancsot, a tábla és annak metaadatai törlődnek. Tehát, az adatok tartoznak a kiesett kezelt_táblázat már nem létezik sehol a HDFS-ben, és semmiképpen sem tudja letölteni. Alapvetően az adatokat áthelyezi, amikor a LOAD parancsot kiadja a HDFS fájl helyéről a Hive raktár könyvtárába.

Jegyzet: A raktárkönyvtár alapértelmezett elérési útja a / user / hive / storage. A Hive tábla adatai a raktár_könyvtárban találhatók / tábla_neve (HDFS). A raktárkönyvtár elérési útját megadhatja a hive.metastore.warehouse.dir konfigurációs paraméterben is, amely a hive-site.xml fájlban található.

2. Külső táblázat:

Parancs:

hogyan állítsuk be az osztályt Java-ban

KÜLSŐ TÁBLÁZAT LÉTREHOZÁSA (1. oszlop adattípus, 2. oszlop adattípus) HELY ”

TÖLTSE ADATOK BEMENETÉT ’’ A TÁBLÁZATBA

Mert külső asztal , A Hive nem felelős az adatok kezeléséért. Ebben az esetben a LOAD parancs kiadásakor a Hive áthelyezi az adatokat a raktár könyvtárába. Ezután a Hive létrehozza a metaadat-információkat a külső táblához. Most, ha kiad egy DROP parancsot a külső asztal , csak a külső táblára vonatkozó metaadatok törlődnek. Ezért továbbra is visszakeresheti az adott külső tábla adatait a raktárkönyvtárból a HDFS parancsok használatával.

Partíciók:

Parancs:

CREATE TABLE táblanév (oszlop1 adattípus, oszlop2 adattípus) PARTITIONED BY (partíció1 adattípus, partíció2 adattípus és hellip.)

A Hive a táblákat partíciókba rendezi, hogy a hasonló típusú adatokat egy oszlop vagy partíciókulcs alapján csoportosítsa. Minden táblának lehet egy vagy több partíciókulcsa egy adott partíció azonosításához. Ez lehetővé teszi számunkra, hogy gyorsabban lekérdezzük az adatok szeleteit.

Jegyzet: Ne feledje, hogy a partíciók létrehozása során elkövetett leggyakoribb hiba az, ha egy meglévő oszlopnevet ad meg partíciós oszlopként. Ennek során hibaüzenetet kap - „Hiba a szemantikai elemzésben: Oszlop ismétlődik a particionáló oszlopokban”.

Értsük meg a partíciót egy példával, ahol van egy táblám: student_details, amely néhány mérnöki főiskola hallgatói adatait tartalmazza, például student_id, név, tanszék, év stb. egy adott részleghez tartozók együtt lesznek tárolva ebben a partícióban. Fizikailag a partíció nem más, mint egy alkönyvtár a táblázat könyvtárában.

Tegyük fel, hogy a hallgatói részletek táblázatban három tanszékről van adatunk - CSE, ECE és Civil. Ezért összesen három partíciónk lesz az egyes részlegekhez, amint az az alábbi képen látható. És minden részlegre vonatkozóan megkapjuk az összes adatot az adott részlegről, amely egy külön alkönyvtárban található a Hive tábla könyvtárában. Például az egyéni keresőmotorral foglalkozó részlegekre vonatkozó összes hallgatói adatot a user / hive / storage / student_details / dept. = CSE tárolja. Tehát a CSE-hallgatókkal kapcsolatos kérdéseknek csak a CSE-partícióban lévő adatokat kell átnézniük. Ez nagyon hasznosgá teszi a particionálást, mivel csak a beolvasással csökkenti a lekérdezés késését ide vonatkozó particionált adatok a teljes adatsor helyett. Valójában a valós megvalósításokban több száz TB adattal fog foglalkozni. Tehát képzelje el, hogy ezt a hatalmas mennyiségű adatot beolvassa valamilyen lekérdezés céljából 95% az Ön által beolvasott adatok nem voltak relevánsak a lekérdezés szempontjából.

Azt javaslom, hogy nézze át a blogot Hive parancsok ahol a partíciók megvalósításának különböző módjait találja meg egy példával.

Vödrök:

Parancsok:

TABLE létrehozása tábla_név PARTITIONED BY (partíció1 adattípus, partíció2 adattípus és & hellip.) CLUSTERED BY (oszlopnév1, oszlopnév2,…) RENDEZÉS (oszlop_név [ASC | DESC], ...)] SZÁMKOSÁROKBAN

Most feloszthatja az egyes partíciókat vagy a fel nem osztott táblákat vödrökre a táblázat oszlopának hash függvénye alapján. Valójában minden csoport csak egy fájl a partíciós könyvtárban vagy a táblázat könyvtárában (fel nem osztott tábla). Ezért, ha úgy döntött, hogy n partícióra osztja a partíciókat, akkor mindegyik partíciós könyvtárban lesz n fájl. Például láthatja a fenti képet, ahol az egyes partíciókat 2 vödörbe soroltuk. Tehát mindegyik partíciónak, mondjuk a CSE-nek, két fájlja lesz, ahol mindegyik tárolja a CSE hallgató adatait.

Hogyan osztja Hive a sorokat vödrökbe?

Nos, a Hive a következő képlet segítségével határozza meg a sor sorszámát: hash_function (ömlesztett_oszlop) modulo (vödrök száma) . Itt van, hAz ash_function az oszlop adattípusától függ. Például, ha a táblázatot valamilyen oszlop (mondjuk felhasználói_azonosító) alapján gyűjtjük össze az INT adattípussal, akkor a hash_ function lesz - hash_function (user_id ) = user_id egész értéke . Tegyük fel, hogy létrehozott két vödröt, majd a Hive kiszámítja az egyes partíciók 1-es vödrébe kerülő sorokat:user_id) modulo (2) értéke. Ezért ebben az esetben a páros egész számjegyű végződésű felhasználói_azonosítójú sorok ugyanabban a vödörben helyezkednek el, mint az egyes partíciók. A hash_function más adattípusok esetében kissé bonyolult a számításhoz, sőt, egy karakterlánc esetében még emberileg sem ismerhető fel.

Jegyzet: Ha Apache Hive 0.x vagy 1.x verziót használ, akkor a gyűjtés végrehajtása előtt ki kell adnia a parancsot - állítsa be a hive.enforce.bucketing = true parancsot a Hive terminálról. Ez lehetővé teszi, hogy a megfelelő számú reduktor legyen, miközben a fürtön keresztül záradékot használ egy oszlop gyűjtéséhez. Abban az esetben, ha még nem tette meg, előfordulhat, hogy a táblázatok könyvtárában létrehozott fájlok száma nem egyenlő a vödrök számával. Alternatív megoldásként beállíthatja a reduktor számát, amely megegyezik a vödrök számával, a set mapred.reduce.task = num_bucket használatával.

Miért van szükség vödrökre?

Két fő oka van a partíciós csoportosításának:

• NAK NEK térképoldali csatlakozás megköveteli, hogy az egyedi csatlakozási kulcshoz tartozó adatok ugyanabban a partícióban legyenek. De mi van azokkal az esetekkel, amikor a partíció kulcsa eltér a csatlakozástól? Ezért ezekben az esetekben elvégezheti a térképoldali csatlakozást úgy, hogy a táblát a csatlakozási kulcs segítségével csoportosítja.
• A csoportosítás hatékonyabbá teszi a mintavételi folyamatot, és ezáltal lehetővé teszi számunkra a lekérdezési idő csökkentését.

Itt szeretném befejezni ezt a Hive bemutató blogot. Biztos vagyok benne, hogy miután átnéztem ezt a Hive oktató blogot, rájöttél volna az Apache Hive egyszerűségére. Azóta srácok megtanultátok a kaptár összes alapját, itt az ideje, hogy kézhez vegyen egy tapasztalatot az Apache Hive-ról. Tehát nézze meg a Hive Tutorial blogsorozat következő blogját, amely a Hive telepítéséről szól, és kezdje el az Apache Hive fejlesztését.

Most, hogy megértette az Apache Hive-ot és annak szolgáltatásait, nézze meg a az Edureka, egy megbízható online tanulási vállalat, amelynek több mint 250 000 elégedett tanulóval rendelkező hálózata elterjedt az egész világon. Az Edureka Big Data Hadoop tanúsító tanfolyam segít a tanulóknak a HDFS, a fonal, a MapReduce, a Pig, a Hive, a HBase, az Oozie, a Flume és a Sqoop szakértőivé válni, valós idejű felhasználási esetek felhasználásával a kiskereskedelem, a szociális média, a repülés, az idegenforgalom és a pénzügy területén.

Van egy kérdésünk? Kérjük, említse meg a megjegyzések részben, és kapcsolatba lépünk Önnel.