Teoria și practica utilizării ClickHouse în aplicații reale. Alexander Zaitsev (2018)

În ciuda faptului că acum există o mulțime de date aproape peste tot, bazele de date analitice sunt încă destul de exotice. Sunt puțin cunoscute și chiar mai rău capabile să le folosească eficient. Mulți continuă să „mânânce cactus” cu MySQL sau PostgreSQL, care sunt concepute pentru alte scenarii, suferă cu NoSQL sau plătesc în plus pentru soluții comerciale. ClickHouse schimbă regulile jocului și scade semnificativ pragul de intrare în lumea DBMS analitică.

Raport de la BackEnd Conf 2018 și este publicat cu permisiunea vorbitorului.

Cine sunt eu și de ce vorbesc despre ClickHouse? Sunt director de dezvoltare la LifeStreet, care folosește ClickHouse. De asemenea, sunt fondatorul Altinity. Este un partener Yandex care promovează ClickHouse și îl ajută pe Yandex să facă ClickHouse mai de succes. De asemenea, gata să împărtășească cunoștințele despre ClickHouse.

Și nu sunt fratele lui Petya Zaitsev. Sunt adesea întrebat despre asta. Nu, nu suntem frați.

„Toată lumea știe” că ClickHouse:

• Foarte rapid,
• Foarte confortabil
• Folosit în Yandex.

Se știe puțin mai puțin în ce companii și cum este utilizat.

Vă voi spune de ce, unde și cum este utilizat ClickHouse, cu excepția Yandex.

Vă voi spune cum sunt rezolvate anumite sarcini cu ajutorul ClickHouse în diferite companii, ce instrumente ClickHouse puteți folosi pentru sarcinile dvs. și cum au fost utilizate în diferite companii.

Am luat trei exemple care arată ClickHouse din unghiuri diferite. Cred că va fi interesant.

Prima întrebare este: „De ce avem nevoie de ClickHouse?”. Pare a fi o întrebare destul de evidentă, dar există mai multe răspunsuri la ea.

• Primul răspuns este pentru performanță. ClickHouse este foarte rapid. Analytics pe ClickHouse este, de asemenea, foarte rapid. Poate fi folosit adesea acolo unde altceva este foarte lent sau foarte rău.
• Al doilea răspuns este costul. Și, în primul rând, costul de scalare. De exemplu, Vertica este o bază de date absolut grozavă. Funcționează foarte bine dacă nu aveți mulți terabytes de date. Dar când vine vorba de sute de terabytes sau petabytes, costul unei licențe și al suportului se ridică într-o sumă destul de semnificativă. Și e scump. Și ClickHouse este gratuit.
• Al treilea răspuns este costul operațional. Aceasta este o abordare ușor diferită. RedShift este un analog grozav. Pe RedShift, puteți lua o decizie foarte rapid. Va funcționa bine, dar, în același timp, în fiecare oră, în fiecare zi și în fiecare lună, veți plăti Amazon destul de scump, deoarece acesta este un serviciu semnificativ de scump. Google BigQuery de asemenea. Dacă cineva l-a folosit, atunci știe că acolo poți rula mai multe solicitări și poți primi dintr-o dată o factură de sute de dolari.

ClickHouse nu are aceste probleme.

Unde se folosește acum ClickHouse? Pe lângă Yandex, ClickHouse este folosit într-o mulțime de afaceri și companii diferite.

• În primul rând, aceasta este analiza aplicațiilor web, adică acesta este un caz de utilizare care a venit de la Yandex.
• Multe companii AdTech folosesc ClickHouse.
• Numeroase companii care trebuie să analizeze jurnalele de tranzacții din diferite surse.
• Mai multe companii folosesc ClickHouse pentru a monitoriza jurnalele de securitate. Le încarcă în ClickHouse, fac rapoarte și obțin rezultatele de care au nevoie.
• Companiile încep să-l folosească în analiza financiară, adică treptat marile afaceri se apropie și de ClickHouse.
• flare de nori. Dacă cineva urmează ClickHouse, atunci probabil că a auzit numele acestei companii. Acesta este unul dintre contributorii esențiali din comunitate. Și au o instalare ClickHouse foarte serioasă. De exemplu, au făcut Kafka Engine pentru ClickHouse.
• Companiile de telecomunicații au început să folosească. Mai multe companii folosesc ClickHouse fie ca dovadă a conceptului, fie deja în producție.
• O companie folosește ClickHouse pentru a monitoriza procesele de producție. Ei testează microcircuite, elimină o grămadă de parametri, există aproximativ 2 de caracteristici. Și apoi analizează dacă jocul este bun sau rău.
• Analiza blockchain. Există o astfel de companie rusă ca Bloxy.info. Aceasta este o analiză a rețelei Ethereum. Au făcut acest lucru și pe ClickHouse.

Și dimensiunea nu contează. Există multe companii care folosesc un server mic. Și le permite să-și rezolve problemele. Și chiar mai multe companii folosesc clustere mari de mai multe servere sau zeci de servere.

Și dacă te uiți la înregistrări, atunci:

