Teorija i praksa korištenja ClickHousea u stvarnim aplikacijama. Alexander Zaitsev (2018.)

Unatoč činjenici da sada ima mnogo podataka gotovo posvuda, analitičke baze podataka još uvijek su prilično egzotične. Slabo su poznati, a još gore ih je moguće učinkovito koristiti. Mnogi nastavljaju "jesti kaktus" s MySQL ili PostgreSQL, koji su dizajnirani za druge scenarije, pate s NoSQL ili preplaćuju za komercijalna rješenja. ClickHouse mijenja pravila igre i značajno snižava prag za ulazak u svijet analitičkih DBMS-a.

Izvještaj s BackEnd Conf 2018. objavljujemo uz dopuštenje predavača.

Tko sam ja i zašto govorim o ClickHouseu? Ja sam direktor razvoja u LifeStreetu, koji koristi ClickHouse. Također, ja sam osnivač Altinityja. To je Yandexov partner koji promovira ClickHouse i pomaže Yandexu učiniti ClickHouse uspješnijim. Također spreman podijeliti znanje o ClickHouseu.

A ja nisam brat Petje Zajceva. Često me o tome pitaju. Ne, nismo braća.

“Svi znaju” da ClickHouse:

• Vrlo brzo,
• Vrlo udobno
• Koristi se u Yandexu.

Nešto manje je poznato u kojim tvrtkama se i kako koristi.

Reći ću vam zašto, gdje i kako se koristi ClickHouse, osim za Yandex.

Reći ću vam kako se uz pomoć ClickHousea rješavaju određeni zadaci u različitim tvrtkama, koje ClickHouse alate možete koristiti za svoje zadatke i kako su se koristili u različitim tvrtkama.

Odabrao sam tri primjera koji prikazuju ClickHouse iz različitih kutova. Mislim da će biti zanimljivo.

Prvo pitanje je: “Zašto nam treba ClickHouse?”. Čini se da je to prilično očito pitanje, ali postoji više od jednog odgovora na njega.

• Prvi odgovor je za izvedbu. ClickHouse je vrlo brz. Analitika na ClickHouseu također je vrlo brza. Često se može koristiti tamo gdje je nešto drugo jako sporo ili jako loše.
• Drugi odgovor je trošak. I prije svega, trošak skaliranja. Na primjer, Vertica je apsolutno sjajna baza podataka. Radi vrlo dobro ako nemate puno terabajta podataka. Ali kada se radi o stotinama terabajta ili petabajta, cijena licence i podrške ide u prilično značajan iznos. I skupo je. A ClickHouse je besplatan.
• Treći odgovor je operativni trošak. Ovo je malo drugačiji pristup. RedShift je odličan analog. Na RedShiftu možete vrlo brzo donijeti odluku. Radit će dobro, ali istovremeno ćete svaki sat, svaki dan i svaki mjesec prilično skupo plaćati Amazonu jer se radi o značajno skupoj usluzi. Google BigQuery također. Ako ga je netko koristio, onda zna da tamo možete pokrenuti nekoliko zahtjeva i odjednom dobiti račun na stotine dolara.

ClickHouse nema tih problema.

Gdje se sada koristi ClickHouse? Osim Yandexa, ClickHouse se koristi u hrpi različitih tvrtki i tvrtki.

• Prije svega, ovo je analitika web aplikacije, tj. ovo je slučaj korištenja koji je došao iz Yandexa.
• Mnoge AdTech tvrtke koriste ClickHouse.
• Brojne tvrtke koje trebaju analizirati zapisnike transakcija iz različitih izvora.
• Nekoliko tvrtki koristi ClickHouse za praćenje sigurnosnih zapisa. Učitavaju ih na ClickHouse, prave izvješća i dobivaju rezultate koji su im potrebni.
• Kompanije ga počinju koristiti u financijskim analizama, tj. postupno se ClickHouseu približavaju i velike tvrtke.
• plamen oblaka. Ako netko prati ClickHouse, onda je vjerojatno čuo ime ove tvrtke. Ovo je jedan od bitnih doprinosa iz zajednice. I imaju vrlo ozbiljnu ClickHouse instalaciju. Na primjer, napravili su Kafka Engine za ClickHouse.
• Telekomunikacijske tvrtke počele su koristiti. Nekoliko tvrtki koristi ClickHouse ili kao dokaz koncepta ili već u proizvodnji.
• Jedna tvrtka koristi ClickHouse za praćenje proizvodnih procesa. Testiraju mikro krugove, otpisuju hrpu parametara, ima oko 2 karakteristika. I onda analiziraju je li igra dobra ili loša.
• Blockchain analitika. Postoji takva ruska tvrtka kao Bloxy.info. Ovo je analiza ethereum mreže. To su učinili i na ClickHouseu.

A veličina nije bitna. Postoje mnoge tvrtke koje koriste jedan mali poslužitelj. I on im omogućuje da riješe svoje probleme. Čak i više tvrtki koristi velike klastere od mnogo poslužitelja ili desetaka poslužitelja.

A ako pogledate zapise, onda:

• Yandex: 500+ poslužitelja, tamo pohranjuju 25 milijardi zapisa dnevno.
• LifeStreet: 60 poslužitelja, približno 75 milijardi zapisa dnevno. Ima manje poslužitelja, više zapisa nego u Yandexu.
• CloudFlare: 36 poslužitelja, spremaju 200 milijardi zapisa dnevno. Imaju još manje poslužitelja i pohranjuju još više podataka.
• Bloomberg: 102 poslužitelja, oko trilijun unosa dnevno. Rekorder.

Geografski, ovo je također puno. Ova karta prikazuje toplinsku kartu gdje se ClickHouse koristi u svijetu. Tu se jasno ističu Rusija, Kina, Amerika. Malo je europskih zemalja. I ima 4 klastera.

Ovo je komparativna analiza, nema potrebe tražiti apsolutne brojke. Ovo je analiza posjetitelja koji čitaju materijale na engleskom jeziku na web stranici Altinity, jer tamo nema onih koji govore ruski. A Rusija, Ukrajina, Bjelorusija, odnosno ruskojezični dio zajednice, to su najbrojniji korisnici. Zatim dolaze SAD i Kanada. Kina itekako sustiže. Tamo Kine prije šest mjeseci gotovo da i nije bilo, sada je Kina već prestigla Europu i nastavlja rasti. Stara Europa također ne zaostaje, a lider u korištenju ClickHousea je, čudno, Francuska.

Zašto sve ovo pričam? Pokazati da ClickHouse postaje standardno rješenje za analizu velikih podataka i da se već koristi na mnogim mjestima. Ako ga koristite, u pravom ste trendu. Ako ga još ne koristite, onda se ne možete bojati da ćete ostati sami i da vam nitko neće pomoći, jer mnogi to već rade.

Ovo su primjeri stvarne upotrebe ClickHousea u nekoliko tvrtki.

• Prvi primjer je oglasna mreža: migracija s Vertice na ClickHouse. I znam nekoliko tvrtki koje su prešle s Vertice ili su u procesu tranzicije.
• Drugi primjer je transakcijska pohrana na ClickHouseu. Ovo je primjer izgrađen na antiuzorcima. Ovdje se radi sve ono što se ne bi trebalo raditi u ClickHouseu po savjetu programera. I to je tako učinkovito da djeluje. I radi mnogo bolje od tipičnog transakcijskog rješenja.
• Treći primjer je distribuirano računalstvo na ClickHouseu. Bilo je pitanje kako se ClickHouse može integrirati u Hadoop ekosustav. Pokazat ću primjer kako je tvrtka napravila nešto slično kontejneru za smanjenje karte na ClickHouseu, praćenju lokalizacije podataka itd., kako bi izračunala vrlo netrivijalan zadatak.

• LifeStreet je tvrtka za oglašavanje koja ima svu tehnologiju koja dolazi s oglasnom mrežom.
• Bavi se optimizacijom oglasa, programmatic biddingom.
• Mnoštvo podataka: oko 10 milijardi događaja dnevno. Pritom se događaji tamo mogu podijeliti u nekoliko poddogađaja.
• Postoji mnogo klijenata ovih podataka, a to nisu samo ljudi, mnogo više - to su različiti algoritmi koji se bave programskim licitiranjem.

Tvrtka je prošla dug i trnovit put. I pričao sam o tome na HighLoadu. Prvo se LifeStreet preselio s MySQL-a (uz kratko zaustavljanje u Oracleu) na Verticu. I možete pronaći priču o tome.

I sve je bilo jako dobro, ali brzo je postalo jasno da podaci rastu i da je Vertica skupa. Stoga su se tražile razne alternative. Neki od njih su navedeni ovdje. I zapravo smo radili proof of concept ili ponekad testiranje performansi gotovo svih baza podataka koje su bile dostupne na tržištu od 13. do 16. godine i bile su približno odgovarajuće u smislu funkcionalnosti. Također sam govorio o nekima od njih na HighLoadu.

Zadatak je prije svega bio migrirati s Vertice jer su podaci rasli. I eksponencijalno su rasli tijekom godina. Zatim su otišli na policu, ali svejedno. I predviđajući taj rast, poslovne zahtjeve za količinom podataka na kojima treba raditi nekakvu analitiku, bilo je jasno da će se uskoro govoriti o petabajtima. A plaćanje petabajta je već jako skupo, pa smo tražili alternativu kamo otići.

Gdje ići? I dugo vremena uopće nije bilo jasno kamo ići, jer s jedne strane postoje komercijalne baze podataka, čini se da dobro rade. Neki rade gotovo jednako dobro kao Vertica, neki lošije. Ali svi su skupi, ništa jeftinije i bolje se nije moglo naći.

S druge strane, postoje open source rješenja kojih nema baš puno, odnosno za analitiku se mogu nabrojati na prste. I besplatni su ili jeftini, ali spori. I često im nedostaje potrebna i korisna funkcionalnost.

I nije se imalo što spojiti ono dobro što je u komercijalnim bazama i sve ono besplatno što je u open sourceu.

Nije bilo ništa dok, neočekivano, Yandex nije izvukao ClickHouse, kao mađioničar iz šešira, kao zec. I to je bila neočekivana odluka, još uvijek postavljaju pitanje: "Zašto?", Ali ipak.

