Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Megjithëse informacioni tani është i pranishëm pothuajse kudo, databankat analitike ende mbeten mjaft ekzotike. Ato njihen pak dhe përdoren akoma më pak në mënyrë efikase. Shumë njerëz vazhdojnë të "hanë kaktus" me MySQL ose PostgreSQL, të cilat janë projektuar për skenarë të tjerë, të vuajnë me NoSQL, ose të paguajnë shumë për zgjidhje komerciale. ClickHouse ndryshon rregullat e lojës dhe ndjeshëm ul barrierat për t'u futur në botën e DBMS analitik.

Raporti nga BackEnd Conf 2018 dhe është publikuar me leje nga folësi.

Kush jam unë dhe pse po flas për ClickHouse? Unë jam drejtor i zhvillimit në kompaninë LifeStreet, e cila përdor ClickHouse. Për më tepër, unë jam themelues i Altinity. Kjo është një partner i Yandex, i cili promovon ClickHouse dhe ndihmon Yandex-in ta bëjë ClickHouse më të suksesshëm. Gjithashtu, jam i gatshëm të ndaj njohuri mbi ClickHouse.

Dhe akoma, unë nuk jam vëlla i Peti Zaitsev-it. Shpesh më pyesin për këtë. Jo, ne nuk jemi vëllezër.

"Të gjithë e dinë", se ClickHouse:

• Shumë i shpejtë,
• Shumë i përshtatshëm,
• Përdoret në Yandex.

Pak më pak dihet se në cilat kompani dhe si përdoret ai.

Do t'ju tregoj se për çfarë, ku dhe si përdoret ClickHouse, përveç Yandex-it.

Do të flas për mënyrat se si detyra specifike zgjidhen me ClickHouse në kompani të ndryshme, cilat mjete ClickHouse mund të përdorni për detyrat tuaja, dhe si janë përdorur ato në kompani të ndryshme.

Kam përgatitur tre shembuj që tregojnë ClickHouse nga disa këndvështrime. Mendoj se do të jetë interesante.

Pyetja e parë: "Pse është i nevojshëm ClickHouse?". Duket si një pyetje e qartë, por ka më shumë se një përgjigje.

• Përgjigja e parë – për shkak të performancës. ClickHouse është shumë i shpejtë. Analizat në ClickHouse gjithashtu janë shumë të shpejta. Ai shpesh mund të përdoret atje ku diçka tjetër punon shumë ngadalë ose shumë keq.
• Përgjigja e dytë – është kostoja. Në radhë të parë, kostoja e skalimit. Për shembull, Vertica është një bazë të dhënash krejtësisht e shkëlqyer. Ajo funksionon shumë mirë, nëse keni një sasi të vogël të terabajve të të dhënave. Por kur bëhet fjalë për qindra terabaj, ose petabaj, kostoja e licencës dhe mbështetjes arrin një shumë të konsiderueshme. Dhe kjo është e shtrenjtë. Ndërsa ClickHouse është falas.
• Përgjigjja e tretë është kostoja operacionale. Kjo është një qasje që vjen pak ndryshe. RedShift është një alternativë e shkëlqyer. Në RedShift, mund të krijoni zgjidhje shumë shpejt. Ajo do të funksionojë mirë, por çdo orë, çdo ditë dhe çdo muaj do të paguani mjaft shtrenjtë për Amazon, sepse ky është një shërbim tepër i kushtueshëm. Edhe Google BigQuery është i tillë. Nëse dikush e ka përdorur, e di se atje mund të ekzekutoni disa pyetje dhe të merrni një faturë që shkon në qindarka dollarë papritur.

Në ClickHouse nuk ka këto probleme.

Ku përdoret tani ClickHouse? Përveç Yandex, ClickHouse përdoret në shumë biznese dhe kompani të ndryshme.

• Në radhë të parë, kjo është analiza e aplikacioneve web, pra është një rast përdorimi që ka ardhur nga Yandex.
• Shumë kompani të AdTech përdorin ClickHouse.
• Shumë kompani që kanë nevojë të analizojnë logët operative nga burime të ndryshme.
• Disa kompani përdorin ClickHouse për monitorimin e logëve të sigurisë. Ato i ngarkojnë në ClickHouse, bëjnë raporte dhe marrin rezultatet e nevojshme.
• Kompani po fillojnë ta përdorin në analizën financiare, pra gradualisht biznesi i madh po e pranon gjithashtu ClickHouse.
• CloudFlare. Nëse dikush po ndjek ClickHouse, me siguri ka dëgjuar për emrin e kësaj kompanie. Ky është një nga kontribuesit e rëndësishëm nga komuniteti. Ata kanë një instalim shumë të rëndësishëm të ClickHouse. Për shembull, ata krijuan Kafka Engine për ClickHouse.
• Kompani telekomunikacioni kanë filluar ta përdorin. Disa kompani ClickHouse e përdorin ose si provë koncepti, ose tashmë në prodhim.
• Një kompani e përdor ClickHouse për monitorimin e proceseve prodhuese. Ata testojnë çipa, regjistrojnë shumë parametra, rreth 2,000 karakteristika. Dhe më pas analizojnë – është një partinë e mirë apo e keqe.
• Analiza e blockchain. Ekziston një kompani ruse e quajtur Bloxy.info. Kjo është analiza e rrjetit ethereum. Këta e realizuan gjithashtu në ClickHouse.

Shkallëzimi nuk ka rëndësi. Ka shumë kompani që përdorin një server të vogël. Dhe ai u lejon atyre të zgjidhin problemet e tyre. Dhe më shumë kompani përdorin klastera të mëdhenj me shumë servera ose dhjetëra servera.

Dhe nëse shikoni rekordet, atëherë:

• Yandex: 500+ servera, 25 miliardë regjistrime në ditë që ata ruajnë aty.
• LifeStreet: 60 servera, rreth 75 miliardë regjistrime në ditë. Më pak servera, më shumë regjistrime se në Yandex.
• CloudFlare: 36 serverë, 200 miliardë regjistrime në ditë ata ruajnë. Ata kanë edhe për së tepërmi pak serverë dhe edhe më shumë të dhëna që ruajnë.
• Bloomberg: 102 server, rreth një trilion regjistrimesh në ditë. Rekordmeni për regjistrime.

