Teorija i praksa korištenja ClickHousea u stvarnim aplikacijama. Aleksandar Zajcev (2018)

Unatoč činjenici da sada postoji puno podataka gotovo posvuda, analitičke baze podataka su još uvijek prilično egzotične. Oni su slabo poznati i još gore u stanju da ih efikasno koriste. Mnogi i dalje "jedu kaktuse" sa MySQL-om ili PostgreSQL-om, koji su dizajnirani za druge scenarije, pate sa NoSQL-om 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 sa BackEnd Conf 2018 i objavljuje se uz dozvolu govornika.

Ko sam ja i zašto govorim o ClickHouseu? Ja sam direktor razvoja u LifeStreet-u, koji koristi ClickHouse. Takođe, ja sam osnivač Altinity-a. To je Yandex partner koji promovira ClickHouse i pomaže Yandexu da ClickHouse učini uspješnijim. Također spreman podijeliti znanje o ClickHouseu.

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

“Svi znaju” da ClickHouse:

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

Nešto manje se zna u kojim kompanijama i kako se koristi.

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

Reći ću vam kako se konkretni zadaci rješavaju uz pomoć ClickHouse-a u različitim kompanijama, koje ClickHouse alate možete koristiti za svoje zadatke i kako su korišteni u različitim kompanijama.

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

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

• Prvi odgovor je za performanse. ClickHouse je veoma brz. Analitika na ClickHouseu je također 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 odlična baza podataka. Radi vrlo dobro ako nemate puno terabajta podataka. Ali kada je riječ 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 donijeti odluku vrlo brzo. Radit će dobro, ali u isto vrijeme, svaki sat, svaki dan i svaki mjesec ćete platiti Amazonu prilično skupo, jer je ovo značajno skupa usluga. Google BigQuery također. Ako ga je neko koristio, onda zna da tamo možete pokrenuti nekoliko zahtjeva i odjednom dobiti račun za stotine dolara.

ClickHouse nema ovih problema.

Gdje se sada koristi ClickHouse? Uz Yandex, ClickHouse se koristi u gomili različitih poslova i kompanija.

• Prije svega, ovo je analitika web aplikacija, odnosno ovo je slučaj upotrebe koji dolazi od Yandexa.
• Mnoge AdTech kompanije koriste ClickHouse.
• Brojne kompanije koje trebaju analizirati dnevnike transakcija iz različitih izvora.
• Nekoliko kompanija koristi ClickHouse za praćenje sigurnosnih dnevnika. Oni ih postavljaju na ClickHouse, prave izvještaje i dobijaju rezultate koji su im potrebni.
• Kompanije ga počinju koristiti u finansijskoj analizi, odnosno postepeno se i velika preduzeća približavaju ClickHouseu.
• cloudflare. Ako neko prati ClickHouse, vjerovatno je čuo ime ove kompanije. Ovo je jedan od bitnih doprinosioca zajednice. I imaju vrlo ozbiljnu ClickHouse instalaciju. Na primjer, napravili su Kafka Engine za ClickHouse.
• Telekomunikacione kompanije su počele da koriste. Nekoliko kompanija koristi ClickHouse ili kao dokaz koncepta ili već u proizvodnji.
• Jedna kompanija koristi ClickHouse za praćenje proizvodnih procesa. Testiraju mikro krugove, otpisuju gomilu parametara, ima oko 2 karakteristika. A onda analiziraju da li je igra dobra ili loša.
• Blockchain analitika. Postoji takva ruska kompanija kao što je Bloxy.info. Ovo je analiza ethereum mreže. To su također radili na ClickHouseu.

I veličina nije bitna. Mnogo je kompanija koje koriste jedan mali server. I dozvoljava im da riješe svoje probleme. I još više kompanija koristi velike klastere od mnogo servera ili desetine servera.

A ako pogledate zapise, onda:

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

Geografski, ovo je takođe mnogo. Ova mapa ovdje prikazuje toplotnu kartu gdje se ClickHouse koristi u svijetu. Tu se jasno ističu Rusija, Kina, Amerika. Malo je evropskih zemalja. I postoje 4 klastera.

