ClickHouse aplikazio errealetan erabiltzeko teoria eta praktika. Alexander Zaitsev (2018)

Gaur egun datu asko ia nonahi egon arren, datu-base analitikoak nahiko exotikoak dira oraindik. Gaizki ezagutzen dira eta are okerrago modu eraginkorrean erabiltzeko gai dira. Askok MySQL edo PostgreSQL-ekin "kaktusak" jaten jarraitzen dute, beste agertoki batzuetarako diseinatuta daudenak, NoSQLrekin jasaten edo irtenbide komertzialak gehiegi ordaintzen dituztenak. ClickHouse-k joko-arauak aldatzen ditu eta DBMS analitikoen munduan sartzeko atalasea nabarmen jaisten du.

BackEnd Conf 2018ko txostena eta hizlariaren baimenarekin argitaratzen da.

Nor naiz ni eta zergatik ari naiz ClickHousez hitz egiten? ClickHouse erabiltzen duen LifeStreet-eko garapen zuzendaria naiz. Gainera, Altinity-ren sortzailea naiz. ClickHouse sustatzen duen Yandex-eko bazkidea da eta Yandex-i ClickHouse arrakastatsua egiten laguntzen diona. ClickHouseri buruzko ezagutza partekatzeko prest ere.

Eta ez naiz Petya Zaitseven anaia. Askotan galdetzen didate honetaz. Ez, ez gara anaiak.

"Edonork daki" ClickHouse hori:

• Oso azkar,
• Oso erosoa
• Yandex-en erabiltzen da.

Gutxiago ezagutzen da zein enpresatan eta nola erabiltzen den.

Esango dizut zergatik, non eta nola erabiltzen den ClickHouse, Yandex izan ezik.

Enpresa ezberdinetan ClickHouse-ren laguntzaz zeregin zehatzak nola konpontzen diren esango dizut, zure zereginetarako zein ClickHouse tresna erabil ditzakezun eta enpresa ezberdinetan nola erabiltzen ziren.

ClickHouse angelu ezberdinetatik erakusten duten hiru adibide jaso ditut. Interesgarria izango dela uste dut.

Lehenengo galdera hau da: "Zergatik behar dugu ClickHouse?". Nahiko galdera argia dirudi, baina erantzun bat baino gehiago dago.

• Lehenengo erantzuna errendimendurako da. ClickHouse oso azkarra da. ClickHouse-n analitika ere oso azkarra da. Askotan beste zerbait oso motela edo oso txarra den lekuetan erabil daiteke.
• Bigarren erantzuna kostua da. Eta lehenik eta behin, eskalatzearen kostua. Adibidez, Vertica datu-base guztiz bikaina da. Oso ondo funtzionatzen du terabyte datu asko ez badituzu. Baina ehunka terabyte edo petabyteren kasuan, lizentzia eta laguntzaren kostua nahiko kopuru esanguratsua da. Eta garestia da. Eta ClickHouse doakoa da.
• Hirugarren erantzuna funtzionamendu kostua da. Hau ikuspegi apur bat ezberdina da. RedShift analogiko bikaina da. RedShift-en, erabaki bat oso azkar har dezakezu. Ondo funtzionatuko du, baina, aldi berean, orduro, egunero eta hilabetero, nahiko garesti ordainduko diozu Amazoni, zerbitzu hau nabarmen garestia delako. Google BigQuery ere. Norbaitek erabiltzen badu, badaki bertan hainbat eskaera egin ditzakezula eta ehunka dolarren faktura bat jaso dezakezula bat-batean.

ClickHouse-k ez ditu arazo hauek.

Non erabiltzen da ClickHouse orain? Yandex-ez gain, ClickHouse negozio eta enpresa ezberdinetan erabiltzen da.

• Lehenik eta behin, hau web aplikazioen analisia da, hau da, Yandex-etik etorritako erabilera kasu bat da.
• AdTech enpresa askok ClickHouse erabiltzen dute.
• Iturri ezberdinetako transakzioen erregistroak aztertu behar dituzten enpresa ugari.
• Hainbat konpainiak ClickHouse erabiltzen dute segurtasun-erregistroak kontrolatzeko. ClickHousera igotzen dituzte, txostenak egiten dituzte eta behar dituzten emaitzak lortzen dituzte.
• Enpresak finantza-analisian erabiltzen hasi dira, hau da, pixkanaka negozio handiak ere hurbiltzen ari dira ClickHousera.
• hodei-flare. Norbaitek ClickHouse jarraitzen badu, ziurrenik konpainia honen izena entzun du. Hau komunitatearen funtsezko laguntzaileetako bat da. Eta ClickHouse instalazio oso serioa dute. Adibidez, ClickHouserako Kafka Engine egin zuten.
• Telekomunikazio enpresak erabiltzen hasi ziren. Hainbat konpainiak ClickHouse erabiltzen dute kontzeptuaren froga gisa edo dagoeneko produkzioan.
• Enpresa batek ClickHouse erabiltzen du ekoizpen-prozesuak kontrolatzeko. Mikrozirkuituak probatzen dituzte, parametro mordoa idazten dute, 2 ezaugarri inguru daude. Eta gero partida ona ala txarra den aztertzen dute.
• Blockchain-en analitika. Bloxy.info bezalako enpresa errusiar bat dago. Hau ethereum sarearen analisia da. ClickHousen ere egin zuten.

Eta tamainak ez du axola. Zerbitzari txiki bat erabiltzen duten enpresa asko daude. Eta arazoak konpontzeko aukera ematen die. Eta are gehiago konpainiak zerbitzari asko edo dozenaka zerbitzariren multzo handiak erabiltzen dituzte.

Eta erregistroei begiratuz gero, orduan:

