Teorio kaj praktiko de uzado de ClickHouse en realaj aplikoj. Alexander Zaitsev (2018)

Malgraŭ la fakto, ke nun estas multaj datumoj preskaŭ ĉie, analizaj datumbazoj ankoraŭ estas sufiĉe ekzotikaj. Ili estas malbone konataj kaj eĉ pli malbone kapablas uzi ilin efike. Multaj daŭre "manĝas kakton" kun MySQL aŭ PostgreSQL, kiuj estas desegnitaj por aliaj scenaroj, suferas per NoSQL aŭ tropagas por komercaj solvoj. ClickHouse ŝanĝas la regulojn de la ludo kaj signife malaltigas la sojlon por eniri la mondon de analiza DBMS.

Raporto de BackEnd Conf 2018 kaj ĝi estas publikigita kun la permeso de la parolanto.

Kiu mi estas kaj kial mi parolas pri ClickHouse? Mi estas evoludirektoro ĉe LifeStreet, kiu uzas ClickHouse. Ankaŭ mi estas la fondinto de Altinity. Ĝi estas Yandex-partnero, kiu antaŭenigas ClickHouse kaj helpas Yandex fari ClickHouse pli sukcesa. Ankaŭ preta dividi scion pri ClickHouse.

Kaj mi ne estas la frato de Petja Zaitsev. Oni ofte demandas min pri tio. Ne, ni ne estas fratoj.

"Ĉiuj scias" ke ClickHouse:

• Tre rapida,
• Tre komforta
• Uzita en Yandex.

Iom malpli estas konata en kiuj kompanioj kaj kiel ĝi estas uzata.

Mi diros al vi kial, kie kaj kiel ClickHouse estas uzata, krom Yandex.

Mi rakontos al vi kiel specifaj taskoj estas solvitaj helpe de ClickHouse en malsamaj kompanioj, kiajn ilojn de ClickHouse vi povas uzi por viaj taskoj, kaj kiel ili estis uzataj en malsamaj kompanioj.

Mi prenis tri ekzemplojn kiuj montras ClickHouse de malsamaj anguloj. Mi pensas, ke ĝi estos interese.

La unua demando estas: "Kial ni bezonas ClickHouse?". Ĝi ŝajnas esti sufiĉe evidenta demando, sed estas pli ol unu respondo al ĝi.

• La unua respondo estas por agado. ClickHouse estas tre rapida. Analytics sur ClickHouse ankaŭ estas tre rapida. Ĝi ofte povas esti uzata kie io alia estas tre malrapida aŭ tre malbona.
• La dua respondo estas kosto. Kaj antaŭ ĉio, la kosto de grimpi. Ekzemple, Vertica estas absolute bonega datumbazo. Ĝi funkcias tre bone se vi ne havas multajn terabajtojn da datumoj. Sed kiam temas pri centoj da terabajtoj aŭ petabajtoj, la kosto de permesilo kaj subteno eniras sufiĉe signifan kvanton. Kaj ĝi estas multekosta. Kaj ClickHouse estas senpaga.
• La tria respondo estas operacia kosto. Ĉi tio estas iomete malsama aliro. RedShift estas bonega analogaĵo. En RedShift, vi povas fari decidon tre rapide. Ĝi funkcios bone, sed samtempe, ĉiuhore, ĉiutage kaj ĉiumonate, vi pagos al Amazon sufiĉe kare, ĉar ĉi tio estas signife multekosta servo. Google BigQuery ankaŭ. Se iu uzis ĝin, tiam li scias, ke tie vi povas fari plurajn petojn kaj ricevi fakturon por centoj da dolaroj subite.

ClickHouse ne havas ĉi tiujn problemojn.

Kie estas nun uzata ClickHouse? Krom Yandex, ClickHouse estas uzata en multaj diversaj entreprenoj kaj kompanioj.

• Antaŭ ĉio, ĉi tio estas analizo pri TTT-apliko, t.e. ĉi tio estas uzkazo, kiu venis de Yandex.
• Multaj AdTech-kompanioj uzas ClickHouse.
• Multaj kompanioj, kiuj bezonas analizi transakciajn protokolojn de malsamaj fontoj.
• Pluraj kompanioj uzas ClickHouse por kontroli sekurecajn protokolojn. Ili alŝutas ilin al ClickHouse, faras raportojn kaj ricevas la rezultojn, kiujn ili bezonas.
• Firmaoj komencas uzi ĝin en financa analizo, t.e. iom post iom grandaj entreprenoj ankaŭ alproksimiĝas al ClickHouse.
• nuboflamo. Se iu sekvas ClickHouse, tiam ili verŝajne aŭdis la nomon de ĉi tiu kompanio. Ĉi tiu estas unu el la esencaj kontribuantoj de la komunumo. Kaj ili havas tre seriozan instaladon de ClickHouse. Ekzemple, ili faris Kafka Engine por ClickHouse.
• Telekomunikaj kompanioj komencis uzi. Pluraj kompanioj uzas ClickHouse aŭ kiel pruvon pri koncepto aŭ jam en produktado.
• Unu firmao uzas ClickHouse por monitori produktadajn procezojn. Ili testas mikrocirkvitojn, forprenas amason da parametroj, estas ĉirkaŭ 2 karakterizaĵoj. Kaj tiam ili analizas ĉu la ludo estas bona aŭ malbona.
• Blockchain-analitiko. Estas tia rusa kompanio kiel Bloxy.info. Ĉi tio estas analizo de la reto ethereum. Ili ankaŭ faris tion ĉe ClickHouse.

Kaj la grandeco ne gravas. Estas multaj kompanioj, kiuj uzas unu malgrandan servilon. Kaj li permesas al ili solvi iliajn problemojn. Kaj eĉ pli da kompanioj uzas grandajn aretojn de multaj serviloj aŭ dekoj da serviloj.

Kaj se vi rigardas la rekordojn, tiam:

• Yandex: 500+ serviloj, ili stokas 25 miliardojn da diskoj tage tie.
• LifeStreet: 60 serviloj, proksimume 75 miliardoj da registroj ĉiutage. Estas malpli da serviloj, pli da rekordoj ol en Yandex.
• CloudFlare: 36 serviloj, ili ŝparas 200 miliardojn da rekordoj tage. Ili havas eĉ malpli da serviloj kaj stokas eĉ pli da datumoj.
• Bloomberg: 102 serviloj, ĉirkaŭ triliono da eniroj ĉiutage. Rekordisto.

Geografie, ĉi tio ankaŭ estas multe. Ĉi tiu mapo ĉi tie montras varmmapon de kie ClickHouse estas uzata en la mondo. Rusujo, Ĉinio, Ameriko klare elstaras ĉi tie. Estas malmultaj eŭropaj landoj. Kaj estas 4 aretoj.

Ĉi tio estas kompara analizo, ne necesas serĉi absolutajn ciferojn. Jen analizo de vizitantoj, kiuj legas anglalingvajn materialojn en la retejo de Altinity, ĉar tie ne ekzistas ruslingvaj. Kaj Rusio, Ukrainio, Belorusio, t.e. la ruslingva parto de la komunumo, ĉi tiuj estas la plej multaj uzantoj. Poste venas Usono kaj Kanado. Ĉinio tre akiras. Antaŭ ses monatoj preskaŭ ne estis Ĉinio tie, nun Ĉinio jam superis Eŭropon kaj daŭre kreskas. Malnova Eŭropo ankaŭ ne malproksimiĝas, kaj la gvidanto en la uzo de ClickHouse estas, strange, Francio.

Kial mi rakontas ĉion ĉi? Montri, ke ClickHouse fariĝas norma solvo por analizo de grandaj datumoj kaj jam estas uzata en multaj lokoj. Se vi uzas ĝin, vi estas en la ĝusta tendenco. Se vi ankoraŭ ne uzas ĝin, tiam vi ne povas timi, ke vi restos sola kaj neniu helpos vin, ĉar multaj jam faras tion.

Ĉi tiuj estas ekzemploj de reala uzo de ClickHouse en pluraj kompanioj.

• La unua ekzemplo estas reklama reto: migrado de Vertica al ClickHouse. Kaj mi konas kelkajn kompaniojn, kiuj transiris de Vertica aŭ estas en procezo de transiro.
• La dua ekzemplo estas transakcia stokado sur ClickHouse. Ĉi tio estas ekzemplo konstruita sur kontraŭŝablonoj. Ĉio, kio ne devus esti farita en ClickHouse laŭ la konsilo de programistoj, estas farita ĉi tie. Kaj ĝi estas farita tiel efike ke ĝi funkcias. Kaj ĝi funkcias multe pli bone ol la tipa transakcia solvo.
• La tria ekzemplo estas distribuita komputado sur ClickHouse. Estis demando pri kiel ClickHouse povas esti integrita en la Hadoop-ekosistemon. Mi montros ekzemplon de kiel firmao faris ion similan al mapo redukti ujo sur ClickHouse, tenante trakon de datumoj lokalizo, ktp, por kalkuli tre ne-triviala tasko.

• LifeStreet estas Ad Tech-kompanio, kiu havas la tutan teknologion, kiu venas kun reklama reto.
• Ŝi okupiĝas pri reklam-optimumigo, programa oferto.
• Multaj datumoj: ĉirkaŭ 10 miliardoj da eventoj ĉiutage. Samtempe tie eventoj povas esti dividitaj en plurajn subokazaĵojn.
• Estas multaj klientoj de ĉi tiuj datumoj, kaj ĉi tiuj ne estas nur homoj, multe pli - ĉi tiuj estas diversaj algoritmoj, kiuj okupiĝas pri programaj oferto.

La kompanio venis longan kaj dornan vojon. Kaj mi parolis pri ĝi ĉe HighLoad. Unue, LifeStreet translokiĝis de MySQL (kun mallonga halto ĉe Oracle) al Vertica. Kaj vi povas trovi rakonton pri ĝi.

Kaj ĉio estis tre bona, sed rapide evidentiĝis, ke la datumoj kreskas kaj Vertica estas multekosta. Tial oni serĉis diversajn alternativojn. Kelkaj el ili estas listigitaj ĉi tie. Kaj fakte, ni faris pruvon de koncepto aŭ foje agado-testadon de preskaŭ ĉiuj datumbazoj, kiuj estis haveblaj sur la merkato de la 13-a ĝis la 16-a jaro kaj estis proksimume taŭgaj laŭ funkcieco. Kaj mi ankaŭ parolis pri kelkaj el ili ĉe HighLoad.

La tasko estis migri de Vertica unue, ĉar la datumoj kreskis. Kaj ili kreskis eksponente tra la jaroj. Poste ili iris sur la breton, sed tamen. Kaj antaŭdiri ĉi tiun kreskon, komercajn postulojn por la kvanto da datumoj, pri kiuj ia analizo necesas fari, estis klare, ke petabajtoj baldaŭ estos diskutitaj. Kaj pagi petabajtojn jam estas tre multekosta, do ni serĉis alternativon kien iri.

Kien iri? Kaj dum longa tempo estis tute neklara kien iri, ĉar unuflanke estas komercaj datumbazoj, ili ŝajnas bone funkcii. Iuj funkcias preskaŭ same kiel Vertica, iuj pli malbone. Sed ili ĉiuj estas multekostaj, nenio pli malmultekosta kaj pli bona ne troveblas.

Aliflanke, ekzistas liberkodaj solvoj, kiuj ne estas tre multaj, t.e. por analitiko, ili povas esti kalkulitaj sur la fingroj. Kaj ili estas senpagaj aŭ malmultekostaj, sed malrapidaj. Kaj ofte mankas al ili la necesaj kaj utilaj funkcioj.

Kaj estis nenio por kombini la bonon kiu estas en komercaj datumbazoj kaj la tuta senpaga kiu estas en malferma fonto.

Estis nenio ĝis, neatendite, Yandex eltiris ClickHouse, kiel magiisto el ĉapelo, kiel kuniklo. Kaj ĝi estis neatendita decido, ili ankoraŭ demandas: "Kial?", Sed tamen.

Kaj tuj en la somero de 2016, ni komencis rigardi kio estas ClickHouse. Kaj montriĝis, ke foje ĝi povas esti pli rapida ol Vertica. Ni testis malsamajn scenarojn pri malsamaj demandoj. Kaj se la demando uzis nur unu tablon, tio estas, sen iuj kuniĝoj (kuniĝi), tiam ClickHouse estis duoble pli rapida ol Vertica.

Mi ne estis tro maldiligenta kaj rigardis Yandex-testojn la alian tagon. Tie estas same: ClickHouse estas duoble pli rapida ol Vertica, do oni ofte parolas pri tio.

Sed se estas kuniĝoj en la demandoj, tiam ĉio rezultas ne tre malambigue. Kaj ClickHouse povas esti duoble pli malrapida ol Vertica. Kaj se vi iomete korektas la peton kaj reverkas ĝin, tiam ili estas proksimume egalaj. Ne malbona. Kaj senpage.

Kaj ricevinte la testrezultojn, kaj rigardante ĝin de malsamaj anguloj, LifeStreet iris al ClickHouse.

Ĉi tiu estas la 16-a jaro, mi memorigas al vi. Estis kvazaŭ ŝerco pri musoj, kiuj ploris kaj pikis sin, sed daŭre manĝis la kakton. Kaj ĉi tio estis priskribita detale, estas video pri tio, ktp.

Tial mi ne parolos pri ĝi detale, mi nur parolos pri la rezultoj kaj kelkaj interesaj aferoj, pri kiuj mi tiam ne parolis.

La rezultoj estas:

• Sukcesa migrado kaj pli ol jaro la sistemo jam funkcias en produktado.
• Produktiveco kaj fleksebleco pliiĝis. El la 10 miliardoj da diskoj, kiujn ni povus pagi konservi tage kaj poste por mallonga tempo, LifeStreet nun stokas 75 miliardojn da diskoj tage kaj povas fari tion dum 3 monatoj aŭ pli. Se vi kalkulas je la pinto, tiam ĉi tio estas ĝis miliono da eventoj por sekundo. Pli ol miliono da SQL-demandoj tage alvenas en ĉi tiu sistemo, plejparte de malsamaj robotoj.
• Malgraŭ tio, ke pli da serviloj estis uzitaj por ClickHouse ol por Vertica, ili ankaŭ ŝparis sur aparataro, ĉar sufiĉe multekostaj SAS-diskoj estis uzitaj en Vertica. ClickHouse uzis SATA. Kaj kial? Ĉar en Vertica enmeto estas sinkrona. Kaj sinkronigado postulas, ke la diskoj ne tro malrapidu, kaj ankaŭ ke la reto ne tro malrapidu, tio estas sufiĉe multekostan operacion. Kaj en ClickHouse enmeto estas nesinkrona. Krome, vi ĉiam povas skribi ĉion loke, ne estas aldonaj kostoj por tio, do datumoj povas esti enmetitaj en ClickHouse multe pli rapide ol en Vertika, eĉ en pli malrapidaj diskoj. Kaj legado estas proksimume la sama. Legante sur SATA, se ili estas en RAID, tiam ĉio ĉi estas sufiĉe rapida.
• Ne limigita de permesilo, t.e. 3 petabajtoj da datumoj en 60 serviloj (20 serviloj estas unu kopio) kaj 6 bilionoj da rekordoj en faktoj kaj agregaĵoj. Nenio tia povus esti pagebla ĉe Vertica.

Mi nun turnas min al praktikaj aferoj en ĉi tiu ekzemplo.

• La unua estas efika skemo. Multe dependas de la skemo.
• La dua estas efika SQL-generado.

Tipa OLAP-demando estas elekto. Kelkaj el la kolumnoj iras al grupigo per, kelkaj el la kolumnoj iras al agregaj funkcioj. Estas kie, kiu povas esti reprezentita kiel tranĉaĵo de kubo. La tuta grupo de povas esti opiniita kiel projekcio. Kaj tial ĝi nomiĝas plurvaria datuma analizo.

Kaj ofte ĉi tio estas modeligita en la formo de stelskemo, kiam estas centra fakto kaj karakterizaĵoj de ĉi tiu fakto laŭ la flankoj, laŭ la radioj.

Kaj laŭ fizika dezajno, kiel ĝi taŭgas sur la tablo, ili kutime faras normaligitan reprezenton. Vi povas malnormaligi, sed ĝi estas multekosta en disko kaj ne tre efika ĉe demandoj. Tial, ili kutime faras normaligitan reprezentadon, t.e. faktabelon kaj multajn, multajn dimensiotabelojn.

Sed ĝi ne funkcias bone en ClickHouse. Estas du kialoj:

• La unua estas ĉar ClickHouse ne havas tre bonajn kuniĝojn, t.e. ekzistas aliĝoj, sed ili estas malbonaj. Dum malbona.
• La dua estas, ke la tabeloj ne estas ĝisdatigitaj. Kutime en ĉi tiuj platoj, kiuj estas ĉirkaŭ la stel-cirkvito, io devas esti ŝanĝita. Ekzemple, klientonomo, kompanio nomo, ktp. Kaj ĝi ne funkcias.

Kaj estas elirejo de ĉi tio en ClickHouse. eĉ du:

• La unua estas la uzo de vortaroj. Eksteraj Vortaroj estas kio helpas 99% solvi la problemon kun la stelskemo, kun ĝisdatigoj ktp.
• La dua estas la uzo de tabeloj. Tabeloj ankaŭ helpas forigi kuniĝojn kaj problemojn kun normaligo.

• Neniu aliĝo bezonata.
• Ĝisdatigebla. Ekde marto 2018 aperis nedokumentita okazo (tion vi ne trovos en la dokumentaro) parte ĝisdatigi vortarojn, t.e. tiujn enskribojn, kiuj ŝanĝiĝis. Praktike, ĝi estas kiel tablo.
• Ĉiam en memoro, do kuniĝas kun vortaro funkcias pli rapide ol se ĝi estus tabelo kiu estas sur disko kaj ankoraŭ ne estas fakto ke ĝi estas en la kaŝmemoro, plej verŝajne ne.

• Vi ankaŭ ne bezonas aliĝojn.
• Ĉi tio estas kompakta 1-al-multaj reprezento.
• Kaj laŭ mi, tabeloj estas faritaj por geeks. Ĉi tiuj estas lambda funkcioj ktp.

Ĉi tio ne estas por ruĝaj vortoj. Ĉi tio estas tre potenca funkcio, kiu ebligas al vi fari multajn aferojn en tre simpla kaj eleganta maniero.

Tipaj ekzemploj kiuj helpas solvi tabelojn. Ĉi tiuj ekzemploj estas sufiĉe simplaj kaj klaraj:

• Serĉu per etikedoj. Se vi havas hashtags tie kaj volas trovi kelkajn afiŝojn per hashtag.
• Serĉu per ŝlosil-valoraj paroj. Estas ankaŭ iuj atributoj kun valoro.
• Stokante listojn de ŝlosiloj, kiujn vi bezonas traduki al io alia.

Ĉiuj ĉi tiuj taskoj povas esti solvitaj sen tabeloj. Etikedoj povas esti metitaj en iu linio kaj elektitaj per regula esprimo aŭ en aparta tabelo, sed tiam vi devas fari kuniĝojn.

Kaj en ClickHouse, vi ne bezonas fari ion ajn, sufiĉas priskribi la ĉen-tabelon por hashtags aŭ fari nestitan strukturon por ŝlosil-valoraj sistemoj.

Nestita strukturo eble ne estas la plej bona nomo. Ĉi tiuj estas du tabeloj, kiuj havas komunan parton en la nomo kaj iujn rilatajn trajtojn.

Kaj estas tre facile serĉi per etikedo. Havi funkcion has, kiu kontrolas ke la tabelo enhavas elementon. Ĉiuj, trovis ĉiujn enskribojn kiuj rilatas al nia konferenco.

Serĉo per subid estas iom pli komplika. Ni devas unue trovi la indekson de la ŝlosilo, kaj poste preni la elementon kun ĉi tiu indekso kaj kontroli, ke ĉi tiu valoro estas tio, kion ni bezonas. Tamen, ĝi estas tre simpla kaj kompakta.

La regula esprimo, kiun vi ŝatus skribi, se vi konservus ĉion en unu linio, ĝi estus, unue, mallerta. Kaj, due, ĝi funkciis multe pli longe ol du tabeloj.

Alia ekzemplo. Vi havas tabelon kie vi stokas la ID. Kaj vi povas traduki ilin en nomojn. Funkcio arrayMap. Ĉi tio estas tipa lambda funkcio. Vi pasas lambdajn esprimojn tie. Kaj ŝi eltiras la valoron de la nomo por ĉiu identigilo el la vortaro.

Serĉo povas esti farita en la sama maniero. Oni pasas predikatan funkcion, kiu kontrolas, kion la elementoj kongruas.

Ĉi tiuj aferoj multe simpligas la cirkviton kaj solvas amason da problemoj.

Sed la sekva problemo, kiun ni alfrontas, kaj kiun mi ŝatus mencii, estas efikaj demandoj.

• ClickHouse ne havas konsultplanilon. Absolute ne.
• Tamen, kompleksaj demandoj ankoraŭ devas esti planitaj. En kiuj kazoj?
• Se estas pluraj kuniĝoj en la demando, vi envolvas ilin en subelektoj. Kaj la ordo en kiu ili estas ekzekutitaj gravas.
• Kaj la dua - se la peto estas distribuita. Ĉar en distribuita konsulto, nur la plej interna subelekto estas ekzekutita distribuita, kaj ĉio alia estas transdonita al unu servilo al kiu vi konektis kaj ekzekutita tie. Sekve, se vi distribuis demandojn kun multaj kuniĝoj (aliĝi), tiam vi devas elekti la ordon.

Kaj eĉ en pli simplaj kazoj, foje ankaŭ necesas fari la laboron de la planilo kaj reverki demandojn iomete.

Jen ekzemplo. Maldekstre estas demando, kiu montras la suprajn 5 landojn. Kaj necesas 2,5 sekundoj, laŭ mi. Kaj sur la dekstra flanko, la sama demando, sed iomete reverkita. Anstataŭ grupigi per ŝnuro, ni komencis grupigi per ŝlosilo (int). Kaj ĝi estas pli rapida. Kaj poste ni kunligis vortaron al la rezulto. Anstataŭ 2,5 sekundoj, la peto daŭras 1,5 sekundojn. Ĉi tio estas bona.

Simila ekzemplo kun reverkaj filtriloj. Jen peto por Rusio. Ĝi kuras dum 5 sekundoj. Se ni reverkas ĝin tiel, ke ni komparas denove ne ŝnuron, sed nombrojn kun iu aro de tiuj klavoj, kiuj rilatas al Rusio, tiam ĝi estos multe pli rapida.

Estas multaj tiaj lertaĵoj. Kaj ili ebligas al vi signife akceli demandojn, kiujn vi opinias, ke jam funkcias rapide aŭ, male, malrapide. Ili povas esti faritaj eĉ pli rapide.

• Maksimuma laboro en distribuita reĝimo.
• Ordigo laŭ minimumaj tipoj, kiel mi faris per ints.
• Se estas iuj kuniĝoj (kuniĝi), vortaroj, tiam estas pli bone fari ilin kiel lasta rimedo, kiam vi jam havas datumojn almenaŭ parte grupigitajn, tiam la kunigo-operacio aŭ vortaro vokos malpli fojojn kaj estos pli rapida. .
• Anstataŭigi filtrilojn.

Estas aliaj teknikoj, kaj ne nur tiuj, kiujn mi pruvis. Kaj ĉiuj ili foje povas signife akceli la plenumadon de demandoj.

Ni transiru al la sekva ekzemplo. Kompanio X el Usono. Kion ŝi faras?

Estis tasko:

• Senrete ligado de reklamaj transakcioj.
• Modeligado de malsamaj biligaj modeloj.

Kio estas la scenaro?

Ordinara vizitanto venas al la retejo, ekzemple, 20 fojojn monate de malsamaj reklamoj, aŭ ĝuste tiel foje venas sen reklamoj, ĉar li memoras ĉi tiun retejon. Rigardas kelkajn produktojn, metas ilin en la korbon, elprenas ilin el la korbo. Kaj, finfine, io aĉetas.

Raciaj demandoj: "Kiu pagu por reklamado, se necese?" kaj "Kia reklamado influis lin, se iu?". Tio estas, kial li aĉetis kaj kiel igi homojn kiel ĉi tiu homo aĉeti ankaŭ?

Por solvi ĉi tiun problemon, vi devas konekti la eventojn okazantajn en la retejo en la ĝusta maniero, tio estas, iel konstrui ligon inter ili. Tiam ili estas senditaj por analizo al DWH. Kaj surbaze de ĉi tiu analizo, konstruu modelojn pri kiu kaj kiaj reklamoj montri.

Reklama transakcio estas aro de rilataj uzantkazaĵoj, kiuj komenciĝas de montrado de reklamo, tiam io okazas, tiam eble aĉeto, kaj tiam povas esti aĉetoj ene de aĉeto. Ekzemple, se ĉi tio estas movebla aplikaĵo aŭ movebla ludo, tiam kutime la instalado de la aplikaĵo okazas senpage, kaj se io estas farita tie, tiam mono povas esti postulata por tio. Kaj ju pli homo elspezas en la aplikaĵo, des pli valora ĝi estas. Sed por ĉi tio vi devas konekti ĉion.

Estas multaj biligaj modeloj.

La plej popularaj estas:

• Lasta Interago, kie interago estas aŭ klako aŭ impreso.
• Unua Interago, t.e. la unua afero, kiu alportis homon al la retejo.
• Lineara kombinaĵo - ĉiuj egale.
• Malfortiĝo.
• Kaj tiel plu.

Kaj kiel ĉio funkciis unue? Estis Runtime kaj Kasandra. Kasandra estis utiligita kiel transakciostokado, t.e. ĉiuj rilataj transakcioj estis stokitaj en ĝi. Kaj kiam iu evento venas en Runtime, ekzemple, montrante iun paĝon aŭ ion alian, tiam oni faris peton al Kasandra - ĉu ekzistas tia persono aŭ ne. Tiam la transakcioj kiuj rilatas al ĝi estis akiritaj. Kaj la ligo estis farita.

Kaj se estas bonŝance, ke la peto havas transakciidentigilon, tiam ĝi estas facila. Sed kutime neniu sorto. Tial, necesis trovi la lastan transakcion aŭ la transakcion kun la lasta klako, ktp.

Kaj ĉio funkciis tre bone dum la ligado estis ĝis la lasta klako. Ĉar estas, ekzemple, 10 milionoj da klakoj tage, 300 milionoj monate, se ni fiksas fenestron por monato. Kaj ĉar en Cassandra ĝi devas esti ĉio en memoro por funkcii rapide, ĉar la Runtime bezonas rapide respondi, necesas ĉirkaŭ 10-15 serviloj.

Kaj kiam ili volis ligi transakcion al la ekrano, ĝi tuj montriĝis ne tiel amuza. Kaj kial? Oni povas vidi, ke 30 fojojn pli da eventoj devas esti stokitaj. Kaj, sekve, vi bezonas 30 fojojn pli da serviloj. Kaj montriĝas, ke ĉi tio estas ia astronomia figuro. Por konservi ĝis 500 servilojn por fari la ligon, malgraŭ la fakto ke estas signife malpli da serviloj en Runtime, tiam ĉi tio estas ia malĝusta figuro. Kaj ili ekpensis, kion fari.

Kaj ni iris al ClickHouse. Kaj kiel fari ĝin sur ClickHouse? Unuavide, ŝajnas, ke ĉi tio estas aro de kontraŭ-ŝablonoj.

• La transakcio kreskas, ni ligas pli kaj pli da eventoj al ĝi, t.e. ĝi estas ŝanĝebla, kaj ClickHouse ne tre bone funkcias kun ŝanĝeblaj objektoj.
• Kiam vizitanto venas al ni, ni devas eltiri siajn transakciojn per ŝlosilo, per sia vizitid. Ĉi tio ankaŭ estas punktodemando, ili ne faras tion en ClickHouse. Kutime ClickHouse havas grandajn …skanaĵojn, sed ĉi tie ni devas akiri kelkajn rekordojn. Ankaŭ kontraŭŝablono.
• Krome, la transakcio estis en json, sed ili ne volis reverki ĝin, do ili volis konservi json en nestrukturita maniero, kaj se necese, eltiri ion el ĝi. Kaj ĉi tio ankaŭ estas kontraŭŝablono.

Tio estas, aro da kontraŭŝablonoj.

Sed tamen ĝi rezultis fari sistemon kiu funkciis tre bone.

Kio estis farita? Aperis ClickHouse, en kiun ŝtipoj estis ĵetitaj, dividitaj en rekordojn. Atribuita servo aperis, kiu ricevis protokolojn de ClickHouse. Post tio, por ĉiu eniro, per vizitidentigilo, mi ricevis transakciojn kiuj eble ankoraŭ ne estis prilaboritaj kaj plus momentfotojn, t.e. transakciojn jam konektitajn, nome la rezulton de antaŭa laboro. Mi jam faris logikon el ili, elektis la ĝustan transakcion, konektis novajn eventojn. Ensalutinta denove. La protokolo revenis al ClickHouse, t.e. ĝi estas konstante cikla sistemo. Kaj krome mi iris al DWH por analizi ĝin tie.

Estis en ĉi tiu formo ke ĝi ne funkciis tre bone. Kaj por plifaciligi ĝin por ClickHouse, kiam estis peto per vizitid, ili grupigis ĉi tiujn petojn en blokojn de 1-000 vizitid-id kaj eltiris ĉiujn transakciojn por 2-000 homoj. Kaj tiam ĉio funkciis.

Se vi rigardas ene de ClickHouse, tiam estas nur 3 ĉefaj tabloj, kiuj servas ĉion ĉi.

La unua tabelo en kiu protokoloj estas alŝutitaj, kaj la protokoloj estas alŝutitaj preskaŭ sen prilaborado.

Dua tablo. Per la materiigita vido, el ĉi tiuj protokoloj, eventoj kiuj ankoraŭ ne estis atribuitaj, t.e., senrilataj, estis morditaj. Kaj tra la realigita vido, transakcioj estis eltiritaj el ĉi tiuj protokoloj por konstrui momentan foton. Tio estas, speciala materiigita vido konstruis momentfoton, nome la lasta amasigita stato de la transakcio.

Jen la teksto skribita en SQL. Mi ŝatus komenti kelkajn gravajn aferojn en ĝi.

La unua grava afero estas la kapablo eltiri kolumnojn kaj kampojn de json en ClickHouse. Tio estas, ClickHouse havas kelkajn metodojn por labori kun json. Ili estas tre, tre primitivaj.

visitParamExtractInt permesas ĉerpi atributojn de json, t.e. la unua trafo funkcias. Kaj tiamaniere vi povas eltiri transakcian identigilon aŭ viziti id. Ĉifoje.

Due, delikata materiigita kampo estas uzata ĉi tie. Kion ĝi signifas? Ĉi tio signifas, ke vi ne povas enmeti ĝin en la tabelon, t.e. ĝi ne estas enigita, ĝi estas kalkulita kaj stokita post enmeto. Algluante, ClickHouse faras la laboron por vi. Kaj tio, kion vi bezonas poste, estas jam eltirita el json.

En ĉi tiu kazo, materiigita vido estas por krudaj vicoj. Kaj la unua tablo kun preskaŭ krudaj ŝtipoj estas nur uzata. Kaj kion li faras? Unue, ĝi ŝanĝas la ordigon, t.e. ordigo nun iras per vizitid, ĉar ni devas rapide eltiri lian transakcion por specifa persono.

La dua grava afero estas indekso_granuleco. Se vi vidis MergeTree, ĝi kutime estas 8 defaŭlte index_granularity. Kio ĝi estas? Ĉi tiu estas la parametro de indekso maldenseco. En ClickHouse la indekso estas malabunda, ĝi neniam indeksas ĉiun eniron. Ĝi faras ĉi tion ĉiun 192 8. Kaj ĉi tio estas bona kiam multaj datumoj estas bezonataj por esti kalkulitaj, sed malbona kiam malmulte, ĉar estas granda superkosto. Kaj se ni reduktas la indekson granularecon, tiam ni reduktas la superkoston. Ĝi ne povas esti reduktita al unu, ĉar eble mankas sufiĉe da memoro. La indekso ĉiam estas konservita en memoro.

Momentfoto ankaŭ uzas aliajn interesajn funkciojn de ClickHouse.

Unue, ĝi estas AggregatingMergeTree. Kaj AggregatingMergeTree stokas argMax, t.e. ĉi tiu estas la stato de la transakcio responda al la lasta tempomarko. Transakcioj estas generitaj la tutan tempon por donita vizitanto. Kaj en la plej lasta stato de ĉi tiu transakcio, ni aldonis eventon kaj ni havas novan staton. Ĝi denove trafis ClickHouse. Kaj per argMax en ĉi tiu realigita vido, ni ĉiam povas akiri la nunan staton.

• La ligado estas "malkunliga" de la Runtime.
• Ĝis 3 miliardoj da transakcioj monate estas stokitaj kaj prilaboritaj. Ĉi tio estas grandordo pli ol ĝi estis en Kasandra, t.e. en tipa transakcia sistemo.
• Areto de 2x5 ClickHouse-serviloj. 5 serviloj kaj ĉiu servilo havas kopion. Ĉi tio estas eĉ malpli ol ĝi estis en Kasandra por fari klak-bazitan atribuon, kaj ĉi tie ni havas impreson bazitan. Tio estas, anstataŭ pliigi la nombron da serviloj je 30 fojojn, ili sukcesis redukti ilin.

Kaj la lasta ekzemplo estas financa kompanio Y, kiu analizis la korelaciojn de ŝanĝoj en akciaj prezoj.

Kaj la tasko estis:

• Estas proksimume 5 akcioj.
• Citaĵoj ĉiuj 100 milisekundoj estas konataj.
• La datumoj amasiĝis dum 10 jaroj. Ŝajne, por iuj kompanioj pli, por iuj malpli.
• Estas proksimume 100 miliardoj da vicoj entute.

Kaj necesis kalkuli la korelacion de ŝanĝoj.

Jen du akcioj kaj iliaj citaĵoj. Se unu iras supren kaj la alia iras supren, tiam ĉi tio estas pozitiva korelacio, t.e. unu iras supren kaj la alia iras supren. Se unu iras supren, kiel ĉe la fino de la grafikaĵo, kaj la alia malsupreniras, tiam tio estas negativa korelacio, t.e. kiam unu leviĝas, la alia falas.

Analizante ĉi tiujn reciprokajn ŝanĝojn, oni povas fari antaŭdirojn en la financa merkato.

Sed la tasko estas malfacila. Kion oni faras por tio? Ni havas 100 miliardojn da registroj, kiuj havas: tempon, akciojn kaj prezon. Ni devas kalkuli unue 100 miliardojn da fojoj la kuranta Diferenco de la prezo-algoritmo. RunningDifference estas funkcio en ClickHouse, kiu sinsekve kalkulas la diferencon inter du ŝnuroj.

Kaj post tio, vi devas kalkuli la korelacion, kaj la korelacio devas esti kalkulita por ĉiu paro. Por 5 000 akcioj, paroj estas 12,5 milionoj. Kaj ĉi tio estas multe, t.e. 12,5 fojojn necesas kalkuli ĝuste tian korelacian funkcion.

Kaj se iu forgesis, tiam ͞x kaj ͞y estas mato. specimena atendo. Tio estas, necesas ne nur kalkuli la radikojn kaj sumojn, sed ankaŭ unu pli da sumoj ene de ĉi tiuj sumoj. Aro da kalkuloj devas esti faritaj 12,5 milionojn da fojoj, kaj eĉ grupigitaj laŭ horoj. Ni ankaŭ havas multajn horojn. Kaj vi devas fari ĝin en 60 sekundoj. Estas ŝerco.

