ClickHouse naudojimo realiose programose teorija ir praktika. Aleksandras Zaicevas (2018 m.)

Nepaisant to, kad dabar beveik visur yra daug duomenų, analitinės duomenų bazės vis dar yra gana egzotiškos. Jie menkai žinomi ir dar blogiau gali juos efektyviai panaudoti. Daugelis ir toliau „valgo kaktusą“ su MySQL ar PostgreSQL, kurios yra skirtos kitiems scenarijams, kenčia nuo NoSQL arba permoka už komercinius sprendimus. ClickHouse pakeičia žaidimo taisykles ir gerokai sumažina slenkstį įžengti į analitinės DBVS pasaulį.

Ataskaita iš „BackEnd Conf 2018“ ir publikuojama gavus pranešėjo leidimą.

Kas aš esu ir kodėl aš kalbu apie ClickHouse? Esu „LifeStreet“, kuri naudoja ClickHouse, plėtros direktorius. Be to, aš esu Altinity įkūrėjas. Tai yra „Yandex“ partneris, reklamuojantis „ClickHouse“ ir padedantis „Yandex“ padaryti „ClickHouse“ sėkmingesnį. Taip pat pasiruošę pasidalinti žiniomis apie ClickHouse.

Ir aš nesu Petios Zaicevo brolis. Manęs dažnai apie tai klausia. Ne, mes nesame broliai.

„Visi žino“, kad ClickHouse:

• Labai greitai,
• Labai patogu
• Naudojamas Yandex.

Kiek mažiau žinoma, kokiose įmonėse ir kaip jis naudojamas.

Aš jums pasakysiu, kodėl, kur ir kaip naudojamas „ClickHouse“, išskyrus „Yandex.

Papasakosiu kaip konkrečios užduotys sprendžiamos ClickHouse pagalba skirtingose ​​įmonėse, kokius ClickHouse įrankius galite naudoti savo užduotims atlikti ir kaip jie buvo naudojami skirtingose ​​įmonėse.

Aš pasirinkau tris pavyzdžius, rodančius ClickHouse iš skirtingų kampų. Manau, bus įdomu.

Pirmas klausimas yra: „Kodėl mums reikia ClickHouse? Atrodo, kad tai gana akivaizdus klausimas, tačiau atsakymo į jį yra ne vienas.

• Pirmasis atsakymas yra dėl našumo. ClickHouse yra labai greitas. „ClickHouse“ analizė taip pat yra labai greita. Jis dažnai gali būti naudojamas, kai kažkas vyksta labai lėtai arba labai blogai.
• Antrasis atsakymas yra kaina. Ir pirmiausia mastelio keitimo kaina. Pavyzdžiui, Vertica yra puiki duomenų bazė. Tai labai gerai veikia, jei neturite daug terabaitų duomenų. Tačiau kalbant apie šimtus terabaitų ar petabaitų, licencijos ir palaikymo kaina yra gana didelė. Ir tai brangu. Ir ClickHouse yra nemokama.
• Trečias atsakymas – veiklos sąnaudos. Tai šiek tiek kitoks požiūris. „RedShift“ yra puikus analogas. Naudodami RedShift galite labai greitai priimti sprendimą. Veiks neblogai, bet tuo pačiu kas valandą, kiekvieną dieną ir kas mėnesį „Amazon“ mokėsite gana brangiai, nes tai ženkliai brangi paslauga. „Google BigQuery“ taip pat. Jei kas nors jį naudojo, jis žino, kad ten galite pateikti keletą užklausų ir staiga gauti šimtų dolerių sąskaitą.

„ClickHouse“ neturi šių problemų.

Kur dabar naudojamas ClickHouse? Be „Yandex“, „ClickHouse“ naudojamas daugelyje skirtingų verslų ir įmonių.

• Visų pirma, tai yra žiniatinklio programų analizė, ty tai yra „Yandex“ naudojimo atvejis.
• Daugelis „AdTech“ įmonių naudoja „ClickHouse“.
• Daugybė įmonių, kurioms reikia analizuoti skirtingų šaltinių operacijų žurnalus.
• Kelios įmonės naudoja „ClickHouse“ saugos žurnalams stebėti. Jie įkelia juos į ClickHouse, rengia ataskaitas ir gauna reikiamus rezultatus.
• Įmonės pradeda tai naudoti finansinėje analizėje, t. y. pamažu prie ClickHouse artėja ir didieji verslai.
• debesų pliūpsnis. Jei kas nors seka ClickHouse, tai tikriausiai yra girdėjęs šios įmonės pavadinimą. Tai vienas iš esminių bendruomenės prisidėjusiųjų. Ir jie turi labai rimtą ClickHouse instaliaciją. Pavyzdžiui, jie sukūrė „Kafka Engine“, skirtą „ClickHouse“.
• Pradėjo naudotis telekomunikacijų įmonės. Kelios įmonės naudoja ClickHouse kaip koncepcijos įrodymą arba jau gamyboje.
• Viena įmonė naudoja ClickHouse gamybos procesams stebėti. Jie išbando mikroschemas, nurašo krūvą parametrų, yra apie 2 charakteristikų. Tada jie analizuoja, ar žaidimas geras, ar blogas.
• Blockchain analizė. Yra tokia Rusijos įmonė kaip Bloxy.info. Tai ethereum tinklo analizė. Jie taip pat padarė tai „ClickHouse“.

Ir dydis nesvarbu. Yra daug įmonių, kurios naudoja vieną mažą serverį. Ir jis leidžia jiems išspręsti savo problemas. Ir dar daugiau įmonių naudoja dideles daugelio serverių grupes arba keliasdešimt serverių.

Ir jei pažvelgsite į įrašus, tada:

