Podcasti transkriptsioon on tõlgitud Linuxi administraatori kursuse alguse eelõhtuks

Kuigi andmeid on praegu peaaegu igal pool palju, on analüütilised andmebaasid endiselt üsna eksootilised. Neid tuntakse halvasti ja veelgi hullem, neid ei osata efektiivselt kasutada. Paljud jätkavad "kaktuse söömist" MySQL-i või PostgreSQL-iga, mis on projekteeritud teiste stsenaariumide jaoks, vaevlevad NoSQL-i abil või maksavad liiga palju kommertslahenduste eest. ClickHouse muudab reegleid ja vähendab oluliselt sisenemise takistust analüütiliste DBMS-ide maailma.

Ettekanne BackEnd Conf 2018 ja see on avaldatud ettekandja loal.

Kes ma olen ja miks ma räägin ClickHouse'ist? Olen LifeStreet'i arenduse direktor, kes kasutab ClickHouse'i. Lisaks olen Altinity asutaja. See on Yandexi partner, kes edendab ClickHouse'i ja aitab Yandexil ClickHouse'i edukamaks muuta. Olen ka valmis jagama teadmisi ClickHouse'i kohta.

Ja veel, ma ei ole Petja Zaitsevi vend. Sellest küsitakse mind sageli. Ei, me ei ole vennad.

«Kõigile on teada», et ClickHouse:

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

Muudatakse vähem tuntuks, millistes ettevõtetes ja kuidas seda kasutatakse.

Räägin teile, milleks, kus ja kuidas ClickHouse'i kasutatakse, peale Yandexi.

Räägin, kuidas konkreetsed ülesanded lahendatakse ClickHouse'i abil erinevates ettevõtetes, milliseid ClickHouse'i tööriistu saate oma ülesannete jaoks kasutada ja kuidas neid on erinevates ettevõtetes kasutatud.

Olen valinud kolm näidet, mis näitavad ClickHouse'i erinevaid külgi. Mõtlen, et see on huvitav.

Esimene küsimus: «Miks on vajalik ClickHouse?». Kuigi küsimus tundub piisavalt ilmne, on sellele rohkem kui üks vastus.

• Esimene vastus – tootlikkuse nimel. ClickHouse on väga kiire. Analüüs ClickHouse'is on samuti väga kiire. Seda saab sageli kasutada seal, kus midagi muud töötab väga aeglaselt või väga halvasti.
• Teine vastus – see on maksumus. Eelkõige skaleerimise maksumus. Näiteks Vertica on täiesti suurepärane andmebaas. See töötab väga hästi, kui teil ei ole väga palju terabaite andmeid. Kuid kui jutt on sadadest terabaidist või petabaidist, siis litsentsi ja toe maksumus tõuseb piisavalt suureks. Ja see on kallis. ClickHouse on aga tasuta.
• Kolmas vastus on tegevuskulu. See lähenemine on natuke teiselt poolt. RedShift on suurepärane analoog. RedShiftis saab väga kiiresti lahenduse teha. See töötab hästi, kuid see maksab iga tunni, iga päeva ja iga kuu lühidalt Amazonile üsna kallilt, kuna see on oluliselt kulukas teenus. Google BigQuery on samuti. Kui keegi on seda kasutanud, siis ta teab, et seal saab käitada mitu päringut ja äkki saada arve sadade dollarite eest.

ClickHouse'is ei ole neid probleeme.

Kus kasutatakse ClickHouse'i praegu? Peale Yandexi kasutatakse ClickHouse'i mitmesugustes äri- ja ettevõtetes.

• Esiteks on see veebirakenduste analüüs, st see on kasutusjuht, mis tuli Yandexist.
• Palju AdTech ettevõtteid kasutavad ClickHouse'i.
• Paljud ettevõtted, kellel on vaja analüüsida operatiivlogisid erinevatest allikatest.
• Mõned ettevõtted kasutavad ClickHouse'i turvalogide jälgimiseks. Nad laadivad need ClickHouse'i, teevad aruandeid ja saavad vajalikud tulemused.
• Ettevõtted hakkavad seda kasutama finantsanalüüsis, st järk-järgult suur äri ka valib ClickHouse'i.
• CloudFlare. Kui keegi jälgib ClickHouse'i, siis on ta kindlasti kuulnud selle ettevõtte nime. See on üks olulisemaid panustajaid kogukonnas. Ja neil on väga tõsine ClickHouse'i paigaldus. Näiteks nad tegid Kafka Engine'i ClickHouse'i jaoks.
• Telekommunikatsiooni ettevõtted on hakanud seda kasutama. Mitmed ettevõtted kasutavad ClickHouse'i kas proof of conceptina või juba tootmises.
• Üks ettevõte kasutab ClickHouse'i tootmisprotsesside jälgimiseks. Nad testivad mikrokiipe, registreerivad hulga parameetreid, seal on umbes 2000 omadust. Ja seejärel analüüsivad – kas partii on hea või halb.
• Blokiaanalüüs. On selline Venemaa ettevõte nagu Bloxy.info. See analüüsib ethereum-võrku. Nad tegid seda ka ClickHouse'i abil.

Lisaks ei ole suurus tähtis. On palju ettevõtteid, kes kasutavad ühte väikest serverit. Ja see lahendab nende probleemid. Ja veel rohkem ettevõtteid kasutavad suuri klastreid, mis koosnevad paljusid serverid või kümneid servereid.

Ja kui vaadata rekordite järgi, siis:

• Yandex: 500+ serverit, nad salvestavad 25 miljardit kirjet päevas.
• LifeStreet: 60 serverit, umbes 75 miljardit kirjet päevas. Servereid on vähem, kirjeid rohkem kui Yandexis.
• CloudFlare: 36 serverit, 200 miljardi kirjet päevas, mida nad hoiavad. Neil on veel vähem servereid ja veel rohkem andmeid, mida nad hoiavad.
• Bloomberg: 102 serverilt, umbes triljon kirjet päevas. Rekordite hoidja.

Geograafiliselt on see ka palju. Siin on kaart, mis näitab heatmap'i, kus ClickHouse'i maailmas kasutatakse. Siin paistavad silma Venemaa, Hiina, Ameerika. Euroopa riike on vähe. Ja võib välja tuua 4 klastrit.

See on võrdlev analüüs, siin ei ole vaja otsida absoluutarve. See on analüüs külastajatest, kes loevad ingliskeelseid materjale Altinity veebisaidil, sest seal pole venekeelseid. Venemaa, Ukraina, Valgevene, s.t. venekeelne osa kogukonnast, on kõige arvukamad kasutajad. Seejärel tulevad USA ja Kanada. Hiina tuleb kiiresti järele. Pool aastat tagasi ei olnud Hiinat peaaegu üldse, nüüd on Hiina juba Euroopa üle läinud ja jätkab kasvu. Vanaproua Euroopa jääb raskeveo asemel järele, samas on ClickHouse'i juhtiv kasutaja, nagu kummaline see ka ei tunduks, Prantsusmaa.

Miks ma seda kõike räägin? Selleks, et näidata, et ClickHouse saab standardseks lahenduseks suurte andmete analüüsimiseks ja seda kasutatakse juba väga paljudes kohtades. Kui te seda kasutate, olete õigel teel. Kui te veel ei kasuta, siis ei pea muretsema, et jääte üksi ja keegi teid ei aita, sest juba paljud tegelevad sellega.

Need on ClickHouse'i reaalsed kasutusnäited mitmes ettevõttes.

• Esimene näide on reklaamivõrk: migratsioon Verticalt ClickHouse'i. Ja ma tean mitmeid ettevõtteid, kes on Vertica kaudu kolinud või on kolimisel.
• Teine näide on tehingute andmehoidla ClickHouse'is. See on näide, mis on üles ehitatud antipattern'idel. Kõik, mida ClickHouse'is ei tohiks teha arendajate nõuannete järgi, on siin tehtud. Ja see on tehtud nii tõhusalt, et see töötab. Ja töötab palju paremini kui tüüpiline tehingute lahendus.
• Kolmas näide on jaotatud arvutused ClickHouse'is. Oli küsimus selle kohta, kuidas ClickHouse'i integreerida Hadoopi ökosüsteemi. Näitan näidet, kuidas firma tegi ClickHouse'is midagi tüüpi analoog map reduce konteinerist, jälgides andmete lokaliseerimist jne, et lahendada väga mitte triviaalne ülesanne.

• LifeStreet – See on Ad Tech ettevõte, millel on kõik tehnoloogiad, mis on seotud reklaamivõrguga.
• Tegeleb reklaamide optimeerimise ja programmatic bidding'iga.
• Palju andmeid: umbes 10 miljardit sündmust päevas. Need sündmused võivad seejuures jaguneda mitmeks alamsündmuseks.
• Palju kliente nendele andmetele, ning need ei ole ainult inimesed, vaid palju rohkem – erinevad algoritmid, mis tegelevad programmilise pakkumisega.

Ettevõte on läbinud pika ja keerulise tee. Olen sellest rääkinud HighLoadis. Algul kolis LifeStreet MySQL-lt (väikese peatusega Oracle’il) Verticasse. Ja sellest on võimalik leida juttu.

Ja kõik oli väga hästi, kuid üsna kiiresti sai selgeks, et andmed kasvavad ja Vertica on kallis. Seetõttu otsiti erinevaid alternatiive. Mõned neist on siin loetletud. Tegime tõepoolest proof of concept’i või mõnikord ka jõudlustestimist peaaegu kõigi andmebaasidega, mis olid turul saadaval aastatel 2013 kuni 2016 ja vastasid funktsionaalsuselt umbes meie vajadustele. Ja mõnest neist rääkisin samuti HighLoadis.

Ülesanne oli migratsioon Verticast, sest andmed kasvasid. Ja nad kasvasid eksponentsiaalselt mitu aastat. Siis jõudsid nad tasemele, kuid siiski. Viies seda kasvu prognoosides, ettevõtte nõuded andmemahu osas, mille põhjal tuleb teha mingisugust analüüsi, oli selge, et varsti hakatakse rääkima petabaitidest. Ja petabaitide eest tuleb juba väga palju maksta, seega otsiti alternatiivi, kuhu liikuda.

Kuhu liikuda? Pikka aega ei olnud üldse selge, kuhu minna, sest ühelt poolt on olemas kommertstandmebaasid, mis näivad töötavat hästi. Mõned neist töötavad peaaegu sama hästi kui Vertica, mõned halvemini. Kuid nad kõik on kallid, midagi odavamat ja paremat leida ei õnnestunud.

Teiselt poolt on olemas avatud lähtekoodiga lahendused, mida ei ole väga palju, st andmete analüüsi jaoks võib neid sõrmedel kokku lugeda. Need on tasuta või odavad, kuid töötavad aeglaselt. Ja neis puudub sageli vajalik ja kasulik funktsionaalsus.

Laadi, mis ühendaks hea, mis olemas kommertstandmebaasides, ja kogu tasuta, mis olemas avatud lähtekoodiga lahendustes – ei olnud midagi.

Ei olnud midagi, kuni ootamatult Yandex ei toonud, nagu maagia, ClickHouse’i. See oli ootamatu lahendus, ja seni küsitakse: "Miks?", kuid siiski.

Ja juba suvel 2016. aastal hakkasime uurima, mis on ClickHouse. Selgus, et mõnikord võib see olla kiiremini kui Vertica. Testisime erinevaid stsenaariume erinevate päringute peal. Ja kui päringutas kasutati ainult ühte tabelit, st ilma mingite join'ideta, siis oli ClickHouse kaks korda kiiremini kui Vertica.

Ma ei lasknud end laiskusest andestada ja vaatasin hiljuti ka Yandexi teste. Seal on sama: ClickHouse on kaks korda kiiremini kui Vertica, seetõttu räägivad nad sellest sageli.

Aga kui päringutes on join'id, siis on kõik mitte nii üheselt mõistetav. Ja ClickHouse võib olla Vertica'st kaks korda aeglasem. Kui natuke päringut kohendada ja ümber kirjutada, siis on need enam-vähem ühesugused. Mitte halb. Ja tasuta.

Saades testitulemused ja vaadates sellele erinevatest nurkadest, läks LifeStreet ClickHouse'i üle.

See on 2016. aasta, meenutan. See oli nagu anekdoot hiirtest, kes nutsid ja torkisid end, aga jätkasid kaktuse söömist. Ja sellest on põhjalikult räägitud, olemas on selle kohta videosid jne.

Seetõttu ma ei hakka sellest põhjalikult rääkima, räägin ainult tulemustest ja mõnest huvitavast asjast, millest ma tol ajal ei rääkinud.

Tulemused on järgmised:

• Edukalt migratsioon ja süsteem on juba üle aasta olnud tootmises.
• Tootlikkus ja paindlikkus on kasvanud. 10 miljardi kirje asemel, mida me saime endale lubada säilitada päevade kaupa ja siis lühikest aega, hoiab LifeStreet nüüd 75 miljardit kirjet päevas ja suudab seda teha 3 kuud või kauem. Tippsituatsioonis salvestatakse kuni miljon sündmust sekundis. Üks miljon SQL-päringut päevas jõuab sellesse süsteemi, enamasti erinevatelt robotitelt.
• Hoolimata sellest, et ClickHouse'i jaoks hakkas kasutama rohkem servereid kui Vertica jaoks, toimus säästmine ka riistvaras, sest Verticas kasutati üsna kalliseid SAS-kettasid. ClickHouse'is kasutati SATA-d. Miks? Sest Verticas on insert sünkroonne. Ja sünkroniseerimine nõuab, et kettad ei peaks väga palju pidurdama, samuti ei tohi võrguühendus väga aeglane olla, st see on piisavalt kallis operatsioon. Samas ClickHouse'is on insert asünkroonne. Veelgi enam, kõike saab alati kohapeal kirjutada, selle jaoks ei ole mingeid lisakulusid, seega saab andmeid ClickHouse'i sisestada palju kiiremini kui Vertica'sse isegi mitte kõige kiirematel ketastel. Ja lugemine on umbes sama. Lugemise ajal SATA-l, kui need on RAID-is, on see kõik piisavalt kiire.
• Ei ole litsentsiga piiratud, st 3 petabaidid andmeid 60 serveris (20 serverit on üks koopia) ja 6 triljonit kirjet faktide ja agregaatide osas. Midagi sarnast ei suutnud Vertica endale lubada.

Nüüd liigun ma selles näites praktiliste asjade juurde.

• Esimene asi on efektiivne skeem. Skeemist sõltub väga palju.
• Teine asi on efektiivse SQL-i genereerimine.

Tüüpiline OLAP-päring on select. Osa veerge läheb group by, osa veerge läheb agregaatfunktsioonidesse. On where, mida saab pidada kuubi lõikeks. Kogu group by saab pidada projektsiooniks. Seetõttu nimetatakse seda multidimensionaalseks andmeanalüüsiks.

Ja sageli modelleeritakse seda star-skeemi kujul, kus on keskne fakt ja selle fakti omadused külgedel, kiirte kujul.

Ja füüsilise disaini seisukohalt, kuidas see tabelisse asetub, tehakse tavaliselt normaliseeritud esitamine. Võite denormaliseerida, kuid see on ketta peal kallis ja päringute osas mitte väga tõhus. Seega tehakse tavaliselt normaliseeritud esitamine, st faktitabel ja palju-palju mõõtmetabelit.

Aga ClickHouse'is töötab see halvasti. On kaks põhjust:

• Esimene – see, et ClickHouse'il ei ole väga häid join'e, st join'id on olemas, kuid need on halvad. Praegu on nad halvad.
• Teine – see, et tabeleid ei uuendata. Tavaliselt on neil tabelitel, mis on star-skeemi ümber, vaja midagi muuta. Näiteks kliendi nimi, ettevõtte nimi jne. Ja see ei toimi.

Ja ClickHouse'is on sellele väljakäik. Lausa kaks:

• Esimene – see, et kasutada sõnastikke. External Dictionaries on see, mis aitab 99% ulatuses lahendada star-skeemi, uuenduste ja muu probleemi.
• Teine – see, et kasutada mahtusid. Mahtud aitavad samuti vabaneda join'ist ja normaliseerimise probleemidest.

• Join'id ei ole vajalikud.
• Uuendatavad. Alates märtsist 2018 on ilmunud dokumenteerimata võimalus (dokumentatsioonis te ei leia seda), et uuendada sõnastikke osaliselt, st neid kirjeid, mis on muutunud. Praktikas on see nagu tabel.
• Alati mälus, seega töötavad join'id sõnastikuga kiiremini kui siis, kui see oleks tabel, mis on kettal ja pole isegi fakt, et see on vahemälus, tõenäoliselt ei ole.

• Samuti ei ole join'id vajalikud.
• See on kompaktne esitus 1 paljudele.
• Ja minu arvates on massiivid loodud geekkide jaoks. Need on lambda-funktsioonid jne.

See ei ole lihtsalt tühja jutu pärast. See on väga võimas funktsionaalsus, mis võimaldab paljusid asju teha väga lihtsalt ja elegantselt.

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

• Otsi siltide järgi. Kui sul on seal hashtags ja soovid leida mingeid postitusi selle sildi järgi.
• Otsi key-value paaride järgi. Seal on ka mingeid atribuute koos väärtustega.
• Hoia loendeid võtmetest, mida pead tõlkima millegi muuks.

Kõiki neid ülesandeid saab lahendada ka ilma massiivideta. Silte saab panna mingisse ritta ja regulaarselt väljendit kasutades valida või eraldi tabelisse, kuid siis tuleb teha ühendused (join).

Aga ClickHouse'is ei pea mingit lisatööd tegema, piisab, kui kirjeldad massiivi stringide jaoks hashtagi või teed pesakonstruktsiooni key-value tüüpi süsteemide jaoks.

Pesakonstruktsioon – see võibolla ei ole kõige õnnestunum nimetus. Need on kaks massiivi, millel on ühine osa nimedes ja mõned seotud omadused.

Ja sildi järgi on otsimine väga lihtne. Funktsioon has, mis kontrollib, kas massiivis on element. Kõik, leidsime kõik postitused, mis kuuluvad meie konverentsile.

Otsimine subidi järgi on veidi keerulisem. Peame esmalt leidma võtme indeksi ja seejärel võtma selle indeksi elemendi ning kontrollima, kas see väärtus on selline, nagu me vajame. Kuid see on siiski väga lihtne ja kompaktne.

Regulaarne väljend, mille sa tahaksid kirjutada, kui sa kõik seda ühe ritta hoiaksid, oleks kõigepealt kohmakas. Teiseks, see töötaks palju kauem kui kaks massiivi.

Teine näide. Sul on massiiv, milles hoiad ID-sid. Ja sa saad need nimedeks tõlkida. Funktsioon arrayMap. See on tüüpiline lambda-funktsioon. Sa edastad sinna lambda-väljendeid. Ja see toob igale ID-le sõnastikus välja nime väärtuse.

Sarnasel viisil on võimalik ka otsingut teha. Edastatakse predikaat-funktsioon, mis kontrollib, millele elemendid vastavad.

Need asjad lihtsustavad skeemi ja lahendavad hulgaliselt probleeme.

Aga järgmine probleem, millega me silmitsi seisame ja millest ma tahaksin rääkida, on efektiivsed päringud.

• ClickHouse'is ei ole päringute planeerijat. Üldse mitte.
• Kuid keerulisi päringuid tuleb ikkagi planeerida. Millal?
• Kui päringus on mitu join'i, mis ümbritsete alampäringutes, siis on oluline, millises järjekorras neid täidetakse.
• Ja teine asi on see, kui päring on jaotatud. Sest jaotatud päringus täidetakse ainult kõige sisemine alampäring ja kõik muu edastatakse ühele serverile, millega olete ühendatud, ja toimub seal. Seetõttu, kui teil on jaotatud päringud paljude join'idega, tuleb määrata järjekord.

Ja isegi lihtsamatel juhtudel tuleks mõnikord planeerija tööd teha ja päringuid natuke ümber kirjutada.

Siin on näide. Vasakul on päring, mis näitab 5 parimat riiki. Ja see kestab 2,5 sekundit, minu arvates. Ja paremal on sama päring, kuid natuke ümber kirjutatud. Me ei grupeerinud ridade kaupa, vaid grupeerisime võtme (int) järgi. Ja see on kiiremini. Pärast seda liitsime tulemusele sõnastiku. Selle asemel, et päring kestaks 2,5 sekundit, kestab see 1,5 sekundit. See on hea.

Sarnane näide filtrite ümber kirjutamisest. Siin on päring Venemaa kohta. See kestab 5 sekundit. Kui me kirjutame selle ümber nii, et võrreldame taas mitte rida, vaid numbreid mingite võtmete kogumiga, mis kuuluvad Venemaale, siis on see palju kiirem.

Selliseid trikke on palju. Ja need võimaldavad märkimisväärselt kiirendada päringute täitmist, mis tunduvad juba kiiret, või vastupidi, töötavad aeglaselt. Need saab teha veelgi kiiremateks.

• Maksimaalne töö jaotatud režiimis.
• Sorteerimine minimaalsete tüüpide järgi, nagu ma seda tegin int-de põhjal.
• Kui on mingeid join'e, sõnastikke, siis on parem need teha viimases järjekorras, kui teil on andmed vähemalt osaliselt grupeeritud, siis on join'i või sõnastiku üleskutse vähem kordi ning see on kiirem.
• Filtrite asendamine.

On veel teisi tehnikaid, mitte ainult need, mida ma demonstreerisin. Ja kõik need võimaldavad mõnikord märkimisväärselt kiirendada päringute täitmist.

Liigume järgmise näite juurde. Firma X Ameerikast. Mida nad teevad?

Ülesanne oli:

• Reklaamitehingute offline-seostamine.
• Erinevate seostamismudelite modelleerimine.

Mis on stsenaariumi sisu?

Tavaline külastaja külastab veebisaiti näiteks 20 korda kuus erinevate reklaamide kaudu või tuleb lihtsalt aeg-ajalt jälgides, kuna ta mäletab seda saiti. Ta vaatab mõningaid tooteid, paneb need ostukorvi, eemaldab need ostukorvist. Ja lõpuks ostab ta midagi.

Mõistlikud küsimused: "Kellele tuleb reklaami eest tasuda, kui on vajadus?" ja "Milline reklaam teda mõjutas, kui mõjutas?". See tähendab, miks ta ostis ja kuidas teha nii, et sarnased inimesed ostaksid samuti?

Selle probleemi lahendamiseks on vaja siduda veebisaidil toimuvad sündmused omavahel, st luua nende vahel side. Seejärel tuleb need edastada analüüsiks DWH-sse. Ja selle analüüsi põhjal luua mudeleid, kellele ja millist reklaami näidata.

Reklaamitehing on seotud kasutaja sündmuste kogum, mis algab reklaami näitamisest, millele järgneb midagi, siis võib-olla ost ja hiljem võivad olla ostud ostus. Näiteks, kui see on mobiilirakendus või mobiilimäng, siis tavaliselt installitakse rakendus tasuta, kuid kui seal toimub midagi muud, võivad selleks olla vajalikud rahad. Ja mida rohkem inimene rakenduses kulutab, seda väärtuslikum ta on. Kuid selleks tuleb kõik siduda.

Sidumise mudeleid on palju.

Kõige populaarsemad on:

• Viimane interaktsioon, kus interaktsioon on kas klikk või näitamine.
• Esimene interaktsioon, st esimene, mis tõi inimese veebisaidile.
• Lineaarne kombinatsioon – kõigil võrdselt.
• Häipumine.
• Ja muud.

Kuidas see kõik algselt toimi? Oli Runtime ja Cassandra. Cassandrat kasutati tehingute salvestamiseks, st seal hoiti kõiki seotud tehinguid. Ja kui mõni sündmus jõuab Runtime'i, näiteks mingi lehe näitamine või midagi muud, tehti päring Cassandrale – kas selline inimene on olemas või mitte. Siis tuuakse välja tehingud, mis temaga on seotud. Ja sidumine toimus.

Ja kui vedas, et päringus on tehingu id, siis see on lihtne. Kuid tavaliselt ei vea. Seetõttu tuli leida viimane tehing või tehing viimase kliki järgi jne.

Ja see kõik töötas väga hästi, kuni sidumine toimis viimase kliki järgi. Sest klikke oli näiteks 10 miljonit päevas, 300 miljonit kuus, kui seada kuu aknaks. Ja kuna Cassandras peab see kõik olema mälus, et töötada kiiresti, kuna Runtime peab vastama kiiresti, siis oli vaja umbes 10-15 serverit.

Aga kui sooviti siduda tehingut näitamistega, siis hakkas asi koheselt tunduma mitte nii lõbus. Ja miks? On selge, et tuleb salvestada 30 korda rohkem sündmusi. Ja seetõttu on vaja 30 korda rohkem servereid. Tulemuseks on mingisugune astronomiline number. Hoida kuni 500 serverit selleks, et siduda, samas kui Runtime'i servereid on oluliselt vähem, on vale number. Ja hakati mõtlema, mida teha.

Ja jõuti ClickHouse'ni. Aga kuidas seda ClickHouse'is teha? Esmapilgul tundub, et see on antipaaterne.

• Tehing kasvab, me lisame sellele uusi ja uusi sündmusi, see tähendab, et see on muudetav, aga ClickHouse ei tööta hästi muudetavate objektidega.
• Kui külastaja meie juurde tuleb, peame välja tõmbama tema tehingud võtme, tema külastuse ID järgi. See on samuti punktiküsimus, ClickHouse'is nii ei tehta. Tavaliselt tehakse ClickHouse'is suuri skaneeringuid, aga meil on vaja välja tõmmata mitu kirjet. See on samuti antipaaterne.
• Lisaks oli tehing JSON-vormingus, kuid me ei soovinud seda ümber kirjutada, seetõttu soovisime hoida JSON-i struktureerimata ja vajadusel sealt midagi välja tõmmata. Ja see on samuti antipaaterne.

See on antipaaterne kogum.

Kuid siiski õnnestus luua süsteem, mis töötas väga hästi.

Mis tehti? Ilmus ClickHouse, kuhu visati logid, jagatud kirjedeks. Ilmus atribuuditeenus, mis sai ClickHouse'ist logid. Pärast seda sai iga kirje järgi külastuse ID tehingud, mis võisid olla veel töötlemata, pluss snapshotid, see tähendab, et tehingud olid juba seotud, nimelt eelneva töö tulemus. Nendest tehti juba loogika, valiti õige tehing ja ühendati uued sündmused. Salvestati uuesti logisse. Logi saadeti tagasi ClickHouse'i, see tähendab, et see on pidevalt tsükliline süsteem. Lisaks saadeti see DWH-sse, et seal analüüsida.

