Apache Impala: My Insights and Best Practices

Utilizăm Impala în câteva scopuri:

• Permiteți analiștilor să interogheze noi tipuri de date pentru care inginerii de date nu au creat încă niciun ETL.
• Să lăsăm analiștii să interogheze date a căror destinație finală (după procesul ETL) este HDFS.
• Generarea de rapoarte (cu propriile noastre instrumente).
• Monitorizarea & sistemelor de alertă (cu privire la datele noi care intră în fiecare oră).

Avem zeci de mii de interogări pe zi, fiecare interogare scanează în medie câțiva gigabytes de date și durează 10 secunde. Clusterul nostru nu este uriaș din punct de vedere hardware și al numărului de noduri pe care le avem. Ca să nu mai spunem că avem sute de alte fluxuri de lucru (Spark, Pig, Hive) care rulează în fiecare zi pe același cluster.

În acest articol voi împărtăși cunoștințele și concluziile pe care le-am învățat din proiectul nostru de optimizare Impala.

Ce este Impala?

Dacă nu știți ce este – citiți despre el în Ghidul Cloudera Impala și apoi reveniți aici pentru lucrurile interesante.

Impala vs. alte soluții SQL-on-Hadoop

Nu este nimic de comparat aici. În aceste zile, Hive este doar pentru ETL-uri și procesare pe loturi. Analiștii dvs. își vor primi răspunsul mult mai repede folosind Impala, deși, spre deosebire de Hive, Impala nu este tolerantă la erori. Dar asta este în regulă pentru un motor MPP (Massive Parallel Processing).

Impala este mai rapid decât Hive pentru că este un motor complet diferit, iar Hive este peste MapReduce (care este foarte lent din cauza prea multor operații de I/O pe disc).

Impala Vs. SparkSQL

Da, SparkSQL este mult mai rapid decât Hive, mai ales dacă efectuează doar calcule în memorie, dar Impala este totuși mai rapid decât SparkSQL.

Este mai rapid pentru că Impala este un motor conceput special pentru misiunea de SQL interactiv peste HDFS și are concepte de arhitectură care îl ajută să realizeze acest lucru. De exemplu, demonii Impala „always-on” sunt activi și așteaptă interogări 24 de ore din 24, 7 zile din 7 – lucru care nu face parte din SparkSQL. Și alte câteva motive, cum ar fi mecanismul Codegen al lui Impala, optimizarea formatului Parquet, statisticile, cache-ul de metadate, etc.

Serverul JDBC/ODBC Thrift al SparkSQL ar putea fi un concurent comparabil cu Impala, dar din moment ce nu am putut găsi prea multe despre el pe web – îl voi declara doar aici și dacă aveți cunoștințe și experiență pe acest subiect, vă rog să scrieți un post mediu despre el. S-ar putea să scriu unul în viitorul apropiat.

Impala Vs. Presto

Presto este o tehnologie foarte asemănătoare cu o arhitectură similară. Conform aproape fiecărui benchmark de pe web – Impala este mai rapid decât Presto, dar Presto este mult mai ușor de conectat decât Impala. Impala presupune că este mai rapid atunci când aveți nevoie de SQL peste Hadoop, dar dacă aveți nevoie să interogați mai multe surse de date cu același motor de interogare – Presto este mai bun decât Impala. Consultați această listă de conectori Presto. Impala poate, de asemenea, să interogheze Amazon S3, Kudu, HBase și cam atât.

Pentru o lectură suplimentară despre Presto- aceasta este o recenzie completă a PrestoDB pe care am făcut-o.

Cele mai bune practici pentru Impala

Impala funcționează cel mai bine atunci când interoghează fișiere stocate în format Parquet. Întreaga tehnologie pe care se bazează Cloudera Impala provine din Whitepaper-ul Google Dremel și în acel document puteți găsi conceptul pe care se bazează Parquet. Așadar, nu uitați să nu interogați fișiere json, csv sau secvențiale – parchetându-vă fișierele înainte de a permite analiștilor să le interogheze.

Work With Partitions

Partiționați datele în funcție de interogările analiștilor dumneavoastră. Impala nu are indici, așa că aceasta este singura modalitate de a reduce cantitatea de date pe care o procesați în fiecare interogare. Noi folosim DT (data și ora) ca metodă principală de partiționare pentru majoritatea tabelelor noastre. Suprapartiționarea excesivă poate fi periculoasă (continuați să citiți pentru mai multe detalii).

Declarația REFRESH

Declarația REFRESH poate fi o operațiune costisitoare, mai ales dacă aveți mii de tabele cu date care se adaugă la ele în fiecare oră. Noi rulăm mai mult de 10.000 de reîmprospătări pe zi. Acestea sunt cele mai bune practici ale mele pentru reîmprospătări:

• De la Impala 2.7 puteți efectua o reîmprospătare pe o partiție specifică, utilizați acest lucru pentru a face instrucțiunea REFRESH mult mai ușoară.
• Arhitectura tabelelor fierbinți & Arhivate – fiecare tabel va avea o versiune fierbinte și o versiune arhivată. Versiunea fierbinte va reține ultimele 24 de ore, iar o reîmprospătare a tabelului respectiv va avea loc la fiecare oră și va fi mult mai ușoară. În fiecare zi, tabelul fierbinte va fi fuzionat cu tabelul arhivat și va avea loc o reîmprospătare mai intensă a tabelului respectiv. Și, bineînțeles, un VIEW deasupra celor 2 care le unește, astfel încât utilizatorii nici măcar nu vor fi conștienți de acest lucru.
• Nu aveți prea multe metadate (fișiere și partiții) pe tabel (vezi secțiunea „Dimensiunea optimă a fișierului”).