Ovo je komparativna analiza, nema potrebe tražiti apsolutne brojke. Ovo je analiza posetilaca koji čitaju materijale na engleskom jeziku na sajtu Altinity, jer tamo nema onih koji govore ruski. A Rusija, Ukrajina, Bjelorusija, odnosno dio zajednice koji govori ruski, to su najbrojniji korisnici. Zatim dolaze SAD i Kanada. Kina uveliko sustiže. Prije šest mjeseci tamo Kine gotovo da nije bilo, sada je Kina već pretekla Evropu i nastavlja da raste. Stara Evropa takođe ne zaostaje, a lider u upotrebi ClickHouse-a je, začudo, Francuska.

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

Ovo su primjeri stvarne upotrebe ClickHouse-a u nekoliko kompanija.

• Prvi primjer je oglasna mreža: migracija s Vertice na ClickHouse. I znam nekoliko kompanija koje su prešle iz Vertice ili su u procesu tranzicije.
• Drugi primjer je transakcijska pohrana na ClickHouse. Ovo je primjer izgrađen na antiuzorcima. Sve što se ne bi trebalo raditi u ClickHouseu po savjetu programera radi se ovdje. I to je urađeno tako efikasno da radi. I radi mnogo bolje od tipičnog transakcionog rješenja.
• Treći primjer je distribuirano računarstvo na ClickHouse-u. Postavilo se pitanje kako se ClickHouse može integrirati u Hadoop ekosistem. Pokazat ću primjer kako je kompanija napravila nešto slično kontejneru za smanjenje mape na ClickHouse-u, praćenje lokalizacije podataka, itd., kako bi izračunala vrlo netrivijalan zadatak.

• LifeStreet je Ad Tech kompanija koja ima svu tehnologiju koja dolazi s oglasnom mrežom.
• Bavi se optimizacijom oglasa, programskim licitiranjem.
• Mnogo podataka: oko 10 milijardi događaja dnevno. Istovremeno, tamošnji događaji se mogu podijeliti na nekoliko pod-događaja.
• Mnogo je klijenata ovih podataka, a to nisu samo ljudi, mnogo više - to su razni algoritmi koji se bave programskim licitiranjem.

Kompanija je prešla dug i trnovit put. I pričao sam o tome na HighLoad-u. Prvo, LifeStreet se preselio sa MySQL-a (sa kratkim zaustavljanjem u Oracle-u) na Vertica. I možete pronaći priču o tome.

I sve je bilo jako dobro, ali brzo je postalo jasno da podaci rastu, a Vertica je skupa. Stoga su tražene različite alternative. Neki od njih su navedeni ovdje. I zapravo smo radili proof koncepta ili ponekad testiranje performansi gotovo svih baza podataka koje su bile dostupne na tržištu od 13. do 16. godine i koje su bile približno funkcionalne. O nekima od njih sam također pričao na HighLoad-u.

Zadatak je bio prije svega migrirati iz Vertice, jer su podaci rasli. I eksponencijalno su rasli tokom godina. Onda su otišli na policu, ali ipak. A predviđajući ovaj rast, poslovne zahtjeve za količinom podataka o kojoj je trebalo napraviti neku vrstu analitike, bilo je jasno da će se uskoro govoriti o petabajtima. A plaćanje petabajta je već veoma skupo, pa smo tražili alternativu gde da idemo.

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

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

I nije bilo ničega što bi spojilo ono dobro što se nalazi u komercijalnim bazama podataka i sve besplatno što je u otvorenom kodu.

Nije bilo ničega dok, neočekivano, Yandex nije izvukao ClickHouse, kao mađioničar iz šešira, kao zec. I to je bila neočekivana odluka, oni i dalje postavljaju pitanje: “Zašto?”, ali ipak.

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

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

Ali ako u upitima postoje spojevi, onda sve ispada ne baš jednoznačno. A ClickHouse može biti duplo 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 je primio rezultate testa i pogledao ih iz različitih uglova, 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 bockali se, ali su nastavili da jedu kaktus. I ovo je detaljno opisano, postoji video o tome itd.

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

Rezultati su:

• Uspješna migracija i više od godinu dana sistem već radi u proizvodnji.
• Povećane su produktivnost i fleksibilnost. Od 10 milijardi zapisa koje smo mogli priuštiti da pohranjujemo dnevno, a zatim na kratko, LifeStreet sada pohranjuje 75 milijardi zapisa dnevno i to može raditi 3 mjeseca ili više. Ako računate na vrhuncu, onda je to do milion događaja u sekundi. Više od milion SQL upita dnevno stiže u ovaj sistem, uglavnom od različitih robota.
• Unatoč činjenici da je više servera korišteno za ClickHouse nego za Vertica, uštedjeli su i na hardveru, jer su se u Vertici koristili prilično skupi SAS diskovi. ClickHouse koristi SATA. I zašto? Zato što je u Vertici insert sinhroni. A za sinhronizaciju je potrebno da diskovi ne usporavaju previše, kao i da mreža ne usporava previše, odnosno prilično skupa operacija. I u ClickHouse umetanje je asinkrono. Štaviše, uvijek možete sve pisati lokalno, nema dodatnih troškova za to, pa se podaci mogu ubaciti u ClickHouse mnogo brže nego u Vertiku, čak i na sporijim diskovima. I čitanje je otprilike isto. Čitajući na SATA, ako su u RAID-u, onda je sve ovo dovoljno brzo.
• Nije ograničeno licencom, tj. 3 petabajta podataka na 60 servera (20 servera je jedna replika) i 6 triliona zapisa u činjenicama i agregacijama. U Vertici se ovako ništa ne može priuštiti.

Sada prelazim na praktične stvari u ovom primjeru.

• Prva je efikasna šema. Mnogo zavisi od šeme.
• Drugi je efikasna SQL generacija.

Tipičan OLAP upit je odabir. Neki od stupaca idu u grupiranje po, neki od stupaca idu u agregatne funkcije. Postoji gdje, što se može predstaviti kao komad kocke. Cela grupa se može posmatrati kao projekcija. I zato se to zove multivarijantna analiza podataka.

I često se to modelira u obliku zvijezde-šeme, kada postoji središnja činjenica i karakteristike te činjenice duž strana, duž zraka.

A u smislu fizičkog dizajna, kako se uklapa na sto, oni obično rade normaliziranu reprezentaciju. Možete denormalizirati, ali to je skupo na disku i nije baš efikasno za upite. Stoga obično prave normaliziranu reprezentaciju, tj. tablicu činjenica i mnoge, mnoge tabele dimenzija.

Ali to ne radi dobro u ClickHouseu. Dva su razloga:

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

I postoji izlaz iz ovoga u ClickHouseu. cak dva:

• Prvi je upotreba rječnika. Eksterni rječnici su ono što pomaže u 99% rješavanja problema sa star-šemom, ažuriranjima i tako dalje.
• Drugi je upotreba nizova. Nizovi također pomažu da se riješite spojeva i problema s normalizacijom.

• Nije potrebno pridruživanje.
• Nadogradivo. Od marta 2018. godine pojavila se nedokumentovana mogućnost (nećete to pronaći u dokumentaciji) da se djelimično ažuriraju rječnici, odnosno oni unosi koji su promijenjeni. Praktično, to je kao sto.
• Uvek u memoriji, tako da spojevi sa rečnikom rade brže nego da se radi o tabeli koja je na disku i još uvek nije činjenica da je u kešu, najverovatnije ne.

• Ne trebaju vam ni spojevi.
• Ovo je kompaktan prikaz 1-prema-više.
• I po mom mišljenju, nizovi su napravljeni za štreberke. Ovo su lambda funkcije i tako dalje.

Ovo nije za crvene riječi. Ovo je vrlo moćna funkcionalnost koja vam omogućava 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:

• Traži po oznakama. Ako tamo imate hashtagove i želite pronaći neke postove po hashtagovima.
• Pretražujte po parovima ključ/vrijednost. Postoje i neki atributi sa vrijednošću.
• Pohranjivanje liste ključeva koje trebate prevesti u nešto drugo.

Svi ovi zadaci se mogu riješiti bez nizova. Oznake se mogu staviti u neki red i odabrati regularnim izrazom ili u posebnu tabelu, ali onda morate napraviti spojeve.

A u ClickHouseu ne morate ništa raditi, dovoljno je opisati niz stringova za hashtagove ili napraviti ugniježđenu strukturu za sisteme ključ/vrijednost.

Ugniježđena struktura možda nije najbolje ime. To su dva niza koja imaju zajednički dio u nazivu i neke povezane karakteristike.

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