• Yandex: peste 500 de servere, acestea stochează acolo 25 de miliarde de înregistrări pe zi.
• LifeStreet: 60 de servere, aproximativ 75 de miliarde de înregistrări pe zi. Există mai puține servere, mai multe înregistrări decât în ​​Yandex.
• CloudFlare: 36 de servere, economisesc 200 de miliarde de înregistrări pe zi. Au și mai puține servere și stochează și mai multe date.
• Bloomberg: 102 servere, aproximativ un trilion de intrări pe zi. Deținătorul recordului.

Din punct de vedere geografic, acest lucru este, de asemenea, mult. Această hartă de aici arată o hartă termică a locurilor în care ClickHouse este utilizat în lume. Rusia, China, America se evidențiază clar aici. Sunt puține țări europene. Și sunt 4 clustere.

Aceasta este o analiză comparativă, nu este nevoie să căutați cifre absolute. Aceasta este o analiză a vizitatorilor care citesc materiale în limba engleză pe site-ul Altinity, deoarece acolo nu există altele vorbitoare de rusă. Și Rusia, Ucraina, Belarus, adică partea de limbă rusă a comunității, aceștia sunt cei mai numeroși utilizatori. Apoi urmează SUA și Canada. China este foarte mult din urmă. Aproape că nu era nicio China acolo în urmă cu șase luni, acum China a depășit deja Europa și continuă să crească. Vechea Europa nu este nici pe departe în urmă, iar liderul în utilizarea ClickHouse este, în mod ciudat, Franța.

De ce spun toate astea? Pentru a arăta că ClickHouse devine o soluție standard pentru analiza datelor mari și este deja folosită în multe locuri. Dacă îl folosești, ești în tendința potrivită. Dacă nu îl folosiți încă, atunci nu vă puteți teme că veți rămâne singur și nimeni nu vă va ajuta, pentru că mulți deja fac asta.

Acestea sunt exemple de utilizare reală a ClickHouse în mai multe companii.

• Primul exemplu este o rețea publicitară: migrarea de la Vertica la ClickHouse. Și cunosc câteva companii care au trecut de la Vertica sau sunt în proces de tranziție.
• Al doilea exemplu este stocarea tranzacțională pe ClickHouse. Acesta este un exemplu construit pe antipatterns. Tot ceea ce nu ar trebui făcut în ClickHouse la sfatul dezvoltatorilor se face aici. Și este făcut atât de eficient încât funcționează. Și funcționează mult mai bine decât soluția tranzacțională tipică.
• Al treilea exemplu este calculul distribuit pe ClickHouse. A existat o întrebare despre cum poate fi integrat ClickHouse în ecosistemul Hadoop. Voi arăta un exemplu despre modul în care o companie a făcut ceva similar cu un container de reducere a hărților pe ClickHouse, ținând evidența localizării datelor etc., pentru a calcula o sarcină foarte netrivială.

• LifeStreet este o companie Ad Tech care are toată tehnologia care vine cu o rețea publicitară.
• Ea este implicată în optimizarea anunțurilor, licitarea programatică.
• O mulțime de date: aproximativ 10 miliarde de evenimente pe zi. În același timp, evenimentele de acolo pot fi împărțite în mai multe sub-evenimente.
• Există mulți clienți ai acestor date și aceștia nu sunt doar oameni, ci mult mai mult - aceștia sunt diverși algoritmi care sunt implicați în licitarea programatică.

Compania a parcurs un drum lung și spinos. Și am vorbit despre asta pe HighLoad. Mai întâi, LifeStreet s-a mutat de la MySQL (cu o scurtă oprire la Oracle) la Vertica. Și puteți găsi o poveste despre asta.

Și totul a fost foarte bine, dar a devenit rapid clar că datele cresc și Vertica este scumpă. Prin urmare, s-au căutat diverse alternative. Unele dintre ele sunt enumerate aici. Și, de fapt, am făcut dovada conceptului sau, uneori, teste de performanță pentru aproape toate bazele de date care au fost disponibile pe piață din anul 13 până în al 16-lea și care erau aproximativ adecvate din punct de vedere al funcționalității. Și am vorbit și despre unele dintre ele pe HighLoad.

Sarcina a fost să migrem de la Vertica în primul rând, deoarece datele au crescut. Și au crescut exponențial de-a lungul anilor. Apoi au mers pe raft, dar totuși. Și prezicând această creștere, cerințele de afaceri pentru cantitatea de date pe care trebuia făcută un fel de analiză, era clar că petaocteți aveau să fie discutați în curând. Și plata pentru petabytes este deja foarte scumpă, așa că căutam o alternativă unde să mergem.

Unde să mergem? Și multă vreme nu a fost deloc clar încotro să se îndrepte, pentru că pe de o parte există baze de date comerciale, par să funcționeze bine. Unele funcționează aproape la fel de bine ca Vertica, altele mai rău. Dar toate sunt scumpe, nimic mai ieftin și mai bun nu a putut fi găsit.

Pe de altă parte, există soluții open source, care nu sunt foarte numeroase, adică pentru analiză, pot fi numărate pe degete. Și sunt gratuite sau ieftine, dar lente. Și adesea le lipsește funcționalitatea necesară și utilă.

Și nu a fost nimic care să combine binele care se află în bazele de date comerciale și tot ce este gratuit în sursa deschisă.

Nu a fost nimic până când, în mod neașteptat, Yandex a scos ClickHouse, ca un magician dintr-o pălărie, ca un iepure. Și a fost o decizie neașteptată, ei încă pun întrebarea: „De ce?”, Dar totuși.