• Yandex: 500+ zerbitzari, egunean 25 milioi erregistro gordetzen dituzte bertan.
• LifeStreet: 60 zerbitzari, egunero 75 milioi erregistro inguru. Zerbitzari gutxiago daude, Yandex-en baino erregistro gehiago.
• CloudFlare: 36 zerbitzari, egunean 200 milioi erregistro aurrezten dituzte. Are zerbitzari gutxiago dituzte eta are datu gehiago gordetzen dituzte.
• Bloomberg: 102 zerbitzari, egunean bilioi bat sarrera inguru. Erregistro titularra.

Geografikoki, hau ere asko da. Hemengo mapa honek ClickHouse munduan erabiltzen ari den bero-mapa erakusten du. Errusia, Txina, Amerika nabarmentzen dira hemen. Europako herrialde gutxi daude. Eta 4 multzo daude.

Analisi konparatiboa da hau, ez dago zifra absoluturik bilatu beharrik. Altinity webgunean ingelesezko materialak irakurtzen dituzten bisitarien analisia da hau, han ez baitago errusieraz hitz egiten dutenik. Eta Errusia, Ukraina, Bielorrusia, hau da, komunitatearen errusiar hiztunen zatia, hauek dira erabiltzaile ugarienak. Gero AEB eta Kanada datoz. Txina asko harrapatzen ari da. Duela sei hilabete ez zegoen ia Txinarik han, orain Txinak Europa gainditu du jada eta hazten jarraitzen du. Europa zaharra ere ez dago atzean, eta ClickHouse-ren erabileran liderra, bitxia bada ere, Frantzia da.

Zergatik kontatzen dut hau guztia? ClickHouse datu handien analisirako irtenbide estandarra bihurtzen ari dela erakusteko eta dagoeneko leku askotan erabiltzen dela. Erabiltzen baduzu, joera egokian zaude. Oraindik erabiltzen ari ez bazara, ezin duzu beldur izan bakarrik geratuko zarela eta inork ez dizula lagunduko, asko dagoeneko egiten ari direlako.

Hauek hainbat enpresatan ClickHouse benetako erabileraren adibideak dira.

• Lehenengo adibidea iragarki-sare bat da: Verticatik ClickHouserako migrazioa. Eta ezagutzen ditut Verticatik igaro diren edo trantsizio prozesuan dauden enpresa batzuk.
• Bigarren adibidea ClickHouse-n biltegiratze transakzionala da. Hau antipatroietan eraikitako adibide bat da. Garatzaileen aholkularitzarekin ClickHousen egin behar ez dena hemen egiten da. Eta hain modu eraginkorrean egiten da funtzionatzen duela. Eta transakzio irtenbide tipikoa baino askoz hobeto funtzionatzen du.
• Hirugarren adibidea ClickHouse-n banatutako informatika da. ClickHouse Hadoop ekosisteman nola integra daitekeen galdera bat zegoen. Adibide bat erakutsiko dut enpresa batek nola egin duen mapa murrizteko edukiontzi baten antzeko zerbait ClickHousen, datuen lokalizazioaren jarraipena eginez, etab., oso zeregin ez-trivial bat kalkulatzeko.

• LifeStreet Ad Tech enpresa bat da, iragarki-sare batekin datorren teknologia guztia duena.
• Iragarkien optimizazioan, eskaintza programatikoan dihardu.
• Datu asko: egunean 10 milioi gertakari inguru. Aldi berean, hango ekitaldiak hainbat azpigertaeratan bana daitezke.
• Datu horien bezero asko daude, eta hauek ez dira pertsonak bakarrik, askoz gehiago; eskaintza programatikoan aritzen diren hainbat algoritmo dira.

Bide luze eta arantzatsua egin du konpainiak. Eta horretaz hitz egin nuen HighLoad-en. Lehenik eta behin, LifeStreet MySQL-tik (Oracle-n geldialdi labur batekin) Verticara joan zen. Eta horri buruzko istorio bat aurki dezakezu.

Eta dena oso ona zen, baina azkar ikusi zen datuak hazten ari direla eta Vertica garestia dela. Horregatik, hainbat alternatiba bilatu ziren. Horietako batzuk hemen zerrendatzen dira. Izan ere, 13. urtetik 16. urtera merkatuan eskuragarri zeuden eta funtzionalitate aldetik gutxi gorabehera egokiak ziren ia datu-base guztien kontzeptuaren froga edo, batzuetan, errendimendu probak egin genituen. Eta horietako batzuei buruz ere hitz egin nuen HighLoad-en.

Lehenik eta behin Verticatik migratzea zen zeregina, datuak hazi egin zirelako. Eta urteetan zehar esponentzialki hazi ziren. Gero apalera joan ziren, baina hala ere. Eta hazkunde hori aurreikusten, negozio-eskakizunak nolabaiteko analisiak egin behar diren datu-kopuruari dagokionez, argi zegoen laster petabyte-ak eztabaidatuko zirela. Eta petabyteak ordaintzea dagoeneko oso garestia da, beraz, nora joan alternatiba bat bilatzen ari ginen.

Nora joan? Eta denbora luzez ez zegoen batere argi nora jo, alde batetik datu-base komertzialak daudelako, ondo funtzionatzen dutela dirudi. Batzuk Verticak bezain ondo funtzionatzen dute, beste batzuk okerrago. Baina guztiak garestiak dira, ez da ezer merkeagorik eta hoberik aurkitu.

Bestalde, kode irekiko irtenbideak daude, oso ugariak ez direnak, hau da, analitiketarako, hatzekin zenbatu daitezke. Eta doakoak edo merkeak dira, baina motelak. Eta askotan ez dute beharrezko eta erabilgarria funtzionaltasunik.

Eta ez zegoen ezer datu-base komertzialetan dagoen ona eta kode irekian dagoen doako guztia uztartzeko.

Ez zen ezer izan, ustekabean, Yandexek ClickHouse atera zuen arte, txapel batetik aztia bezala, untxi bat bezala. Eta ustekabeko erabakia izan zen, oraindik galdera egiten dute: “Zergatik?”, baina hala ere.

