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.

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.