Și imediat, în vara lui 2016, am început să ne uităm la ce este ClickHouse. Și s-a dovedit că uneori poate fi mai rapid decât Vertica. Am testat diferite scenarii pe diferite interogări. Și dacă interogarea a folosit doar un tabel, adică fără alăturari (join), atunci ClickHouse a fost de două ori mai rapid decât Vertica.

Nu am fost prea leneș și m-am uitat zilele trecute la testele Yandex. Acolo este la fel: ClickHouse este de două ori mai rapid decât Vertica, așa că ei vorbesc des despre asta.

Dar dacă există asocieri în interogări, atunci totul se dovedește a nu foarte clar. Și ClickHouse poate fi de două ori mai lent decât Vertica. Și dacă corectați ușor cererea și o rescrieți, atunci acestea sunt aproximativ egale. Nu-i rău. Și gratuit.

Și după ce a primit rezultatele testului și privindu-l din unghiuri diferite, LifeStreet a mers la ClickHouse.

Acesta este al 16-lea an, vă reamintesc. Era ca o glumă despre șoareci care plângeau și se înțepau, dar continuau să mănânce cactusul. Și acest lucru a fost descris în detaliu, există un videoclip despre asta etc.

Prin urmare, nu voi vorbi despre asta în detaliu, voi vorbi doar despre rezultate și despre câteva lucruri interesante despre care nu am vorbit atunci.

Rezultatele sunt:

• Migrare reușită și mai bine de un an sistemul funcționează deja în producție.
• Productivitatea și flexibilitatea au crescut. Din cele 10 miliarde de înregistrări pe care ne-am putea permite să le stocăm pe zi și apoi pentru o perioadă scurtă de timp, LifeStreet stochează acum 75 de miliarde de înregistrări pe zi și poate face acest lucru timp de 3 luni sau mai mult. Dacă numărați la vârf, atunci acesta este până la un milion de evenimente pe secundă. În acest sistem ajung zilnic peste un milion de interogări SQL, majoritatea de la diferiți roboți.
• În ciuda faptului că au fost folosite mai multe servere pentru ClickHouse decât pentru Vertica, acestea au făcut economii și pe hardware, deoarece în Vertica au fost folosite discuri SAS destul de scumpe. ClickHouse a folosit SATA. Și de ce? Pentru că în Vertica insertul este sincron. Și sincronizarea necesită ca discurile să nu încetinească prea mult și, de asemenea, ca rețeaua să nu încetinească prea mult, adică o operațiune destul de costisitoare. Și în ClickHouse inserarea este asincronă. Mai mult, puteți scrie oricând totul local, nu există costuri suplimentare pentru asta, astfel încât datele pot fi inserate în ClickHouse mult mai rapid decât în ​​Vertika, chiar și pe unități mai lente. Și cititul este cam la fel. Citind pe SATA, dacă sunt în RAID, atunci totul este suficient de rapid.
• Nu este limitat de licență, adică 3 petaocteți de date pe 60 de servere (20 de servere reprezintă o replică) și 6 trilioane de înregistrări în fapte și agregate. Nimic de genul acesta nu putea fi permis la Vertica.

Mă întorc acum la lucruri practice din acest exemplu.

• Prima este o schemă eficientă. Multe depind de schema.
• Al doilea este generarea eficientă de SQL.

O interogare tipică OLAP este o selectare. Unele dintre coloane merg la grupare după, unele dintre coloane merg la funcții de agregare. Există unde, care poate fi reprezentat ca o felie de cub. Întregul grup poate fi gândit ca o proiecție. Și de aceea se numește analiză multivariată a datelor.

Și adesea acest lucru este modelat sub forma unei scheme stelare, când există un fapt central și caracteristici ale acestui fapt de-a lungul părților laterale, de-a lungul razelor.

Și în ceea ce privește designul fizic, cum se potrivește pe masă, de obicei fac o reprezentare normalizată. Puteți denormaliza, dar este scump pe disc și nu foarte eficient la interogări. Prin urmare, ei fac de obicei o reprezentare normalizată, adică un tabel de fapte și multe, multe tabele de dimensiuni.

Dar nu funcționează bine în ClickHouse. Există două motive:

• Primul este pentru că ClickHouse nu are join-uri foarte bune, adică există join-uri, dar sunt proaste. În timp ce rău.
• Al doilea este că tabelele nu sunt actualizate. De obicei, în aceste plăci, care se află în jurul circuitului stea, ceva trebuie schimbat. De exemplu, numele clientului, numele companiei etc. Și nu funcționează.

Și există o cale de ieșire din asta în ClickHouse. chiar si doua:

• Prima este utilizarea dicționarelor. Dicționarele externe sunt cele care ajută 99% să rezolve problema cu schema stea, cu actualizări și așa mai departe.
• Al doilea este utilizarea matricelor. Matricele ajută, de asemenea, la eliminarea îmbinărilor și a problemelor cu normalizarea.

• Nu este necesară înscrierea.
• Upgradabil. Din martie 2018, a apărut o oportunitate nedocumentată (nu veți găsi acest lucru în documentație) de a actualiza parțial dicționarele, adică acele intrări care s-au schimbat. Practic, este ca o masă.
• Întotdeauna în memorie, așa că uniunile cu un dicționar funcționează mai repede decât dacă ar fi un tabel care este pe disc și nu este încă un fapt că este în cache, cel mai probabil nu.

