Miten saimme Impalan toimimaan nopeammin?
Sinulla on siis Hadoop, sinne tulee teratavuja dataa päivässä, ETL:iä tehdään 24/7 Sparkilla, Hivellä tai – luoja paratkoon – Pigillä. Ja sitten kun data on täsmälleen haluamassasi muodossa (tai jopa ennen sitä) ja kaikki on täydellistä – analyytikot haluavat kysyä sitä. Jos valitsit Impalan tätä tehtävää varten, tämä artikkeli on sinulle.
Käytämme Impalaa muutamaan tarkoitukseen:
- Analyytikot voivat kysyä uudentyyppistä dataa, jolle data-insinöörit eivät ole vielä luoneet ETL:ää.
- Analyytikot voivat kysyä dataa, jonka lopullinen määränpää (ETL-prosessin jälkeen) on HDFS.
- Raporttien tuottaminen (omilla työkaluillamme).
- Valvonta &Hälytysjärjestelmiin (uuteen dataan, jota tulee joka tunti).
Meillä on kymmeniätuhansia kyselyjä päivässä, kukin kysely skannaa keskimäärin muutaman gigatavun datan ja kestää 10 sekuntia. Klusterimme ei ole valtava laitteiston ja solmujen määrän suhteen. Puhumattakaan siitä, että meillä on satoja muita työnkulkuja (Spark, Pig, Hive) käynnissä päivittäin samassa klusterissa.
Tässä artikkelissa jaan tietoa ja johtopäätöksiä, joita opimme Impala-optimointiprojektistamme.
Mikä on Impala?
Jos et tiedä, mikä se on – lue siitä Cloudera Impala Guide -oppaasta ja palaa sitten tänne mielenkiintoisten asioiden pariin.
Impala Vs. muut SQL-on-Hadoop-ratkaisut
Tässä ei ole mitään vertailtavaa. Hive on nykyään vain ETL:iä ja batch-prosessointia varten. Analyytikkosi saavat vastauksensa paljon nopeammin käyttämällä Impalaa, vaikka toisin kuin Hive, Impala ei ole vikasietoinen. Mutta se on ihan ok MPP-moottorille (Massive Parallel Processing).
Impala on nopeampi kuin Hive, koska se on täysin eri moottori ja Hive on yli MapReducen (joka on erittäin hidas liian monien levyn I/O-operaatioidensa takia).
Impala Vs. SparkSQL
Kyllä, SparkSQL on paljon nopeampi kuin Hive, varsinkin jos se suorittaa vain in-memory-laskentoja, mutta Impala on silti nopeampi kuin SparkSQL.
Se on nopeampi, koska Impala on moottori, joka on suunniteltu erityisesti interaktiivisen SQL:n tehtävään HDFS:n yli, ja sillä on arkkitehtuurikonsepteja, jotka auttavat sitä saavuttamaan sen. Esimerkiksi Impalan ”always-on”-demonit ovat ylhäällä ja odottavat kyselyjä 24/7 – jotain, mikä ei ole osa SparkSQL:ää. Ja joitakin muita syitä, kuten Impalan codegen-mekanismi, Parquet-formaatin optimointi, tilastot, metatietovälimuisti jne.
SparkSQL:n JDBC/ODBC Thrift Server voi olla vertailukelpoinen kilpailija Impalalle, mutta koska en löytänyt siitä paljoakaan verkosta – totean sen vain tässä, ja jos teillä on tietoa ja kokemusta aiheesta, kirjoittakaa mediassa viestiä siitä. Saatan kirjoittaa sellaisen lähitulevaisuudessa.
Impala Vs. Presto
Presto on hyvin samankaltainen teknologia, jolla on samanlainen arkkitehtuuri. Lähes jokaisen netissä olevan benchmarkin mukaan – Impala on nopeampi kuin Presto, mutta Presto on paljon liitettävämpi kuin Impala. Impalan oletetaan olevan nopeampi, kun tarvitset SQL:ää Hadoopin yli, mutta jos haluat kysyä useita tietolähteitä samalla kyselymoottorilla – Presto on Impalaa parempi. Katso tämä luettelo Presto-liitännöistä. Impala voi myös tehdä kyselyjä Amazon S3:lle, Kudulle, HBaselle ja siinä se periaatteessa onkin.
Lisälukemista Prestosta löytyy tästä tekemästäni PrestoDB:n täydellisestä arvostelusta.
Impalan parhaat käytännöt
Impala suoriutuu parhaiten, kun se tekee kyselyjä tiedostoille, jotka on tallennettu Parquet-muodossa. Koko teknologia, johon Cloudera Impala perustuu, on peräisin Googlen Dremel Whitepaperista ja tuosta paperista löytyy käsite, johon Parquet perustuu. Muista siis olla tekemättä kyselyjä json-, csv- tai sekvenssitiedostoista – parketoi tiedostosi ennen kuin annat analyytikoiden tehdä kyselyjä.
Työskentele partitioiden kanssa
Partitioi datasi analyytikoiden kyselyiden mukaan. Impalassa ei ole indeksejä, joten se on ainoa tapa vähentää kussakin kyselyssä käsiteltävän datan määrää. Käytämme DT:tä (päivämääräaika) pääasiallisena osiointimenetelmänä useimmissa taulukoissamme. Liiallinen osiointi voi olla vaarallista (lue lisää).
The REFRESH Statement
The REFRESH statement can be an expensive operation, especially if you have thousands of tables with data adding to them every hour. Me suoritamme yli 10 000 päivitystä päivässä. Nämä ovat parhaita käytäntöjäni päivityksiä varten:
- Imalan 2.7:stä lähtien voit suorittaa päivityksen tietylle osiolle, käytä sitä REFRESH-lausekkeen tekemiseen paljon kevyemmäksi.
- Kuuma & Arkistoitujen taulujen arkkitehtuuri – jokaisella taululla on kuuma versio ja arkistoitu versio. Hot-versioon tallennetaan viimeiset 24 tuntia, ja kyseisen taulukon päivitys tapahtuu tunnin välein ja on paljon kevyempi. Joka päivä kuuma taulukko yhdistetään arkistoituun taulukkoon, ja kyseisen taulukon päivitys on raskaampi. Ja tietenkin VIEW noiden 2:n yläpuolella, joka yhdistää ne, joten käyttäjät eivät edes huomaa tätä.
- Ei saa olla liikaa metadataa (tiedostoja ja osioita) per taulukko (katso kohta ’Optimaalinen tiedostokoko’).
Laskekaa tilastoja
Tilastot tekevät kyselyistäsi paljon tehokkaampia, erityisesti niistä, joissa on mukana useampi kuin yksi taulukko (joins). Siksi sinun tulisi laskea tilastot kaikille taulukoillesi ja ylläpitää työnkulkua, joka pitää ne ajan tasalla inkrementaalisilla tilastoilla. Lisätietoja teknisistä yksityiskohdista saat lukemalla Cloudera Impala Table and Column Statistics.
Optimaalinen tiedostokoko – 256MB/File
TL;DR: Varmista, että sinulla ei ole liian pieniä tiedostoja – se vahingoittaa katalogipalvelintasi, päivityksiä ja kyselyiden suorituskykyä todella pahasti.
Huomioimme, että Impala-katalogipalvelimemme kaatuilee jatkuvasti 4 kertaa viikossa ja että kyselyt veivät liikaa aikaa. Sitten tajusimme, että meillä on aivan liikaa tiedostoja ja osioita. Työskentelimme DT-partitioiden kanssa tunneittain riippumatta partitioiden koosta.
Siten meillä oli kahden vuoden jälkeen taulukoita, joissa oli 17 Gt dataa ja 17 000 partitiota – mikä tarkoittaa, että jokainen partitio on noin 1 Mt. Meillä oli taulukoita, joiden osioiden koko oli 50KB. Ja jos tämä ei vielä riitä, joissakin näistä pienistä osioista oli useita tiedostoja.
Aluksi ajattelimme, että tämä kohtuuton määrä tiedostoja aiheuttaa vain sen, että metatietomme ovat liian suuria ja siksi päivitykset ovat niin raskaita ja luettelopalvelin kaatuu. Mutta sitten tajusimme, että tiedostojen määrä vaikuttaa myös kyselymme suorituskykyyn erittäin huonosti (koska niin monen parkettitiedoston lukemiseen tarvittavien skannerisäikeiden määrä).
Miten huonosti? Teimme testin todellisella 500MB:n taulullamme, jossa oli 17 280(!) osiota ja tiedostoa. Loimme uuden yhdistetyn version tästä taulukosta, jossa oli vain 2 tiedostoa, 1 per vuosi. SCAN HDFS -osio kyselyn suoritusyhteenvedossa oli 2 000 kertaa nopeampi. Tuossa osassa ymmärsimme juuri sen, kuinka paljon pienet tiedostomme vahingoittavat meitä.
Siten aloimme hallita osioitamme ja yhdistää ne optimaaliseen tiedostokokoon, joka on noin 256 Mt.
Taulukot, joissa oli tuntikohtainen osiointi, muuttuivat päivittäisiksi, kuukausittaisiksi tai vuosittaisiksi osioiksi. Jokaisella osiolla on vain 1 tiedosto (ellei sen koko ole > 256mb)
Configure Coordinators & Executors Per Daemon
Impala 2.9:stä lähtien voit määritellä, mitkä impala-daemonit ovat koordinaattoreita ja mitkä toteuttajia. Se on valtava muutos, koska ennen sitä – kaikki daemonit olivat koordinaattoreita ja toteuttajia ja koordinaattorina olemisen yleiskustannus on hyvin resursseja vievää suurissa klustereissa.
Se tarkoittaa esimerkiksi sitä, että jokainen solmu pitää kaiken metadatan välimuistin RAM-muistissaan. Ja jos sinulla on esimerkiksi 20GB metadataa ja 50 solmua – se tarkoittaa 1TB:n RAM-muistin tuhlausta vain siksi, että kaikki solmut ovat myös koordinaattoreita!
Testaa, mikä on paras koordinaattorien/suorittajien osuus sinulle ja käytä sitä. Vinkki: aloita 2 koordinaattorilla per klusteri.
Sarakkeiden tietotyypit
Aluksi käytimme STRING-merkintää kaikissa sarakkeissamme kaikissa taulukoissa. Se on todella huono käytäntö, joka haittasi suorituskykyä erittäin paljon. Kannattaa yrittää valita sarakkeelle sopivin tyyppi kaikista Impalan tukemista tietotyypeistä.
Impala Query Limits
Sinun kannattaa käyttää Impala Admission Controlia asettaaksesi eri poolit eri käyttäjäryhmille rajoittaaksesi joidenkin käyttäjien käyttöä X samanaikaiseen kyselyyn tai Y muistiin. Mutta vielä enemmän – olemme rakentaneet oman järjestelmämme käsittelemään ongelmallisia käyttäjiä ja kyselyitä.
Järjestelmämme ottaa näytteitä parhaillaan käynnissä olevista kyselyistä 10 sekunnin välein ja jos kysely on käynnissä yli 30 minuuttia – se tapetaan. Jos sama kyselymalli tapettiin 90 % kertaa viime kuussa, koska se kesti yli 30 minuuttia – järjestelmämme tappaa sen välittömästi, kun se tunnistaa mallin, suojellakseen infrastruktuuria.
Kyselyjen tappaminen ei ole uusi konsepti – Amazon Athena on tehnyt sen ennen meitä, mutta kyselyjen tappaminen vain ongelmallisen mallin mukaan – sitä ei tee kukaan muu, ja se on ainoa tapa käsitellä tuhansia nälkäisiä analyytikoita.
Yhteenveto
Jos haluat antaa analyytikkojesi tehdä ad-hoc-luonteisia, vuorovaikutteisia SQL-kyselyjä Hadoop-tietokannassasi – Impala on loistava ratkaisu. Sinun kannattaa lukea Clouderan Impala-opas, jotta sinusta tulee todella hyvä Impalan ylläpitäjä, ja muistaa toimia tässä selostamieni parhaiden käytäntöjen mukaan.