I odmah u ljeto 2016. počeli smo gledati što je ClickHouse. I pokazalo se da ponekad može biti brži od Vertice. Testirali smo različite scenarije na različite zahtjeve. A ako je upit koristio samo jednu tablicu, odnosno bez spajanja (join), tada je ClickHouse bio duplo brži od Vertice.

Nisam bio previše lijen i neki dan sam pogledao Yandex testove. I tamo je isto: ClickHouse je duplo brži od Vertice pa se o tome često priča.

Ali ako postoje spojevi u upitima, onda sve ispada ne baš nedvosmisleno. A ClickHouse može biti dvostruko sporiji od Vertice. A ako malo ispravite zahtjev i prepišete ga, onda su približno jednaki. Nije loše. I besplatno.

I nakon što su dobili rezultate testa i pogledali ga iz različitih kutova, LifeStreet je otišao u ClickHouse.

Ovo je 16. godina, podsjećam. Bilo je to kao u šali o miševima koji su plakali i bokali se, ali su nastavili jesti kaktus. I ovo je detaljno opisano, postoji video o tome itd.

Stoga neću o tome detaljnije, govorit ću samo o rezultatima i nekoliko zanimljivosti o kojima tada nisam govorio.

Rezultati su:

• Uspješna migracija i više od godinu dana sustav već radi u proizvodnji.
• Produktivnost i fleksibilnost su se povećale. Od 10 milijardi zapisa koje bismo mogli priuštiti pohraniti dnevno i to na kratko vrijeme, LifeStreet sada pohranjuje 75 milijardi zapisa dnevno i to može činiti 3 mjeseca ili više. Ako računate na vrhuncu, onda je to do milijun događaja u sekundi. Više od milijun SQL upita dnevno stiže u ovaj sustav, uglavnom od različitih robota.
• Unatoč tome što je za ClickHouse korišteno više poslužitelja nego za Verticu, uštedjelo se i na hardveru jer su u Vertici korišteni prilično skupi SAS diskovi. ClickHouse je koristio SATA. I zašto? Budući da je u Vertica umetak sinkroni. A za sinkronizaciju je potrebno da diskovi ne usporavaju previše, a i da mreža ne usporava previše, odnosno prilično skupa operacija. I u ClickHouseu umetanje je asinkrono. Štoviše, uvijek možete sve napisati lokalno, za to nema dodatnih troškova, pa se podaci mogu ubaciti u ClickHouse puno brže nego u Vertiku, čak i na sporijim diskovima. I čitanje je otprilike isto. Čitanje na SATA, ako su u RAID-u, onda je ovo sve dovoljno brzo.
• Nije ograničeno licencom, tj. 3 petabajta podataka u 60 poslužitelja (20 poslužitelja je jedna replika) i 6 trilijuna zapisa u činjenicama i agregacijama. U Vertici se ovako nešto ne može priuštiti.

Sada se okrećem praktičnim stvarima u ovom primjeru.

• Prva je učinkovita shema. Puno ovisi o shemi.
• Drugi je učinkovito generiranje SQL-a.

Tipičan OLAP upit je odabir. Neki od stupaca idu na grupiranje, neki od stupaca idu na agregatne funkcije. Postoji mjesto koje se može prikazati kao dio kocke. Cijela se grupa može smatrati projekcijom. I zato se zove multivarijatna analiza podataka.

I često je to modelirano u obliku zvjezdane sheme, kada postoji središnja činjenica i karakteristike te činjenice duž strana, duž zraka.

A što se tiče fizičkog dizajna, kako stane na stol, obično rade normalizirani prikaz. Možete denormalizirati, ali to je skupo na disku i nije baš učinkovito na upite. Stoga obično prave normalizirani prikaz, tj. tablicu činjenica i mnogo, mnogo dimenzijskih tablica.

Ali to ne radi dobro u ClickHouseu. Postoje dva razloga:

• Prvi je zato što ClickHouse nema baš dobre spojeve, tj. spojeva ima, ali su loši. Dok loše.
• Drugi je da se tablice ne ažuriraju. Obično u ovim pločama, koje su oko zvjezdanog kruga, treba nešto promijeniti. Na primjer, ime klijenta, naziv tvrtke itd. I ne ide.

I iz ovoga postoji izlaz u ClickHouseu. čak dva:

• Prvi je korištenje rječnika. Vanjski rječnici su ono što pomaže 99% riješiti problem sa shemom zvijezda, s ažuriranjima i tako dalje.
• Drugi je korištenje nizova. Nizovi također pomažu da se riješite spojeva i problema s normalizacijom.

• Nije potrebno pridruživanje.
• Mogućnost nadogradnje. Od ožujka 2018. pojavila se nedokumentirana mogućnost (nećete je pronaći u dokumentaciji) da se rječnici djelomično ažuriraju, tj. oni natuknici koji su se promijenili. Praktično, to je poput stola.
• Uvijek u memoriji, tako da spojevi s rječnikom rade brže nego da se radi o tablici koja je na disku i još nije činjenica da je u cacheu, najvjerojatnije nije.

• Ne trebaju vam ni pridruživanja.
• Ovo je kompaktni prikaz 1-prema-više.
• I po mom mišljenju, nizovi su napravljeni za geekove. To su lambda funkcije i tako dalje.

