ClickHouse'i kasutamise teooria ja praktika reaalsetes rakendustes. Aleksander Zaitsev (2018)

Vaatamata sellele, et praegu on peaaegu kõikjal palju andmeid, on analüütilised andmebaasid siiski üsna eksootilised. Neid tuntakse vähe ja veel halvemini oskavad neid tõhusalt kasutada. Paljud jätkavad kaktuse söömist MySQL-i või PostgreSQL-iga, mis on mõeldud muude stsenaariumide jaoks, kannatavad NoSQL-iga või maksavad rohkem kommertslahenduste eest. ClickHouse muudab mängureegleid ja alandab oluliselt analüütilise DBMS-i maailma sisenemise läve.

Raport BackEnd Conf 2018-st ja see avaldatakse esineja loal.

Kes ma olen ja miks ma ClickHouse'ist räägin? Olen ClickHouse'i kasutava LifeStreeti arendusdirektor. Lisaks olen ma Altinity asutaja. See on Yandexi partner, kes reklaamib ClickHouse'i ja aitab Yandexil ClickHouse'i edukamaks muuta. Valmis ka ClickHouse’i kohta teadmisi jagama.

Ja ma pole Petja Zaitsevi vend. Minu käest küsitakse selle kohta sageli. Ei, me ei ole vennad.

"Kõik teavad", et ClickHouse:

• Väga kiiresti,
• Väga mugav
• Kasutatakse Yandexis.

Veidi vähem teatakse, millistes ettevõtetes ja kuidas seda kasutatakse.

Ma ütlen teile, miks, kus ja kuidas ClickHouse'i kasutatakse, välja arvatud Yandex.

Räägin teile, kuidas erinevates ettevõtetes ClickHouse’i abil konkreetseid ülesandeid lahendatakse, milliseid ClickHouse’i tööriistu saate oma ülesannete täitmiseks kasutada ning kuidas neid erinevates ettevõtetes kasutati.

Võtsin välja kolm näidet, mis näitavad ClickHouse'i erinevate nurkade alt. Ma arvan, et see saab olema huvitav.

Esimene küsimus on: "Miks me vajame ClickHouse'i?". See tundub olevat üsna ilmne küsimus, kuid sellele on rohkem kui üks vastus.

• Esimene vastus on jõudluse kohta. ClickHouse on väga kiire. ClickHouse'i analüüs on samuti väga kiire. Seda saab sageli kasutada, kui midagi muud on väga aeglane või väga halb.
• Teine vastus on kulu. Ja esiteks skaleerimise maksumus. Näiteks Vertica on täiesti suurepärane andmebaas. See töötab väga hästi, kui teil pole palju terabaiti andmemahtu. Kuid kui tegemist on sadade terabaitidega või petabaitidega, läheb litsentsi ja toe maksumus üsna märkimisväärseks. Ja see on kallis. Ja ClickHouse on tasuta.
• Kolmas vastus on tegevuskulud. See on veidi teistsugune lähenemine. RedShift on suurepärane analoog. RedShiftis saate otsuse teha väga kiiresti. See töötab hästi, kuid samal ajal maksate Amazonile iga tund, iga päev ja iga kuu üsna kallilt, kuna see on märkimisväärselt kallis teenus. Ka Google BigQuery. Kui keegi seda kasutas, siis ta teab, et seal saate käivitada mitu päringut ja saada ootamatult sadade dollarite arve.

ClickHouse'il neid probleeme pole.

Kus ClickHouse'i praegu kasutatakse? Lisaks Yandexile kasutatakse ClickHouse'i paljudes erinevates ettevõtetes ja ettevõtetes.

• Esiteks on see veebirakenduse analüüs, st see on Yandexist pärit kasutusjuhtum.
• Paljud AdTechi ettevõtted kasutavad ClickHouse'i.
• Arvukalt ettevõtteid, kes peavad analüüsima erinevatest allikatest pärit tehinguloge.
• Mitmed ettevõtted kasutavad ClickHouse'i turvalogide jälgimiseks. Nad laadivad need üles ClickHouse'i, koostavad aruandeid ja saavad soovitud tulemusi.
• Ettevõtted hakkavad seda kasutama finantsanalüüsis, st tasapisi lähenevad ClickHouse'ile ka suurettevõtted.
• pilvetuled. Kui keegi jälgib ClickHouse’i, siis on ta ilmselt selle firma nime kuulnud. See on üks olulisemaid kogukonna panustajaid. Ja neil on väga tõsine ClickHouse'i install. Näiteks tegid nad ClickHouse'i jaoks Kafka Engine'i.
• Telekommunikatsiooniettevõtted hakkasid kasutama. Mitmed ettevõtted kasutavad ClickHouse'i kas kontseptsiooni tõestuseks või juba tootmises.
• Üks ettevõte kasutab tootmisprotsesside jälgimiseks ClickHouse'i. Nad testivad mikroskeeme, kirjutavad maha hulga parameetreid, omadusi on umbes 2. Ja siis analüüsitakse, kas mäng on hea või halb.
• Plokiahela analüüs. Seal on selline vene firma nagu Bloxy.info. See on ethereumi võrgu analüüs. Nad tegid seda ka ClickHouse'is.

Ja suurus pole oluline. On palju ettevõtteid, kes kasutavad ühte väikest serverit. Ja ta võimaldab neil oma probleeme lahendada. Ja veelgi rohkem ettevõtteid kasutab suuri paljudest või kümnetest serveritest koosnevaid klastreid.

Ja kui vaadata rekordeid, siis:

• Yandex: 500+ serverit, nad salvestavad seal 25 miljardit kirjet päevas.
• LifeStreet: 60 serverit, umbes 75 miljardit kirjet päevas. Seal on vähem servereid, rohkem kirjeid kui Yandexis.
• CloudFlare: 36 serverit, need salvestavad 200 miljardit kirjet päevas. Neil on veelgi vähem servereid ja nad salvestavad veelgi rohkem andmeid.
• Bloomberg: 102 serverit, umbes triljon kirjet päevas. Rekordihoidja.

Geograafiliselt on seda ka palju. See kaart siin näitab soojuskaarti selle kohta, kus ClickHouse'i maailmas kasutatakse. Venemaa, Hiina, Ameerika paistavad siin selgelt silma. Euroopa riike on vähe. Ja seal on 4 klastrit.

See on võrdlev analüüs, absoluutarvusid pole vaja otsida. See on analüüs külastajatest, kes loevad Altinity veebilehel ingliskeelseid materjale, sest venekeelseid seal pole. Ja Venemaa, Ukraina, Valgevene, st kogukonna venekeelne osa, on kõige arvukamad kasutajad. Siis tulevad USA ja Kanada. Hiina on väga järele jõudmas. Pool aastat tagasi Hiinat seal peaaegu ei olnud, nüüd on Hiina juba Euroopast mööda läinud ja jätkab kasvu. Ka Vana Euroopa ei jää kaugele maha ning ClickHouse’i kasutamise liider on kummalisel kombel Prantsusmaa.

Miks ma seda kõike räägin? Näidata, et ClickHouse’ist on saamas suurandmete analüüsi standardlahendus ja seda kasutatakse juba väga paljudes kohtades. Kui kasutate seda, olete õiges trendis. Kui te seda veel ei kasuta, siis ei saa te karta, et jääte üksi ja keegi ei aita teid, sest paljud teevad seda juba.

Need on näited reaalsest ClickHouse'i kasutamisest mitmes ettevõttes.

• Esimene näide on reklaamivõrgustik: migratsioon Verticast ClickHouse'i. Ja ma tean mõnda ettevõtet, kes on Verticast üle läinud või on üleminekul.
• Teine näide on tehingute salvestamine ClickHouse'is. See on näide, mis on üles ehitatud antimustritele. Siin on tehtud kõik, mida ClickHouse’is arendajate nõuannete järgi teha ei tohiks. Ja seda tehakse nii tõhusalt, et see töötab. Ja see töötab palju paremini kui tavaline tehingulahendus.
• Kolmas näide on ClickHouse'i hajutatud andmetöötlus. Tekkis küsimus, kuidas saab ClickHouse'i Hadoopi ökosüsteemi integreerida. Näitan näidet, kuidas ettevõte tegi ClickHouse'is midagi sarnast kaardi vähendamise konteineriga, jälgides andmete lokaliseerimist jne, et arvutada väga mittetriviaalne ülesanne.

• LifeStreet on Ad Tech ettevõte, millel on kogu reklaamivõrgustikuga kaasas olev tehnoloogia.
• Ta tegeleb reklaamide optimeerimise ja programmilise pakkumisega.
• Palju andmeid: umbes 10 miljardit sündmust päevas. Samas saab sealsed üritused jagada mitmeks alaürituseks.
• Nende andmete kliente on palju ja need pole ainult inimesed, vaid palju muud – need on erinevad algoritmid, mis tegelevad programmilise pakkumisega.