Gjeografikisht – është gjithashtu shumë. Kjo hartë tregon heatmap-in, ku ClickHouse përdoret në botë. Këtu spikasin qartë Rusia, Kina, Amerika. Ka pak vende evropiane. Dhe mund të veçojmë 4 klastera.

Ky është një analizë krahasuese, nuk ka nevojë të kërkosh numra absolutë. Ky është një analizë e vizitorëve që lexojnë materiale në anglishte në faqen e Altinity, sepse atje nuk ka material në rusisht. Dhe Rusia, Ukraina, Bjellorusia, dmth. pjesa rusishtfolëse e komunitetit, janë përdoruesit më të shumtë. Më pas vjen SHBA dhe Kanada. Kina po ngjitet shumë shpejt. Para gjashtë muajve nuk kishte pothuajse asgjë nga Kina, tani Kina ka kaluar Evropën dhe vazhdon të rritet. Vjetër-Evropa gjithashtu nuk mbetet prapa, ndërsa lideri në përdorimin e ClickHouse është, siç nuk është për t'u besuar, Franca.

Pse po tregoj gjithë këtë? Për të treguar se ClickHouse po bëhet zgjidhja standarde për analizimin e të dhënave të mëdha dhe se po përdoret në shumë vende. Nëse e përdorni, jeni në rrugën e duhur. Nëse ende nuk e përdorni, mund të mos keni frikë se do të mbeteni vetëm dhe askush nuk do t'ju ndihmojë, sepse shumë njerëz tashmë po merren me këtë.

Këto janë shembuj të përdorimit të vërtetë të ClickHouse në disa kompani.

• Shembulli i parë është një rrjet reklamash: migrimi nga Vertica në ClickHouse. Dhe unë di disa kompani që janë transferuar nga Vertica ose janë në procesin e kalimit.
• Shembulli i dytë është një depo tranzaksionesh në ClickHouse. Ky është një shembull i ndërtuar mbi antipat ndërsa. Çdo gjë që nuk duhet bërë në ClickHouse sipas këshillave të zhvilluesve, këtu është bërë. Dhe gjithashtu është bërë aq efektivisht sa funksionon. Dhe funksionon shumë më mirë se një zgjidhje tipike tranzaksionesh.
• Shembulli i tretë është llogaritjet e shpërndara në ClickHouse. Kishte një pyetje në lidhje me mënyrën se si mund të integrohet ClickHouse në ekosistemin Hadoop. Do të tregoj një shembull se si një kompani bëri në ClickHouse diçka si një analog të kontejnerit map reduce, duke mbajtur parasysh lokalizimin e të dhënave etj., për të llogaritur një detyrë shumë jo triviale.

• LifeStreet – është një kompani Ad Tech, që ka të gjitha teknologjitë përkatëse për një rrjet reklamash.
• Ajo merret me optimizimin e reklamave, ofertat programatike.
• Shumë të dhëna: rreth 10 miliard ngjarje në ditë. Në të njëjtën kohë, këto ngjarje mund të ndahen në disa nën-ngjarje.
• Shumë klientë përdorin këto të dhëna, dhe kjo nuk janë vetëm njerëzit, ka shumë më tepër – janë algoritme të ndryshme që merret me ofertat programatike.

Kompania ka kaluar një rrugë të gjatë dhe me sfida. E kam përmendur këtë në HighLoad. Fillimisht, LifeStreet kaloi nga MySQL (me një ndalesë të vogël në Oracle) në Vertica. Dhe mund të gjeni informacion mbi këtë.

Gjithçka shkoi shumë mirë, por mjaft shpejt u kuptua që të dhënat po rriteshin dhe Vertica është e shtrenjtë. Prandaj, u kërkuan alternativa të ndryshme. Disa prej tyre janë përmendur këtu. Në të vërtetë, ne bëmë një provë koncepti ose ndonjëherë testim performancë për gati të gjitha databazat që ishin në dispozicion në treg nga viti 2013 deri në 2016 dhe që përshtateshin për funksionalitetin. Dhe për disa prej tyre kam folur gjithashtu në HighLoad.

I ishte një detyrë – të migrohej nga Vertica fillimisht, sepse të dhënat po rriteshin. Ato rriteshin eksponencialisht për disa vite. Pastaj dolën në një nivel të caktuar, megjithatë. Duke parashikuar këtë rritje, kërkesat e biznesit për volum të të dhënave, për të cilat duhet të bëhej ndonjë analizë, ishte e qartë se shumë shpejt do të diskutohej për petabajt. Dhe për petabajt, pagesa tashmë është shumë e shtrenjtë, prandaj po kërkonim alternativë ku mund të iknim.

Ku të iknim? Dhe për një kohë të gjatë ishte krejtësisht e paqartë, ku të iknim, sepse nga njëra anë ekzistojnë bazat e të dhënave komerciale, ato duket se funksionojnë mirë. Disa funksionojnë pothuajse po aq mirë sa Vertica, disa më keq. Por të gjitha janë të shtrenjta, nuk arritëm të gjenim asgjë më të lirë dhe më të mirë.

Nga ana tjetër, ekzistojnë zgjidhje open source, të cilat nuk janë shumë, dmth. për analizë mund të numërohen me gishta. Dhe ato janë pa pagesë ose të lira, por funksionojnë ngadalë. Dhe shpesh u mungon funksionaliteti i nevojshëm dhe i dobishëm.

Dhe për të kombinuar ato të mira që ekzistojnë në bazat e të dhënave komerciale dhe gjithçka që është pa pagesë në open source, nuk kishte asgjë.

Nuk kishte asgjë deri sa papritur Yandex nxori, si një magjistar që nxjerr një lepur nga një kapelë, ClickHouse. Dhe kjo ishte një zgjidhje e papritur, ende shijoje pyetjen: "Pse?", por megjithatë.

