Teory en praktyk fan it brûken fan ClickHouse yn echte applikaasjes. Alexander Zaitsev (2018)

Nettsjinsteande it feit dat der no hast oeral in protte gegevens binne, binne analytyske databases noch altyd frij eksoatysk. Se binne min bekend en noch minder yn steat om se effektyf te brûken. In protte bliuwe "de kaktus ite" mei MySQL of PostgreSQL, dy't binne ûntworpen foar oare senario's, wrakselje mei NoSQL, of tefolle betelje foar kommersjele oplossingen. ClickHouse is in spultsje-wikseler en ferleget de barriêre foar yngong yn 'e wrâld fan analytyske DBMS signifikant.

It rapport is fan BackEnd Conf 2018 en it wurdt publisearre mei tastimming fan 'e sprekker.

Wa bin ik en wêrom praat ik oer ClickHouse? Ik bin de direkteur fan ûntwikkeling by LifeStreet, dy't ClickHouse brûkt. Ik bin ek de oprjochter fan Altinity. Dit is in Yandex-partner dy't ClickHouse befoarderet en Yandex helpt om ClickHouse suksesfol te meitsjen. Ik bin ek ree om kennis te dielen oer ClickHouse.

En ik bin ek net de broer fan Petya Zaitsev. Ik wurd hjir faak oer frege. Nee, wy binne gjin bruorren.

"Elkenien wit" dat ClickHouse:

• Hiel fluch,
• Hiel handig,
• Wurdt brûkt yn Yandex.

It is wat minder bekend yn hokker bedriuwen en hoe't it brûkt wurdt.

Ik sil jo fertelle wêrom, wêr en hoe't ClickHouse wurdt brûkt, neist Yandex.

Ik sil jo fertelle hoe't spesifike problemen wurde oplost mei ClickHouse yn ferskate bedriuwen, hokker ClickHouse-ark kinne jo brûke foar jo taken, en hoe't se waarden brûkt yn ferskate bedriuwen.

Ik haw trije foarbylden selektearre dy't ClickHouse fan ferskate kanten sjen litte. Ik tink dat it ynteressant wêze sil.

De earste fraach is: "Wêrom hawwe wy ClickHouse nedich?" It liket derop dat de fraach frij dúdlik is, mar d'r binne mear as ien antwurden op.

• It earste antwurd is foar prestaasjes redenen. ClickHouse is heul rap. Analytics op ClickHouse is ek heul rap. It kin faak brûkt wurde dêr't wat oars wurket hiel stadich of hiel min.
• It twadde antwurd is kosten. En earst fan alle, de kosten fan skaalfergrutting. Bygelyks, Vertica is in absolút poerbêste databank. It wurket heul goed as jo net in protte terabytes oan gegevens hawwe. Mar as wy it hawwe oer hûnderten terabytes of petabytes, binne de kosten fan in lisinsje en stipe in frij signifikant bedrach. En it is djoer. En ClickHouse is fergees.
• It tredde antwurd is bedriuwskosten. Dit is in wat oare oanpak. RedShift is in geweldige analoog. Mei RedShift kinne jo heul fluch in beslút nimme. It sil goed wurkje, mar tagelyk sille jo elke oere, elke dei en elke moanne in soad betelje oan Amazon, om't it in signifikant djoere tsjinst is. Google BigQuery ek. As immen it brûkt hat, dan wit hy dat jo dêr ferskate fragen útfiere kinne en ynienen in faktuer krije foar hûnderten dollars.

ClickHouse hat dizze problemen net.

Wêr wurdt ClickHouse no brûkt? Neist Yandex wurdt ClickHouse brûkt yn in boskje ferskate bedriuwen en bedriuwen.

• Alderearst is dit webapplikaasje-analytyk, dat wol sizze dit is in gebrûksgefal dat kaam fan Yandex.
• In protte AdTech-bedriuwen brûke ClickHouse.
• Tal fan bedriuwen dy't operasjonele logs moatte analysearje út ferskate boarnen.
• Ferskate bedriuwen brûke ClickHouse om feiligenslogs te kontrolearjen. Se uploade se nei ClickHouse, meitsje rapporten, en krije de resultaten dy't se nedich binne.
• Bedriuwen begjinne it te brûken yn finansjele analyze, dus stadichoan komme grutte bedriuwen ek oan ClickHouse.
• CloudFlare. As immen ClickHouse folget, hawwe jo wierskynlik de namme fan dit bedriuw heard. Dit is ien fan 'e wichtige bydragen út 'e mienskip. En se hawwe in heul serieuze ClickHouse-ynstallaasje. Bygelyks makken se Kafka Engine foar ClickHouse.
• Telekommunikaasjebedriuwen binne begon te brûken. Ferskate bedriuwen brûke ClickHouse as bewiis op konsept of al yn produksje.
• Ien bedriuw brûkt ClickHouse om produksjeprosessen te kontrolearjen. Se testen mikrocircuits, skriuwe in protte parameters, d'r binne sa'n 2 skaaimerken. En dan analysearje se oft de batch goed of min is.
• Blockchain analytics. Der is in Russyske bedriuw neamd Bloxy.info. Dit is in analyze fan it Ethereum netwurk. Se diene dit ek op ClickHouse.

Boppedat makket de grutte net út. D'r binne in protte bedriuwen dy't ien lytse server brûke. En hy lit se har problemen oplosse. En noch mear bedriuwen brûke grutte klusters fan in protte servers as tsientallen servers.

En as jo nei de records sjogge, dan:

• Yandex: 500+ servers, se bewarje dêr 25 miljard records per dei.
• LifeStreet: 60 servers, sawat 75 miljard records per dei. D'r binne minder servers en mear records dan yn Yandex.
• CloudFlare: 36 servers, se bewarje 200 miljard records per dei. Se hawwe noch minder servers en bewarje noch mear gegevens.
• Bloomberg: 102 servers, sawat in triljoen records per dei. Rekordhâlder.

Geografysk is dit ek in protte. Dizze kaart toant de waarmtekaart fan wêr't ClickHouse wurdt brûkt yn 'e wrâld. Hjir steane Ruslân, Sina en Amearika dúdlik út. D'r binne in pear Europeeske lannen. En 4 klusters kinne wurde ûnderskieden.

Dit is in ferlykjende analyze, it is net nedich om te sykjen nei absolute nûmers. Dit is in analyze fan besikers dy't Ingelsktalige materialen lêze op 'e webside fan Altinity, om't d'r gjin Russysk sprekkers binne. En Ruslân, Oekraïne, Wyt-Ruslân, dus it Russysktalige diel fan 'e mienskip, binne de meast tal brûkers. Dan komme de FS en Kanada. Sina is tige ynhelle. D'r wie dêr seis moanne lyn hast gjin Sina; no hat Sina Jeropa al ynhelle en bliuwt groeie. Alde Jeropa leit ek net efter, en de lieder yn it brûken fan ClickHouse is, frjemd genôch, Frankryk.

Wêrom fertel ik dit alles? Om sjen te litten dat ClickHouse in standert oplossing wurdt foar grutte data-analyse en al op in protte plakken brûkt wurdt. As jo ​​​​it brûke, binne jo op 'e goeie trend. As jo ​​​​it noch net brûke, dan moatte jo net bang wêze dat jo allinich wurde litten en gjinien sil jo helpe, om't in protte dit al dogge.

Dit binne foarbylden fan wirklik gebrûk fan ClickHouse yn ferskate bedriuwen.

• It earste foarbyld is in advertinsjenetwurk: migraasje fan Vertica nei ClickHouse. En ik wit ferskate bedriuwen dy't binne oerstapt fan Vertica of binne yn it proses fan it wikseljen.
• It twadde foarbyld is transaksje opslach op ClickHouse. Dit is in foarbyld boud op antipatterns. Alles wat net hoecht te wurde dien yn ClickHouse neffens it advys fan 'e ûntwikkelders wurdt hjir dien. En tagelyk wurdt it sa effektyf dien dat it wurket. En it wurket folle better dan in typyske transaksjonele oplossing.
• It tredde foarbyld is ferspraat komputer op ClickHouse. D'r wie in fraach oer hoe't ClickHouse kin wurde yntegrearre yn it Hadoop-ekosysteem. Ik sil in foarbyld sjen litte fan hoe't in bedriuw wat dien hat gelyk oan in kaartferminderingskontener op ClickHouse, tafersjoch op gegevenslokalisaasje, ensfh., Om in heul net-triviale taak te berekkenjen.

• LifeStreet is in Ad Tech-bedriuw dat alle technologyen hat ferbûn mei in advertinsjenetwurk.
• Se is dwaande mei advertinsjeoptimalisaasje en programmatyske biedingen.
• In protte gegevens: sawat 10 miljard eveneminten per dei. Boppedat kinne der eveneminten wurde ferdield yn ferskate sub-eveneminten.
• D'r binne in protte kliïnten fan dizze gegevens, en dit binne net allinich minsken, folle mear binne ferskate algoritmen dy't har dwaande hâlde mei programmatyske biedingen.

It bedriuw hat in lange en steklike wei kommen. En ik praat der oer op HighLoad. Earst migrearre LifeStreet fan MySQL (mei in koarte stop by Oracle) nei Vertica. En dêr kinne jo in ferhaal oer fine.

En alles wie heul goed, mar it waard gau dúdlik dat de gegevens groeiden en Vertica djoer wie. Dêrom is socht nei ferskate alternativen. Guon fan harren wurde hjir neamd. En yn feite, wy diene bewiis fan konsept of soms prestaasjes testen fan hast alle databases dy't wiene beskikber op 'e merk fan 13 oan 16 en wiene likernôch geskikt yn funksjonaliteit. En ik praat ek oer guon fan harren op HighLoad.

De taak wie earst te migrearjen fan Vertica, om't de gegevens groeiden. En se groeiden eksponentiell foar ferskate jierren. Doe gongen se op 'e planke, mar dochs. En it foarsizzen fan dizze groei, saaklike easken foar it folume fan gegevens dêr't in soarte fan analytyk op dien wurde moat, wie dúdlik dat der al gau praat wurde soe fan petabytes. En it is al hiel djoer om te beteljen foar petabytes, dus wy sochten in alternatyf wêr't te gean.

Wêr te gean? En lange tiid wie it folslein ûndúdlik wêr't te gean, want oan de iene kant binne der kommersjele databanken, dy lykje te wurkjen goed. Guon wurkje hast like goed as Vertica, guon slimmer. Mar se binne allegear djoer, neat goedkeaper of better koe wurde fûn.

Oan 'e oare kant binne d'r iepen boarne-oplossings, wêrfan d'r net in protte binne, dus foar analytiken kinne se op ien hân teld wurde. En se binne fergees of goedkeap, mar se wurkje stadich. En se misse faaks needsaaklike en nuttige funksjonaliteit.

En d'r wie neat om de goede dingen te kombinearjen dy't yn kommersjele databases binne en alle fergese dingen dy't yn iepen boarne binne.

