Come abbiamo reso il nostro Impala più veloce?
Allora avete il vostro Hadoop, terabyte di dati ci entrano ogni giorno, gli ETL sono fatti 24/7 con Spark, Hive o Dio non voglia – Pig. E poi, dopo che i dati sono nella forma esatta che vuoi (o anche prima) e tutto è perfetto, gli analisti vogliono interrogarli. Se hai scelto Impala per questa missione, questo articolo è per te.
Utiamo Impala per alcuni scopi:
- Lasciare che gli analisti interroghino nuovi tipi di dati su cui gli ingegneri dei dati non hanno ancora creato alcun ETL.
- Lasciare che gli analisti interroghino i dati la cui destinazione finale (dopo il processo ETL) è HDFS.
- Generazione di report (con i nostri strumenti).
- Monitoraggio dei sistemi di allarme & (sui nuovi dati che arrivano ogni ora).
Abbiamo decine di migliaia di query al giorno, ogni query analizza in media qualche gigabyte di dati e impiega 10 secondi. Il nostro cluster non è enorme in termini di hardware e numero di nodi che abbiamo. Senza contare che abbiamo centinaia di altri flussi di lavoro (Spark, Pig, Hive) in esecuzione ogni giorno sullo stesso cluster.
In questo articolo condividerò le conoscenze e le conclusioni che abbiamo imparato dal nostro progetto di ottimizzazione Impala.
Che cos’è Impala?
Se non sai cos’è – leggilo nella Guida Cloudera Impala, e poi torna qui per le cose interessanti.
Impala Vs. Altre Soluzioni SQL-on-Hadoop
Non c’è niente da confrontare qui. Al giorno d’oggi, Hive è solo per ETL ed elaborazione batch. I vostri analisti otterranno la loro risposta molto più velocemente usando Impala, anche se, a differenza di Hive, Impala non è fault-tolerance. Ma questo va bene per un motore MPP (Massive Parallel Processing).
Impala è più veloce di Hive perché è un motore completamente diverso e Hive è sopra MapReduce (che è molto lento a causa delle sue troppe operazioni I/O su disco).
Impala Vs. SparkSQL
Sì, SparkSQL è molto più veloce di Hive, specialmente se esegue solo calcoli in-memoria, ma Impala è ancora più veloce di SparkSQL.
È più veloce perché Impala è un motore progettato appositamente per la missione di SQL interattivo su HDFS, e ha concetti di architettura che lo aiutano a raggiungere questo obiettivo. Per esempio i demoni ‘always-on’ di Impala sono attivi e in attesa di query 24/7 – qualcosa che non fa parte di SparkSQL. E alcune altre ragioni come il meccanismo di codegen di Impala, l’ottimizzazione del formato Parquet, le statistiche, la cache dei metadati, ecc.
Il JDBC/ODBC Thrift Server di SparkSQL potrebbe essere un concorrente paragonabile a Impala, ma poiché non sono riuscito a trovare molto su di esso sul web – lo dichiarerò qui e se hai qualche conoscenza ed esperienza su questo argomento per favore scrivi un post medio su di esso. Potrei scriverne uno nel prossimo futuro.
Impala Vs. Presto
Presto è una tecnologia molto simile con un’architettura simile. Secondo quasi tutti i benchmark sul web – Impala è più veloce di Presto, ma Presto è molto più collegabile di Impala. Impala suppone di essere più veloce quando hai bisogno di SQL su Hadoop, ma se hai bisogno di interrogare più fonti di dati con lo stesso motore di query – Presto è meglio di Impala. Basta vedere questa lista di Connettori Presto. Impala può anche interrogare Amazon S3, Kudu, HBase e questo è fondamentalmente tutto.
Per ulteriori letture su Presto- questa è una recensione completa di PrestoDB che ho fatto.
Impala Best Practices
Impala funziona meglio quando interroga i file memorizzati come formato Parquet. L’intera tecnologia su cui si basa Cloudera Impala proviene dal Google Dremel Whitepaper e in quel documento si può trovare il concetto su cui si basa Parquet. Quindi ricordati di non interrogare file json, csv o sequenze – parcheggia i tuoi file prima di lasciare che gli analisti li interroghino.
Lavora con le partizioni
Partiziona i tuoi dati secondo le richieste dei tuoi analisti. Impala non ha indici, quindi questo è l’unico modo per ridurre la quantità di dati che elaborate in ogni query. Usiamo DT (date time) come metodo di partizionamento principale per la maggior parte delle nostre tabelle. Il partizionamento eccessivo può essere pericoloso (continua a leggere per maggiori dettagli).
La dichiarazione REFRESH
La dichiarazione REFRESH può essere un’operazione costosa, specialmente se hai migliaia di tabelle con dati che si aggiungono ad esse ogni ora. Noi eseguiamo più di 10.000 refresh al giorno. Queste sono le mie migliori pratiche per i refresh:
- Da Impala 2.7 puoi eseguire un refresh su una partizione specifica, usalo per rendere l’istruzione REFRESH molto più leggera.
- Architettura delle tabelle calde & archiviate – ogni tabella avrà una versione calda e una versione archiviata. La versione a caldo conterrà le ultime 24 ore e un refresh su quella tabella avverrà ogni ora e sarà molto più leggero. Ogni giorno la tabella calda sarà unita alla tabella archiviata e si verificherà un refresh più pesante su quella tabella. E naturalmente una VIEW sopra quelle 2 che le unisce, così gli utenti non se ne accorgeranno nemmeno.
- Non avere troppi metadati (file e partizioni) per tabella (vedi la sezione ‘Dimensione ottimale del file’).
Computa le statistiche
Le statistiche renderanno le tue query molto più efficienti, specialmente quelle che coinvolgono più di una tabella (join). Pertanto dovresti calcolare le statistiche per tutte le tue tabelle e mantenere un flusso di lavoro che le tenga aggiornate con statistiche incrementali. Per maggiori dettagli tecnici leggi Cloudera Impala Table and Column Statistics.
Dimensione ottimale dei file – 256MB/File
TL;DR: Assicurati di non avere troppi file piccoli – farà male al tuo server di catalogo, ai refresh e alle prestazioni delle query davvero male.
Abbiamo notato che il nostro server di catalogo Impala va in crash 4 volte a settimana e che le nostre query richiedono troppo tempo. Poi ci siamo resi conto che abbiamo troppi file e partizioni. Stavamo lavorando con le partizioni DT su base oraria, indipendentemente dalla dimensione delle partizioni.
In questo modo dopo 2 anni avevamo tabelle con 17GB di dati e 17.000 partizioni – il che significa che ogni partizione è circa 1mb. Avevamo tabelle con partizioni della dimensione di 50KB. E come se non bastasse, alcune di quelle piccole partizioni avevano più file al loro interno.
All’inizio abbiamo pensato che questa quantità irragionevole di file sta solo causando i nostri metadati troppo grandi ed è per questo che i refresh sono così pesanti e il server di catalogo va in crash. Ma poi ci siamo resi conto che la quantità di file influisce anche molto negativamente sulle prestazioni delle nostre query (a causa del numero di thread di scansione necessari per leggere così tanti file di parquet).
Quanto negativamente? Abbiamo fatto un test su una tabella reale di 500MB che abbiamo, con 17.280(!) partizioni e file. Abbiamo creato una nuova versione fusa di questa tabella con solo 2 file, 1 per anno. La parte di SCAN HDFS nel riepilogo dell’esecuzione della query era 2.000 volte più veloce. Questa è stata la parte in cui abbiamo capito quanto i nostri piccoli file ci stiano danneggiando.
Allora abbiamo iniziato a gestire le nostre partizioni e a fonderle nella dimensione ottimale dei file che è di circa 256mb.
Le tabelle con un partizionamento orario sono diventate partizionate giornalmente, mensilmente o annualmente. Ogni partizione ha solo 1 file (a meno che la sua dimensione sia > 256mb)
Configura i coordinatori &esecutori per demone
Da Impala 2.9 è possibile determinare quali demoni impala sono coordinatori e quali sono esecutori. Questo è un enorme cambiamento perché prima – tutti i demoni erano coordinatori ed esecutori e l’overhead di essere un coordinatore è molto dispendioso per i grandi cluster.
Significa per esempio che ogni nodo mantiene tutta la cache dei metadati nella sua RAM. E se hai per esempio 20GB di metadati e 50 nodi – questo significa uno spreco di 1TB di RAM solo perché tutti i nodi sono anche coordinatori!
Testa qual è il miglior tasso di coordinatori/esecutori per te e usalo. Suggerimento: inizia con 2 coordinatori per cluster.
Tipi di dati delle colonne
All’inizio abbiamo usato STRING per tutte le nostre colonne in tutte le tabelle. È una pratica davvero cattiva che danneggia molto le prestazioni. Dovresti provare a scegliere il tipo più adatto alla colonna tra tutti i tipi di dati che Impala supporta.
Impala Query Limits
Dovresti usare Impala Admission Control per impostare diversi pool per diversi gruppi di utenti al fine di limitare l’uso di alcuni utenti a X query concorrenti o Y memoria. Ma ancora di più – abbiamo costruito il nostro sistema per gestire utenti e query problematiche.
Il nostro sistema campiona le query in esecuzione ogni 10 secondi e se una query è in esecuzione da più di 30 minuti – viene uccisa. Se lo stesso modello di query è stato ucciso il 90% delle volte il mese scorso perché ha richiesto più di 30 minuti – il nostro sistema lo ucciderà immediatamente quando riconoscerà il modello, al fine di proteggere la nostra infrastruttura.
Uccidere le query non è un concetto nuovo – Amazon Athena lo ha fatto prima di noi, ma uccidere le query solo per modello problematico – è qualcosa che nessun altro fa ed è l’unico modo per gestire migliaia di analisti affamati.
Sommario
Se avete bisogno di permettere ai vostri analisti di eseguire query SQL ad-hoc e interattive sul vostro Hadoop – Impala è una grande soluzione. Dovresti leggere la Guida Cloudera Impala per diventare un ottimo amministratore di Impala e ricordarti di lavorare secondo le migliori pratiche che ho spiegato qui.