• „Yandex“: daugiau nei 500 serverių, juose per dieną saugoma 25 milijardai įrašų.
• LifeStreet: 60 serverių, maždaug 75 milijardai įrašų per dieną. Yra mažiau serverių, daugiau įrašų nei „Yandex.
• CloudFlare: 36 serveriai, jie išsaugo 200 milijardų įrašų per dieną. Jie turi dar mažiau serverių ir saugo dar daugiau duomenų.
• Bloomberg: 102 serveriai, apie trilijonas įrašų per dieną. Rekordininkas.

Geografiškai tai taip pat daug. Šiame žemėlapyje parodytas šilumos žemėlapis, kur „ClickHouse“ naudojamas pasaulyje. Čia aiškiai išsiskiria Rusija, Kinija, Amerika. Europos šalių nedaug. Ir yra 4 klasteriai.

Tai lyginamoji analizė, nereikia ieškoti absoliučių skaičių. Tai lankytojų, kurie skaito medžiagą anglų kalba Altinity svetainėje, analizė, nes rusakalbių ten nėra. O Rusija, Ukraina, Baltarusija, t.y. rusakalbė bendruomenės dalis, tai daugiausia vartotojų. Tada ateina JAV ir Kanada. Kinija labai vejasi. Prieš pusmetį Kinijos ten beveik nebuvo, dabar Kinija jau aplenkė Europą ir toliau auga. Neatsilieka ir Senoji Europa, o ClickHouse naudojimo lyderė, kaip bebūtų keista, yra Prancūzija.

Kodėl aš visa tai sakau? Parodyti, kad ClickHouse tampa standartiniu didelių duomenų analizės sprendimu ir jau naudojamas daug kur. Jei jį naudojate, esate tinkamoje tendencijoje. Jei dar nenaudojate, tuomet negalite bijoti, kad liksite vienas ir niekas jums nepadės, nes daugelis tai jau daro.

Tai tikro ClickHouse naudojimo keliose įmonėse pavyzdžiai.

• Pirmasis pavyzdys yra skelbimų tinklas: perkėlimas iš Vertica į ClickHouse. Ir aš žinau keletą įmonių, kurios perėjo iš „Vertica“ arba šiuo metu pereina.
• Antrasis pavyzdys yra operacijų saugykla „ClickHouse“. Tai pavyzdys, paremtas antipatternais. Viskas, ko „ClickHouse“ nereikėtų daryti pagal kūrėjų patarimą, daroma čia. Ir tai daroma taip efektyviai, kad veikia. Ir tai veikia daug geriau nei įprastas sandorio sprendimas.
• Trečiasis pavyzdys yra paskirstytasis skaičiavimas „ClickHouse“. Iškilo klausimas, kaip ClickHouse galima integruoti į Hadoop ekosistemą. Parodysiu pavyzdį, kaip įmonė padarė kažką panašaus į žemėlapio mažinimo konteinerį ClickHouse, stebėdama duomenų lokalizaciją ir pan., kad apskaičiuotų labai nebanalią užduotį.

• „LifeStreet“ yra „Ad Tech“ įmonė, turinti visas su skelbimų tinklu susijusias technologijas.
• Ji užsiima skelbimų optimizavimu, programiniu kainų siūlymu.
• Daug duomenų: apie 10 milijardų įvykių per dieną. Tuo pačiu metu ten vykstančius renginius galima suskirstyti į keletą porūšių.
• Šių duomenų klientų yra daug, ir tai ne tik žmonės, daug daugiau – tai įvairūs algoritmai, kurie užsiima programiniu kainų siūlymu.

Įmonė nuėjo ilgą ir sudėtingą kelią. Ir aš apie tai kalbėjau HighLoad. Pirma, „LifeStreet“ perėjo iš „MySQL“ (su trumpam sustojimu „Oracle“) į „Vertica“. Ir apie tai galite rasti istoriją.

Ir viskas buvo labai gerai, bet greitai paaiškėjo, kad duomenys auga, o Vertica brangi. Todėl buvo ieškoma įvairių alternatyvų. Kai kurie iš jų išvardyti čia. Ir iš tikrųjų mes atlikome beveik visų duomenų bazių, kurios buvo rinkoje nuo 13 iki 16 metų ir buvo maždaug tinkamos funkcionalumo, koncepcijos įrodymą arba kartais našumo testavimą. Ir aš taip pat kalbėjau apie kai kuriuos iš jų „HighLoad“.

Užduotis pirmiausia buvo migruoti iš „Vertica“, nes duomenys augo. Ir bėgant metams jie augo eksponentiškai. Tada jie pateko į lentyną, bet vis tiek. Ir prognozuojant šį augimą, verslo reikalavimus duomenų kiekiui, dėl kurio reikėjo atlikti kažkokią analizę, buvo aišku, kad netrukus bus kalbama apie petabaitus. O mokėti už petabaitus jau labai brangu, tad ieškojome alternatyvos kur nuvažiuoti.

Kur eiti? Ir ilgą laiką buvo visiškai neaišku, kur kreiptis, nes iš vienos pusės yra komercinės duomenų bazės, atrodo, kad jos veikia gerai. Kai kurie veikia beveik taip pat, kaip Vertica, kai kurie prasčiau. Bet jie visi brangūs, nieko pigesnio ir geresnio nerasi.

Kita vertus, yra atvirojo kodo sprendimų, kurių nėra labai daug, t.y. analitikai juos galima suskaičiuoti ant pirštų. Ir jie nemokami arba pigūs, bet lėti. O jiems dažnai trūksta reikiamo ir naudingo funkcionalumo.

Ir nebuvo ko derinti to gėrio, kuris yra komercinėse duomenų bazėse, ir visą nemokamą, kuris yra atvirojo kodo.

Nieko nebuvo, kol netikėtai „Yandex“ ištraukė „ClickHouse“ kaip magas iš kepurės, kaip triušis. Ir tai buvo netikėtas sprendimas, jie vis dar užduoda klausimą: „Kodėl?“, Bet vis dėlto.