• Nici nu ai nevoie de uniuni.
• Aceasta este o reprezentare compactă de la 1 la mulți.
• Și după părerea mea, matricele sunt făcute pentru tocilari. Acestea sunt funcții lambda și așa mai departe.

Acest lucru nu este pentru cuvinte roșii. Aceasta este o funcționalitate foarte puternică care vă permite să faceți multe lucruri într-un mod foarte simplu și elegant.

Exemple tipice care ajută la rezolvarea matricelor. Aceste exemple sunt destul de simple și clare:

• Căutați după etichete. Dacă aveți hashtag-uri acolo și doriți să găsiți câteva postări după hashtag.
• Căutați după perechi cheie-valoare. Există, de asemenea, unele atribute cu o valoare.
• Stocarea listelor de chei pe care trebuie să le traduceți în altceva.

Toate aceste sarcini pot fi rezolvate fără matrice. Etichetele pot fi puse într-o linie și selectate cu o expresie regulată sau într-un tabel separat, dar apoi trebuie să faceți alinări.

Și în ClickHouse, nu trebuie să faceți nimic, este suficient să descrieți matricea de șiruri pentru hashtag-uri sau să faceți o structură imbricată pentru sistemele cheie-valoare.

Structura imbricată poate să nu fie cel mai bun nume. Acestea sunt două matrice care au o parte comună în nume și unele caracteristici asociate.

Și este foarte ușor să cauți după etichetă. Au o funcție has, care verifică dacă tabloul conține un element. Toată lumea, a găsit toate intrările care se referă la conferința noastră.

Căutarea după subid este puțin mai complicată. Mai întâi trebuie să găsim indexul cheii, apoi să luăm elementul cu acest index și să verificăm dacă această valoare este ceea ce avem nevoie. Cu toate acestea, este foarte simplu și compact.

Expresia regulată pe care ai vrea să o scrii dacă ai păstra totul într-un singur rând, ar fi, în primul rând, stângace. Și, în al doilea rând, a funcționat mult mai mult decât două matrice.

Alt exemplu. Aveți o matrice în care stocați ID-ul. Și le poți traduce în nume. Funcţie arrayMap. Aceasta este o funcție tipică lambda. Treci acolo expresii lambda. Și ea scoate valoarea numelui pentru fiecare ID din dicționar.

Căutarea se poate face în același mod. Este transmisă o funcție predicat care verifică cu ce se potrivesc elementele.

Aceste lucruri simplifică foarte mult circuitul și rezolvă o grămadă de probleme.

Dar următoarea problemă cu care ne confruntăm și pe care aș dori să o menționez este interogările eficiente.

• ClickHouse nu are un planificator de interogări. Absolut nu.
• Cu toate acestea, interogările complexe trebuie încă să fie planificate. In ce cazuri?
• Dacă există mai multe alinări în interogare, le includeți în subselectări. Iar ordinea în care sunt executate contează.
• Și al doilea - dacă cererea este distribuită. Deoarece într-o interogare distribuită, doar subselectarea cea mai interioară este executată distribuită, iar orice altceva este transmis unui server la care v-ați conectat și executat acolo. Prin urmare, dacă ați distribuit interogări cu multe îmbinări (join), atunci trebuie să alegeți ordinea.

Și chiar și în cazuri mai simple, uneori este, de asemenea, necesar să faceți munca planificatorului și să rescrieți puțin interogările.

Iată un exemplu. În partea stângă este o interogare care arată primele 5 țări. Și durează 2,5 secunde, după părerea mea. Și în partea dreaptă, aceeași interogare, dar ușor rescrisă. În loc să grupăm după șir, am început să grupăm după cheie (int). Și este mai rapid. Și apoi am conectat un dicționar la rezultat. În loc de 2,5 secunde, cererea durează 1,5 secunde. Asta e bine.

Un exemplu similar cu filtrele de rescriere. Iată o cerere pentru Rusia. Se rulează timp de 5 secunde. Dacă îl rescriem în așa fel încât să comparăm din nou nu un șir, ci numere cu un set de acele chei care se referă la Rusia, atunci va fi mult mai rapid.

Există multe astfel de trucuri. Și vă permit să accelerați semnificativ interogările despre care credeți că rulează deja rapid sau, dimpotrivă, rulează încet. Ele pot fi făcute și mai repede.

• Lucru maxim în modul distribuit.
• Sortarea după tipuri minime, așa cum am făcut eu după int.
• Dacă există uniuni (join), dicționare, atunci este mai bine să le faceți ca ultimă soluție, când aveți deja date cel puțin parțial grupate, atunci operația de alăturare sau apelul de dicționar va fi apelat de mai puține ori și va fi mai rapid .
• Înlocuirea filtrelor.

Există și alte tehnici, și nu doar cele pe care le-am demonstrat. Și toate acestea pot uneori să accelereze semnificativ execuția interogărilor.

Să trecem la următorul exemplu. Compania X din SUA. Ce face ea?

A fost o sarcină:

• Conectarea offline a tranzacțiilor publicitare.
• Modelarea diferitelor modele de legare.

Care este scenariul?