Eta berehala 2016ko udan, ClickHouse zer den aztertzen hasi ginen. Eta ondorioztatu zen batzuetan Vertica baino azkarragoa izan daitekeela. Eszenatoki desberdinak probatu ditugu eskaera ezberdinetan. Eta kontsultak taula bakarra erabiltzen bazuen, hau da, batuketarik gabe (join), orduan ClickHouse Vertica baino bi aldiz azkarragoa zen.

Ez nintzen oso alferra eta Yandex probei begiratu nion lehengo egunean. Han ere berdina da: ClickHouse Vertica baino bi aldiz azkarragoa da, beraz, askotan hitz egiten dute horretaz.

Baina kontsultetan batuketak badaude, dena ez da oso argi eta garbi ateratzen. Eta ClickHouse Vertica baino bi aldiz motelagoa izan daiteke. Eta eskaera apur bat zuzentzen baduzu eta berridazten baduzu, gutxi gorabehera berdinak dira. Ez dago gaizki. Eta doan.

Eta proben emaitzak jasota, eta hainbat angelutatik begiratuta, LifeStreet ClickHousera joan zen.

16. urtea da, gogorarazten dizuet. Saguei buruzko txantxa bat bezalakoa zen negar egiten eta zulatu egiten zuten, baina kaktusa jaten jarraitu zuten. Eta hau zehatz-mehatz deskribatu zen, honi buruzko bideo bat dago, etab.

Hori dela eta, ez dut horri buruz zehatz-mehatz hitz egingo, emaitzei eta orduan hitz egin ez nituen gauza interesgarri batzuei buruz bakarrik hitz egingo dut.

Emaitzak hauek dira:

• Migrazio arrakastatsua eta urtebete baino gehiago sistema dagoeneko lanean ari da ekoizpenean.
• Produktibitatea eta malgutasuna handitu dira. Egunero gorde genitzakeen 10 milioi diskoetatik eta, ondoren, denbora laburrean, LifeStreet-ek gaur egun 75 milioi erregistro gordetzen ditu egunean eta 3 hilabetez edo gehiagoz egin ditzake. Gailurrean zenbatzen baduzu, milioi bat gertaera segundoko izango dira. Egunean milioi bat SQL kontsulta baino gehiago iristen dira sistema honetara, gehienbat robot ezberdinetatik.
• ClickHouserako Verticarako baino zerbitzari gehiago erabili ziren arren, hardwarean ere aurreztu zuten, Vertican SAS disko garesti samarrak erabiltzen zirelako. ClickHouse-k SATA erabili zuen. Eta zergatik? Vertican txertaketa sinkronikoa delako. Eta sinkronizazioak eskatzen du diskoak ez moteltzea gehiegi, eta, gainera, sarea gehiegi moteltzea, hau da, eragiketa garestia samarra. Eta ClickHousen txertatzea asinkronoa da. Gainera, dena lokalean idatz dezakezu beti, ez dago kostu gehigarririk horretarako, beraz, datuak ClickHousen Vertika-n baino askoz azkarrago txerta daitezke, baita disko geldoagoetan ere. Eta irakurtzea gauza bera da. SATA-n irakurtzen, RAID-en badaude, hau guztia nahikoa azkarra da.
• Lizentziaren arabera mugatuta ez dago, hau da, 3 petabyte datu 60 zerbitzaritan (20 zerbitzari erreplika bat da) eta 6 bilioi erregistro gertakari eta agregazioetan. Vertican ezin zen horrelakorik lortu.

Orain adibide honetan gauza praktikoetara jotzen dut.

• Lehenengoa eskema eraginkorra da. Asko eskemaren araberakoa da.
• Bigarrena SQL sorkuntza eraginkorra da.

OLAP kontsulta tipikoa hautaketa bat da. Zutabe batzuk taldeka doaz, zutabe batzuk agregazio funtzioetara. Non dago, kubo baten xerra gisa irudika daitekeena. Talde osoa proiekzio gisa har daiteke. Eta horregatik deitzen zaio aldagai anitzeko datuen analisia.

Eta askotan hori izar-eskema moduan modelatzen da, alboetan, izpietan zehar, gertakari zentral bat eta gertakari horren ezaugarriak daudenean.

Eta diseinu fisikoari dagokionez, mahai gainean nola egokitzen den, normalean irudikapen normalizatua egiten dute. Desnormaliza dezakezu, baina diskoan garestia da eta ez da oso eraginkorra kontsultetan. Hori dela eta, normalean errepresentazio normalizatua egiten dute, hau da, egitateen taula eta dimentsio asko eta askoko taulak.

Baina ez du ondo funtzionatzen ClickHousen. Bi arrazoi daude:

• Lehenengoa ClickHouse-k ez duelako oso juntadura onak, hau da, juntaketak badaude, baina txarrak dira. Txarra berriz.
• Bigarrena da taulak ez daudela eguneratzen. Normalean, izar-zirkuitu inguruan dauden plaka hauetan zerbait aldatu behar da. Adibidez, bezeroaren izena, enpresaren izena, etab. Eta ez du funtzionatzen.

Eta hortik ateratzeko modu bat dago ClickHousen. bi ere bai:

• Lehenengoa hiztegien erabilera da. Kanpoko Hiztegiak da % 99ri izar-eskemaren arazoa konpontzen laguntzen duena, eguneratzeekin eta abarrekin.
• Bigarrena array-en erabilera da. Array-ek normalizazioarekin loturak eta arazoak kentzen laguntzen dute.

• Ez da batu behar.
• Berritu daiteke. 2018ko martxoaz geroztik, dokumenturik gabeko aukera bat agertu da (ez duzu hori dokumentazioan aurkituko) hiztegiak partzialki eguneratzeko, hau da, aldatu diren sarrerak. Praktikan, mahai bat bezalakoa da.
• Beti memorian, beraz, hiztegi batekin elkartzen da diskoan dagoen taula bat balitz baino azkarrago eta oraindik ez da egia cachean dagoenik, ziurrenik ez.

