Apache Impala: Min indsigt og bedste praksis

Så du har din Hadoop, terabyte af data kommer ind i den om dagen, ETL’er udføres 24/7 med Spark, Hive eller – gud forbyde det – Pig. Og når dataene så er i præcis den form, du ønsker (eller endda før det), og alt er helt perfekt – så vil analytikerne søge i dem. Hvis du har valgt Impala til den mission, er denne artikel til dig.

Vi bruger Impala til et par formål:

• Lad analytikerne forespørge på nye typer data, som datateknikerne endnu ikke har lavet ETL’er på.
• Lad analytikere forespørge på data, hvis endelige destination (efter ETL-processen) er HDFS.
• Rapportering (med vores egne værktøjer).
• Overvågning & af varslingssystemer (på nye data, der kommer ind hver time).

Vi har titusindvis af forespørgsler om dagen, hver forespørgsel scanner i gennemsnit et par gigabyte data og tager 10 sekunder. Vores klynge er ikke enorm i form af hardware og antal knuder vi har. For ikke at nævne, at vi har hundredvis af andre arbejdsgange (Spark, Pig, Hive), der kører hver dag på den samme klynge.

I denne artikel vil jeg dele den viden og de konklusioner, vi har lært af vores Impala-optimeringsprojekt.

Hvad er Impala?

Hvis du ikke ved, hvad det er – læs om det i Cloudera Impala Guide, og kom så tilbage her til de interessante ting.

Impala Vs. Other SQL-on-Hadoop Solutions

Der er ikke noget at sammenligne her. I disse dage er Hive kun til ETL’er og batch-processing. Dine analytikere vil få deres svar langt hurtigere ved hjælp af Impala, selv om Impala i modsætning til Hive ikke er fejltolerant. Men det er ok for en MPP-motor (Massive Parallel Processing).

Impala er hurtigere end Hive, fordi det er en helt anden motor, og Hive er over MapReduce (som er meget langsom på grund af de alt for mange disk I/O-operationer).

Impala Vs. SparkSQL

Ja, SparkSQL er meget hurtigere end Hive, især hvis den kun udfører in-memory-beregninger, men Impala er stadig hurtigere end SparkSQL.

Det er hurtigere, fordi Impala er en motor, der er designet specielt til opgaven med interaktiv SQL over HDFS, og den har arkitekturkoncepter, der hjælper den med at opnå det. For eksempel er Impala’s “always-on” daemons oppe og venter på forespørgsler 24/7 – noget som ikke er en del af SparkSQL. Og nogle flere grunde som Impalas codegen-mekanisme, Parquet-formatoptimering, statistik, metadata-cache osv.

Den JDBC/ODBC Thrift Server i SparkSQL kan være en sammenlignelig konkurrent til Impala, men da jeg ikke kunne finde meget om den på nettet – vil jeg bare oplyse det her, og hvis du har noget viden og erfaring om dette emne, så skriv venligst et medium indlæg om det. Jeg skriver måske et i den nærmeste fremtid.

Impala Vs. Presto

Presto er en meget lignende teknologi med en lignende arkitektur. Ifølge næsten alle benchmarks på nettet – er Impala hurtigere end Presto, men Presto er meget mere pluggable end Impala. Impala formodes at være hurtigere, når du har brug for SQL over Hadoop, men hvis du har brug for at forespørge flere datakilder med den samme forespørgselsmotor – er Presto bedre end Impala. Se blot denne liste over Presto Connectors. Impala kan også forespørge Amazon S3, Kudu, HBase, og det er stort set det hele.

For yderligere læsning om Presto – dette er en PrestoDB fuld gennemgang, jeg har lavet.

Impala Best Practices

Impala klarer sig bedst, når den forespørger filer, der er gemt som Parquet-format. Hele den teknologi, som Cloudera Impala er baseret på, kommer fra Google Dremel Whitepaper, og i dette dokument kan du finde det koncept, som Parquet er baseret på. Så husk bare ikke at forespørge json-, csv- eller sekvensfiler – parquet dine filer, før du lader analytikere forespørge dem.

Arbejd med partitioner

Partioner dine data i overensstemmelse med dine analytikeres forespørgsler. Impala har ikke nogen indekser, så det er den eneste måde at reducere mængden af data, du behandler i hver forespørgsel. Vi bruger DT (datotid) som den vigtigste partitioneringsmetode for de fleste af vores tabeller. Overpartitionering kan være farlig (læs videre for at få flere detaljer).

The REFRESH Statement

The REFRESH Statement kan være en dyr operation, især hvis du har tusindvis af tabeller med data, der tilføjes til dem hver time. Vi kører mere end 10.000 af opdateringer om dagen. Det er min bedste praksis for refreshes:

• Siden Impala 2.7 kan du udføre en refresh på en specifik partition, brug det til at gøre REFRESH-erklæringen meget lettere.
• Hot & Archived tables architecture – hver tabel vil have en hot version og en arkiveret version. Den varme version vil indeholde de sidste 24 timer, og en opdatering af denne tabel vil finde sted hver time og vil være meget lettere. Hver dag vil den aktuelle tabel blive slået sammen med den arkiverede tabel, og der vil blive foretaget en kraftigere opdatering af denne tabel. Og selvfølgelig en VIEW over disse 2, der forener dem, så brugerne vil ikke engang være opmærksomme på dette.
• Har ikke for mange metadata (filer og partitioner) pr. tabel (se afsnittet “Optimal filstørrelse”).

Compute Stats

Statistik vil gøre dine forespørgsler meget mere effektive, især dem, der involverer mere end én tabel (joins). Derfor bør du beregne statistik for alle dine tabeller og vedligeholde en arbejdsgang, der holder dem opdateret med inkrementel statistik. For flere tekniske detaljer læs om Cloudera Impala Table and Column Statistics.

Optimal filstørrelse – 256 MB/Fil

TL;DR: Sørg for, at du ikke har for mange små filer – det vil skade din katalogserver, opdateringer og forespørgselsydelse rigtig meget.

Vi bemærkede, at vores Impala-katalogserver bliver ved med at gå ned 4 gange om ugen, og at vores forespørgsler tog for lang tid. Så indså vi, at vi har alt for mange filer og partitioner. Vi arbejdede med DT-partitioner på timebasis, uanset partitionernes størrelse.

Sådan havde vi efter 2 år tabeller med 17 GB data og 17.000 partitioner – hvilket betyder, at hver partition er ca. 1 MB. Vi havde tabeller med partitioner på en størrelse på 50 KB. Og som om det ikke var nok, havde nogle af disse små partitioner flere filer i dem.

I begyndelsen tænkte vi, at denne urimelige mængde filer blot får vores metadata til at blive for store, og at det er derfor, at opdateringerne er så tunge, og at katalogserveren går ned. Men så gik det op for os, at mængden af filer også påvirker vores forespørgselsydelse meget dårligt (fordi antallet af scannertråde, der er nødvendige for at læse så mange parketfiler).

Hvor dårligt? Vi udførte en test på en faktisk 500 MB tabel, vi har, med 17.280(!) partitioner og filer. Vi oprettede en ny fusioneret version af denne tabel med kun 2 filer, 1 pr. år. SCAN HDFS-delen i oversigten over forespørgselsudførelsen var 2.000 gange hurtigere. Det var den del, vi forstod lige præcis, hvor meget vores små filer skader os.

Så begyndte vi at administrere vores partitioner og slå dem sammen til den optimale filstørrelse, som er ca. 256mb.

Tabeller med en timelig partitionering blev dagligt, månedligt eller årligt partitioneret. Hver partition har kun 1 fil (medmindre dens størrelse er > 256mb)

Konfigurer koordinatorer & eksekutorer pr. dæmon

Siden Impala 2.9 kan du bestemme, hvilke impala-dæmoner der er koordinatorer og hvilke der er eksekutorer. Det er en enorm ændring, for før det – alle dæmoner var koordinatorer og eksekutorer, og overheadet ved at være koordinator er meget ressourcekrævende for store klynger.

Det betyder for eksempel, at hver knude holder al metadata-cache i sin RAM. Og hvis du f.eks. har 20 GB metadata og 50 knuder – betyder det et spild af 1 TB RAM, bare fordi alle knuderne også er koordinatorer!

Test, hvad der er den bedste koordinatorer/eksekutorer-hastighed for dig, og brug den. Tip: Start med 2 koordinatorer pr. klynge.

Kolonne-datatyper

I starten brugte vi STRING til alle vores kolonner i alle tabellerne. Det er en rigtig dårlig praksis, der skadede ydeevnen meget. Du bør forsøge at vælge den type, der passer bedst til kolonnen ud af alle de datatyper, som Impala understøtter.

Impala Query Limits

Du bør bruge Impala Admission Control til at indstille forskellige puljer til forskellige grupper af brugere for at begrænse nogle brugeres brug til X samtidige forespørgsler eller Y hukommelse. Men endnu mere end det – vi har bygget vores eget system til at håndtere problematiske brugere og forespørgsler.

Vores system sampler de aktuelle kørende forespørgsler hvert 10. sekund, og hvis en forespørgsel kører i mere end 30 minutter – bliver den dræbt. Hvis den samme forespørgselsskabelon blev dræbt 90 % af gangene i sidste måned, fordi den tog mere end 30 minutter – vil vores system dræbe den straks, når det genkender skabelonen, for at beskytte vores infrastruktur.

Dræbning af forespørgsler er ikke et nyt koncept – Amazon Athena har gjort det før os, men dræb forespørgsler kun ved problematiske mønstre – det er noget, ingen andre gør, og det er den eneste måde at håndtere tusindvis af sultne analytikere på.

Summary

Hvis du har brug for at lade dine analytikere udføre ad-hoc, interaktive SQL-forespørgsler over din Hadoop – så er Impala en fantastisk løsning. Du bør læse Cloudera Impala Guide for at blive en rigtig god Impala-administrator og huske at arbejde efter den bedste praksis, som jeg forklarede her.