Pretraga po subid-u je malo komplikovanija. Prvo moramo pronaći indeks ključa, a zatim uzeti element sa ovim indeksom i provjeriti da li je ta vrijednost ono što nam treba. Međutim, vrlo je jednostavan i kompaktan.

Regularni izraz koji biste hteli da napišete da sve držite u jednom redu, bio bi, prvo, nespretan. I, drugo, radio je mnogo duže od dva niza.

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

Pretraga se može izvršiti na isti način. Predikatna funkcija se prosljeđuje koja provjerava s čim se elementi podudaraju.

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

Ali sledeći problem sa kojim se suočavamo, a koji bih želeo da pomenem, su efikasni upiti.

• ClickHouse nema planer upita. Apsolutno ne.
• Ipak, složene upite još uvijek treba planirati. U kojim slučajevima?
• Ako u upitu postoji više spajanja, umotavate ih u podizbore. Bitan je i redosled kojim se oni izvršavaju.
• I drugo - ako se zahtjev distribuira. Zato što se u distribuiranom upitu distribuira samo najdublji podizbor, a sve ostalo se prosljeđuje na jedan server na koji ste se povezali i tamo izvršili. Stoga, ako imate distribuirane upite s mnogo spajanja (join), onda morate odabrati redoslijed.

A čak iu jednostavnijim slučajevima, ponekad je potrebno obaviti posao planera i malo prepisati upite.

Evo primjera. Na lijevoj strani je upit koji prikazuje prvih 5 zemalja. I traje 2,5 sekunde, po mom mišljenju. A na desnoj strani isti upit, ali malo prepisan. Umjesto grupiranja po nizu, počeli smo grupirati po ključu (int). I to je brže. I onda smo spojili rječnik na rezultat. Umjesto 2,5 sekunde, zahtjev traje 1,5 sekunde. Ovo je dobro.

Sličan primjer sa prepisivanjem filtera. Evo zahtjeva za Rusiju. Radi 5 sekundi. Ako ga prepišemo na način da ponovo uporedimo ne niz, već brojeve sa nekim skupom onih ključeva koji se odnose na Rusiju, onda će to biti mnogo brže.

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

• Maksimalan rad u distribuiranom režimu.
• Sortiranje po minimalnim tipovima, kao što sam ja radio po ints.
• Ako postoje spojevi (join), rječnici, onda ih je bolje učiniti u krajnjoj nuždi, kada već imate podatke barem djelomično grupirane, tada će se operacija spajanja ili poziv rječnika pozivati ​​manje puta i to će biti brže .
• Zamjena filtera.

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

Prijeđimo na sljedeći primjer. Kompanija X iz SAD. Šta to ona radi?

Postojao je zadatak:

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

Kakav je scenario?

Običan posjetitelj dođe na stranicu, na primjer, 20 puta mjesečno iz različitih oglasa, ili jednostavno tako ponekad dođe bez ikakvih oglasa, jer pamti ovu stranicu. Gleda neke proizvode, stavlja ih u korpu, vadi iz korpe. I, na kraju, nešto se kupi.

Razumna pitanja: "Ko treba da plati oglašavanje, ako je potrebno?" i “Koje je oglašavanje utjecalo na njega, ako je bilo?”. Odnosno, zašto je kupio i kako navesti ljude poput ove osobe da i oni kupe?

Da biste riješili ovaj problem, potrebno je da na pravi način povežete događaje koji se dešavaju na web stranici, odnosno nekako izgradite vezu između njih. Zatim se šalju na analizu u DWH. I na osnovu ove analize, napravite modele ko i koje oglase prikazati.

Transakcija oglasa je skup povezanih korisničkih događaja koji počinju od prikazivanja oglasa, zatim se nešto dogodi, zatim možda kupovina, a zatim može doći do kupovina unutar kupovine. Na primjer, ako je ovo mobilna aplikacija ili mobilna igra, tada se obično instalacija aplikacije odvija besplatno, a ako se tamo nešto radi, onda će za to možda biti potreban novac. I što više osoba potroši u aplikaciji, to je ona vrednija. Ali za ovo morate povezati sve.

Postoji mnogo modela vezivanja.

Najpopularniji su:

• Zadnja interakcija, gdje je interakcija ili klik ili impresija.
• Prva interakcija, odnosno prva stvar koja je dovela osobu na stranicu.
• Linearna kombinacija - sve podjednako.
• Slabljenje.
• I tako dalje.

I kako je sve to uopće funkcioniralo? Postojali su Runtime i Cassandra. Cassandra je korištena kao skladište transakcija, odnosno sve povezane transakcije su pohranjene u njemu. I kada dođe neki događaj u Runtime-u, na primjer, prikazuje neku stranicu ili nešto drugo, onda je Cassandri upućen zahtjev - postoji li takva osoba ili ne. Tada su dobijene transakcije koje se odnose na to. I veza je uspostavljena.

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

I sve je funkcionisalo jako dobro dok je uvez bio do zadnjeg klika. Jer ima recimo 10 miliona klikova dnevno, 300 miliona mesečno, ako postavimo prozor na mesec dana. A pošto u Cassandri sve mora biti u memoriji da bi se brzo pokrenulo, jer Runtime mora brzo odgovoriti, bilo je potrebno oko 10-15 servera.

A kada su htjeli da povežu transakciju sa ekranom, to se odmah pokazalo i nije tako zabavno. I zašto? Vidi se da je potrebno pohraniti 30 puta više događaja. I, shodno tome, potrebno vam je 30 puta više servera. I ispostavilo se da je ovo neka vrsta astronomske figure. Zadržati do 500 servera da bi se izvršilo povezivanje, uprkos činjenici da ima znatno manje servera u Runtime-u, onda je to neka pogrešna brojka. I počeli su da razmišljaju šta da rade.

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

• Transakcija raste, na nju povezujemo sve više događaja, tj. promjenjiva je, a ClickHouse ne radi baš dobro sa promjenjivim objektima.
• Kada posjetilac dođe kod nas, potrebno je da izvučemo njegove transakcije po ključu, po ID-u posjete. Ovo je takođe tačkasti upit, oni to ne rade u ClickHouseu. Obično ClickHouse ima velike ... skeniranja, ali ovdje moramo dobiti neke zapise. Takođe antiuzorak.
• Osim toga, transakcija je bila u json-u, ali nisu htjeli da je prepišu, pa su željeli pohraniti json na nestrukturiran način, i ako je potrebno, izvući nešto iz njega. I ovo je takođe antiuzorak.

Odnosno, skup antišablona.

Ali ipak se pokazalo da je napravio sistem koji je funkcionisao veoma dobro.

Šta je urađeno? Pojavio se ClickHouse, u koji su bačeni trupci, podijeljeni u zapise. Pojavio se pripisani servis koji je primao dnevnike od ClickHouse-a. Nakon toga, za svaki unos, po ID-u posjete, dobio sam transakcije koje možda još nisu obrađene i plus snimke, odnosno transakcije koje su već povezane, odnosno rezultat prethodnog rada. Već sam napravio logiku od njih, izabrao ispravnu transakciju, povezao nove događaje. Ponovo registrovan. Dnevnik se vratio u ClickHouse, tj. to je konstantno cikličan sistem. Osim toga, otišao sam u DWH da to analiziram tamo.

U ovom obliku nije dobro funkcionirao. I da bi olakšali ClickHouseu, kada je postojao zahtjev po ID-u posjete, grupisali su ove zahtjeve u blokove od 1-000 ID-ova posjeta i izvlačili sve transakcije za 2-000 ljudi. I onda je sve upalilo.

Ako pogledate unutra ClickHouse, onda postoje samo 3 glavna stola koji služe za sve ovo.

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

Drugi sto. Kroz materijalizovani pogled, iz ovih dnevnika su izgrizani događaji koji još nisu pripisani, odnosno nepovezani. I kroz materijalizovani prikaz, transakcije su izvučene iz ovih dnevnika da bi se napravio snimak. Odnosno, poseban materijalizirani pogled je napravio snimak, odnosno posljednje akumulirano stanje transakcije.

Ovdje je tekst napisan u SQL-u. Želio bih da prokomentarišem nekoliko bitnih stvari u njemu.

Prva važna stvar je mogućnost izvlačenja kolona i polja iz json-a u ClickHouse-u. To jest, ClickHouse ima neke metode za rad sa json-om. Oni su veoma, veoma primitivni.