Dhe menjëherë në verën e vitit 2016 filluam të shikojmë se çfarë ishte ClickHouse. Dhe rezultoi se ndonjëherë mund të ishte më i shpejtë se Vertica. Ne testuam skenarë të ndryshëm me kërkesa të ndryshme. Dhe nëse kërkesa përdorte vetëm një tabelë, pra pa ndonjë bashkëngjitje (join), ClickHouse ishte dy herë më i shpejtë se Vertica.

Nuk u larova dhe shikova testet e Yandex në ditët e fundit. Aty ishte e njëjta gjë: ClickHouse dy herë më i shpejtë se Vertica, prandaj ata shpesh flasin për këtë.

Por nëse kërkesat përmbajnë bashkëngjitje (join), atëherë gjithçka bëhet jo shumë e qartë. Dhe ClickHouse mund të jetë dy herë më i ngadaltë se Vertica. Por nëse pak e rregullojmë kërkesën dhe e rishkruajmë, atëherë janë afërsisht të barabarta. Jo keq. Dhe falas.

Dhe duke marrë rezultatet e testeve dhe duke e parë nga kënde të ndryshme, LifeStreet kaloi në ClickHouse.

Kjo është vitin 2016, kujtoj. Ishte si në një anekdotë për miqtë, që qanin dhe mbusheshin me gjilpërë, por vazhdonin të hanin kaktusin. Dhe për këtë u përshkrua në detaje, ka video për të, etj.

Prandaj nuk do të flas në detaje rreth kësaj, do të ndaj vetëm rezultatet dhe disa gjëra interesante që nuk i kam përmendur atëherë.

Rezultatet janë:

• Migrimi i suksesshëm dhe sistemi tashmë funksionon në prodhim për më shumë se një vit.
• Performanca dhe fleksibiliteti janë rritur. Nga 10 miliardë regjistrime që mund të lejonim të ruheshin për një ditë dhe atë për një kohë të shkurtër, tani LifeStreet ruan 75 miliardë regjistrime në ditë dhe mund ta bëjë këtë për 3 muaj e më shumë. Në pikun e aktivitetit, ruhet deri në një milion ngjarje në sekondë. Më shumë se një milion kërkesa SQL në ditë arrijnë në këtë sistem, kryesisht nga robotë të ndryshëm.
• Megjithëse për ClickHouse po përdoren më shumë serverë se për Vertica, kursimi dhe në hardware është arritur, sepse në Vertica janë përdorur disqe SAS mjaft të shtrenjta. Ndërsa në ClickHouse janë përdorur SATA. Pse? Sepse në Vertica, inserti është sinkron. Dhe sinkronizimi kërkon që disqet të mos ngadalësohen shumë, si dhe rrjeti të mos ngadalësohet shumë, dmth, është një operacion mjaft i shtrenjtë. Ndërsa në ClickHouse, inserti është asinkron. Për më tepër, gjithçka mund të shkruhet gjithmonë lokal, nuk ka shpenzime shtesë për këtë, prandaj të dhënat në ClickHouse mund të futen shumë më shpejt se në Vertica edhe në disqe që nuk janë nga më të shpejtit. Ndërsa në lexim janë përafërsisht të njëjta. Leximi në SATA, nëse janë në RAID, atëherë kjo është e gjitha mjaft e shpejtë.
• Nuk janë të kufizuar nga licenca, dmth. 3 petabayta të dhënash në 60 serverë (20 serverë - është një replikë) dhe 6 trilion artikuj në fakte dhe agregate. Asgjë e tillë nuk mund të lejohej në Vertica.

Tani po kaloj në gjërat praktike në këtë shembull.

• E para - është një skemë efikase. Nga skema varet shumë.
• E dyta - është gjenerimi i SQL-it efikas.

Një pyetje tipike OLAP është një select. Disa kolona shkojnë në group by, disa kolona shkojnë në funksionet agregate. Ka një where, të cilën mund ta përshkruajmë si një prerje të kubit. I gjithë group by mund të përfaqësohet si një projekcion. Pra, kjo quhet analiza multidimensionale e të dhënave.

Dhe shpesh kjo modelizohet në formën e një skeme yll, kur ka një fakt qendror dhe karakteristikat e këtij fakti përreth, në rrezatimin jashtë.

Dhe nga këndvështrimi i dizajnit fizik, se si shtrihet në tabela, zakonisht bëhet një përfaqësim i normalizuar. Mund të bëni denormalizim, por kjo është e shtrenjtë në disk dhe jo shumë efikase në pyetje. Prandaj, zakonisht bëhet një përfaqësim i normalizuar, pra, tabela e faktit dhe shumë tabele dimensionale.

Por në ClickHouse kjo funksionon keq. Ka dy arsye:

• E para – është sepse në ClickHouse nuk ka shumë lidhje (join) të mira, pra, lidhje (join) ka, por ato janë të këqija. Ose për momentin janë të këqija.
• E dyta – është se tabelat nuk përditësohen. Zakonisht në këto tabela, që rrethojnë skemën e yllit, nevojitet të ndryshohet diçka. Për shembull, emri i klientit, emri i kompanisë dhe të tjera. Dhe kjo nuk funksionon.

Dhe ka dy zgjidhje për këtë në ClickHouse:

• E para në përdorimi i fjalorëve. Fjalorët e Jashtëm janë ato që ndihmojnë për të zgjidhur me 99% problemin e skemës star, me përditësimet dhe të tjera.
• E dyta – është përdorimi i masivave. Masivat gjithashtu ndihmojnë për të eliminuar bashkëngjitjet (join) dhe problemet me normalizimin.

• Nuk nevojiten bashkëngjitje (join).
• Të përditësueshme. Që nga marsi i vitit 2018, ka ardhur një mundësi e pa dokumentuar (nuk do ta gjeni në dokumentacion) për të përditësuar pjesërisht fjalorët, dmth, ato shënime që kanë ndryshuar. Praktikisht – është si një tabelë.
• Gjithmonë në memorie, kështu që bashkëngjitjet (join) me fjalorin punojnë më shpejt se sa do të ishte një tabelë që ndodhet në disk dhe nuk dihet akoma nëse është në cache, ndoshta nuk është.

• Po ashtu nuk nevojiten bashkëngjitje (join).
• Kjo është një përfaqësim kompakt 1 ndaj shumë.
• Dhe sipas mendimit tim, masivat janë bërë për geek-ët. Këto janë funksionet lambda dhe të tjera.

Kjo nuk është për fjalë të kuqe. Kjo është një funksionalitet shumë i fuqishëm që lejon të bëni shumë gjëra shumë thjesht dhe elegant.

Shembuj tipikë që ndihmojnë për të zgjidhur masivat. Këta shembuj janë të thjeshtë dhe mjaft të qartë:

• Kërkimi sipas etiketave. Nëse keni atje hashtag dhe dëshironi të gjeni disa shënime sipas hashtags.
• Kërkoni në parametrat key-value. Ka disa atribute me vlera gjithashtu.
• Ruani listat e çelësave që duhet t'i përktheni në ndonjë gjë tjetër.

Të gjitha këto detyra mund të zgjidhen pa masa. Etiketat mund të vendosen në një varg dhe të zgjedhen me shprehje reguli ose në një tabelë të veçantë, por atëherë do t'ju duhet të bëni bashkime (join).

Në ClickHouse nuk ka nevojë të bëni asgjë, mjafton të përshkruani një varg string për hashtagët ose të krijoni një strukturë të thelluar për sisteme si key-value.

Struktura e thelluar – ndoshta nuk është emri më i mirë. Janë dy vargje që kanë një pjesë të përbashkët në emër dhe disa karakteristika të lidhura.

Dhe të kërkosh për etiketën është shumë e thjeshtë. Ekziston një funksion ka, që kontrollon nëse një element është në varg. Këtu, gjetëm të gjitha regjistrimet që i përkasin konferencës tonë.

Kërkimi për subid është pak më i komplikuar. Fillimisht duhet të gjejmë indeksin e çelësit, pastaj të marrim elementin me këtë indeks dhe të kontrollojmë nëse vlera është ajo që duam. Megjithatë, është shumë e thjeshtë dhe kompakte.

Një shprehje e rregullt që do të dëshironit të shkruani, nëse do ta ruanit të gjitha këto në një rresht, do të ishte, para së gjithash, e çuditshme. Dhe, për më tepër, do të funksiononte shumë më ngadalë se dy tabela.

Një shembull tjetër. Keni një array ku ruani ID-të. Dhe mund t'i konvertoni ato në emra. Funksioni arrayMap. Ky është një funksion tipik lambda. Ju dërgoni atje shprehje lambda. Dhe ai nxjerr vlerën e emrit për secilën ID nga fjalori.

Në mënyrë të ngjashme, mund të bëni kërkimin. Kalohet një funksion predikati, i cili kontrollon se çfarë i përket elementeve.

Këto gjëra ndihmojnë shumë në thjeshtimin e skemës dhe zgjidhin shumë probleme.

Por problemi tjetër me të cilin u përballëm, dhe që do të doja të përmendja, janë kërkesat efektive.

• Në ClickHouse nuk ka planifikues kërkesash. Në tërësi, nuk ka.
• Megjithatë, kërkesat komplekse ende duhet të planifikohen. Në cilat raste?
• Nëse në kërkesë ka disa bashkime (join), të cilat i vendosni në sub-selekta. Dhe rendi në të cilin ata ekzekutohen ka rëndësi.
• Dhe e dyta – nëse kërkesa është e shpërndarë. Sepse në një kërkesë të shpërndarë, vetëm nënklauzola më e brendshme ekzekutohet në mënyrë të shpërndarë, ndërsa e gjithë pjesa tjetër dërgohet në një server, te i cili jeni lidhur dhe ekzekutohet atje. Prandaj, nëse keni kërkesa të shpërndara me shumë bashkëngjitje (join), duhet të zgjidhni rendin.

Edhe në raste më të thjeshta, ndonjëherë duhet të bëni punën e planifikuesit dhe të riformuloni paksa kërkesat.

Ja një shembull. Në anën e majtë është kërkesa që tregon 5 vendet kryesore. Dhe ajo ekzekutohet për 2,5 sekonda, mendoj. Ndërsa në anën e djathtë është e njëjta kërkesë, por pak e riformuluar. Në vend që të grupojmë sipas vargut, ne filluam të grupojmë sipas çelësit (int). Dhe kjo është më e shpejtë. Pastaj ne lidhim një fjalor me rezultatin. Në vend të 2,5 sekondave, kërkesa ekzekutohet për 1,5 sekonda. Kjo është mirë.

Një shembull i ngjashëm me riformulimin e filtrave. Këtu është një kërkesë për Rusinë. Ajo ekzekutohet për 5 sekonda. Nëse e riformulojmë në këtë mënyrë, që të krahasojmë përsëri jo vargje, por numra me një grup të atyre çelësave që lidhen me Rusinë, atëherë kjo do të jetë shumë më shpejt.

Kaç teknikë të tilla ka. Ato lejojnë të përshpejtohen ndjeshëm kërkesat që ndiheni se tashmë funksionojnë shpejt, ose, përkundrazi, që funksionojnë ngadalë. Mund të bëhen edhe më shpejt.

• Maksimumi i punës në mënyrë të shpërndarë.
• Së pari, renditja sipas llojeve minimale, ashtu siç e kam bërë me integerët.
• Nëse ka ndonjë bashkim (join), fjalorë, atëherë është më mirë t'i bëni ato në fund të fundit, kur të keni të dhënat e grumbulluara të paktën në pjesë, atëherë operacioni i bashkimit (join) ose thirrja e fjalorit do të ndodhë më pak herë dhe do të jetë më shpejt.
• Zëvendësimi i filtrave.

Ka edhe teknika të tjera, jo vetëm ato që unë demonstroj. Të gjitha këto ndonjëherë lejojnë përshpejtimin ndjeshëm të ekzekutimit të kërkesave.

Të kalojmë në shembullin tjetër. Kompania X nga SHBA. Çfarë bën ajo?

Ishte një detyrë:

• Lidhja offline e transaksioneve të reklamave.
• Modelimi i modeleve të ndryshme të lidhjes.

Në çfarë përbëhet skenari?