Necesis havi tempon almenaŭ iel, ĉar ĉio ĉi funkciis tre, tre malrapide antaŭ la alveno de ClickHouse.

Ili provis kalkuli ĝin sur Hadoop, sur Spark, sur Greenplum. Kaj ĉio ĉi estis tre malrapida aŭ multekosta. Tio estas, eblis iel kalkuli, sed tiam ĝi estis multekosta.

Kaj tiam venis ClickHouse kaj aferoj multe pliboniĝis.

Mi memorigas al vi, ke ni havas problemon kun datumloko, ĉar korelacioj ne povas esti lokalizitaj. Ni ne povas meti iujn datumojn sur unu servilon, iujn sur alian kaj kalkuli, ni devas havi ĉiujn datumojn ĉie.

Kion ili faris? Komence, la datumoj estas lokalizitaj. Ĉiu servilo stokas datumojn pri la prezo de certa aro de akcioj. Kaj ili ne interkovras. Tial, eblas kalkuli logReturn paralele kaj sendepende, ĉio ĉi okazas ĝis nun paralele kaj distribuita.

Tiam ni decidis redukti ĉi tiujn datumojn, ne perdante esprimivon. Reduktu uzante tabelojn, t.e. por ĉiu tempodaŭro, faru aron da akcioj kaj aron da prezoj. Tial ĝi okupas multe malpli da datumspaco. Kaj ili estas iom pli facile labori kun ili. Ĉi tiuj estas preskaŭ paralelaj operacioj, t.e. ni parte legas paralele kaj poste skribas al la servilo.

Post tio, ĝi povas esti reproduktita. La litero "r" signifas, ke ni reproduktis ĉi tiujn datumojn. Tio estas, ni havas la samajn datumojn sur ĉiuj tri serviloj - ĉi tiuj estas la tabeloj.

Kaj tiam kun speciala skripto de ĉi tiu aro de 12,5 milionoj da korelacioj, kiuj devas esti kalkulitaj, vi povas fari pakaĵojn. Tio estas, 2 500 taskoj kun 5 000 paroj da korelacioj. Kaj ĉi tiu tasko estas kalkulita sur specifa servilo de ClickHouse. Li havas ĉiujn datumojn, ĉar la datumoj estas la samaj kaj li povas sinsekve kalkuli ilin.

Denove, jen kiel ĝi aspektas. Unue, ni havas ĉiujn datumojn en ĉi tiu strukturo: tempo, akcioj, prezo. Tiam ni kalkulis logReturn, t.e. datumojn de la sama strukturo, sed anstataŭ la prezo ni jam havas logReturn. Tiam ili estis refaritaj, t.e. ni ricevis la tempon kaj groupArray por akcioj kaj prezoj. Sreplikita. Kaj post tio, ni generis amason da taskoj kaj nutris ilin al ClickHouse por ke ĝi kalkulu ilin. Kaj ĝi funkcias.

Sur pruvo de koncepto, la tasko estis subtasko, t.e., malpli da datenoj estis prenitaj. Kaj nur tri serviloj.

Ĉi tiuj unuaj du stadioj: kalkuli Log_return kaj envolvi en tabeloj daŭris proksimume horon.

Kaj la kalkulo de la korelacio estas ĉirkaŭ 50 horoj. Sed 50 horoj ne sufiĉas, ĉar oni laboris dum semajnoj. Ĝi estis granda sukceso. Kaj se vi kalkulas, tiam 70 fojojn je sekundo ĉio estis kalkulita sur ĉi tiu areto.

Sed la plej grava afero estas, ke ĉi tiu sistemo estas praktike sen botelkoloj, t.e., ĝi skalas preskaŭ linie. Kaj ili kontrolis ĝin. Sukcese pligrandigis ĝin.

• La ĝusta skemo estas duono de la batalo. Kaj la ĝusta skemo estas la uzo de ĉiuj necesaj ClickHouse-teknologioj.
• Summing/AggregatingMergeTrees estas teknologioj kiuj permesas vin kunigi aŭ konsideri ŝtatan momentfoton kiel specialan kazon. Kaj ĝi ege simpligas multajn aferojn.
• Materiigitaj Vidoj permesas vin preterpasi la unu indeksan limon. Eble mi ne diris ĝin tre klare, sed kiam ni ŝargis la protokolojn, la krudaj protokoloj estis en la tabelo kun unu indekso, kaj la atributo-protokoloj estis en la tabelo, t.e. la samaj datumoj, nur filtritaj, sed la indekso estis tute. aliaj. Ĝi ŝajnas esti la samaj datumoj, sed malsama ordigo. Kaj Materiigitaj Vidoj permesas vin, se vi bezonas ĝin, preteriri tian limigon de ClickHouse.
• Redukti indeksgranulecon por punktodemandoj.
• Kaj distribuu la datumojn inteligente, provu lokalizi la datumojn ene de la servilo kiel eble plej multe. Kaj provu certigi, ke petoj ankaŭ uzu lokalizon laŭeble kiel eble plej multe.

Kaj resumante ĉi tiun mallongan paroladon, ni povas diri, ke ClickHouse nun firme okupis la teritorion de kaj komercaj datumbazoj kaj malfermfontaj datumbazoj, t.e., specife por analizo. Li perfekte persvadas en ĉi tiun pejzaĝon. Kaj kio estas pli, ĝi malrapide komencas elpeli aliajn, ĉar kiam vi havas ClickHouse, vi ne bezonas InfiniDB. Vertika eble ne estos bezonata baldaŭ se ili faras normalan SQL-subtenon. Ĝuu!

-Dankon pro la raporto! Tre interesa! Ĉu estis komparoj kun Apache Phoenix?

Ne, mi aŭdis neniun kompari. Ni kaj Yandex provas konservi trakon de ĉiuj ClickHouse-komparoj kun malsamaj datumbazoj. Ĉar se subite io montriĝas pli rapida ol ClickHouse, tiam Lesha Milovidov ne povas dormi nokte kaj komencas rapide akceli ĝin. Mi ne aŭdis pri tia komparo.

