Teorî û pratîka karanîna ClickHouse di serîlêdanên rastîn de. Alexander Zaitsev (2018)

Tevî vê rastiyê ku naha hema hema li her deverê gelek dane hene, databasên analîtîk hîn jî pir biyanî ne. Ew kêm têne zanîn û hîn xirabtir dikarin wan bi bandor bikar bînin. Pir kes bi MySQL an PostgreSQL, ku ji bo senaryoyên din hatine sêwirandin, bi NoSQL re êşê dikişînin, an jî ji bo çareseriyên bazirganî zêde didin "kaktusê" didomînin. ClickHouse qaîdeyên lîstikê diguhezîne û sînorê ketina cîhana DBMS-ya analîtîk bi girîngî kêm dike.

Rapor ji BackEnd Conf 2018 û ew bi destûra axaftvan tê weşandin.

Ez kî me û çima ez qala ClickHouse dikim? Ez derhênerek pêşkeftinê me li LifeStreet, ku ClickHouse bikar tîne. Di heman demê de, ez damezrînerê Altinity me. Ew hevkarek Yandex e ku ClickHouse pêşve dike û ji Yandex re dibe alîkar ku ClickHouse serfiraztir bike. Di heman demê de amade ne ku zanyariyan di derbarê ClickHouse de parve bikin.

Û ez ne birayê Petya Zaitsev im. Pir caran li ser vê yekê ji min tê pirsîn. Na, em ne bira ne.

"Her kes dizane" ku ClickHouse:

• Pir zû,
• Pir rehet
• Di Yandex de tê bikaranîn.

Piçek kêmtir tê zanîn ku di kîjan pargîdaniyan de û çawa tê bikar anîn.

Ez ê ji we re bibêjim çima, li ku û çawa ClickHouse tê bikar anîn, ji bilî Yandex.

Ez ê ji we re vebêjim ka bi alîkariya ClickHouse di pargîdaniyên cihêreng de peywirên taybetî çawa têne çareser kirin, hûn dikarin çi amûrên ClickHouse ji bo karên xwe bikar bînin, û ew çawa di pargîdaniyên cihêreng de hatine bikar anîn.

Min sê mînakên ku ClickHouse ji aliyên cihêreng nîşan didin hildan. Ez difikirim ku ew ê balkêş be.

Pirsa yekem ev e: "Çima em hewce ne ClickHouse?". Wusa dixuye ku ew pirsek pir zelal e, lê ji yekê zêdetir bersiv jê re hene.

• Bersiva yekem ji bo performansê ye. ClickHouse pir zû ye. Analytics li ser ClickHouse jî pir zû ye. Ew pir caran dikare li cîhê ku tiştek din pir hêdî an pir xirab e were bikar anîn.
• Bersiva duyemîn lêçûn e. Û berî her tiştî, lêçûna pîvanê. Mînakî, Vertica databasek bêkêmasî ye. Ger gelek terabytes daneya we tune be ew pir baş dixebite. Lê gava ku dor tê bi sedan terabytes an petabytes, lêçûna destûrnameyek û piştgirîyê digihîje hejmareke pir girîng. Û biha ye. Û ClickHouse belaş e.
• Bersiva sêyemîn lêçûna xebitandinê ye. Ev nêzîkatiyek hinekî cuda ye. RedShift analogek mezin e. Li ser RedShift, hûn dikarin pir zû biryarek bidin. Ew ê baş bixebite, lê di heman demê de, her demjimêr, her roj û her meh, hûn ê pir giran bidin Amazon-ê, ji ber ku ev karûbarek pir biha ye. Google BigQuery jî. Ger kesek wê bikar aniye, wê hingê ew dizane ku li wir hûn dikarin çend daxwazan bişopînin û ji nişka ve fatûreyek bi sedan dolaran bistînin.

ClickHouse van pirsgirêkan tune.

ClickHouse niha li ku tê bikar anîn? Ji bilî Yandex, ClickHouse di komek karsaz û pargîdaniyên cihêreng de tê bikar anîn.

• Berî her tiştî, ev analîtîka serîlêdana malperê ye, ango ev dozek karanîna ku ji Yandex hatî ye.
• Gelek pargîdaniyên AdTech ClickHouse bikar tînin.
• Gelek pargîdaniyên ku hewce ne ku têketinên danûstendinê ji çavkaniyên cihêreng analîz bikin.
• Gelek pargîdan ClickHouse bikar tînin da ku têketinên ewlehiyê bişopînin. Ew wan li ClickHouse bar dikin, raporan çêdikin, û encamên ku ew hewce ne digirin.
• Pargîdan dest bi karanîna wê di analîzên darayî de dikin, ango hêdî hêdî karsaziyên mezin jî nêzî ClickHouse dibin.
• cloudflare. Ger kesek ClickHouse bişopîne, wê hingê dibe ku wan navê vê pargîdaniyê bihîstibe. Ev yek ji beşdarên bingehîn ên civakê ye. Û wan sazûmanek ClickHouse ya pir cidî heye. Mînakî, wan Kafka Engine ji bo ClickHouse çêkir.
• Pargîdaniyên Telekomunîkasyonê dest bi kar kirin. Gelek pargîdan ClickHouse-ê wekî delîl li ser têgînê an jî jixwe di hilberînê de bikar tînin.
• Pargîdanek ClickHouse bikar tîne da ku pêvajoyên hilberînê bişopîne. Ew mîkrocircuitan ceribandin, komek pîvanan dinivîsin, bi qasî 2 taybetmendî hene. Û paşê ew analîz dikin ka lîstik baş e an xirab e.
• Analîtîkên Blockchain. Pargîdaniyek rûsî wekî Bloxy.info heye. Ev analîzek tora ethereum e. Wan jî ev yek li ser ClickHouse kir.

Û mezinahî ne girîng e. Gelek pargîdan hene ku serverek piçûk bikar tînin. Û ew destûrê dide wan ku pirsgirêkên xwe çareser bikin. Û hêj bêtir pargîdan komên mezin ên gelek serveran an bi dehan serveran bikar tînin.

Û heger hûn li qeydan binêrin, wê hingê:

• Yandex: Zêdetirî 500 server, ew rojane 25 mîlyar tomar li wir hilînin.
• LifeStreet: 60 server, rojane 75 mîlyar tomar. Ji Yandex-ê kêmtir server, bêtir tomar hene.
• CloudFlare: 36 server, ew rojê 200 mîlyar tomar tomar dikin. Ew hê kêmtir server hene û hêj bêtir daneyan hilînin.
• Bloomberg: 102 pêşkêşker, rojane nêzîkî trîlyonek navnîşan. Xwediyê qeydê.

Ji aliyê erdnîgarî ve jî ev yek pir e. Ev nexşeya li vir nexşeyek germê ya ku ClickHouse li cîhanê tê bikar anîn nîşan dide. Rûsya, Çîn, Amerîka li vir bi zelalî radiwestin. Welatên Ewropayê hindik in. Û 4 kom hene.

Ev analîzek berawirdî ye, ne hewce ye ku li hejmarên mutleq bigerin. Ev analîzek mêvanên ku li ser malpera Altinity materyalên bi zimanê îngilîzî dixwînin e, ji ber ku li wir yên rûsî-axêv tune. Û Rûsya, Ukrayna, Belarûs, ango beşa civakê ya rûsîaxêv, ev bikarhênerên herî pir in. Paşê jî DYA û Kanada tê. Çîn pir li ber xwe dide. Berî şeş mehan hema hema li wir Çîn tune bû, niha Çîn berê xwe daye Ewropayê û mezin dibe. Ewropaya Kevin jî ne dûr e, û serokê di karanîna ClickHouse de, ecêb, Fransa ye.

Çima ez van hemûyan dibêjim? Ji bo ku nîşan bide ku ClickHouse ji bo analîzkirina daneyên mezin dibe çareseriyek standard û berê li gelek deveran tê bikar anîn. Ger hûn wê bikar bînin, hûn di meyla rast de ne. Ger hûn hîna wê bikar neynin, wê hingê hûn nekarin bitirsin ku hûn ê bi tenê bimînin û kes dê alîkariya we neke, ji ber ku gelek berê vê yekê dikin.

Vana mînakên karanîna rastîn a ClickHouse di gelek pargîdaniyan de ne.

• Mînaka yekem torgilokek reklamê ye: koçî ji Vertica berbi ClickHouse. Û ez çend pargîdaniyên ku ji Vertica veguherî an jî di pêvajoya veguherînê de nas dikim.
• Mînaka duyemîn hilanîna danûstendinê ya li ser ClickHouse ye. Ev mînakek e ku li ser antipatternan hatî çêkirin. Her tiştê ku divê li ClickHouse li ser şîreta pêşdebiran neyê kirin li vir tê kirin. Û ew qas bi bandor hatî çêkirin ku ew dixebite. Û ew ji çareseriya danûstendinê ya tîpîk pir çêtir dixebite.
• Mînaka sêyem li ser ClickHouse hesabkirina belavkirî ye. Pirsek hebû ka ClickHouse çawa dikare di ekosîstema Hadoop de were yek kirin. Ez ê mînakek nîşan bidim ka pargîdaniyek çawa tiştek mîna konteynerek kêmkirina nexşeyê li ser ClickHouse kir, şopandina herêmîbûna daneyê, hwd., da ku karekî pir ne-pîvan hesab bike.

• LifeStreet pargîdaniyek Ad Tech-ê ye ku hemî teknolojiya ku bi tora reklamê re tê de heye.
• Ew bi optimîzasyona reklamê, îtirazkirina bernameyê ve mijûl e.
• Gelek dane: rojane nêzîkî 10 mîlyar bûyer. Di heman demê de, bûyerên li wir dikarin di çend bûyeran de bêne dabeş kirin.
• Gelek xerîdarên vê daneyê hene, û ev ne tenê mirov in, pir zêde jî - ev algorîtmayên cihêreng in ku di pêşnumaya bernamesaziyê de mijûl dibin.

Şirket rêyek dûr û dirêj hat. Û min li ser HighLoad behsa wê kir. Pêşîn, LifeStreet ji MySQL (bi rawestgehek kurt li Oracle) berbi Vertica ve çû. Û hûn dikarin çîrokek li ser wê bibînin.

Û her tişt pir baş bû, lê zû eşkere bû ku dane mezin dibin û Vertica biha ye. Ji ber vê yekê, li alternatîfên cûrbecûr hatin gerandin. Hin ji wan li vir têne navnîş kirin. Bi rastî, me îsbata têgehê an carinan ceribandina performansê ya hema hema hemî databasên ku ji sala 13-an heya 16-an li sûkê peyda bûn û di warê fonksiyonê de bi qasî guncan bûn, kir. Û min jî li ser hin ji wan li ser HighLoad axivî.

Kar di serî de koçkirina ji Vertica bû, ji ber ku dane mezin bûn. Û ew di nav salan de qat bi qat mezin bûn. Paşê çûn ser refê, lê dîsa jî. Û pêşbînkirina vê mezinbûnê, hewcedariyên karsaziyê yên ji bo mîqdara daneya ku li ser hin celeb analîtîk hewce bû ku were kirin, diyar bû ku dê di demek nêzîk de petabytes werin nîqaş kirin. Û dayîna petabytes jixwe pir biha ye, ji ber vê yekê em li alternatîfek digerin ku em biçin ku derê.

Ku biçe? Û ji bo demek dirêj ne diyar bû ku biçe ku derê, ji ber ku ji aliyekî ve databasên bazirganî hene, ew xuya dikin ku baş dixebitin. Hin hema hema wekî Vertica dixebitin, hin xirabtir. Lê ew hemî biha ne, tiştek erzantir û çêtir nayê dîtin.

Ji hêla din ve, çareseriyên çavkaniyek vekirî hene, ku pir ne pir in, ango ji bo analîtîkan, ew dikarin li ser tiliyan bêne jimartin. Û ew belaş an erzan in, lê hêdî ne. Û ew bi gelemperî fonksiyonek pêdivî û kêrhatî tune.

Û tiştek tune bû ku başiya ku di databasên bazirganî de û hemî belaşên ku di çavkaniya vekirî de ne bi hev re bikin.

Tiştek tune bû heya ku, ji nişka ve, Yandex ClickHouse, mîna sêrbazek ji kêzikê, mîna kêvroşkê, derxist. Û ew biryarek nediyar bû, ew hîn jî pirsê dikin: "Çima?", Lê dîsa jî.

