Tutorial de rusc: estudi de casos de l'arquitectura de rusc i la NASA



Aquest bloc d'aprenentatge Hive us proporciona un coneixement profund de l'arquitectura i el model de dades de Hive. També explica l’estudi de casos de la NASA sobre Apache Hive.

Tutorial Apache Hive: Introducció

Hive és una eina rigorosament utilitzada a tota la indústria per a Big Data Analytics i una eina fantàstica per iniciar el vostre amb. En aquest bloc de tutorial Hive, parlarem en profunditat sobre Apache Hive. Apache Hive és una eina d 'emmagatzematge de dades a , que proporciona llenguatge SQL com a consulta i anàlisi de Big Data. La motivació del desenvolupament d’Hive és el camí d’aprenentatge sense friccions per als desenvolupadors i analistes de SQL. Hive no només és un salvador per a persones que no provenen de programació, sinó que també redueix la feina dels programadors que passen llargues hores escrivint programes MapReduce. En aquest bloc Tutorial Apache Hive, parlaré de:





Tutorial Apache Hive: què és Hive?

Apache Hive és un sistema de magatzem de dades construït sobre Hadoop i que s’utilitza per analitzar dades estructurades i semiestructurades.Hive resumeix la complexitat de Hadoop MapReduce. Bàsicament, proporciona un mecanisme per projectar l'estructura a les dades i realitzar consultes escrites en HQL (Hive Query Language) que són similars a les sentències SQL. Internament, aquestes consultes o HQL es converteixen en mapes per reduir feines pel compilador Hive. Per tant, no us haureu de preocupar d’escriure programes complexos de MapReduce per processar les vostres dades mitjançant Hadoop. Està dirigit a usuaris que estiguin còmodes amb SQL. Apache Hive admet el llenguatge de definició de dades (DDL), el llenguatge de manipulació de dades (DML) i les funcions definides per l'usuari (UDF).

Tutorial de rusc per a principiants | Comprendre el rusc en profunditat Edureka



SQL + Hadoop MapReduce = HiveQL

Tutorial Apache Hive: Story of Hive: de Facebook a Apache

Facebook Utilitza Casi - Hive Tutorial - EdurekaFig : Tutorial Hive: cas d'ús de Facebook

Reptes a Facebook: creixement exponencial de les dades

Abans del 2008, tota la infraestructura de processament de dades de Facebook es construïa al voltant d’un magatzem de dades basat en RDBMS comercial. Aquestes infraestructures eren prou capaces de satisfer les necessitats de Facebook en aquell moment. Però, a mesura que les dades van començar a créixer molt ràpidament, es va convertir en un repte enorme gestionar i processar aquest enorme conjunt de dades. Segons un article de Facebook, les dades es van passar d’un conjunt de dades de 15 TB el 2007 a dades de 2 PB el 2009. A més, molts productes de Facebook impliquen anàlisis de dades com Audience Insights, Facebook Lexicon, Facebook Ads, etc. necessitava una solució econòmica i escalable per fer front a aquest problema i, per tant, va començar a utilitzar el marc Hadoop.



Democratitzant Hadoop - MapReduce

Però, a mesura que les dades creixien, la complexitat dels codis Map-Reduce va créixer proporcionalment. Per tant, la formació de persones amb antecedents no programatius per escriure programes MapReduce es va fer difícil. A més, per realitzar anàlisis senzilles cal escriure cent línies de codi MapReduce. Atès que SQL va ser àmpliament utilitzat per enginyers i analistes, inclòs Facebook, per tant, posar SQL a la part superior d’Hadoop semblava una manera lògica de fer Hadoop accessible als usuaris amb antecedents SQL.

Per tant, la capacitat de SQL és suficient per a la majoria dels requisits analítics i l’escalabilitat d’Hadoop va donar a llum Rusc Apache que permet realitzar consultes SQL com les dades presents a HDFS. Més tard, el projecte Hive va ser obert a l'agost del 2008 per Facebook i avui està disponible gratuïtament com Apache Hive.