Një vizitor i zakonshëm hyn në sit, për shembull, 20 herë në muaj nga reklama të ndryshme ose ndonjëherë vjen thjesht sepse e mban mend këtë sit. Ai shikon disa produkte, i vendos në shportë, i nxjerr nga shporta. Dhe, në fund, diçka blen.

Pyetje të arsyeshme: "Kë duhet të paguajë për reklama nëse është e nevojshme?" dhe "Cila reklamë e ndikoi, nëse ndikoi?". Pra, përse bleu dhe si të sigurohemi që njerëz të ngjashëm me këtë person të blejnë gjithashtu?

Për të zgjidhur këtë detyrë, është e nevojshme të lidhen ngjarjet që ndodhin në uebsajt në mënyrën e duhur, pra të krijohet një lidhje ndërmjet tyre. Më pas ato duhet të dërgohen për analizë në DWH. Dhe në bazë të kësaj analize, të ndërtohen modele se kujt dhe cfarë reklame t'i tregojmë.

Transaksioni reklamues është një grup ngjarjesh të lidhura që fillon nga shfaqja e një reklame, pastaj ndodhin diçka, mund të jetë një blerje, dhe më pas mund të ketë blerje të tjera. Për shembull, nëse është një aplikacion mobil ose një lojë mobile, zakonisht instalimi i aplikacionit është falas, dhe nëse ndodhin aktivitete të tjera, mund të kërkohet pagesë për to. Sa më shumë të shpenzojë një person në aplikacion, aq më i vlefshëm është ai. Por për këtë duhet të lidhësh gjithçka.

Ka shumë modele lidhjeje.

Modelet më të njohura janë:

• Interaksioni i fundit, ku interaksioni është ose një klikim, ose një shfaqje.
• Interaksioni i parë, domethënë, ajo që e solli fillimisht personin në faqe.
• Kombinimi linear – të gjithë në mënyrë të barabartë.
• Zbehja.
• Dhe të tjera.

Si ka funksionuar gjithçka fillimisht? Ka pasur Runtime dhe Cassandra. Cassandra u përdor si ruajtje transaksionesh, dmth. të gjitha transaksionet e lidhura ruheshin atje. Kur ndodhte një ngjarje në Runtime, për shembull, shfaqja e një faqeje ose diçka tjetër, dikush bëhej një kërkesë në Cassandra – nëse ekzistonte ky person apo jo. Më pas nxirrnin transaksionet që i përkasin atij. Dhe bëhej lidhja.

Nëse ka fat që në kërkesë ka një ID transaksioni, është e lehtë. Por zakonisht nuk ka fat. Prandaj, duhej të gjendej transaksioni i fundit ose transaksioni me klikimin e fundit, etj.

Dhe gjithçka funksiononte shumë mirë derisa lidhja ishte me klikimin e fundit. Sepse, le të themi, ka 10 milion klikime në ditë, 300 milion në muaj, nëse vendosni një dritare për muajin. Dhe pasi që në Cassandra gjithçka duhet të jetë në memorie për të funksionuar shpejt, sepse kërkohet që Runtime të japë përgjigje shpejt, nevojiteshin rreth 10-15 serverë.

Dhe kur u dëshirua të lidhej transaksioni me shfaqjen, menjëherë kjo nuk doli aq argëtuese. Pse? Duke parë, është e qartë se duhen ruajtur 30 herë më shumë ngjarje. Dhe, për rrjedhojë, nevojiten 30 herë më shumë serverë. Dhe rezulton se është një numër astronomik. Të mbash deri në 500 serverë për të bërë lidhje, ndërsa në Runtime ka shumë më pak serverë, kjo është një shifër e gabuar. Dhe filluam të mendojmë se çfarë të bëjmë.

Dhe arritëm te ClickHouse. Si mund ta bëjmë këtë në ClickHouse? Në shikim të parë duket si një grup antipatish.

• Transaksioni po rritet, ne po lidhim ngjarje të reja me të, pra është mutable, dhe ClickHouse nuk punon shumë mirë me objekte mutable.
• Kur na vjen një vizitor, ne duhet të nxjerrim transaksionet e tij sipas çelësit, sipas visit ID-së së tij. Kjo gjithashtu është një point query, dhe në ClickHouse nuk bëhet kështu. Zakonisht në ClickHouse ka skane të mëdha... dhe këtu na nevojitet të nxjerrim disa regjistra. Po ashtu është një antipattern.
• Përveç kësaj, transaksioni ishte në json, por nuk donin ta ri-shkruanin, kështu që donin ta ruanin json-in në një formë jo të strukturuar, dhe nëse ishte e nevojshme, të nxirrnin diçka nga ai. Dhe kjo gjithashtu është një antipattern.

Pra, një grup antipatternesh.

Por megjithatë, arritëm të krijojmë një sistem që punonte shumë mirë.

Çfarë është bërë? U shfaq ClickHouse, në të cilin hidhen logët, të ndara në regjistra. U shfaq një shërbim i atribuar, i cili merr logët nga ClickHouse. Pas kësaj, për secilin regjistër sipas visit id, merrte transaksionet që mund të ishin akoma të pa përpunuara dhe plus snapshots, domethënë transaksionet tashmë të lidhura, veçanërisht rezultati i punës së mëparshme. Nga ato, krijohej logjika, zgjidheshin transaksionet e duhura, bashkoheshin ngjarje të reja. Përsëri regjistrohej në log. Logu shkonte përsëri në ClickHouse, domethënë kjo është një sistem i vazhdueshëm ciklik. Dhe përveç kësaj, shkonte në DWH për ta analizuar atje.

Në këtë formë, kjo nuk funksiononte shumë mirë. Dhe për ta bërë më të lehtë ClickHouse, kur kishte një kërkesë sipas visit id, kërkesat grupoheshin në blloqe nga 1,000-2,000 visit id dhe merrnim për 1,000-2,000 njerëz të gjitha transaksionet. Dhe atëherë gjithçka filloi të funksionojë.

Nëse shikoni brenda ClickHouse, ka vetëm 3 tabela kryesore që e shërbejnë këtë.

Tabela e parë, ku hidhen logët, dhe logët hidhen praktikisht pa u përpunuar.