Ir iš karto 2016 m. vasarą pradėjome žiūrėti, kas yra ClickHouse. Ir paaiškėjo, kad kartais jis gali būti greitesnis nei Vertica. Išbandėme skirtingus scenarijus pagal skirtingas užklausas. Ir jei užklausa naudojo tik vieną lentelę, tai yra be jokių sujungimų (join), tada ClickHouse buvo dvigubai greitesnis nei Vertica.

Aš nebuvau pernelyg tingus ir kitą dieną pažiūrėjau į „Yandex“ testus. Ten tas pats: ClickHouse yra dvigubai greitesnis nei Vertica, todėl dažnai apie tai kalba.

Bet jei užklausose yra sujungimų, tada viskas pasirodo ne itin vienareikšmiškai. Ir ClickHouse gali būti dvigubai lėtesnis nei Vertica. Ir jei šiek tiek pataisysite prašymą ir perrašysite, tada jie bus maždaug vienodi. Neblogai. Ir nemokamai.

Ir gavęs testo rezultatus bei pažvelgęs iš skirtingų kampų, LifeStreet pateko į ClickHouse.

Jau 16 metų, primenu. Tai buvo tarsi pokštas apie peles, kurios verkė ir dūrė, bet toliau valgė kaktusą. Ir tai buvo išsamiai aprašyta, yra vaizdo įrašas apie tai ir pan.

Todėl plačiau apie tai nekalbėsiu, kalbėsiu tik apie rezultatus ir keletą įdomių dalykų, apie kuriuos tada nekalbėjau.

Rezultatai:

• Sėkmingas perkėlimas ir daugiau nei metai sistema jau veikia gamyboje.
• Padidėjo našumas ir lankstumas. Iš 10 milijardų įrašų, kuriuos galėtume sau leisti saugoti per dieną ir po to trumpą laiką, LifeStreet dabar saugo 75 milijardus įrašų per dieną ir gali tai daryti 3 mėnesius ar ilgiau. Jei skaičiuojate piko metu, tai yra iki milijono įvykių per sekundę. Į šią sistemą per dieną ateina daugiau nei milijonas SQL užklausų, daugiausia iš skirtingų robotų.
• Nepaisant to, kad „ClickHouse“ buvo naudojama daugiau serverių nei „Vertica“, jie taip pat taupė aparatinę įrangą, nes „Verticoje“ buvo naudojami gana brangūs SAS diskai. ClickHouse naudojo SATA. Ir kodėl? Kadangi Vertica įdėklas yra sinchroninis. O sinchronizacija reikalauja, kad diskai per daug nesulėtėtų, o taip pat ir tinklas per daug nesulėtėtų, tai yra gana brangi operacija. Ir ClickHouse įterpimas yra asinchroninis. Be to, visada galite viską rašyti lokaliai, tam nereikia papildomų išlaidų, todėl duomenis į ClickHouse galima įterpti daug greičiau nei į Vertiką, net ir lėtesniuose diskuose. Ir skaitymas yra maždaug tas pats. Skaitant SATA, jei jie yra RAID, tai viskas yra pakankamai greita.
• Neribojama licencija, t. y. 3 petabaitai duomenų 60 serverių (20 serverių yra viena kopija) ir 6 trilijonai faktų ir suvestinių įrašų. Nieko panašaus negalėjo sau leisti „Vertica“.

Dabar šiame pavyzdyje kreipiuosi į praktinius dalykus.

• Pirmasis yra veiksminga schema. Daug kas priklauso nuo schemos.
• Antrasis yra efektyvus SQL generavimas.

Įprasta OLAP užklausa yra pasirinkimas. Kai kurie stulpeliai pereina prie grupavimo pagal, kai kurie stulpeliai – į agregavimo funkcijas. Yra kur, kurią galima pavaizduoti kaip kubo gabalą. Visa grupė pagal gali būti laikoma projekcija. Štai kodėl ji vadinama daugiamatine duomenų analize.

Ir dažnai tai yra modeliuojama žvaigždės schemos pavidalu, kai yra pagrindinis faktas ir šio fakto charakteristikos išilgai šonų, išilgai spindulių.

O kalbant apie fizinį dizainą, kaip jis dera ant stalo, jie paprastai pateikia normalizuotą vaizdą. Galite denormalizuoti, bet tai brangu diske ir nėra labai efektyvu atliekant užklausas. Todėl jie paprastai sudaro normalizuotą vaizdą, t. y. faktų lentelę ir daug, daug matmenų lentelių.

Bet „ClickHouse“ tai neveikia gerai. Yra dvi priežastys:

• Pirmoji dėl to, kad ClickHouse nėra labai gerų prisijungimų, t.y. yra prisijungimų, bet jie yra blogi. Nors blogai.
• Antra, lentelės neatnaujinamos. Paprastai šiose plokštėse, esančiose aplink žvaigždžių grandinę, reikia ką nors pakeisti. Pavyzdžiui, kliento vardas, įmonės pavadinimas ir kt. Ir tai neveikia.

Ir „ClickHouse“ yra išeitis iš to. net du:

• Pirmasis yra žodynų naudojimas. Išoriniai žodynai yra tai, kas 99% padeda išspręsti žvaigždžių schemos, atnaujinimų ir pan.
• Antrasis yra masyvų naudojimas. Masyvai taip pat padeda atsikratyti sujungimų ir normalizavimo problemų.

• Nereikia prisijungti.
• Atnaujinama. Nuo 2018 m. kovo mėn. atsirado nedokumentuota galimybė (dokumentacijoje to nerasite) atnaujinti žodynus iš dalies, t.y. tuos, kurie pasikeitė. Praktiškai tai tarsi stalas.
• Visada atmintyje, todėl prisijungimas prie žodyno veikia greičiau, nei jei tai būtų lentelė, kuri yra diske ir dar nėra faktas, kad ji yra talpykloje, greičiausiai ne.