visitParamExtractInt vam omogućava da izvučete atribute iz json-a, tj. prvi pogodak radi. I na ovaj način možete izvući ID transakcije ili ID posjete. Ovaj put.

Drugo, ovdje se koristi lukavo materijalizirano polje. Šta to znači? To znači da ga ne možete ubaciti u tabelu, tj. nije umetnut, već se izračunava i pohranjuje nakon umetanja. Prilikom lijepljenja, ClickHouse radi umjesto vas. A ono što vam treba kasnije je već izvučeno iz json-a.

U ovom slučaju, materijalizirani pogled je za neobrađene redove. A prva tabela sa praktički sirovim trupcima se upravo koristi. I šta on radi? Prvo, mijenja se sortiranje, odnosno sortiranje sada ide po ID-u posjete, 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 po defaultu index_granularity. Šta je to? Ovo je parametar rijetkosti indeksa. U ClickHouseu indeks je rijedak, nikada ne indeksira svaki unos. To radi svakih 192 8. I to je dobro kada je potrebno mnogo podataka da se izračuna, ali loše kada je malo, jer postoje veliki troškovi. A ako smanjimo granularnost indeksa, onda ćemo smanjiti 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 generišu cijelo vrijeme za određenog posjetitelja. I u posljednjem stanju ove transakcije, dodali smo događaj i imamo novo stanje. Ponovo je pogodio ClickHouse. A kroz argMax u ovom materijaliziranom pogledu, uvijek možemo dobiti trenutno stanje.

• Vezivanje je "razdvojeno" od vremena izvođenja.
• Do 3 milijarde transakcija mjesečno se pohranjuju i obrađuju. Ovo je za red veličine više nego što je bilo u Cassandri, odnosno u tipičnom transakcionom sistemu.
• Klaster 2x5 ClickHouse servera. 5 servera i svaki server ima repliku. Ovo je čak i manje nego što je bilo u Cassandri da bi se izvršila atribucija zasnovana na klikovima, a ovdje imamo baziranu na utisku. Odnosno, umjesto povećanja broja servera za 30 puta, uspjeli su ih smanjiti.

I posljednji primjer je finansijska kompanija Y, koja je analizirala korelacije promjena cijena dionica.

A zadatak je bio:

• Postoji oko 5 dionica.
• Poznati su citati na svakih 100 milisekundi.
• Podaci su prikupljani tokom 10 godina. Očigledno, za neke kompanije više, za neke manje.
• Ukupno ima oko 100 milijardi redova.

I bilo je potrebno izračunati korelaciju promjena.

Ovdje su dvije dionice i njihove kotacije. Ako jedno ide gore, a drugo ide gore, onda je ovo pozitivna korelacija, odnosno jedno ide gore, a drugo gore. Ako jedan ide gore, kao na kraju grafikona, a drugi pada, onda je ovo negativna korelacija, odnosno kada se jedan diže, drugi pada.

Analizirajući ove međusobne promjene, moguće je prognozirati na finansijskom tržištu.

Ali zadatak je težak. Šta se radi za ovo? Imamo 100 milijardi zapisa koji imaju: vrijeme, zalihe i cijenu. Moramo izračunati prvih 100 milijardi puta veću razliku od algoritma cijene. RunningDifference je funkcija u ClickHouseu koja sekvencijalno izračunava razliku između dva niza.

I nakon toga, potrebno je izračunati korelaciju, a korelacija se mora izračunati za svaki par. Za 5 dionica, parovi su 000 miliona. A to je mnogo, odnosno 12,5 puta je potrebno izračunati upravo takvu korelaciju.

A ako je neko zaboravio, onda su ͞x i ͞y mat. očekivanje uzorkovanja. Odnosno, potrebno je ne samo izračunati korijene i zbrojeve, već i još jedan zbir unutar tih suma. Gomilu proračuna treba uraditi 12,5 miliona puta, pa čak i grupirati po satima. Imamo i dosta sati. I to morate učiniti za 60 sekundi. To je šala.

Trebalo je barem nekako imati vremena, jer je sve ovo funkcionisalo vrlo, vrlo sporo prije nego što je ClickHouse došao.

Pokušali su to izračunati na Hadoop-u, na Spark-u, na Greenplum-u. I sve je to bilo jako sporo ili skupo. Odnosno, moglo se nekako izračunati, ali tada je bilo skupo.