Un vizitator obișnuit vine pe site, de exemplu, de 20 de ori pe lună din diferite reclame, sau chiar așa vine uneori fără reclame, pentru că își amintește acest site. Se uită la unele produse, le pune în coș, le scoate din coș. Și, până la urmă, ceva cumpără.

Întrebări rezonabile: „Cine ar trebui să plătească pentru publicitate, dacă este necesar?” și „Ce publicitate l-a influențat, dacă există?”. Adică de ce a cumpărat și cum să-i determine pe oameni ca această persoană să cumpere și ei?

Pentru a rezolva această problemă, trebuie să conectați în mod corect evenimentele care au loc pe site, adică să construiți cumva o conexiune între ele. Apoi sunt trimise spre analiză la DWH. Și pe baza acestei analize, construiți modele despre cine și ce anunțuri să afișați.

O tranzacție publicitară este un set de evenimente asociate utilizatorilor care pornesc de la afișarea unui anunț, apoi se întâmplă ceva, apoi poate o achiziție și apoi pot exista achiziții în cadrul unei achiziții. De exemplu, dacă aceasta este o aplicație mobilă sau un joc mobil, atunci, de obicei, instalarea aplicației are loc gratuit, iar dacă se face ceva acolo, atunci pot fi necesari bani pentru aceasta. Și cu cât o persoană cheltuiește mai mult în aplicație, cu atât este mai valoroasă. Dar pentru aceasta trebuie să conectați totul.

Există multe modele de legături.

Cele mai populare sunt:

• Ultima interacțiune, unde interacțiunea este fie un clic, fie o afișare.
• Prima interacțiune, adică primul lucru care a adus o persoană pe site.
• Combinație liniară - toate la fel.
• Atenuare.
• Și așa mai departe.

Și cum a funcționat totul în primul rând? Erau Runtime și Cassandra. Cassandra a fost folosită ca stocare a tranzacțiilor, adică toate tranzacțiile aferente au fost stocate în ea. Și când vine un eveniment în Runtime, de exemplu, afișând o pagină sau altceva, atunci i s-a făcut o solicitare Cassandrei - există sau nu o astfel de persoană. Apoi au fost obținute tranzacțiile care se referă la acesta. Și legătura s-a făcut.

Și dacă este norocos că cererea are un ID de tranzacție, atunci este ușor. Dar de obicei fără noroc. Prin urmare, a fost necesar să găsiți ultima tranzacție sau tranzacția cu ultimul clic etc.

Și totul a funcționat foarte bine atâta timp cât legarea a fost până la ultimul clic. Pentru că sunt, să zicem, 10 milioane de clicuri pe zi, 300 de milioane pe lună, dacă setăm o fereastră pentru o lună. Și din moment ce în Cassandra trebuie să fie totul în memorie pentru a rula rapid, pentru că Runtime-ul trebuie să răspundă rapid, a fost nevoie de aproximativ 10-15 servere.

Și când au vrut să lege o tranzacție de afișaj, sa dovedit imediat că nu a fost atât de distractiv. Și de ce? Se poate observa că trebuie stocate de 30 de ori mai multe evenimente. Și, în consecință, aveți nevoie de 30 de ori mai multe servere. Și se dovedește că acesta este un fel de cifră astronomică. Pentru a păstra până la 500 de servere pentru a face legătura, în ciuda faptului că există mult mai puține servere în Runtime, atunci aceasta este o cifră greșită. Și au început să se gândească ce să facă.

Și am mers la ClickHouse. Și cum se face pe ClickHouse? La prima vedere, se pare că acesta este un set de anti-modare.

• Tranzacția crește, conectăm tot mai multe evenimente la ea, adică este mutabilă, iar ClickHouse nu funcționează foarte bine cu obiectele mutabile.
• Când un vizitator vine la noi, trebuie să-i scoatem tranzacțiile prin cheie, după id-ul de vizită. Aceasta este, de asemenea, o interogare de punct, ei nu fac asta în ClickHouse. De obicei, ClickHouse are scanări mari, dar aici trebuie să obținem câteva înregistrări. De asemenea, un antimodel.
• În plus, tranzacția a fost în json, dar nu au vrut să o rescrie, așa că au vrut să stocheze json într-un mod nestructurat și, dacă este necesar, să scoată ceva din el. Și acesta este și un antimodel.

Adică un set de antipatterns.

Dar, cu toate acestea, sa dovedit a face un sistem care a funcționat foarte bine.

Ce sa făcut? A apărut ClickHouse, în care au fost aruncate bușteni, împărțite în înregistrări. A apărut un serviciu atribuit care a primit jurnale de la ClickHouse. După aceea, pentru fiecare intrare, prin ID de vizită, am primit tranzacții care ar putea să nu fi fost încă procesate și plus instantanee, adică tranzacții deja conectate, și anume rezultatul muncii anterioare. Am făcut deja logica din ele, am ales tranzacția corectă, am conectat evenimente noi. Conectat din nou. Jurnalul a revenit la ClickHouse, adică este un sistem constant ciclic. Și în plus, am fost la DWH să o analizez acolo.

În această formă nu a funcționat prea bine. Și pentru a face mai ușor pentru ClickHouse, atunci când a existat o solicitare după id-ul de vizită, au grupat aceste solicitări în blocuri de 1-000 de ID-uri de vizită și au scos toate tranzacțiile pentru 2-000 de persoane. Și apoi totul a funcționat.