• Jums taip pat nereikia prisijungimų.
• Tai kompaktiškas „1 su daugeliu“ vaizdas.
• Ir mano nuomone, masyvai yra sukurti geekams. Tai yra lambda funkcijos ir pan.

Tai ne raudoniems žodžiams. Tai labai galinga funkcija, leidžianti atlikti daugybę dalykų labai paprastai ir elegantiškai.

Tipiški pavyzdžiai, padedantys išspręsti masyvus. Šie pavyzdžiai yra pakankamai paprasti ir aiškūs:

• Ieškoti pagal žymas. Jei turite žymų su grotelėmis ir norite rasti kai kuriuos įrašus naudodami grotažymę.
• Ieškokite pagal rakto-reikšmių poras. Taip pat yra keletas atributų, turinčių reikšmę.
• Saugomi raktų, kuriuos reikia išversti į ką nors kita, sąrašai.

Visas šias užduotis galima išspręsti be masyvų. Žymos gali būti dedamos į kokią nors eilutę ir pasirenkamos reguliariuoju posakiu arba atskiroje lentelėje, bet tuomet reikia atlikti sujungimus.

O „ClickHouse“ jums nieko nereikia daryti, užtenka aprašyti grotažymių eilučių masyvą arba sukurti įdėtą struktūrą raktų-reikšmių sistemoms.

Įdėta struktūra gali būti ne pats geriausias pavadinimas. Tai yra du masyvai, kurių pavadinime yra bendra dalis ir kai kurios susijusios savybės.

Ir labai paprasta ieškoti pagal žymą. Turėti funkciją has, kuris patikrina, ar masyve yra elementas. Visi rado visus įrašus, susijusius su mūsų konferencija.

Ieškoti pagal subid yra šiek tiek sudėtingesnė. Pirmiausia turime rasti rakto indeksą, tada paimti elementą su šiuo indeksu ir patikrinti, ar ši reikšmė yra tai, ko mums reikia. Tačiau jis yra labai paprastas ir kompaktiškas.

Reguliarus posakis, kurį norėtumėte parašyti, jei viską laikytumėte vienoje eilutėje, pirmiausia būtų gremėzdiškas. Ir, antra, jis veikė daug ilgiau nei du masyvai.

Kitas pavyzdys. Turite masyvą, kuriame saugote ID. Ir jūs galite juos išversti į vardus. Funkcija arrayMap. Tai tipiška lambda funkcija. Ten perduodi lambda išraiškas. Ir ji iš žodyno ištraukia kiekvieno ID vardo reikšmę.

Paiešką galima atlikti tuo pačiu būdu. Perduodama predikato funkcija, kuri patikrina, ką elementai atitinka.

Šie dalykai labai supaprastina grandinę ir išsprendžia daugybę problemų.

Tačiau kita problema, su kuria susiduriame ir kurią norėčiau paminėti, yra veiksmingos užklausos.

• ClickHouse neturi užklausų planavimo priemonės. Visiškai ne.
• Nepaisant to, vis dar reikia planuoti sudėtingas užklausas. Kokiais atvejais?
• Jei užklausoje yra keli sujungimai, juos supakuojate į požymius. Ir jų vykdymo tvarka yra svarbi.
• O antrasis – jei prašymas išplatintas. Kadangi paskirstytoje užklausoje paskirstytas vykdomas tik vidinis požymis, o visa kita perduodama vienam serveriui, prie kurio prisijungėte ir ten įvykdėte. Todėl, jei paskirstėte užklausas su daugybe prisijungimų (join), tuomet turite pasirinkti tvarką.

Ir net paprastesniais atvejais kartais taip pat reikia atlikti planuotojo darbą ir šiek tiek perrašyti užklausas.

Štai pavyzdys. Kairėje pusėje yra užklausa, rodanti 5 populiariausias šalis. Ir tai, mano nuomone, užtrunka 2,5 sekundės. Ir dešinėje pusėje ta pati užklausa, tik šiek tiek perrašyta. Užuot grupuodami pagal eilutę, pradėjome grupuoti pagal raktą (int). Ir tai greičiau. Ir tada prie rezultato prijungėme žodyną. Vietoj 2,5 sekundės užklausa trunka 1,5 sekundės. Tai yra gerai.

Panašus pavyzdys su perrašymo filtrais. Štai prašymas Rusijai. Jis veikia 5 sekundes. Jei perrašysime taip, kad vėl palygintume ne eilutę, o skaičius su kažkokiu tų raktų rinkiniu, kurie yra susiję su Rusija, tai bus daug greičiau.

Tokių gudrybių yra daug. Ir jie leidžia žymiai pagreitinti užklausas, kurios, jūsų manymu, jau veikia greitai arba, atvirkščiai, lėtai. Juos galima pagaminti dar greičiau.

• Maksimalus darbas paskirstytu režimu.
• Rūšiavimas pagal minimalius tipus, kaip aš dariau pagal int.
• Jei yra kokių nors sujungimų (join), žodynų, tai geriau juos daryti kraštutiniu atveju, kai jau turite duomenis bent iš dalies sugrupuoti, tada sujungimo operacija arba žodyno iškvietimas bus skambinamas mažiau kartų ir bus greitesnis .
• Filtrų keitimas.

Yra ir kitų metodų, ne tik tų, kuriuos pademonstravau. Ir visos jos kartais gali gerokai paspartinti užklausų vykdymą.

Pereikime prie kito pavyzdžio. Įmonė X iš JAV. Ką ji daro?

Buvo tokia užduotis:

• Reklaminių operacijų susiejimas neprisijungus.
• Įvairių įrišimo modelių modeliavimas.

Koks yra scenarijus?