• Zuk ere ez duzu batu beharrik.
• Hau 1-askoren irudikapen trinkoa da.
• Eta nire ustez, arrayak geekentzat eginak daude. Hauek lambda funtzioak eta abar dira.

Hau ez da hitz gorrietarako. Oso funtzionalitate indartsua da, gauza asko oso modu sinple eta dotorean egiteko aukera ematen duena.

Array ebazten laguntzen duten adibide tipikoak. Adibide hauek nahiko sinpleak eta argiak dira:

• Bilatu etiketen arabera. Han traolak badituzu eta hashtag bidez mezu batzuk aurkitu nahi badituzu.
• Bilatu gako-balio bikoteen arabera. Balio bat duten atributu batzuk ere badaude.
• Beste zerbaitetara itzuli behar dituzun gakoen zerrendak gordetzea.

Zeregin horiek guztiak array gabe konpondu daitezke. Etiketak lerro batzuetan jar daitezke eta adierazpen erregular batekin edo aparteko taula batean hauta daitezke, baina gero elkarketak egin behar dituzu.

Eta ClickHousen, ez duzu ezer egin behar, nahikoa da hashtagentzako kate-matrizea deskribatzea edo gako-balio-sistemetarako habiaraturiko egitura bat egitea.

Egitura habiaratua agian ez da izen onena. Izenan parte komun bat eta erlazionatutako ezaugarri batzuk dituzten bi array dira.

Eta etiketa bidez bilatzea oso erraza da. Funtzio bat izan has, matrizeak elementu bat duela egiaztatzen duena. Denok, gure hitzaldiarekin zerikusia duten sarrera guztiak aurkitu ditugu.

Subid bidezko bilaketa pixka bat zailagoa da. Lehenik eta behin gakoaren indizea aurkitu behar dugu, eta ondoren indize honekin duen elementua hartu eta balio hori behar duguna dela egiaztatu. Hala ere, oso sinplea eta trinkoa da.

Dena lerro batean gordez gero idatzi nahiko zenukeen esamolde erregularra, lehenik eta behin, traketsa izango litzateke. Eta, bigarrenik, bi array baino askoz gehiago funtzionatu zuen.

Beste adibide bat. IDa gordetzen duzun array bat duzu. Eta izenetara itzul ditzakezu. Funtzioa arrayMap. Hau lambda funtzio tipikoa da. Lambda esamoldeak pasatzen dituzu hor. Eta ID bakoitzaren izenaren balioa ateratzen du hiztegitik.

Bilaketa modu berean egin daiteke. Elementuak zer bat datozen egiaztatzen duen funtzio predikatu bat pasatzen da.

Gauza hauek zirkuitua asko errazten dute eta arazo mordoa ebazten dute.

Baina aurrean dugun hurrengo arazoa, eta aipatu nahi dudana, kontsulta eraginkorrak dira.

• ClickHouse-k ez du kontsulta-planifikatzailerik. Erabat ez.
• Hala ere, kontsulta konplexuak oraindik planifikatu behar dira. Zein kasutan?
• Kontsultan elkartze anitz badaude, azpi-hautaketetan bilduko dituzu. Eta gauzatzeko ordenak garrantzia du.
• Eta bigarrena - eskaera banatzen bada. Kontsulta banatu batean, barruko azpi-hautaketa bakarrik exekutatzen baita banatuta, eta gainerako guztia konektatu eta bertan exekutatu duzun zerbitzari batera pasatzen da. Hori dela eta, batuketa askorekin (join) kontsultak banatu badituzu, orduan ordena aukeratu behar duzu.

Eta kasu sinpleagoetan ere, batzuetan, planifikatzailearen lana ere egin behar da eta kontsultak apur bat berridatzi.

Hona hemen adibide bat. Ezkerreko aldean lehen 5 herrialdeak erakusten dituen kontsulta dago. Eta 2,5 segundo behar ditu, nire ustez. Eta eskuinaldean, kontsulta bera, baina apur bat berridatzia. Katearen arabera taldekatu beharrean, teklaz (int) taldekatzen hasi ginen. Eta azkarragoa da. Eta gero hiztegi bat lotu dugu emaitzari. 2,5 segundoren ordez, eskaerak 1,5 segundo behar ditu. Hau ona da.

Antzeko adibide bat berridazketa-iragazkiekin. Hona hemen Errusiarentzako eskaera. 5 segundoz ibiltzen da. Berridazten badugu, berriro ere kate bat ez, Errusiarekin erlazionatutako gako horietako zenbaki batzuekin alderatzen badugu, askoz azkarragoa izango da.

Horrelako trikimailu asko daude. Eta dagoeneko azkar exekutatzen ari direla uste duzun kontsultak nabarmen bizkortzeko aukera ematen dute, edo, alderantziz, poliki. Are azkarrago egin daitezke.

• Gehienezko lana modu banatuan.
• Gutxieneko moten arabera ordenatzea, ints arabera egin nuen bezala.
• Elkarketarik (join), hiztegirik badago, orduan hobe da azken aukera gisa egitea, datuak gutxienez partzialki taldekatuta dituzunean, batzeko eragiketa edo hiztegi-deia aldiz gutxiago deituko da eta azkarragoa izango da. .
• Iragazkiak ordezkatzea.

Badira beste teknika batzuk, eta ez nik bakarrik frogatu ditudanak. Eta horiek guztiek batzuetan nabarmen bizkortu dezakete kontsulten exekuzioa.

Goazen hurrengo adibidera. AEBetako X konpainia. Zer egiten ari da?

Zeregin bat zegoen:

• Publizitate-transakzioen lineaz kanpo lotzea.
• Lotura-eredu desberdinak modelatzea.

Zein da eszenatokia?

Bisitari arrunt bat etortzen da gunera, adibidez, hilean 20 aldiz iragarki ezberdinetatik, edo horrela batzuetan iragarkirik gabe etortzen da, gune hau gogoratzen duelako. Produktu batzuk begiratzen ditu, saskian sartzen ditu, saskitik ateratzen ditu. Eta, azkenean, zerbait erosten da.

Arrazoizko galderak: "Nork ordaindu behar du publizitatea, behar izanez gero?" eta “Zer publizitatek eragin zion, baldin bada?”. Hau da, zergatik erosi zuen eta nola lortu pertsona hau bezalako jendeak ere erostera?

Arazo hau konpontzeko, webgunean gertatzen diren gertaerak modu egokian konektatu behar dituzu, hau da, nolabait haien arteko konexioa sortu. Ondoren, DWHra bidaltzen dira aztertzera. Eta analisi horretan oinarrituta, eraiki nork eta zer iragarkiak erakutsiko dituen ereduak.

Iragarki-transakzio bat erlazionatutako erabiltzaile-gertaera multzo bat da, iragarki bat erakustetik hasten dena, gero zerbait gertatzen da, gero agian erosketa bat eta gero erosketak egon daitezke erosketa batean. Adibidez, hau mugikorretarako aplikazio bat edo mugikorrentzako joko bat bada, normalean aplikazioaren instalazioa doan egiten da, eta zerbait egiten bada, horretarako dirua behar da. Eta zenbat eta gehiago gastatu pertsona batek aplikazioan, orduan eta balio handiagoa du. Baina horretarako dena konektatu behar duzu.

Lotura eredu asko daude.

Ezagunenak hauek dira:

• Azken interakzioa, non interakzioa klik edo inpresioa den.
• Lehen interakzioa, hau da, pertsona bat gunera eraman zuen lehen gauza.
• Konbinazio lineala - denak berdin.
• Atenuazioa.
• Eta abar.

Eta nola funtzionatu zuen dena lehenik eta behin? Runtime eta Cassandra zeuden. Cassandra transakzioen biltegiratze gisa erabiltzen zen, hau da, erlazionatutako transakzio guztiak bertan gordetzen ziren. Eta Runtime-n gertaeraren bat etortzen denean, adibidez, orrialderen bat edo beste zerbait erakusten, orduan eskaera bat egin zitzaion Cassandrari - ba al dago pertsona hori ala ez. Ondoren, horri dagozkion transakzioak lortu ziren. Eta lotura egin zen.

Eta eskaerak transakzio ID bat badu zortea bada, erraza da. Baina normalean zorterik ez. Horregatik, beharrezkoa zen azken transakzioa edo azken klikarekin egindako transakzioa aurkitzea, etab.

Eta oso ondo funtzionatu zuen dena, betiere koadernatzea azken klikera arte. Egunean, demagun, 10 milioi klik daudelako, hilean 300 milioi, hilabete baterako leiho bat ezartzen badugu. Eta Cassandran dena memorian egon behar denez azkar exekutatzeko, Runtimeak azkar erantzun behar duelako, 10-15 zerbitzari inguru behar zituen.

Eta transakzio bat pantailarekin lotu nahi zutenean, berehala ez zen hain dibertigarria izan. Eta zergatik? Ikusten da 30 aldiz ekitaldi gehiago gorde behar direla. Eta, horren arabera, 30 aldiz zerbitzari gehiago behar dituzu. Eta ematen du hau figura astronomiko moduko bat dela. Loturak egiteko 500 zerbitzari edukitzea, Runtime-n zerbitzariak nabarmen gutxiago egon arren, okerreko zifra hau da. Eta zer egin pentsatzen hasi ziren.

Eta ClickHousera joan ginen. Eta nola egin ClickHousen? Lehen begiratuan, badirudi hau anti-ereduen multzoa dela.

• Transakzioa hazten da, gero eta gertaera gehiago lotzen ditugu, hau da, aldagarria da, eta ClickHouse-k ez du oso ondo funtzionatzen objektu aldagarriekin.
• Bisitari bat gurera etortzen denean, bere transakzioak atera behar ditugu gakoaren bidez, bere bisitaren IDaren arabera. Hau ere puntu kontsulta bat da, ez dute hori egiten ClickHousen. Normalean ClickHousek... eskaneatu handiak ditu, baina hemen erregistro batzuk lortu behar ditugu. Antipatroi bat ere.
• Horrez gain, transakzioa json-en zegoen, baina ez zuten berridatzi nahi, beraz, json modu desegituratu batean gorde nahi zuten, eta behar izanez gero, zerbait atera. Eta hau ere antipatroi bat da.

Hau da, antipatroi multzo bat.

Baina, hala ere, oso ondo funtzionatzen zuen sistema bat sortu zen.

Zer egin zen? ClickHouse agertu zen, zeinetara erregistroak botatzen ziren, erregistroetan banatuta. ClickHouse-ren erregistroak jaso dituen zerbitzu egotzi bat agertu da. Horren ostean, sarrera bakoitzeko, bisitaren IDaren arabera, oraindik prozesatu ez ziren transakzioak eta argazki gehigarriak jaso nituen, hau da, dagoeneko konektatutako transakzioak, aurreko lanaren emaitza alegia. Dagoeneko logika egin nuen, transakzio zuzena aukeratu nuen, gertaera berriak lotu nituen. Berriro saioa hasi da. Erregistroa ClickHousera itzuli zen, hau da, etengabe ziklikoa den sistema da. Eta gainera, DWHra joan nintzen bertan aztertzera.

Forma honetan ez zuen oso ondo funtzionatu. Eta ClickHouse-ri errazago egiteko, bisitaren IDaren araberako eskaera bat zegoenean, eskaera horiek 1-000 bisita IDen blokeetan multzokatu zituzten eta 2-000 pertsonentzako transakzio guztiak atera zituzten. Eta gero dena funtzionatu zuen.

ClickHouse barrura begiratzen baduzu, 3 mahai nagusi baino ez daude hori guztia zerbitzatzen dutenak.