Just like that, it didn't work very well. To make it easier for ClickHouse when querying by visit ID, they grouped these requests into blocks of 1,000-2,000 visit IDs and extracted all transactions for 1,000-2,000 people. Then everything started to work.

If you look inside ClickHouse, there are only 3 main tables that serve all this.

The first table, where logs are poured in, is filled with logs that are virtually unprocessed.

The second table. Through a materialized view, non-attributed events, i.e. unrelated ones, were filtered out from these logs. And through another materialized view, transactions were extracted from these logs to build a snapshot. Specifically, a special materialized view constructed the snapshot, representing the latest accumulated state of the transaction.

Here is the text written in SQL. I would like to comment on a few important things in it.

The first important thing is ClickHouse's ability to extract columns and fields from JSON. That is, ClickHouse has some methods for working with JSON. They are very, very primitive.

visitParamExtractInt allows extracting attributes from JSON, i.e., the first occurrence is triggered. This way, you can fetch the transaction ID or visit ID. That's one.

Second, a clever materialized field is used here. What does this mean? It means that you can't insert it into the table; it is calculated and stored upon insertion. When you insert, ClickHouse does the work for you. And it extracts from JSON what you will need later.

In this case, the materialized view is for unprocessed rows. It precisely uses the first table with virtually raw logs. So, what does it do? First of all, it changes the sorting, i.e., sorting is now done by visit ID because we need to quickly extract the transaction for a specific person.

The second important thing is index_granularity. If you've seen MergeTree, the default index_granularity is usually set to 8,192. What is this? This parameter indicates the sparsity of the index. In ClickHouse, the index is sparse; it never indexes every record. It does this every 8,192 entries. This is good when you need to calculate a lot of data, but bad when you need just a few, as it incurs significant overhead. And if you decrease index granularity, you reduce overhead. However, it cannot be reduced to one because there might not be enough memory. The index is always stored in memory.

Snapshoot kasutab veel mõningaid huvitavaid ClickHouse'i funktsioone.

Esiteks on see AggregatingMergeTree. Ja AggregatingMergeTree'is hoitakse argMax'i, s.t. see on tehingu olek, mis vastab viimasele ajamärgile. Tehingud genereeritakse pidevalt selle külastaja jaoks. Ja selle tehingu uuemas olekus lisame sündmuse ja meil on uus olek. See jõudis jälle ClickHouse'i. Ja läbi argMax'i selles materialiseeritud vaates saame alati saada ajakohase oleku.

• Sidumine on „lahutatud“ Runtime'ist.
• Kuni 3 miljardit tehingut kuus hoitakse ja töödeldakse. See on kordades rohkem kui oli Cassandras, s.t. tüüpilises tehingusüsteemis.
• Klastri 2x5 ClickHouse'i serverites. 5 serverit ja igal serveril on koopiad. See on isegi vähem, kui oli Cassandras, et teha kliki põhjal atribuutikat, siin on meil aga mulje põhjal. S.t. selle asemel, et suurendada serverite arvu 30 korda, suudeti neid vähendada.

Ja viimane näide on finantsfirma Y, mis analüüsis aktsiahindade muutuste korrelatsioone.

Ja ülesanne oli järgmine:

• Umbes 5000 aktsiat on.
• Hinnad on teada iga 100 millisekundi järel.
• Andmed on kogunenud 10 aasta jooksul. Näib, et mõne firma jaoks rohkem, mõne jaoks vähem.
• Kokku umbes 100 miljardit rida.

Ja tuli arvutada muutuste korrelatsioon.

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

Analüüsides neid vastastikuseid muutusi, saab teha ennustusi finantsturgudel.

Aga ülesanne on keeruline. Mida selleks tehakse? Meil on 100 miljardit kirjet, kus on: aeg, aktsia ja hind. Peame esmalt arvutama 100 miljardit korda kost lõikes olevat hinnavahetust. RunningDifference on funktsioon ClickHouse'is, mis arvutab järjestikku kahe rea vahelise erinevuse.

Ja pärast seda tuleb arvutada korrelatsioon, ja korrelatsioon tuleb arvutada iga paari jaoks. 5000 aktsia jaoks on paare 12,5 miljonit. Ja see on palju, s.t. 12,5 korda tuleb arvutada selline korrelatsioonifunktsioon.

Ja kui keegi on unustanud, siis ͞x ja ͞y – need on valimi matemaatilised ootused. See tähendab, et tuleb mitte ainult juured ja summad arvutada, vaid ka nende summade sees veel ühed summad. Tuleb teha tohutult arvutusi 12,5 miljonit korda ja lisaks tuleb need ka tundide kaupa grupeerida. Aega on meil samuti parajalt. Ja kõik see tuleb 60 sekundi jooksul ära teha. See on nali.

Tuli kuidagi hakkama saada, sest kõik see töötas väga- väga aeglaselt, enne kui ClickHouse tuli.

Nad proovisid seda arvutada Hadoopis, Sparkis, Greenplumis. Ja kõik see oli kas väga aeglane või kallis. See tähendab, et mingil moel oli võimalik arvutada, kuid see oli seejärel kallis.

Ja siis tuli ClickHouse ja kõik muutus palju paremaks.