Û tavilê di havîna 2016-an de, me dest pê kir ku li ClickHouse çi ye mêze bikin. Û derket holê ku carinan ew dikare ji Vertica zûtir be. Me senaryoyên cihê li ser daxwazên cihê ceriband. Û heke pirsê tenê tabloyek bikar anî, ango bêyî tevlêbûnê (tevlîbûn), wê hingê ClickHouse du caran ji Vertica zûtir bû.

Ez ne pir tembel bûm û roja din li testên Yandex mêze kir. Li wir jî heman e: ClickHouse du caran ji Vertica zûtir e, ji ber vê yekê ew pir caran li ser wê diaxivin.

Lê heke di pirsan de tevlêbûn hebin, wê hingê her tişt ne pir nezelal derdikeve. Û ClickHouse dikare ji Vertica du caran hêdî be. Û heke hûn daxwazê ​​hinekî rast bikin û ji nû ve binivîsin, wê hingê ew bi qasî hev in. Xerab nîne. Û belaş.

Û piştî ku encamên testê wergirtin, û ji aliyên cihêreng lê mêze kirin, LifeStreet çû ClickHouse.

Ev 16 sal e, ez bi bîr tînim. Mîna henekekê li ser mişkan bû ku digiriyan û xwe hejandin, lê xwarina kaktusê berdewam dikirin. Û ev bi hûrgulî hate vegotin, vîdyoyek li ser vê yekê heye, hwd.

Ji ber vê yekê ez ê bi berfirehî behsa wê nekim, tenê behsa encam û çend tiştên balkêş ên ku min wê demê behsa wan nekiribû bikim.

Encam ev in:

• Koçberiya serketî û zêdetirî salekê sîstem jixwe di hilberînê de dixebite.
• Hilberîn û nermbûn zêde bûye. Ji 10 mîlyar tomarên ku me dikaribû her roj û dûv re jî ji bo demek kurt hilanîn, LifeStreet naha rojane 75 mîlyar tomar hilîne û dikare 3 mehan an jî bêtir vê yekê bike. Ger hûn di lûtkeyê de bijmêrin, wê hingê ev di çirkeyê de heya mîlyonek bûyer e. Rojane zêdetirî mîlyonek pirsên SQL di vê pergalê de, bi piranî ji robotên cihêreng, têne.
• Tevî vê rastiyê ku ji bo ClickHouse ji Vertica bêtir server hatine bikar anîn, wan li ser hardware jî tomar kirine, ji ber ku di Vertica de dîskên SAS-ê yên hêja hatine bikar anîn. ClickHouse SATA bikar anî. Û çima? Ji ber ku di Vertica de têketina hevdem e. Û hevdemkirinê hewce dike ku dîskên pir hêdî nebin, û di heman demê de ku torê pir zêde hêdî neke, ango operasyonek pir biha ye. Û di ClickHouse de têketina asînkron e. Digel vê yekê, hûn her gav dikarin her tiştî herêmî binivîsin, ji bo vê tu lêçûnek zêde tune, ji ber vê yekê dane dikarin ji Vertika zûtir ji Vertika, tewra li ser ajokarên hêdîtir jî, di ClickHouse de werin danîn. Û xwendin jî heman e. Xwendina li ser SATA, heke ew di RAID-ê de bin, wê hingê ev hemî têra xwe zû ye.
• Ji hêla lîsansê ve ne tixûbdar e, ango 3 petabytes daneya di 60 serveran de (20 pêşkêşker yek kopiyek e) û 6 trîlyon tomar di rastî û berhevokan de. Tiştek bi vî rengî li Vertica nayê peyda kirin.

Ez niha di vê nimûneyê de vedigerim ser tiştên pratîk.

• Ya yekem planek bikêr e. Pir tişt bi schema ve girêdayî ye.
• Ya duyemîn hilberîna SQL-a bikêr e.

Lêpirsînek OLAP-a tîpîk hilbijartiyek e. Hin stûn ji hêla komê ve diçin, hin stûn jî diçin fonksiyonên tevhev. Li ku derê ye, ku dikare wekî perçeyek kubê were temsîl kirin. Tevahiya komê dikare wekî projeyek were fikirîn. Û ji ber vê yekê jê re analîza daneya pirreng tê gotin.

Û bi gelemperî ev di forma stêrkek-pîvaz de tête model kirin, dema ku rastiyek navendî û taybetmendiyên vê rastiyê li kêlekan, li ser tîrêjan hene.

Û di warê sêwirana laşî de, ew çawa li ser sifrê dikeve, ew bi gelemperî nûneriyek normalîzekirî dikin. Hûn dikarin denormalîze bikin, lê ew li ser dîskê biha ye û li ser pirsan ne pir bikêrhatî ye. Ji ber vê yekê, ew bi gelemperî nûneriyek normalîzekirî, ango tabloyek rastiyê û gelek, gelek tabloyên pîvanê çêdikin.

Lê ew di ClickHouse de baş naxebite. Du sedem hene:

• Ya yekem ji ber ku ClickHouse xwedan girêdanên ne pir baş e, ango tevlêbûn hene, lê ew xirab in. Dema ku xerab.
• Ya duyemîn jî ew e ku tablo nayên nûve kirin. Bi gelemperî di van lewheyên ku li dora çerxa stêrkê ne, pêdivî ye ku tiştek were guheztin. Mînakî, navê xerîdar, navê pargîdanî, hwd. Û kar nake.

Û di ClickHouse de rêyek ji vê yekê heye. du jî:

• Ya yekem bikaranîna ferhengan e. Ferhengên Derveyî ew e ku ji% 99 ji bo çareserkirina pirsgirêkê bi stêrk-şema, bi nûvekirin û hwd re dibe alîkar.
• Ya duyemîn bikaranîna array e. Array di heman demê de ji bo rakirina tevlêbûn û pirsgirêkên bi normalbûnê re dibe alîkar.

• Tevlîbûn hewce nake.
• Upgradable. Ji Adara 2018-an vir ve, fersendek bêbelge derketiye (hûn ê di belgeyê de vê yekê nebînin) ji bo nûvekirina ferhengan bi qismî, ango ew navnîşên ku hatine guhertin. Di pratîkê de, ew mîna maseyek e.
• Her tim di bîranînê de ye, ji ber vê yekê bi xebata ferhengê re zûtir dibe ku ew tabloyek li ser dîskê be û hîn ne rastiyek e ku ew di cache de ye, bi îhtîmalek mezin na.

• Hûn jî ne hewceyê tevlîbûnê ne.
• Ev temsîla 1-to-gelek kompakt e.
• Û bi dîtina min, array ji bo geekan têne çêkirin. Vana fonksiyonên lambda û hwd.

Ev ne ji bo peyvên sor e. Ev fonksiyonek pir hêzdar e ku dihêle hûn gelek tiştan bi rengek pir hêsan û elegant bikin.

Mînakên tîpîk ên ku alîkariya çareserkirina arrayiyan dikin. Ev nimûne bi têra xwe sade û zelal in:

• Bi etîketan bigerin. Ger hashtagên we li wir hebin û dixwazin bi hashtagê hin peyaman bibînin.
• Bi cotên key-nirxê bigerin. Hin taybetmendiyên bi nirx jî hene.
• Lîsteyên mifteyên ku hûn hewce ne ku wergerînin tiştek din hilînin.

Hemî van karan bêyî array têne çareser kirin. Etîket dikarin di hin rêzan de werin danîn û bi vegotinek birêkûpêk an di tabloyek cûda de bêne hilbijartin, lê dûv re divê hûn tevlêbûnê bikin.

Û di ClickHouse de, hûn ne hewce ne ku tiştek bikin, bes e ku hûn rêzika rêzê ji bo hashtag-an rave bikin an jî avahiyek hêlînek ji bo pergalên girîng-nirxê çêbikin.

Struktura nested dibe ku ne navê çêtirîn be. Ev du rêzikên ku di nav û hin taybetmendiyên têkildar de beşek hevpar in.

Û lêgerîna bi tagê pir hêsan e. Fonksiyonek hebe has, ku kontrol dike ku array hêmanek heye. Her kesî, hemû navnîşên ku bi konferansa me ve girêdayî ye dîtin.

Lêgerîna ji hêla subid ve hinekî tevlihevtir e. Pêdivî ye ku em pêşî pêveka mifteyê bibînin, û dûv re jî hêmanê bi vê pêvekê bigirin û kontrol bikin ka ev nirx tiştê ku em hewce ne. Lêbelê, ew pir hêsan û tevlihev e.

Gotina birêkûpêk a ku hûn dixwazin binivîsin ger we ew hemî di yek rêzê de bihêle, ew ê, pêşî, bêkêmasî be. Û, ya duyemîn, ew ji du rêzan pir dirêjtir xebitî.

Mînakek din. Li ku derê hûn nasnameyê hildigirin arrayek we heye. Û hûn dikarin wan navan wergerînin. Karkirin arrayMap. Ev fonksiyonek lambda ya tîpîk e. Hûn li wir îfadeyên lambda derbas dikin. Û ew ji ferhengê nirxa navî ji bo her nasnameyê derdixe.

Lêgerîn dikare bi heman awayî were kirin. Fonksiyonek pêşdaraz tê derbas kirin ku kontrol dike ka kîjan hêman li hev dikin.

Van tiştan dorpêçê pir hêsan dike û komek pirsgirêkan çareser dike.

Lê pirsgirêka din a ku em pê re rû bi rû ne, û ya ku ez dixwazim behs bikim, pirsên bikêrhatî ne.

• ClickHouse plansaziyek pirsê tune. Qetiyen na.
• Lêbelê, pirsên tevlihev hîn jî hewce ne ku bêne plansaz kirin. Di kîjan rewşan de?
• Ger di pirsê de gelek hevgirtin hebin, hûn wan di binhilbijartinan de dipêçin. Û rêza îdamkirina wan jî girîng e.
• Û ya duyemîn - heke daxwaz tê belav kirin. Ji ber ku di pirsek belavkirî de, tenê jêrhilbijartina hundurîn tête belav kirin, û her tiştê din ji serverek ku we pê ve girêdaye û li wir hatî darve kirin tê derbas kirin. Ji ber vê yekê, heke we bi gelek tevlêbûnê pirs belav kiriye (tevlî), wê hingê hûn hewce ne ku rêzê hilbijêrin.

Û tewra di rewşên hêsan de, carinan jî pêdivî ye ku meriv karê plansazker bike û pirsan hinekî ji nû ve binivîsîne.

Li vir mînakek e. Li milê çepê pirsek heye ku 5 welatên jorîn nîşan dide. Û bi dîtina min 2,5 çirkeyan digire. Û li aliyê rastê, heman pirsê, lê hinekî ji nû ve hatî nivîsandin. Li şûna komkirina bi rêzê, me dest bi komkirina bi key (int) kir. Û ew zûtir e. Û paşê me ferhengek bi encamê ve girêda. Li şûna 2,5 çirke, daxwaz 1,5 saniye digire. Ev baş e.

Mînakek weha bi fîlterên ji nû ve nivîsandinê. Li vir daxwazek ji Rûsyayê heye. Ew ji bo 5 seconds dimeşîne. Ger em wê bi rengekî ji nû ve binivîsin ku em dîsa ne rêzek, lê jimareyan bi hin komek ji wan kilîtên ku bi Rûsyayê re têkildar in bidin ber hev, wê hingê ew ê pir zûtir be.

Gelek hîleyên wiha hene. Û ew rê didin we ku hûn pirsên ku hûn difikirin ku berê zû dimeşin, an, berevajî, hêdî dimeşin, bi girîngî bilezînin. Ew dikarin hê zûtir jî bêne çêkirin.

• Karê herî zêde di moda belavkirî de.
• Rêzkirina li gorî celebên hindiktirîn, wekî ku min bi ints kir.
• Heke tevlêbûn (tevlîbûn), ferheng hebin, wê hingê çêtir e ku hûn wan wekî çareya dawîn bikin, gava ku berê we daneya bi kêmanî qismî komkirî be, wê hingê operasyona tevlêbûnê an jî banga ferhengê dê kêm caran were gazî kirin û ew ê zûtir be. .
• Li şûna Parzûnan.

Teknîkên din hene, û ne tenê yên ku min destnîşan kirine. Û hemî ew carinan carinan dikarin pêkanîna pirsan bi girîngî bilez bikin.

Ka em herin ser mînaka din. Pargîdaniya X ji DY. Ew çi dike?

Karek hebû:

• Girêdana offline ya danûstendinên reklamê.
• Modelkirina modelên cuda yên girêdanê.

Senaryo çi ye?

Ziyaretvanek asayî tê malperê, mînakî, mehê 20 caran ji reklamên cihêreng, an jî wusa carinan bêyî reklam tê, ji ber ku ew vê malperê bi bîr tîne. Li hin berheman dinêre, dixe selikê, ji selikê derdixe. Û, di dawiyê de, tiştek dikire.

Pirsên maqûl: "Ger pêwîst be divê kî ji bo reklamê bide?" û "Kîjan reklam bandor li wî kir, heke hebe?". Yanî çima kirî û çawa kesên wek vî kesî jî bikirin?

Ji bo ku hûn vê pirsgirêkê çareser bikin, hûn hewce ne ku bûyerên ku li ser malperê diqewimin bi rengek rast ve girêdin, ango, bi rengekî têkiliyek di navbera wan de ava bikin. Dûv re ew ji bo analîzê têne şandin DWH. Û li ser bingeha vê analîzê, modelên kê û kîjan reklaman nîşan bidin ava bikin.

Danûstandinek reklamê komek bûyerên bikarhêner ên têkildar e ku ji nîşandana reklamekê dest pê dike, dûv re tiştek diqewime, dûv re dibe ku kirînek, û dûv re dibe ku di nav kirînê de kirîn hebin. Mînakî, heke ev serîlêdanek mobîl an lîstikek mobîl e, wê hingê bi gelemperî sazkirina serîlêdanê belaş pêk tê, û heke tiştek li wir were kirin, wê hingê dibe ku ji bo vê yekê drav hewce be. Û her ku kesek di serîlêdanê de xerc dike, ew qas hêjatir e. Lê ji bo vê yekê hûn hewce ne ku her tiştî girêdin.

Gelek modelên girêdanê hene.

Ya herî populer ev in:

• Têkiliya Dawîn, ku têkiliyek an klîk an bandorek e.
• Têkiliya Yekem, ango yekem tiştê ku kesek anî ser malperê.
• Kombînasyona linear - hemî wekhev.
• Atenuation.
• Wate ya vê çîye.

Û di rêza yekem de ew hemî çawa xebitî? Runtime û Cassandra hebû. Cassandra wekî hilanîna danûstendinê hate bikar anîn, ango hemî danûstandinên têkildar tê de hatin hilanîn. Û gava ku hin bûyer di Runtime de tê, mînakî, hin rûpel an tiştek din nîşan dide, wê hingê daxwazek ji Cassandra hate kirin - kesek wusa heye an na. Dûre danûstendinên ku pê re têkildar in hatin bidestxistin. Û girêdan çêbû.

Û heger ew bi şens e ku daxwazname xwediyê nasnameya danûstendinê ye, wê hingê ew hêsan e. Lê bi gelemperî bê şens. Ji ber vê yekê, pêdivî bû ku meriv danûstendina paşîn an danûstendina bi tikandina paşîn, hwd.

Û ew hemî pir baş dixebitî heya ku girêdan heya klîkek paşîn bû. Ji ber ku her roj 10 mîlyon klîk hene, her meh 300 mîlyon, heke em ji bo mehekê pencereyek saz bikin. Û ji ber ku li Cassandra divê ew hemî di bîranînê de be da ku bilez bimeşîne, ji ber ku Runtime pêdivî ye ku zû bersivê bide, ew bi qasî 10-15 server girt.

Û gava ku wan dixwest ku danûstendinek bi dîmenderê ve girêdin, ew tavilê ew qas ne xweş derket. Û çima? Tê dîtin ku 30 qat zêdetir bûyer hewce ne ku werin hilanîn. Û, li gorî vê yekê, hûn 30 carî bêtir servers hewce ne. Û derket holê ku ev celebek jimareyek astronomîkî ye. Ji bo ku hûn girêdanê bikin heya 500 serveran bihêlin, tevî ku di Runtime-ê de pir kêm server hene, wê hingê ev celebek jimareyek xelet e. Û wan dest pê kir ku çi bikin.

Û em çûn ClickHouse. Û çawa meriv wê li ser ClickHouse bike? Di nihêrîna pêşîn de, wusa dixuye ku ev komek antî-patternan e.

• Danûstandin mezin dibe, em her ku diçe bêtir bûyeran bi wê ve girêdidin, ango ew guhêrbar e, û ClickHouse bi tiştên guhêrbar re pir baş naxebite.
• Dema ku serdanek tê ba me, pêdivî ye ku em danûstandinên wî bi kilît, bi nasnameya seredana wî derxin. Ev jî pirsek xalek e, ew di ClickHouse de wiya nakin. Bi gelemperî ClickHouse xwedan…skanên mezin hene, lê li vir hewce ye ku em hin tomaran bigirin. Her weha antîpatternek.
• Wekî din, danûstendin di json de bû, lê wan nexwest ku wê ji nû ve binivîsin, ji ber vê yekê wan dixwest ku json bi rengek nesazkirî hilînin, û ger hewce bike, tiştek jê derxin. Û ev jî antîpattern e.

Ango komek antîpattern.

Lê dîsa jî derket holê ku ew pergalek ku pir baş dixebitî çêkir.

Çi hate kirin? ClickHouse xuya bû, ku têketin tê de hatine avêtin, li tomaran hatine dabeş kirin. Karûbarek diyarkirî xuya bû ku têketin ji ClickHouse wergirt. Dûv re, ji bo her têketinê, bi nasnameya serdanê, min danûstendinên ku dibe ku hîn nehatibin pêvajokirin û plus wêneyan, ango danûstendinên jixwe ve girêdayî, ango encama xebata berê, wergirtin. Min berê ji wan mantiq çêkir, danûstendina rast hilbijart, bûyerên nû girêda. Dîsa têketin. Têketin vegeriya ClickHouse, ango ew pergalek domdar çerxîkî ye. Û ji bilî vê, ez çûm DWH ku wê li wir analîz bikim.

Di vê formê de bû ku ew pir baş ne xebitî. Û ji bo ku ClickHouse hêsantir bike, dema ku daxwazek ji hêla id-ê serdanê ve hebû, wan van daxwazan di nav blokên 1-000 nasnameyên serdanê de kom kirin û hemî danûstandinên ji bo 2-000 kesan derxistin. Û paşê her tişt xebitî.

Ger hûn li hundurê ClickHouse mêze bikin, wê hingê tenê 3 tabloyên sereke hene ku van hemîyan xizmet dikin.

Tabloya yekem a ku têketin tê de têne barkirin, û têketin hema hema bêyî pêvajoyê têne barkirin.

Tabloya duyemîn. Bi dîtina maddî, bûyerên ku hê nehatine binavkirin, ango yên negirêdayî, ji van qeydan hatine kişandin. Û bi riya dîtina materyalî, danûstendin ji van têketin hatin derxistin da ku wêneyek çêbikin. Ango, dîmenek materyalkirî ya taybetî wêneyek çêkir, ango rewşa paşîn a berhevkirî ya danûstendinê.

Li vir nivîsa ku bi SQL hatî nivîsandin e. Ez dixwazim di wê de çend tiştên girîng şîrove bikim.

Yekem tiştê girîng ew e ku meriv di ClickHouse de stûn û zeviyan ji json derxe. Ango, ClickHouse ji bo xebata bi json re hin rêbaz hene. Ew pir, pir prîmîtîv in.

visitParamExtractInt destûrê dide te ku hûn taybetmendiyan ji json derxînin, ango hita yekem dixebite. Û bi vî awayî hûn dikarin nasnameya danûstendinê derxînin an jî seredana id-ê bikin. Vê carê.

Ya duyemîn, li vir qadek materyalkirî ya dijwar tê bikar anîn. Poldayî? Ev tê wê wateyê ku hûn nekarin wê têxin tabloyê, ango ew nayê xistin, li ser têxistinê tê hesibandin û hilanîn. Dema ku pêvekirin, ClickHouse ji we re kar dike. Û ya ku hûn paşê hewce ne jixwe ji jsonê têne derxistin.

Di vê rewşê de, dîtina materyalkirî ji bo rêzikên xav e. Û tabloya yekem bi têketinên pratîkî yên xav tenê tê bikar anîn. Û ew çi dike? Pêşîn, ew cûrbecûr diguhezîne, ango rêzkirin naha bi nasnameya serdanê re derbas dibe, ji ber ku pêdivî ye ku em zû danûstendina wî ji bo kesek taybetî derxînin.

Ya duyemîn girîng index_granularity e. Ger we MergeTree dîtibe, ew bi gelemperî 8 ji hêla index_granularity-ya xwerû ve ye. Ew çi ye? Ev pîvana kêmbûna îndeksê ye. Di ClickHouse de index kêm e, ew çu carî her têketinê nîşan nake. Her 192 8 vê yekê dike. Û ev baş e dema ku pêdivî ye ku gelek dane bêne hesibandin, lê gava hindik xirab e, ji ber ku sermayek mezin heye. Û heke em granularîteya îndeksê kêm bikin, wê hingê em sermayê kêm dikin. Nabe ku ew bi yek were kêm kirin, ji ber ku dibe ku bîranîn têr nebe. Indeksa her dem di bîranînê de tête tomar kirin.

Snapshot hin taybetmendiyên din ên balkêş ên ClickHouse jî bikar tîne.

Pêşîn, ew AggregatingMergeTree ye. Û AggregatingMergeTree argMax difiroşe, ango ev rewşa danûstendinê ye ku li gorî demjimêra paşîn e. Danûstandin her dem ji bo mêvanek diyar têne çêkirin. Û di rewşa dawî ya vê danûstendinê de, me bûyerek lê zêde kir û me dewletek nû heye. Dîsa li ClickHouse xist. Û bi rêya argMax di vê dîtina materyalî de, em her gav dikarin rewşa heyî bistînin.

• Girêdan ji Runtime "veqetandî" ye.
• Her meh heya 3 mîlyar danûstendinan têne hilanîn û hilanîn. Ev ji ya ku li Cassandra bû, ango di pergalek danûstendinê ya tîpîk de, rêzek mezinahiyê ye.
• Komek pêşkêşkerên 2x5 ClickHouse. 5 pêşkêşker û her serverek kopiyek heye. Ev ji ya ku li Cassandra-yê bû jî kêmtir e ji bo ku meriv bitikîne li ser bingeha klîk bike, û li vir em li ser bingeha bandorê hene. Yanî li şûna ku hejmara serveran 30 qat zêde bikin, karîbûn wan kêm bikin.

Û mînaka paşîn pargîdaniya darayî Y e, ku têkiliyên guhertinên di bihayên stock de analîz kir.

Û peywir ev bû:

• Nêzîkî 5 parve hene.
• Gotinên her 100 milîsaneyan têne zanîn.
• Daneyên di 10 salan de hatine berhev kirin. Xuya ye, ji bo hin pargîdaniyan bêtir, ji bo hinan kêmtir.
• Bi tevahî nêzî 100 milyar rêz hene.

Û pêdivî bû ku pêwendiya guhertinan were hesibandin.

Li vir du stokan û nirxên wan hene. Ger yek bilind bibe û yê din bilind bibe, wê demê ev têkiliyek erênî ye, ango yek bilind dibe û yê din bilind dibe. Ger yek wek dawiya grafikê ber bi jor ve biçe û yê din dakeve jêr, wê demê ev têkiliyek neyînî ye, ango gava yek radibe, yê din dikeve.

Bi analîzkirina van guhertinên hevbeş, mirov dikare di bazara darayî de pêşbîniyan bike.

Lê kar zehmet e. Ji bo vê çi tê kirin? 100 mîlyar tomarên me hene ku hene: dem, stok û bihayê. Pêdivî ye ku em pêşî 100 mîlyar carî Cûdahiya xebitandinê ji algorîtmaya bihayê hesab bikin. RunningDifference di ClickHouse de fonksiyonek e ku bi dû hev cûdahiya di navbera du rêzan de hesab dike.

Û piştî wê, hûn hewce ne ku pêwendiyê hesab bikin, û pêdivî ye ku ji bo her cotek pêwendiyê were hesibandin. Ji bo 5 hîseyan, cot 000 mîlyon in. Û ev pir e, ango 12,5 carî pêdivî ye ku meriv fonksiyonek pêwendiyek wusa were hesibandin.

Û heke kesek ji bîr kir, wê hingê ͞x û ͞y hevokek e. bendewariya nimûneyê. Ango ne tenê kok û koman, lê di nav van berhevokan de jî komekî din jî hewce ye. Pêdivî ye ku komek hesab 12,5 mîlyon carî were kirin, û tewra bi saetan were kom kirin. Saetên me jî gelek in. Û divê hûn di 60 çirkeyan de bikin. Ev henek e.

Pêdivî bû ku bi kêmanî bi rengek dem hebe, ji ber ku ev hemî pir, pir hêdî xebitîn berî ku ClickHouse were.

Wan hewl da ku wê li ser Hadoop, li Spark, li ser Greenplum hesab bikin. Û ev hemû pir hêdî an biha bû. Ango dikaribû bi rengekî hesab bikira, lê dûvre biha bû.

Û paşê ClickHouse hat û tişt pir çêtir bûn.

Ez ji we re bi bîr tînim ku pirsgirêkek me bi cîhê daneyê re heye, ji ber ku têkilî nayên herêmî kirin. Em nikarin hin daneyan deynin ser serverek, hinan li ser serverek din û hesab bikin, divê em hemî daneyan li her derê hebin.

Wan çi kir? Di destpêkê de, daneyên herêmî têne kirin. Her server daneyan li ser nirxa komek diyarkirî hilîne. Û ew li hev nakin. Ji ber vê yekê, gengaz e ku meriv logReturn paralel û serbixwe bihesibîne, ev hemî heta nuha paralel û dabeşkirî diqewimin.

Dûv re me biryar da ku em van daneyan kêm bikin, di heman demê de ku îfadeyê winda nekin. Bi karanîna rêzan kêm bikin, ango ji bo her heyamekê, komek stok û komek bihayan çêbikin. Ji ber vê yekê, ew cîhê daneyê pir kêmtir digire. Û karkirina bi wan re hinekî hêsantir in. Ev hema hema operasyonên paralel in, ango em qismî paralel dixwînin û dûv re ji serverê re dinivîsin.

Piştî vê yekê, ew dikare were dubare kirin. Tîpa "r" tê vê wateyê ku me ev dane dubare kir. Ango, em li ser her sê pêşkêşkeran heman dane hene - ev rêzik in.

Û dûv re bi skrîptek taybetî ji vê koma 12,5 mîlyon pêwendiyên ku divê bêne hesibandin, hûn dikarin pakêtan çêbikin. Ango 2 peywir bi 500 cot pêwendiyan. Û ev peywir divê li ser serverek ClickHouse ya taybetî were hesibandin. Hemî daneyên wî hene, ji ber ku dane yek in û ew dikare wan li pey hev hesab bike.

Careke din, ev e ku ew xuya dike. Pêşîn, me hemî daneyên di vê strukturê de hene: dem, parvekirin, biha. Dûv re me logReturn, ango daneyên heman strukturê hesab kir, lê li şûna bihayê me berê logReturn heye. Dûv re ew ji nû ve hatin çêkirin, ango me dem û komArray ji bo stok û bihayan girt. Replicated. Û piştî wê, me komek peywir çêkir û wan da ClickHouse da ku ew wan bijmêre. Û ew dixebite.

Li ser îsbatkirina têgînê, peywirek binavûdeng bû, yanî kêm dane girtin. Û tenê sê server.

Du qonaxên pêşîn: Hesabkirina Log_return û pêçana di rêzan de bi qasî saetekê girt.

Û hesabkirina pêwendiyê nêzîkî 50 saetan e. Lê 50 saet têr nake, ji ber ku berê bi hefteyan dixebitîn. Serkeftinek mezin bû. Û heke hûn bijmêrin, wê hingê 70 car di çirkeyê de her tişt li ser vê komê hate hesibandin.

Lê ya herî girîng ev e ku ev pergal bi pratîkî bê kêşan e, ango hema hema bi xêzikî mezin dibe. Û wan ew kontrol kirin. Bi serketî mezin kir.

• Plana rast nîvê şer e. Û pilana rast karanîna hemî teknolojiyên ClickHouse yên pêwîst e.
• Berhevkirin/AggregatingMergeTrees teknolojiyên ku destûrê didin we ku hûn wêneyek dewletê wekî dozek taybetî berhev bikin an bihesibînin. Û ew pir tiştan hêsan dike.
• Nêrînên Materyalîzekirî dihêle hûn sînorê yek indexê derbas bikin. Dibe ku min ew pir zelal negot, lê gava ku me têketin barkirin, têketinên xav di tabloyê de bi yek nîşanek bûn, û têketinên taybetmendiyê di tabloyê de bûn, ango heman dane, tenê fîlter kirin, lê pêvek bi tevahî bû. yên din. Wusa dixuye ku ew heman dane, lê cûrbecûr cûda ye. Û Dîtinên Materialized dihêle hûn, ger hewcedariya we hebe, hûn sînorkirinek ClickHouse ya weha derbas bikin.
• Ji bo pirsên xalê hûrguliya îndeksê kêm bikin.
• Û daneyan bi aqilmendî belav bikin, hewl bidin ku bi qasî ku gengaz daneyên di hundurê serverê de herêmî bikin. Û hewl bidin ku bicîh bikin ku daxwaz jî bi qasî ku gengaz dibe herêmîkirinê bikar bînin.

Û bi kurtkirina vê axaftina kurt, em dikarin bibêjin ku ClickHouse naha bi zexmî axa hem databasên bazirganî û hem jî databasên çavkaniya vekirî, ango, bi taybetî ji bo analîtîk, dagir kiriye. Ew bi tevahî di vê perestgehê de cih digire. Û ya din jî, ew hêdî hêdî dest pê dike ku yên din qerebalix bike, ji ber ku gava ku we ClickHouse heye, hûn ne hewce ne InfiniDB. Ger ku ew piştgirîya SQL-ya normal bikin, dibe ku Vertika zû hewce nebe. Hizkirin!

-Spas ji bo raporê! Gelek balkêş! Bi Apache Phoenix re ti berhevdan hebûn?

Na, min nebihîstiye ku tu kes bide ber hev. Em û Yandex hewl didin ku hemî berhevokên ClickHouse bi databasên cihêreng bişopînin. Ji ber ku heke ji nişka ve tiştek ji ClickHouse zûtir derkeve holê, wê hingê Lesha Milovidov nikare bi şev razê û dest bi lezkirina wê dike. Min muqayesek wisa nebihîstiye.

