Hive View og indeksering: Lag med eksempler

⚡ Smart oppsummering

Visninger i Hive er lagrede spørringer som oppfører seg som skrivebeskyttede tabeller, mens indekser er pekere til en kolonne som fremskynder oppslag, og begge opprettes med korte HiveQL-setninger som vist her.

  • 👁️ Synspunktet er logisk: En visning lagrer bare SELECT-setningen sin i metalageret, så den opptar ingen egen diskplass.
  • 🔒 Skrivebeskyttet av design: En visning kan ikke være målet for LOAD, INSERT eller ALTER, fordi Hive evaluerer den på nytt på hver spørring.
  • 📍 Indekspunkter på data: En indeks er en peker til en kolonneverdi som lar Hive lese deler av en fil i stedet for hele tabellen.
  • 🗂️ To håndterere: Kompakt indeksering passer for kolonner med høy kardinalitet, og bitmap-indeksering passer for kolonner med få distinkte verdier.
  • 🔄 Manuell ombygging: En indeks oppdateres aldri automatisk, så ALTER INDEX REBUILD må kjøres etter at basistabellen endres.
  • 🚫 Fjernet i Hive 3.0: Indeksering ble fjernet under HIVE-18448, og materialiserte visninger, ORC eller Parquet-lagring og -partisjonering erstattet den.

Visninger og indekser i Hive forklart med eksempler

Hva er en visning?

Visninger ligner på tabeller, og de genereres basert på kravene. En visning er et rent logisk objekt uten egen lagring: Hive beholder bare spørreteksten i metalageret og evaluerer den hver gang visningen refereres til.

  • Vi kan lagre alle resultatsettdata som en visning i Hive
  • Bruken ligner på visninger som brukes i SQL
  • En visning er skrivebeskyttet, så den kan ikke være målet for en LOAD-, INSERT- eller ALTER-setning som skriver data.

Oppretting av visning:

Syntaks:

Create VIEW <VIEWNAME> AS SELECT

Det fullstendig dokumenterte skjemaet godtar også en IF NOT EXISTS-klausul og en valgfri kolonneliste, noe som er nyttig når SELECT-listen inneholder uttrykk i stedet for vanlige kolonnenavn.

Eksempel:

Hive>Create VIEW Sample_View AS SELECT * FROM employees WHERE salary>25000

I dette eksemplet oppretter vi visningen Sample_View, som viser alle radverdier med et lønnsfelt større enn 25 000. Filteret ligger i visningen, slik at alle spørringer som velger fra Sample_View bare ser disse radene.

Hva er indeks?

Indekser er pekere til et bestemt kolonnenavn i en tabell. Målet med en indeks er å forbedre oppslagshastigheten: uten en indeks kan en spørring med et predikat som HVOR tab1.col1 = 10 laster inn hele tabellen eller partisjonen og behandler hver rad, mens en indeks på col1 lar Hive bare lese deler av filen.

  • Brukeren må definere indeksen manuelt
  • Uansett hvor vi oppretter en indeks, betyr det at vi oppretter en peker til et bestemt kolonnenavn i tabellen.
  • Eventuelle endringer som gjøres i kolonnen i tabellen lagres ved hjelp av indeksverdien som er opprettet for kolonnenavnet.

Denne hastighetsøkningen er ikke gratis. Det koster ekstra prosessering å bygge indeksen, og selve indeksen tar opp diskplass som må vedlikeholdes ved siden av tabellen.

Syntaks:

Create INDEX <INDEX_NAME> ON TABLE <TABLE_NAME(column names)>

Eksempel:

Create INDEX sample_Index ON TABLE guruhive_internaltable(id)

Her lager vi en indeks på tabellen guruhive_internaltable for kolonnenavnet id. Merk at en fullstendig setning på en utgivelse som fortsatt støtter indeksering også trenger en index-handler-klausul, som neste avsnitt viser i sin helhet.

Forskjellen mellom visning og indeks i Hive

Visninger og indekser introduseres ofte sammen fordi begge ligger oppå en eksisterende tabell, men de løser forskjellige problemer. En visning endrer hva en spørring ser, mens en indeks endrer hvor raskt Hive finner den. Tabellen nedenfor sammenligner dem.

Aspekt Se Index
Hva den lagrer Bare SELECT-setningen i metastoren En separat indekstabell som inneholder pekere til dataene
Formål Forenkle eller begrense hva en spørring returnerer Reduser mengden data som skannes for et predikat
Diskkostnad none Ekstra lagringsplass pluss en gjenoppbygging etter dataendringer
Skrivetilgang Read-only Ikke spørt direkte; optimizeren bruker den
Nåværende status Fullt støttet Fjernet i Hive 3.0

I praksis opprettes en visning for lesbarhet og tilgangskontroll, og en indeks opprettes utelukkende for ytelse på en selektiv kolonne.

Typer indeks i Hive med syntaks