Der barde neat oant Yandex ynienen ClickHouse út in hoed luts as in konijn fan in tsjoender. En dit wie in ûnferwachte beslút, minsken stelle noch altyd de fraach: "Wêrom?", mar dochs.

En fuort yn 'e simmer fan 2016 begûnen wy te sjen nei wat ClickHouse is. En it die bliken dat it soms flugger kin as Vertica. Wy testen ferskate senario's op ferskate oanfragen. En as de query mar ien tabel brûkte, dus sûnder joins, dan wie ClickHouse twa kear sa fluch as Vertica.

Ik wie net te lui en seach de oare deis nei mear Yandex-tests. It is dêr itselde: ClickHouse is twa kear sa fluch as Vertica, dus se prate der faak oer.

Mar as de queries joins befetsje, dan blykt alles net heul dúdlik. En ClickHouse kin twa kear sa stadich wêze as Vertica. En as jo it fersyk in bytsje korrigearje en oerskriuwe, dan sille se sawat gelyk wêze. Net min. En it is fergees.

En nei it ûntfangen fan de testresultaten, en it besjen fan ferskate hoeken, gie LifeStreet nei ClickHouse.

Dit is it 16e jier, tink ik. It wie as de grap oer de mûzen dy't gûlen en harsels ynjeksje, mar de kaktus fierder iten. En dit waard yn detail besprutsen, d'r is in fideo oer dit, ensfh.

Dêrom sil ik hjir net yn detail oer prate, ik sil allinich prate oer de resultaten en in pear nijsgjirrige dingen wêr't ik doe net oer praat.

De resultaten binne:

• Súksesfolle migraasje en it systeem is mear as in jier yn produksje west.
• Produktiviteit en fleksibiliteit binne tanommen. Fan 'e 10 miljard records dy't wy ús kinne betelje om mar in koarte tiid per dei op te slaan, bewarret LifeStreet no 75 miljard records per dei en kin dat foar 3 moannen of mear dwaan. As jo ​​op it hichtepunt telle, dan wurdt dit opslein oant in miljoen eveneminten per sekonde. Mear dan in miljoen SQL-fragen per dei komme yn dit systeem, meast fan ferskate robots.
• Nettsjinsteande it feit dat ClickHouse mear tsjinners begon te brûken as Vertica, waarden ek besparrings makke op hardware, om't Vertica frij djoere SAS-skiven brûkte. ClickHouse brûkte SATA. En werom? Omdat yn Vertica ynfoegje is syngroane. En syngronisaasje fereasket dat de skiven net folle fertrage, en ek dat it netwurk net te folle fertraget, dus in frij djoere operaasje. En yn ClickHouse is ynfoegje asynchrone. Boppedat kinne jo altyd alles lokaal skriuwe, d'r binne gjin ekstra kosten foar dit, sadat gegevens folle flugger yn ClickHouse kinne wurde ynfoege as yn Vertika, sels op net de fluchste skiven. En it lêzen is sawat itselde. Lêzen op SATA, as se yn RAID binne, dan is it allegear fluch genôch.
• Unbeheind troch lisinsje, d.w.s. 3 petabytes oan gegevens yn 60 servers (20 servers binne ien replika) en 6 trillion records yn feiten en aggregaten. Vertica koe soks net betelje.

No kom ik ta de praktyske dingen yn dit foarbyld.

• De earste is in effektyf skema. In protte hinget ôf fan it skema.
• De twadde generearret effisjinte SQL.

In typyske OLAP-query wurdt selektearre. Guon kolommen geane nei groep troch, guon kolommen geane nei aggregate funksjes. Der is wêr, dat kin wurde tocht as in stik fan in kubus. De hiele groep troch kin sjoen wurde as in projeksje. En dêrom wurdt it multivariate gegevensanalyse neamd.

En faak wurdt dit modelearre yn 'e foarm fan in stjerdiagram, as d'r in sintraal feit en skaaimerken fan dit feit op' e kanten, lâns de strielen.

En út it eachpunt fan fysyk ûntwerp, hoe't it op 'e tafel past, meitsje se normaal in normalisearre foarstelling. Jo kinne denormalize, mar it is djoer op skiif en net hiel effisjint op queries. Dêrom meitsje se meastentiids in normalisearre werjefte, dus in feittabel en in protte, in protte diminsjetabellen.

Mar dit wurket net goed yn ClickHouse. D'r binne twa redenen:

• De earste is om't ClickHouse net heul goede joins hat, d.w.s. d'r binne joins, mar se binne min. Oant no ta binne se min.
• De twadde is dat de tabellen net bywurke wurde. Meastal yn dizze tekens dy't om it stjerdiagram binne, moat wat feroare wurde. Bygelyks klantnamme, bedriuwsnamme, ensfh. En it wurket net.

En d'r is in manier út dit yn ClickHouse. sels twa:

• De earste is it brûken fan wurdboeken. Eksterne wurdboeken is wat helpt 99% oplosse it probleem mei de stjer skema, mei updates ensafuorthinne.
• De twadde is it brûken fan arrays. Arrays helpe ek los te kommen fan joins en problemen mei normalisaasje.