Dacă te uiți în interiorul ClickHouse, atunci există doar 3 mese principale care servesc toate acestea.

Primul tabel în care sunt încărcate jurnalele, iar jurnalele sunt încărcate aproape fără procesare.

A doua masă. Prin viziunea materializată, evenimentele care nu au fost încă atribuite, adică cele fără legătură, au fost mușcate din aceste jurnalele. Și prin vizualizarea materializată, tranzacțiile au fost scoase din aceste jurnale pentru a construi un instantaneu. Adică, o vedere materializată specială a construit un instantaneu, și anume ultima stare acumulată a tranzacției.

Iată textul scris în SQL. Aș dori să comentez câteva lucruri importante în ea.

Primul lucru important este capacitatea de a extrage coloane și câmpuri din json în ClickHouse. Adică, ClickHouse are câteva metode de lucru cu json. Sunt foarte, foarte primitivi.

visitParamExtractInt vă permite să extrageți atribute din json, adică prima lovitură funcționează. Și în acest fel puteți extrage id-ul tranzacției sau puteți vizita id. De data asta.

În al doilea rând, aici este folosit un câmp materializat complicat. Ce înseamnă? Aceasta înseamnă că nu îl puteți introduce în tabel, adică nu este inserat, este calculat și stocat la inserare. Când lipiți, ClickHouse face treaba pentru dvs. Și ceea ce aveți nevoie mai târziu este deja scos din json.

În acest caz, vizualizarea materializată este pentru rândurile brute. Și primul tabel cu bușteni practic bruti este doar folosit. Și ce face? În primul rând, schimbă sortarea, adică sortarea se face acum după id-ul vizitei, deoarece trebuie să scoatem rapid tranzacția pentru o anumită persoană.

Al doilea lucru important este index_granularity. Dacă ați văzut MergeTree, de obicei este 8 implicit index_granularity. Ce este? Acesta este parametrul de raritate al indicelui. În ClickHouse indexul este rar, nu indexează niciodată fiecare intrare. Face acest lucru la fiecare 192 8. Și acest lucru este bine atunci când sunt necesare o mulțime de date pentru a fi calculate, dar rău când sunt puține, deoarece există o suprasarcină mare. Și dacă reducem granularitatea indicelui, atunci reducem supraîncărcarea. Nu poate fi redus la unul, pentru că s-ar putea să nu existe suficientă memorie. Indexul este întotdeauna stocat în memorie.

Snapshot folosește și alte caracteristici interesante ClickHouse.

În primul rând, este AggregatingMergeTree. Și AggregatingMergeTree stochează argMax, adică aceasta este starea tranzacției corespunzătoare ultimului marcaj temporal. Tranzacțiile sunt generate tot timpul pentru un anumit vizitator. Și în ultima stare a acestei tranzacții, am adăugat un eveniment și avem o stare nouă. A lovit ClickHouse din nou. Și prin argMax în această vedere materializată, putem obține întotdeauna starea curentă.

• Legarea este „decuplată” de Runtime.
• Sunt stocate și procesate până la 3 miliarde de tranzacții pe lună. Acesta este un ordin de mărime mai mare decât a fost în Cassandra, adică într-un sistem tranzacțional tipic.
• Cluster de servere ClickHouse 2x5. 5 servere și fiecare server are o replică. Acest lucru este chiar mai mic decât a fost în Cassandra pentru a face atribuire bazată pe clic, iar aici avem bazate pe impresii. Adică, în loc să crească numărul de servere de 30 de ori, au reușit să le reducă.

Iar ultimul exemplu este compania financiară Y, care a analizat corelațiile modificărilor prețurilor acțiunilor.

Iar sarcina a fost:

• Există aproximativ 5 de acțiuni.
• Se cunosc cotațiile la fiecare 100 de milisecunde.
• Datele au fost acumulate pe parcursul a 10 ani. Aparent, pentru unele companii mai mult, pentru unele mai puțin.
• Există aproximativ 100 de miliarde de rânduri în total.

Și a fost necesar să se calculeze corelația schimbărilor.

Iată două acțiuni și cotațiile lor. Dacă unul urcă și celălalt crește, atunci aceasta este o corelație pozitivă, adică unul urcă și celălalt crește. Dacă unul urcă, ca la sfârșitul graficului, iar celălalt coboară, atunci aceasta este o corelație negativă, adică atunci când unul crește, celălalt scade.

Analizând aceste schimbări reciproce, se pot face predicții pe piața financiară.

Dar sarcina este dificilă. Ce se face pentru asta? Avem 100 de miliarde de înregistrări care au: timp, stoc și preț. Trebuie să calculăm primele 100 de miliarde de ori diferența curentă față de algoritmul de preț. RunningDifference este o funcție din ClickHouse care calculează secvențial diferența dintre două șiruri.

Și după aceea, trebuie să calculați corelația, iar corelația trebuie calculată pentru fiecare pereche. Pentru 5 de acțiuni, perechile sunt 000 milioane. Și acest lucru este mult, adică de 12,5 ori este necesar să se calculeze o astfel de funcție de corelare.