Tabela e dytë. Përmes materialized view nga këto log-e, u nxorrën evenete që ende nuk ishin të atribuuara, dmth të pa lidhura. Dhe përmes materialized view nga këto log-e u nxorrën transaksionet për ndërtimin e snapshot-it. Pra, një materialized view i veçantë ndërtoi snapshot-in, konkretisht gjendjen e fundit të akumuluar të transaksionit.

Këtu është shkruar teksti në SQL. Do të doja të komentoj disa gjëra të rëndësishme në të.

Gjëja e parë e rëndësishme – është mundësia në ClickHouse për të nxjerrë kolona, fusha nga json. Pra, në ClickHouse ka disa metoda për të punuar me json. Ato janë shumë, shumë primitive.

visitParamExtractInt lejon të nxjerrësh atribute nga json, dmth, e para që kapet aktivizohet. Dhe në këtë mënyrë mund të nxjerrësh transaction id ose visit id. Kjo është një.

E dyta – këtu është përdorur një fushë materialized e zgjuar. Çfarë do të thotë kjo? Do të thotë se nuk mund ta përfshish në tabelë, dmth nuk shtohet, por llogaritet dhe ruhet gjatë proçesit të shtimit. Gjatë shtimit, ClickHouse bën punën për ju. Dhe pastaj nxirret nga json ajo që do t'ju nevojitet më pas.

Në këtë rast, materialized view është për rreshta të papërpunuar. Dhe pikërisht përdoret tabela e parë me log-e praktikisht të papërpunuara. Çfarë bën? Së pari, ndryshon renditjen, dmth. renditja tani bëhet sipas visit id, sepse na nevojitet të nxjerrim shpejt transaksionin e një individi të caktuar.

I dyti aspekt i rëndësishëm është index_granularity. Nëse keni parë MergeTree, zakonisht në default është 8,192 për index_granularity. Çfarë është kjo? Ky është një parametër i hollësisë së indeksit. Në ClickHouse indeksi është i hollë, ai nuk indekson kurrë çdo regjistrim. E bën këtë çdo 8,192. Kjo është mirë kur nevojiten shumë të dhëna për të llogaritur, por e keqe kur nevojiten pak, sepse ka një overhead të madh. Dhe nëse e zvogëlojmë index granularity, ne zvogëlojmë overhead-in. Nuk mund ta zvogëlojmë deri në një, sepse mund të mos ketë mjaftueshëm memorie. Indeksi gjithmonë ruhet në memorien.

Dhe snapshot-i përdor disa funksione interesante të ClickHouse.

Së pari, ky është AggregatingMergeTree. Në AggregatingMergeTree ruhet argMax, pra kjo është gjendja e transaksionit që korrespondon me timestamp-in e fundit. Transaksionet gjithëmonë krijohen të reja për këtë vizitor. Dhe në gjendjen më të fundit të këtij transaksioni ne kemi shtuar një event dhe tani kemi një gjendje të re. Ajo përsëri është rifutur në ClickHouse. Dhe përmes argMax në këtë paraqitje materializuar gjithmonë mund të marrim gjendjen aktuale.

• Lidhja "e çmontuar" nga Runtime.
• Ruhet dhe përpunohen deri në 3 miliard transaksionesh në muaj. Kjo është shumë më shumë se në Cassandra, pra në një sistem tipik transaksionesh.
• Kluster i 2x5 serverave ClickHouse. 5 servera dhe çdo server ka një replikë. Kjo është edhe më pak se sa ishte në Cassandra për të realizuar atributimin bazuar në klikë, ndërsa këtu kemi atributimin bazuar në impresion. Pra, në vend që të rritej numri i serverave 30 herë, ata arritën ta ulen.

Dhe shembulli i fundit – është kompania financiare Y, e cila analizoi korrelacionet e ndryshimeve të çmimeve të aksioneve.

Dhe detyra ishte e tillë:

• Ka rreth 5,000 aksione.
• Çmimet çdo 100 milisekonda janë të njohura.
• Të dhënat janë grumbulluar për 10 vjet. Njëherazi, për disa kompani më shumë, për disa më pak.
• Në total rreth 100 miliardë rreshta.

Dhe duhej të llogaritej korelacioni i ndryshimeve.

Këtu janë dy aksione dhe kotacionet e tyre. Nëse njëra ngjitet, dhe tjetra ngjitet, atëherë kjo është korelacion pozitiv, dmth, një rritet dhe tjetra rritet. Nëse njëra ngjitet, si në fund të grafikut, ndërsa tjetra bie, atëherë kjo është korelacion negativ, dmth, kur një rritet, tjetra bie.

Duke analizuar këto ndryshime të ndërsjellta mund të bëhen parashikime në tregun financiar.

Por detyra është e komplikuar. Çfarë bëhet për këtë? Ne kemi 100 miliardë regjistrime, në të cilat ka: koha, aksioni dhe çmimi. Na nevojitet të llogarisim fillimisht 100 miliardë herë vlerën e runningDifference nga algoritmi i çmimit. RunningDifference është një funksion në ClickHouse, i cili llogarit ndryshimin mes dy rreshtave njëpasnjëshëm.

Dhe pas kësaj, duhet të llogaritet korelacioni, për më tepër korelacioni duhet të llogaritet për çdo çift. Për 5,000 aksione, ka 12.5 milionë çifte. Dhe kjo është shumë, dmth, 12.5 herë duhen llogaritur një funksion të tillë korelacioni.

Dhe nëse dikush e harroi, atëherë ͞x dhe ͞y janë pritet e matematikës në mostrën. Pra, duhet jo vetëm të llogarisni rrënjët dhe shumat, por gjithashtu brenda këtyre shumave të bëni edhe një herë shuma. Duhen kryer shumë llogaritje 12.5 milion herë, dhe gjithashtu duhet të grupohen sipas orëve. Dhe orët kemi të shumta. Dhe duhet ta përfundojmë brenda 60 sekondave. Kjo është një shaka.

Duhej të arrinim të bënim diçka, sepse gjithë kjo punonte shumë-ngadalë, para se të vinte ClickHouse.