Eilinis lankytojas ateina į svetainę, pavyzdžiui, 20 kartų per mėnesį iš skirtingų skelbimų arba tiesiog taip kartais ateina be jokių skelbimų, nes prisimena šią svetainę. Pasižiūri kažkokius gaminius, deda į krepšelį, išima iš krepšelio. Ir galų gale kažkas perka.

Pagrįsti klausimai: "Kas turėtų mokėti už reklamą, jei reikia?" ir „Kokia reklama jį paveikė, jei tokia buvo?“. Tai yra, kodėl jis pirko ir kaip priversti tokius žmones kaip šis pirkti?

Norint išspręsti šią problemą, reikia tinkamai sujungti svetainėje vykstančius įvykius, tai yra kažkaip tarp jų sukurti ryšį. Tada jie siunčiami analizei į DWH. Remdamiesi šia analize, sukurkite modelius, kam ir kokius skelbimus rodyti.

Skelbimo operacija – tai susijusių naudotojo įvykių rinkinys, kuris prasideda nuo skelbimo rodymo, tada kažkas įvyksta, tada galbūt įsigyjama, o per pirkimą gali būti ir pirkimų. Pavyzdžiui, jei tai yra mobilioji programa ar mobilusis žaidimas, tada paprastai programos diegimas vyksta nemokamai, o jei ten kažkas bus padaryta, už tai gali prireikti pinigų. Ir kuo daugiau žmogus išleidžia paraiškoje, tuo ji vertingesnė. Bet tam reikia viską sujungti.

Yra daug įrišimo modelių.

Populiariausi yra:

• Paskutinė sąveika, kai sąveika yra paspaudimas arba parodymas.
• Pirmoji sąveika, t. y. pirmas dalykas, atvedęs žmogų į svetainę.
• Linijinis derinys – visi vienodai.
• Silpninimas.
• Ir taip toliau.

Ir kaip visa tai veikė iš pradžių? Buvo Runtime ir Cassandra. „Cassandra“ buvo naudojama kaip operacijų saugykla, t.y. joje buvo saugomos visos susijusios operacijos. Ir kai „Runtime“ ateina koks nors įvykis, pavyzdžiui, rodo kokį nors puslapį ar dar ką nors, tada buvo pateiktas prašymas Kasandrai – yra toks žmogus ar ne. Tada buvo gauti su juo susiję sandoriai. Ir ryšys buvo užmegztas.

Ir jei pasisekė, kad užklausoje yra operacijos ID, tai paprasta. Bet dažniausiai nesiseka. Todėl reikėjo rasti paskutinę operaciją arba operaciją su paskutiniu paspaudimu ir pan.

Ir viskas veikė labai gerai, kol įrišimas buvo iki paskutinio paspaudimo. Nes yra, tarkime, 10 milijonų paspaudimų per dieną, 300 milijonų per mėnesį, jei nustatysime langą mėnesiui. O kadangi Cassandra viskas turi būti atmintyje, kad veiktų greitai, nes Runtime reikia greitai reaguoti, tai užtruko apie 10-15 serverių.

Ir kai jie norėjo susieti operaciją su ekranu, tai iškart pasirodė ne taip smagu. Ir kodėl? Matyti, kad reikia saugoti 30 kartų daugiau įvykių. Ir atitinkamai jums reikia 30 kartų daugiau serverių. Ir pasirodo, kad tai kažkokia astronominė figūra. Jei norite išlaikyti iki 500 serverių, kad būtų galima susieti, nepaisant to, kad Runtime serverių yra žymiai mažiau, tai yra kažkoks neteisingas skaičius. Ir jie pradėjo galvoti, ką daryti.

Ir mes nuėjome į ClickHouse. O kaip tai padaryti ClickHouse? Iš pirmo žvilgsnio atrodo, kad tai yra anti-raktų rinkinys.

• Sandoris auga, mes prie jo prijungiame vis daugiau įvykių, t.y. jis yra kintamas, o ClickHouse nelabai veikia su keičiamais objektais.
• Kai lankytojas ateina pas mus, turime ištraukti jo operacijas pagal raktą, pagal jo apsilankymo ID. Tai taip pat taškinė užklausa, jie to nedaro „ClickHouse“. Paprastai ClickHouse atlieka didelius … nuskaitymus, bet čia mums reikia gauti kai kuriuos įrašus. Taip pat antimodelis.
• Be to, sandoris buvo json, bet jie nenorėjo jos perrašyti, todėl norėjo saugoti json nestruktūrizuotu būdu ir, jei reikia, ką nors iš jo ištraukti. Ir tai taip pat yra antipatternas.

Tai yra antipatternų rinkinys.

Tačiau vis dėlto paaiškėjo, kad buvo sukurta sistema, kuri veikė labai gerai.

Kas buvo padaryta? Atsirado ClickHouse, į kurį buvo įmesti rąstai, suskirstyti į įrašus. Pasirodė priskirta paslauga, kuri gavo žurnalus iš ClickHouse. Po to kiekvienam įrašui pagal apsilankymo ID gavau dar galbūt neapdorotas operacijas ir momentines nuotraukas, t.y. jau susietas operacijas, būtent ankstesnio darbo rezultatą. Iš jų jau sukūriau logiką, pasirinkau teisingą sandorį, sujungiau naujus įvykius. Vėl užsiregistravo. Žurnalas grįžo į ClickHouse, ty tai yra nuolat cikliška sistema. Ir be to, aš nuėjau į DWH ten analizuoti.

Būtent tokia forma ji nelabai veikė. Ir kad ClickHouse būtų lengviau, kai buvo užklausa pagal apsilankymo ID, jie sugrupavo šias užklausas į 1 000–2 000 apsilankymų ID blokus ir ištraukė visas operacijas 1 000–2 000 žmonių. Ir tada viskas pavyko.

Jei pažvelgsite į ClickHouse vidų, yra tik 3 pagrindinės lentelės, kuriose visa tai aptarnaujama.