A onda je došao ClickHouse i stvari su postale mnogo bolje.

Podsjećam da imamo problem s lokalizacijom podataka, jer se korelacije ne mogu lokalizirati. Ne možemo staviti neke podatke na jedan server, neke na drugi i izračunati, moramo imati sve podatke svuda.

Šta su uradili? U početku se podaci lokaliziraju. Svaki server pohranjuje podatke o cijenama određenog skupa dionica. I ne preklapaju se. Stoga je moguće izračunati logReturn paralelno i nezavisno, sve se to do sada dešava paralelno i distribuirano.

Tada smo odlučili smanjiti ove podatke, a da pritom ne izgubimo izražajnost. Smanjite korištenje nizova, tj. za svaki vremenski period napravite niz akcija i niz cijena. Stoga zauzima mnogo manje prostora za podatke. I sa njima je malo lakše raditi. To su gotovo paralelne operacije, odnosno djelomično paralelno čitamo, a zatim pišemo na server.

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

I onda sa posebnom skriptom iz ovog skupa od 12,5 miliona korelacija koje treba izračunati, možete napraviti pakete. Odnosno 2 zadataka sa 500 parova korelacija. I ovaj zadatak treba da se izračuna na određenom ClickHouse serveru. On ima sve podatke, jer su podaci isti i može ih izračunati uzastopno.

Još jednom, ovako to izgleda. Prvo, imamo sve podatke u ovoj strukturi: vrijeme, dionice, cijenu. Zatim smo izračunali logReturn, odnosno podatke iste strukture, ali umjesto cijene već imamo logReturn. Zatim su preuređeni, tj. dobili smo vrijeme i groupArray za akcije i cijene. Sreplicano. I nakon toga, generirali smo gomilu zadataka i poslali ih ClickHouseu da ih on broji. I radi.

Na dokazu koncepta, zadatak je bio podzadatak, odnosno uzeto je manje podataka. I samo tri servera.

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

A izračunavanje korelacije je oko 50 sati. Ali 50 sati nije dovoljno, jer su radili nedeljama. Bio je to veliki uspjeh. A ako računate, onda je 70 puta u sekundi sve izbrojano na ovom klasteru.

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

• Prava šema je pola bitke. A prava shema je korištenje svih potrebnih ClickHouse tehnologija.
• Summing/AggregatingMergeTrees su tehnologije koje vam omogućavaju da agregirate ili razmotrite snimak stanja kao poseban slučaj. I to uvelike pojednostavljuje mnoge stvari.
• Materijalizovani prikazi vam omogućavaju da zaobiđete ograničenje jednog indeksa. Možda nisam baš jasno rekao, ali kada smo učitavali dnevnike, sirovi logovi su bili u tabeli sa jednim indeksom, a zapisnici atributa su bili u tabeli, tj. isti podaci, samo filtrirani, ali je indeks u potpunosti drugi. Čini se da su to isti podaci, ali različito sortiranje. A Materialized Views vam omogućava, ako vam je potrebno, da zaobiđete takvo ClickHouse ograničenje.
• Smanjite granularnost indeksa za upite o tačkama.
• I pametno distribuirajte podatke, pokušajte lokalizirati podatke unutar servera što je više moguće. I pokušajte osigurati da zahtjevi također koriste lokalizaciju u najvećoj mogućoj mjeri.

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

-Hvala na izvještaju! Vrlo zanimljivo! Da li je bilo poređenja sa Apache Phoenixom?

Ne, nisam čuo da neko poredi. Mi i Yandex pokušavamo pratiti sva ClickHouse poređenja s različitim bazama podataka. Jer ako se odjednom nešto pokaže brže od ClickHousea, onda Lesha Milovidov ne može spavati noću i počinje to brzo da ubrzava. Nisam čuo za takvo poređenje.

• (Aleksey Milovidov) Apache Phoenix je SQL motor koji pokreće Hbase. Hbase je uglavnom za radni scenarij ključ/vrijednost. Tamo, u svakom redu, može biti proizvoljan broj kolona sa proizvoljnim imenima. To se može reći za takve sisteme kao što su Hbase, Cassandra. A upravo teški analitički upiti neće raditi normalno za njih. Ili možda mislite da rade dobro ako niste imali iskustva sa ClickHouse.