Erregistroak kargatzen diren lehenengo taula, eta erregistroak ia prozesatu gabe kargatzen dira.

Bigarren mahaia. Materializatutako ikuspegiaren bidez, erregistro horietatik, oraindik egotzi gabeko gertaerak, hau da, zerikusirik ez dutenak, hozka egin ziren. Eta materializatutako ikuspegiaren bidez, transakzioak erregistro horietatik atera ziren argazki bat sortzeko. Hau da, materializatutako ikuspegi berezi batek argazki bat eraiki zuen, hots, transakzioaren azken metatutako egoera.

Hona hemen SQLn idatzitako testua. Bertan gauza garrantzitsu batzuk komentatu nahiko nituzke.

Lehenengo gauza garrantzitsua ClickHouse-n json-etik zutabeak eta eremuak ateratzeko gaitasuna da. Hau da, ClickHouse-k json-ekin lan egiteko metodo batzuk ditu. Oso-oso primitiboak dira.

visitParamExtractInt-ek json-etik atributuak ateratzeko aukera ematen du, hau da, lehen hit-ak funtzionatzen du. Eta modu honetan transakzio ID atera dezakezu edo bisita ID. Oraingoan.

Bigarrenik, eremu materializatu delikatua erabiltzen da hemen. Zer esan nahi du? Horrek esan nahi du ezin duzula taulan sartu, hau da, ez da txertatzen, txertatzean kalkulatzen eta gordetzen da. Itsatsi egiten duzunean, ClickHousek egiten du lana. Eta gero behar duzuna jsonetik aterata dago jada.

Kasu honetan, ikuspegi materializatua errenkada gordinarentzat da. Eta ia erregistro gordinak dituen lehen taula erabiltzen da. Eta zer egiten du? Lehenik eta behin, sailkapena aldatzen du, hau da, ordenatzea orain bisitaren IDaren arabera doa, bere transakzioa azkar atera behar dugulako pertsona zehatz bati.

Bigarren gauza garrantzitsua index_granularity da. MergeTree ikusi baduzu, normalean 8 izan ohi da index_granularity lehenespenez. Zer da hau? Hau indizearen urritasun parametroa da. ClickHousen indizea urria da, ez ditu inoiz sarrera guztiak indexatzen. 192 behin egiten du hori.Eta ona da datu asko kalkulatu behar direnean, baina txarra gutxi denean, gainkostu handia baitago. Eta indizearen granulartasuna murrizten badugu, gainkostua murrizten dugu. Ezin da bakarrera murriztu, agian memoria nahikorik ez egotea. Indizea memorian gordetzen da beti.

Snapshot-ek beste ClickHouse ezaugarri interesgarri batzuk ere erabiltzen ditu.

Lehenik eta behin, AggregatingMergeTree da. Eta AggregatingMergeTree-k argMax gordetzen du, hau da, azken denbora-zigiluari dagokion transakzioaren egoera da. Transakzioak uneoro sortzen dira bisitari jakin baterako. Eta transakzio honen azken egoeran, gertaera bat gehitu dugu eta egoera berri bat dugu. ClickHouse sakatu zuen berriro. Eta argMax-en bidez materializatutako ikuspegi honetan, beti lor dezakegu uneko egoera.

• Lotura "desakoplatuta" dago Runtimetik.
• Hilero gehienez 3 milioi transakzio gordetzen eta prozesatzen dira. Hau Cassandra-n zegoena baino magnitude ordena bat gehiago da, hau da, transakzio-sistema tipiko batean.
• 2x5 ClickHouse zerbitzarien multzoa. 5 zerbitzari eta zerbitzari bakoitzak erreplika bat du. Hau Cassandra-n zegoena baino txikiagoa da kliketan oinarritutako atribuzioa egiteko, eta hemen inpresioak oinarritzen ditugu. Hau da, zerbitzari kopurua 30 aldiz handitu beharrean, murriztea lortu zuten.

Eta azken adibidea Y finantza konpainia da, zeinak akzioen prezioen aldaketen korrelazioak aztertu zituen.

Eta zeregina izan zen:

• Gutxi gorabehera 5 akzio daude.
• 100 milisegundoko aurrekontuak ezagutzen dira.
• Datuak 10 urtean pilatu dira. Dirudienez, enpresa batzuentzat gehiago, beste batzuentzat gutxiago.
• Gutxi gorabehera 100 milioi errenkada daude guztira.

Eta beharrezkoa zen aldaketen korrelazioa kalkulatzea.

Hona hemen bi akzio eta haien aurrekontuak. Bata gora eta bestea igotzen bada, korrelazio positiboa da hau, hau da, bata gora eta bestea. Bata gora egiten badu, grafikoaren amaieran bezala, eta bestea behera egiten badu, korrelazio negatiboa da hau, hau da, bat igotzen denean, bestea jaisten da.

Elkarren arteko aldaketa horiek aztertuta, finantza-merkatuan iragarpenak egin daitezke.

Baina zeregina zaila da. Zer egiten da horretarako? 100 milioi erregistro dauzkagu: denbora, stocka eta prezioa. Lehen 100 milioi aldiz kalkulatu behar dugu prezio-algoritmoaren exekuzio-aldea. RunningDifference bi kateen arteko aldea sekuentzialki kalkulatzen duen ClickHouse-ko funtzio bat da.

Eta horren ondoren, korrelazioa kalkulatu behar duzu, eta bikote bakoitzeko korrelazioa kalkulatu behar da. 5 akziorako, bikoteak 000 milioi dira. Eta hau asko da, hau da, 12,5 aldiz beharrezkoa da halako korrelazio funtzio bat kalkulatzea.

Eta norbaitek ahaztu badu, ͞x eta ͞y xake mate bat da. laginketaren itxaropena. Hau da, beharrezkoa da erroak eta batuketak kalkulatzea ez ezik, batuketa horien barruan batuketa bat gehiago ere egitea. Kalkulu pila bat 12,5 milioi aldiz egin behar dira, eta orduen arabera taldekatuta ere bai. Ordu asko ere baditugu. Eta 60 segundotan egin behar duzu. Broma bat da.