Computeți statisticile

Statisticile vor face ca interogările să fie mult mai eficiente, în special cele care implică mai multe tabele (îmbinări). Prin urmare, ar trebui să calculați statisticile pentru toate tabelele dvs. și să mențineți un flux de lucru care să le actualizeze cu statistici incrementale. Pentru mai multe detalii tehnice, citiți despre Cloudera Impala Table and Column Statistics.

Optimal File Size – 256MB/File

TL;DR: Asigurați-vă că nu aveți prea multe fișiere mici – vă va afecta foarte rău serverul de catalog, actualizările și performanța interogărilor.

Am observat că serverul nostru de catalog Impala continuă să se blocheze de 4 ori pe săptămână și că interogările noastre luau prea mult timp. Apoi ne-am dat seama că avem mult prea multe fișiere și partiții. Lucram cu partiții DT în fiecare oră, indiferent de dimensiunea partițiilor.

În acest fel, după 2 ani, aveam tabele cu 17GB de date și 17.000 de partiții – ceea ce înseamnă că fiecare partiție este de aproximativ 1mb. Aveam tabele cu partiții la dimensiunea de 50KB. Și dacă asta nu era de ajuns, unele dintre aceste partiții mici aveau mai multe fișiere în ele.

La început ne-am gândit că această cantitate nerezonabilă de fișiere nu face decât să ne facă metadatele să fie prea mari și de aceea actualizările sunt atât de grele și serverul de catalog se blochează. Dar apoi ne-am dat seama că această cantitate de fișiere afectează, de asemenea, foarte rău performanța interogării noastre (din cauza numărului de fire de scanare necesare pentru a citi atât de multe fișiere de parchet).

Cât de rău? Am efectuat un test pe un tabel real de 500MB pe care îl avem, cu 17.280(!) partiții și fișiere. Am creat o nouă versiune fuzionată a acestui tabel cu doar 2 fișiere, câte unul pe an. Partea SCAN HDFS din rezumatul execuției interogării a fost de 2.000 de ori mai rapidă. Aceasta a fost partea din care am înțeles exact cât de mult ne afectează fișierele noastre mici.

Așa că am început să gestionăm partițiile noastre și să le fuzionăm în dimensiunea optimă a fișierelor, care este de aproximativ 256mb.

Tabelele cu o partiționare orară au devenit partiționate zilnic, lunar sau anual. Fiecare partiție are doar 1 singur fișier (cu excepția cazului în care dimensiunea sa este de > 256mb)

Configurați coordonatori & Executori per daemon

De la Impala 2.9 puteți determina ce daemoni impala sunt coordonatori și care sunt executori. Aceasta este o schimbare enormă, deoarece înainte de aceasta – toate demonii erau coordonatori și executanți, iar sarcina de a fi coordonator este foarte consumatoare de resurse pentru clusterele mari.

Înseamnă, de exemplu, că fiecare nod păstrează toată memoria cache de metadate în memoria sa RAM. Și dacă aveți, de exemplu, 20GB de metadate și 50 de noduri – asta înseamnă o risipă de 1TB de RAM doar pentru că toate nodurile sunt și coordonatori!

Testați care este cea mai bună rată de coordonatori/executori pentru dumneavoastră și folosiți-o. Sfat: începeți cu 2 coordonatori pe cluster.

Tipuri de date pentru coloane

La început am folosit STRING pentru toate coloanele noastre din toate tabelele. Este o practică foarte proastă care a afectat foarte mult performanța. Ar trebui să încercați să alegeți tipul cel mai potrivit pentru coloană dintre toate tipurile de date pe care Impala le acceptă.

Impala Query Limits

Ar trebui să utilizați Impala Admission Control pentru a seta diferite pool-uri pentru diferite grupuri de utilizatori pentru a limita utilizarea unor utilizatori la X interogări simultane sau Y memorie. Dar chiar mai mult decât atât – am construit propriul nostru sistem pentru a gestiona utilizatorii și interogările problematice.

Sistemul nostru eșantionează interogările care rulează în prezent la fiecare 10 secunde și dacă o interogare rulează mai mult de 30 de minute – aceasta este eliminată. Dacă același șablon de interogare a fost ucis de 90% din ori luna trecută pentru că a durat mai mult de 30 de minute – sistemul nostru îl va ucide imediat când recunoaște șablonul, pentru a ne proteja infrastructura.

Uciderea interogărilor nu este un concept nou – Amazon Athena a făcut acest lucru înaintea noastră, dar uciderea interogărilor numai în funcție de un model problematic – este ceva ce nimeni altcineva nu face și este singura modalitate de a face față la mii de analiști înfometați.

Rezumat

Dacă aveți nevoie să le permiteți analiștilor dvs. să efectueze interogări SQL ad-hoc, interactive pe Hadoop – Impala este o soluție excelentă. Ar trebui să citiți Ghidul Cloudera Impala pentru a deveni un foarte bun administrator Impala și nu uitați să lucrați după cele mai bune practici pe care le-am explicat aici.

.