Și dacă cineva a uitat, atunci ͞x și ͞y sunt șahmat. așteptarea eșantionării. Adică, este necesar nu numai să se calculeze rădăcinile și sumele, ci și încă o sumă în interiorul acestor sume. O grămadă de calcule trebuie făcute de 12,5 milioane de ori și chiar grupate pe ore. Avem și o mulțime de ore. Și trebuie să o faci în 60 de secunde. Este o gluma.

Era necesar să avem timp măcar cumva, pentru că toate acestea au funcționat foarte, foarte încet înainte să vină ClickHouse.

Au încercat să o calculeze pe Hadoop, pe Spark, pe Greenplum. Și toate acestea au fost foarte lente sau costisitoare. Adică se putea calcula cumva, dar apoi era scump.

Și apoi a apărut ClickHouse și lucrurile s-au îmbunătățit mult.

Vă reamintesc că avem o problemă cu localitatea datelor, deoarece corelațiile nu pot fi localizate. Nu putem pune unele date pe un server, altele pe altul și calcula, trebuie să avem toate datele peste tot.

Ce au facut? Inițial, datele sunt localizate. Fiecare server stochează date despre prețul unui anumit set de acțiuni. Și nu se suprapun. Prin urmare, este posibil să se calculeze logReturn în paralel și independent, toate acestea se întâmplă până acum în paralel și distribuite.

Apoi am decis să reducem aceste date, fără a pierde expresivitate. Reduceți utilizarea matricelor, adică pentru fiecare perioadă de timp, creați o serie de stocuri și o serie de prețuri. Prin urmare, ocupă mult mai puțin spațiu de date. Și este puțin mai ușor de lucrat cu ele. Acestea sunt operații aproape paralele, adică citim parțial în paralel și apoi scriem pe server.

După aceea, poate fi replicat. Litera „r” înseamnă că am replicat aceste date. Adică avem aceleași date pe toate cele trei servere - acestea sunt matricele.

Și apoi, cu un script special din acest set de 12,5 milioane de corelații care trebuie calculate, puteți face pachete. Adică 2 de sarcini cu 500 de perechi de corelații. Și această sarcină trebuie calculată pe un anumit server ClickHouse. El are toate datele, pentru că datele sunt aceleași și le poate calcula secvenţial.

Încă o dată, așa arată. În primul rând, avem toate datele din această structură: timp, acțiuni, preț. Apoi am calculat logReturn, adică date din aceeași structură, dar în loc de preț avem deja logReturn. Apoi au fost refăcute, adică am primit timpul și groupArray pentru stocuri și prețuri. Sreplicat. Și după aceea, am generat o grămadă de sarcini și le-am alimentat ClickHouse, astfel încât să le numere. Și funcționează.

Pe dovezi de concept, sarcina a fost o subsarcină, adică s-au luat mai puține date. Și doar trei servere.

Primele două etape: calcularea Log_return și împachetarea în matrice au durat aproximativ o oră.

Iar calculul corelației este de aproximativ 50 de ore. Dar 50 de ore nu sunt suficiente, pentru că ei lucrau săptămâni întregi. A fost un mare succes. Și dacă numărați, atunci de 70 de ori pe secundă totul a fost numărat pe acest cluster.

Dar cel mai important lucru este că acest sistem este practic fără blocaje, adică se scalează aproape liniar. Și l-au verificat. S-a mărit cu succes.

• Schema corectă este jumătate din succes. Și schema potrivită este utilizarea tuturor tehnologiilor ClickHouse necesare.
• Summing/AggregatingMergeTrees sunt tehnologii care vă permit să agregați sau să considerați un instantaneu de stare ca un caz special. Și simplifică foarte mult o mulțime de lucruri.
• Vizualizările materializate vă permit să ocoliți limita unui singur index. Poate că nu am spus-o foarte clar, dar când am încărcat jurnalele, jurnalele brute erau în tabel cu un singur index, iar jurnalele de atribute erau în tabel, adică aceleași date, doar filtrate, dar indexul era complet alții. Par a fi aceleași date, dar sortare diferită. Și Materialized Views vă permite, dacă aveți nevoie, să ocoliți o astfel de limitare ClickHouse.
• Reduceți granularitatea indexului pentru interogările punctuale.
• Și distribuiți datele în mod inteligent, încercați să localizați datele pe server cât mai mult posibil. Și încercați să vă asigurați că cererile folosesc și localizarea, acolo unde este posibil, cât mai mult posibil.

Și rezumând acest scurt discurs, putem spune că ClickHouse a ocupat acum ferm teritoriul atât al bazelor de date comerciale, cât și al bazelor de date open source, adică în mod specific pentru analiză. Se încadrează perfect în acest peisaj. Și mai mult, încet începe să-i scoată pe alții, pentru că atunci când ai ClickHouse, nu ai nevoie de InfiniDB. Este posibil ca Vertika să nu fie nevoie în curând dacă oferă suport SQL normal. Bucurați-vă!

-Multumesc pentru raport! Foarte interesant! Au existat comparații cu Apache Phoenix?

Nu, nu am auzit pe nimeni să se compare. Noi și Yandex încercăm să urmărim toate comparațiile ClickHouse cu diferite baze de date. Pentru că, dacă dintr-o dată ceva se dovedește a fi mai rapid decât ClickHouse, atunci Lesha Milovidov nu poate dormi noaptea și începe să accelereze rapid. Nu am auzit de o asemenea comparație.