Ettevõte on käinud pika ja okkalise tee. Ja ma rääkisin sellest HighLoadis. Esiteks kolis LifeStreet MySQL-ist (lühikese peatusega Oracle'is) Verticasse. Ja selle kohta võite leida loo.

Ja kõik oli väga hea, kuid kiiresti sai selgeks, et andmed kasvavad ja Vertica on kallis. Seetõttu otsiti erinevaid alternatiive. Mõned neist on siin loetletud. Ja tegelikult tegime peaaegu kõigi 13.-16. aastani turul saadaolevate ja funktsionaalsuse poolest ligilähedaselt sobivate andmebaaside kontseptsiooni tõestamise või mõnikord jõudlustestimise. Ja mõnest neist rääkisin ka HighLoadis.

Ülesanne oli kõigepealt Verticast migreeruda, sest andmed kasvasid. Ja need kasvasid aastatega plahvatuslikult. Siis läksid nad riiulisse, aga sellest hoolimata. Ja ennustades seda kasvu, ärinõudeid andmehulgale, mille kohta oli vaja teha mingisugune analüüs, oli selge, et peagi hakatakse arutama petabaite. Ja petabaitide eest maksmine on juba väga kallis, seega otsisime alternatiivi, kuhu minna.

Kuhu minna? Ja pikka aega polnud üldse selge, kuhu minna, sest ühest küljest on kommertsandmebaasid, need näivad hästi toimivat. Mõned töötavad peaaegu sama hästi kui Vertica, mõned halvemini. Aga nad on kõik kallid, midagi odavamat ja paremat ei leidnud.

See-eest on avatud lähtekoodiga lahendusi, mida ei ole väga palju, st analüütika jaoks on need näppude peal üles loetavad. Ja need on tasuta või odavad, kuid aeglased. Ja sageli puudub neil vajalik ja kasulik funktsionaalsus.

Ja polnud millegagi ühendada seda head, mis on kommertsandmebaasis ja kõike seda tasuta, mis on avatud lähtekoodiga.

Polnud midagi, kuni Yandex tõmbas ootamatult ClickHouse'i välja nagu mustkunstnik kübarast, nagu jänes. Ja see oli ootamatu otsus, nad esitavad endiselt küsimuse: "Miks?", Kuid sellegipoolest.

Ja kohe 2016. aasta suvel hakkasime vaatama, mis ClickHouse on. Ja selgus, et mõnikord võib see olla kiirem kui Vertica. Testisime erinevate päringutega erinevaid stsenaariume. Ja kui päring kasutas ainult ühte tabelit, see tähendab ilma liitumisteta (join), siis ClickHouse oli kaks korda kiirem kui Vertica.

Ma ei olnud liiga laisk ja vaatasin eelmisel päeval Yandexi teste. Seal on sama: ClickHouse on kaks korda kiirem kui Vertica, nii et nad räägivad sellest sageli.

Aga kui päringutes on liitumisi, siis ei selgu kõik väga üheselt. Ja ClickHouse võib olla kaks korda aeglasem kui Vertica. Ja kui taotlust veidi parandate ja ümber kirjutate, on need ligikaudu võrdsed. Pole paha. Ja tasuta.

Ja olles saanud testi tulemused ja vaadanud seda erinevate nurkade alt, läks LifeStreet ClickHouse’i.

See on 16. aasta, ma tuletan teile meelde. See oli nagu nali hiirte kohta, kes nutsid ja torkisid end, kuid jätkasid kaktuse söömist. Ja seda kirjeldati üksikasjalikult, selle kohta on video jne.

Seetõttu ma sellest täpsemalt ei räägi, räägin ainult tulemustest ja paarist huvitavast asjast, millest ma siis ei rääkinud.

Tulemused on järgmised:

• Edukas migratsioon ja enam kui aasta töötab süsteem juba tootmises.
• Tootlikkus ja paindlikkus on kasvanud. 10 miljardist kirjest, mida saaksime endale lubada päevas ja seejärel lühikese aja jooksul salvestada, salvestab LifeStreet nüüd 75 miljardit kirjet päevas ja suudab seda teha 3 kuud või kauem. Kui arvestada tipphetkega, on see kuni miljon sündmust sekundis. Sellesse süsteemi jõuab päevas üle miljoni SQL-päringu, peamiselt erinevatelt robotitelt.
• Vaatamata sellele, et ClickHouse’i jaoks kasutati rohkem servereid kui Vertica jaoks, hoiti kokku ka riistvara pealt, sest Verticas kasutati üsna kalleid SAS-kettaid. ClickHouse kasutas SATA-d. Ja miks? Kuna Verticas on sisestus sünkroonne. Ja sünkroniseerimine eeldab, et kettad liiga palju ei aeglustaks ja ka võrk liiga palju ei aeglustaks ehk siis üsna kulukas operatsioon. Ja ClickHouse'is on sisestus asünkroonne. Pealegi saab alati kõike lokaalselt kirjutada, selle eest ei kaasne lisakulusid, nii et ka aeglasematel draividel saab andmeid ClickHouse'i palju kiiremini sisestada kui Vertikasse. Ja lugemine on umbes sama. SATA-st lugedes, kui need on RAID-is, on see kõik piisavalt kiire.
• Pole litsentsiga piiratud, st 3 petabaiti andmeid 60 serveris (20 serverit on üks koopia) ja 6 triljonit kirjet faktides ja koondandmetes. Midagi sellist ei saa Vertica endale lubada.

Pöördun nüüd selles näites praktiliste asjade juurde.

• Esimene on tõhus skeem. Palju oleneb skeemist.
• Teine on tõhus SQL-i genereerimine.

Tüüpiline OLAP-päring on valik. Mõned veerud lähevad rühmitamiseks, mõned veerud koondavad funktsioonid. Seal on koht, mida saab kujutada kuubiku viiluna. Kogu gruppi võib pidada projektsiooniks. Ja sellepärast nimetatakse seda mitme muutujaga andmete analüüsiks.

Ja sageli modelleeritakse seda täheskeemi kujul, kui külgedel, mööda kiiri on selle fakti keskne fakt ja omadused.

Ja füüsilise disaini osas, kuidas see lauale sobib, teevad nad tavaliselt normaliseeritud esituse. Saate denormaliseerida, kuid see on kettal kallis ja päringute puhul mitte eriti tõhus. Seetõttu teevad nad tavaliselt normaliseeritud esituse, st faktitabeli ja palju-palju dimensioonitabeleid.

Kuid see ei tööta ClickHouse'is hästi. Sellel on kaks põhjust.

• Esimene on sellepärast, et ClickHouse'il pole väga häid liitumisi, st liitumisi on, aga need on halvad. Kuigi halb.
• Teine on see, et tabeleid ei uuendata. Tavaliselt tuleb nendes plaatides, mis on täheahela ümber, midagi muuta. Näiteks kliendi nimi, firma nimi jne. Ja see ei tööta.

Ja ClickHouse'is on sellest väljapääs. isegi kaks:

• Esimene on sõnaraamatute kasutamine. Välised sõnastikud aitavad 99% lahendada täheskeemi, värskenduste ja muu sellise probleemi.
• Teine on massiivide kasutamine. Samuti aitavad massiivid vabaneda liitudest ja normaliseerimise probleemidest.

• Liitumist pole vaja.
• Uuendatav. Alates 2018. aasta märtsist on ilmunud dokumenteerimata võimalus (seda dokumentatsioonist ei leia) sõnaraamatuid osaliselt, s.o muutunud kirjeid uuendada. Praktiliselt on see nagu laud.
• Alati mälus, nii et sõnastikuga liitumine toimib kiiremini kui siis, kui see oleks kettal olev tabel ja pole veel tõsiasi, et see on vahemälus, tõenäoliselt mitte.

• Samuti pole teil vaja liitumisi.
• See on kompaktne 1-mitmele esitus.
• Ja minu arust on massiivid tehtud nohikutele. Need on lambda funktsioonid ja nii edasi.

See pole punaste sõnade jaoks. See on väga võimas funktsioon, mis võimaldab teha paljusid asju väga lihtsal ja elegantsel viisil.

Tüüpilised näited, mis aitavad massiive lahendada. Need näited on piisavalt lihtsad ja selged:

• Otsige siltide järgi. Kui teil on seal hashtage ja soovite mõnda postitust leida hashtagide järgi.
• Otsige võtme-väärtuse paaride järgi. Samuti on mõned atribuudid väärtusega.
• Võtmete loendite salvestamine, mille peate millekski muuks tõlkima.

Kõiki neid ülesandeid saab lahendada ilma massiivideta. Sildid saab panna mõnele reale ja valida regulaaravaldisega või eraldi tabelisse, kuid siis tuleb teha liitmisi.

Ja ClickHouse'is ei pea te midagi tegema, piisab, kui kirjeldate hashtagide stringimassiivi või loote võtmeväärtussüsteemide jaoks pesastatud struktuur.

Pesastatud struktuur ei pruugi olla parim nimi. Need on kaks massiivi, millel on nimes ühine osa ja mõned seotud omadused.

Ja sildi järgi on väga lihtne otsida. Omavad funktsiooni has, mis kontrollib, kas massiiv sisaldab elementi. Kõik, leidsid kõik meie konverentsiga seotud sissekanded.

Subidi järgi otsimine on veidi keerulisem. Peame esmalt leidma võtme indeksi ja seejärel võtma selle indeksiga elemendi ja kontrollima, kas see väärtus on see, mida me vajame. Siiski on see väga lihtne ja kompaktne.

Regulaaravaldis, mille tahaksite kirjutada, kui hoiaksite selle kõik ühel real, oleks see esiteks kohmakas. Ja teiseks töötas see palju kauem kui kaks massiivi.

Veel üks näide. Teil on massiiv, kuhu ID salvestate. Ja saate need nimedeks tõlkida. Funktsioon arrayMap. See on tüüpiline lambda funktsioon. Sa annad seal lambda väljendeid. Ja ta tõmbab sõnastikust iga ID jaoks välja nime väärtuse.

Otsingut saab teha samal viisil. Läbitakse predikaatfunktsioon, mis kontrollib elementide vastavust.

Need asjad lihtsustavad oluliselt vooluringi ja lahendavad hulga probleeme.

Kuid järgmine probleem, millega me silmitsi seisame ja mida tahaksin mainida, on tõhusad päringud.

• ClickHouse'il pole päringuplaneerijat. Absoluutselt mitte.
• Sellegipoolest tuleb keerukaid päringuid veel planeerida. Millistel juhtudel?
• Kui päringus on mitu liitumist, mähite need alamvalikutesse. Ja nende täitmise järjekord on oluline.
• Ja teine ​​- kui taotlust jagatakse. Sest hajutatud päringu puhul täidetakse hajutatult ainult kõige sisemine alamvalik ja kõik muu edastatakse ühele serverile, millega ühendasite ja seal käivitasite. Seega, kui olete levitanud päringuid paljude liitumistega (liitu), siis peate valima järjekorra.

Ja ka lihtsamatel juhtudel on vahel vaja ka planeerija töö ära teha ja päringuid veidi ümber kirjutada.

Siin on näide. Vasakul küljel on päring, mis näitab 5 parimat riiki. Ja see võtab minu arvates 2,5 sekundit. Ja paremal pool sama päring, aga veidi ümber kirjutatud. Stringi järgi rühmitamise asemel hakkasime rühmitama võtme (int) järgi. Ja see on kiirem. Ja siis ühendasime tulemusega sõnastiku. 2,5 sekundi asemel kulub päringule 1,5 sekundit. See on hea.

Sarnane näide ümberkirjutamise filtritega. Siin on palve Venemaale. See töötab 5 sekundit. Kui me kirjutame selle ümber nii, et võrdleme jällegi mitte stringi, vaid numbreid mõne Venemaaga seotud võtmekomplektiga, siis on see palju kiirem.

Selliseid nippe on palju. Ja need võimaldavad teil oluliselt kiirendada päringuid, mis teie arvates juba kiiresti töötavad või vastupidi, aeglaselt. Neid saab teha veelgi kiiremini.

• Maksimaalne töö hajutatud režiimis.
• Sorteerimine miinimumtüüpide järgi, nagu ma tegin ints.
• Kui on mingeid liitumisi (liitu), sõnastikke, siis on parem neid teha viimase abinõuna, kui andmed on juba vähemalt osaliselt grupeeritud, siis kutsutakse liitumisoperatsiooni või sõnastikukutset vähem korda ja see on kiirem .
• Filtrite vahetamine.

On ka teisi tehnikaid, mitte ainult neid, mida olen demonstreerinud. Ja kõik need võivad mõnikord päringute täitmist oluliselt kiirendada.

Liigume edasi järgmise näite juurde. Ettevõte X USA-st. Mida ta teeb?

Seal oli ülesanne:

• Reklaamitehingute võrguühenduseta linkimine.
• Erinevate köitemudelite modelleerimine.

Milline on stsenaarium?

Tavakülastaja tuleb lehele näiteks 20 korda kuus erinevatest kuulutustest või lihtsalt niisama tuleb vahel ilma igasuguste reklaamideta, sest see sait jääb talle meelde. Vaatab mõnda toodet, paneb korvi, võtab korvist välja. Ja lõpuks midagi ostab.

Põhjendatud küsimused: "Kes peaks vajadusel reklaami eest maksma?" ja "Milline reklaam teda mõjutas, kui üldse?". See tähendab, miks ta ostis ja kuidas panna inimesi nagu see inimene ka ostma?

Selle probleemi lahendamiseks peate veebisaidil toimuvad sündmused õigel viisil ühendama, st nende vahel kuidagi ühendust looma. Seejärel saadetakse need analüüsiks DWH-le. Ja selle analüüsi põhjal koostage mudelid selle kohta, kellele ja milliseid reklaame näidata.

Reklaamitehing on seotud kasutajasündmuste kogum, mis algab reklaami näitamisest, seejärel juhtub midagi, siis võib-olla ostmine ja siis võib ostu raames toimuda oste. Näiteks kui tegemist on mobiilirakenduse või mobiilimänguga, siis tavaliselt toimub rakenduse installimine tasuta ja kui seal midagi ette võetakse, siis võib selle eest ka raha nõuda. Ja mida rohkem inimene rakenduses kulutab, seda väärtuslikum see on. Kuid selleks peate kõik ühendama.

Sidumismudeleid on palju.

Kõige populaarsemad on:

• Viimane interaktsioon, kus interaktsioon on kas klikk või näitamine.
• Esimene interaktsioon, st esimene asi, mis tõi inimese saidile.
• Lineaarne kombinatsioon – kõik võrdselt.
• Sumbumine.
• Ja nii edasi.

Ja kuidas see kõik üldse töötas? Seal olid Runtime ja Cassandra. Cassandrat kasutati tehingute salvestusruumina, st sinna salvestati kõik seotud tehingud. Ja kui Runtime’is tuleb mingi üritus, näiteks mingit lehte või midagi muud, siis tehti Cassandrale päring - kas selline inimene on või ei ole. Seejärel saadi sellega seotud tehingud. Ja ühendus tekkis.

Ja kui veab, et päringul on tehingu ID, siis on see lihtne. Aga tavaliselt ei vea. Seetõttu oli vaja leida viimane tehing või viimase klikiga tehing jne.

Ja see kõik töötas väga hästi, kuni sidumine oli viimase klõpsuni. Sest päevas on näiteks 10 miljonit klikki, kuus 300 miljonit, kui paneme akna kuuks ajaks. Ja kuna Cassandras peab see kiireks töötamiseks kõik mälus olema, kuna Runtime peab kiiresti reageerima, siis kulus selleks umbes 10-15 serverit.

Ja kui nad tahtsid tehingut ekraaniga siduda, selgus kohe, et see pole nii lõbus. Ja miks? On näha, et sündmusi on vaja salvestada 30 korda rohkem. Ja vastavalt sellele vajate 30 korda rohkem servereid. Ja selgub, et see on mingi astronoomiline kujund. Kui hoida linkimise jaoks kuni 500 serverit, hoolimata sellest, et Runtime'is on servereid oluliselt vähem, siis on see mingi vale näitaja. Ja nad hakkasid mõtlema, mida teha.

Ja me läksime ClickHouse'i. Ja kuidas seda ClickHouse'is teha? Esmapilgul tundub, et tegemist on antimustrite komplektiga.

• Tehing kasvab, me ühendame sellega üha rohkem sündmusi, st see on muutuv ja ClickHouse ei tööta eriti hästi muudetavate objektidega.
• Kui külastaja tuleb meie juurde, peame tema tehingud võtme, tema külastuse ID järgi välja tõmbama. See on ka punktpäring, ClickHouse'is nad seda ei tee. Tavaliselt on ClickHouse'il suured … skaneeringud, kuid siin peame hankima mõned rekordid. Samuti antimuster.
• Lisaks oli tehing json-vormingus, kuid nad ei tahtnud seda ümber kirjutada, mistõttu nad soovisid jsoni struktureerimata salvestada ja vajadusel sealt midagi välja tõmmata. Ja see on ka antimuster.

See tähendab, et antimustrite komplekt.

Kuid sellest hoolimata osutus see süsteemiks, mis töötas väga hästi.

Mida tehti? Ilmus ClickHouse, millesse visati logid, mis jagati kirjeteks. Ilmus omistatud teenus, mis sai ClickHouse'ilt logisid. Pärast seda sain iga kande kohta visiit id-ga tehingud, mida ei pruugi olla veel töödeldud, ja pluss snapshotid, st juba ühendatud tehingud, nimelt eelmise töö tulemus. Tegin neist juba loogika, valisin õige tehingu, ühendasin uued sündmused. Jälle logitud. Logi läks tagasi ClickHouse’i ehk see on pidevalt tsükliline süsteem. Ja pealegi käisin DWH-s seda seal analüüsimas.

Just sellisel kujul see väga hästi ei toiminud. Ja ClickHouse'i jaoks lihtsamaks tegemiseks rühmitasid nad külastuse ID-ga päringud 1–000 külastuse ID-ga plokkidesse ja tõmbasid välja kõik tehingud 2–000 inimese kohta. Ja siis see kõik töötas.

Kui vaatate ClickHouse'i sisse, siis seal on ainult 3 peamist tabelit, mis seda kõike teenindavad.

Esimene tabel, kuhu logid üles laaditakse, ja logid laaditakse üles peaaegu ilma töötlemiseta.

Teine tabel. Realiseerunud vaate kaudu hammustati nendest logidest välja sündmused, mida pole veel omistatud, st mitteseotud. Ja realiseerunud vaate kaudu võeti nendest logidest välja tehingud, et luua ülevaade. See tähendab, et spetsiaalne materialiseeritud vaade koostas hetktõmmise, nimelt tehingu viimase akumuleeritud oleku.

Siin on SQL-is kirjutatud tekst. Tahaksin selles kommenteerida mõnda olulist asja.

Esimene oluline asi on võimalus ClickHouse'is jsonist veerge ja välju välja tõmmata. See tähendab, et ClickHouse'il on jsoniga töötamiseks mõned meetodid. Nad on väga-väga primitiivsed.

visitParamExtractInt võimaldab teil jsonist atribuute eraldada, st esimene tabamus töötab. Ja nii saate välja tõmmata tehingu ID või külastada ID. Seekord.

Teiseks kasutatakse siin keerulist materialiseerunud välja. Mida see tähendab? See tähendab, et te ei saa seda tabelisse sisestada, st seda ei sisestata, see arvutatakse ja salvestatakse sisestamisel. Kleepimisel teeb ClickHouse töö teie eest ära. Ja see, mida hiljem vajate, on juba jsonist välja tõmmatud.

Sel juhul on materialiseeritud vaade töötlemata ridade jaoks. Ja esimene praktiliselt toore palgiga laud on just kasutuses. Ja mida ta teeb? Esiteks muudab see sorteerimist, st sorteerimine käib nüüd visiit id järgi, kuna peame kiiresti tema tehingu konkreetse inimese jaoks välja tõmbama.

Teine oluline asi on index_granularity. Kui olete MergeTree'i näinud, on see tavaliselt vaikimisi 8 index_granularity. Mis see on? See on indeksi hõreduse parameeter. ClickHouse'is on indeks hõre, see ei indekseeri kunagi iga kirjet. Ta teeb seda iga 192 8. Ja see on hea, kui on vaja arvutada palju andmeid, kuid halb, kui neid on vähe, sest seal on palju üldkulusid. Ja kui me vähendame indeksi detailsust, siis vähendame üldkulusid. Seda ei saa taandada ühele, sest mälu ei pruugi olla piisavalt. Indeks salvestatakse alati mällu.

Snapshot kasutab ka mõnda muud huvitavat ClickHouse'i funktsiooni.

Esiteks on see AggregatingMergeTree. Ja AggregatingMergeTree salvestab argMaxi, st see on viimasele ajatemplile vastava tehingu olek. Tehinguid genereeritakse antud külastaja kohta kogu aeg. Ja selle tehingu viimases olekus lisasime sündmuse ja meil on uus olek. See tabas uuesti ClickHouse'i. Ja argMaxi kaudu selles materialiseeritud vaates saame alati praeguse oleku.

• Köitmine on käitusajast lahti ühendatud.
• Kuus salvestatakse ja töödeldakse kuni 3 miljardit tehingut. Seda on suurusjärgu võrra rohkem kui Cassandras, st tüüpilises tehingusüsteemis.
• 2x5 ClickHouse'i serverite klaster. 5 serverit ja igal serveril on koopia. Seda on isegi vähem kui Cassandras, et teha klikipõhise omistamise puhul, ja siin on meil näitamistepõhine. See tähendab, et selle asemel, et serverite arvu 30 korda suurendada, õnnestus neil neid vähendada.

Ja viimane näide on finantsettevõte Y, mis analüüsis aktsiahindade muutuste seoseid.

Ja ülesanne oli:

• Aktsiaid on ligikaudu 5.
• Tuntud on hinnapakkumised iga 100 millisekundi järel.
• Andmeid on kogutud 10 aasta jooksul. Ilmselt mõnele firmale rohkem, mõnele vähem.
• Kokku on umbes 100 miljardit rida.

Ja oli vaja arvutada muutuste korrelatsioon.

Siin on kaks aktsiat ja nende noteeringud. Kui üks tõuseb ja teine ​​tõuseb, siis see on positiivne korrelatsioon, st üks tõuseb ja teine ​​tõuseb. Kui üks tõuseb, nagu graafiku lõpus, ja teine ​​langeb, on see negatiivne korrelatsioon, st kui üks tõuseb, siis teine ​​langeb.

Neid vastastikuseid muutusi analüüsides saab teha finantsturul ennustusi.

Kuid ülesanne on raske. Mida selleks tehakse? Meil on 100 miljardit kirjet, millel on: aeg, varud ja hind. Peame arvutama esimesed 100 miljardit korda jooksva erinevuse hinnaalgoritmist. RunningDifference on ClickHouse'i funktsioon, mis arvutab järjestikku kahe stringi erinevuse.

Ja pärast seda peate arvutama korrelatsiooni ja iga paari jaoks tuleb arvutada korrelatsioon. 5 aktsia puhul on paarid 000 miljonit. Ja seda on palju, st 12,5 korda on vaja arvutada just selline korrelatsioonifunktsioon.

Ja kui keegi unustas, siis on ͞x ja ͞y matt. valimi võtmise ootus. See tähendab, et pole vaja arvutada ainult juured ja summad, vaid ka nende summade sees veel üks summa. Hunnik arvutusi tuleb teha 12,5 miljonit korda ja isegi tundide kaupa rühmitada. Meil on ka palju tunde. Ja sa pead seda tegema 60 sekundiga. See on nali.

Aega oli vaja vähemalt kuidagi saada, sest kõik see toimis väga-väga aeglaselt, enne kui ClickHouse tuli.

Nad proovisid seda arvutada Hadoopi, Sparki ja Greenplumi kaudu. Ja see kõik oli väga aeglane või kallis. St sai kuidagi arvutada, aga siis oli kallis.

Ja siis tuli ClickHouse ja asjad läksid palju paremaks.

Tuletan meelde, et meil on probleem andmete lokaliseerimisega, kuna korrelatsioone ei saa lokaliseerida. Me ei saa panna osa andmetest ühte serverisse, osa teise serverisse ja arvutada, meil peavad kõik andmed olema igal pool.

Mida nad tegid? Esialgu andmed lokaliseeritakse. Iga server salvestab andmeid teatud aktsiate kogumi hinnakujunduse kohta. Ja need ei kattu. Seetõttu on võimalik logReturn arvutada paralleelselt ja iseseisvalt, see kõik toimub seni paralleelselt ja hajutatult.

Seejärel otsustasime neid andmeid vähendada, kaotamata samas väljendusrikkust. Vähendage massiive kasutades, st koostage iga ajaperioodi kohta aktsiate massiiv ja hindade massiiv. Seetõttu võtab see palju vähem andmeruumi. Ja nendega on natuke lihtsam töötada. Need on peaaegu paralleelsed toimingud, st me loeme osaliselt paralleelselt ja seejärel kirjutame serverisse.

Pärast seda saab seda korrata. Täht "r" tähendab, et me kordasime need andmed. See tähendab, et meil on kõigis kolmes serveris samad andmed – need on massiivid.

Ja siis saate koostada pakette spetsiaalse skriptiga sellest 12,5 miljonist korrelatsioonist, mida tuleb arvutada. Ehk siis 2 ülesannet 500 korrelatsioonipaariga. Ja see ülesanne tuleb arvutada konkreetses ClickHouse'i serveris. Tal on kõik andmed olemas, sest andmed on samad ja ta saab neid järjest arvutada.

Taaskord näeb see välja selline. Esiteks on meil selles struktuuris kõik andmed: aeg, aktsiad, hind. Seejärel arvutasime välja logReturn ehk sama struktuuriga andmed, kuid hinna asemel on meil juba logReturn. Seejärel tehti need ümber, st saime aktsiate ja hindade jaoks aja ja groupArray. Paljundatud. Ja pärast seda genereerisime hunniku ülesandeid ja andsime need ClickHouse'ile, et see neid loendaks. Ja see toimib.

Kontseptsiooni tõendamisel oli ülesanne alamülesanne, st võeti vähem andmeid. Ja ainult kolm serverit.

Esimesed kaks etappi: Log_return arvutamine ja massiividesse mähkimine võttis aega umbes tund.

Ja korrelatsiooni arvutamine on umbes 50 tundi. Aga 50 tunnist ei piisa, sest varem töötati nädalaid. See oli suur edu. Ja kui arvestada, siis 70 korda sekundis loeti kõik sellel klastris.

Kuid kõige olulisem on see, et see süsteem on praktiliselt ilma kitsaskohtadeta, st see mastaabib peaaegu lineaarselt. Ja nad kontrollisid seda. Suurendati seda edukalt.

• Õige skeem on pool edust. Ja õige skeem on kõigi vajalike ClickHouse tehnoloogiate kasutamine.
• Summing/AggregatingMergeTrees on tehnoloogiad, mis võimaldavad teil oleku hetktõmmist koondada või käsitleda erijuhtumina. Ja see lihtsustab paljusid asju oluliselt.
• Materialiseeritud vaated võimaldavad teil ühe indeksi piirangust mööda minna. Võib-olla ma ei öelnud seda väga selgelt, aga kui me logisid laadisime, olid töötlemata logid tabelis ühe indeksiga ja atribuutide logid olid tabelis, st samad andmed, ainult filtreeritud, kuid indeks oli täielikult teised. Tundub, et tegemist on samade andmetega, kuid erineva sorteerimisega. Ja materialiseeritud vaated võimaldavad teil vajaduse korral sellisest ClickHouse'i piirangust mööda minna.
• Vähendage punktipäringute indeksi detailsust.
• Ja jagage andmeid nutikalt, proovige andmeid võimalikult palju serveris lokaliseerida. Ja püüdke tagada, et taotlused kasutaksid võimaluse korral ka lokaliseerimist.

Ja selle lühikese kõne kokkuvõtteks võib öelda, et ClickHouse on nüüdseks kindlalt hõivanud nii kommertsandmebaaside kui ka avatud lähtekoodiga andmebaaside territooriumi, st spetsiaalselt analüütika jaoks. Ta sobib sellesse maastikku suurepäraselt. Veelgi enam, see hakkab aeglaselt teisi välja tõrjuma, sest kui teil on ClickHouse, pole teil InfiniDB-d vaja. Vertikat ei pruugi varsti vaja minna, kui nad teevad tavalist SQL-i tuge. Nautige!

-Täname raporti eest! Väga huvitav! Kas oli mingeid võrdlusi Apache Phoenixiga?

Ei, ma pole kuulnud kedagi võrdlemas. Meie ja Yandex püüame jälgida kõiki ClickHouse'i võrdlusi erinevate andmebaasidega. Sest kui äkki midagi osutub ClickHouse'ist kiiremaks, siis Lesha Milovidov ei saa öösel magada ja hakkab seda kiiresti kiirendama. Ma pole sellisest võrdlusest kuulnud.

• (Aleksey Milovidov) Apache Phoenix on SQL-i mootor, mida toidab Hbase. Hbase on mõeldud peamiselt võtmeväärtuse tööstsenaariumi jaoks. Seal võib igal real olla suvalise arvu suvaliste nimedega veerge. Seda võib öelda selliste süsteemide kohta nagu Hbase, Cassandra. Ja just rasked analüütilised päringud nende puhul normaalselt ei tööta. Või võite arvata, et need töötavad hästi, kui teil pole ClickHouse'iga kogemusi.

• Tänan

  • Tere päevast Olen juba üsna huvitatud sellest teemast, kuna mul on analüütiline alamsüsteem. Aga ClickHouse’i vaadates tekib tunne, et ClickHouse sobib väga hästi sündmuste analüüsiks, muutlik. Ja kui mul on vaja hunniku suurte tabelitega palju äriandmeid analüüsida, siis ClickHouse, nii palju kui ma aru saan, ei sobi mulle eriti? Eriti kui need muutuvad. Kas see on õige või on näiteid, mis võivad selle ümber lükata?

  • See on õige. Ja see kehtib enamiku spetsialiseeritud analüütiliste andmebaaside kohta. Need on kohandatud asjaolule, et on üks või mitu suurt tabelit, mis on muudetavad, ja paljude väikeste jaoks, mis muutuvad aeglaselt. See tähendab, et ClickHouse pole nagu Oracle, kuhu saab kõike panna ja väga keerulisi päringuid koostada. ClickHouse'i tõhusaks kasutamiseks peate koostama skeemi viisil, mis ClickHouse'is hästi töötab. See tähendab, et vältige liigset normaliseerimist, kasutage sõnaraamatuid, proovige teha vähem pikki linke. Ja kui skeem on sellisel viisil üles ehitatud, saab sarnaseid äriülesandeid ClickHouse'is palju tõhusamalt lahendada kui traditsioonilises relatsiooniandmebaasis.

Täname raporti eest! Mul on küsimus viimase finantsjuhtumi kohta. Neil oli analüüs. Oli vaja võrrelda, kuidas nad üles ja alla lähevad. Ja ma saan aru, et lõite süsteemi spetsiaalselt selle analüüsi jaoks? Kui neil on näiteks homme vaja mingit muud aruannet nende andmete kohta, kas nad peavad siis skeemi uuesti üles ehitama ja andmed üles laadima? See tähendab, et teha päringu saamiseks mingi eeltöötlus?

Loomulikult on see ClickHouse'i kasutamine väga konkreetse ülesande jaoks. Seda saaks traditsioonilisemalt lahendada Hadoopi raames. Hadoopi jaoks on see ideaalne ülesanne. Kuid Hadoopis on see väga aeglane. Ja minu eesmärk on demonstreerida, et ClickHouse suudab lahendada ülesandeid, mida tavaliselt lahendatakse täiesti erinevate vahenditega, kuid samas palju tõhusamalt. See on kohandatud konkreetse ülesande jaoks. Selge see, et kui millegi sarnasega on probleem, siis saab seda ka sarnaselt lahendada.

See on selge. Ütlesite, et töödeldi 50 tundi. Kas algusest peale, millal sa andmed laadisid või tulemused said?

Jah Jah.

OK tänan teid väga.

See on 3 serveriklastris.

Tervitused! Täname raporti eest! Kõik on väga huvitav. Ma ei küsi natuke funktsionaalsuse kohta, vaid ClickHouse'i kasutamise kohta stabiilsuse mõttes. See tähendab, kas teil oli, kas teil oli vaja taastada? Kuidas ClickHouse sel juhul käitub? Ja kas juhtus, et teil oli ka koopia? Näiteks tekkis probleem ClickHouse'iga, kui see ikka ületab oma piiri ja kukub.

Muidugi pole ideaalseid süsteeme olemas. Ja ClickHouse’il on ka omad probleemid. Kuid kas olete kuulnud, et Yandex.Metrica ei tööta pikka aega? Ilmselt mitte. See on ClickHouse'is töötanud usaldusväärselt alates 2012-2013. Sama võin öelda oma kogemuse kohta. Meil pole kunagi olnud täielikke ebaõnnestumisi. Mõned osalised asjad võisid juhtuda, kuid need ei olnud kunagi piisavalt kriitilised, et äri tõsiselt mõjutada. Seda ei juhtunud kunagi. ClickHouse on üsna töökindel ja ei jookse juhuslikult kokku. Sa ei pea selle pärast muretsema. See pole toores asi. Seda on tõestanud paljud ettevõtted.

Tere! Ütlesite, et peate kohe andmeskeemile mõtlema. Mis siis, kui see juhtus? Minu andmeid kallab ja kallab. Möödub kuus kuud ja ma saan aru, et niimoodi elada on võimatu, pean andmed uuesti üles laadima ja nendega midagi ette võtma.

See sõltub muidugi teie süsteemist. Seda saab praktiliselt ilma peatumata teha mitmel viisil. Näiteks saate luua materialiseeritud vaate, kus luua erinev andmestruktuur, kui seda saab unikaalselt kaardistada. See tähendab, et kui see võimaldab ClickHouse'i abil kaardistada, st välja võtta mõned asjad, muuta primaarvõtit, muuta partitsiooni, saate teha materialiseeritud vaate. Kirjuta sinna oma vanad andmed üle, uued kirjutatakse automaatselt. Seejärel lülitage lihtsalt materialiseeritud vaate kasutamisele, seejärel vahetage kirje ja hävitage vana tabel. See on üldiselt non-stop meetod.

Aitäh.

Allikas: www.habr.com