Utgivelser opp til Hive 2.x leverte to indeksbehandlere, og behandleren er navngitt i den obligatoriske AS-klausulen. Kompakt indeksering kom i Hive 0.7.0 og bitmap-indeksering i Hive 0.8.0.

  • Kompakt indeks: lagrer verdien sammen med adressen til HDFS-blokken som inneholder den, i stedet for å registrere plasseringen av hver enkelt forekomst. Den passer til kolonner med mange forskjellige verdier.
  • Bitmap-indeks: lagrer et bitmap per distinkt verdi, som er den vanlige tilnærmingen for en kolonne med bare et lite antall distinkte verdier, for eksempel et status- eller kjønnsflagg.

En kompakt indeks opprettes, listes og slettes som følger:

CREATE INDEX table01_index ON TABLE table01 (column2) AS 'COMPACT';
SHOW INDEX ON table01;
DROP INDEX table01_index ON table01;

Alternativet MED UTSAT GJENOPPSBYGGING registrerer indeksen uten å fylle den ut, slik at byggingen kan planlegges separat med ALTER INDEX. En bitmap-indeks opprettes på samme måte, med et annet handlernavn:

CREATE INDEX table03_index ON TABLE table03 (column4) AS 'BITMAP' WITH DEFERRED REBUILD;
ALTER INDEX table03_index ON table03 REBUILD;
SHOW FORMATTED INDEX ON table03;
DROP INDEX table03_index ON table03;

En indeks oppdateres ikke automatisk. Hver gang basistabellen mottar nye data, må ALTER INDEX … REBUILD kjøres på nytt, og på en partisjonert tabell kan gjenoppbyggingen begrenses til én enkelt partisjon.

Hvorfor indeksering ble fjernet i Hive 3.0

Indeksering ble fjernet fra Hive i versjon 3.0 under HIVE-18448, så CREATE INDEX, SHOW INDEX og DROP INDEX finnes ikke lenger på en gjeldende klynge. Funksjonen var sjelden verdt gjenoppbyggingskostnadene når kolonnelagring og den kostnadsbaserte optimizeren var modnet. Tre erstatninger dekker samme område.

  • Materialiserte visninger: introdusert i Hive 3.0.0, en materialisert visning lagrer det forhåndsberegnede resultatet av en spørring, og optimaliseringsprogrammet skriver innkommende spørringer mot det automatisk på nytt.
  • Kolonneformater: ORC og Parquet har sine egne lette indekser og min/maks-statistikk, slik at leseren kan hoppe over hele striper, blokker eller filer uten noen brukerdefinert indeks.
  • Skillevegger og bøtter: partisjonering og bucketing beskjære data på katalog- og filnivå, noe som vanligvis fjerner langt mer input enn en indeks noen gang gjorde.

På Hive 2.x er en indeks fortsatt gyldig, men nytt arbeid er bedre tjent med et av alternativene ovenfor.

Spørsmål og svar

DROP VIEW view_name fjerner den, og ALTER VIEW view_name RENAME TO new_name gir den nytt navn. Fordi en visning ikke inneholder data, slippping man berører aldri basistabellen; bare metastore-oppføringen forsvinner.

En materialisert visning lagrer det forhåndsberegnede spørreresultatet som reelle data, så det koster diskplass og trenger en GJENBYGGING. En normal visning lagrer bare spørreteksten og beregnes på nytt for hver referanse.

Nei. Metalageret beholder SELECT-setningen og den løste kolonnelisten, ikke noe mer. Hver referanse kjører den underliggende spørringen på nytt, og det er derfor en visning over en treg kobling forblir treg.

I Hive 0.12.0 og tidligere var navnet sensitivt for store og små bokstaver for CREATE INDEX og DROP INDEX, mens ALTER INDEX trengte små bokstaver. Hive 0.13.0 gjorde indeksnavn ufølsomme for store og små bokstaver for alle setninger.

Ja, på alle moderne klynger. Partisjonsrensing fjerner hele mapper før skanningen starter, og bucketing begrenser en sammenføyning eller et eksempel til bestemte filer, noe som vanligvis overgår det en indekstabell kan levere.

Maskinlæringsverktøy profilerer spørrelogger, rangerer predikatkolonner etter selektivitet og frekvens, og foreslår hvor en materialisert visning eller partisjonsordning ville lønne seg. Valider hvert forslag mot en EXPLAIN-plan før du bruker det.

Den produserer CREATE VIEW-setninger pålitelig fra en kort kommentar. Sjekk alt versjonsspesifikt, fordi den fortsatt sender ut CREATE INDEX-syntaks som en Hive 3.0 eller nyere klynge avviser direkte.

Indeksen er en separat tabell med pekere, og Hive oppdaterer den aldri når basistabellen endres. Uten en gjenoppbygging blir pekerne foreldet, så optimaliseringsprogrammet hopper enten over indeksen eller returnerer utdaterte treff.

Oppsummer dette innlegget med: