Teorija in praksa uporabe ClickHouse v realnih aplikacijah. Aleksander Zajcev (2018)

Kljub temu, da je zdaj podatkov veliko skoraj povsod, so analitične baze še vedno precejšnja eksotika. Slabo jih poznamo in še slabše jih znamo učinkovito uporabiti. Mnogi še naprej "jedo kaktus" z MySQL ali PostgreSQL, ki sta zasnovana za druge scenarije, trpijo z NoSQL ali preplačajo komercialne rešitve. ClickHouse spreminja pravila igre in bistveno niža prag za vstop v svet analitičnih DBMS.

Poročilo z BackEnd Conf 2018 in je objavljeno z dovoljenjem predavatelja.

Kdo sem in zakaj govorim o ClickHouse? Sem direktor razvoja pri LifeStreet, ki uporablja ClickHouse. Poleg tega sem ustanovitelj Altinityja. Je Yandexov partner, ki promovira ClickHouse in pomaga Yandexu narediti ClickHouse uspešnejši. Pripravljen tudi deliti znanje o ClickHouse.

In nisem brat Petje Zajceva. Pogosto me sprašujejo o tem. Ne, nisva brata.

»Vsi vedo«, da ClickHouse:

• Zelo hitro,
• Zelo udobno
• Uporablja se v Yandex.

Nekoliko manj je znano, v katerih podjetjih in kako se uporablja.

Povedal vam bom, zakaj, kje in kako se uporablja ClickHouse, razen za Yandex.

Povedal vam bom, kako se določene naloge rešujejo s pomočjo ClickHouse v različnih podjetjih, katera orodja ClickHouse lahko uporabite za svoje naloge in kako so jih uporabljali v različnih podjetjih.

Izbral sem tri primere, ki prikazujejo ClickHouse iz različnih zornih kotov. Mislim, da bo zanimivo.

Prvo vprašanje je: “Zakaj potrebujemo ClickHouse?”. Zdi se, da je to precej očitno vprašanje, vendar obstaja več kot en odgovor nanj.

• Prvi odgovor je za uspešnost. ClickHouse je zelo hiter. Tudi analitika na ClickHouse je zelo hitra. Pogosto se lahko uporablja tam, kjer je nekaj drugega zelo počasno ali zelo slabo.
• Drugi odgovor je strošek. In najprej strošek skaliranja. Na primer, Vertica je absolutno odlična zbirka podatkov. Deluje zelo dobro, če nimate veliko terabajtov podatkov. Ko pa gre za stotine terabajtov ali petabajtov, gredo stroški licence in podpore v dokaj velik znesek. In to je drago. In ClickHouse je brezplačen.
• Tretji odgovor so operativni stroški. To je nekoliko drugačen pristop. RedShift je odličen analog. Na RedShift se lahko odločite zelo hitro. Delovalo bo dobro, hkrati pa boste vsako uro, vsak dan in vsak mesec Amazonu precej drago plačali, saj je to bistveno draga storitev. Tudi Google BigQuery. Če ga je kdo uporabljal, potem ve, da lahko tam zaženeš več zahtev in kar naenkrat dobiš račun za stotine dolarjev.

ClickHouse teh težav nima.

Kje se zdaj uporablja ClickHouse? Poleg Yandexa se ClickHouse uporablja v številnih različnih podjetjih in podjetjih.

• Najprej je to analitika spletnih aplikacij, to je primer uporabe, ki je prišel iz Yandexa.
• Mnoga AdTech podjetja uporabljajo ClickHouse.
• Številna podjetja, ki morajo analizirati dnevnike transakcij iz različnih virov.
• Več podjetij uporablja ClickHouse za spremljanje varnostnih dnevnikov. Naložijo jih v ClickHouse, pripravijo poročila in dobijo rezultate, ki jih potrebujejo.
• Podjetja ga začenjajo uporabljati v finančni analizi, tj postopoma se ClickHouse približujejo tudi velika podjetja.
• cloudflare. Če kdo spremlja ClickHouse, potem je verjetno že slišal za ime tega podjetja. To je eden od bistvenih prispevkov skupnosti. In imajo zelo resno namestitev ClickHouse. Na primer, naredili so Kafka Engine za ClickHouse.
• Telekomunikacijska podjetja so začela uporabljati. Več podjetij uporablja ClickHouse kot dokaz o konceptu ali že v proizvodnji.
• Eno podjetje uporablja ClickHouse za spremljanje proizvodnih procesov. Testirajo mikrovezja, odpišejo kup parametrov, okoli 2 karakteristik je. In potem analizirajo, ali je igra dobra ali slaba.
• Analitika verige blokov. Obstaja takšno rusko podjetje, kot je Bloxy.info. To je analiza omrežja ethereum. To so naredili tudi na ClickHouse.

In velikost ni pomembna. Obstaja veliko podjetij, ki uporabljajo en majhen strežnik. In jim omogoča, da rešijo svoje težave. In še več podjetij uporablja velike gruče številnih strežnikov ali več deset strežnikov.

In če pogledate zapise, potem:

• Yandex: 500+ strežnikov, tam shranijo 25 milijard zapisov na dan.
• LifeStreet: 60 strežnikov, približno 75 milijard zapisov na dan. Obstaja manj strežnikov, več zapisov kot v Yandexu.
• CloudFlare: 36 strežnikov, shranijo 200 milijard zapisov na dan. Imajo še manj strežnikov in hranijo še več podatkov.
• Bloomberg: 102 strežnika, približno trilijon vnosov na dan. Rekorderka.

Geografsko je tudi to veliko. Ta zemljevid tukaj prikazuje toplotni zemljevid, kje po svetu se uporablja ClickHouse. Tu jasno izstopajo Rusija, Kitajska, Amerika. Evropskih držav je malo. In tam so 4 grozdi.

To je primerjalna analiza, ni treba iskati absolutnih številk. To je analiza obiskovalcev, ki berejo gradiva v angleškem jeziku na spletnem mestu Altinity, ker tam ni rusko govorečih. In Rusija, Ukrajina, Belorusija, torej rusko govoreči del skupnosti, to so najštevilčnejši uporabniki. Nato pridejo ZDA in Kanada. Kitajska jo zelo dohiteva. Kitajske pred pol leta tam skoraj ni bilo, zdaj je Kitajska že prehitela Evropo in še naprej raste. Tudi stara Evropa ne zaostaja, vodilna v uporabi ClickHouse pa je, nenavadno, Francija.

Zakaj vse to pripovedujem? Pokazati, da ClickHouse postaja standardna rešitev za analizo velikih podatkov in se že uporablja na številnih mestih. Če ga uporabljate, ste v pravem trendu. Če ga še ne uporabljate, se ne morete bati, da boste ostali sami in vam nihče ne bo pomagal, ker mnogi to že počnejo.

To so primeri resnične uporabe ClickHouse v več podjetjih.

• Prvi primer je oglasno omrežje: selitev iz Vertice v ClickHouse. In poznam nekaj podjetij, ki so prešla iz Vertice ali so v procesu prehoda.
• Drugi primer je shranjevanje transakcij na ClickHouse. To je primer, zgrajen na antipatternih. Vse, kar se po nasvetu razvijalcev ne bi smelo početi v ClickHouse, se naredi tukaj. In to je tako učinkovito, da deluje. In deluje veliko bolje kot tipična transakcijska rešitev.
• Tretji primer je porazdeljeno računalništvo na ClickHouse. Pojavilo se je vprašanje, kako je mogoče ClickHouse vključiti v ekosistem Hadoop. Pokazal bom primer, kako je podjetje naredilo nekaj podobnega vsebniku za zmanjšanje zemljevidov na ClickHouse, spremljanje lokalizacije podatkov itd., da bi izračunalo zelo netrivialno nalogo.

• LifeStreet je podjetje Ad Tech, ki ima vso tehnologijo, ki je priložena oglaševalskemu omrežju.
• Ukvarja se z optimizacijo oglasov, programskim ponujanjem.
• Veliko podatkov: približno 10 milijard dogodkov na dan. Obenem lahko dogajanje tam razdelimo na več poddogodkov.
• Odjemalcev teh podatkov je veliko in to niso samo ljudje, veliko več - to so različni algoritmi, ki se ukvarjajo s programskim ponujanjem.

Podjetje je prehodilo dolgo in trnovo pot. In o tem sem govoril na HighLoadu. Najprej se je LifeStreet preselil iz MySQL (s kratkim postankom v Oracle) na Vertico. In lahko najdete zgodbo o tem.

In vse je bilo zelo dobro, vendar je hitro postalo jasno, da podatki rastejo in je Vertica draga. Zato so se iskale različne alternative. Nekateri od njih so navedeni tukaj. In pravzaprav smo naredili proof of concept ali včasih performance testing skoraj vseh podatkovnih baz, ki so bile na voljo na trgu od 13. do 16. leta in so bile po funkcionalnosti približno ustrezne. In o nekaterih od njih sem govoril tudi na HighLoadu.

Naloga je bila najprej migrirati iz Vertice, ker so podatki rasli. In z leti so eksponentno rasli. Potem so šli na polico, a kljub temu. In napovedovanje te rasti, poslovnih zahtev glede količine podatkov, na katerih je treba opraviti neke vrste analitiko, je bilo jasno, da se bo kmalu razpravljalo o petabajtih. In plačevanje petabajtov je že tako zelo drago, zato smo iskali alternativo, kam bi šli.

Kam iti? In dolgo časa sploh ni bilo jasno, kam iti, ker na eni strani obstajajo komercialne baze podatkov, zdi se, da dobro delujejo. Nekateri delujejo skoraj tako dobro kot Vertica, nekateri slabše. Ampak vsi so dragi, nič cenejšega in boljšega ni bilo mogoče najti.

Na drugi strani pa so odprtokodne rešitve, ki jih ni prav veliko, torej za analitiko jih lahko preštejemo na prste. In so brezplačni ali poceni, vendar počasni. In pogosto nimajo potrebne in uporabne funkcionalnosti.

In ni bilo nič, kar bi združilo dobro, kar je v komercialnih bazah, in vse brezplačno, kar je v odprti kodi.

Nič ni bilo, dokler ni Yandex nepričakovano izvlekel ClickHouse, kot čarovnik iz klobuka, kot zajec. In to je bila nepričakovana odločitev, še vedno postavljajo vprašanje: "Zakaj?", Ampak kljub temu.

In takoj poleti 2016 smo začeli iskati, kaj je ClickHouse. In izkazalo se je, da je včasih lahko hitrejši od Vertice. Preizkusili smo različne scenarije na različne zahteve. In če je poizvedba uporabila samo eno tabelo, torej brez kakršnih koli združevanj (join), potem je bil ClickHouse dvakrat hitrejši od Vertice.

Nisem bil preveč len in sem prejšnji dan pogledal teste Yandex. Tam je enako: ClickHouse je dvakrat hitrejši od Vertice, zato o tem pogosto govorijo.

Če pa so v poizvedbah spoji, potem se vse izkaže ne zelo nedvoumno. In ClickHouse je lahko dvakrat počasnejši od Vertice. In če nekoliko popravite zahtevo in jo prepišete, potem sta približno enaka. Ni slabo. In brezplačno.

In ko je prejel rezultate testa in pogledal z različnih zornih kotov, je LifeStreet odšel v ClickHouse.

To je 16. leto, vas spomnim. Bilo je kot v šali o miškah, ki so jokale in se zbadale, vendar so še naprej jedle kaktus. In to je bilo podrobno opisano, o tem obstaja video itd.

Zato o tem ne bom podrobneje govoril, govoril bom le o rezultatih in nekaj zanimivostih, o katerih takrat nisem govoril.

Rezultati so:

• Uspešna migracija in več kot leto dni sistem že deluje v produkciji.
• Produktivnost in fleksibilnost sta se povečali. Od 10 milijard zapisov, ki bi si jih lahko privoščili shraniti na dan in nato za kratek čas, LifeStreet zdaj shrani 75 milijard zapisov na dan in to lahko počne 3 mesece ali več. Če štejete na vrhuncu, potem je to do milijon dogodkov na sekundo. V ta sistem dnevno prispe več kot milijon poizvedb SQL, večinoma od različnih robotov.
• Kljub temu, da so za ClickHouse uporabili več strežnikov kot za Vertico, so varčevali tudi pri strojni opremi, saj so v Vertici uporabljali precej drage diske SAS. ClickHouse uporablja SATA. In zakaj? Ker je v Vertica vložek sinhron. In sinhronizacija zahteva, da se diski ne upočasnijo preveč, pa tudi, da omrežje ne upočasni preveč, se pravi precej drago operacijo. In v ClickHouse je vstavljanje asinhrono. Poleg tega lahko vedno vse pišete lokalno, za to ni dodatnih stroškov, tako da se podatki v ClickHouse vnesejo veliko hitreje kot v Vertiko, tudi na počasnejših diskih. In branje je približno enako. Branje na SATA, če so v RAID, potem je to vse dovolj hitro.
• Ni omejeno z licenco, tj. 3 petabajti podatkov v 60 strežnikih (20 strežnikov je ena replika) in 6 trilijonov zapisov v dejstvih in agregacijah. Česa takega si pri Vertici ne bi mogli privoščiti.

Zdaj se bom v tem primeru posvetil praktičnim stvarem.

• Prva je učinkovita shema. Veliko je odvisno od sheme.
• Drugi je učinkovito ustvarjanje SQL.

Tipična poizvedba OLAP je izbira. Nekateri stolpci gredo v skupino po, nekateri stolpci gredo v agregatne funkcije. Obstaja kje, kar lahko predstavimo kot rezino kocke. Celotno skupino lahko razumemo kot projekcijo. In zato se imenuje multivariatna analiza podatkov.

In pogosto je to modelirano v obliki zvezdne sheme, ko je osrednje dejstvo in značilnosti tega dejstva ob straneh, vzdolž žarkov.

Kar zadeva fizično zasnovo, kako se prilega mizi, običajno naredijo normalizirano predstavitev. Lahko denormalizirate, vendar je drago na disku in premalo učinkovito pri poizvedbah. Zato običajno naredijo normalizirano predstavitev, tj. tabelo dejstev in veliko, veliko dimenzijskih tabel.

Toda v ClickHouse ne deluje dobro. Razloga sta dva:

• Prvi je, ker ClickHouse nima zelo dobrih združitev, tj. združitve obstajajo, vendar so slabe. Čeprav slabo.
• Drugi je, da se tabele ne posodabljajo. Običajno je treba v teh ploščah, ki so okoli zvezdnega vezja, nekaj spremeniti. Na primer ime stranke, ime podjetja itd. In ne gre.

In v ClickHouse obstaja izhod iz tega. celo dva:

• Prvi je uporaba slovarjev. Zunanji slovarji so tisti, ki v 99 % pomagajo rešiti težavo s shemo zvezdic, s posodobitvami itd.
• Drugi je uporaba nizov. Matrike prav tako pomagajo odpraviti združevanja in težave z normalizacijo.

• Pridružitev ni potrebna.
• Nadgradljivo. Od marca 2018 se je pojavila nedokumentirana možnost (tega ne boste našli v dokumentaciji) za delno posodobitev slovarjev, torej tistih vnosov, ki so se spremenili. Praktično je kot miza.
• Vedno v pomnilniku, zato spoji s slovarjem delujejo hitreje, kot če bi bila tabela, ki je na disku in še ni dejstvo, da je v predpomnilniku, verjetno ne.

• Tudi pridružitve ne potrebujete.
• To je kompaktna predstavitev 1 proti mnogo.
• In po mojem mnenju so nizi narejeni za geeke. To so lambda funkcije in tako naprej.

To ni za rdeče besede. To je zelo zmogljiva funkcionalnost, ki vam omogoča, da naredite marsikaj na zelo preprost in eleganten način.

Tipični primeri, ki pomagajo pri reševanju nizov. Ti primeri so preprosti in dovolj jasni:

• Iskanje po oznakah. Če imate tam hashtage in želite najti nekaj objav po hashtagu.
• Iskanje po parih ključ-vrednost. Obstaja tudi nekaj atributov z vrednostjo.
• Shranjevanje seznamov ključev, ki jih morate prevesti v nekaj drugega.

Vse te naloge je mogoče rešiti brez nizov. Oznake lahko postavite v neko vrstico in izberete z regularnim izrazom ali v ločeni tabeli, vendar morate potem narediti spoje.

In v ClickHouse vam ni treba storiti ničesar, dovolj je, da opišete niz nizov za hashtags ali naredite ugnezdeno strukturo za sisteme ključ-vrednost.

Ugnezdena struktura morda ni najboljše ime. To sta dve matriki, ki imata skupni del v imenu in nekatere sorodne lastnosti.

In iskanje po oznaki je zelo enostavno. Imeti funkcijo has, ki preveri, ali matrika vsebuje element. Vsi, našli smo vse vnose, ki se nanašajo na našo konferenco.

Iskanje po subid je nekoliko bolj zapleteno. Najprej moramo najti indeks ključa, nato pa vzeti element s tem indeksom in preveriti, ali je ta vrednost tisto, kar potrebujemo. Vendar je zelo preprost in kompakten.

Regularni izraz, ki bi ga želeli napisati, če bi vse ohranili v eni vrstici, bi bil, prvič, neroden. In drugič, deloval je veliko dlje kot dve nizi.

Še en primer. Imate matriko, kamor shranite ID. In jih lahko prevedete v imena. funkcija arrayMap. To je tipična lambda funkcija. Tam posredujete lambda izraze. In iz slovarja potegne vrednost imena za vsak ID.

Iskanje je mogoče izvesti na enak način. Posreduje se predikatna funkcija, ki preveri, kateri elementi se ujemajo.

Te stvari zelo poenostavijo vezje in rešijo kup težav.

Toda naslednja težava, s katero se srečujemo in ki bi jo rad omenil, so učinkovite poizvedbe.

• ClickHouse nima načrtovalca poizvedb. Absolutno ne.
• Kljub temu je treba kompleksne poizvedbe še vedno načrtovati. V katerih primerih?
• Če je v poizvedbi več združevanj, jih zavijete v podizbore. In vrstni red, v katerem se izvajajo, je pomemben.
• In drugi - če je zahteva razdeljena. Ker se v porazdeljeni poizvedbi porazdeljeno izvede samo najbolj notranji podizbor, vse ostalo pa se posreduje enemu strežniku, s katerim ste se povezali in tam izvajate. Če ste torej porazdelili poizvedbe s številnimi združevanji (join), potem morate izbrati vrstni red.

In tudi v enostavnejših primerih je včasih treba opraviti tudi delo planerja in malo prepisati poizvedbe.

Tukaj je primer. Na levi strani je poizvedba, ki prikazuje 5 najboljših držav. In po mojem mnenju traja 2,5 sekunde. In na desni strani ista poizvedba, vendar nekoliko prepisana. Namesto združevanja po nizu smo začeli združevati po ključu (int). In je hitrejši. In potem smo z rezultatom povezali slovar. Zahteva namesto 2,5 sekunde traja 1,5 sekunde. To je dobro.

Podoben primer s filtri za prepisovanje. Tukaj je prošnja za Rusijo. Teče 5 sekund. Če ga prepišemo tako, da spet ne primerjamo niza, ampak številke z nekim nizom tistih ključev, ki se nanašajo na Rusijo, potem bo veliko hitreje.

Takih trikov je veliko. Poleg tega vam omogočajo, da znatno pospešite poizvedbe, za katere menite, da že tečejo hitro ali, nasprotno, tečejo počasi. Lahko se naredijo še hitreje.

• Največje delo v porazdeljenem načinu.
• Razvrščanje po minimalnih tipih, kot sem jaz po ints.
• Če obstajajo kakršna koli združevanja (join), slovarji, jih je bolje narediti v skrajnem primeru, ko že imate podatke vsaj delno združene, potem bo operacija združevanja ali klic slovarja poklican manjkrat in bo hitrejši .
• Zamenjava filtrov.

Obstajajo tudi druge tehnike in ne samo tiste, ki sem jih pokazal. In vsi lahko včasih bistveno pospešijo izvajanje poizvedb.

Pojdimo na naslednji primer. Podjetje X iz ZDA. Kaj ona počne?

Bila je naloga:

• Offline povezovanje oglaševalskih transakcij.
• Modeliranje različnih modelov vezave.

Kakšen je scenarij?

Običajen obiskovalec pride na spletno stran na primer 20-krat na mesec iz različnih oglasov ali kar tako včasih pride brez oglasov, ker si to stran zapomni. Pogleda nekaj izdelkov, jih da v košarico, vzame iz košarice. In na koncu se nekaj kupi.

Razumna vprašanja: "Kdo naj plača oglaševanje, če je potrebno?" in "Katero oglaševanje je vplivalo nanj, če sploh?". Se pravi, zakaj je kupil in kako doseči, da ljudje, kot je ta oseba, tudi kupijo?

Da bi rešili ta problem, morate dogodke, ki se dogajajo na spletnem mestu, pravilno povezati, torej nekako zgraditi povezavo med njimi. Nato se pošljejo v analizo v DWH. In na podlagi te analize zgradite modele, komu in kakšne oglase prikazati.

Oglasna transakcija je niz povezanih uporabniških dogodkov, ki se začnejo s prikazovanjem oglasa, nato se nekaj zgodi, nato morda nakup, nato pa lahko pride do nakupov znotraj nakupa. Na primer, če je to mobilna aplikacija ali mobilna igra, potem običajno namestitev aplikacije poteka brezplačno, in če se tam kaj naredi, bo morda za to potreben denar. In več ko oseba porabi v aplikaciji, bolj je vredna. Toda za to morate vse povezati.

Obstaja veliko modelov vezave.

Najbolj priljubljeni so:

• Zadnja interakcija, kjer je interakcija klik ali prikaz.
• Prva interakcija, torej prva stvar, ki je osebo pripeljala na stran.
• Linearna kombinacija - vse enako.
• Slabljenje.
• In tako naprej.

In kako je vse skupaj sploh potekalo? Tam sta bila Runtime in Cassandra. Cassandra je bila uporabljena kot shramba transakcij, tj. vse povezane transakcije so bile shranjene vanjo. In ko v Runtime pride nek dogodek, na primer prikaz neke strani ali kaj drugega, je bila Cassandri vložena zahteva - ali obstaja taka oseba ali ne. Nato so bile pridobljene transakcije, ki se nanašajo na to. In povezava je bila vzpostavljena.

In če je sreča, da ima zahteva ID transakcije, potem je enostavno. Ampak ponavadi ni sreče. Zato je bilo treba najti zadnjo transakcijo ali transakcijo z zadnjim klikom itd.

In vse je delovalo zelo dobro, dokler je bila vezava na zadnji klik. Ker je recimo 10 milijonov klikov na dan, 300 milijonov na mesec, če nastavimo okno na mesec. In ker mora biti v Cassandri vse v pomnilniku, da lahko deluje hitro, ker se mora Runtime hitro odzvati, je bilo potrebnih približno 10-15 strežnikov.

In ko so želeli transakcijo povezati z zaslonom, se je takoj izkazalo, da ni tako zabavno. In zakaj? Vidi se, da je treba shraniti 30-krat več dogodkov. In zato potrebujete 30-krat več strežnikov. In izkaže se, da je to nekakšna astronomska številka. Obdržati do 500 strežnikov za povezovanje, kljub dejstvu, da je v Runtime bistveno manj strežnikov, potem je to nekakšna napačna številka. In začeli so razmišljati, kaj storiti.

In smo šli v ClickHouse. In kako to narediti na ClickHouse? Na prvi pogled se zdi, da gre za skupek anti-vzorcev.

• Transakcija raste, vanjo priklapljamo vedno več dogodkov, torej je spremenljiva, ClickHouse pa ne deluje dobro s spremenljivimi objekti.
• Ko obiskovalec pride k nam, moramo izvleči njegove transakcije po ključu, po njegovem ID-ju obiska. To je tudi točkovna poizvedba, tega v ClickHouse ne počnejo. Običajno ima ClickHouse velike ... skeniranje, tukaj pa moramo pridobiti nekaj zapisov. Tudi antivzorec.
• Poleg tega je bila transakcija v jsonu, vendar je niso želeli prepisati, zato so želeli json shraniti nestrukturirano in če je treba, iz njega kaj potegniti. In to je tudi antivzorec.

To je niz antivzorcev.

Vendar se je izkazalo, da je sistem zelo dobro deloval.

Kaj je bilo narejeno? Pojavila se je ClickHouse, v katero so metali polena, razdeljena na zapise. Pojavila se je pripisana storitev, ki je prejemala dnevnike od ClickHouse. Nato sem za vsak vnos po ID-ju obiska prejel transakcije, ki morda še niso bile obdelane in plus posnetke, torej že povezane transakcije, torej rezultat prejšnjega dela. Iz njih sem že naredil logiko, izbral pravo transakcijo, povezal nove dogodke. Ponovno prijavljen. Dnevnik je šel nazaj v ClickHouse, torej gre za stalno cikličen sistem. In poleg tega sem šel na DWH, da bi to tam analiziral.

Prav v tej obliki se ni najbolje obnesel. Da bi ClickHousu olajšali delo, so te zahteve združili v bloke po 1–000 ID-jev obiskov in izvlekli vse transakcije za 2–000 ljudi. In potem je vse delovalo.

Če pogledate znotraj ClickHouse, potem obstajajo samo 3 glavne mize, ki služijo vsemu temu.

Prva tabela, v katero se nalagajo dnevniki, dnevniki pa se nalagajo skoraj brez obdelave.

Druga miza. Skozi materializiran pogled so iz teh dnevnikov izgriznjeni dogodki, ki še niso bili pripisani, torej nepovezani. Z materializiranim pogledom so bile transakcije potegnjene iz teh dnevnikov, da bi ustvarili posnetek. To pomeni, da je poseben materializiran pogled zgradil posnetek, in sicer zadnje akumulirano stanje transakcije.

Tukaj je besedilo, napisano v SQL. V njej bi rad komentiral nekaj pomembnih stvari.

Prva pomembna stvar je možnost izvleka stolpcev in polj iz json v ClickHouse. To pomeni, da ima ClickHouse nekaj metod za delo z json. So zelo, zelo primitivni.

visitParamExtractInt vam omogoča ekstrahiranje atributov iz json, tj. prvi zadetek deluje. Na ta način lahko izvlečete ID transakcije ali ID obiska. Tokrat.

Drugič, tu je uporabljeno zapleteno materializirano polje. Kaj to pomeni? To pomeni, da ga ne morete vnesti v tabelo, torej se ne vstavi, se izračuna in shrani ob vnosu. Pri lepljenju ClickHouse opravi delo namesto vas. In tisto, kar potrebujete pozneje, je že potegnjeno iz json.

V tem primeru je materializirani pogled za neobdelane vrstice. In prva tabela s praktično neobdelanimi dnevniki je pravkar uporabljena. In kaj počne? Prvič, spremeni razvrščanje, tj. razvrščanje zdaj poteka po ID-ju obiska, ker moramo hitro izvleči njegovo transakcijo za določeno osebo.

Druga pomembna stvar je index_granularity. Če ste videli MergeTree, je običajno 8 privzeto index_granularity. Kaj je to? To je parameter redkosti indeksa. V ClickHouse je indeks redek, nikoli ne indeksira vsakega vnosa. To stori vsakih 192. In to je dobro, ko je za izračun potrebnih veliko podatkov, slabo pa, če je malo, ker so stroški veliki. In če zmanjšamo razdrobljenost indeksa, zmanjšamo režijske stroške. Ni ga mogoče zmanjšati na eno, ker morda ni dovolj pomnilnika. Indeks je vedno shranjen v pomnilniku.

Snapshot uporablja tudi nekatere druge zanimive funkcije ClickHouse.

Prvič, to je AggregatingMergeTree. In AggregatingMergeTree shrani argMax, tj. to je stanje transakcije, ki ustreza zadnjemu časovnemu žigu. Transakcije se generirajo ves čas za določenega obiskovalca. In v zadnjem stanju te transakcije smo dodali dogodek in imamo novo stanje. Ponovno je udarilo ClickHouse. In skozi argMax v tem materializiranem pogledu lahko vedno dobimo trenutno stanje.

• Vezava je "ločena" od izvajalnega okolja.
• Shrani in obdela se do 3 milijarde transakcij na mesec. To je za red velikosti več, kot je bilo v Cassandri, torej v tipičnem transakcijskem sistemu.
• Grozd 2x5 strežnikov ClickHouse. 5 strežnikov in vsak strežnik ima repliko. To je celo manj, kot je bilo v Cassandri, da bi lahko izvajali dodeljevanje na podlagi klikov, tukaj pa temelji na vtisih. Se pravi, namesto da bi povečali število strežnikov za 30-krat, jim jih je uspelo zmanjšati.

In zadnji primer je finančna družba Y, ki je analizirala korelacije sprememb tečajev delnic.

In naloga je bila:

• Delnic je približno 5.
• Citati vsakih 100 milisekund so znani.
• Podatki so se zbirali 10 let. Očitno za nekatera podjetja bolj, za nekatera manj.
• Skupaj je približno 100 milijard vrstic.

In treba je bilo izračunati korelacijo sprememb.

Tukaj sta dve delnici in njuni kotaciji. Če se eden dvigne in drugi dvigne, potem je to pozitivna korelacija, tj. eden se dvigne in drugi dvigne. Če gre eden navzgor, kot na koncu grafa, drugi pa dol, potem je to negativna korelacija, tj. ko se eden dvigne, drugi pade.

Če analiziramo te medsebojne spremembe, lahko naredimo napovedi na finančnem trgu.

Toda naloga je težka. Kaj se dela za to? Imamo 100 milijard zapisov, ki vsebujejo: čas, zalogo in ceno. Najprej moramo izračunati 100-milijardkratno tekočo razliko od algoritma cene. RunningDifference je funkcija v ClickHouse, ki zaporedno izračuna razliko med dvema nizoma.

In potem morate izračunati korelacijo, korelacijo pa je treba izračunati za vsak par. Za 5 delnic so pari 000 milijona. In to je veliko, tj. 12,5-krat je treba izračunati samo takšno korelacijsko funkcijo.

In če je kdo pozabil, potem sta ͞x in ͞y mat. pričakovano vzorčenje. To pomeni, da ni treba samo izračunati korenov in vsot, ampak tudi še eno vsoto znotraj teh vsot. Kup izračunov je treba opraviti 12,5-milijonkrat in še razvrščenih po urah. Imamo tudi veliko ur. In to morate storiti v 60 sekundah. To je šala.

Vsaj nekako je bilo treba imeti čas, saj je vse to delovalo zelo, zelo počasi, preden je prišel ClickHouse.

Poskušali so ga izračunati na Hadoopu, na Sparku, na Greenplumu. In vse to je bilo zelo počasno ali drago. To pomeni, da je bilo mogoče nekako izračunati, potem pa je bilo drago.

In potem je prišel ClickHouse in stvari so šle veliko bolje.

Opozarjam vas, da imamo problem z lokalnostjo podatkov, ker korelacije ni mogoče lokalizirati. Ne moremo dati nekaj podatkov na en strežnik, nekaj na drugega in računati, vse podatke moramo imeti povsod.

Kaj so storili? Na začetku so podatki lokalizirani. Vsak strežnik hrani podatke o ceni določenega nabora delnic. In se ne prekrivajo. Zato je možno izračunati logReturn vzporedno in neodvisno, vse to se zaenkrat dogaja vzporedno in porazdeljeno.

Potem smo se odločili zmanjšati te podatke, pri tem pa ne izgubiti izraznosti. Zmanjšajte uporabo nizov, tj. za vsako časovno obdobje naredite niz delnic in niz cen. Zato zavzame veliko manj podatkovnega prostora. In z njimi je malo lažje delati. To so skoraj vzporedne operacije, se pravi, da vzporedno delno beremo in nato pišemo na strežnik.

Po tem se lahko ponovi. Črka "r" pomeni, da smo te podatke posnemali. Se pravi, da imamo na vseh treh strežnikih iste podatke – to so polja.

In potem lahko s posebnim skriptom iz tega niza 12,5 milijona korelacije, ki jih je treba izračunati, naredite pakete. Se pravi 2 nalog s 500 pari korelacij. In to nalogo je treba izračunati na določenem strežniku ClickHouse. Ima vse podatke, ker so podatki enaki in jih lahko izračuna zaporedno.

Še enkrat, tako je videti. Prvič, v tej strukturi imamo vse podatke: čas, deleže, ceno. Nato smo izračunali logReturn, torej podatke enake strukture, le da imamo namesto cene že logReturn. Nato so bili predelani, tj. dobili smo čas in groupArray za delnice in cene. Podvojeno. Po tem smo ustvarili kup nalog in jih posredovali ClickHouseu, da jih je preštel. In deluje.

Pri dokazu koncepta je bila naloga podnaloga, kar pomeni, da je bilo vzetih manj podatkov. In samo trije strežniki.

Ti prvi dve fazi: izračun Log_return in zavijanje v nize sta trajali približno eno uro.

In izračun korelacije je približno 50 ur. A 50 ur je premalo, saj so včasih delali tedne. To je bil velik uspeh. In če štejete, potem je bilo 70-krat na sekundo vse prešteto v tej gruči.

Najpomembneje pa je, da je ta sistem praktično brez ozkih grl, se pravi, da se skalira skoraj linearno. In to so preverili. Uspešno povečano.

• Pravilna shema je polovica uspeha. In prava shema je uporaba vseh potrebnih tehnologij ClickHouse.
• Summing/AggregatingMergeTrees sta tehnologiji, ki vam omogočata združevanje ali obravnavanje posnetka stanja kot posebnega primera. In veliko stvari močno poenostavi.
• Materializirani pogledi vam omogočajo, da obidete omejitev enega indeksa. Mogoče nisem povedal zelo jasno, toda ko smo nalagali dnevnike, so bili neobdelani dnevniki v tabeli z enim indeksom, dnevniki atributov pa v tabeli, tj. isti podatki, le filtrirani, vendar je bil indeks popolnoma drugi. Zdi se, da gre za iste podatke, vendar različno razvrščanje. Materializirani pogledi pa vam omogočajo, da obidete takšno omejitev ClickHouse, če jo potrebujete.
• Zmanjšajte razdrobljenost indeksa za poizvedbe točk.
• Pametno porazdelite podatke, poskušajte čim bolj lokalizirati podatke znotraj strežnika. Poskusite zagotoviti tudi, da zahteve čim bolj uporabljajo lokalizacijo, kjer je to mogoče.

In če povzamemo ta kratek govor, lahko rečemo, da je ClickHouse zdaj trdno zasedel ozemlje tako komercialnih baz podatkov kot odprtokodnih baz podatkov, torej posebej za analitiko. Popolnoma se prilega tej pokrajini. In še več, počasi začne izrivati ​​druge, ker ko imate ClickHouse, ne potrebujete InfiniDB. Vertika morda kmalu ne bo več potrebna, če naredijo normalno podporo za SQL. Uživajte!

-Hvala za poročilo! Zelo zanimivo! So bile kakšne primerjave z Apache Phoenix?

Ne, nisem slišal nikogar primerjati. Mi in Yandex poskušamo slediti vsem primerjavam ClickHouse z različnimi zbirkami podatkov. Ker če se nenadoma izkaže, da je nekaj hitrejše od ClickHouse, Lesha Milovidov ponoči ne more spati in začne hitro pospeševati. Za takšno primerjavo še nisem slišal.