Ara, vegem les característiques o avantatges de Hive que el fan tan popular.

Tutorial Apache Hive: avantatges de Hive

  • Útil per a persones que no provenen de programació, ja que elimina la necessitat d’escriure un programa complex MapReduce.
  • extensible i escalable per fer front al creixent volum i varietat de dades, sense afectar el rendiment del sistema.
  • És com una eina eficient ETL (Extreure, Transformar, Carregar).
  • Hive admet qualsevol aplicació client escrita en Java, PHP, Python, C ++ o Ruby exposant la seva Servidor Thrift . (Podeu utilitzar aquests llenguatges del costat del client incrustats amb SQL per accedir a una base de dades com DB2, etc.).
  • Com que la informació de metadades d'Hive s'emmagatzema en un RDBMS, redueix significativament el temps per realitzar comprovacions semàntiques durant l'execució de la consulta.

Tutorial Apache Hive: on utilitzar Apache Hive?

Apache Hive s’aprofita tant dels mons, és a dir, del sistema de bases de dades SQL i marc. Per tant, l’utilitzen una gran multitud d’empreses. S’utilitza principalment per a emmagatzematge de dades on podeu realitzar anàlisis i extracció de dades que no requereixen processament en temps real. Alguns dels camps on podeu utilitzar Apache Hive són els següents:

  • Emmagatzematge de dades
  • Anàlisi ad hoc

Com es diu, no es pot aplaudir amb una sola mà, és a dir, no es pot resoldre tots els problemes amb una sola eina. Per tant, podeu combinar Hive amb altres eines per utilitzar-lo en molts altres dominis. Per exemple, Tableau juntament amb Apache Hive es poden utilitzar per a la visualització de dades, la integració d’Apache Tez amb Hive us proporcionarà capacitats de processament en temps real, etc.
Avançant en aquest bloc Apache Hive Tutorial, anem a fer una ullada a un estudi de casos de la NASA en el qual coneixereu com Hive va resoldre el problema que s’enfrontaven els científics de la NASA mentre realitzaven l’avaluació dels models climàtics.

Tutorial de rusc: cas pràctic de la NASA

Un model climàtic és una representació matemàtica dels sistemes climàtics basada en diversos factors que afecten el clima de la Terra. Bàsicament, descriu la interacció de diversos motors del clima com oceà, sol, atmosfera, etc.proporcionar una visió de la dinàmica del sistema climàtic. S'utilitza per projectar les condicions climàtiques simulant els canvis climàtics en funció de factors que afecten el clima. El Laboratori de Propulsió per Reacció de la NASA ha desenvolupat el Sistema Regional d’Avaluació del Model Climàtic (RCMES) per a l’anàlisi i l’avaluació del model de sortida climàtica enfront de dades de teledetecció presents en diversos dipòsits externs.