Tuletan meelde, et meie probleem on andmete lokaalsus, seetõttu ei saa korrelatsioone lokaliseerida. Me ei saa osa andmeid panna ühele serverile, osa teisele ja arvutada, kõik andmed peavad olema igal pool.

Mida nad tegid? Algselt on andmed lokaliseeritud. Igal serveril hoitakse andmeid kindla aktsiapuhul hindade kohta. Need ei ühti. Seetõttu saab logReturni arvutada paralleelselt ja iseseisvalt, kõik toimub paralleelselt ja jaotatult.

Edasi otsustati andmeid vähendada, samas mitte kaotades väljendusrikkust. Vähendada massiivide abil, st iga ajavahemiku jaoks teha aktsiate massiiv ja hindade massiiv. Nii võtab see andmete hoidmiseks palju vähem ruumi. Ja nendega on veidi mugavam töötada. Need on peaaegu paralleelsed toimingud, st arvutame paralleelselt osaliselt ja siis kirjutame serverisse.

Pärast seda saab need replitseerida. Täht 'r' tähendab, et need andmed oleme replitseerinud. See tähendab, et kõikidel kolmel serveril on samad andmed - need massiivid.

Ja edasi erilise skripti abil saab sellest 12,5 miljonist korrelatsioonist, mida tuleb arvutada, teha pakendid. See tähendab 2 500 ülesannet, milles igaühes on 5 000 korrelatsiooni paari. Ja seda ülesannet arvutada konkreetses ClickHouse serveris. Kõik andmed on tal olemas, kuna andmed on samad ja ta saab neid järjestikku arvutada.

Veel, kuidas see välja näeb. Esiteks on meil kõik andmed sellises struktuuris: aeg, aktsiad, hind. Siis arvutasime logReturn, st andmed sama struktuuri, ainult et hinna asemel on meil nüüd logReturn. Siis tegime need ümber, st meil on aeg ja groupArray aktsiate ja hindade kaupa. Me replikeerisime. Ja pärast seda genereerisime hulga ülesandeid ja söötsime need ClickHouse' ile, et see neid arvutaks. Ja see töötab.

Proof of concept'i ülesanne - see oli alamülesanne, st võtsime vähem andmeid. Ja kõik vaid kolmel serveril.

Kaks esimest etappi: log_returni arvutamine ja massiividesse pakkimine võttis aega umbes tund.

Aga korrelatsiooni arvutamine võttis umbes 50 tundi. Kuid 50 tund on vähe, sest varem töötas see nädalate kaupa. See oli suur edu. Ja kui arvutada, siis 70 korda sekundis arvutati kogu selle klastriga.

Aga kõige tähtsam on see, et see süsteem on praktiliselt ilma kitsaskohtadeta, st see skaleerub praktiliselt lineaarselt. Ja nad on seda kontrollinud. Eduka skaleerimise saavutasid.

• Õige skeem on pool edu. Ja õige skeem on kõigi vajalike ClickHouse'i tehnoloogiate kasutamine.
• Summing/Aggregating MergeTrees - need on tehnoloogiad, mis võimaldavad agregreerida või arvutada snapshot state'i erijuhuks. See lihtsustab palju asju.
• Materialiseeritud vaated võimaldavad vältida ühe indeksi piirangut. Võib-olla ei selgitanud ma seda väga selgelt, kuid kui laadisime logisid, siis toored logid olid tabelis, kus oli üks indeks, ja atribuutlogid olid teises tabelis, st samad andmed, ainult filtreeritud, aga indeks oli täiesti erinev. Näib, et need on samad andmed, kuid erinev järjestus. Ja materialiseeritud vaated võimaldavad, kui see on vajalik, sellist ClickHouse'i piirangut vältida.
• Vähendage indeksi granulaarsust täppisteks päringuteks.
• Ja jaotage andmeid nutikalt, püüdke maksimaalselt lokaliseerida andmeid serveri sees. Ja püüdke, et päringud kasutaksid ka lokaliseerimist seal, kus see on võimalik maksimaalselt.

Kokkuvõttes võib öelda, et ClickHouse on kindlalt haaranud nii kommertsebase andmebaaside kui ka avatud lähtekoodiga andmebaaside territooriumi, st just analüüsi jaoks. See on suurepäraselt sobitunud sellele maastikule. Veelgi enam, see hakkab tasapisi teisi välja tõrjuma, sest kui teil on ClickHouse, siis ei vaja te InfiniDB-d. Veridika võib peagi olla ebavajalik, kui nad teevad normaalse SQL-i toe. Kasutage seda!

—Aitäh ettekande eest! Väga huvitav! Kas oli mingeid võrdlusi Apache Phoenixiga?

-Ei, ma ei ole kuulnud, et keegi oleks võrrelnud. Me ja Yandex püüame jälgida kõiki võrdlusi ClickHouse'i ja erinevate andmebaaside vahel. Sest kui äkki selgub, et midagi on kiirem kui ClickHouse, siis Aleksei Milovidov ei saa öösiti magada ja hakkab seda kiiresti kiirendama. Ma ei ole sellisest võrdlusest kuulnud.

• (Aleksei Milovidov) Apache Phoenix on SQL-mootor Hbase'i peal. Hbase on peamiselt mõeldud key-value tüüpi tööstsenaariumiteks. Iga rida võib sisaldada suvalist arvu veerge suvaliste nimedega. Seda saab öelda selliste süsteemide kohta nagu Hbase, Cassandra. Ja nende peal ei tööta tõsised analüütilised päringud normaalselt. Või võite arvata, et need töötavad normaalselt, kui teil pole ClickHouse'iga töökogemust.

