Kenning og framkvæmd um notkun ClickHouse í raunverulegum forritum. Alexander Zaitsev (2018)

Þrátt fyrir þá staðreynd að það er nú mikið af gögnum nánast alls staðar, eru greiningargagnagrunnar enn frekar framandi. Þeir eru illa þekktir og enn verri færir um að nota þá á áhrifaríkan hátt. Margir halda áfram að „borða kaktus“ með MySQL eða PostgreSQL, sem eru hönnuð fyrir aðrar aðstæður, þjást af NoSQL eða ofborga fyrir viðskiptalausnir. ClickHouse breytir leikreglunum og lækkar verulega þröskuldinn til að komast inn í heim greinandi DBMS.

Skýrsla frá BackEnd Conf 2018 og hún er birt með leyfi ræðumanns.

Hver er ég og hvers vegna er ég að tala um ClickHouse? Ég er þróunarstjóri hjá LifeStreet, sem notar ClickHouse. Einnig er ég stofnandi Altinity. Það er Yandex samstarfsaðili sem kynnir ClickHouse og hjálpar Yandex að gera ClickHouse farsælli. Einnig tilbúinn til að deila þekkingu um ClickHouse.

Og ég er heldur ekki bróðir Petya Zaitsev. Ég er oft spurður um þetta. Nei, við erum ekki bræður.

„Allir vita“ að ClickHouse:

• Mjög hratt,
• Mjög þægilegt,
• Notað í Yandex.

Aðeins minna er vitað í hvaða fyrirtækjum og hvernig það er notað.

Ég mun segja þér hvers vegna, hvar og hvernig ClickHouse er notað, nema fyrir Yandex.

Ég mun segja þér hvernig ákveðin verkefni eru leyst með hjálp ClickHouse í mismunandi fyrirtækjum, hvaða ClickHouse tól þú getur notað fyrir verkefni þín og hvernig þau voru notuð í mismunandi fyrirtækjum.

Ég tók upp þrjú dæmi sem sýna ClickHouse frá mismunandi sjónarhornum. Ég held að það verði áhugavert.

Fyrsta spurningin er: "Af hverju þurfum við ClickHouse?". Það virðist vera nokkuð augljós spurning, en við henni eru fleiri en eitt svar.

• Fyrsta svarið er fyrir frammistöðu. ClickHouse er mjög hratt. Greining á ClickHouse er líka mjög hröð. Það er oft hægt að nota það þar sem eitthvað annað er mjög hægt eða mjög slæmt.
• Annað svarið er kostnaður. Og fyrst af öllu, kostnaður við stigstærð. Til dæmis er Vertica alveg frábær gagnagrunnur. Það virkar mjög vel ef þú ert ekki með mikið af terabætum af gögnum. En þegar kemur að hundruðum terabæta eða petabæta fer kostnaðurinn við leyfi og stuðning í nokkuð verulegt magn. Og það er dýrt. Og ClickHouse er ókeypis.
• Þriðja svarið er rekstrarkostnaður. Þetta er aðeins önnur nálgun. RedShift er frábær hliðstæða. Á RedShift geturðu tekið ákvörðun mjög fljótt. Það mun virka vel, en á sama tíma, á klukkutíma fresti, á hverjum degi og í hverjum mánuði, muntu borga Amazon nokkuð dýrt, því þetta er verulega dýr þjónusta. Google BigQuery líka. Ef einhver notaði það, þá veit hann að þar er hægt að keyra nokkrar beiðnir og fá reikning upp á hundruð dollara allt í einu.

ClickHouse hefur ekki þessi vandamál.

Hvar er ClickHouse notað núna? Auk Yandex er ClickHouse notað í fullt af mismunandi fyrirtækjum og fyrirtækjum.

• Í fyrsta lagi er þetta vefforritsgreining, þ.e. þetta er notkunartilvik sem kom frá Yandex.
• Mörg AdTech fyrirtæki nota ClickHouse.
• Fjölmörg fyrirtæki sem þurfa að greina viðskiptaskrár frá mismunandi aðilum.
• Nokkur fyrirtæki nota ClickHouse til að fylgjast með öryggisskrám. Þeir hlaða þeim upp á ClickHouse, gera skýrslur og fá þær niðurstöður sem þeir þurfa.
• Fyrirtæki eru farin að nota það í fjármálagreiningu, þ.e.a.s. smám saman nálgast stór fyrirtæki líka ClickHouse.
• skýjablossi. Ef einhver fylgist með ClickHouse, þá hefur hann líklega heyrt nafnið á þessu fyrirtæki. Þetta er einn af mikilvægustu þátttakendum samfélagsins. Og þeir hafa mjög alvarlega ClickHouse uppsetningu. Til dæmis gerðu þeir Kafka Engine fyrir ClickHouse.
• Fjarskiptafyrirtæki fóru að nota. Nokkur fyrirtæki nota ClickHouse annað hvort sem sönnun á hugmynd eða þegar í framleiðslu.
• Eitt fyrirtæki notar ClickHouse til að fylgjast með framleiðsluferlum. Þeir prófa örrásir, afskrifa fullt af breytum, það eru um 2 einkenni. Og svo greina þeir hvort leikurinn sé góður eða slæmur.
• Blockchain greiningar. Það er svo rússneskt fyrirtæki eins og Bloxy.info. Þetta er greining á ethereum netinu. Þeir gerðu þetta líka á ClickHouse.

Og stærðin skiptir ekki máli. Það eru mörg fyrirtæki sem nota einn lítinn netþjón. Og hann leyfir þeim að leysa vandamál sín. Og jafnvel fleiri fyrirtæki nota stóra klasa af mörgum netþjónum eða tugum netþjóna.

Og ef þú skoðar skrárnar, þá:

• Yandex: 500+ netþjónar, þeir geyma 25 milljarða færslur á dag þar.
• LifeStreet: 60 netþjónar, um það bil 75 milljarðar færslur á dag. Það eru færri netþjónar, fleiri skrár en í Yandex.
• CloudFlare: 36 netþjónar, þeir spara 200 milljarða færslur á dag. Þeir hafa enn færri netþjóna og geyma enn fleiri gögn.
• Bloomberg: 102 netþjónar, um trilljón færslur á dag. Methafi.

Landfræðilega er þetta líka mikið. Þetta kort hér sýnir hitakort af því hvar ClickHouse er notað í heiminum. Rússland, Kína, Ameríka skera sig greinilega úr hér. Það eru fá Evrópulönd. Og það eru 4 klasar.

Þetta er samanburðargreining, það þarf ekki að leita að algildum tölum. Þetta er greining á gestum sem lesa enskumælandi efni á vefsíðu Altinity, því þar eru engir rússneskumælandi. Og Rússland, Úkraína, Hvíta-Rússland, þ.e.a.s. rússneskumælandi hluti samfélagsins, þetta eru fjölmargir notendur. Svo koma Bandaríkin og Kanada. Kína er mjög að ná sér á strik. Það var nánast ekkert Kína þar fyrir hálfu ári, nú hefur Kína þegar farið fram úr Evrópu og heldur áfram að vaxa. Gamla Evrópa er heldur ekki langt á eftir og leiðandi í notkun ClickHouse er, einkennilega nóg, Frakkland.

Af hverju er ég að segja þetta allt? Til að sýna að ClickHouse er að verða staðlað lausn fyrir stóra gagnagreiningu og er nú þegar notuð á mörgum stöðum. Ef þú notar það ertu í réttri þróun. Ef þú ert ekki að nota það ennþá, þá geturðu ekki verið hræddur um að þú verðir í friði og enginn muni hjálpa þér, því margir eru nú þegar að gera þetta.

Þetta eru dæmi um raunverulega ClickHouse notkun í nokkrum fyrirtækjum.

• Fyrsta dæmið er auglýsinganet: flutningur frá Vertica til ClickHouse. Og ég þekki nokkur fyrirtæki sem hafa skipt yfir frá Vertica eða eru í því að skipta.
• Annað dæmið er viðskiptageymsla á ClickHouse. Þetta er dæmi byggt á antipatterns. Allt sem ekki þarf að gera í ClickHouse samkvæmt ráðleggingum þróunaraðila er gert hér. Og á sama tíma er það gert svo áhrifaríkt að það virkar. Og það virkar miklu betur en dæmigerð viðskiptalausn.
• Þriðja dæmið er dreifð tölvumál á ClickHouse. Spurt var hvernig hægt er að samþætta ClickHouse inn í Hadoop vistkerfið. Ég mun sýna dæmi um hvernig fyrirtæki gerði eitthvað svipað og kortaminnkunarílát á ClickHouse, fylgdist með staðfærslu gagna osfrv., til að reikna út mjög léttvægt verkefni.

• LifeStreet er auglýsingatæknifyrirtæki sem hefur alla þá tækni sem fylgir auglýsinganeti.
• Hún fæst við hagræðingu auglýsinga, forritunartilboð.
• Fullt af gögnum: um 10 milljarðar atburða á dag. Jafnframt er hægt að skipta viðburðum þar í nokkra undirviðburði.
• Það eru margir viðskiptavinir þessara gagna, og þetta er ekki bara fólk, miklu meira - þetta eru ýmis reiknirit sem taka þátt í forritunartilboði.

Fyrirtækið er langt og þyrnum stráð. Og ég talaði um það á HighLoad. Í fyrsta lagi flutti LifeStreet frá MySQL (með stuttu stoppi hjá Oracle) til Vertica. Og þú getur fundið sögu um það.

Og allt var mjög gott, en það kom fljótt í ljós að gögnin eru að stækka og Vertica er dýrt. Því var leitað ýmissa kosta. Sum þeirra eru skráð hér. Og í raun gerðum við sönnun á hugmynd eða stundum frammistöðuprófun á næstum öllum gagnagrunnum sem voru fáanlegir á markaðnum frá 13. til 16. ári og voru um það bil hentugir hvað varðar virkni. Og ég talaði líka um sum þeirra á HighLoad.

Verkefnið var að flytja frá Vertica fyrst, vegna þess að gögnin voru að stækka. Og þeim fjölgaði mjög í nokkur ár. Síðan fóru þeir á hilluna, en samt. Og með því að spá fyrir um þennan vöxt, viðskiptakröfur um gagnamagn sem þarf að gera einhvers konar greiningar á, þá var ljóst að bráðum yrði talað um petabæt. Og það er nú þegar mjög dýrt að borga fyrir petabæt, svo við vorum að leita að valkosti hvert við ættum að fara.

Hvert á að fara? Og lengi vel var algjörlega óljóst hvert ætti að fara, því annars vegar eru viðskiptagagnagrunnar, þeir virðast virka vel. Sumir virka næstum eins vel og Vertica, aðrir verri. En þeir eru allir dýrir, ekkert ódýrara og betra var ekki hægt að finna.

Hins vegar eru til opnar lausnir, sem eru ekki mjög margar, þ.e.a.s. til greiningar er hægt að telja þær á fingrum. Og þeir eru ókeypis eða ódýrir, en hægir. Og þeir skortir oft nauðsynlega og gagnlega virkni.

Og það var ekkert að sameina það góða sem er í viðskiptalegum gagnagrunnum og allt það ókeypis sem er í opnum hugbúnaði.

Það var ekkert fyrr en, óvænt, Yandex dró ClickHouse út, eins og töframaður úr hatti, eins og kanína. Og það var óvænt ákvörðun, þeir spyrja samt spurningarinnar: "Af hverju?", En engu að síður.

Og strax sumarið 2016 fórum við að skoða hvað ClickHouse er. Og það kom í ljós að stundum getur það verið hraðari en Vertica. Við prófuðum mismunandi aðstæður á mismunandi fyrirspurnum. Og ef fyrirspurnin notaði aðeins eina töflu, það er, án allra joins (join), þá var ClickHouse tvöfalt hraðari en Vertica.

Ég var ekkert of latur og skoðaði Yandex próf um daginn. Það er það sama þar: ClickHouse er tvöfalt hraðari en Vertica, svo þeir tala oft um það.

En ef það eru sameiningar í fyrirspurnum, þá kemur allt ekki mjög ótvírætt í ljós. Og ClickHouse getur verið tvöfalt hægari en Vertica. Og ef þú leiðréttir beiðnina örlítið og endurskrifar hana, þá eru þær um það bil jafnar. Ekki slæmt. Og ókeypis.

Og eftir að hafa fengið niðurstöðurnar og skoðað þær frá mismunandi sjónarhornum fór LifeStreet til ClickHouse.

Þetta er 16. árið minnir mig. Þetta var eins og grín um mýs sem grétu og stinguðu sig, en héldu áfram að borða kaktusinn. Og þessu var lýst í smáatriðum, það er myndband um þetta o.s.frv.

Þess vegna ætla ég ekki að tala um það í smáatriðum, ég mun aðeins tala um niðurstöðurnar og nokkra áhugaverða hluti sem ég talaði ekki um þá.

Úrslitin eru:

• Árangursrík flutningur og meira en ár er kerfið þegar að vinna í framleiðslu.
• Framleiðni og sveigjanleiki hefur aukist. Af þeim 10 milljörðum skráa sem við hefðum efni á að geyma á dag og þá í stuttan tíma, geymir LifeStreet nú 75 milljarða skráa á dag og getur gert þetta í 3 mánuði eða lengur. Ef þú telur í hámarki, þá er þetta allt að milljón atburðir á sekúndu. Meira en milljón SQL fyrirspurnir á dag berast í þetta kerfi, aðallega frá mismunandi vélmennum.
• Þrátt fyrir að fleiri netþjónar hafi verið notaðir fyrir ClickHouse en fyrir Vertica þá sparast líka á vélbúnaði því frekar dýrir SAS diskar voru notaðir í Vertica. ClickHouse notaði SATA. Og hvers vegna? Vegna þess að í Vertica er innsetningin samstillt. Og samstilling krefst þess að diskarnir hægist ekki of mikið og einnig að netið hægist ekki of mikið, það er frekar dýr aðgerð. Og í ClickHouse er innsetningin ósamstillt. Þar að auki er alltaf hægt að skrifa allt á staðnum, það er enginn aukakostnaður fyrir þetta, svo hægt er að setja gögn inn í ClickHouse mun hraðar en í Vertika, jafnvel á hægari drifum. Og lestur er um það bil það sama. Að lesa á SATA, ef þeir eru í RAID, þá er þetta allt nógu hratt.
• Ótakmarkað af leyfi, þ.e.a.s. 3 petabæta af gögnum á 60 netþjónum (20 netþjónar eru ein eftirlíking) og 6 trilljón færslur í staðreyndum og samanlögðum. Vertica hafði ekki efni á öðru eins.

Ég vík nú að praktískum hlutum í þessu dæmi.

• Hið fyrra er skilvirkt kerfi. Mikið veltur á fyrirkomulaginu.
• Annað er skilvirk SQL kynslóð.

Dæmigerð OLAP fyrirspurn er val. Sumir dálkanna fara í hópa eftir, sumir dálkarnir fara í samanlagðar aðgerðir. Það er hvar, sem hægt er að tákna sem sneið af teningi. Líta má á allan hópinn sem vörpun. Og þess vegna er það kallað margbreytileg gagnagreining.

Og oft er þetta mótað í formi stjörnukerfis, þegar það er miðlæg staðreynd og einkenni þessarar staðreyndar meðfram hliðum, meðfram geislum.

Og frá sjónarhóli líkamlegrar hönnunar, hvernig það passar á borðið, gera þeir venjulega staðlaða framsetningu. Þú getur afeðlað, en það er dýrt á disknum og ekki mjög duglegt við fyrirspurnir. Þess vegna gera þeir venjulega staðlaða sýn, þ.e. staðreyndatöflu og margar, margar víddartöflur.

En þetta virkar ekki vel í ClickHouse. Það eru tvær ástæður:

• Sú fyrsta er vegna þess að ClickHouse hefur ekki mjög góða joins, þ.e.a.s. það eru joins, en þeir eru slæmir. Þó slæmt.
• Annað er að töflurnar eru ekki uppfærðar. Venjulega þarf að breyta einhverju í þessum plötum, sem eru í kringum stjörnuhringinn. Til dæmis, nafn viðskiptavinar, nafn fyrirtækis osfrv. Og það virkar ekki.

Og það er leið út úr þessu í ClickHouse. jafnvel tveir:

• Í fyrsta lagi er notkun orðabóka. Ytri orðabækur eru það sem hjálpar 99% að leysa vandamálið með stjörnuskemanu, með uppfærslum og svo framvegis.
• Annað er notkun fylkja. Fylki hjálpa einnig til við að losna við samskeyti og vandamál með eðlilegt ástand.

• Engin þátttöku krafist.
• Hægt að uppfæra. Síðan í mars 2018 hefur birst óskráð tækifæri (þú finnur þetta ekki í skjölunum) til að uppfæra orðabækur að hluta, þ.e.a.s. þær færslur sem hafa breyst. Í rauninni er það eins og borð.
• Alltaf í minni, svo sameinast með orðabók vinna hraðar en ef það væri borð sem er á diski og það er ekki enn staðreynd að það er í skyndiminni, líklega ekki.

• Þú þarft ekki joins heldur.
• Þetta er þétt 1-til-marga framsetning.
• Og að mínu mati eru fylkingar gerðar fyrir nörda. Þetta eru lambda aðgerðir og svo framvegis.

Þetta er ekki fyrir rauð orð. Þetta er mjög öflug virkni sem gerir þér kleift að gera marga hluti á mjög einfaldan og glæsilegan hátt.

Dæmigert dæmi sem hjálpa til við að leysa fylki. Þessi dæmi eru einföld og nógu skýr:

• Leitaðu eftir merkjum. Ef þú ert með hashtags þar og vilt finna nokkrar færslur eftir hashtag.
• Leitaðu eftir lykilgildapörum. Það eru líka nokkrir eiginleikar með gildi.
• Geymir lista yfir lykla sem þú þarft að þýða yfir í eitthvað annað.

Öll þessi verkefni er hægt að leysa án fylkja. Merki er hægt að setja í einhverja línu og velja með reglulegri tjáningu eða í sérstakri töflu, en þá þarf að gera join (join).

Og í ClickHouse þarftu ekki að gera neitt, það er nóg að lýsa strengjafylki fyrir hashtags eða búa til hreiðraða uppbyggingu fyrir lykilgildakerfi.

Hreiður uppbygging er kannski ekki besta nafnið. Þetta eru tvær fylkingar sem eiga sameiginlegan þátt í nafninu og sumum tengdum einkennum.

Og það er mjög auðvelt að leita eftir merki. Hafa aðgerð has, sem athugar hvort fylkið inniheldur stak. Allir, fundu allar færslur sem tengjast ráðstefnunni okkar.

Leit eftir subid er aðeins flóknari. Við þurfum fyrst að finna vísitöluna á lyklinum og taka svo þáttinn með þessari vísitölu og athuga hvort þetta gildi sé það sem við þurfum. Hins vegar er það mjög einfalt og fyrirferðarlítið.

Venjulega tjáningin sem þú myndir vilja skrifa ef þú hefðir þetta allt í einni línu, það væri í fyrsta lagi klaufalegt. Og í öðru lagi virkaði það miklu lengur en tvö fylki.

Annað dæmi. Þú ert með fylki þar sem þú geymir auðkennið. Og þú getur þýtt þau í nöfn. Virka arrayMap. Þetta er dæmigerð lambda aðgerð. Þú ferð framhjá lambda-tjáningum þarna. Og hún dregur út gildi nafnsins fyrir hvert auðkenni úr orðabókinni.

Þú getur leitað á sama hátt. Hlutfallsfall er gefið inn sem athugar hvað þættirnir passa saman.

Þessir hlutir einfalda hringrásina til muna og leysa fullt af vandamálum.

En næsta vandamál sem við stöndum frammi fyrir, og sem ég vil nefna, eru skilvirkar fyrirspurnir.

• ClickHouse er ekki með fyrirspurnaráætlun. Alls ekki.
• Engu að síður þarf enn að skipuleggja flóknar fyrirspurnir. Í hvaða tilfellum?
• Ef það eru margar sameiningar í fyrirspurninni, vefur þú þeim inn í undirval. Og röðin sem þeir eru framkvæmdir í skiptir máli.
• Og annað - ef beiðninni er dreift. Vegna þess að í dreifðri fyrirspurn er aðeins innsta undirvalið keyrt dreift og allt annað er sent á einn netþjón sem þú tengdir við og keyrðir þar. Þess vegna, ef þú hefur dreift fyrirspurnum með mörgum joins (join), þá þarftu að velja röðina.

Og jafnvel í einfaldari tilfellum, stundum er líka nauðsynlegt að vinna vinnu tímaáætlunarmannsins og endurskrifa fyrirspurnir aðeins.

Hér er dæmi. Vinstra megin er fyrirspurn sem sýnir efstu 5 löndin. Og það keyrir á 2,5 sekúndum held ég. Og hægra megin er sama beiðni, en örlítið endurskrifuð. Í stað þess að flokka eftir streng byrjuðum við að flokka eftir lykli (int). Og það er fljótlegra. Og svo tengdum við orðabók við niðurstöðuna. Í stað 2,5 sekúndna tekur beiðnin 1,5 sekúndur. Þetta er gott.

Svipað dæmi með endurskrifa síur. Hér er beiðni um Rússland. Það keyrir í 5 sekúndur. Ef við endurskrifum það á þann hátt að við berum saman aftur ekki streng, heldur tölur með einhverju setti af þessum lyklum sem tengjast Rússlandi, þá verður það miklu hraðar.

Það eru til mörg slík brögð. Og þeir gera þér kleift að flýta verulega fyrir fyrirspurnum sem þú heldur að séu þegar í gangi hratt, eða öfugt, gangi hægt. Þeir geta verið enn hraðari.

• Hámarksvinna í dreifðri stillingu.
• Að flokka eftir lágmarkstegundum, eins og ég gerði eftir ints.
• Ef það eru einhverjar joins (join), orðabækur, þá er betra að gera þær sem síðasta úrræði, þegar þú ert nú þegar með gögn að minnsta kosti að hluta til flokkuð, þá mun sameinaaðgerðin eða orðabókarsímtalið vera kallað sjaldnar og það verður hraðari .
• Skipt um síur.

Það eru aðrar aðferðir, en ekki bara þær sem ég hef sýnt. Og allar geta þær stundum flýtt verulega fyrir framkvæmd fyrirspurna.

Við skulum halda áfram að næsta dæmi. Fyrirtæki X frá Bandaríkjunum. Hvað er hún að gera?

Það var verkefni:

• Ótengdur tenging auglýsingaviðskipta.
• Módela mismunandi bindingarlíkön.

Hver er atburðarásin?

Venjulegur gestur kemur inn á síðuna til dæmis 20 sinnum í mánuði úr mismunandi auglýsingum, eða bara svona stundum án auglýsinga, því hann man eftir þessari síðu. Horfir á sumar vörur, setur þær í körfuna, tekur þær úr körfunni. Og á endanum kaupir eitthvað.

Sanngjarnar spurningar: "Hver ætti að borga fyrir auglýsingar ef þörf krefur?" og „Hvaða auglýsingar, ef einhverjar, höfðu áhrif á hann? Það er, hvers vegna keypti hann og hvernig á að tryggja að fólk svipað og þessi manneskja kaupi líka?

Til að leysa þetta vandamál þarftu að tengja atburðina sem eiga sér stað á vefsíðunni á réttan hátt, það er einhvern veginn að byggja upp tengsl á milli þeirra. Síðan eru þau send til greiningar til DWH. Og byggt á þessari greiningu, byggðu líkan af því hverja og hvaða auglýsingar á að sýna.

Auglýsingafærslur eru sett af tengdum notendaviðburðum sem byrja á því að birta auglýsingu, svo gerist eitthvað, svo kannski kaup og svo geta verið kaup innan kaups. Til dæmis, ef þetta er farsímaforrit eða farsímaleikur, þá fer uppsetning forritsins venjulega fram ókeypis og ef eitthvað er gert þar, þá gæti þurft peninga til þess. Og því meira sem maður eyðir í umsóknina, því verðmætara er það. En fyrir þetta þarftu að tengja allt.

Það eru margar bindandi gerðir.

Vinsælustu eru:

• Síðasta samskipti, þar sem samskipti eru annað hvort smellur eða birting.
• Fyrsta samskipti, þ.e.a.s. það fyrsta sem kom einstaklingi á síðuna.
• Línuleg samsetning - allt jafnt.
• Dempun.
• Og svo framvegis.

Og hvernig virkaði þetta allt í upphafi? Það var Runtime og Cassandra. Cassandra var notuð sem færslugeymsla, þ.e.a.s. allar tengdar færslur voru geymdar í henni. Og þegar einhver atburður kemur í Runtime, til dæmis, sýnir einhverja síðu eða eitthvað annað, þá var farið fram á beiðni til Cassöndru - er slík manneskja til eða ekki. Þá fengust þau viðskipti sem því tengjast. Og tengingin var gerð.

Og ef það er heppið að beiðnin hefur viðskiptaauðkenni, þá er það auðvelt. En yfirleitt engin heppni. Því var nauðsynlegt að finna síðustu færsluna eða færsluna með síðasta smelli o.s.frv.

Og þetta virkaði allt mjög vel þar til tengingin var á síðasta smell. Vegna þess að það eru til dæmis 10 milljónir smellir á dag, 300 milljónir á mánuði, ef þú stillir glugga í mánuð. Og þar sem í Cassandra þarf allt að vera í minni til að vinna hratt, vegna þess að Runtime þarf til að bregðast hratt við, þurfti um það bil 10-15 netþjóna.

Og þegar þeir vildu tengja viðskipti við skjáinn, reyndist það strax ekki svo skemmtilegt. Og hvers vegna? Það má sjá að geyma þarf 30 sinnum fleiri atburði. Og í samræmi við það þarftu 30 sinnum fleiri netþjóna. Og það kemur í ljós að þetta er einhvers konar stjarnfræðileg mynd. Til að halda allt að 500 netþjónum til að gera tenginguna, þrátt fyrir að það séu verulega færri netþjónar í Runtime, þá er þetta einhvers konar röng tala. Og þeir fóru að hugsa hvað þeir ættu að gera.

Og við fórum í ClickHouse. Og hvernig á að gera það á ClickHouse? Við fyrstu sýn virðist sem þetta sé sett af andmynstri.

• Viðskiptin stækka, við tengjum fleiri og fleiri atburði við það, þ.e.a.s. það er breytilegt, og ClickHouse virkar ekki mjög vel með breytanlegum hlutum.
• Þegar gestur kemur til okkar þurfum við að draga út færslur hans með lykli, eftir heimsóknarnúmeri hans. Þetta er líka punktaspurning, þeir gera það ekki í ClickHouse. Venjulega er ClickHouse með stórar ...skannanir, en hér þurfum við að fá nokkrar skrár. Líka antimynstur.
• Að auki voru viðskiptin í json, en þeir vildu ekki endurskrifa það, svo þeir vildu geyma json á óskipulagðan hátt, og ef nauðsyn krefur, draga eitthvað út úr því. Og þetta er líka andmynstur.

Það er sett af andmynstri.

En engu að síður reyndist það gera kerfi sem virkaði mjög vel.

Hvað var gert? ClickHouse birtist, þar sem annálum var hent, skipt í færslur. Eignuð þjónusta birtist sem fékk logs frá ClickHouse. Eftir það, fyrir hverja færslu, með heimsóknarauðkenni, fékk ég færslur sem gætu ekki hafa verið unnar ennþá og auk skyndimynda, þ.e.a.s. færslur sem þegar eru tengdar, þ. Ég gerði þegar rökfræði úr þeim, valdi réttu viðskiptin, tengdi nýja atburði. Skráður aftur. Skráin fór aftur í ClickHouse, þ.e. það er stöðugt hringrásarkerfi. Og þar að auki fór ég til DWH til að greina það þar.

Það var í þessu formi sem það virkaði ekki mjög vel. Og til að auðvelda ClickHouse, þegar það var beiðni um heimsóknarkenni, flokkuðu þeir þessar beiðnir í blokkir með 1-000 heimsóknaauðkennum og drógu út allar færslur fyrir 2-000 manns. Og svo virkaði þetta allt.

Ef þú lítur inn í ClickHouse, þá eru aðeins 3 aðalborð sem þjóna þessu öllu.

Fyrsta taflan sem annálum er hlaðið inn í og ​​annálum er hlaðið upp nánast án vinnslu.

