Hoe hebben we onze Impala sneller laten draaien?
Dus je hebt je Hadoop, er komen terabytes aan data per dag in, ETL’s worden 24/7 gedaan met Spark, Hive of god verhoede – Pig. En nadat de gegevens precies in de gewenste vorm zijn gegoten (of zelfs daarvoor) en alles perfect is, willen analisten er query’s van maken. Als u Impala voor die missie hebt gekozen, is dit artikel voor u.
We gebruiken Impala voor een paar doeleinden:
- Laat analisten nieuwe gegevenstypen bevragen waar de data-engineers nog geen ETL’s op hebben gemaakt.
- Analisten data laten bevragen waarvan de eindbestemming (na het ETL-proces) HDFS is.
- Rapportgeneratie (met onze eigen tools).
- Monitoring &waarschuwingssystemen (op nieuwe data die elk uur binnenkomt).
We hebben tienduizenden query’s per dag, elke query scant gemiddeld een paar gigabyte aan data en duurt 10 seconden. Ons cluster is niet groot in termen van hardware en het aantal nodes dat we hebben. En dan hebben we nog honderden andere workflows (Spark, Pig, Hive) die elke dag op hetzelfde cluster draaien.
In dit artikel deel ik de kennis en conclusies die we hebben geleerd van ons Impala optimalisatieproject.
Wat is Impala?
Als u niet weet wat het is – lees erover in de Cloudera Impala Guide, en kom dan hier terug voor de interessante dingen.
Impala Vs. Other SQL-on-Hadoop Solutions
Er valt hier niets te vergelijken. Tegenwoordig is Hive alleen voor ETL’s en batch-verwerking. Uw analisten zullen hun antwoord veel sneller krijgen met Impala, hoewel Impala in tegenstelling tot Hive geen fouttolerantie heeft. Maar dat is niet erg voor een MPP (Massive Parallel Processing) engine.
Impala is sneller dan Hive omdat het een heel andere engine is en Hive is over MapReduce (die erg traag is door zijn te veel disk I/O operaties).
Impala Vs. SparkSQL
Ja, SparkSQL is veel sneller dan Hive, vooral als het alleen in-memory berekeningen uitvoert, maar Impala is nog steeds sneller dan SparkSQL.
Het is sneller omdat Impala een engine is die speciaal is ontworpen voor de missie van interactieve SQL over HDFS, en het heeft architectuur concepten die het helpen dat te bereiken. Bijvoorbeeld de Impala ‘always-on’ daemons zijn 24/7 in de lucht en wachten op queries – iets dat geen onderdeel is van SparkSQL. En nog wat redenen zoals Impala’s codegen mechanisme, de Parquet formaat optimalisatie, statistieken, metadata cache, etc.
De JDBC/ODBC Thrift Server van SparkSQL is misschien een vergelijkbare concurrent voor Impala, maar omdat ik er niet veel over kon vinden op het web – zal ik het hier maar vermelden en als je enige kennis en ervaring hebt over dit onderwerp, schrijf er dan alsjeblieft een medium post over. Ik schrijf er misschien een in de nabije toekomst.
Impala Vs. Presto
Presto is een zeer vergelijkbare technologie met een vergelijkbare architectuur. Volgens bijna elke benchmark op het web – is Impala sneller dan Presto, maar Presto is veel meer pluggable dan Impala. Impala veronderstelt sneller te zijn als je SQL over Hadoop nodig hebt, maar als je meerdere databronnen moet bevragen met dezelfde query engine – is Presto beter dan Impala. Zie gewoon deze lijst van Presto Connectors. Impala kan ook query’s uitvoeren op Amazon S3, Kudu, HBase en dat is het eigenlijk.
Voor verder lezen over Presto- dit is een PrestoDB volledige review die ik heb gemaakt.
Impala Best Practices
Impala presteert het beste wanneer het query’s uitvoert op bestanden die zijn opgeslagen als Parquet-formaat. De hele technologie waar Cloudera Impala op is gebaseerd komt uit de Google Dremel Whitepaper en in die paper kun je het concept vinden waar Parquet op is gebaseerd. Denk er dus aan dat u geen query’s uitvoert op json-, csv- of sequentiebestanden – parqueteer uw bestanden voordat u ze door analisten laat bevragen.
Werken met partities
Partitioneer uw gegevens op basis van de query’s van uw analisten. Impala heeft geen indexen, dus dat is de enige manier om de hoeveelheid gegevens die u in elke query verwerkt, te verminderen. Wij gebruiken DT (datum tijd) als de belangrijkste partitioneringsmethode voor de meeste van onze tabellen. Over partitioneren kan gevaarlijk zijn (lees verder voor meer details).
Het REFRESH Statement
Het REFRESH statement kan een dure operatie zijn, vooral als je duizenden tabellen hebt waar elk uur data aan toegevoegd wordt. Wij voeren meer dan 10.000 verversingen per dag uit. Dit zijn mijn best practices voor refreshes:
- Sinds Impala 2.7 kun je een refresh uitvoeren op een specifieke partitie, gebruik dat om het REFRESH statement veel lichter te maken.
- Hot & Archived tables architecture – elke tabel zal een hot versie en een gearchiveerde versie hebben. De hot versie zal de laatste 24 uur bevatten en een refresh op die tabel zal elk uur plaatsvinden en zal veel lichter zijn. Elke dag zal de “hot” tabel samengevoegd worden met de gearchiveerde tabel en zal er een zwaardere refresh over die tabel gebeuren. En natuurlijk een VIEW boven die 2 die ze verenigt zodat de gebruikers zich hier niet eens bewust van zullen zijn.
- Zorg voor niet te veel metadata (bestanden en partities) per tabel (zie de sectie ‘Optimale bestandsgrootte’).
Compute Stats
Statistieken zullen uw queries veel efficiënter maken, vooral die waarbij meer dan één tabel betrokken is (joins). Daarom moet u statistieken berekenen voor al uw tabellen en een workflow onderhouden die ze up-to-date houdt met incrementele statistieken. Lees voor meer technische details over Cloudera Impala Tabel- en kolomstatistieken.
Optimale bestandsgrootte – 256MB/Bestand
TL;DR: Zorg ervoor dat u niet te veel kleine bestanden hebt – het zal uw catalogusserver, refreshes en queryprestaties echt slecht schaden.
We merkten dat onze Impala-catalogusserver 4 keer per week bleef crashen en dat onze query’s te veel tijd kostten. Toen realiseerden we ons dat we veel te veel bestanden en partities hebben. We werkten met DT partities op uurbasis, ongeacht de grootte van de partities.
Op die manier hadden we na 2 jaar tabellen met 17GB aan data en 17.000 partities – wat betekent dat elke partitie ongeveer 1mb is. We hadden tabellen met partities ter grootte van 50KB. En alsof dat nog niet genoeg was, hadden sommige van die kleine partities meerdere bestanden erin.
In het begin dachten we dat deze onredelijke hoeveelheid bestanden er alleen maar voor zorgde dat onze metadata te groot werd en dat daarom de verversingen zo zwaar waren en de catalogusserver vastliep. Maar toen realiseerden we ons dat de hoeveelheid bestanden ook een slechte invloed heeft op onze query performance (door het aantal scanner threads dat nodig is om zoveel parket bestanden te lezen).
Hoe slecht? We hebben een test uitgevoerd op een echte 500MB tabel die we hebben, met 17.280(!) partities en bestanden. We hebben een nieuwe samengevoegde versie van deze tabel gemaakt met slechts 2 bestanden, 1 per jaar. Het SCAN HDFS gedeelte in de samenvatting van de query uitvoering was 2.000 keer sneller. Dat was het deel dat we begrepen hoezeer onze kleine bestanden ons pijn doen.
Dus begonnen we onze partities te beheren en samen te voegen tot de optimale bestandsgrootte die ongeveer 256mb is.
Tabellen met een uurpartitie werden dagelijks, maandelijks of jaarlijks gepartitioneerd. Elke partitie heeft slechts 1 bestand (tenzij de grootte > 256mb is)
Configure Coordinators & Executors Per Daemon
Sinds Impala 2.9 kunt u bepalen welke impala daemons coördinators zijn en welke executors. Dat is een enorme verandering, want daarvoor – waren alle daemons coördinatoren en uitvoerders en de overhead van het zijn van een coördinator is zeer resource consuming voor grote clusters.
Het betekent bijvoorbeeld dat elke node alle metadata cache in zijn RAM bewaart. En als je bijvoorbeeld 20GB metadata hebt en 50 nodes – dat betekent een verspilling van 1TB RAM alleen maar omdat alle nodes ook coördinator zijn!
Probeer wat voor jou de beste coördinator/uitvoerder verhouding is en gebruik het. Tip: begin met 2 coordinatoren per cluster.
Kolom Data Types
In het begin gebruikten we STRING voor al onze kolommen in alle tabellen. Dit is een zeer slechte praktijk die de prestaties zeer veel schaadt. U moet proberen om het meest geschikte type te kiezen voor de kolom uit alle datatypes die Impala ondersteunt.
Impala Query Limits
U moet de Impala Admission Control gebruiken om verschillende pools in te stellen voor verschillende groepen gebruikers om het gebruik van sommige gebruikers te beperken tot X gelijktijdige query’s of Y geheugen. Maar zelfs meer dan dat – we hebben ons eigen systeem gebouwd om problematische gebruikers en query’s te behandelen.
Ons systeem bemonstert de momenteel lopende query’s elke 10 seconden en als een query langer dan 30 minuten loopt – wordt deze gedood. Als dezelfde query sjabloon vorige maand 90% van de keren werd gedood omdat het meer dan 30 minuten duurde – zal ons systeem het onmiddellijk doden wanneer het de sjabloon herkent, om onze infrastructuur te beschermen.
Het doden van query’s is geen nieuw concept – Amazon Athena heeft dat voor ons gedaan, maar dood query’s alleen op basis van problematisch patroon – dat is iets wat niemand anders doet en dat is de enige manier om duizenden hongerige analisten aan te kunnen.
Samenvatting
Als u uw analisten ad-hoc, interactieve SQL-query’s over uw Hadoop moet laten uitvoeren – Impala is een geweldige oplossing. U moet de Cloudera Impala-gids lezen om een echt goede Impala-beheerder te worden en niet vergeten te werken volgens de best practices die ik hier heb uitgelegd.