• Aitäh

  • Tere päevast! Ma olen juba üsna palju selle teemaga huvitatud, kuna mul on analüütiline alamsüsteem. Kuid kui ma vaatan ClickHouse'i, siis mul on tunne, et ClickHouse sobib väga hästi sündmuste, muutuvate andmete analüüsimiseks. Ja kui mul on vaja analüüsida palju ärilisi andmeid koos suurte tabelitega, siis ClickHouse, nii palju kui ma aru saan, ei sobi mulle eriti? Eriti kui need muutuvad. Kas see on õige või on olemas näiteid, mis võiksid seda ümber lükata?

  • See on õige. Ja see kehtib enamiku spetsialiseeritud analüütiliste andmebaaside kohta. Need on optimeeritud selleks, et seal oleks üks või mitu suurt tabelit, mis on muutuvad, ja palju väikseid, mis aeglaselt muutuvad. Teisisõnu, ClickHouse ei ole nagu Oracle, kuhu saab panna kõike ja luua keerulisi päringuid. Et kasutada ClickHouse'i efektiivselt, tuleb skeem üles ehitada viisil, mis ClickHouse'is hästi töötab. See tähendab, et tuleks vältida liigset normaliseerimist, kasutada sõnastikke ja püüda luua vähem pikki seoseid. Ja kui skeem on üles ehitatud selliselt, siis sarnaseid ärilisi ülesandeid ClickHouse'is saab lahendada palju efektiivsemalt kui traditsioonilises relatsioonilises andmebaasis.

Aitäh ettekande eest! Mul on küsimus viimase finantsjuhtumi kohta. Neil oli analüüs. Tuleb võrrelda, kuidas asjad liiguvad üles-alla. Ja ma saan aru, et te ehitasite süsteemi just selle analüüsi jaoks? Kui neil homme, ütleme, on vaja mingit muud aruannet nende andmete põhjal, kas tuleb skeem uuesti üles ehitada ja andmed uuesti laadida? See tähendab, et tuleb teha mingisugune eelprotsess, et saada päring?

Muidugi, see on ClickHouse'i kasutamine täiesti konkreetse ülesande lahendamiseks. Seda on traditsiooniliselt võinud lahendada Hadoopi raames. Hadoopi jaoks on see ideaalne ülesanne. Kuid Hadoopis on see väga aeglane. Ja minu eesmärk on näidata, et ClickHouse'is on võimalik lahendada ülesandeid, mis tavaliselt lahendatakse täiesti teiste vahendite abil, kuid samas teha seda palju efektiivsemalt. See on konkreetselt ühele ülesandele kohandatud. Loomulikult, kui on sarnane ülesanne, siis on võimalik seda sarnasel viisil lahendada.

Selge. Te ütlesite, et töödeldi 50 tundi. Kas see algas algusest, kui andmed laaditi või kui tulemused saadi?

Jah-jah.

Hästi, suur aitäh.

See on 3-serveri klastris.

Tervitused! Aitäh ettekande eest! Kõik on väga huvitav. Ma küsin natuke mitte funktsionaalsuse kohta, vaid ClickHouse'i kasutamise kohta usaldusväärsuse seisukohalt. Kas teil on olnud mingeid probleeme, kas on tulnud taastada? Kuidas ClickHouse sel juhul käitub? Kas on olnud nii, et ka replikatsioon on kokku kukkunud? Me oleme näiteks ClickHouse'is kokku puutunud probleemiga, et see siiski ületab oma piiri ja kukub välja.

Muidugi ei ole ideaalset süsteemi. Ka ClickHouse'il on oma probleemid. Kuid kas olete kuulnud, et Yandex.Metrica ei töötanud pikka aega? Tõenäoliselt mitte. See on töötanud usaldusväärselt alates 2012-2013. aastast ClickHouse'il. Minu kogemuse kohta võin samuti öelda. Meil ei ole kunagi olnud täielikke rikkeid. Mõned osalised probleemid võivad juhtuda, kuid need pole kunagi olnud nii kriitilised, et tõsiselt äri mõjutada. Sedasorti olukordi ei ole kunagi olnud. ClickHouse on piisavalt usaldusväärne ega krahhi mingil ettearvamatul põhjusel. Selle pärast ei pea muretsema. See ei ole toores asi. Seda on tõestanud paljud ettevõtted.

Tere! Te ütlesite, et andmeskeemi tuleks kohe hästi läbi mõelda. Ent kui see on juba juhtunud? Andmed voolavad ja voolavad. Aasta möödub, ja ma saan aru, et nii ei saa elada, pean andmed uuesti üles laadima ja millegagi tegelema.

See sõltub muidugi teie süsteemist. On mitmeid viise, kuidas seda teha praktiliselt katkestusteta. Näiteks võite luua Materialized View, milles on teine andmestruktuur, kui seda saab ühemõtteliselt kaardistada. St. kui see lubab kaardistamist ClickHouse'i vahenditega, s.t. tuletada mõningaid asju, muuta primaarvõtit, muuta partitsioneerimist, siis saab teha Materialized View. Vanad andmed saab sinna kirjutada, uued kirjutatakse automaatselt. Ja siis lihtsalt lülituda Materialized View'i kasutamisele, seejärel lülitada kirjutamine ja vana tabel hävitada. See on täiesti katkestusteta meetod.

Aitäh.

Allikas: habr.com