Ovo nije za crvene riječi. Ovo je vrlo moćna funkcionalnost koja vam omogućuje da radite mnoge stvari na vrlo jednostavan i elegantan način.

Tipični primjeri koji pomažu u rješavanju nizova. Ovi primjeri su jednostavni i dovoljno jasni:

• Pretraživanje po oznakama. Ako tamo imate hashtagove i želite pronaći neke postove po hashtagovima.
• Pretraživanje po parovima ključ-vrijednost. Postoje i neki atributi s vrijednošću.
• Pohranjivanje popisa ključeva koje trebate prevesti u nešto drugo.

Svi ovi zadaci mogu se riješiti bez nizova. Oznake se mogu staviti u neki red i odabrati regularnim izrazom ili u zasebnoj tablici, ali tada morate raditi spojeve.

A u ClickHouseu ne morate ništa učiniti, dovoljno je opisati niz nizova za hashtagove ili napraviti ugniježđenu strukturu za sustave ključ-vrijednost.

Ugniježđena struktura možda nije najbolji naziv. To su dva niza koji imaju zajednički dio u imenu i neke srodne karakteristike.

I vrlo je jednostavno pretraživati ​​po oznaci. Imati funkciju has, koji provjerava sadrži li niz element. Svi, pronašli smo sve unose koji se odnose na našu konferenciju.

Pretraživanje po subid-u je malo kompliciranije. Prvo trebamo pronaći indeks ključa, a zatim uzeti element s ovim indeksom i provjeriti je li ta vrijednost ono što nam treba. Međutim, vrlo je jednostavan i kompaktan.

Regularni izraz koji biste željeli napisati kada biste sve držali u jednom retku, bio bi, prvo, nespretan. I, drugo, radio je mnogo dulje od dva niza.

Još jedan primjer. Imate polje u koje pohranjujete ID. I možete ih prevesti u imena. Funkcija arrayMap. Ovo je tipična lambda funkcija. Tamo prosljeđujete lambda izraze. I ona iz rječnika izvlači vrijednost imena za svaki ID.

Pretraživanje se može izvršiti na isti način. Prosljeđuje se predikatna funkcija koja provjerava koji elementi odgovaraju.

Ove stvari uvelike pojednostavljuju sklop i rješavaju hrpu problema.

Ali sljedeći problem s kojim se suočavamo, a koji bih želio spomenuti, jesu učinkoviti upiti.

• ClickHouse nema planer upita. Apsolutno ne.
• Ipak, složene upite i dalje treba planirati. U kojim slučajevima?
• Ako postoji više spojeva u upitu, zamotajte ih u podselekte. Bitan je i redoslijed kojim se izvršavaju.
• A drugi - ako se zahtjev distribuira. Zato što se u distribuiranom upitu distribuirano izvršava samo najunutarnji pododabir, a sve ostalo se prosljeđuje jednom poslužitelju na koji ste se povezali i tamo ga izvršava. Stoga, ako ste distribuirali upite s mnogo spajanja (join), tada morate odabrati redoslijed.

A čak i u jednostavnijim slučajevima, ponekad je također potrebno obaviti posao planera i malo prepisati upite.

Evo primjera. Na lijevoj strani nalazi se upit koji prikazuje prvih 5 zemalja. I traje 2,5 sekunde, po mom mišljenju. A s desne strane, isti upit, ali malo prepisan. Umjesto grupiranja po nizu, počeli smo grupirati po ključu (int). I brže je. A onda smo s rezultatom povezali rječnik. Umjesto 2,5 sekunde, zahtjev traje 1,5 sekundu. Ovo je dobro.

Sličan primjer s filtrima za prepisivanje. Evo zahtjeva za Rusiju. Radi 5 sekundi. Ako ga prepišemo na takav način da ponovno ne uspoređujemo niz, već brojeve s nekim skupom onih ključeva koji se odnose na Rusiju, tada će biti mnogo brže.

Postoji mnogo takvih trikova. I omogućuju vam da značajno ubrzate upite za koje mislite da se već izvode brzo ili, obrnuto, rade sporo. Mogu se napraviti i brže.

• Maksimalni rad u distribuiranom načinu rada.
• Sortiranje po minimalnim tipovima, kao što sam ja radio po int.
• Ako postoje spojevi (join), rječnici, onda ih je bolje napraviti u krajnjem slučaju, kada već imate podatke barem djelomično grupirane, tada će se operacija spajanja ili poziv rječnika pozivati ​​manje puta i bit će brže .
• Zamjena filtera.

Postoje i druge tehnike, a ne samo one koje sam demonstrirao. I svi oni ponekad mogu značajno ubrzati izvršavanje upita.

Prijeđimo na sljedeći primjer. Tvrtka X iz SAD-a. Što ona radi?

Bio je zadatak:

• Offline povezivanje reklamnih transakcija.
• Modeliranje različitih modela uveza.

Kakav je scenarij?

Običan posjetitelj dođe na stranicu npr. 20 puta mjesečno s različitih reklama ili jednostavno tako ponekad dođe bez ikakve reklame, jer pamti ovu stranicu. Gleda neke proizvode, stavlja ih u košaricu, vadi iz košarice. I, na kraju, nešto se kupuje.