Pirmoji lentelė, į kurią įkeliami žurnalai, o žurnalai įkeliami beveik neapdoroti.

Antra lentelė. Per materializuotą vaizdą iš šių žurnalų buvo išgraužti įvykiai, kurie dar nebuvo priskirti, t. y. nesusiję. Ir per materializuotą vaizdą iš šių žurnalų buvo ištrauktos operacijos, kad būtų sukurta momentinė nuotrauka. Tai yra, specialus materializuotas vaizdas sukūrė momentinę nuotrauką, būtent paskutinę sukauptą operacijos būseną.

Čia yra tekstas, parašytas SQL. Norėčiau jame pakomentuoti keletą svarbių dalykų.

Pirmas svarbus dalykas yra galimybė „ClickHouse“ ištraukti stulpelius ir laukus iš „json“. Tai reiškia, kad „ClickHouse“ turi keletą darbo su json metodų. Jie labai labai primityvūs.

VisitParamExtractInt leidžia išgauti atributus iš json, t. y. veikia pirmasis smūgis. Ir tokiu būdu galite ištraukti operacijos ID arba apsilankyti ID. Šį kartą.

Antra, čia naudojamas sudėtingas materializuotas laukas. Ką tai reiškia? Tai reiškia, kad jūs negalite jo įterpti į lentelę, t. y. ji nėra įterpiama, ji apskaičiuojama ir išsaugoma įterpus. Įklijuojant ClickHouse atlieka darbą už jus. Ir tai, ko jums reikia vėliau, jau yra ištraukta iš json.

Šiuo atveju materializuotas rodinys skirtas neapdorotoms eilutėms. O pirmasis stalas su praktiškai neapdorotais rąstais kaip tik panaudotas. Ir ką jis veikia? Pirma, tai pakeičia rūšiavimą, t. y. dabar rūšiuojama pagal vizito ID, nes reikia greitai ištraukti jo operaciją konkrečiam asmeniui.

Antras svarbus dalykas yra index_granularity. Jei matėte MergeTree, paprastai tai yra index_granularity pagal numatytuosius nustatymus 8. Kas tai yra? Tai yra indekso retumo parametras. „ClickHouse“ indeksas yra negausus, jis niekada neindeksuoja kiekvieno įrašo. Tai daro kas 192 8. Ir tai yra gerai, kai reikia skaičiuoti daug duomenų, bet blogai, kai mažai, nes yra didelė pridėtinė suma. Ir jei sumažinsime indekso detalumą, sumažinsime pridėtines išlaidas. Jo negalima sumažinti iki vieno, nes gali neužtekti atminties. Indeksas visada saugomas atmintyje.

Snapshot taip pat naudoja kai kurias kitas įdomias ClickHouse funkcijas.

Pirma, tai yra AggregatingMergeTree. Ir AggregatingMergeTree saugo argMax, t.y. tai operacijos būsena, atitinkanti paskutinę laiko žymą. Tam tikro lankytojo operacijos generuojamos visą laiką. Ir pačioje paskutinėje šios operacijos būsenoje mes įtraukėme įvykį ir turime naują būseną. Jis vėl pateko į ClickHouse. Ir naudodami argMax šiame materializuotame vaizde visada galime gauti dabartinę būseną.

• Įrišimas yra „atsietas“ nuo vykdymo laiko.
• Per mėnesį saugoma ir apdorojama iki 3 milijardų operacijų. Tai yra eilės tvarka daugiau nei buvo Cassandra, t. y. įprastoje operacijų sistemoje.
• 2x5 ClickHouse serverių klasteris. 5 serveriai ir kiekvienas serveris turi kopiją. Tai dar mažiau nei buvo Cassandra, kad būtų galima priskirti paspaudimais pagrįstą priskyrimą, o štai parodymas pagrįstas. Tai yra, užuot padidinus serverių skaičių 30 kartų, pavyko juos sumažinti.

Ir paskutinis pavyzdys – finansų bendrovė Y, išanalizavusi akcijų kainų pokyčių koreliacijas.

O užduotis buvo tokia:

• Yra apie 5 akcijų.
• Citatos kas 100 milisekundžių žinomos.
• Duomenys kaupiami per 10 metų. Matyt, vienoms įmonėms daugiau, kitoms mažiau.
• Iš viso yra apie 100 milijardų eilučių.

Ir reikėjo skaičiuoti pokyčių koreliaciją.

Štai dvi akcijos ir jų kotiruotės. Jei vienas kyla aukštyn, o kitas kyla aukštyn, tai yra teigiama koreliacija, t. y. vienas kyla, o kitas kyla aukštyn. Jei vienas kyla aukštyn, kaip grafiko pabaigoje, o kitas leidžiasi žemyn, tai yra neigiama koreliacija, t.y. kai vienas kyla, kitas krenta.

Analizuojant šiuos abipusius pokyčius, galima daryti prognozes finansų rinkoje.

Bet užduotis sunki. Kas dėl to daroma? Turime 100 milijardų įrašų, kuriuose yra: laikas, atsargos ir kaina. Turime apskaičiuoti pirmuosius 100 milijardų kartų bėgimo Skirtumas nuo kainos algoritmo. RunningDifference yra ClickHouse funkcija, kuri nuosekliai apskaičiuoja skirtumą tarp dviejų eilučių.

O po to reikia skaičiuoti koreliaciją, o koreliaciją reikia skaičiuoti kiekvienai porai. 5 akcijų poros yra 000 mln. Ir tai yra daug, t. y. 12,5 karto reikia apskaičiuoti tik tokią koreliacijos funkciją.

O jei kas nors pamiršo, tai ͞x ir ͞y yra šachmatas. atrankos lūkesčiai. Tai yra, reikia ne tik skaičiuoti šaknis ir sumas, bet ir dar vieną sumą šių sumų viduje. Skaičiavimų krūvą reikia atlikti 12,5 milijono kartų ir netgi sugrupuoti pagal valandas. Taip pat turime daug valandų. Ir jūs turite tai padaryti per 60 sekundžių. Tai pokštas.