Annað borð. Í gegnum efnislega sýn, úr þessum annálum, voru atburðir sem enn hafa ekki verið eignaðir, þ.e. óskyldir, bitnir út. Og í gegnum efnislega sýn voru viðskipti dregin út úr þessum annálum til að búa til skyndimynd. Það er, sérstakt efnislegt útsýni byggir upp skyndimynd, nefnilega síðasta uppsafnaða ástand viðskiptanna.

Hér er textinn skrifaður í SQL. Mig langar að gera athugasemdir við nokkur mikilvæg atriði í henni.

Það fyrsta sem skiptir máli er hæfileikinn til að draga út dálka og reiti úr json í ClickHouse. Það er, ClickHouse hefur nokkrar aðferðir til að vinna með json. Þau eru mjög, mjög frumstæð.

visitParamExtractInt gerir þér kleift að draga út eiginleika úr json, þ.e.a.s. fyrsta höggið virkar. Og þannig geturðu dregið út viðskiptaauðkenni eða heimsóknarauðkenni. Þetta skipti.

Í öðru lagi er hér notaður erfiður efnislegur reitur. Hvað þýðir það? Þetta þýðir að þú getur ekki sett hana inn í töfluna, þ.e.a.s. hún er ekki sett inn, hún er reiknuð út og geymd við innsetningu. Þegar þú límir gerir ClickHouse verkið fyrir þig. Og það sem þú þarft síðar er þegar dregið úr json.

Í þessu tilviki er efnisbundið útsýni fyrir hráar raðir. Og fyrsta borðið með nánast hráum logum er bara notað. Og hvað gerir hann? Í fyrsta lagi breytir það flokkuninni, þ.e. flokkun fer nú eftir visit id, vegna þess að við þurfum fljótt að draga út færslu hans fyrir tiltekinn einstakling.

Annað mikilvægt er index_granularity. Ef þú hefur séð MergeTree, þá er það venjulega 8 sjálfgefið index_granularity. Hvað það er? Þetta er breytu vísitölunnar. Í ClickHouse er vísitalan dreifð, hún skráir aldrei hverja færslu. Það gerir þetta á 192. Og þetta er gott þegar þarf að reikna mikið af gögnum, en slæmt þegar það er lítið, vegna þess að það er mikill kostnaður. Og ef við lækkum nákvæmni vísitölunnar, þá lækkum við kostnaðinn. Það er ekki hægt að minnka það niður í einn, því það er kannski ekki nóg minni. Vísitalan er alltaf geymd í minni.

Og skyndimyndin notar nokkrar aðrar áhugaverðar ClickHouse aðgerðir.

Í fyrsta lagi er það AggregatingMergeTree. Og AggregatingMergeTree geymir argMax, þ.e. þetta er ástand viðskiptanna sem samsvarar síðasta tímastimpli. Viðskipti verða til allan tímann fyrir tiltekinn gest. Og í síðasta ástandi þessara viðskipta bættum við við viðburði og við höfum nýtt ástand. Það sló aftur á ClickHouse. Og í gegnum argMax í þessari veruleikasýn getum við alltaf fengið núverandi ástand.

• Bindingin er „aftengd“ frá Runtime.
• Allt að 3 milljarðar færslur á mánuði eru geymdar og unnar. Þetta er stærðargráðu meira en það var í Cassöndru, þ.e.a.s. í dæmigerðu viðskiptakerfi.
• Þyrping af 2x5 ClickHouse netþjónum. 5 netþjónar og hver server er með eftirmynd. Þetta er jafnvel minna en það var í Cassöndru til að gera smelli byggða tilvísun, og hér höfum við birtingu byggt. Það er, í stað þess að fjölga netþjónum um 30 sinnum tókst þeim að fækka þeim.

Og síðasta dæmið er fjármálafyrirtækið Y, sem greindi fylgni breytinga á hlutabréfaverði.

Og verkefnið var:

• Það eru um það bil 5 hlutir.
• Tilvitnanir á 100 millisekúndna fresti eru þekktar.
• Gögnunum hefur verið safnað á 10 árum. Svo virðist sem fyrir sum fyrirtæki meira, fyrir sum minna.
• Alls eru um það bil 100 milljarðar lína.

Og það var nauðsynlegt að reikna út fylgni breytinga.

Hér eru tvö hlutabréf og verð þeirra. Ef annar hækkar og hinn hækkar, þá er þetta jákvæð fylgni, þ.e.a.s. einn hækkar og hinn hækkar. Ef einn fer upp, eins og í lok línuritsins, og hinn fer niður, þá er þetta neikvæð fylgni, þ.e.a.s. þegar annar hækkar, þá lækkar hinn.

Með því að greina þessar gagnkvæmu breytingar er hægt að gera spár á fjármálamarkaði.

En verkefnið er erfitt. Hvað er verið að gera í þessu? Við höfum 100 milljarða færslur sem hafa: tíma, birgðir og verð. Við þurfum að reikna fyrstu 100 milljarða sinnum hlaupandi Munurinn frá verðalgríminu. RunningDifference er fall í ClickHouse sem reiknar út muninn á milli tveggja strengja í röð.

Og eftir það þarftu að reikna út fylgnina og fylgnin verður að vera reiknuð út fyrir hvert par. Fyrir 5 hluti eru pör 000 milljónir. Og þetta er mikið, þ.e.a.s. 12,5 sinnum er nauðsynlegt að reikna bara svona fylgnifall.

Og ef einhver gleymdi, þá er ͞x og ͞y mát. sýnatökuvæntingu. Það er, það er ekki aðeins nauðsynlegt að reikna út rætur og upphæðir, heldur einnig eina upphæð í viðbót inni í þessum upphæðum. Það þarf að gera fullt af útreikningum 12,5 milljón sinnum og jafnvel flokka eftir klukkustundum. Við höfum líka marga tíma. Og þú þarft að gera það á 60 sekúndum. Þetta er brandari.

Það var nauðsynlegt að hafa tíma að minnsta kosti einhvern veginn, því allt þetta virkaði mjög, mjög hægt áður en ClickHouse kom.

Þeir reyndu að reikna það út á Hadoop, á Spark, á Greenplum. Og allt var þetta mjög hægt eða dýrt. Það er að segja, það var hægt að reikna einhvern veginn, en þá var það dýrt.

Og svo kom ClickHouse og hlutirnir urðu miklu betri.

Ég minni á að við eigum í vandræðum með staðsetning gagna, því ekki er hægt að staðfæra fylgni. Við getum ekki sett sum gögnin á einn netþjón, sum á annan og reiknað út, við verðum að hafa öll gögn alls staðar.

Hvað gerðu þeir? Upphaflega eru gögnin staðbundin. Hver netþjónn geymir gögn um verðlagningu á tilteknu safni hlutabréfa. Og þeir skarast ekki. Þess vegna er hægt að reikna logReturn samhliða og sjálfstætt, allt þetta gerist hingað til samhliða og dreift.

Síðan ákváðum við að draga úr þessum gögnum, án þess að missa tjáninguna. Dragðu úr því að nota fylki, þ.e. fyrir hvert tímabil, búðu til fjölda hlutabréfa og fylki af verði. Þess vegna tekur það mun minna gagnapláss. Og þeir eru aðeins auðveldari að vinna með. Þetta eru nánast samhliða aðgerðir, þ.e.a.s. við lesum að hluta samhliða og skrifum svo á netþjóninn.

Þetta er síðan hægt að endurtaka. Bókstafurinn „r“ þýðir að við endurtókum þessi gögn. Það er, við höfum sömu gögnin á öllum þremur netþjónunum - þetta eru fylkin.

Og svo með sérstöku handriti úr þessu setti af 12,5 milljón fylgni sem þarf að reikna út geturðu búið til pakka. Það er 2 verkefni með 500 pör af fylgni. Og þetta verkefni á að reikna út á tilteknum ClickHouse netþjóni. Hann hefur öll gögnin, því gögnin eru þau sömu og hann getur reiknað þau í röð.

Enn og aftur, svona lítur þetta út. Í fyrsta lagi höfum við öll gögnin í þessari uppbyggingu: tími, hlutabréf, verð. Síðan reiknuðum við logReturn, þ.e. gögn af sömu uppbyggingu, en í stað verðsins höfum við nú þegar logReturn. Síðan voru þau endurgerð, þ.e.a.s. við fengum tíma og groupArray fyrir birgðir og verð. Afritað. Og eftir það bjuggum við til fullt af verkefnum og færðum þau til ClickHouse svo það myndi telja þau. Og það virkar.

Á sönnun á hugmyndinni var verkefnið undirverkefni, þ.e. minni gögn voru tekin. Og aðeins þrír netþjónar.

Þessi fyrstu tvö stig: útreikningur á Log_return og umbúðir í fylki tók um klukkustund.

Og útreikningur á fylgni er um 50 klst. En 50 tímar eru ekki nóg, því þeir unnu áður vikum saman. Það var mikill árangur. Og ef þú telur, þá var allt talið 70 sinnum á sekúndu á þessum klasa.

En það mikilvægasta er að þetta kerfi er nánast án flöskuhálsa, þ.e.a.s. það skalast nánast línulega. Og þeir athugaðu það. Tókst að stækka það.

• Rétt kerfi er hálf baráttan. Og rétta kerfið er notkun allra nauðsynlegrar ClickHouse tækni.
• Summing/AggregatingMergeTrees eru tækni sem gerir þér kleift að safna saman eða líta á ástandsmynd sem sérstakt tilvik. Og það einfaldar mjög margt.
• Efnislegar skoðanir leyfa þér að komast framhjá einu vísitölumörkunum. Kannski sagði ég það ekki mjög skýrt, en þegar við hlóðum logs voru hráu logarnir í töflunni með einni vísitölu og eigindaskrárnar voru í töflunni, þ.e.a.s. sömu gögnin, aðeins síuð, en vísitalan var algjörlega öðrum. Þetta virðast vera sömu gögnin, en mismunandi flokkun. Og efnisbundið útsýni gerir þér kleift, ef þú þarft á því að halda, að komast framhjá slíkri takmörkun ClickHouse.
• Draga úr nákvæmni vísitölu fyrir punktafyrirspurnir.
• Og dreifðu gögnunum á skynsamlegan hátt, reyndu að staðfæra gögnin innan netþjónsins eins mikið og mögulegt er. Og reyndu að tryggja að beiðnir noti einnig staðfærslu þar sem hægt er eins mikið og mögulegt er.

Og til að draga saman þessa stuttu ræðu getum við sagt að ClickHouse hefur nú staðfastlega hertekið yfirráðasvæði bæði viðskiptagagnagrunna og opinna gagnagrunna, þ.e.a.s. sérstaklega fyrir greiningar. Hann passar fullkomlega inn í þetta landslag. Og það sem meira er, það er hægt og rólega farið að víkja frá öðrum, því þegar ClickHouse er til staðar þarftu ekki InfiniDB. Lóðrétt gæti fljótlega ekki verið þörf ef þeir veita venjulegan SQL stuðning. Nota það!

-Takk fyrir skýrsluna! Mjög áhugavert! Var einhver samanburður við Apache Phoenix?

Nei, ég hef ekki heyrt neinn bera saman. Við og Yandex reynum að fylgjast með öllum ClickHouse samanburði við mismunandi gagnagrunna. Vegna þess að ef allt í einu reynist eitthvað vera hraðar en ClickHouse, þá getur Lesha Milovidov ekki sofið á nóttunni og byrjar að flýta því hratt. Ég hef ekki heyrt um slíkan samanburð.