Beharrezkoa zen nolabait behintzat denbora edukitzea, honek guztiak oso-oso poliki funtzionatu baitzuen ClickHouse etorri aurretik.

Hadoop-en, Spark-en, Greenplum-en kalkulatzen saiatu ziren. Eta hori guztia oso motela edo garestia zen. Hau da, nolabait kalkulatzea posible zen, baina gero garestia zen.

Eta gero ClickHouse etorri zen eta gauzak askoz hobetu ziren.

Gogorarazten dizut arazo bat daukagula datuen tokiarekin, korrelazioak ezin direlako lokalizatu. Ezin ditugu datu batzuk zerbitzari batean jarri, beste batzuk beste batean eta kalkulatu, datu guztiak nonahi izan behar ditugu.

Zer egin zuten? Hasieran, datuak lokalizatuta daude. Zerbitzari bakoitzak akzio multzo jakin baten prezioei buruzko datuak gordetzen ditu. Eta ez dira gainjartzen. Hori dela eta, logReturn paraleloan eta independentean kalkula daiteke, hau guztia orain arte paralelo eta banatuta gertatzen da.

Orduan, datu hauek murriztea erabaki genuen, adierazkortasuna galdu gabe. Murriztu matrizeak erabiliz, hau da, denbora-tarte bakoitzerako, egin izakinen eta prezioen array bat. Beraz, datu-espazio askoz gutxiago hartzen du. Eta lan egiteko apur bat errazagoa da. Eragiketa ia paraleloak dira, hau da, partzialki paraleloan irakurtzen dugu eta gero zerbitzarian idazten dugu.

Horren ondoren, errepikatu daiteke. "r" hizkiak datu hauek errepikatu ditugula esan nahi du. Hau da, hiru zerbitzarietan datu berdinak ditugu - hauek dira arrayak.

Eta gero kalkulatu behar diren 12,5 milioi korrelazio multzo honetako script berezi batekin, paketeak egin ditzakezu. Hau da, 2 zeregin 500 bikote korrelaziorekin. Eta zeregin hori ClickHouse zerbitzari zehatz batean kalkulatu behar da. Datu guztiak ditu, datuak berdinak direlako eta sekuentzialki kalkula ditzakeelako.

Berriro ere, hau da itxura. Lehenik eta behin, datu guztiak ditugu egitura honetan: denbora, akzioak, prezioa. Gero logReturn kalkulatu dugu, hau da, egitura bereko datuak, baina prezioaren ordez logReturn dugu jada. Ondoren, berriz egin ziren, hau da, izakinetarako eta prezioetarako denbora eta groupArray lortu genuen. Erreplikatua. Eta horren ostean, zeregin mordo bat sortu eta ClickHouse-ra elikatu genituen, zenbatu zezan. Eta funtzionatzen du.

Kontzeptuaren frogan, ataza azpiataza bat zen, hau da, datu gutxiago hartu ziren. Eta hiru zerbitzari bakarrik.

Lehenengo bi fase hauek: Log_return kalkulatzea eta arrayetan biltzea ordubete inguru behar izan zuten.

Eta korrelazioaren kalkulua 50 ordu ingurukoa da. Baina 50 ordu ez dira nahikoa, asteetan lan egiten zutelako. Arrakasta handia izan zen. Eta zenbatzen baduzu, 70 aldiz segundoko dena zenbatu zen kluster honetan.

Baina garrantzitsuena da sistema hau ia botilarik gabe dagoela, hau da, ia linealki eskalatzen duela. Eta egiaztatu zuten. Ondo handitu da.

• Eskema egokia borrokaren erdia da. Eta eskema egokia ClickHouse teknologia guztiak erabiltzea da.
• Summing/AggregatingMergeTrees egoeraren argazki bat kasu berezi gisa bateratzeko edo kontuan hartzeko aukera ematen duten teknologiak dira. Eta gauza asko errazten ditu.
• Ikuspegi materializatuak indize muga bakarra gainditzeko aukera ematen dizu. Agian ez nuen oso argi esan, baina erregistroak kargatzean, erregistro gordinak taulan zeuden indize batekin, eta atributuen erregistroak taulan zeuden, hau da, datu berdinak, soilik iragaziak, baina indizea guztiz zegoen. beste batzuk. Datu berdinak dirudite, baina ordenazio ezberdina. Eta Materialized Views aukera ematen dizu, behar izanez gero, ClickHouse muga hori saihesteko.
• Murriztu indizearen granulartasuna puntu-kontsultetarako.
• Eta banatu datuak modu adimentsuan, saiatu datuak zerbitzarian ahalik eta gehien lokalizatzen. Eta saiatu eskaerek ahal den neurrian lokalizazioa ere erabiltzen dutela ziurtatzen.

Eta diskurtso labur hau laburbilduz, esan dezakegu ClickHousek orain irmo okupatu duela datu-base komertzialen nahiz kode irekiko datu-baseen lurraldea, hau da, analitikarako bereziki. Ezin hobeto moldatzen da paisaia honetan. Eta are gehiago, poliki-poliki beste batzuk kanporatzen hasten da, ClickHouse duzunean ez duzulako InfiniDB behar. Baliteke Vertika laster behar ez izatea SQL euskarria normala egiten badute. Gozatu!

-Eskerrik asko erreportajeagatik! Oso interesgarria! Apache Phoenix-ekin konparaziorik egon al zen?

Ez, ez diot inori konparatzen entzun. Gu eta Yandex saiatzen gara ClickHouse datu-base desberdinekin egindako konparazio guztien jarraipena egiten. Zeren eta bat-batean zerbait ClickHouse baino azkarragoa bihurtzen bada, Lesha Milovidovek ezin du gauez lo egin eta azkar bizkortzen hasten da. Ez dut halako konparaziorik entzun.