Reikėjo bent kažkaip turėti laiko, nes visa tai veikė labai labai lėtai, kol atėjo ClickHouse.

Jie bandė jį apskaičiuoti naudodami „Hadoop“, „Spark“, „Greenplum“. Ir visa tai buvo labai lėta arba brangu. Tai yra, buvo galima kažkaip paskaičiuoti, bet tada tai buvo brangu.

Tada atsirado ClickHouse ir viskas tapo daug geriau.

Primenu, kad turime problemų su duomenų lokalumu, nes koreliacijų negalima lokalizuoti. Negalime dėti dalies duomenų į vieną serverį, dalies į kitą ir skaičiuoti, visus duomenis turime turėti visur.

Ką jie padare? Iš pradžių duomenys lokalizuojami. Kiekvienas serveris saugo duomenis apie tam tikro akcijų rinkinio kainodarą. Ir jie nesutampa. Todėl logReturn galima skaičiuoti lygiagrečiai ir nepriklausomai, visa tai kol kas vyksta lygiagrečiai ir paskirstyta.

Tada nusprendėme sumažinti šiuos duomenis, neprarasdami išraiškingumo. Sumažinkite naudodami masyvus, t. y. kiekvienam laikotarpiui sukurkite akcijų ir kainų masyvą. Todėl jis užima daug mažiau duomenų vietos. Ir su jais dirbti šiek tiek lengviau. Tai yra beveik lygiagrečios operacijos, t. y. mes iš dalies skaitome lygiagrečiai ir tada rašome į serverį.

Po to jį galima pakartoti. Raidė „r“ reiškia, kad mes pakartojome šiuos duomenis. Tai yra, mes turime tuos pačius duomenis visuose trijuose serveriuose – tai yra masyvai.

Ir tada naudodami specialų scenarijų iš šio 12,5 milijono koreliacijų rinkinio, kurį reikia apskaičiuoti, galite sudaryti paketus. Tai yra 2 užduočių su 500 koreliacijų porų. Ir ši užduotis turi būti skaičiuojama konkrečiame ClickHouse serveryje. Jis turi visus duomenis, nes duomenys yra vienodi ir jis gali juos skaičiuoti paeiliui.

Dar kartą taip atrodo. Pirma, šioje struktūroje turime visus duomenis: laiką, akcijas, kainą. Tada paskaičiavome logReturn, t.y. tokios pat struktūros duomenis, bet vietoj kainos jau turime logReturn. Tada jie buvo perdaryti, t. y. gavome laiko ir groupArray atsargoms ir kainoms. Pakartotinai. Ir po to mes sugeneravome krūvą užduočių ir pateikėme jas ClickHouse, kad ji jas suskaičiuotų. Ir tai veikia.

Koncepcijos įrodymu užduotis buvo antrinė užduotis, t. y. buvo paimta mažiau duomenų. Ir tik trys serveriai.

Pirmieji du etapai: Log_return skaičiavimas ir įvyniojimas į masyvus užtruko apie valandą.

O koreliacijos skaičiavimas yra apie 50 valandų. Tačiau 50 valandų neužtenka, nes anksčiau jie dirbdavo savaites. Tai buvo didelė sėkmė. O jei skaičiuoti, tai 70 kartų per sekundę viskas buvo suskaičiuota šiame klasteryje.

Tačiau svarbiausia yra tai, kad ši sistema praktiškai neturi kliūčių, t. Ir jie tai patikrino. Sėkmingai padidintas.

• Tinkama schema yra pusė sėkmės. O teisinga schema yra visų būtinų ClickHouse technologijų naudojimas.
• Sumavimo / AggregatingMergeTrees yra technologijos, leidžiančios apibendrinti arba laikyti būsenos momentinę nuotrauką ypatingu atveju. Ir tai labai supaprastina daugybę dalykų.
• Materializuoti rodiniai leidžia apeiti vieno indekso limitą. Gal nelabai aiškiai pasakiau, bet kai įkėlėme žurnalus, neapdoroti žurnalai buvo lentelėje su vienu indeksu, o atributų žurnalai buvo lentelėje, t.y. tie patys duomenys, tik filtruoti, bet indeksas buvo visiškai kiti. Atrodo, kad tai tie patys duomenys, bet skirtingas rūšiavimas. Materializuoti vaizdai leidžia, jei jums to reikia, apeiti tokį ClickHouse apribojimą.
• Sumažinkite taškinių užklausų indekso detalumą.
• Ir protingai paskirstykite duomenis, stenkitės kuo labiau lokalizuoti duomenis serveryje. Ir pabandykite užtikrinti, kad užklausose, kur įmanoma, būtų naudojama lokalizacija.

Ir apibendrinant šią trumpą kalbą, galima teigti, kad ClickHouse dabar tvirtai užėmė tiek komercinių, tiek atvirojo kodo duomenų bazių teritoriją, t.y., skirtą būtent analitikai. Jis puikiai dera prie šio kraštovaizdžio. Ir dar daugiau, jis pamažu pradeda išstumti kitus, nes kai turite ClickHouse, jums nereikia InfiniDB. „Vertika“ gali prireikti greitai, jei jie palaikys įprastą SQL. Mėgautis!

-Ačiū už pranešimą! Labai įdomu! Ar buvo kokių nors palyginimų su „Apache Phoenix“?

Ne, negirdėjau, kad kas nors lygintų. Mes ir „Yandex“ stengiamės sekti visus „ClickHouse“ palyginimus su skirtingomis duomenų bazėmis. Nes jei staiga kažkas pasirodo greičiau nei „ClickHouse“, Lesha Milovidov negali miegoti naktį ir pradeda greitai tai pagreitinti. Negirdėjau tokio palyginimo.