Razumna pitanja: "Tko bi trebao platiti oglašavanje, ako je potrebno?" i "Koje je oglašavanje utjecalo na njega, ako je uopće?". Odnosno, zašto je kupio i kako natjerati ljude poput ove osobe da također kupuju?

Da biste riješili ovaj problem potrebno je na pravi način povezati događaje koji se događaju na web stranici, odnosno na neki način izgraditi vezu među njima. Zatim se šalju na analizu u DWH. I na temelju te analize izradite modele kome i kakve oglase prikazivati.

Transakcija oglasa je skup povezanih korisničkih događaja koji počinju prikazivanjem oglasa, zatim se nešto dogodi, zatim možda kupnja, a zatim mogu postojati kupnje unutar kupnje. Na primjer, ako se radi o mobilnoj aplikaciji ili mobilnoj igrici, tada se obično instalacija aplikacije odvija besplatno, a ako se tamo nešto radi, za to može biti potreban novac. I što više osoba potroši u aplikaciji, to je ona vrjednija. Ali za ovo morate sve povezati.

Postoji mnogo modela vezanja.

Najpopularniji su:

• Zadnja interakcija, gdje je interakcija ili klik ili pojavljivanje.
• Prva interakcija, tj. prva stvar koja je osobu dovela na stranicu.
• Linearna kombinacija - sve jednako.
• Prigušenje.
• I tako dalje.

I kako je sve to uopće funkcioniralo? Postojali su Runtime i Cassandra. Cassandra je korištena kao pohrana transakcija, tj. u njoj su pohranjene sve povezane transakcije. I kada dođe neki događaj u Runtimeu, na primjer, pokaže se neka stranica ili nešto drugo, onda se uputi zahtjev Cassandri - postoji li takva osoba ili ne. Zatim su dobivene transakcije koje se na to odnose. I veza je uspostavljena.

A ako je sreća da zahtjev ima ID transakcije, onda je lako. Ali obično nema sreće. Dakle, bilo je potrebno pronaći zadnju transakciju ili transakciju sa zadnjim klikom itd.

I sve je radilo vrlo dobro sve dok je vezivanje bilo do zadnjeg klika. Jer ima recimo 10 milijuna klikova dnevno, 300 milijuna mjesečno, ako postavimo prozor za mjesec dana. A budući da u Cassandri sve mora biti u memoriji da bi brzo radilo, jer Runtime treba brzo reagirati, trebalo je oko 10-15 poslužitelja.

A kada su htjeli povezati transakciju s prikazom, odmah se pokazalo da nije tako zabavno. I zašto? Vidi se da treba pohraniti 30 puta više događaja. I, sukladno tome, trebate 30 puta više poslužitelja. I ispada da je to neka vrsta astronomske brojke. Zadržati do 500 poslužitelja kako bi se izvršilo povezivanje, unatoč činjenici da u Runtimeu ima znatno manje poslužitelja, onda je to neka vrsta krive brojke. I počeli su razmišljati što im je činiti.

I otišli smo u ClickHouse. A kako to učiniti na ClickHouseu? Na prvi pogled čini se da je riječ o skupu antišablona.

• Transakcija raste, na nju povezujemo sve više i više događaja, tj. promjenjiva je, a ClickHouse ne radi baš dobro s promjenjivim objektima.
• Kada nam dođe posjetitelj, moramo izvući njegove transakcije po ključu, po ID-u posjeta. Ovo je također točkasti upit, u ClickHouseu to ne rade. ClickHouse obično ima velike ...skenove, ali ovdje moramo dobiti neke zapise. Također antiuzorak.
• Osim toga, transakcija je bila u jsonu, ali ga nisu htjeli prepisati, pa su htjeli pohraniti json na nestrukturiran način, i ako je potrebno, izvući nešto iz njega. I ovo je također antiuzorak.

Odnosno skup antiuzoraka.

No ipak se pokazalo da je napravio sustav koji je jako dobro funkcionirao.

Što je učinjeno? Pojavio se ClickHouse u koji su se bacale cjepanice podijeljene na zapise. Pojavila se pripisana usluga koja je primala zapise od ClickHousea. Nakon toga sam za svaki unos, po ID-u posjeta, dobio transakcije koje možda još nisu obrađene i plus snimke, tj. već povezane transakcije, odnosno rezultat prethodnog rada. Već sam napravio logiku iz njih, izabrao ispravnu transakciju, povezao nove događaje. Opet prijavljen. Zapisnik se vratio u ClickHouse, odnosno radi se o stalno cikličkom sustavu. A osim toga, otišao sam u DWH da to tamo analiziram.

Upravo u tom obliku nije baš dobro funkcionirao. A kako bi ClickHouseu olakšali posao, kada je postojao zahtjev prema ID-u posjeta, grupirali su te zahtjeve u blokove od 1-000 ID-ova posjeta i izvukli sve transakcije za 2-000 ljudi. I onda je sve upalilo.

Ako pogledate unutar ClickHousea, onda postoje samo 3 glavna stola koji poslužuju sve ovo.

Prva tablica u koju se učitavaju dnevnici, a dnevnici se učitavaju gotovo bez obrade.

