Apache Impala: Mina insikter och bästa praxis

Så du har din Hadoop, terabyte av data kommer in i den per dag, ETL:er görs dygnet runt med Spark, Hive eller, gud förbjude – Pig. Och sedan när uppgifterna har fått exakt den form du vill ha dem i (eller till och med före det) och allt är perfekt, vill analytikerna fråga efter dem. Om du valde Impala för det uppdraget är den här artikeln för dig.

Vi använder Impala för några få syften:

• Låta analytiker söka efter nya typer av data som datateknikerna inte har skapat några ETL:er på ännu.
• Låta analytiker söka efter data vars slutdestination (efter ETL-processen) är HDFS.
• Rapportering (med våra egna verktyg).
• Övervakning &varningssystem (på nya data som kommer in varje timme).

Vi har tiotusentals förfrågningar per dag, varje förfrågan genomsöker i genomsnitt ett par gigabyte data och tar 10 sekunder. Vårt kluster är inte enormt när det gäller hårdvara och antal noder vi har. För att inte nämna att vi har hundratals andra arbetsflöden (Spark, Pig, Hive) som körs varje dag på samma kluster.

I den här artikeln kommer jag att dela med mig av den kunskap och de slutsatser vi lärt oss från vårt Impala-optimeringsprojekt.

Vad är Impala?

Om du inte vet vad det är – läs om det i Cloudera Impala Guide, och kom sedan tillbaka hit för de intressanta sakerna.

Impala Vs. Other SQL-on-Hadoop Solutions

Det finns inget att jämföra här. Hive är numera bara till för ETL:er och batch-bearbetning. Dina analytiker kommer att få sitt svar mycket snabbare om de använder Impala, även om Impala till skillnad från Hive inte är feltolerant. Men det är okej för en MPP-motor (Massive Parallel Processing).

Impala är snabbare än Hive eftersom det är en helt annan motor och Hive är över MapReduce (som är mycket långsam på grund av för många disk I/O-operationer).

Impala Vs. SparkSQL

Ja, SparkSQL är mycket snabbare än Hive, särskilt om den endast utför beräkningar i minnet, men Impala är fortfarande snabbare än SparkSQL.

Det är snabbare eftersom Impala är en motor som är utformad speciellt för uppdraget med interaktiv SQL över HDFS, och den har arkitekturkoncept som hjälper den att uppnå detta. Till exempel är Impalas ”always-on” daemons uppe och väntar på förfrågningar dygnet runt – något som inte ingår i SparkSQL. Och ytterligare några skäl som Impalas codegen-mekanism, optimeringen av Parquet-formatet, statistik, metadatacache etc.

JDBC/ODBC Thrift Server i SparkSQL kan vara en jämförbar konkurrent till Impala, men eftersom jag inte hittade så mycket om den på webben – så anger jag det bara här, och om du har någon kunskap och erfarenhet om detta ämne så skriv gärna ett medium inlägg om det. Jag kanske skriver ett inom en snar framtid.

Impala Vs. Presto

Presto är en mycket liknande teknik med liknande arkitektur. Enligt nästan alla benchmarks på nätet – Impala är snabbare än Presto, men Presto är mycket mer pluggable än Impala. Impala antas vara snabbare när du behöver SQL över Hadoop, men om du behöver fråga flera datakällor med samma sökmotor – Presto är bättre än Impala. Se den här listan över Presto Connectors. Impala kan också fråga Amazon S3, Kudu, HBase och det är i princip allt.

För ytterligare läsning om Presto – det här är en fullständig PrestoDB-granskning som jag har gjort.

Impala Best Practices

Impala presterar bäst när den frågar efter filer som är lagrade i Parquet-format. Hela tekniken som Cloudera Impala bygger på kommer från Google Dremel Whitepaper och i det dokumentet kan du hitta konceptet som Parquet bygger på. Så kom ihåg att inte fråga efter json-, csv- eller sekvensfiler – parquetera dina filer innan du låter analytiker söka efter dem.

Arbeta med partitioner

Partitionera dina data i enlighet med dina analytikers frågor. Impala har inga index så det är det enda sättet att minska mängden data som du bearbetar i varje fråga. Vi använder DT (datum och tid) som den huvudsakliga partitioneringsmetoden för de flesta av våra tabeller. Överpartitionering kan vara farligt (läs vidare för mer information).

The REFRESH Statement

The REFRESH Statement kan vara en dyr operation, särskilt om du har tusentals tabeller med data som läggs till varje timme. Vi kör mer än 10 000 uppdateringar per dag. Detta är mina bästa metoder för uppdateringar:

• Sedan Impala 2.7 kan du utföra en uppdatering på en specifik partition, använd det för att göra REFRESH-anvisningen mycket lättare.
• Hot & Archived tables architecture – varje tabell kommer att ha en hot version och en arkiverad version. Den heta versionen kommer att innehålla de senaste 24 timmarna och en uppdatering av den tabellen kommer att ske varje timme och kommer att vara mycket lättare. Varje dag kommer den aktuella tabellen att slås samman med den arkiverade tabellen och en kraftigare uppdatering av den tabellen kommer att ske. Och naturligtvis en VIEW ovanför dessa 2 som förenar dem så att användarna inte ens blir medvetna om detta.
• Har inte för mycket metadata (filer och partitioner) per tabell (se avsnittet ”Optimal filstorlek”).

Beräkna statistik

Statistik kommer att göra dina förfrågningar mycket effektivare, särskilt de som involverar mer än en tabell (joins). Därför bör du beräkna statistik för alla dina tabeller och upprätthålla ett arbetsflöde som håller dem uppdaterade med inkrementell statistik. För mer tekniska detaljer läs om Cloudera Impala Table and Column Statistics.

Optimal File Size – 256MB/File

TL;DR: Se till att du inte har för många små filer – det kommer att skada din katalogserver, uppdateringar och frågeprestanda väldigt mycket.

Vi märkte att vår Impala-katalogserver fortsätter att krascha fyra gånger i veckan och att våra frågor tog för lång tid. Sedan insåg vi att vi har alldeles för många filer och partitioner. Vi arbetade med DT-partitioner varje timme, oavsett partitionernas storlek.

Så hade vi efter två år tabeller med 17 GB data och 17 000 partitioner – vilket innebär att varje partition är ungefär 1 mb. Vi hade tabeller med partitioner med en storlek på 50KB. Och som om det inte vore nog hade några av dessa små partitioner flera filer i dem.

I början trodde vi att denna orimliga mängd filer bara gör att våra metadata blir för stora och att det är därför som uppdateringarna är så tunga och katalogservern kraschar. Men sedan insåg vi att mängden filer också påverkar våra sökprestanda mycket negativt (på grund av antalet skannertrådar som krävs för att läsa så många parkettfiler).

Hur negativt? Vi utförde ett test på en verklig tabell på 500 MB som vi har, med 17 280(!) partitioner och filer. Vi skapade en ny sammanslagen version av denna tabell med endast 2 filer, 1 per år. SCAN HDFS-delen i sammanfattningen av frågeutförandet var 2 000 gånger snabbare. Det var den delen vi förstod precis hur mycket våra små filer skadar oss.

Så började vi hantera våra partitioner och slå ihop dem till den optimala filstorleken som är cirka 256mb.

Tabeller med en timvis partitionering blev dagligen, månadsvis eller årsvis partitionerade. Varje partition har bara 1 fil (om inte dess storlek är > 256mb)

Konfigurera koordinatorer &utförare per daemon

Sedan Impala 2.9 kan du bestämma vilka impala-demoner som är koordinatorer och vilka som är utförare. Det är en enorm förändring eftersom innan dess – alla daemoner var koordinatorer och utförare och overheadkostnaden för att vara en koordinator är mycket resurskrävande för stora kluster.

Det innebär till exempel att varje nod håller all metadatacache i sitt RAM-minne. Om du till exempel har 20 GB metadata och 50 noder innebär det ett slöseri med 1 TB RAM-minne bara för att alla noder också är koordinatorer!

Testa vad som är det bästa förhållandet mellan koordinatorer och utförare för dig och använd det. Tips: börja med 2 koordinatorer per kluster.

Kolumndatatyper

I början använde vi STRING för alla våra kolumner i alla tabeller. Det är ett riktigt dåligt tillvägagångssätt som skadade prestandan väldigt mycket. Du bör försöka välja den typ som passar kolumnen bäst av alla datatyper som Impala stöder.

Impala Query Limits

Du bör använda Impala Admission Control för att ställa in olika pooler för olika användargrupper för att begränsa vissa användares användning till X samtidiga sökningar eller Y minne. Men ännu mer än så – vi har byggt ett eget system för att hantera problematiska användare och frågor.

Vårt system samplar de för närvarande pågående frågorna var 10:e sekund och om en fråga körs i mer än 30 minuter – dödas den. Om samma förfrågningsmall dödades 90 % av gångerna förra månaden eftersom den tog mer än 30 minuter – kommer vårt system att döda den omedelbart när det känner igen mallen, för att skydda vår infrastruktur.

Döda frågor är inget nytt koncept – Amazon Athena har gjort det före oss, men döda frågor endast genom problematiska mönster – det är något som ingen annan gör och det är det enda sättet att hantera tusentals hungriga analytiker.

Sammanfattning

Om du behöver låta dina analytiker utföra ad-hoc, interaktiva SQL-förfrågningar över din Hadoop – är Impala en utmärkt lösning. Du bör läsa Cloudera Impala Guide för att bli en riktigt bra Impala-administratör och komma ihåg att arbeta efter de bästa metoderna som jag förklarade här.