• (Aleksejus Milovidovas) „Apache Phoenix“ yra SQL variklis, maitinamas Hbase. Hbase daugiausia skirta pagrindinės vertės darbo scenarijui. Ten kiekvienoje eilutėje gali būti savavališkas skaičius stulpelių su savavališkais pavadinimais. Tai galima pasakyti apie tokias sistemas kaip Hbase, Cassandra. Ir būtent sunkios analitinės užklausos jiems normaliai neveiks. Arba galite manyti, kad jie veikia gerai, jei neturite patirties su ClickHouse.

• Ačiū

  • Laba diena Šia tema jau gana domiuosi, nes turiu analitinę posistemę. Bet kai žiūriu į ClickHouse, man kyla jausmas, kad ClickHouse yra labai tinkamas įvykių analizei, kintamas. O jei man reikia analizuoti daug verslo duomenų su krūva didelių lentelių, tai ClickHouse, kiek suprantu, man nelabai tinka? Ypač jei jie keičiasi. Ar tai teisinga, ar yra pavyzdžių, galinčių tai paneigti?

  • Tai tiesa. Ir tai pasakytina apie daugumą specializuotų analitinių duomenų bazių. Jie pritaikyti tam, kad yra viena ar daugiau didelių lentelių, kurios yra keičiamos, ir daug mažų, kurios keičiasi lėtai. Tai reiškia, kad „ClickHouse“ nėra kaip „Oracle“, kur galite sudėti viską ir sukurti labai sudėtingas užklausas. Norėdami efektyviai naudoti ClickHouse, turite sukurti schemą taip, kad ji gerai veiktų ClickHouse. Tai yra, venkite per didelio normalizavimo, naudokite žodynus, stenkitės padaryti mažiau ilgų nuorodų. Ir jei schema sukurta tokiu būdu, panašias verslo užduotis ClickHouse galima išspręsti daug efektyviau nei tradicinėje reliacinėje duomenų bazėje.

Ačiū už pranešimą! Turiu klausimą dėl naujausios finansinės bylos. Jie turėjo analizę. Reikėjo palyginti, kaip jie kyla aukštyn ir žemyn. Ir aš suprantu, kad sukūrėte sistemą specialiai šiai analizei? Pavyzdžiui, jei rytoj jiems reikia kitos ataskaitos apie šiuos duomenis, ar jiems reikia iš naujo sukurti schemą ir įkelti duomenis? Tai yra, atlikti tam tikrą išankstinį apdorojimą, kad gautumėte užklausą?

Žinoma, tai yra ClickHouse naudojimas labai konkrečiai užduočiai. Tradiciškiau tai galėtų būti išspręsta naudojant „Hadoop“. „Hadoop“ tai yra ideali užduotis. Tačiau „Hadoop“ tai labai lėta. O mano tikslas – pademonstruoti, kad ClickHouse gali išspręsti užduotis, kurios dažniausiai išsprendžiamos visai kitomis priemonėmis, bet tuo pačiu tai padaryti daug efektyviau. Jis pritaikytas konkrečiai užduočiai. Akivaizdu, kad jei yra problema su kažkuo panašiu, tada ją galima išspręsti panašiai.

Tai aišku. Sakėte, kad buvo apdorota 50 valandų. Ar nuo pat pradžių, kada įkėlėte duomenis ar gavote rezultatus?

Taip taip.

Gerai labai ačiū.

Tai yra 3 serverių klasteryje.

Sveikinimai! Ačiū už pranešimą! Viskas labai įdomu. Neklausiu šiek tiek apie funkcionalumą, o apie ClickHouse panaudojimą stabilumo požiūriu. Tai ar turėjote, ar teko atkurti? Kaip tokiu atveju elgiasi ClickHouse? O ar atsitiko, kad turėjote ir kopiją? Pavyzdžiui, susidūrėme su „ClickHouse“ problema, kai ji vis tiek viršija savo ribą ir krenta.

Žinoma, idealių sistemų nėra. O ClickHouse irgi turi savų problemų. Bet ar girdėjote, kad „Yandex.Metrica“ jau seniai neveikia? Tikriausiai ne. Patikimai veikia nuo 2012-2013 m. ClickHouse. Tą patį galiu pasakyti apie savo patirtį. Mes niekada neturėjome visiškų nesėkmių. Kai kurie daliniai dalykai galėjo nutikti, tačiau jie niekada nebuvo pakankamai svarbūs, kad galėtų rimtai paveikti verslą. Tai niekada neįvyko. ClickHouse yra gana patikimas ir nesugenda atsitiktinai. Jūs neturite dėl to jaudintis. Tai nėra žalias dalykas. Tai įrodė daugelis įmonių.

Sveiki! Sakėte, kad reikia nedelsiant pagalvoti apie duomenų schemą. O jei taip atsitiko? Mano duomenys liejasi ir liejasi. Praeina šeši mėnesiai, ir aš suprantu, kad taip gyventi neįmanoma, reikia iš naujo įkelti duomenis ir ką nors su jais daryti.

Tai, žinoma, priklauso nuo jūsų sistemos. Yra keletas būdų, kaip tai padaryti praktiškai be sustojimo. Pavyzdžiui, galite sukurti materializuotą rodinį, kuriame sukurtumėte kitokią duomenų struktūrą, jei ją galima unikaliai susieti. Tai yra, jei jis leidžia atvaizduoti naudojant ClickHouse, ty išgauti kai kuriuos dalykus, pakeisti pirminį raktą, pakeisti skaidymą, tada galite sukurti materializuotą vaizdą. Ten perrašykite savo senus duomenis, nauji bus įrašyti automatiškai. Tada tiesiog pereikite prie materializuoto rodinio, tada perjunkite įrašą ir nužudykite seną lentelę. Paprastai tai yra nepertraukiamas metodas.

Ačiū.

Šaltinis: www.habr.com