Drugi stol. Kroz materijalizirani pogled iz tih su balvana izgrizeni događaji koji još nisu atribuirani, tj. nepovezani. I kroz materijalizirani pogled, transakcije su izvučene iz ovih zapisa kako bi se napravila snimka. To jest, poseban materijalizirani pogled napravio je snimku, odnosno posljednje akumulirano stanje transakcije.

Ovdje je tekst napisan u SQL-u. Htio bih komentirati nekoliko važnih stvari u njemu.

Prva važna stvar je mogućnost izvlačenja stupaca i polja iz jsona u ClickHouseu. Odnosno, ClickHouse ima neke metode za rad s jsonom. Oni su vrlo, vrlo primitivni.

visitParamExtractInt vam omogućuje izdvajanje atributa iz jsona, tj. prvi pogodak radi. I na ovaj način možete izvući ID transakcije ili ID posjeta. Ovaj put.

Drugo, ovdje se koristi lukavo materijalizirano polje. Što to znači? To znači da ga ne možete umetnuti u tablicu, tj. ne ubacuje se, izračunava se i pohranjuje nakon umetanja. Prilikom lijepljenja, ClickHouse obavlja posao umjesto vas. A ono što trebate kasnije već je izvučeno iz jsona.

U ovom slučaju, materijalizirani prikaz je za neobrađene retke. I prvi stol s praktički sirovim zapisima je upravo korišten. I što on radi? Prvo, mijenja se sortiranje, tj. sortiranje sada ide po ID-u posjeta, jer moramo brzo izvući njegovu transakciju za određenu osobu.

Druga važna stvar je index_granularity. Ako ste vidjeli MergeTree, obično je 8 prema zadanoj postavci index_granularity. Što je? Ovo je parametar prorijeđenosti indeksa. U ClickHouseu indeks je rijedak, nikad ne indeksira svaki unos. To čini svakih 192. I to je dobro kada je potrebno izračunati mnogo podataka, ali loše kada je malo, jer postoji veliki teret. A ako smanjimo granularnost indeksa, tada ćemo smanjiti režijske troškove. Ne može se svesti na jedan, jer možda nema dovoljno memorije. Indeks je uvijek pohranjen u memoriji.

Snapshot također koristi neke druge zanimljive ClickHouse značajke.

Prvo, to je AggregatingMergeTree. A AggregatingMergeTree pohranjuje argMax, tj. ovo je stanje transakcije koje odgovara posljednjoj vremenskoj oznaci. Transakcije se generiraju cijelo vrijeme za određenog posjetitelja. I u posljednjem stanju ove transakcije dodali smo događaj i imamo novo stanje. Ponovno je pogodio ClickHouse. A kroz argMax u ovom materijaliziranom pogledu, uvijek možemo dobiti trenutno stanje.

• Vezanje je "odvojeno" od vremena izvođenja.
• Pohranjuje se i obrađuje do 3 milijarde transakcija mjesečno. To je red veličine više nego što je bilo u Cassandri, tj. u tipičnom transakcijskom sustavu.
• Klaster 2x5 ClickHouse poslužitelja. 5 servera i svaki server ima repliku. To je čak manje nego što je bilo u Cassandri da bi se izvršila atribucija na temelju klikova, a ovdje imamo na temelju dojmova. Odnosno, umjesto da povećaju broj poslužitelja za 30 puta, uspjeli su ih smanjiti.

I posljednji primjer je financijska tvrtka Y, koja je analizirala korelacije promjena cijena dionica.

A zadatak je bio:

• Ima oko 5 dionica.
• Poznati su citati svakih 100 milisekundi.
• Podaci su prikupljani tijekom 10 godina. Navodno, za neke tvrtke više, za neke manje.
• Ukupno ima oko 100 milijardi redaka.

I trebalo je izračunati korelaciju promjena.

Ovdje su dvije dionice i njihove kotacije. Ako jedan raste, a drugi raste, onda je to pozitivna korelacija, tj. jedan ide gore, a drugi raste. Ako jedan ide gore, kao na kraju grafa, a drugi pada, onda je to negativna korelacija, tj. kada jedan raste, drugi pada.

Analizirajući te međusobne promjene, mogu se napraviti predviđanja na financijskom tržištu.

Ali zadatak je težak. Što se radi za to? Imamo 100 milijardi zapisa koji sadrže: vrijeme, zalihu i cijenu. Moramo izračunati prvih 100 milijardi puta tekuće razlike od algoritma cijene. RunningDifference je funkcija u ClickHouseu koja uzastopno izračunava razliku između dva niza.

I nakon toga treba izračunati korelaciju, a korelacija se mora izračunati za svaki par. Za 5 dionica, parovi su 000 milijuna. A to je puno, tj. 12,5 puta je potrebno izračunati upravo takvu korelacijsku funkciju.

A ako je netko zaboravio, onda su ͞x i ͞y mat. očekivano uzorkovanje. To jest, potrebno je ne samo izračunati korijene i zbrojeve, već i još jedan zbroj unutar tih zbrojeva. Hrpu izračuna treba napraviti 12,5 milijuna puta, pa još i grupirati po satima. Imamo i puno sati. I to morate učiniti za 60 sekundi. To je vic.