• (Aleksey Milovidov) Apache Phoenix er SQL vél knúin af Hbase. Hbase er aðallega fyrir lykilgildi vinnusviðsmynd. Þar, í hverri línu, getur verið handahófskenndur fjöldi dálka með handahófskenndum nöfnum. Þetta má segja um slík kerfi eins og Hbase, Cassandra. Og það eru einmitt þungar greiningarfyrirspurnir sem virka ekki venjulega fyrir þær. Eða þú gætir haldið að þeir virki vel ef þú hefur ekki reynslu af ClickHouse.

• Takk

  • Góðan daginn Ég hef nú þegar mikinn áhuga á þessu efni, vegna þess að ég er með greiningar undirkerfi. En þegar ég horfi á ClickHouse fæ ég á tilfinninguna að ClickHouse henti mjög vel í atburðagreiningu, breytilegt. Og ef ég þarf að greina mikið af viðskiptagögnum með fullt af stórum töflum, þá hentar ClickHouse, eftir því sem ég skil, ekki mjög vel fyrir mig? Sérstaklega ef þeir breytast. Er þetta rétt eða eru til dæmi sem geta hrakið þetta?

  • Þetta er rétt. Og þetta á við um flesta sérhæfða greiningargagnagrunna. Þau eru sérsniðin fyrir þá staðreynd að það eru eitt eða fleiri stór borð sem eru breytileg og fyrir mörg lítil sem breytast hægt. Það er, ClickHouse er ekki eins og Oracle, þar sem þú getur sett allt og smíðað mjög flóknar fyrirspurnir. Til þess að nota ClickHouse á áhrifaríkan hátt þarftu að byggja upp kerfi á þann hátt sem virkar vel í ClickHouse. Það er að segja, forðast óhóflega normalization, notaðu orðabækur, reyndu að búa til færri langa tengla. Og ef stefið er byggt upp á þennan hátt, þá er hægt að leysa svipuð viðskiptaverkefni á ClickHouse mun skilvirkari en á hefðbundnum venslagagnagrunni.

Takk fyrir skýrsluna! Ég er með spurningu um nýjasta fjármálamálið. Þeir höfðu greiningar. Það var nauðsynlegt að bera saman hvernig þeir fara upp og niður. Og mér skilst að þú hafir smíðað kerfið sérstaklega fyrir þessar greiningar? Ef á morgun, til dæmis, þeir þurfa einhverja aðra skýrslu um þessi gögn, þurfa þeir að endurbyggja stefið og hlaða upp gögnunum? Það er að segja að gera einhvers konar forvinnslu til að fá beiðnina?

Auðvitað er þetta notkun ClickHouse fyrir mjög ákveðið verkefni. Það væri meira hefðbundið hægt að leysa það innan Hadoop. Fyrir Hadoop er þetta tilvalið verkefni. En á Hadoop er það mjög hægt. Og markmið mitt er að sýna fram á að ClickHouse getur leyst verkefni sem venjulega eru leyst með allt öðrum hætti, en á sama tíma gert það mun skilvirkari. Það er sérsniðið fyrir ákveðið verkefni. Það er ljóst að ef það er vandamál með eitthvað svipað, þá er hægt að leysa það á svipaðan hátt.

Það er skýrt. Þú sagðir að það tæki 50 klukkustundir að vinna úr því. Er það að byrja alveg frá upphafi, þegar þú hleður gögnunum eða fékkst niðurstöðurnar?

Já já.

OK þakka þér kærlega fyrir.

Þetta er á 3 netþjónaþyrpingum.

Kveðja! Takk fyrir skýrsluna! Allt er mjög áhugavert. Ég mun ekki spyrja smá um virknina heldur um notkun ClickHouse hvað varðar stöðugleika. Það er að segja, áttirðu eitthvað, þurftirðu að endurheimta? Hvernig hegðar ClickHouse sér í þessu tilfelli? Og gerðist það að þú áttir líka eftirlíkingu? Við, til dæmis, stóðum frammi fyrir vandamáli með ClickHouse þegar það fer enn út fyrir mörk sín og dettur.

Auðvitað eru engin kjörkerfi. Og ClickHouse hefur líka sín eigin vandamál. En hefur þú heyrt um að Yandex.Metrica hafi ekki virkað í langan tíma? Örugglega ekki. Það hefur virkað áreiðanlega síðan 2012-2013 á ClickHouse. Ég get sagt það sama um mína reynslu. Við höfum aldrei lent í algjörum mistökum. Sumir hlutir gætu gerst, en þeir voru aldrei nógu mikilvægir til að hafa alvarleg áhrif á viðskiptin. Það gerðist aldrei. ClickHouse er nokkuð áreiðanlegt og hrynur ekki af handahófi. Þú þarft ekki að hafa áhyggjur af því. Það er ekki hrátt hlutur. Þetta hafa mörg fyrirtæki sannað.

Halló! Þú sagðir að þú þyrftir að hugsa um gagnaskemmuna strax. Hvað ef það gerðist? Gögnin mín streyma og hellast. Sex mánuðir líða og ég skil að það er ómögulegt að lifa svona, ég þarf að hlaða upp gögnunum aftur og gera eitthvað við þau.

Þetta fer auðvitað eftir kerfinu þínu. Það eru nokkrar leiðir til að gera þetta nánast án stöðvunar. Til dæmis er hægt að búa til efnisbundið útsýni þar sem hægt er að búa til aðra gagnauppbyggingu ef hægt er að kortleggja hana einstaklega. Það er að segja, ef það leyfir kortlagningu með því að nota ClickHouse, þ. Skrifaðu yfir gömlu gögnin þín þar, ný verða skrifuð sjálfkrafa. Og skiptu svo bara yfir í að nota efnislega sýn, skiptu síðan um skrána og dreptu gamla borðið. Þetta er almennt stanslaus aðferð.

Þakka þér.

Heimild: www.habr.com