• (Aleksej Milovidov) Apache Phoenix je motor SQL, ki ga poganja Hbase. Hbase je v glavnem za scenarij dela s ključno vrednostjo. V vsaki vrstici je lahko poljubno število stolpcev s poljubnimi imeni. To lahko rečemo o sistemih, kot sta Hbase, Cassandra. In ravno težke analitične poizvedbe jim ne bodo delovale normalno. Lahko pa mislite, da dobro delujejo, če s ClickHouse niste imeli izkušenj.

• Hvala

  • Dober večer Ta tema me že precej zanima, ker imam analitični podsistem. Toda ko pogledam ClickHouse, imam občutek, da je ClickHouse zelo primeren za analizo dogodkov, spremenljiv. In če moram analizirati veliko poslovnih podatkov s kupom velikih tabel, potem ClickHouse, kolikor razumem, ni zelo primeren zame? Še posebej, če se spremenijo. Je to res ali obstajajo primeri, ki to lahko ovržejo?

  • To je prav. In to velja za večino specializiranih analitičnih baz podatkov. Prilagojeni so dejstvu, da obstaja ena ali več velikih tabel, ki so spremenljive, in za veliko majhnih, ki se počasi spreminjajo. To pomeni, da ClickHouse ni kot Oracle, kamor lahko postavite vse in zgradite nekaj zelo zapletenih poizvedb. Za učinkovito uporabo ClickHouse morate zgraditi shemo na način, ki dobro deluje v ClickHouse. To pomeni, izogibajte se pretirani normalizaciji, uporabljajte slovarje, poskusite ustvariti manj dolgih povezav. In če je shema zgrajena na ta način, potem je mogoče podobne poslovne naloge rešiti na ClickHouse veliko bolj učinkovito kot na tradicionalni relacijski bazi podatkov.

Hvala za poročilo! Imam vprašanje o zadnjem finančnem primeru. Imeli so analitiko. Treba je bilo primerjati, kako gredo gor in dol. Razumem, da ste sistem zgradili posebej za to analitiko? Če bodo jutri na primer potrebovali kakšno drugo poročilo o teh podatkih, ali bodo morali znova sestaviti shemo in naložiti podatke? Se pravi, narediti nekakšno predprocesiranje, da dobimo zahtevo?

Seveda je to uporaba ClickHouse za zelo specifično nalogo. To bi lahko bolj tradicionalno rešili znotraj Hadoopa. Za Hadoop je to idealna naloga. Toda na Hadoopu je zelo počasen. In moj cilj je dokazati, da lahko ClickHouse reši naloge, ki se običajno rešujejo na popolnoma drugačna sredstva, a hkrati to počne veliko bolj učinkovito. Prilagojen je za določeno nalogo. Jasno je, da če obstaja problem z nečim podobnim, potem ga je mogoče rešiti na podoben način.

To je jasno. Rekli ste, da je bilo obdelanih 50 ur. Je od samega začetka, kdaj ste naložili podatke ali dobili rezultate?

Da, da.

OK hvala lepa.

To je v gruči s tremi strežniki.

Pozdravi! Hvala za poročilo! Vse je zelo zanimivo. Ne bom spraševal malo o funkcionalnosti, ampak o uporabi ClickHouse v smislu stabilnosti. Se pravi, ste jih imeli, ste jih morali obnoviti? Kako se ClickHouse obnaša v tem primeru? Pa se je zgodilo, da ste imeli tudi repliko? Na primer, naleteli smo na težavo s ClickHouse, ko še vedno preseže svojo mejo in pade.

Idealnih sistemov seveda ni. In ClickHouse ima tudi svoje težave. Toda ali ste slišali, da Yandex.Metrica že dolgo ne deluje? Verjetno ne. Zanesljivo deluje od 2012-2013 na ClickHouse. Enako lahko rečem o svoji izkušnji. Nikoli nismo imeli popolnih neuspehov. Nekatere delne stvari so se lahko zgodile, vendar nikoli niso bile dovolj kritične, da bi resneje vplivale na poslovanje. Nikoli se ni zgodilo. ClickHouse je precej zanesljiv in se ne zruši naključno. Ni ti treba skrbeti za to. To ni surova stvar. To so dokazala številna podjetja.

Zdravo! Rekli ste, da morate takoj razmisliti o podatkovni shemi. Kaj če bi se zgodilo? Moji podatki kar dežujejo in dežujejo. Šest mesecev mine in razumem, da je nemogoče živeti tako, moram znova naložiti podatke in nekaj narediti z njimi.

To je seveda odvisno od vašega sistema. Obstaja več načinov, kako to storiti skoraj brez ustavljanja. Ustvarite lahko na primer materializiran pogled, v katerem naredite drugačno podatkovno strukturo, če jo je mogoče enolično preslikati. Se pravi, če omogoča preslikavo z uporabo ClickHouse, tj. ekstrahiranje nekaterih stvari, spremembo primarnega ključa, spremembo particioniranja, potem lahko naredite materializiran pogled. Tam prepišite svoje stare podatke, novi se bodo samodejno zapisali. In nato preprosto preklopite na uporabo materializiranega pogleda, nato preklopite zapis in uničite staro tabelo. To je na splošno neprekinjena metoda.

Hvala.

Vir: www.habr.com