Trebalo je barem nekako imati vremena, jer je sve ovo radilo jako, jako sporo prije nego je došao ClickHouse.

Pokušali su to izračunati na Hadoopu, na Sparku, na Greenplumu. A sve je to bilo jako sporo ili skupo. Odnosno, bilo je moguće nekako izračunati, ali tada je bilo skupo.

A onda se pojavio ClickHouse i stvari su krenule puno bolje.

Podsjećam da imamo problem s lokalnošću podataka, jer se korelacije ne mogu lokalizirati. Ne možemo neke podatke stavljati na jedan server, neke na drugi i računati, moramo imati sve podatke posvuda.

Što su učinili? U početku su podaci lokalizirani. Svaki poslužitelj pohranjuje podatke o cijenama određenog skupa dionica. I ne preklapaju se. Stoga je moguće izračunati logReturn paralelno i neovisno, sve se to do sada događa paralelno i distribuirano.

Zatim smo odlučili smanjiti te podatke, a da pritom ne izgubimo izražajnost. Smanjite korištenje nizova, tj. za svako vremensko razdoblje napravite niz dionica i niz cijena. Stoga zauzima mnogo manje podatkovnog prostora. I s njima je malo lakše raditi. To su gotovo paralelne operacije, tj. djelomično paralelno čitamo, a zatim pišemo na poslužitelj.

Nakon toga se može replicirati. Slovo "r" znači da smo replicirali ove podatke. Odnosno, imamo iste podatke na sva tri poslužitelja - to su nizovi.

A onda pomoću posebne skripte iz ovog skupa od 12,5 milijuna korelacija koje je potrebno izračunati, možete napraviti pakete. Odnosno 2 zadataka s 500 parova korelacija. I ovaj zadatak treba izračunati na određenom ClickHouse poslužitelju. On ima sve podatke, jer su podaci isti i može ih izračunati redom.

Još jednom, ovako to izgleda. Prvo, imamo sve podatke u ovoj strukturi: vrijeme, udjele, cijenu. Zatim smo izračunali logReturn, odnosno podatke iste strukture, ali umjesto cijene već imamo logReturn. Zatim su prerađeni, tj. dobili smo vrijeme i groupArray za dionice i cijene. Umnoženo. I nakon toga smo generirali hrpu zadataka i dali ih ClickHouseu da ih prebroji. I djeluje.

Na dokazu koncepta, zadatak je bio podzadatak, tj. uzeto je manje podataka. I samo tri poslužitelja.

Ove prve dvije faze: izračunavanje Log_return i umotavanje u nizove trajale su oko sat vremena.

A izračun korelacije je oko 50 sati. Ali 50 sati nije dovoljno, jer se znalo raditi tjednima. Bio je to veliki uspjeh. A ako brojite, onda je 70 puta u sekundi sve izbrojano na ovom klasteru.

Ali najvažnije je da je ovaj sustav praktički bez uskih grla, odnosno skalira se gotovo linearno. I provjerili su. Uspješno ste ga povećali.

• Prava shema je pola uspjeha. A prava shema je korištenje svih potrebnih ClickHouse tehnologija.
• Summing/AggregatingMergeTrees su tehnologije koje vam omogućuju agregiranje ili razmatranje snimke stanja kao posebnog slučaja. I uvelike pojednostavljuje mnoge stvari.
• Materijalizirani prikazi omogućuju vam da zaobiđete ograničenje jednog indeksa. Možda nisam jasno rekao, ali kada smo učitali zapisnike, neobrađeni zapisnici su bili u tablici s jednim indeksom, a zapisnici atributa bili su u tablici, tj. isti podaci, samo filtrirani, ali indeks je bio potpuno drugi. Čini se da su to isti podaci, ali drugačije sortiranje. A Materijalizirani pogledi omogućuju vam, ako vam je potrebno, da zaobiđete takvo ClickHouse ograničenje.
• Smanjite granularnost indeksa za upite točaka.
• I pametno distribuirajte podatke, pokušajte lokalizirati podatke unutar poslužitelja što je više moguće. I pokušajte osigurati da zahtjevi također koriste lokalizaciju što je više moguće.

I sumirajući ovaj kratki govor, možemo reći da je ClickHouse sada čvrsto zauzeo teritorij komercijalnih baza podataka i baza podataka otvorenog koda, odnosno posebno za analitiku. Savršeno se uklapa u ovaj krajolik. I štoviše, polako počinje istiskivati ​​druge, jer kada imate ClickHouse, ne treba vam InfiniDB. Vertika možda uskoro neće biti potrebna ako naprave normalnu SQL podršku. Uživati!

-Hvala na izvješću! Vrlo zanimljivo! Je li bilo usporedbi s Apache Phoenixom?

Ne, nisam čuo da netko uspoređuje. Mi i Yandex pokušavamo pratiti sve usporedbe ClickHousea s različitim bazama podataka. Jer ako se iznenada nešto pokaže bržim od ClickHousea, tada Lesha Milovidov ne može spavati noću i počinje to brzo ubrzavati. Nisam čuo za takvu usporedbu.