• Gjin ferlet fan joins.
• Updateable. Sûnt maart 2018 is der in net-dokumintearre kâns ferskynde (jo fine dit net yn 'e dokumintaasje) om wurdboeken foar in part by te wurkjen, dus dy ynstjoerings dy't feroare binne. Yn 'e praktyk is it as in tafel.
• Altyd yn it ûnthâld, dus slút oan by in wurdboek wurk flugger as as it wie in tabel dy't leit op skiif en it is net in feit dat it is yn de cache, nei alle gedachten net.

• Jo hawwe ek gjin joins nedich.
• Dit is in kompakte 1 oant in protte foarstelling.
• En neffens my binne arrays makke foar geeks. Dit binne lambda-funksjes en sa.

Dit is net om 'e wille fan wurden. Dit is in heul krêftige funksjonaliteit wêrmei jo in protte dingen heul ienfâldich en elegant kinne dwaan.

Typyske foarbylden dy't helpe by it oplossen fan arrays. Dizze foarbylden binne ienfâldich en frij dúdlik:

• Sykje troch tags. As jo ​​​​dêr hashtags hawwe en wat berjochten wolle fine troch hashtag.
• Sykje op kaai-wearde-pearen. Der binne ek guon attributen mei betsjutting.
• Listen fan toetsen opslaan dy't jo moatte oersette yn wat oars.

Al dizze problemen kinne wurde oplost sûnder arrays. Tags kinne wurde pleatst yn guon rigel en selektearre mei help fan in reguliere útdrukking, of yn in aparte tabel, mar dan sille moatte meitsje joins.

Mar yn ClickHouse hoege jo neat te dwaan, beskriuwe gewoan in string-array foar hashtags of meitsje in nestele struktuer foar kaai-wearde-systemen.

In geneste struktuer is miskien net de bêste namme. Dit binne twa arrays dy't in mienskiplik diel hawwe yn 'e namme en guon relatearre skaaimerken.

En it is heul maklik om te sykjen op tag. Der is in funksje has, dy't kontrolearret dat de array in elemint befettet. Elkenien, wy fûnen alle ynstjoerings dy't relatearje oan ús konferinsje.

Sykje op subid is in bytsje yngewikkelder. Wy moatte earst de yndeks fan 'e kaai fine, en nim dan it elemint mei dizze yndeks en kontrolearje dat dizze wearde is wat wy nedich binne. Mar dochs hiel ienfâldich en kompakt.

De reguliere útdrukking dy't jo skriuwe wolle, as jo it allegear yn ien rigel opslein hawwe, soe it foarearst ûnhandich wêze. En, twadde, wurke it folle langer dan twa arrays.

In oar foarbyld. Jo hawwe in array wêryn jo ID's opslaan. En jo kinne se oersette yn nammen. Funksje arrayMap. Dit is in typyske lambdafunksje. Jo passe dêr lambda-útdrukkingen troch. En se hellet de nammewearde foar elke ID út it wurdboek.

Jo kinne op deselde wize sykje. In predikaatfunksje wurdt trochjûn, dy't kontrolearret wat de eleminten oerienkomme.

Dizze dingen ferienfâldigje it circuit sterk en lossen in protte problemen op.

Mar it folgjende probleem dat wy tsjinkamen en dat ik wol neame wol, is effisjinte fragen.

• ClickHouse hat gjin queryplanner. Absolút net.
• Mar dochs moatte komplekse fragen noch pland wurde. Yn hokker gefallen?
• As it fersyk hat ferskate joins, dy't jo wrap yn subselects. En de folchoarder wêryn't se útfierd wurde, is wichtich.
• En twad, as it fersyk wurdt ferdield. Want yn in ferspraat query wurdt allinnich de binnenste subselect útfierd op in ferspraat wize, en al it oare wurdt stjoerd nei de iene tsjinner jo ferbûn oan en útfierd dêr. Dêrom, as jo fragen hawwe ferspraat mei in protte joins, dan moatte jo in bestelling kieze.

En sels yn ienfâldiger gefallen moatte jo soms ek it wurk fan 'e planner dwaan en de queries in bytsje oerskriuwe.

Hjir is in foarbyld. Oan de linkerkant is in fraach dy't de top 5 lannen toant. En it rint yn 2,5 sekonden, tink ik. En oan de rjochterkant is itselde fersyk, mar in bytsje oerskreaun. Yn stee fan groepearjen troch tekenrige, begûnen wy groepearje troch kaai (int). En it is flugger. En dan hawwe wy in wurdboek ferbûn oan it resultaat. Yn stee fan 2,5 sekonden duorret it fersyk 1,5 sekonden. Dit is goed.

In ferlykber foarbyld mei filters foar herskriuwen. Hjir is in fersyk foar Ruslân. It rint foar 5 sekonden. As wy it opnij skriuwe op sa'n manier dat wy wer net in tekenrige fergelykje, mar nûmers mei in set fan dy toetsen dy't relatearje oan Ruslân, dan sil it folle flugger wêze.

Der binne in protte sokke trúkjes. En se kinne jo fragen signifikant fersnelle dy't jo tinke dat se al hurd rinne, of oarsom, stadich rinne. Se kinne wurde makke noch flugger.

• Maksimum wurk yn ferdield modus.
• Sortearje op minimale soarten, lykas ik dien troch ints.
• As der joins of wurdboeken binne, dan is it better om se as lêste te dwaan, as jo de gegevens al op syn minst foar in part groepeare hawwe, dan sil de join-operaasje of it oproppen fan it wurdboek minder kearen wurde neamd en it sil flugger wêze.
• It ferfangen fan filters.

D'r binne oare techniken, net allinich dejingen dy't ik demonstrearre. En allegear kinne jo soms de útfiering fan fragen signifikant fersnelle.

Litte wy nei it folgjende foarbyld gean. Company X út 'e Feriene Steaten. Wat docht sy?

Der wie in taak:

• Offline keppeljen fan advertinsjetransaksjes.
• Simulaasje fan ferskate binende modellen.

Wat is it senario?

In gewoane besiker besiket de side, bygelyks, 20 kear yn 'e moanne fan ferskate advertinsjes, of soms komt hy gewoan sûnder advertinsjes, om't hy dizze side ûnthâldt. Sjocht nei guon produkten, set se yn 'e koer, nimt se út' e koer. En op it lêst keapet er wat.

Redelijke fragen: "Wa moat betelje foar reklame, as it nedich is?" en "Hokker reklame, as ien, hat him beynfloede?" Dat is, wêrom kocht hy en hoe't jo derfoar soargje dat minsken lykas dizze persoan ek keapje?

Om dit probleem op te lossen, moatte jo de eveneminten dy't op 'e webside foarkomme op' e juste manier ferbine, dat is, op ien of oare manier in ferbining meitsje tusken har. Dan wurde se foar analyse oerbrocht nei DWH. En op basis fan dizze analyse, bouwe modellen fan wa't sjen litte hokker reklame.

In advertinsjetransaksje is in set fan relatearre brûkerseveneminten dy't begjinne mei in advertinsje dy't werjûn wurdt, dan bart der wat, dan miskien in oankeap, en dan kinne der oankeapen wêze binnen in oankeap. As dit bygelyks in mobile applikaasje of in mobyl spultsje is, dan is it ynstallearjen fan de applikaasje normaal fergees, mar as der wat oars wurdt dien, dan kin it jild nedich wêze. En hoe mear in persoan besteget yn 'e app, hoe weardefoller it is. Mar hjirfoar moatte jo alles ferbine.

D'r binne in protte binende modellen.

De populêrste binne:

• Lêste ynteraksje, wêrby't ynteraksje of in klik of in yndruk is.
• Earste ynteraksje, dus it earste ding dat in persoan nei de side brocht.
• Lineêre kombinaasje - gelikense oandiel foar elkenien.
• Attenuation.
• Ensafuorthinne.

En hoe wurke it allegear ynearsten? Der wie Runtime en Cassandra. Cassandra waard brûkt as transaksje opslach, dat wol sizze alle relatearre transaksjes waarden opslein yn it. En as guon barren yn Runtime bart, bygelyks it werjaan fan in side of wat oars, wurdt in fersyk dien oan Cassandra oft der sa'n persoan is of net. Doe waarden de transaksjes ûntfongen dy't dêrmei relatearje. En de bining wie dien.

En as jo gelok hawwe dat it fersyk in transaksje-id befettet, dan is dit maklik. Mar meastal hawwe jo gjin gelok. Dêrom wie it nedich om de lêste transaksje te finen as de transaksje mei de lêste klik, ensfh.

En it wurke allegear heul goed oant de keppeling nei de lêste klik wie. Want d'r binne bygelyks 10 miljoen klikken per dei, 300 miljoen per moanne, as jo in finster foar in moanne ynstelle. En om't yn Cassandra it allegear yn it ûnthâld moat wêze om fluch te wurkjen, om't de Runtime fereaske is om fluch te reagearjen, wiene sawat 10-15 servers nedich.

En doe't se in transaksje keppele woene oan it display, waard it fuortendaliks net sa leuk. En werom? It is te sjen dat der 30 kear mear eveneminten opslein wurde moatte. En dêrom hawwe jo 30 kear mear servers nedich. En it docht bliken dat dit in soarte fan astronomyske figuer is. Hâld oant 500 servers om te keppeljen, nettsjinsteande it feit dat d'r signifikant minder servers binne yn Runtime, is in soarte fan ferkearde figuer. En se begûnen te tinken oer wat te dwaan.

En wy gongen nei ClickHouse. Hoe dit te dwaan op ClickHouse? Op it earste each liket it derop dat dit in set fan antipatterns is.

• De transaksje groeit, wy hechtsje mear en mear eveneminten oan it, dat wol sizze it is mutable, en ClickHouse wurket net hiel goed mei mutable objekten.
• As in besiker by ús komt, moatte wy syn transaksjes ophelje troch kaai, troch syn besite-id. Dit is ek in puntfraach; ClickHouse docht dat net. Gewoanlik hat ClickHouse grutte ... scans, mar hjir moatte wy ferskate records krije. Ek in antipattern.
• Dêrnjonken wie de transaksje yn json, mar se woenen it net oerskriuwe, dat se woenen de json ûnstrukturearre opslaan, en as it nedich wie, der wat út lûke. En dit is ek in antipattern.

Dat is, in set fan antipatterns.

Mar nettsjinsteande is it ús slagge om in systeem te meitsjen dat heul goed wurke.

Wat waard dien? ClickHouse ferskynde, wêryn logs, ferdield yn records, waarden smiten. In taskreaun tsjinst ferskynde dy't logs ûntfongen fan ClickHouse. Dêrnei krige ik foar elke yngong per besite-id transaksjes dy't noch net ferwurke koenen en plus snapshots, dus transaksjes dy't al ferbûn binne, nammentlik it resultaat fan earder wurk. Ik haw al logika fan har makke, de juste transaksje selektearre en nije eveneminten ferbûn. It wer oanmeld. It log gie werom nei ClickHouse, d.w.s. it is in konstant syklik systeem. En boppedat gie ik nei DWH om it dêr te analysearjen.

It wurke net sa goed yn dizze foarm. En om it makliker te meitsjen foar ClickHouse, doe't d'r in fersyk wie foar in besite-id, groepeare se dizze oanfragen yn blokken fan 1-000 besite-ID's en lutsen alle transaksjes foar 2-000 minsken út. En doe wurke it allegear.

As jo ​​binnen ClickHouse sjogge, binne d'r mar 3 haadtafels dy't dit alles tsjinje.

De earste tabel wêryn logs wurde opladen, en de logs wurde opladen mei praktysk gjin ferwurking.

Twadde tafel. Troch de materialisearre werjefte waarden eveneminten dy't noch net taskreaun binne, dus net relatearre, út dizze logs helle. En troch de materialisearre werjefte waarden transaksjes út dizze logs helle om in momintopname te bouwen. Dat is, in momintopname waard makke mei in spesjale materialisearre werjefte, nammentlik de lêste accumulearre steat fan 'e transaksje.

Hjir is de tekst skreaun yn SQL. Ik wol dêryn kommentaar jaan op ferskate wichtige saken.

It earste wichtige ding is de mooglikheid yn ClickHouse om kolommen en fjilden út json te ekstrahearjen. Dat is, ClickHouse hat wat metoaden foar wurkjen mei json. Se binne heul, heul primityf.

visitParamExtractInt lit jo attributen út json ekstrahearje, d.w.s. de earste hit wurdt trigger. En op dizze manier kinne jo de transaksje-id útlûke of id besykje. Dizze kear.

As twadde wurdt hjir in lestich materialisearre fjild brûkt. Wat betsjut dat? Dit betsjut dat jo it net kinne ynfoegje yn 'e tabel, d.w.s. it is net ynfoege, it wurdt berekkene en bewarre as it ynfoege is. As jo ​​​​ynfoegje, docht ClickHouse it wurk foar jo. En wat jo letter nedich binne, wurdt út json helle.

Yn dit gefal is materialisearre werjefte foar rauwe snaren. En de earste tafel mei hast rûge logs wurdt brûkt. En wat docht it? As earste feroaret it de sortearring, d.w.s. it sortearjen wurdt no dien troch besite-id, om't wy syn transaksje spesifyk foar in spesifike persoan fluch moatte útlûke.

It twadde wichtige ding is index_granularity. As jo ​​MergeTree sjoen hawwe, dan is normaal de standertwearde 8 index_granularity. Wat is it? Dit is de yndeks sparsity parameter. Yn ClickHouse is de yndeks sparse; it yndeksearret noait elke record. It docht dit elke 192 8. En dit is goed as jo in protte gegevens moatte berekkenje, mar it is min as jo in bytsje berekkenje moatte, om't der in protte overhead is. En as wy de yndeksgranulariteit ferminderje, dan ferminderje wy de overhead. Jo kinne it net ferminderje ta ien, om't d'r miskien net genôch ûnthâld is. De yndeks wurdt altyd opslein yn it ûnthâld.

En de momintopname brûkt wat oare nijsgjirrige ClickHouse-funksjes.

Earst is AggregatingMergeTree. En AggregatingMergeTree bewarret argMax, d.w.s. dit is de transaksjestatus dy't oerienkomt mei de lêste tiidstempel. Nije transaksjes wurde altyd oanmakke foar dizze besiker. En yn 'e alderlêste steat fan dizze transaksje hawwe wy in evenemint tafoege en wy hienen in nije steat. It rekke ClickHouse wer. En fia argMax yn dizze materialisearre werjefte kinne wy ​​altyd de hjoeddeistige steat krije.

• Bining is "ûntbûn" fan Runtime.
• Oant 3 miljard transaksjes per moanne wurde opslein en ferwurke. Dit is in folchoarder fan grutte grutter as yn Cassandra, dus yn in typysk transaksjesysteem.
• Kluster fan 2x5 ClickHouse-tsjinners. 5 tsjinners en elke tsjinner hat in replika. Dit is noch minder dan it wie yn Cassandra om klikbasearre attribúsje te dwaan, mar hjir hawwe wy yndruk basearre. Dat is, ynstee fan it oantal tsjinners mei 30 kear te ferheegjen, waarden se fermindere.

En it lêste foarbyld is finansjeel bedriuw Y, dy't de korrelaasjes fan feroaringen yn oandielprizen analysearre.

En de taak wie dit:

• D'r binne sawat 5 oandielen.
• Quotes elke 100 millisekonden binne bekend.
• De gegevens hawwe sammele oer 10 jier. Blykber is it foar guon bedriuwen mear, foar guon is it minder.
• D'r binne yn totaal sawat 100 miljard rigen.

En it wie nedich om de korrelaasje fan feroaringen te berekkenjen.

Hjir binne twa oandielen en har quotes. As de iene omheech giet en de oare omheech, dan is dit in positive korrelaasje, d.w.s. de iene giet omheech en de oare giet omheech. As ien omheech giet, lykas oan 'e ein fan' e grafyk, en de oare giet omleech, dan is dit in negative korrelaasje, dus as de iene omheech giet, giet de oare omleech.

Troch dizze ûnderlinge feroaringen te analysearjen, kin men foarsizzingen meitsje op 'e finansjele merk.

Mar de taak is dreech. Wat wurdt hjirfoar dien? Wy hawwe 100 miljard records dy't befetsje: tiid, stock en priis. Wy moatte earst 100 miljard kear it rinnende Ferskil fan it priisalgoritme berekkenje. RunningDifference is in funksje yn ClickHouse dy't sequentially berekkent it ferskil tusken twa rigels.

En dêrnei moatte wy de korrelaasje berekkenje, en de korrelaasje moat foar elk pear berekkene wurde. Foar 5 oandielen binne de pearen 000 miljoen. En dit is in protte, dus 12,5 kear moatte jo dizze korrelaasjefunksje berekkenje.

En as immen it fergeat, ͞x en ͞y binne skaakmat. sample ferwachting. Dat is, jo moatte net allinich de woartels en sommen berekkenje, mar ek oare sommen binnen dizze sommen. In protte berekkeningen moatte wurde dien 12,5 miljoen kear, en se moatte ek wurde groepearre troch oere. En wy hawwe ek in protte oeren. En jo moatte it dwaan yn 60 sekonden. It is in grapke.

Wy moasten it op ien of oare manier meitsje, om't it allegear heul, heul stadich wurke foardat ClickHouse oankaam.

Dat besochten se te berekkenjen op Hadoop, op Spark, op Greenplum. En dit alles wie tige stadich of djoer. Dat is, it wie mooglik om ien of oare manier te berekkenjen, mar doe wie it djoer.

En doe kaam ClickHouse en waard alles folle better.

Lit my jo herinnerje dat wy in probleem hawwe mei gegevenslokaasje, dus korrelaasjes kinne net pleatst wurde. Wy kinne gjin gegevens tafoegje oan ien server, guon oan in oare en berekkenje; wy moatte alle gegevens oeral hawwe.

Wat hawwe se dien? Yn it earstoan wurde de gegevens lokalisearre. Elke tsjinner bewarret priisgegevens foar in spesifike set fan oandielen. En se snije net. Dêrom is it mooglik om logReturn parallel en ûnôfhinklik te berekkenjen; dit alles bart parallel en ferspraat.

Doe besleaten wy dizze gegevens te ferminderjen sûnder ekspressiviteit te ferliezen. Ferminderje mei arrays, dus meitsje foar elke perioade in array fan oandielen en in array fan prizen. Sa nimt it folle minder gegevensromte yn. En se binne wat handiger om mei te wurkjen. Dit binne hast parallelle operaasjes, dus wy telle foar in part parallel en skriuwe dan nei de tsjinner.

Dit kin dan werhelle wurde. De letter "r" betsjut dat wy dizze gegevens replikearre. Dat is, wy hawwe deselde gegevens op alle trije servers - dit binne de arrays.

En dan, mei in spesjaal skript, kinne jo pakketten meitsje fan dizze set fan 12,5 miljoen korrelaasjes dy't moatte wurde berekkene. Dat is, 2 taken mei 500 pear korrelaasjes. En dizze taak moat wurde berekkene op in spesifike ClickHouse-tsjinner. Hy hat alle gegevens, om't de gegevens itselde binne en hy kin se opfolgjend berekkenje.

Hjir is hoe't it der wer útsjocht. Earst hawwe wy alle gegevens yn 'e folgjende struktuer: tiid, oandielen, priis. Dan wy berekkene logReturn, dus gegevens fan deselde struktuer, allinne ynstee fan priis wy hawwe logReturn. Doe waarden se opnij makke, d.w.s. wy krigen tiid en groepArray troch promoasjes en priislisten. Replikearre. En dêrnei generearren se in boskje taken en fiede se nei ClickHouse, sadat it se koe telle. En it wurket.

By de proof of concept wie de taak in subtaak, dat wol sizze dat se minder gegevens namen. En allinich op trije servers.

Dizze earste twa stadia: it berekkenjen fan Log_return en it ynpakke yn arrays namen elk sawat in oere.

En it berekkenjen fan de korrelaasje duorret sawat 50 oeren. Mar 50 oeren is net genôch, want earder wurke it wiken foar harren. It wie in grut súkses. En as jo rekkenje, dan waard alles 70 kear per sekonde teld op dit kluster.

Mar it wichtichste is dat dit systeem praktysk gjin knelpunten hat, d.w.s. it skaalet hast lineêr. En se kontrolearren it. It waard mei súkses skalearre.

• It goede skema is de helte fan it sukses. En it juste skema is om alle nedige ClickHouse-technologyen te brûken.
• Summing / AggregatingMergeTrees binne technologyen wêrmei jo in steat momintopname te aggregearjen of telle as in spesjaal gefal. En dit makket gâns simplifies in protte dingen.
• Materialisearre werjeften kinne jo om de ien-yndeks beheining omgean. Miskien haw ik dit net sa dúdlik sein, mar doe't wy de logs laden, wiene de rauwe logs yn in tabel mei ien yndeks, en op attribút wiene de logs yn 'e tabel, dus deselde gegevens, allinich filtere, mar de yndeks wie folslein oan oaren. It liket te wêzen deselde gegevens, mar ferskillende sortearring. En Materialized Views kinne jo, as jo it nedich binne, dizze ClickHouse-beheining omgean.
• Ferminderje yndeksgranulariteit foar puntfragen.
• En fersprieden gegevens tûk, besykje de gegevens safolle mooglik binnen de tsjinner te lokalisearjen. En besykje derfoar te soargjen dat fersiken ek safolle mooglik lokalisaasje brûke.

En om dizze koarte taspraak te gearfetten, kinne wy ​​​​sizze dat ClickHouse no it grûngebiet fan sawol kommersjele databases as iepen boarne databases stevich beset hat, dus spesifyk foar analytics. Hy past perfekt yn dit lânskip. En wat mear is, it begjint stadichoan oaren te ferfangen, want as ClickHouse d'r is, hawwe jo InfiniDB net nedich. Fertikaal kin gau net nedich wêze as se normale SQL-stipe leverje. Brûk it!

-Tank foar it ferslach! Tige nijsgjirrich! Binne d'r fergelikingen west mei Apache Phoenix?

-Nee, ik haw gjinien fergelike heard. Wy en Yandex besykje alle fergelikingen fan ClickHouse mei ferskate databases by te hâlden. Want as der ynienen wat flugger blykt te wêzen as ClickHouse, dan kin Lesha Milovidov nachts net sliepe en begjint it fluch te rapperjen. Ik haw noch net heard fan sa'n ferliking.

• (Alexey Milovidov) Apache Phoenix is ​​​​in SQL-motor basearre op Hbase. Hbase is benammen ûntworpen foar wurksenario fan kaai-wearde-type. Dêr kin elke rigel in willekeurich oantal kolommen hawwe mei willekeurige nammen. Dit kin sein wurde oer systemen lykas Hbase en Cassandra. En it binne krekt swiere analytyske fragen dy't net normaal foar har sille wurkje. Of jo tinke miskien dat se goed wurkje as jo gjin ûnderfining hawwe mei ClickHouse.

• Спасибо

  • Goeiemiddei Ik bin al aardich ynteressearre yn dit ûnderwerp, om't ik in analytysk subsysteem haw. Mar as ik nei ClickHouse sjoch, krij ik it gefoel dat ClickHouse tige geskikt is foar evenemintenanalyse, mutable. En as ik in protte saaklike gegevens analysearje moat mei in bosk grutte tabellen, dan is ClickHouse, sa fier as ik begryp, net heul geskikt foar my? Benammen as se feroarje. Is dit korrekt of binne d'r foarbylden dy't dit kinne wjerlizze?

  • Dit is rjocht. En dit is wier oer de measte spesjalisearre analytyske databases. Se binne ôfstimd op it feit dat der ien of meardere grutte tabellen dy't mutable, en in protte lytse dy't feroarje stadich. Dat is, ClickHouse is net lykas Oracle, wêr't jo alles kinne pleatse en wat heul komplekse fragen bouwe. Om ClickHouse effektyf te brûken, moatte jo it skema bouwe op in manier dy't goed wurket yn ClickHouse. Dat is, oermjittige normalisaasje foarkomme, wurdboeken brûke, besykje minder lange ferbiningen te meitsjen. En as it skema op dizze manier boud is, dan kinne ferlykbere saaklike problemen op ClickHouse folle effisjinter oplost wurde as op in tradisjonele relaasjedatabase.

Tank foar it ferslach! Ik haw in fraach oer de lêste finansjele saak. Se hiene analytics. It wie nedich om te fergelykjen hoe't se op en del geane. En ik begryp dat jo it systeem spesifyk boud hawwe foar dizze analytyk? As moarn, litte wy sizze, se moatte wat oar rapport oer dizze gegevens, moatte se bouwe it diagram wer en lade de gegevens? Dat is, in soarte fan foarferwurking dwaan om it fersyk te ûntfangen?

Fansels brûkt dit ClickHouse foar in heul spesifike taak. It soe tradisjoneeler binnen Hadoop oplost wurde kinne. Foar Hadoop is dit in ideale taak. Mar op Hadoop is it heul stadich. En myn doel is om te bewizen dat ClickHouse problemen kin oplosse dy't normaal troch folslein oare middels oplost wurde, mar tagelyk folle effisjinter dwaan. Dit is ôfstimd foar in spesifike taak. It is dúdlik dat as der in probleem is dat wat ferlykber is, dan kin it op deselde wize oplost wurde.

It is dúdlik. Jo seine dat it 50 oeren duorre om te ferwurkjen. Begjint it fan it begjin ôf, as jo de gegevens hawwe laden of de resultaten krigen?

Ja Ja.

OK tige tank.

Dit is op in 3 tsjinner kluster.

Groetnis! Tank foar it ferslach! Alles is tige nijsgjirrich. Ik freegje net in bytsje oer funksjonaliteit, mar oer it brûken fan ClickHouse út it eachpunt fan stabiliteit. Dat is, hawwe jo problemen en moatte jo se weromsette? Hoe gedraacht ClickHouse? En is it oait bard dat jo replika ek ferûngelokke is? Bygelyks, wy tsjinkaam in probleem mei ClickHouse doe't it noch gie boppe syn limyt en foel.

Fansels binne d'r gjin ideale systemen. En ClickHouse hat ek syn problemen. Mar hawwe jo heard oer Yandex.Metrica net wurkje foar in lange tiid? Wierskynlik net. It wurket betrouber sûnt sawat 2012-2013 op ClickHouse. Ik kin itselde sizze oer myn ûnderfining. Wy hawwe nea hie folsleine mislearrings. Guon parten kinne barre, mar se wiene nea kritysk genôch om serieus ynfloed op it bedriuw. Dit is noch noait earder bard. ClickHouse is frij betrouber en crasht net willekeurich. Jo hoege jo der gjin soargen oer te meitsjen. It is gjin rau ding. Dit is bewiisd troch in protte bedriuwen.

Hallo! Jo seine dat jo moatte fuortendaliks tinke goed oer de gegevens skema. Wat as dit barde? Myn gegevens streamt yn en út. Seis moannen passe, en ik begryp dat ik net sa libje kin, ik moat de gegevens opnij uploade en der wat mei dwaan.

Dit hinget fansels ôf fan jo systeem. D'r binne ferskate manieren om dit hast non-stop te dwaan. Jo kinne bygelyks in Materialized View oanmeitsje wêryn jo in oare gegevensstruktuer kinne oanmeitsje as it unyk yn kaart brocht wurde kin. Dat is, as it mapping mooglik makket mei ClickHouse, d.w.s. guon dingen ekstrahearje, de primêre kaai feroarje, partitionearring feroarje, dan kinne jo in Materialized View meitsje. Dêr wurde jo âlde gegevens opnij skreaun, nije wurde automatysk skreaun. En dan gewoan oerskeakelje nei it brûken fan Materialized View, wikselje dan it rekord en deadzje de âlde tabel. Dit is in algemien non-stop manier.

Спасибо.

Boarne: www.habr.com