Ata u përpoqën ta llogaritnin këtë në Hadoop, në Spark, në Greenplum. Dhe gjithçka ishte shumë ngadalë ose e shtrenjtë. Pra, ishte e mundur ta llogarisnin në një farë mënyre, por më pas ishte e shtrenjtë.

Dhe pastaj erdhi ClickHouse dhe gjithçka u përmirësua shumë.

Ju kujtoj, problemi ynë është me lokalitetin e të dhënave, prandaj korrelacionet nuk mund të lokalizohen. Nuk mund të grumbullojmë një pjesë të të dhënave në një server, një pjesë në një tjetër dhe ta llogarisim, sepse ne duhet të kemi të gjitha të dhënat kudo.

Çfarë bënë ata? Fillimisht të dhënat ishin të lokalizuara. Në secilin nga serverët ruheshin të dhënat për çmimet e një grupi të caktuar të aksioneve. Dhe ato nuk ndërthuren. Prandaj është e mundur të llogaritet logReturn paralelisht dhe në mënyrë të pavarur, gjithçka ndodh ndërkohë në mënyrë paralele dhe të shpërndarë.

Më pas vendosëm t'i reduktonim këto të dhëna, pa humbur asnjë shprehshmëri. T'i reduktonim përmes masivave, dmth, për secilën periudhë kohore të krijonim një masiv të aksioneve dhe një masiv të çmimeve. Kështu të dhënat zënë shumë më pak hapësirë. Dhe është më e lehtë të punosh me to. Këto janë praktika pothuajse paralele, dmth, ne llogarisim pjesërisht në mënyrë paralele dhe më pas i regjistrojmë në server.

Pas kësaj, këto mund të replikohen. Shkronja "r" tregon se këto të dhëna i kemi replikuar. Domethënë, ne kemi të njëjtat të dhëna në të tri serverat - këto masiva.

Më pas, me një skript të veçantë nga ky grup prej 12.5 milion korrelacionesh që duhet të llogariten, mund të krijohen pako. Domethënë, 2,500 detyra me 5,000 çifte korrelacionesh. Dhe këtë detyrë do ta llogarisim në një server të caktuar ClickHouse. Të gjithë të dhënat i ka, sepse të dhënat janë të njëjta dhe ai mund t'i llogarisë ato në mënyrë të radhitur.

Për herë tjetër, si duket kjo? Së pari, ne kemi të gjitha të dhënat në një strukturë të tillë: koha, aksionet, çmimi. Pastaj kemi llogaritur logReturn, pra të dhënat e së njëjtës strukturë, vetëm se në vend të çmimit tani kemi logReturn. Më pas, i kemi transformuar, pra kemi marrë kohën dhe groupArray për aksionet dhe çmimet. I kemi bërë të gjitha bashkë. Dhe, pas kësaj, kemi gjeneruar një sasi të madhe detyrash dhe i kemi ushqyer ClickHouse-i për ta llogaritur. Dhe kjo funksionon.

Në provën e konceptit, detyra ishte një nën-detyrë, pra kemi marrë më pak të dhëna. Dhe gjithçka në tre serverë.

Këto dy etapa të para: llogaritja e Log_return dhe rrethimi në kodi, zuri rreth një orë secila.

Ndërsa llogaritja e korrelacionit zuri rreth 50 orë. Por 50 orë janë pak, sepse më parë ky proces kishte zgjatur javë të tëra. Kjo ishte një sukses i madh. Dhe nëse e llogaritim, në këtë klaster gjithçka llogaritej 70 herë në sekondë.

Por më e rëndësishmja, kjo sistem është praktikisht pa ngushtica, pra ajo shkallëzohet praktikisht linear. Dhe ata e kanë verifikuar këtë. E kanë shkallëzuar me sukses.

• Skema e duhur është gjysma e suksesit. Dhe skema e duhur është përdorimi i të gjitha teknologjive të nevojshme të ClickHouse.
• Summing/AggregatingMergeTrees – janë teknologji që lejojnë agregimin ose llogaritjen e snapshots state si një rast të veçantë. Kjo e thjeshton ndjeshëm shumë gjëra.
• Materialized Views lejojnë të anashkaloni kufizimin e një indeksi. Ndoshta nuk e kam shprehur shumë qartë, por kur ngarkonim log-et, log-et e papërpunuara ishin në një tabelë me një indeks, ndërsa log-et mbi atributet ishin në një tabelë, pra të njëjtat të dhëna, vetëm të filtruar, por indeksi ishte krejtësisht ndryshe. Duket si të njëjtat të dhëna, por renditja është e ndryshme. Dhe Materialized Views lejon, nëse e keni nevojë, të anashkaloni një kufizim të tillë në ClickHouse.
• Reduktoni granularitetin e indeksit për kërkesa specifike.
• Dhe shpërndani të dhënat në mënyrë të mençur, kërkoni të lokalizoni sa më shumë që të jetë e mundur të dhënat brenda serverit. Gjithashtu, përpiquni që kërkesat të përdorin gjithashtu lokalizimin aty ku është e mundur maksimalisht.

Duke përmbledhur këtë fjalim të vogël, mund të themi se ClickHouse tani ka zënë qartë pozita në territoret e bazave të dhënave komerciale dhe ato open source, dmth. pikërisht për analizën. Ai është integruar mrekullisht në këtë peizazh. E më shumë se kaq, ai gradualisht po fillon të zëvendësojë të tjerët, sepse kur keni ClickHouse, nuk ju nevojitet InfiniDB. Vertica, ndoshta për shpejt do të bëhet e panevojshme, nëse ata realizojnë një mbështetje të duhur për SQL. Përdorni!

—Faleminderit për referatin! Shumë interesante! A kishte ndonjë krahasim me Apache Phoenix?

-Jo, nuk kam dëgjuar që dikush të ketë bërë krahasime. Ne dhe Yandex përpiqemi të ndjekim të gjitha krahasimet e ClickHouse me bazat e ndryshme të dhënash. Sepse nëse ndonjëherë diçka del më e shpejtë se ClickHouse, atëherë Alexey Milovidov nuk mund të flejë në netë dhe fillon ta përshpejtojë atë menjëherë. Nuk kam dëgjuar për një krahasim të tillë.