• Spasibo

  • Dobar dan Ova tema me već prilično zanima, jer imam analitički podsistem. Ali kada pogledam ClickHouse, imam osjećaj da je ClickHouse vrlo pogodan za analizu događaja, promjenjiv. A ako trebam analizirati puno poslovnih podataka s gomilom velikih tablica, onda mi ClickHouse, koliko razumijem, nije baš prikladan? Pogotovo ako se promijene. Da li je to tačno ili postoje primjeri koji to mogu opovrgnuti?

  • Ovo je tačno. I to važi za većinu specijalizovanih analitičkih baza podataka. Prilagođeni su za činjenicu da postoji jedna ili više velikih tablica koje su promjenjive, a za mnoge male koje se sporo mijenjaju. Odnosno, ClickHouse nije kao Oracle, gdje možete staviti sve i napraviti neke vrlo složene upite. Da biste efikasno koristili ClickHouse, potrebno je da napravite šemu na način koji dobro funkcioniše u ClickHouseu. Odnosno, 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 rješavati na ClickHouseu mnogo efikasnije nego na tradicionalnoj relacijskoj bazi podataka.

Hvala na izvještaju! Imam pitanje u vezi najnovijeg finansijskog slučaja. Imali su analitiku. Bilo je potrebno uporediti kako idu gore i dole. I koliko sam shvatio, vi ste napravili sistem posebno za ovu analitiku? Ako im sutra, na primjer, zatreba neki drugi izvještaj o ovim podacima, da li trebaju ponovo izgraditi shemu i učitati podatke? Odnosno, izvršiti neku vrstu predprocesiranja da dobijete zahtjev?

Naravno, ovo je upotreba ClickHouse-a za vrlo specifičan zadatak. Tradicionalnije bi se to moglo riješiti unutar Hadoop-a. Za Hadoop, ovo je idealan zadatak. Ali na Hadoop-u 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 u isto vrijeme to radi mnogo efikasnije. Ovo je skrojeno za određeni zadatak. Jasno je da ako postoji problem sa nečim sličnim, onda se može riješiti na sličan način.

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

Da da.

OK hvala vam puno.

Ovo je na klasteru od 3 servera.

Pozdrav! Hvala na izvještaju! Sve je veoma interesantno. Neću se pitati malo o funkcionalnosti, već o korištenju ClickHouse-a u smislu stabilnosti. Odnosno, da li ste imali, da li ste morali da restaurirate? Kako se ClickHouse ponaša u ovom slučaju? A da li se desilo da imate i repliku? Na primjer, naišli smo na problem s ClickHouse-om kada još uvijek prelazi svoje granice i pada.

Naravno, ne postoje idealni sistemi. I ClickHouse također ima svoje probleme. Ali jeste li čuli da Yandex.Metrica ne radi već duže vrijeme? Vjerovatno ne. Pouzdano radi od 2012-2013 na ClickHouseu. Isto mogu reći i o svom iskustvu. Nikada nismo imali potpune neuspjehe. Neke parcijalne stvari su se mogle dogoditi, ali nikada 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. To nije sirova stvar. To su dokazale mnoge kompanije.

Zdravo! Rekli ste da morate odmah razmisliti o šemi podataka. Šta ako se dogodilo? Moji podaci pljušte i pljušte. Prođe šest mjeseci, a shvatim da je nemoguće živjeti ovako, moram ponovo uploadati podatke i učiniti nešto s njima.

Ovo naravno zavisi od vašeg sistema. Postoji nekoliko načina da to učinite gotovo bez zaustavljanja. Na primjer, možete kreirati materijalizirani prikaz u kojem ćete napraviti drugačiju strukturu podataka ako se može jedinstveno mapirati. Odnosno, ako dozvoljava mapiranje pomoću ClickHouse-a, tj. izdvajanje nekih stvari, promjenu primarnog ključa, promjenu particioniranja, onda možete napraviti materijalizirani prikaz. Zamenite svoje stare podatke tamo, novi će biti automatski upisani. A onda se samo prebacite na korištenje materijaliziranog pogleda, zatim promijenite zapis i ubijte staru tablicu. Ovo je općenito non-stop metoda.

Spasibo.

izvor: www.habr.com