• (Aleksey Milovidov) Apache Phoenix motorek SQL ye ku ji hêla Hbase ve hatî hêz kirin. Hbase bi piranî ji bo senaryoya xebata key-nirx e. Li wir, di her rêzê de, dikare hejmarek stûnên bi navên keyfî hebin. Ev dikare li ser pergalên wekî Hbase, Cassandra were gotin. Û ew bi rastî pirsên analîtîk ên giran in ku dê ji wan re normal nexebitin. An jî hûn dikarin bifikirin ku ew baş dixebitin ger we bi ClickHouse re ne xwedî ezmûnek bû.

• Sipî

  • Paş nîvro Ez jixwe bi vê mijarê re pir eleqedar im, ji ber ku min binepergalek analîtîk heye. Lê gava ku ez li ClickHouse mêze dikim, ez hest dikim ku ClickHouse ji bo analîzkirina bûyerê pir xweş e, guhêrbar. Û heger ez hewce bikim ku gelek daneyên karsaziyê bi komek tabloyên mezin re analîz bikim, wê hingê ClickHouse, bi qasî ku ez fêm dikim, ji min re ne pir maqûl e? Bi taybetî eger ew biguherînin. Gelo ev rast e an mînakên ku dikarin vê yekê red bikin hene?

  • Ev rast e. Û ev ji bo piraniya databasên analîtîk ên pispor rast e. Ew ji bo wê yekê hatine çêkirin ku yek an çend tabloyên mezin hene ku guhêrbar in, û ji bo gelek piçûkên ku hêdî hêdî diguhezin. Ango, ClickHouse ne mîna Oracle ye, ku hûn dikarin her tiştî bi cîh bikin û hin pirsên pir tevlihev ava bikin. Ji bo ku hûn ClickHouse bi bandor bikar bînin, hûn hewce ne ku nexşeyek bi rengek ku di ClickHouse de baş bixebitin ava bikin. Ango, xwe ji normalîzekirina zêde dûr bixin, ferhengan bikar bînin, hewl bidin ku kêmtir girêdanên dirêj çêbikin. Û heke nexşe bi vî rengî were çêkirin, wê hingê karên karsaziyê yên wekhev dikarin li ser ClickHouse ji databasek pêwendiya kevneşopî pir bi bandortir werin çareser kirin.

Spas ji bo raporê! Pirsek min li ser doza aborî ya herî dawî heye. Analîtîkên wan hebûn. Pêwîst bû ku ew çawa ber bi jor û jêr ve biçin. Û ez fêm dikim ku we pergalê bi taybetî ji bo vê analîtîk ava kir? Ger sibe, bo nimûne, ew hewceyê raporek din li ser vê daneyê bin, gelo ew hewce ne ku nexşeyê ji nû ve ava bikin û daneyan bar bikin? Ango, ji bo wergirtina daxwazê ​​hin celebek pêşdibistanê bikin?

Bê guman, ev karanîna ClickHouse ji bo karekî pir taybetî ye. Ew dikare bi kevneşopî di hundurê Hadoop de were çareser kirin. Ji bo Hadoop, ev karekî îdeal e. Lê li ser Hadoop ew pir hêdî ye. Û armanca min ev e ku destnîşan bikim ku ClickHouse dikare karên ku bi gelemperî bi rêgezên bi tevahî cûda têne çareser kirin çareser bike, lê di heman demê de wê pir bikêrtir bike. Ev ji bo karekî taybetî hatiye çêkirin. Eşkere ye ku eger pirsgirêkek bi tiştek wekhev re hebe, wê hingê ew dikare bi rengek wekhev were çareser kirin.

Diyar e. We got ku 50 saet hatin kirin. Ma ew ji destpêkê ve, kengê we dane bar kir an encam girt?

Yes Yes.

OK gelek spas.

Ev li ser komek serverek 3 ye.

Silav! Spas ji bo raporê! Her tişt pir balkêş e. Ez ê piçekî li ser fonksiyonê nepirsim, lê li ser karanîna ClickHouse di warê aramiyê de. Yanî te hebû, ma te divê restore bikî? ClickHouse di vê rewşê de çawa tevdigere? Û ev çêbû ku we replica jî hebû? Mînakî, me bi ClickHouse re rastî pirsgirêkek hat dema ku ew hîn jî ji sînorê xwe derdikeve û dikeve.

Bê guman, pergalên îdeal tune. Û ClickHouse jî pirsgirêkên xwe hene. Lê we bihîstiye ku Yandex.Metrica demek dirêj nexebite? Probably ne. Ew ji 2012-2013-an vir ve li ser ClickHouse bi pêbawer dixebite. Ez dikarim di derbarê serpêhatiya xwe de heman tiştî bibêjim. Em tu carî bi tevahî têkçûn nebûne. Dibe ku hin tiştên qismî biqewimin, lê ew tu carî ew qas krîtîk nebûn ku bi giranî bandorê li karsaziyê bikin. Qet nebû. ClickHouse pir pêbawer e û bi tesadufî têk naçe. Ne hewce ye ku hûn li ser vê yekê xemgîn bibin. Ew ne tiştek xav e. Ev ji hêla gelek pargîdaniyan ve hatî îspat kirin.

Slav! We got ku hûn hewce ne ku tavilê li ser şemaya daneyê bifikirin. Heke ew çêbû? Daneyên min dibarin û dibarin. Şeş meh derbas dibin, û ez fêm dikim ku ne gengaz e ku meriv bi vî rengî bijî, pêdivî ye ku ez daneyan ji nû ve barkim û bi wan re tiştek bikim.

Ev bê guman bi pergala we ve girêdayî ye. Gelek rê hene ku meriv vê yekê hema hema bê rawestan bike. Mînakî, hûn dikarin Dîmenek Materyalîzekirî biafirînin ku tê de avahiyek daneya cûda çêbike heke ew bi rengek bêhempa were nexşandin. Ango, heke ew destûrê dide nexşeyê bi karanîna ClickHouse, ango hin tiştan derxe, mifteya bingehîn biguhezîne, dabeşkirinê biguhezîne, wê hingê hûn dikarin Nêrînek Materyalkirî çêbikin. Daneyên xwe yên kevn li wir binivîsin, yên nû dê bixweber bêne nivîsandin. Û dûv re tenê bi karanîna Nêrîna Materialized veguherînin, dûv re tomar biguherînin û tabloya kevn bikujin. Ev bi gelemperî rêbazek bê rawestan e.

Sipî

Source: www.habr.com