• (Aleksej Milovidov) Apache Phoenix je SQL motor koji pokreće Hbase. Hbase je uglavnom za scenarij rada ključ-vrijednost. Tu u svakom redu može biti proizvoljan broj stupaca s proizvoljnim nazivima. To se može reći o takvim sustavima kao što su Hbase, Cassandra. A upravo teški analitički upiti im neće raditi normalno. Ili biste mogli pomisliti da rade dobro ako niste imali iskustva s ClickHousom.

• Hvala

  • Dobar dan Već sam prilično zainteresiran za ovu temu, jer imam analitički podsustav. Ali kad pogledam ClickHouse, imam osjećaj da je ClickHouse vrlo prikladan za analizu događaja, promjenjiv. A ako trebam analizirati puno poslovnih podataka s hrpom velikih tablica, onda ClickHouse, koliko sam shvatio, nije baš prikladan za mene? Pogotovo ako se promijene. Je li to točno ili postoje primjeri koji to mogu opovrgnuti?

  • To je točno. I to vrijedi za većinu specijaliziranih analitičkih baza podataka. Oni su skrojeni za činjenicu da postoji jedna ili više velikih tablica koje su promjenjive, te za mnogo malih koje se sporo mijenjaju. Odnosno, ClickHouse nije poput Oraclea, gdje možete staviti sve i izgraditi neke vrlo složene upite. Kako biste učinkovito koristili ClickHouse, trebate izgraditi shemu na način koji dobro funkcionira u ClickHouseu. To jest, izbjegavajte pretjeranu normalizaciju, koristite rječnike, pokušajte napraviti manje dugih veza. A ako je shema izgrađena na ovaj način, onda se slični poslovni zadaci mogu riješiti na ClickHouseu mnogo učinkovitije nego na tradicionalnoj relacijskoj bazi podataka.

Hvala na izvješću! Imam pitanje o najnovijem financijskom slučaju. Imali su analitiku. Trebalo je usporediti kako idu gore i dolje. Koliko sam shvatio, sustav ste izgradili posebno za ovu analitiku? Ako im sutra, na primjer, treba neko drugo izvješće o tim podacima, trebaju li ponovno izgraditi shemu i učitati podatke? Odnosno, izvršiti neku vrstu predprocesiranja da bi se dobio zahtjev?

Naravno, ovo je korištenje ClickHousea za vrlo specifičan zadatak. To bi se moglo tradicionalnije riješiti unutar Hadoopa. Za Hadoop je ovo idealan zadatak. Ali na Hadoopu je vrlo spor. A moj cilj je pokazati da ClickHouse može rješavati zadatke koji se obično rješavaju potpuno drugačijim sredstvima, ali istovremeno to učiniti mnogo učinkovitije. Ovo je prilagođeno za određeni zadatak. Jasno je da ako postoji problem s nečim sličnim, onda se to može riješiti na sličan način.

To je jasno. Rekli ste da je obrađeno 50 sati. Je li to od samog početka, kada ste učitavali podatke ili dobivali rezultate?

Da da.

U redu, puno hvala.

Ovo je na klasteru od 3 poslužitelja.

Lijep pozdrav! Hvala na izvješću! Sve je jako zanimljivo. Neću malo pitati o funkcionalnosti, već o korištenju ClickHousea u smislu stabilnosti. Odnosno, jeste li imali, jeste li morali restaurirati? Kako se ClickHouse ponaša u ovom slučaju? A je li se dogodilo da imate i repliku? Na primjer, naišli smo na problem s ClickHouseom kada još uvijek izlazi iz svoje granice i pada.

Naravno, ne postoje idealni sustavi. I ClickHouse također ima svojih problema. Ali jeste li čuli da Yandex.Metrica ne radi već dugo? Vjerojatno ne. Pouzdano radi od 2012.-2013. na ClickHouseu. Isto mogu reći i za svoje iskustvo. Nikada nismo imali potpune promašaje. Neke parcijalne stvari su se mogle dogoditi, ali nikad nisu bile dovoljno kritične da ozbiljno utječu na poslovanje. Nikad se nije dogodilo. ClickHouse je prilično pouzdan i ne ruši se nasumično. Ne morate brinuti o tome. Nije sirova stvar. To su dokazale mnoge tvrtke.

Zdravo! Rekli ste da morate odmah razmisliti o shemi podataka. Što ako se dogodilo? Moji podaci se slijevaju i slijevaju. Prošlo je šest mjeseci i shvatio sam da je nemoguće živjeti ovako, moram ponovno učitati podatke i učiniti nešto s njima.

To naravno ovisi o vašem sustavu. Postoji nekoliko načina da to učinite gotovo bez zaustavljanja. Na primjer, možete stvoriti materijalizirani prikaz u kojem ćete napraviti drugačiju podatkovnu strukturu ako se može jedinstveno mapirati. Odnosno, ako dopušta mapiranje pomoću ClickHousea, tj. izdvajanje nekih stvari, promjenu primarnog ključa, promjenu particioniranja, tada možete napraviti materijalizirani prikaz. Tamo prepišite svoje stare podatke, novi će se automatski upisati. A onda samo prijeđite na korištenje materijaliziranog prikaza, zatim prebacite zapis i ubijte staru tablicu. Ovo je općenito metoda koja se ne zaustavlja.

Hvala Vam.

Izvor: www.habr.com