• (Алексей Миловидов) Apache Phoenix – është një motor SQL mbi Hbase. Hbase është kryesisht e dizajnuar për skenarë pune të llojit key-value. Atje në çdo rresht mund të ketë një numër të rastësishëm kolonash me emra të rastësishëm. Kjo mund të thuhet për sisteme si Hbase, Cassandra. Dhe për ta, kërkesat analitike të rënda nuk do të funksionojnë siç duhet. Ose mund të mendoni se ato funksionojnë mirë, nëse nuk keni pasur asnjë përvojë me ClickHouse.

• Faleminderit

  • Përshëndetje! Unë kam qenë duke u interesuar për këtë temë për një kohë të gjatë, sepse unë kam një nën-sistem analitik. Por kur shoh ClickHouse, ndiej se ClickHouse është shumë i përshtatshëm për analizën e eventeve, mutable. Dhe nëse kam nevojë të analizoj shumë të dhëna biznesi me një mori tabelash të mëdha, atëherë ClickHouse, aq sa kuptoj, nuk është shumë i përshtatshëm për mua? Sidomos nëse ato ndryshojnë. A është kjo e saktë apo ka shembuj që mund ta falsifikojnë këtë?

  • Kjo është e saktë. Dhe kjo vlen për shumicën e bazave të të dhënave analitike të specializuara. Ato janë të dizajnuara për të punuar me njërën ose më shumë tabela të mëdha, që janë të ndryshueshme, dhe shumë të vogla që ndryshojnë ngadalë. Domethënë, ClickHouse nuk është si Oracle, ku mund të vendosni gjithçka dhe të ndërtoni kërkesa shumë komplekse. Për ta përdorur ClickHouse në mënyrë efektive, duhet të zhvilloni skemën në një mënyrë që funksionon mirë në ClickHouse. Domethënë, të shmangni normalizimin e tepruar, të përdorni fjalorë, dhe të përpiqeni të keni më pak lidhje të gjata. Nëse skema është zhvilluar në këtë mënyrë, ato detyra të ngjashme biznesi në ClickHouse mund të zgjidhen shumë më efikashem se sa në një bazë të dhënash relacional tradicionale.

Faleminderit për raportin! Kam një pyetje për rastin financiar të fundit. Ata kishin analizën. Duhej të krahasohej si shkonin lart-poshtë. Dhe e kuptoj se ju ndërtuat sistemin pikërisht për këtë analizë? Nëse nesër, supozoni, atyre u nevojitet një raport tjetër mbi këto të dhëna, a duhet ri-ndërtuar skema dhe të ngarkohen të dhënat përsëri? Domethënë, të bëni ndonjë përpunim paraprak për të marrë kërkesën?

Sigurisht, ky është përdorimi i ClickHouse për një detyrë mjaft specifike. Ajo tradicionalisht mund të zgjidhej brenda Hadoop. Për Hadoop – kjo është një detyrë ideale. Por në Hadoop është shumë e ngadaltë. Qëllimi im është të demonstroj se me ClickHouse mund të zgjidhni detyra që zakonisht zgjidhen me mjete krejtësisht të tjera, por duke e bërë këtë shumë më efikase. Kjo është e destinuar për një detyrë specifike. Është e qartë se nëse ka një detyrë të ngjashme, mund ta zgjidhni në një mënyrë të ngjashme.

E kuptoj. Ju thatë se u përpunuan 50 orë. A është kjo që nga fillimi, kur u ngarkuan të dhënat apo kur morët rezultatet?

Po-po.

Mirë, faleminderit shumë.

Kjo është në një klaster me 3 servera.

Përshëndetje! Faleminderit për prezantimin! Gjithçka është shumë interesante. Unë do të pyes pak jo për funksionalitetin, por për përdorimin e ClickHouse nga pikëpamja e stabilitetit. Domethënë, a keni hasur ndonjëherë në ndonjë kërkesë, keni pasur nevojë të riktheni? Si sillet ClickHouse në këto raste? A ka ndodhur që edhe replicimi të ketë dështuar? Na, për shembull, kemi hasur në problemin me ClickHouse kur ai kalon kufirin e tij dhe dështon.

Sigurisht, sistemet ideale nuk ekzistojnë. Edhe ClickHouse ka problemet e veta. Por a keni dëgjuar që Yandex.Metrika ka funksionuar gjatë dhe nuk ka punuar? Ndoshta jo. Ajo ka funksionuar me besueshmëri që nga viti 2012-2013 mbi ClickHouse. Edhe për përvojën time mund të them. Kurrë nuk kemi pasur ndalime totale. Disa gjëra të pjesshme mund të kanë ndodhur, por ato kurrë nuk kanë qenë kaq kritike sa të ndikojnë seriozisht në biznes. Kurrë nuk ka ndodhur. ClickHouse është mjaft i besueshëm dhe nuk bien rastësisht. Mund të mos shqetësoheni për këtë. Nuk është një gjë e papërfunduar. Kjo është provuar nga shumë kompani.

Përshëndetje! Thatë se duhet të mendohet mirë për skemën e të dhënave nga fillimi. Po nëse kjo ndodhi? Të dhënat e mia po derdhen. Kalon gjysmë viti, dhe kuptoj që nuk mund të jetoj kështu, duhet të rishkarkoj të dhënat dhe të bëj diçka me to.

Sigurisht, kjo varet nga sistemi juaj. Ka disa mënyra për ta bërë këtë praktikisht pa ndalesa. Për shembull, mund të krijoni një Materialized View, në të cilin të krijoni një strukturë të ndryshme të dhënash, nëse ajo mund të mapohet qartë. Pra, nëse ajo lejon mapimin përmes ClickHouse, dmth. nxjerrjen e disa gjërave, ndryshimin e çelësit primar, ndryshimin e ndarjes në particione, atëherë mund të krijoni një Materialized View. Atje do të shkruani të dhënat tuaja të vjetra, dhe të rejat do të shkruhen automatikisht. Pastaj, thjesht ndërroni në përdorimin e Materialized View, pas kësaj ndryshoni shkrimin dhe fshini tabelën e vjetër. Kjo është një mënyrë për ta bërë pra pa ndalesa.

Faleminderit.

Burimi: habr.com