• (Aleksey Milovidov) Apache Phoenix Hbasek bultzatutako SQL motor bat da. Hbase gako-balioaren lan-egoerarako da batez ere. Bertan, lerro bakoitzean, izen arbitrarioak dituzten zutabe kopuru arbitrarioa egon daiteke. Hau Hbase, Cassandra bezalako sistemei buruz esan daiteke. Eta, hain zuzen, kontsulta analitiko astunak dira normalean funtzionatuko ez dutenak. Edo pentsa dezakezu ondo funtzionatzen dutela ClickHouse-rekin esperientziarik izan ez baduzu.

• Eskerrik asko

  • Arratsalde on Dagoeneko nahiko interesatzen zait gai hau, azpisistema analitikoa dudalako. Baina ClickHouse-ra begiratzen dudanean, ClickHouse gertaeren analisirako oso egokia dela iruditzen zait, aldagarria. Eta mahai handi mordo batekin negozio datu asko aztertu behar baditut, orduan ClickHouse, ulertzen dudanez, ez al da oso egokia niretzat? Batez ere aldatzen badira. Zuzena al da edo ba al dago hori ezeztatzeko adibiderik?

  • Hau zuzena da. Eta hori gertatzen da datu-base analitiko espezializatu gehienetan. Aldagarriak diren mahai handi bat edo gehiago daudelako eta poliki-poliki aldatzen diren txiki askotarako egokituta daude. Hau da, ClickHouse ez da Oracle bezalakoa, non dena jarri dezakezu eta oso kontsulta konplexuak eraiki ditzakezu. ClickHouse modu eraginkorrean erabiltzeko, ClickHousen ondo funtzionatzen duen eskema bat eraiki behar duzu. Hau da, gehiegizko normalizazioa saihestu, hiztegiak erabili, lotura luze gutxiago egiten saiatu. Eta eskema horrela eraikitzen bada, antzeko negozio-zereginak ClickHousen ebatzi daitezke datu-base erlazional tradizionalean baino askoz eraginkorrago.

Eskerrik asko erreportajeagatik! Azken finantza kasuari buruzko galdera bat daukat. Analitikoak zituzten. Nola igo eta jaisten ziren alderatu beharra zegoen. Eta ulertzen dut sistema analitika honetarako bereziki eraiki duzula? Bihar, adibidez, datu horiei buruzko beste txosten bat behar badute, eskema berriro eraiki eta datuak igo behar al dituzte? Hau da, eskaera lortzeko nolabaiteko aurreprozesamendu bat egitea?

Jakina, hau da ClickHouse-ren erabilera oso zeregin zehatz baterako. Tradizionalki Hadoop barruan konpondu liteke. Hadoopentzat, zeregin ezin hobea da. Baina Hadoop-en oso motela da. Eta nire helburua da erakustea ClickHouse-k modu guztiz desberdinekin konpondu ohi diren zereginak ebatzi ditzakeela, baina aldi berean askoz eraginkorrago egin dezakeela. Zeregin zehatz baterako egokituta dago. Argi dago antzeko zerbaiten arazoren bat baldin badago, orduan antzera konpon daitekeela.

Garbi dago. 50 ordu prozesatu zirela esan duzu. Hasiera-hasieratik al da, noiz kargatu dituzu datuak edo emaitzak?

Bai bai.

Ados eskerrik asko.

Hau 3 zerbitzari-kluster batean dago.

Zorionak! Eskerrik asko erreportajeagatik! Oso interesgarria da dena. Ez dut pixka bat galdetuko funtzionalitateari buruz, baizik eta ClickHouse-ren erabilerari buruz egonkortasunari dagokionez. Hau da, bazenuen, zaharberritu behar zenuten? Nola jokatzen du ClickHousek kasu honetan? Eta gertatu al zen zuk ere erreplika bat izatea? Adibidez, ClickHouse-rekin arazo bat aurkitu dugu oraindik bere mugatik ateratzen denean eta erortzen denean.

Jakina, ez dago sistema idealik. Eta ClickHousek ere bere arazoak ditu. Baina entzun al duzu Yandex.Metricak denbora luzez funtzionatzen ez duela? Seguruenik ez. 2012-2013tik fidagarritasunez funtzionatzen du ClickHouse-n. Gauza bera esan dezaket nire esperientziaz. Ez dugu inoiz hutsegite osoa izan. Gauza partzial batzuk gerta litezke, baina ez ziren inoiz negozioari larriki eragiteko adina kritikoak izan. Ez zen inoiz gertatu. ClickHouse nahiko fidagarria da eta ez da ausaz huts egiten. Ez duzu horretaz kezkatu behar. Ez da gauza gordina. Hori frogatu dute enpresa askok.

Kaixo! Datu-eskema berehala pentsatu behar duzula esan duzu. Zer gertatuko balitz? Nire datuak isurtzen eta isurtzen ari dira. Sei hilabete igarotzen dira, eta ulertzen dut ezinezkoa dela horrela bizitzea, datuak berriro igo behar ditut eta haiekin zerbait egin.

Hori, noski, zure sistemaren araberakoa da. Ia geldialdirik gabe egiteko hainbat modu daude. Esaterako, Ikuspegi materializatu bat sor dezakezu eta bertan datu-egitura ezberdin bat egiteko, modu berezian mapatu badaiteke. Hau da, ClickHouse erabiliz mapak egiteko aukera ematen badu, hau da, gauza batzuk atera, lehen gakoa aldatu, partizioa aldatu, orduan Ikuspegi Materializatu bat egin dezakezu. Gainidatzi datu zaharrak bertan, berriak automatikoki idatziko dira. Eta gero, besterik gabe, aldatu Ikuspegi materializatua erabiltzera, gero erregistroa aldatu eta mahai zaharra hil. Hau, oro har, geldiunerik gabeko metodoa da.

Eskerrik asko.

Iturria: www.habr.com