Malgradu u fattu chì ci hè avà assai dati quasi in ogni locu, e basa di dati analitiche sò sempre abbastanza esotiche. Sò pocu cunnisciuti è ancu peggiu capaci di usà in modu efficace. Parechje cuntinueghjanu à "mangà cactus" cù MySQL o PostgreSQL, chì sò pensati per altri scenarii, soffrenu cù NoSQL, o overpay per suluzioni cummerciale. ClickHouse cambia e regule di u ghjocu è riduce significativamente u sogliu per entra in u mondu di DBMS analiticu.
Rapportu da BackEnd Conf 2018 è hè publicatu cù u permessu di u parlante.
Quale sò eiu è perchè parlu di ClickHouse ? Sò un direttore di sviluppu in LifeStreet, chì usa ClickHouse. Inoltre, sò u fundatore di Altinity. Hè un cumpagnu Yandex chì prumove ClickHouse è aiuta Yandex à fà ClickHouse più successu. Ancu prontu à sparte cunniscenze nantu à ClickHouse.
È ùn sò micca u fratellu di Petya Zaitsev. Sò spessu dumandatu nantu à questu. Innò, ùn simu fratelli.
"Tutti sà" chì ClickHouse:
- Assai prestu,
- Moltu còmode
- Adupratu in Yandex.
Un pocu menu hè cunnisciutu in quale cumpagnie è cumu si usa.
Vi dicu perchè, induve è cumu si usa ClickHouse, eccettu Yandex.
Vi dicu cumu si risolve i compiti specifichi cù l'aiutu di ClickHouse in diverse cumpagnie, quali strumenti ClickHouse pudete aduprà per i vostri compiti, è cumu sò stati utilizati in diverse cumpagnie.
Aghju pigliatu trè esempi chì mostranu ClickHouse da diverse anguli. Pensu chì serà interessante.
A prima quistione hè: "Perchè avemu bisognu di ClickHouse?". Sembra esse una quistione abbastanza ovvia, ma ci sò più di una risposta à questu.
- A prima risposta hè per u rendiment. ClickHouse hè assai veloce. Analytics in ClickHouse hè ancu assai veloce. Pò esse spessu usatu induve qualcosa altru hè assai lenta o assai male.
- A seconda risposta hè u costu. È prima di tuttu, u costu di scaling. Per esempiu, Vertica hè una basa di dati assolutamente fantastica. Funziona assai bè sè ùn avete micca assai terabytes di dati. Ma quandu si tratta di centinaie di terabyte o petabyte, u costu di una licenza è un supportu entra in una quantità abbastanza significativa. È hè caru. È ClickHouse hè liberu.
- A terza risposta hè u costu operativu. Questu hè un approcciu un pocu sfarente. RedShift hè un grande analogu. In RedShift, pudete piglià una decisione assai rapidamente. Funcionà bè, ma à u stessu tempu, ogni ora, ogni ghjornu è ogni mese, pagherete Amazon abbastanza caru, perchè questu hè un serviziu significativamente caru. Google BigQuery ancu. Se qualchissia l'hà utilizatu, allora sapi chì quì pudete eseguisce parechje dumande è uttene una fattura per centinaie di dollari di colpu.
ClickHouse ùn hà micca questi prublemi.
Induve si usa ClickHouse avà? In più di Yandex, ClickHouse hè utilizatu in una mansa di diverse imprese è cumpagnie.
- Prima di tuttu, questu hè l'analitica di l'applicazioni web, vale à dì questu hè un casu d'usu chì vene da Yandex.
- Parechje cumpagnie AdTech utilizanu ClickHouse.
- Numerose cumpagnie chì anu bisognu di analizà i logs di transazzione da diverse fonti.
- Diversi cumpagnie utilizanu ClickHouse per monitorizà i logs di sicurezza. Li caricanu in ClickHouse, facenu rapporti è uttene i risultati chì anu bisognu.
- L'imprese cumincianu à aduprà in l'analisi finanziaria, vale à dì chì i grandi imprese si avvicinanu ancu à ClickHouse.
- nuvola. Se qualchissia seguita ClickHouse, allora probabilmente anu intesu u nome di sta cumpagnia. Questu hè unu di i cuntributori essenziali da a cumunità. È anu una stallazione ClickHouse assai seria. Per esempiu, anu fattu Kafka Engine per ClickHouse.
- L'imprese di telecomunicazioni cuminciaru à aduprà. Diversi cumpagnie utilizanu ClickHouse sia cum'è prova di cuncettu o digià in produzzione.
- Una cumpagnia usa ClickHouse per monitorà i prucessi di produzzione. Testanu i microcircuiti, scrivenu una mansa di parametri, ci sò circa 2 caratteristiche. E poi analizanu se u ghjocu hè bonu o cattivu.
- Analitiche Blockchain. Ci hè una cumpagnia russa cum'è Bloxy.info. Questu hè un analisi di a reta di ethereu. Anu ancu fattu questu nantu à ClickHouse.
È a taglia ùn importa micca. Ci sò parechje cumpagnie chì utilizanu un servitore chjucu. È li permette di risolve i so prublemi. E ancu più cumpagnie utilizanu grandi clusters di parechji servitori o decine di servitori.
È se guardate i registri, allora:
- Yandex: più di 500 servitori, almacenanu 25 miliardi di dischi à ghjornu.
- LifeStreet: 60 servitori, circa 75 miliardi di dischi per ghjornu. Ci hè menu servitori, più record chì in Yandex.
- CloudFlare: 36 servitori, salvanu 200 miliardi di dischi à ghjornu. Hanu ancu menu servitori è almacenanu ancu più dati.
- Bloomberg: 102 servitori, circa un trilione di entrate per ghjornu. Detentore di record.
Geograficamente, questu hè ancu assai. Questa mappa quì mostra una mappa di calore di induve ClickHouse hè adupratu in u mondu. A Russia, a Cina, l'America si distinguenu chjaramente quì. Ci sò pochi paesi europei. È ci sò 4 clusters.
Questu hè un analisi comparativu, ùn ci hè bisognu di circà i figuri assoluti. Questa hè una analisi di i visitori chì leghjenu materiali in lingua inglese in u situ web di Altinity, perchè ùn ci sò micca di lingua russa. E Russia, Ucraina, Bielorussia, vale à dì a parte russa di a cumunità, questi sò l'utilizatori più numerosi. Dopu vene i Stati Uniti è u Canada. Cina hè assai attrattiva. Ùn ci era quasi nisuna Cina sei mesi fà, avà a Cina hà digià superatu l'Europa è cuntinueghja à cresce. L'Europa antica ùn hè micca luntanu, è u capu in l'usu di ClickHouse hè, stranu, Francia.
Perchè dicu tuttu questu? Per dimustrà chì ClickHouse hè diventatu una suluzione standard per l'analisi di big data è hè digià utilizatu in parechji posti. Se l'utilizate, site in a tendenza ghjustu. Sè vo ùn sò ancu aduprà, allura vi pò esse paura chì vi sarà lasciatu solu è nimu vi aiuterà, perchè parechji sò digià fà questu.
Quessi sò esempi di u veru usu di ClickHouse in parechje cumpagnie.
- U primu esempiu hè una reta di publicità: migrazione da Vertica à ClickHouse. E cunnoscu uni pochi di cumpagnie chì anu transizione da Vertica o sò in u prucessu di transizione.
- U sicondu esempiu hè u almacenamentu transazionale nantu à ClickHouse. Questu hè un esempiu custruitu nantu à antipatterns. Tuttu ciò chì ùn deve esse fattu in ClickHouse nantu à i cunsiglii di sviluppatori hè fattu quì. È hè fattu cusì efficace chì funziona. È funziona assai megliu cà a suluzione transazionale tipica.
- U terzu esempiu hè l'informatica distribuita in ClickHouse. Ci era una quistione di cumu ClickHouse pò esse integrata in l'ecosistema Hadoop. Vi mustrarà un esempiu di cumu una cumpagnia hà fattu qualcosa di simile à una mappa di riduzzione di u containeru nantu à ClickHouse, seguitendu a localizazione di dati, etc., per calculà un compitu assai micca trivial.
- LifeStreet hè una cumpagnia di Ad Tech chì hà tutte e tecnulugia chì vene cun una reta publicitaria.
- Hè impegnata in l'ottimisazione di l'annunzii, l'offerta programmatica.
- Un saccu di dati: circa 10 miliardi di avvenimenti per ghjornu. À u listessu tempu, l'avvenimenti ponu esse divisu in parechji sub-eventi.
- Ci sò parechji clienti di sti dati, è questi ùn sò micca solu persone, assai più - sò parechji algoritmi chì sò impegnati in l'offerta programmatica.
A cumpagnia hà fattu una strada longa è spinosa. È ne aghju parlatu nantu à HighLoad. Prima, LifeStreet si trasfirìu da MySQL (cù una breve tappa à Oracle) à Vertica. È pudete truvà una storia nantu à questu.
È tuttu era assai bonu, ma prestu prestu chjaru chì i dati cresce è Vertica hè caru. Dunque, diverse alternative sò state cercate. Certi di elli sò listati quì. E in fattu, avemu fattu una prova di cuncettu o qualchì volta teste di rendiment di quasi tutte e basa di dati chì eranu dispunibili nantu à u mercatu da u 13 à u 16 annu è eranu apprussimatamente adattati in termini di funziunalità. È aghju ancu parlatu di alcuni di elli nantu à HighLoad.
U compitu era di migrà da Vertica in u primu locu, perchè i dati crescenu. È crescenu in modu esponenziale annantu à l'anni. Allora andonu nantu à u scaffale, ma quantunque. E predichendu sta crescita, i bisogni di l'affari per a quantità di dati nantu à quale un tipu d'analitiche deve esse fattu, era chjaru chì i petabytes seranu prestu discututi. È pagà per petabytes hè digià assai caru, cusì avemu cercatu una alternativa induve andà.
Induve andà ? È per un bellu pezzu ùn era micca chjaru induve andà, perchè da una banda ci sò basa di dati cummirciali, parevanu travaglià bè. Certi travaglianu guasi cum'è Vertica, certi peggiu. Ma sò tutti caru, nunda di più prezzu è megliu ùn si pudia truvà.
Per d 'altra banda, ci sò suluzioni open source, chì ùn sò micca assai numerosi, vale à dì per l'analitiche, ponu esse cuntatu nantu à i diti. È sò liberi o boni, ma lentu. È spessu mancanu a funziunalità necessaria è utile.
È ùn ci era nunda di cumminà u bonu chì hè in basa di dati cummerciale è tuttu u liberu chì hè in open source.
Ùn ci era nunda finu à chì, inaspettatamente, Yandex tirava da ClickHouse, cum'è un magu da un cappellu, cum'è un cunigliu. È era una decisione inespettata, anu sempre a quistione: "Perchè?", Ma quantunque.
E subitu in l'estiu di 2016, avemu cuminciatu à vede ciò chì ClickHouse hè. È si girò fora chì qualchì volta pò esse più veloce chè Vertica. Avemu pruvatu diversi scenarii nantu à diverse richieste. È se a quistione hà utilizatu una sola tavola, vale à dì senza alcuna unisce (join), allora ClickHouse era duie volte più veloce di Vertica.
Ùn era micca troppu pigro è fighjulà i testi Yandex l'altru ghjornu. Hè listessa quì: ClickHouse hè duie volte più veloce di Vertica, cusì spessu ne parlanu.
Ma s'ellu ci sò cunghjunghjini in e dumande, allora tuttu risulta micca assai senza ambiguità. È ClickHouse pò esse duie volte lentu cum'è Vertica. È s'ellu curreghja pocu a dumanda è scrivite, allora sò apprussimatamente uguali. Micca male. È liberu.
È dopu avè ricevutu i risultati di a prova, è guardendu da diverse anguli, LifeStreet andò à ClickHouse.
Questu hè u 16u annu, vi ricordu. Era cum'è un scherzu nantu à i topi chì pienghjenu è si punzevanu, ma cuntinuavanu à manghjà u cactus. È questu hè statu descrittu in detail, ci hè un video nantu à questu, etc.
Dunque, ùn ne parleraghju micca in dettagliu, parleraghju solu di i risultati è uni pochi di cose interessanti chì ùn aghju micca parlatu allora.
I risultati sò:
- Migrazione successu è più di un annu u sistema hè digià travagliatu in a produzzione.
- A produttività è a flessibilità anu aumentatu. Di i 10 miliardi di dischi chì pudemu permette di almacenà per ghjornu è dopu per un pocu tempu, LifeStreet guarda avà 75 miliardi di dischi per ghjornu è pò fà questu per 3 mesi o più. Se cuntate à u piccu, allora questu hè finu à un milione di avvenimenti per seconda. Più di un milione di dumande SQL à ghjornu arrivanu in stu sistema, soprattuttu da diversi robots.
- Malgradu u fattu chì più servitori sò stati utilizati per ClickHouse cà per Vertica, anu ancu salvatu in hardware, perchè i dischi SAS piuttostu caru sò stati utilizati in Vertica. ClickHouse hà utilizatu SATA. È perchè ? Perchè in Vertica inserisci hè sincrona. È a sincronizazione esige chì i dischi ùn rallentate micca troppu, è ancu chì a reta ùn rallenta micca troppu, vale à dì una operazione piuttostu caru. È in ClickHouse l'inserimentu hè asincronu. Inoltre, pudete sempre scrive tuttu in u locu, ùn ci hè micca costu supplementu per questu, cusì i dati ponu esse inseriti in ClickHouse assai più veloce cà in Vertika, ancu in unità più lente. È a lettura hè quasi u listessu. Leghjendu nantu à SATA, se sò in RAID, allora tuttu hè abbastanza veloce.
- Micca limitatu da a licenza, vale à dì 3 petabyte di dati in 60 servitori (20 servitori hè una replica) è 6 trilioni di registri in fatti è aggregazioni. Rien ne pouvait être offert à Vertica.
Avà turnu à e cose pratiche in questu esempiu.
- U primu hè un schema efficace. Assai dipende di u schema.
- U sicondu hè a generazione SQL efficiente.
Una dumanda tipica OLAP hè una selezzione. Alcune di e culonne vanu à u gruppu per, alcune di e culonne vanu à e funzioni aggregate. Ci hè induve, chì pò esse rapprisintatu cum'è una fetta di un cubu. U gruppu tutale pò esse pensatu cum'è una projezzione. È per quessa hè chjamatu analisi di dati multivariate.
E spessu questu hè modellatu in a forma di una stella-schema, quandu ci hè un fattu cintrali è e caratteristiche di stu fattu longu i lati, longu i raghji.
È in quantu à u disignu fisicu, cumu si mette nantu à a tavula, di solitu facenu una rapprisintazioni normalizzata. Pudete denormalizà, ma hè caru nantu à u discu è micca assai efficace nantu à e dumande. Per quessa, di solitu facenu una rapprisintazioni nurmalizata, vale à dì una tavula di fatti è parechje tavule di dimensione.
Ma ùn funziona micca bè in ClickHouse. Ci sò dui mutivi:
- U primu hè perchè ClickHouse ùn hà micca assai boni uni, vale à dì chì ci sò uni, ma sò cattivi. Mentre male.
- U sicondu hè chì i tavule ùn sò micca aghjurnati. Di solitu in questi platti, chì sò intornu à u circuitu stella, qualcosa deve esse cambiatu. Per esempiu, u nome di u cliente, u nome di a cumpagnia, etc. È ùn viaghja micca.
È ci hè una manera di esce da questu in ClickHouse. ancu dui:
- U primu hè l'usu di dizionari. Dictionaries Esterni hè ciò chì aiuta 99% à risolve u prublema cù a stella-schema, cù l'aghjurnamenti è cusì.
- U sicondu hè l'usu di arrays. L'arrays aiutanu ancu à sbarazzà di l'unione è i prublemi cù a normalizazione.
- Ùn ci hè bisognu di unisce.
- Aghjurnà. Da marzu 2018, hè apparsa una opportunità senza documentu (ùn truverete micca questu in a ducumentazione) per aghjurnà parzialmente i dizionari, vale à dì quelli chì sò cambiati. In pratica, hè cum'è una tavola.
- Sempre in memoria, cusì unisce cù un dizziunariu travaglia più veloce chè s'ellu era una tavola chì hè nantu à u discu è ùn hè ancu un fattu chì hè in a cache, assai prubabilmente micca.
- Ùn avete micca bisognu di unisce ancu.
- Questa hè una rapprisintazioni compacta di 1 à parechji.
- È in u mo parè, i matrici sò fatti per i geeks. Quessi sò funzioni lambda è cusì.
Questu ùn hè micca per e parolle rosse. Questa hè una funziunalità assai putente chì permette di fà parechje cose in una manera assai simplice è elegante.
Esempii tipici chì aiutanu à risolve arrays. Questi esempi sò simplici è abbastanza chjaru:
- Ricerca per tag. Sì avete hashtags quì è vulete truvà qualchi posti per hashtag.
- Ricerca per coppie chjave-valore. Ci sò ancu qualchi attributi cù un valore.
- Almacene liste di chjavi chì avete bisognu di traduce in qualcosa d'altru.
Tutti issi compiti ponu esse risolti senza arrays. I tag ponu esse messi in una linea è selezziunati cù una espressione regulare o in una tavula separata, ma dopu avete da fà unisce.
È in ClickHouse, ùn avete micca bisognu di fà nunda, hè abbastanza per descriverà u array di stringa per l'hashtags o fà una struttura nidificata per i sistemi di chjave-valore.
A struttura nidificata pò esse micca u megliu nome. Quessi sò dui array chì anu una parte cumuna in u nome è alcune caratteristiche relative.
È hè assai faciule di circà per tag. Avè una funzione has, chì verifica chì u array cuntene un elementu. Tutti, truvate tutte e voci chì riguardanu a nostra cunferenza.
A ricerca per subid hè un pocu più complicata. Avemu bisognu di truvà prima l'indici di a chjave, è poi piglià l'elementu cù questu indice è verificate chì questu valore hè ciò chì avemu bisognu. Tuttavia, hè assai simplice è compactu.
L'espressione regulare chì vulete scrive si manteneva tuttu in una linea, seria, prima, goffa. È, in segundu, hà travagliatu assai più di dui array.
Un altru esempiu. Avete un array induve guardate l'ID. È pudete traduce in nomi. Funzione arrayMap. Questa hè una funzione tipica lambda. Passate espressioni lambda quì. È tira fora u valore di u nome per ogni ID da u dizziunariu.
A ricerca pò esse fatta in u listessu modu. Una funzione predicata hè passata chì verifica ciò chì l'elementi currispondenu.
Queste cose simplificà assai u circuitu è risolve una mansa di prublemi.
Ma u prossimu prublema chì avemu affruntatu, è chì vogliu mencionà, hè e dumande efficaci.
- ClickHouse ùn hà micca un pianificatore di quistione. Assolutamente micca.
- Tuttavia, e dumande cumplesse anu da esse pianificate. In quali casi?
- Se ci sò parechje unimenti in a dumanda, l'imbulighjate in sottoselezzioni. È l'ordine in quale sò eseguiti importa.
- È u sicondu - se a dumanda hè distribuita. Perchè in una dumanda distribuita, solu a subselezzione più interna hè eseguita distribuita, è tuttu u restu hè passatu à un servitore chì avete cunnessu è eseguitu quì. Dunque, s'è vo avete distribuitu dumande cù parechje unisce (join), allora avete bisognu di sceglie l'ordine.
E ancu in i casi più simplici, qualchì volta hè ancu necessariu di fà u travagliu di u pianificatore è di riscrivite e dumande un pocu.
Eccu un esempiu. A sinistra hè una dumanda chì mostra i primi 5 paesi. È ci vole 2,5 seconde, in my opinion. È à u latu drittu, a stessa dumanda, ma pocu riscritta. Invece di raggruppà per stringa, avemu cuminciatu à raggruppà per chjave (int). È hè più veloce. È dopu avemu cunnessu un dizziunariu à u risultatu. Invece di 2,5 seconde, a dumanda dura 1,5 seconde. Questu hè bonu.
Un esempiu simili cù i filtri di riscrittura. Eccu una dumanda per a Russia. Si corre per 5 seconde. Se l'avemu riscrivite in una manera chì paragunemu di novu micca una stringa, ma numeri cù qualchì settore di quelli chjavi chì riguardanu a Russia, allora serà assai più veloce.
Ci sò parechji tali trucchi. È vi permettenu di accelerà significativamente e dumande chì pensate chì sò digià in esecuzione veloce, o, à u cuntrariu, corre lentamente. Puderanu esse fatti ancu più veloce.
- U travagliu massimu in modu distribuitu.
- Sorting per tipi minimi, cum'è aghju fattu da ints.
- Se ci sò unizzioni (join), dizziunari, allora hè megliu per fà cum'è l'ultimu risorsu, quandu avete digià dati, almenu parzialmente raggruppati, allura l'operazione di unisce o chjama di dizziunariu serà chjamatu menu volte è serà più veloce. .
- Sostituzione di i filtri.
Ci sò altre tecniche, è micca solu quelli chì aghju dimustratu. È tutti ponu à volte accelerà significativamente l'esekzione di e dumande.
Andemu à u prossimu esempiu. Cumpagnia X da i Stati Uniti. Chì face ?
Ci era un compitu:
- Ligame offline di transazzioni publicitarii.
- Modellazione di diversi mudelli di rilegatura.
Chì ghjè u scenariu ?
Un visitatore ordinariu vene à u situ, per esempiu, 20 volte à u mese da diversi annunzii, o cum'è questu qualchì volta vene senza annunzii, perchè si ricorda di stu situ. Fighjate certi prudutti, i mette in a cesta, li piglia da a cestera. È, à a fine, qualcosa compra.
Questioni ragiunate: "Quale deve pagà per a publicità, se ne necessariu?" è "Chì publicità l'hà influenzatu, se ci hè?". Questu hè, perchè hà compru è cumu fà chì e persone cum'è sta persona cumprà ancu?
Per risolve stu prublema, avete bisognu di cunnette l'avvenimenti chì si trovanu in u situ web in u modu ghjustu, vale à dì, in qualchì manera di custruisce una cunnessione trà elli. Allora sò mandati per analisi à DWH. È basatu annantu à questa analisi, custruisce mudelli di quale è chì publicità per vede.
Una transazzione di publicità hè un inseme di avvenimenti d'utilizatori cunnessi chì partenu da mostrà un annunziu, dopu qualcosa succede, allora forsi una compra, è poi ci pò esse compra in una compra. Per esempiu, s'ellu hè una applicazione mobile o un ghjocu mobile, di solitu l'installazione di l'applicazione hè fatta gratuitamente, è se qualcosa hè fattu quì, allora i soldi pò esse necessariu per questu. E più una persona spende in l'applicazione, u più preziosu hè. Ma per questu avete bisognu di cunnette tuttu.
Ci sò parechji mudelli di ubligatoriu.
I più populari sò:
- Ultima Interazione, induve l'interazzione hè o un clic o una impressione.
- Prima Interazzione, vale à dì a prima cosa chì hà purtatu una persona à u situ.
- Combinazione lineare - tutti ugualmente.
- Attenuazione.
- Eccetera.
E cumu hà travagliatu tuttu in u primu locu? Ci era Runtime è Cassandra. Cassandra hè stata aduprata cum'è almacenamentu di transazzione, vale à dì chì tutte e transazzioni cunnesse sò state guardate in questu. È quandu qualchì avvenimentu vene in Runtime, per esempiu, chì mostra una pagina o qualcosa altru, allora una dumanda hè stata fatta à Cassandra - ci hè una tale persona o micca. Allora e transazzioni chì sò in relazione cù questu sò stati ottenuti. È a cunnessione hè stata fatta.
È s'ellu hè furtunatu chì a dumanda hà un id di transazzione, allora hè faciule. Ma di solitu ùn hè micca furtuna. Per quessa, era necessariu di truvà l'ultima transazzione o a transazzione cù l'ultimu clic, etc.
È tuttu hà travagliatu assai bè, finu à chì u vintu era à l'ultimu clic. Perchè ci sò, per esempiu, 10 milioni di clics per ghjornu, 300 milioni per mese, se avemu stabilitu una finestra per un mesi. E postu chì in Cassandra deve esse tuttu in memoria per esse curriri veloce, perchè u Runtime hà bisognu di risponde rapidamente, hà pigliatu circa 10-15 servitori.
È quandu anu vulsutu ligà una transazzione à a visualizazione, subitu hè diventatu micca cusì divertente. E perchè ? Pò esse vistu chì 30 volte più avvenimenti deve esse guardatu. È, dunque, avete bisognu di 30 volte più servitori. È risulta chì questu hè una figura astronomica. Per mantene sin'à 500 servitori per fà u ligame, malgradu u fattu chì ci sò assai menu servitori in Runtime, allora questu hè una figura sbagliata. È cuminciaru à pensà à ciò chì fà.
È andemu à ClickHouse. E cumu fà nantu à ClickHouse? À u primu sguardu, pare chì questu hè un inseme di anti-patterns.
- A transazzione cresce, aghjunghjimu più è più avvenimenti à questu, vale à dì hè mutabile, è ClickHouse ùn viaghja micca bè cù l'uggetti mutabili.
- Quandu un visitore vene à noi, avemu bisognu di tirà fora i so transazzione da chjave, da a so visita id. Questu hè ancu una quistione di puntu, ùn facenu micca in ClickHouse. Di solitu ClickHouse hà grandi ...scans, ma quì avemu bisognu di ottene qualchi registri. Ancu un antipattern.
- Inoltre, a transazzione era in json, ma ùn vulianu micca riscrivite, perchè vulianu almacenà json in modu micca strutturatu, è se ne necessariu, tira qualcosa fora di questu. È questu hè ancu un antipattern.
Questu hè, un inseme di antipatterns.
Ma, quantunque, hè risultatu per fà un sistema chì hà travagliatu assai bè.
Chì hè statu fattu ? Apparsu ClickHouse, in quale i ghjurnali sò stati ghjittati, divisu in registri. Un serviziu attribuitu apparsu chì hà ricevutu logs da ClickHouse. Dopu quì, per ogni entrata, per visita id, aghju ricivutu transazzione chì puderia micca esse trattatu ancu è più snapshots, vale à dì transazzioni digià cunnessi, vale à dì u risultatu di u travagliu precedente. Aghju digià fattu a logica da elli, hà sceltu a transazzione curretta, cunnessu novi avvenimenti. Registratu di novu. U logu tornò à ClickHouse, vale à dì hè un sistema sempre cíclicu. E in più, sò andatu à DWH per analizà quì.
Era in questa forma chì ùn hà micca travagliatu assai bè. È per fà più faciule per ClickHouse, quandu ci era una dumanda per l'ID di visita, anu raggruppatu queste richieste in blocchi di 1 000-2 000 ID di visita è anu tiratu tutte e transazzione per 1 000-2 000 persone. E poi tuttu hà travagliatu.
Se guardate in ClickHouse, allora ci sò solu 3 tavule principali chì serve tuttu questu.
A prima tavula in quale i logs sò caricati, è i logs sò caricati quasi senza trasfurmazioni.
Seconda tavola. Per mezu di a vista materializata, l'avvenimenti chì ùn sò micca stati ancu attribuiti, vale à dì, senza relazione, sò stati muzzicati fora di sti logs. È attraversu a vista materializata, e transazzione sò state tirate fora di sti logs per custruisce una snapshot. Questu hè, una vista materializata speciale hà custruitu una snapshot, à dì l'ultimu statu accumulatu di a transazzione.
Eccu u testu scrittu in SQL. Vogliu cummentà uni pochi di cose impurtanti in questu.
A prima cosa impurtante hè a capacità di tirà e culonni è i campi da json in ClickHouse. Questu hè, ClickHouse hà alcuni metudi per travaglià cù json. Sò assai, assai primitivi.
visitParamExtractInt permette di estrattà l'attributi da json, vale à dì u primu successu travaglia. È questu modu pudete tirà l'id di transazzione o visità l'id. Sta volta.
Siconda, un campu materializatu complicatu hè utilizatu quì. Cosa significa? Questu significa chì ùn pudete micca inseritu in a tavula, vale à dì chì ùn hè micca inseritu, hè calculatu è guardatu nantu à l'inserimentu. Quandu incolla, ClickHouse face u travagliu per voi. È ciò chì avete bisognu dopu hè digià sguassatu da json.
In questu casu, a vista materializzata hè per fila cruda. È a prima tavola cù logs praticamenti crudi hè solu utilizata. È chì face ? Prima, cambia l'ordinamentu, vale à dì chì l'ordine passa per l'id di visita, perchè avemu bisognu di tirà rapidamente a so transazzione per una persona specifica.
A seconda cosa impurtante hè index_granularity. Se avete vistu MergeTree, hè di solitu 8 per difettu index_granularity. Chì ghjè ? Questu hè u paràmetru di sparseness di l'indice. In ClickHouse l'indici hè sparse, ùn mai indizia ogni entrata. Face questu ogni 192 8. È questu hè bonu quandu assai dati hè necessariu per esse calculatu, ma male quandu un pocu, perchè ci hè un grande overhead. È se reducimu a granularità di l'indici, allora riducemu l'overhead. Ùn pò esse ridutta à unu, perchè ùn ci pò micca esse abbastanza memoria. L'indice hè sempre guardatu in memoria.
Snapshot usa ancu altre funzioni interessanti di ClickHouse.
Prima, hè AggregatingMergeTree. È AggregatingMergeTree almacena argMax, vale à dì questu hè u statu di a transazzione chì currisponde à l'ultimu timestamp. E transazzioni sò generati tuttu u tempu per un visitatore determinatu. È in l'ultimu statu di sta transazzione, avemu aghjustatu un avvenimentu è avemu un novu statu. Ha colpitu di novu ClickHouse. È attraversu argMax in questa vista materializzata, pudemu sempre ottene u statu attuale.
- U ligame hè "disaccoppiatu" da u Runtime.
- Finu à 3 miliardi di transazzioni per mese sò almacenati è processati. Questu hè un ordine di grandezza più di ciò chì era in Cassandra, vale à dì in un sistema transazionale tipicu.
- Cluster di servitori ClickHouse 2x5. 5 servitori è ogni servitore hà una replica. Questu hè ancu menu di quellu chì era in Cassandra per fà cliccà l'attribuzione basatu, è quì avemu l'impressione basatu. Questu hè, invece di aumentà u numeru di servitori da 30 volte, anu sappiutu di riduce.
È l'ultimu esempiu hè a cumpagnia finanziaria Y, chì analizò i correlazioni di i cambiamenti in i prezzi di l'azzioni.
È u compitu era:
- Ci sò circa 5 000 azzioni.
- Quotes ogni 100 millisecondi sò cunnisciuti.
- I dati sò stati accumulati più di 10 anni. Apparentemente, per certi cumpagnie più, per certi menu.
- Ci sò circa 100 miliardi di fila in totale.
È era necessariu di calculà a correlazione di cambiamenti.
Eccu duie azioni è e so quote. Se l'un culla è l'altru, allora questu hè una correlazione pusitiva, vale à dì chì l'un si stende è l'altru s'arrizza. Sì unu cullà, cum'è à a fine di u graficu, è l'altru scende, allora questu hè una correlazione negativa, vale à dì, quandu unu s'alza, l'altru fala.
Analizendu sti cambiamenti mutuali, si pò fà prediczioni in u mercatu finanziariu.
Ma u compitu hè difficiule. Chì hè fattu per questu? Avemu 100 billion records chì anu: tempu, stock è prezzu. Avemu bisognu di calculà prima 100 miliardi di volte u runningDifference da l'algoritmu di prezzu. RunningDifference hè una funzione in ClickHouse chì calcula in sequenza a diferenza trà duie stringhe.
E dopu, avete bisognu di calculà a correlazione, è a correlazione deve esse calculata per ogni paru. Per 5 000 azzioni, i coppie sò 12,5 milioni. È questu hè assai, vale à dì 12,5 volte hè necessariu di calculà solu una tale funzione di correlazione.
È s'è qualchissia s'hè scurdatu, allora ͞x è ͞y hè un scacco mattu. aspettativa di campionamentu. Vale à dì, hè necessariu micca solu di calculà e radiche è e sume, ma ancu una sume più ind'è queste sume. Una mansa di calculi deve esse fattu 12,5 milioni di volte, è ancu raggruppati per ore. Avemu dinù assai ore. È avete da fà in 60 seconde. Hè un scherzu.
Era necessariu di avè u tempu almenu in una certa manera, perchè tuttu questu hà travagliatu assai, assai pianu prima chì ClickHouse ghjunse.
Anu pruvatu à calculà nantu à Hadoop, in Spark, in Greenplum. È tuttu questu era assai lento o caru. Questu hè, era pussibule di calculà in qualchì modu, ma dopu era caru.
E poi ClickHouse hè ghjuntu è e cose sò assai megliu.
Ricurdaraghju chì avemu un prublema cù a località di dati, perchè e correlazioni ùn ponu micca esse localizate. Ùn pudemu micca mette una parte di e dati nantu à un servitore, alcuni nantu à un altru è calculà, duvemu avè tutte e dati in ogni locu.
Chì anu fattu ? In principiu, i dati sò localizzati. Ogni servitore guarda dati nantu à u prezzu di un certu settore di azzioni. È ùn si sovrapponenu micca. Per quessa, hè pussibule di calculà logReturn in parallelu è indipindentamente, tuttu questu succede finu à quì in parallelu è distribuitu.
Allora avemu decisu di riduce sti dati, senza perde l'espressività. Reduce usendu arrays, vale à dì per ogni periodu di tempu, fate un array di stocks è un array di prezzi. Dunque, piglia assai menu spaziu di dati. È sò un pocu più faciuli di travaglià. Il s'agit d'opérations quasi parallèles, c'est-à-dire que l'on lit en partie en parallèle et qu'on écrivit ensuite à l'ordinateur.
Dopu questu, pò esse replicatu. A lettera "r" significa chì avemu replicatu sta dati. Questu hè, avemu i stessi dati nantu à tutti i trè servitori - questi sò i arrays.
E dopu cù un script speciale da questu settore di 12,5 milioni di correlazione chì deve esse calculatu, pudete fà pacchetti. Questu hè, 2 compiti cù 500 pariglii di correlazione. È questu compitu deve esse calculatu nantu à un servitore ClickHouse specificu. Hà tutte e dati, perchè e dati sò listessi è pò calculà in sequenza.
Una volta, questu hè ciò chì pare. Prima, avemu tutte e dati in questa struttura: tempu, azzioni, prezzu. Allora avemu calculatu logReturn, vale à dì dati di a listessa struttura, ma invece di u prezzu avemu digià logReturn. Allora sò stati rifatti, vale à dì avemu u tempu è u gruppu Array per i stocks è i prezzi. Sreplicated. È dopu, avemu generatu una mansa di travaglii è l'avemu alimentatu à ClickHouse in modu chì li cuntassi. È travaglia.
A prova di cuncettu, u compitu era un subtask, vale à dì, menu dati sò stati pigliati. È solu trè servitori.
Sti primi dui tappe: calculing Log_return è wrapping in arrays pigghiau circa una ora.
È u calculu di a correlazione hè di circa 50 ore. Ma 50 ore ùn sò micca abbastanza, perchè anu travagliatu per settimane. Hè statu un grande successu. E se cuntate, allora 70 volte per seconda tuttu hè statu cuntatu nantu à questu cluster.
Ma u più impurtante hè chì stu sistema hè praticamente senza bottlenecks, vale à dì, scala quasi linearly. E anu verificatu. Scala cù successu.
- U schema ghjustu hè a mità di successu. È u schema ghjustu hè l'usu di tutte e tecnulugia ClickHouse necessarie.
- Summing/AggregatingMergeTrees sò tecnulugii chì permettenu di aggregate o di cunsiderà una snapshot statale cum'è un casu speciale. È simplificà assai assai cose.
- Le Viste Materializzate vi permettenu di scaccià u limitu di un indice. Forsi ùn l'aghju micca dettu assai chjaramente, ma quandu avemu caricatu i logs, i logs crudi eranu in a tavula cù un indice, è i logs d'attributi eranu in a tavula, vale à dì i stessi dati, solu filtrati, ma l'indice era cumpletamente. altri. Sembra esse a listessa data, ma una sorta diversa. E Viste Materialisate vi permette, se ne avete bisognu, per sguassate una tale limitazione di ClickHouse.
- Riduce a granularità di l'indici per e dumande di punti.
- E distribuisce e dati in modu intelligente, pruvate di localizà e dati in u servitore quantu pussibule. È pruvate à assicurà chì e dumande utilizanu ancu a localizazione induve pussibule quant'è pussibule.
E riassuntu stu breve discorsu, pudemu dì chì ClickHouse hà avà fermamente occupatu u territoriu di e basa di dati cummerciale è di basa di dati open source, vale à dì, specificamente per l'analitiche. Si adatta perfettamente à stu paisaghju. E in più, lentamente principia à affucà l'altri, perchè quandu avete ClickHouse, ùn avete micca bisognu di InfiniDB. Vertika pò esse micca necessariu prestu si facenu un supportu SQL normale. Prufittate!
-Grazie per u rapportu! Moltu interessante! Ci sò stati paraguni cù Apache Phoenix?
Innò, ùn aghju intesu à nimu paragunà. Noi è Yandex pruvemu di seguità tutti i paraguni di ClickHouse cù diverse basa di dati. Perchè s'ellu di colpu qualcosa diventa più veloce di ClickHouse, allora Lesha Milovidov ùn pò micca dorme di notte è cumencia à accelerà rapidamente. Ùn aghju micca intesu parlà di tali paraguni.
-
(Aleksey Milovidov) Apache Phoenix hè un mutore SQL alimentatu da Hbase. Hbase hè principalmente per u scenariu di travagliu chjave-valore. Quì, in ogni linea, pò esse un numeru arbitrariu di colonne cù nomi arbitrarii. Questu pò esse dettu di tali sistemi cum'è Hbase, Cassandra. È sò precisamente e dumande analitiche pesanti chì ùn funzionanu micca nurmale per elli. O pudete pensà chì travaglianu bè se ùn avete micca avutu una sperienza cù ClickHouse.
-
Спасибо
-
Bonghjornu Sò digià assai interessatu in questu tema, perchè aghju un sottosistema analiticu. Ma quandu mi fighjulà à ClickHouse, aghju u sintimu chì ClickHouse hè assai bè adattatu per l'analisi di l'eventi, mutabile. E s'ellu ci vole à analizà assai dati di l'affari cù una mansa di grande tavule, allora ClickHouse, quantu aghju capitu, ùn hè micca assai adattatu per mè? In particulare s'elli cambianu. Hè questu currettu o ci sò esempi chì ponu refutà questu?
-
Questu hè ghjustu. È questu hè veru di a maiò parte di e basa di dati analitiche specializate. Sò adattati per u fattu chì ci sò una o più grande tavule chì sò mutabili, è per parechji chjuchi chì cambianu lentamente. Questu hè, ClickHouse ùn hè micca cum'è Oracle, induve pudete mette tuttu è custruisce parechje dumande assai cumplesse. Per utilizà ClickHouse in modu efficace, avete bisognu di custruisce un schema in una manera chì funziona bè in ClickHouse. Vale à dì, evite a normalizazione eccessiva, utilizate dizziunari, pruvate à fà menu ligami longu. È se u schema hè custruitu in questu modu, allora i travaglii di cummerciale simili ponu esse risolti in ClickHouse assai più efficaci chì in una basa di dati relazionale tradiziunale.
-
Grazie per u rapportu! Aghju una quistione nantu à l'ultimu casu finanziariu. Anu avutu analitiche. Era bisognu di paragunà cumu si scendenu è falà. E capiscu chì avete custruitu u sistema specificamente per questa analisi? Se dumane, per esempiu, anu bisognu di qualchì altru rapportu nantu à sta dati, anu bisognu di ricustruisce u schema è carica i dati? Hè, per fà qualchì tipu di preprocessing per uttene a dumanda?
Di sicuru, questu hè l'usu di ClickHouse per un compitu assai specificu. Puderia più tradiziunale esse risolta in Hadoop. Per Hadoop, questu hè un compitu ideale. Ma nantu à Hadoop hè assai lento. È u mo scopu hè di dimustrà chì ClickHouse pò risolve i travaglii chì sò generalmente risolti per mezu completamente differenti, ma à u stessu tempu facenu assai più efficace. Questu hè adattatu per un compitu specificu. Hè chjaru chì s'ellu ci hè un prublema cù qualcosa simili, allura pò esse risoltu in una manera simili.
Hè chjaru. Avete dettu chì 50 ore sò state trattate. Hè da u principiu, quandu avete caricatu i dati o avete i risultati?
Iè Iè.
OK ti ringraziu assai.
Questu hè nantu à un cluster di servitori 3.
Saluti ! Grazie per u rapportu! Tuttu hè assai interessante. Ùn dumandaraghju micca un pocu nantu à a funziunalità, ma nantu à l'usu di ClickHouse in termini di stabilità. Vale à dì, avete avutu, avete da risturà ? Cumu si comporta ClickHouse in questu casu? È hè accadutu chì avete avutu ancu una replica ? Per esempiu, avemu scontru un prublemu cù ClickHouse quand'ellu sempre esce da u so limitu è cascà.
Di sicuru, ùn ci sò micca sistemi ideali. È ClickHouse hà ancu i so prublemi. Ma avete intesu parlà di Yandex.Metrica ùn hà micca travagliatu per un bellu pezzu? Probabilmente micca. Hè travagliatu in modu affidabile da 2012-2013 in ClickHouse. Puderaghju u listessu di a mo sperienza. Ùn avemu mai avutu fallimenti cumpleti. Alcune cose parziali puderanu accade, ma ùn eranu mai abbastanza critichi per affettà seriamente l'affari. Ùn hè mai accadutu. ClickHouse hè abbastanza affidabile è ùn crash in casually. Ùn avete micca à preoccupassi. Ùn hè micca una cosa cruda. Questu hè statu pruvatu da parechje cumpagnie.
Bonghjornu! Avete dettu chì avete bisognu di pensà à u schema di dati immediatamente. E s'ellu hè accadutu ? I mo dati si stende è sguassate. Sei mesi passanu, è capiscu chì hè impussibile di campà cusì, aghju bisognu di ricaricà i dati è fà qualcosa cun elli.
Questu dipende di sicuru da u vostru sistema. Ci hè parechje manere di fà questu senza quasi senza stop. Per esempiu, pudete creà una Vista Materializzata in quale fà una struttura di dati differente si pò esse mappatu unicu. Vale à dì, s'ellu permette di mapping usendu ClickHouse, vale à dì, estrae alcune cose, cambia a chjave primaria, cambia a partizione, allora pudete fà una Vista Materializzata. Overwrite i vostri vechji dati quì, i novi seranu scritti automaticamente. E poi cambiate solu per aduprà a Vista Materializzata, dopu cambiate u record è tumbà a vechja tavola. Questu hè generalmente un metudu senza stop.
Спасибо.
Source: www.habr.com