• (Aleksey Milovidov) Apache Phoenix estas SQL-motoro funkciigita de Hbase. Hbase estas ĉefe por ŝlosilvalora laborscenaro. Tie, en ĉiu linio, povas esti arbitra nombro da kolumnoj kun arbitraj nomoj. Ĉi tio povas esti dirita pri tiaj sistemoj kiel Hbase, Cassandra. Kaj ĝuste pezaj analizaj demandoj ne funkcios normale por ili. Aŭ vi povus pensi, ke ili funkcias bone se vi ne havis sperton kun ClickHouse.

• Спасибо

  • Bonan posttagmezon Mi jam sufiĉe interesiĝas pri ĉi tiu temo, ĉar mi havas analizan subsistemon. Sed kiam mi rigardas ClickHouse, mi havas la senton, ke ClickHouse tre bone taŭgas por eventanalizo, ŝanĝebla. Kaj se mi bezonas analizi multajn komercajn datumojn kun amaso da grandaj tabloj, tiam ClickHouse, laŭ mia kompreno, ne tre taŭgas por mi? Precipe se ili ŝanĝiĝas. Ĉu tio estas ĝusta aŭ ĉu ekzistas ekzemploj kiuj povas refuti tion?

  • Ĉi tio pravas. Kaj tio validas pri la plej multaj fakaj analizaj datumbazoj. Ili estas tajloritaj por tio, ke ekzistas unu aŭ pluraj grandaj tabloj, kiuj estas ŝanĝeblaj, kaj por multaj malgrandaj, kiuj malrapide ŝanĝiĝas. Tio estas, ClickHouse ne similas al Oracle, kie vi povas meti ĉion kaj konstrui tre kompleksajn demandojn. Por uzi ClickHouse efike, vi devas konstrui skemon en maniero kiu funkcias bone en ClickHouse. Tio estas, evitu troan normaligon, uzu vortarojn, provu fari malpli longajn ligilojn. Kaj se la skemo estas konstruita tiamaniere, tiam similaj komercaj taskoj povas esti solvitaj sur ClickHouse multe pli efike ol sur tradicia rilata datumbazo.

Dankon pro la raporto! Mi havas demandon pri la lasta financa kazo. Ili havis analizojn. Necesis kompari kiel ili supreniras kaj malsupreniras. Kaj mi komprenas, ke vi konstruis la sistemon specife por ĉi tiu analizo? Se morgaŭ, ekzemple, ili bezonas alian raporton pri ĉi tiuj datumoj, ĉu ili bezonas rekonstrui la skemon kaj alŝuti la datumojn? Tio estas, fari ian antaŭtraktadon por ricevi la peton?

Kompreneble, ĉi tio estas la uzo de ClickHouse por tre specifa tasko. Ĝi povus pli tradicie esti solvita ene de Hadoop. Por Hadoop, ĉi tio estas ideala tasko. Sed ĉe Hadoop ĝi estas tre malrapida. Kaj mia celo estas pruvi, ke ClickHouse povas solvi taskojn, kiuj estas kutime solvitaj per tute malsamaj rimedoj, sed samtempe fari ĝin multe pli efike. Ĉi tio estas adaptita por specifa tasko. Estas klare, ke se estas problemo kun io simila, tiam ĝi povas esti solvita en simila maniero.

Estas klare. Vi diris, ke 50 horoj estis prilaboritaj. Ĉu de la komenco, kiam vi ŝargis la datumojn aŭ ricevis la rezultojn?

Jes Jes.

Bone koran dankon.

Ĉi tio estas sur 3 servila areto.

Saluton! Dankon pro la raporto! Ĉio estas tre interesa. Mi ne demandos iomete pri la funkcieco, sed pri la uzo de ClickHouse laŭ stabileco. Tio estas, ĉu vi havis, ĉu vi devis restarigi? Kiel kondutas ClickHouse en ĉi tiu kazo? Kaj ĉu okazis, ke vi ankaŭ havis kopion? Ekzemple, ni renkontis problemon kun ClickHouse kiam ĝi ankoraŭ eliras el sia limo kaj falas.

Kompreneble, ne ekzistas idealaj sistemoj. Kaj ClickHouse ankaŭ havas siajn proprajn problemojn. Sed ĉu vi aŭdis pri Yandex.Metrica ne funkcianta dum longa tempo? Verŝajne ne. Ĝi funkcias fidinde ekde 2012-2013 ĉe ClickHouse. Mi povas diri la samon pri mia sperto. Ni neniam havis kompletajn fiaskojn. Iuj partaj aferoj povus okazi, sed ili neniam estis sufiĉe kritikaj por serioze influi la komercon. Ĝi neniam okazis. ClickHouse estas sufiĉe fidinda kaj ne kraŝas hazarde. Vi ne devas zorgi pri ĝi. Ĝi ne estas kruda afero. Ĉi tio estis pruvita de multaj kompanioj.

Saluton! Vi diris, ke vi devas tuj pripensi la datumskemon. Kio se ĝi okazus? Miaj datumoj verŝas kaj verŝas. Ses monatoj pasas, kaj mi komprenas, ke estas neeble vivi tiel, mi devas re-alŝuti la datumojn kaj fari ion per ili.

Ĉi tio kompreneble dependas de via sistemo. Estas pluraj manieroj fari tion preskaŭ sen halto. Ekzemple, vi povas krei Materialigitan Vidon en kiu fari malsaman datumstrukturon se ĝi povas esti unike mapita. Tio estas, se ĝi permesas mapadon per ClickHouse, t.e. ĉerpi iujn aferojn, ŝanĝi la ĉefan ŝlosilon, ŝanĝi dispartigon, tiam vi povas fari Materiigitan Vidon. Anstataŭigu viajn malnovajn datumojn tie, novaj estos skribitaj aŭtomate. Kaj tiam simple ŝanĝu al uzado de la Materiigita Vido, tiam ŝanĝu la rekordon kaj mortigu la malnovan tablon. Ĉi tio estas ĝenerale senhalta metodo.

Kontrolo.

fonto: www.habr.com