El RCMES (Sistema d'Avaluació del Model Climàtic Regional) té dos components:

  • RCMED (base de dades d’avaluació del model climàtic regional):

És una base de dades de núvol escalable que carrega les dades de teledetecció i dades de reanàlisi relacionades amb el clima mitjançant extractors com ara extractors Apache OODT, Apache Tika, etc. Finalment, transforma les dades com a model de punt de dades que té la forma (latitud , longitud, temps, valor, alçada) i l’emmagatzema a la base de dades My SQL. El client pot recuperar les dades presents a RCMED realitzant consultes Espai / Temps. La descripció d’aquestes consultes ara no és rellevant per a nosaltres.

  • RCMET (conjunt d’eines d’avaluació del model climàtic regional):

Proporciona a l'usuari la possibilitat de comparar les dades de referència presents al RCMED amb les dades de sortida del model climàtic obtingudes d'algunes altres fonts per realitzar diferents tipus d'anàlisi i avaluació. Podeu consultar la imatge que es mostra a continuació per entendre l'arquitectura de RCMES.

Les dades de referència del RCMED provenen de la teledetecció basada en satèl·lit, d'acord amb els diferents paràmetres necessaris per a l'avaluació del model climàtic. Per exemple: AIRS (Atmospheric Infrared Sounder) proporciona paràmetres com la temperatura de l'aire superficial, la temperatura i el geopotencial, TRMM (Tropical Rainfall Measurement Mission) proporciona precipitacions mensuals, etc.

Problemes que afronta la NASA mitjançant el sistema de bases de dades MySQL:

  • Després de carregar la base de dades MySQL amb 6.000 milions de tuples del formulari (latitud, longitud, temps, valor del punt de dades, alçada), el sistema es va bloquejar com es mostra a la imatge superior.
  • Fins i tot després de dividir tota la taula en subconjunts més petits, el sistema generava una sobrecàrrega enorme mentre processava les dades.

Per tant, necessitaven una solució escalable que pogués emmagatzemar i processar aquesta enorme quantitat de dades amb SQL, com ara la capacitat de consulta. Finalment, van decidir utilitzar Apache Hive per superar els problemes esmentats anteriorment.

Com pot Apache Hive solucionar el problema?

Ara, a veure, quines són aquestes característiques que van convèncer l’equip JPL de la NASA a incloure Apache Hive com a part integral de la seva estratègia de solució:

  • Atès que Apache Hive s’executa a la part superior d’Hadoop, és escalable i pot processar dades de manera distribuïda i paral·lela.
  • Proporciona un llenguatge de consulta Hive, similar al SQL i, per tant, fàcil d'aprendre.

Desplegament de Hive:

La següent imatge explica l’arquitecte RCMES amb integració d’Apache Hive:

gestió de compres en gestió de projectes

Fig : Tutorial Hive - Arquitectura RCMES amb Apache Hive

La imatge anterior mostra el desplegament del rusc apache a RCMES. L'equip de la NASA va fer els següents passos mentre desplegava Apache Hive:

  • Van instal·lar Hive mitjançant Cloudera i Apache Hadoop, tal com es mostra a la imatge anterior.
  • Van utilitzar Apache Sqoop per ingerir dades a la base de dades MySQL de Hive.
  • Apache OODT wrapper es va implementar per realitzar consultes a Hive i recuperar les dades a RCMET.

Observacions inicials de benchmarking amb Hive:

  • Inicialment, carregaven 2.500 milions de punts de dades en una sola taula i realitzaven una consulta de recompte. Per exemple, Rusc> seleccioneu recompte (datapoint_id) de dataPoint. Van trigar entre 5 i 6 minuts a comptar tots els registres (de 15 a 17 minuts per als 6.800 milions de registres).
  • La fase de reducció va ser ràpida, però la fase del mapa va trigar el 95% del temps total de processament. N’utilitzaven sis ( 4x quad-core ) sistemes amb 24 GB de RAM (aprox.) en cadascun dels sistemes.
  • Fins i tot després d’afegir més màquines, canviar la mida del bloc HDFS (64 MB, 128 MB, 256 MB) i modificar moltes altres variables de configuració (io.ordenar.factor, i.ordenar.mb), no van obtenir massa èxit en reduir el temps per completar el recompte.

Entrada dels membres de la comunitat Hive:

Finalment, els membres de la comunitat Hive van rescatar i van proporcionar diverses idees per resoldre els problemes amb les seves implementacions actuals de Hive:

  • Van esmentar que la velocitat de lectura HDFS és aproximadament 60 MB / s en comparació amb 1 GB / s en cas de disc local, depenent de la capacitat de la xarxa i de la càrrega de treball a NameNode.
  • Els membres van suggerir això 16 mapers caldrà que en el seu sistema actual coincideixi amb el rendiment d'E / S d'una tasca local que no sigui Hadoop.
  • També van suggerir reduir el de mida dividida perquè cada mapador augmenti el nombredemapers i, per tant, proporcionant més paral·lelisme.
  • Finalment, els membres de la comunitat els ho van dir recompte d'ús (1) en lloc de referir-se a comptar ( id_punt_data) . Això es deu al fet que en cas de recompte (1), no hi ha cap columna de referència i, per tant, no es produeixi descompressió ni deserialització mentre es realitza el recompte.

Finalment, la NASA va poder ajustar el seu clúster Hive a les seves expectatives tenint en compte tots els suggeriments donats pels membres de la comunitat Hive. Per tant, van poder consultar milers de milions de files en només 15 segons mitjançant les configuracions del sistema esmentades anteriorment.

Tutorial Apache Hive: Arquitectura del rusc i els seus components

La imatge següent descriu l'arquitectura del rusc i el flux en què s'envia una consultaRusci finalment processat mitjançant el marc MapReduce:

Fig : Tutorial de rusc - Arquitectura de rusc

Com es mostra a la imatge anterior, l'arquitectura Hive es pot classificar en els components següents:

  • Clients de rusc: Hive admet aplicacions escrites en molts idiomes com Java, C ++, Python, etc. mitjançant controladors JDBC, Thrift i ODBC. Per tant, sempre es pot escriure una aplicació client de rusc escrita en un idioma que triï.
  • Serveis de rusc: Apache Hive proporciona diversos serveis com CLI, interfície web, etc. per realitzar consultes. En breu explorarem cadascun d’ells en aquest bloc de tutorials d’Hive.
  • Marc de processament i gestió de recursos: Internament,Hive utilitza el marc Hadoop MapReduce com a motor de facto per executar les consultes. és un tema separat en si mateix i, per tant, no es tracta aquí.
  • Emmagatzematge distribuït: Com que Hive s’instal·la a la part superior d’Hadoop, utilitza l’HDFS subjacent per a l’emmagatzematge distribuït. Podeu consultar el document HDFS bloc per obtenir més informació.

Ara, anem a explorar els dos primers components principals de l’arquitectura Hive:

1. Clients de rusc:

Apache Hive admet diferents tipus d'aplicacions client per realitzar consultes a Hive. Aquests clients es poden classificar en tres tipus:

  • Clients de segona mà: Com que el servidor Hive es basa en Apache Thrift, pot servir la sol·licitud de tots aquells llenguatges de programació que admetin Thrift.
  • Clients de JDBC: Hive permet a les aplicacions Java connectar-s’hi mitjançant el controlador JDBC que es defineix a la classe org.apatxe.hadoop.rusc.jdbc.HiveDriver.
  • Clients ODBC: El controlador ODBC Hive permet que les aplicacions que admeten el protocol ODBC es connectin a Hive. (Igual que el controlador JDBC, el controlador ODBC utilitza Thrift per comunicar-se amb el servidor Hive).

2. Serveis de rusc:

Hive proporciona molts serveis com es mostra a la imatge superior. Vegem cadascun d'ells:

  • Hive CLI (interfície de línia d'ordres): Aquest és l'intèrpret d'ordres predeterminat que proporciona Hive, on podeu executar directament les vostres comandes i consultes de Hive.
  • Interfícies web Apache Hive: A part de la interfície de línia d'ordres, Hive també proporciona una interfície gràfica d'usuari basada en web per executar consultes i ordres de Hive.
  • Servidor Hive: El servidor Hive està basat en Apache Thrift i, per tant, també es coneix com Thrift Server que permet a diferents clients enviar sol·licituds a Hive i recuperar el resultat final.
  • Controlador Apache Hive: És responsable de rebre les consultes enviades a través de la CLI, la interfície d’usuari web, Thrift, ODBC o JDBC per un client. A continuació, el controlador passa la consulta al compilador on es produeix l’anàlisi, la comprovació de tipus i l’anàlisi semàntica amb l’ajut de l’esquema present al metastore.. En el següent pas, es genera un pla lògic optimitzat en forma de DAG (Directed Acyclic Graph) de tasques de reducció de mapes i tasques HDFS. Finalment, el motor d'execució executa aquestes tasques en l'ordre de les seves dependències, mitjançant Hadoop.
  • Metastore: Es pot pensar en botiga metàl·licacom a dipòsit central per emmagatzemar tota la informació de metadades de Hive. Les metadades del rusc inclouen diversos tipus d'informació, com ara l'estructura de les taules i les particionsjuntament amb la columna, el tipus de columna, el serialitzador i el desserialitzador que són necessaris per a l'operació de lectura / escriptura de les dades presents a HDFS. El metastorecomprèn dues unitats fonamentals:
    • Un servei que proporciona metastoreaccés a altresrServeis rusc.
    • Emmagatzematge en disc de les metadades que és separat de l’emmagatzematge HDFS.

Ara, entenem les diferents maneres d’implementar el botiga metàl·lica Hivea la següent secció d’aquest tutorial de rusc.

Tutorial Apache Hive: Configuració del metastore

Metastore emmagatzema la informació de meta dades mitjançant RDBMS i una capa de codi obert ORM (Object Relational Model) anomenada Data Nucleus que converteix la representació d'objectes en esquema relacional i viceversa. La raó per triar RDBMS en lloc de HDFS és aconseguir una latència baixa. Podem implementar metastore en tres configuracions següents:

1. Metastore incrustat:

Tant el servei de metastore com el servei Hive s’executen de manera predeterminada a la mateixa JVM mitjançant una instància de base de dades Derby incrustada on s’emmagatzemen les metadades al disc local. Això s’anomena configuració de metastore incrustat. En aquest cas, només un usuari es pot connectar a la base de dades de metastore alhora. Si inicieu una segona instància del controlador Hive, obtindreu un error. Això és bo per a les proves d’unitats, però no per a les solucions pràctiques.

2. Botiga local:

Aquesta configuració ens permet tenir diverses sessions d’Hive, és a dir, diversos usuaris poden utilitzar la base de dades de metastore alhora. Això s’aconsegueix utilitzant qualsevol base de dades compatible amb JDBC, com MySQL, que s’executa en una JVM independent o en una màquina diferent de la del servei Hive i el servei de metastore que s’executen a la mateixa JVM que es mostra a dalt. En general, l'opció més popular és implementar un servidor MySQL com a base de dades de metastore.

3. Magatzem remot:

A la configuració de botiga de control remot, el servei de botiga de botiga s'executa en la seva pròpia JVM independent i no en el servei de botiga JVM. Altres processos es comuniquen amb el servidor de metastore mitjançant API de Thrift Network. Podeu tenir un o més servidors de metastore en aquest cas per proporcionar més disponibilitat.El principal avantatge d'utilitzar el magatzem remot és que no cal compartir les credencials d'inici de sessió de JDBC amb cada usuari de Hive per accedir a la base de dades de magatzem.

Tutorial Apache Hive: model de dades

Les dades de Hive es poden classificar en tres tipus a nivell granular:

  • Taula
  • Partició
  • Cubell

Taules:

Les taules de Hive són les mateixes que les taules presents en una base de dades relacional. Podeu fer-hi operacions de filtratge, projecció, unió i unió. Hi ha dos tipus de taules a Hive:

1. Taula gestionada:

Comandament:

Preguntes sobre l'entrevista de científics de dades de Google

CREA TAULA (columna1 tipus_dades, columna2 tipus_dades)

CARREGAR LES DADES INPATH INTO a la taula managed_table

Com el seu nom indica (taula gestionada), Hive és responsable de gestionar les dades d’una taula gestionada. En altres paraules, el que volia dir amb 'Hive gestiona les dades' és que si carregueu les dades d'un fitxer present a HDFS en un Hive Taula gestionada i emetre-hi una ordre DROP, se suprimirà la taula juntament amb les seves metadades. Per tant, les dades que pertanyen a la caiguda taula_gestionada ja no existeixen a cap lloc de HDFS i no es pot recuperar de cap manera. Bàsicament, moveu les dades quan emeteu l'ordre LOAD de la ubicació del fitxer HDFS al directori del magatzem Hive.

Nota: El camí per defecte del directori del magatzem està definit a / user / hive / warehouse. Les dades d'una taula Hive resideixen a warehouse_directory / nom_tabla (HDFS). També podeu especificar la ruta del directori del magatzem al paràmetre de configuració hive.metastore.warehouse.dir present al hive-site.xml.

2. Taula externa:

Comandament:

CREA UNA TAULA EXTERNA (columna1 tipus_dades, columna2 tipus_dades) UBICACIÓ ''

CÀRREGA DE DADES INPATH ‘’ A LA TAULA

Per a taula externa , Hive no es fa responsable de la gestió de les dades. En aquest cas, quan emeteu l'ordre LOAD, Hive mou les dades al directori del magatzem. A continuació, Hive crea la informació de metadades per a la taula externa. Ara, si emeteu una ordre DROP al fitxer taula externa , només se suprimirà la informació de metadades relativa a la taula externa. Per tant, encara podeu recuperar les dades d’aquesta taula molt externa del directori de magatzem mitjançant ordres HDFS.

Particions:

Comandament:

CREA TABLE nom_table (columna1 tipus_dades, columna2 tipus_dades) PARTICIONAT PER (partició1 tipus_dades, partició2_tipus_dades, & hellip.)

Hive organitza les taules en particions per agrupar tipus de dades similars en funció d'una clau de partició o columna. Cada taula pot tenir una o més claus de partició per identificar una partició en particular. Això ens permet tenir una consulta més ràpida sobre les parts de les dades.

Nota: Recordeu que l’error més comú en crear particions és especificar un nom de columna existent com a columna de partició. En fer-ho, rebreu un error: 'Error en l'anàlisi semàntica: columna repetida en particions de columnes'.

Entenguem la partició prenent un exemple en què tinc una taula student_details que conté la informació dels estudiants d'alguns col·legis d'enginyeria com student_id, nom, departament, any, etc. que pertanyen a un departament concret s’emmagatzemaran junts a la mateixa partició. Físicament, una partició no és res més que un subdirectori del directori de la taula.

Suposem que tenim dades de tres departaments a la taula de detalls estudiant: CSE, ECE i Civil. Per tant, tindrem tres particions en total per a cadascun dels departaments tal com es mostra a la imatge següent. I, per a cada departament, tindrem totes les dades relatives a aquest mateix departament que resideixen en un subdirectori separat sota el directori de la taula Hive. Per exemple, totes les dades dels estudiants sobre els departaments CSE s’emmagatzemaran a user / hive / warehouse / student_details / dept. = CSE. Per tant, les consultes sobre estudiants CSE només haurien de revisar les dades presents a la partició CSE. Això fa que la partició sigui molt útil, ja que redueix la latència de la consulta només escanejant rellevant dades particionades en lloc de tot el conjunt de dades. De fet, en implementacions del món real, us ocupareu de centenars de TB de dades. Per tant, imagineu-vos escanejar aquesta enorme quantitat de dades per obtenir alguna consulta 95% les dades escanejades per vosaltres no eren rellevants per a la vostra consulta.

Us suggeriria que passeu pel bloc a Ordres de rusc on trobareu diferents maneres d'implementar particions amb un exemple.

Cubells:

Ordres:

CREA TABLE nom_tabla PARTICIONAT PER (partició1 tipus_dades, partició2_tipus_dades, & hellip.) AGRUPAT PER (nom_columna1, nom_colonna2, ...) ORDENAT PER (nom_columna [ASC | DESC], ...)] A NUM_buckets BUCKETS

Ara podeu dividir cada partició o la taula sense particionar en dipòsits segons la funció hash d’una columna de la taula. En realitat, cada dipòsit és només un fitxer al directori de particions o al directori de la taula (taula sense particionar). Per tant, si heu escollit dividir les particions en n dipòsits, tindreu n fitxers a cadascun del directori de particions. Per exemple, podeu veure la imatge anterior on hem compartit cada partició en 2 cubs. Per tant, cada partició, diguem CSE, tindrà dos fitxers on cadascun d’ells emmagatzemarà les dades de l’estudiant CSE.

llançament contra llançaments vs llançable a Java

Com distribueix Hive les files en cubs?

Bé, Hive determina el número de dipòsit d'una fila mitjançant la fórmula: hash_function (bucketing_column) mòdul (num_of_buckets) . Aquí, hash_function depèn del tipus de dades de la columna. Per exemple, si esteu recopilant la taula sobre la base d'alguna columna, diguem user_id, del tipus de dades INT, la funció hash_ serà: funció hash (identificador_usuari ) = valor enter de user_id . I, suposem que heu creat dos compartiments, llavors Hive determinarà les files que aniran al dipòsit 1 de cada partició calculant: (valor de user_id) mòdul (2). Per tant, en aquest cas, les files que tinguin user_id que acabin amb un dígit enter parell residiran en un mateix dipòsit corresponent a cada partició. La funció hash_ per a altres tipus de dades és una mica complexa de calcular i, de fet, per a una cadena ni tan sols es reconeix humanament.

Nota: Si utilitzeu Apache Hive 0.x o 1.x, heu d'emetre command-set hive.enforce.bucketing = true des del terminal Hive abans de realitzar el bucketing. Això us permetrà tenir el nombre correcte de reductor mentre utilitzeu clàusula clúster per recollir una columna. En cas que no ho hàgiu fet, és possible que el nombre de fitxers generats al directori de la taula no sigui igual al nombre de dipòsits. Com a alternativa, també podeu establir el nombre de reductor igual al nombre de dipòsits utilitzant set mapred.reduce.task = num_bucket.

Per què necessitem galledes?

Hi ha dos motius principals per realitzar un bucketing a una partició:

  • A unió lateral del mapa requereix que les dades que pertanyen a una clau d’unió única estiguin presents a la mateixa partició. Però, què passa amb els casos en què la vostra clau de partició difereix de la d'unió? Per tant, en aquests casos podeu realitzar una unió lateral del mapa recopilant la taula amb la tecla d'unió.
  • L’acumulació fa que el procés de mostreig sigui més eficient i, per tant, ens permet reduir el temps de consulta.

M’agradaria concloure aquest bloc de tutorials d’Hive aquí. Estic bastant segur que després d’haver passat aquest bloc de tutorial de Hive, us haureu adonat de la simplicitat d’Apache Hive. Des de llavors, heu après tots els fonaments del rusc, és hora de tenir una experiència pràctica amb Apache Hive. Per tant, mireu el proper bloc d’aquesta sèrie de blocs de Hive Tutorial que es troba a la instal·lació de Hive i comenceu a treballar a Apache Hive.

Ara que ja heu entès Apache Hive i les seves característiques, consulteu el per Edureka, una empresa d'aprenentatge en línia de confiança amb una xarxa de més de 250.000 estudiants satisfets repartits per tot el món. El curs de formació en certificació Edureka Big Data Hadoop ajuda els estudiants a convertir-se en experts en HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume i Sqoop mitjançant casos d’ús en temps real en dominis Retail, Social Media, Aviació, Turisme, Finances

Tens alguna pregunta? Esmenta’l a la secció de comentaris i et respondrem.