• (Aleksey Milovidov) Apache Phoenix este un motor SQL alimentat de Hbase. Hbase este în principal pentru scenariul de lucru cheie-valoare. Acolo, în fiecare linie, poate exista un număr arbitrar de coloane cu nume arbitrare. Acest lucru se poate spune despre sisteme precum Hbase, Cassandra. Și tocmai interogările analitice grele nu vor funcționa normal pentru ele. Sau ați putea crede că funcționează bine dacă nu ați avut nicio experiență cu ClickHouse.

• mulțumesc

  • Bună ziua Sunt deja destul de interesat de acest subiect, deoarece am un subsistem analitic. Dar când mă uit la ClickHouse, am senzația că ClickHouse este foarte potrivit pentru analiza evenimentelor, mutabil. Și dacă am nevoie să analizez o mulțime de date de afaceri cu o grămadă de tabele mari, atunci ClickHouse, din câte am înțeles, nu este foarte potrivit pentru mine? Mai ales dacă se schimbă. Este corect sau există exemple care pot infirma acest lucru?

  • Asta e corect. Și acest lucru este valabil pentru majoritatea bazelor de date analitice specializate. Ele sunt adaptate pentru faptul că există una sau mai multe mese mari care sunt mutabile și pentru multe altele mici care se schimbă lent. Adică ClickHouse nu este ca Oracle, unde poți pune totul și construi niște interogări foarte complexe. Pentru a utiliza ClickHouse în mod eficient, trebuie să construiți o schemă într-un mod care să funcționeze bine în ClickHouse. Adică evitați normalizarea excesivă, folosiți dicționare, încercați să faceți mai puține link-uri lungi. Și dacă schema este construită în acest fel, atunci sarcini similare de afaceri pot fi rezolvate pe ClickHouse mult mai eficient decât pe o bază de date relațională tradițională.

Multumesc pentru raport! Am o întrebare despre ultimul caz financiar. Aveau analize. A fost necesar să se compare cum urcă și coboară. Și înțeleg că ați construit sistemul special pentru această analiză? Dacă mâine, de exemplu, au nevoie de un alt raport cu privire la aceste date, trebuie să reconstruiască schema și să încarce datele? Adică să faci un fel de preprocesare pentru a primi cererea?

Desigur, aceasta este utilizarea ClickHouse pentru o sarcină foarte specifică. Ar putea fi rezolvat mai tradițional în Hadoop. Pentru Hadoop, aceasta este o sarcină ideală. Dar pe Hadoop este foarte lent. Și scopul meu este să demonstrez că ClickHouse poate rezolva sarcini care sunt de obicei rezolvate prin mijloace complet diferite, dar în același timp o pot face mult mai eficient. Aceasta este adaptată pentru o anumită sarcină. Este clar că dacă există o problemă cu ceva asemănător, atunci poate fi rezolvată într-un mod similar.

Este clar. Ai spus că au fost procesate 50 de ore. Este de la bun început, când ați încărcat datele sau ați obținut rezultatele?

Da Da.

OK multumesc foarte mult.

Acesta este pe un cluster cu 3 servere.

Salutari! Multumesc pentru raport! Totul este foarte interesant. Nu voi întreba puțin despre funcționalitate, ci despre utilizarea ClickHouse în ceea ce privește stabilitatea. Adică ați avut vreunul, a trebuit să restaurați? Cum se comportă ClickHouse în acest caz? Și s-a întâmplat să ai și tu o replică? De exemplu, am întâlnit o problemă cu ClickHouse când încă iese din limită și cade.

Desigur, nu există sisteme ideale. Și ClickHouse are și propriile sale probleme. Dar ați auzit despre Yandex.Metrica care nu funcționează de mult? Probabil ca nu. Funcționează în mod fiabil din 2012-2013 pe ClickHouse. Pot spune același lucru despre experiența mea. Nu am avut niciodată eșecuri complete. S-ar putea întâmpla unele lucruri parțiale, dar nu au fost niciodată suficient de critice pentru a afecta serios afacerea. Nu sa întâmplat niciodată. ClickHouse este destul de fiabil și nu se blochează la întâmplare. Nu trebuie să vă faceți griji pentru asta. Nu este un lucru brut. Acest lucru a fost dovedit de multe companii.

Buna ziua! Ai spus că trebuie să te gândești imediat la schema de date. Dacă s-a întâmplat? Datele mele se toarnă și se revarsă. Trec șase luni și înțeleg că este imposibil să trăiești așa, trebuie să reîncarc datele și să fac ceva cu ele.

Acest lucru depinde desigur de sistemul dvs. Există mai multe moduri de a face acest lucru, practic fără oprire. De exemplu, puteți crea o vizualizare materializată în care să creați o structură de date diferită, dacă aceasta poate fi mapată în mod unic. Adică, dacă permite maparea folosind ClickHouse, adică extrageți unele lucruri, schimbați cheia primară, schimbați partiționarea, atunci puteți face o Vedere Materializată. Suprascrieți datele vechi acolo, altele noi vor fi scrise automat. Și apoi treceți la utilizarea Vizualizării materializate, apoi schimbați înregistrarea și omorâți vechea masă. Aceasta este, în general, o metodă non-stop.

Mulțumesc.

Sursa: www.habr.com