Teoria e pratica dell'utilizzo di ClickHouse in applicazioni reali. Aleksandr Zaitsev (2018)

Nonostante ora ci siano molti dati quasi ovunque, i database analitici sono ancora piuttosto esotici. Sono poco conosciuti e ancor peggio in grado di utilizzarli efficacemente. Molti continuano a "mangiare cactus" con MySQL o PostgreSQL, che sono progettati per altri scenari, soffrono con NoSQL o pagano più del dovuto per soluzioni commerciali. ClickHouse cambia le regole del gioco e abbassa sensibilmente la soglia per entrare nel mondo dei DBMS analitici.

Rapporto da BackEnd Conf 2018 ed è pubblicato con il permesso del relatore.

Chi sono e perché parlo di ClickHouse? Sono un direttore dello sviluppo presso LifeStreet, che utilizza ClickHouse. Inoltre, sono il fondatore di Altinity. È un partner Yandex che promuove ClickHouse e aiuta Yandex a rendere ClickHouse più efficace. Pronto anche a condividere le conoscenze su ClickHouse.

E io non sono il fratello di Petya Zaitsev. Mi viene spesso chiesto di questo. No, non siamo fratelli.

“Tutti sanno” che ClickHouse:

• Molto veloce,
• Molto comodo
• Utilizzato in Yandex.

Un po 'meno si sa in quali aziende e come viene utilizzato.

Ti dirò perché, dove e come viene utilizzato ClickHouse, ad eccezione di Yandex.

Ti dirò come vengono risolti problemi specifici utilizzando ClickHouse in diverse aziende, quali strumenti ClickHouse puoi utilizzare per le tue attività e come sono stati utilizzati in diverse aziende.

Ho raccolto tre esempi che mostrano ClickHouse da diverse angolazioni. Penso che sarà interessante.

La prima domanda è: “Perché abbiamo bisogno di ClickHouse?”. Sembra essere una domanda abbastanza ovvia, ma ci sono più di una risposta.

• La prima risposta è per motivi di prestazioni. ClickHouse è molto veloce. Anche l'analisi su ClickHouse è molto veloce. Spesso può essere utilizzato laddove qualcos'altro funziona molto lentamente o molto male.
• La seconda risposta è il costo. E prima di tutto, il costo del ridimensionamento. Ad esempio, Vertica è un database assolutamente eccezionale. Funziona molto bene se non hai molti terabyte di dati. Ma quando si tratta di centinaia di terabyte o petabyte, il costo di una licenza e del supporto raggiunge un importo piuttosto significativo. Ed è costoso. E ClickHouse è gratuito.
• La terza risposta è il costo operativo. Questo è un approccio leggermente diverso. RedShift è un ottimo analogo. Su RedShift, puoi prendere una decisione molto rapidamente. Funzionerà bene, ma allo stesso tempo, ogni ora, ogni giorno e ogni mese, pagherai Amazon abbastanza caro, perché questo è un servizio molto costoso. Anche Google BigQuery. Se qualcuno l'ha usato, allora sa che lì puoi eseguire diverse richieste e ottenere un conto per centinaia di dollari all'improvviso.

ClickHouse non ha questi problemi.

Dove viene utilizzato ora ClickHouse? Oltre a Yandex, ClickHouse è utilizzato in una serie di diverse aziende e società.

• Prima di tutto, questa è l'analisi delle applicazioni web, ad es. questo è un caso d'uso proveniente da Yandex.
• Molte aziende AdTech utilizzano ClickHouse.
• Numerose aziende che hanno bisogno di analizzare i registri delle transazioni da fonti diverse.
• Diverse aziende utilizzano ClickHouse per monitorare i registri di sicurezza. Li caricano su ClickHouse, creano rapporti e ottengono i risultati di cui hanno bisogno.
• Le aziende stanno iniziando a usarlo nell'analisi finanziaria, cioè gradualmente anche le grandi aziende si stanno avvicinando a ClickHouse.
• cloudflare. Se qualcuno segue ClickHouse, probabilmente ha sentito il nome di questa azienda. Questo è uno dei contributori essenziali della comunità. E hanno un'installazione ClickHouse molto seria. Ad esempio, hanno realizzato Kafka Engine per ClickHouse.
• Le società di telecomunicazioni hanno iniziato a utilizzare. Diverse aziende utilizzano ClickHouse come prova del concetto o già in produzione.
• Una società utilizza ClickHouse per monitorare i processi di produzione. Testano i microcircuiti, cancellano una serie di parametri, ci sono circa 2 caratteristiche. E poi analizzano se il gioco è buono o cattivo.
• Analisi blockchain. Esiste un'azienda russa come Bloxy.info. Questa è un'analisi della rete ethereum. Lo hanno fatto anche su ClickHouse.

E le dimensioni non contano. Ci sono molte aziende che utilizzano un piccolo server. E permette loro di risolvere i loro problemi. E ancora più aziende utilizzano grandi cluster di molti server o dozzine di server.

E se guardi i record, allora:

• Yandex: oltre 500 server, lì memorizzano 25 miliardi di record al giorno.
• LifeStreet: 60 server, circa 75 miliardi di record al giorno. Ci sono meno server, più record rispetto a Yandex.
• CloudFlare: 36 server, salvano 200 miliardi di record al giorno. Hanno ancora meno server e archiviano ancora più dati.
• Bloomberg: 102 server, circa un trilione di accessi al giorno. Detentore del record.

Geograficamente, anche questo è molto. Questa mappa qui mostra una mappa termica di dove viene utilizzato ClickHouse nel mondo. Russia, Cina, America si distinguono chiaramente qui. Ci sono pochi paesi europei. E ci sono 4 cluster.

Questa è un'analisi comparativa, non è necessario cercare cifre assolute. Questa è un'analisi dei visitatori che leggono materiali in lingua inglese sul sito web di Altinity, perché lì non ce ne sono di lingua russa. E Russia, Ucraina, Bielorussia, ad es. la parte di lingua russa della comunità, questi sono gli utenti più numerosi. Poi arrivano Stati Uniti e Canada. La Cina sta recuperando molto terreno. Non c'era quasi la Cina sei mesi fa, ora la Cina ha già superato l'Europa e continua a crescere. Anche la vecchia Europa non è molto indietro e il leader nell'uso di ClickHouse è, stranamente, la Francia.

Perché racconto tutto questo? Per dimostrare che ClickHouse sta diventando una soluzione standard per l'analisi dei big data ed è già utilizzata in molti posti. Se lo usi, sei nella tendenza giusta. Se non lo stai ancora usando, non puoi aver paura di essere lasciato solo e nessuno ti aiuterà, perché molti lo stanno già facendo.

Questi sono esempi di utilizzo reale di ClickHouse in diverse aziende.

• Il primo esempio è una rete pubblicitaria: migrazione da Vertica a ClickHouse. E conosco alcune aziende che sono passate da Vertica o sono in fase di transizione.
• Il secondo esempio è l'archiviazione transazionale su ClickHouse. Questo è un esempio costruito sugli antipattern. Tutto ciò che non è necessario fare in ClickHouse secondo i consigli degli sviluppatori viene fatto qui. E allo stesso tempo è fatto in modo così efficace che funziona. E funziona molto meglio di una tipica soluzione transazionale.
• Il terzo esempio è il calcolo distribuito su ClickHouse. C'era una domanda su come ClickHouse può essere integrato nell'ecosistema Hadoop. Mostrerò un esempio di come un'azienda ha fatto qualcosa di simile a una mappa per ridurre il contenitore su ClickHouse, tenendo traccia della localizzazione dei dati, ecc., per calcolare un'attività molto non banale.

• LifeStreet è una società di tecnologia pubblicitaria che dispone di tutta la tecnologia fornita con una rete pubblicitaria.
• Si occupa di ottimizzazione degli annunci e offerte programmatiche.
• Tantissimi dati: circa 10 miliardi di eventi al giorno. Allo stesso tempo, gli eventi possono essere suddivisi in diversi sotto-eventi.
• Ci sono molti clienti di questi dati, e queste non sono solo persone, molto di più: si tratta di vari algoritmi che sono coinvolti nell'offerta programmatica.

L'azienda ha percorso un percorso lungo e spinoso. E ne ho parlato su HighLoad. Innanzitutto, LifeStreet è passato da MySQL (con una breve sosta in Oracle) a Vertica. E puoi trovare una storia a riguardo.

E tutto è andato molto bene, ma è diventato subito chiaro che i dati stanno crescendo e Vertica è costosa. Pertanto, sono state ricercate varie alternative. Alcuni di loro sono elencati qui. E infatti, abbiamo fatto proof of concept o talvolta test delle prestazioni di quasi tutti i database che erano disponibili sul mercato dal 13° al 16° anno e che erano approssimativamente adatti in termini di funzionalità. E ne ho parlato anche su HighLoad.

Il compito era migrare da Vertica in primo luogo, perché i dati crescevano. E sono cresciuti esponenzialmente nel corso degli anni. Poi sono andati sullo scaffale, ma comunque. E prevedendo questa crescita, i requisiti aziendali per la quantità di dati su cui era necessario eseguire un qualche tipo di analisi, era chiaro che presto si sarebbe discusso di petabyte. E pagare per petabyte è già molto costoso, quindi stavamo cercando un'alternativa dove andare.

Dove andare? E per molto tempo non è stato affatto chiaro dove andare, perché da un lato ci sono i database commerciali, sembrano funzionare bene. Alcuni funzionano quasi bene come Vertica, altri peggio. Ma sono tutti costosi, non è stato possibile trovare niente di più economico e migliore.

Esistono invece soluzioni open source, che non sono moltissime, cioè per gli analytics si contano sulle dita. E sono gratuiti o economici, ma lenti. E spesso mancano delle funzionalità necessarie e utili.

E non c'era niente che combinasse il buono che c'è nei database commerciali e tutto il libero che c'è nell'open source.

Non c'era niente fino a quando, inaspettatamente, Yandex ha tirato fuori ClickHouse, come un mago da un cappello, come un coniglio. Ed è stata una decisione inaspettata, fanno ancora la domanda: "Perché?", Ma comunque.

E subito nell'estate del 2016, abbiamo iniziato a vedere cos'è ClickHouse. E si è scoperto che a volte può essere più veloce di Vertica. Abbiamo testato diversi scenari su diverse richieste. E se la query utilizzava solo una tabella, ovvero senza join (join), ClickHouse era due volte più veloce di Vertica.

Non ero troppo pigro e l'altro giorno ho guardato i test di Yandex. È lo stesso lì: ClickHouse è due volte più veloce di Vertica, quindi ne parlano spesso.

Ma se ci sono join nelle query, allora tutto risulta non molto inequivocabile. E ClickHouse può essere due volte più lento di Vertica. E se correggi leggermente la richiesta e la riscrivi, sono approssimativamente uguali. Non male. E libero.

E dopo aver ricevuto i risultati del test e averlo osservato da diverse angolazioni, LifeStreet è andato su ClickHouse.

Questo è il sedicesimo anno, te lo ricordo. Era come uno scherzo sui topi che piangevano e si pungevano, ma continuavano a mangiare il cactus. E questo è stato descritto in dettaglio, c'è un video su questo, ecc.

Pertanto, non ne parlerò in dettaglio, parlerò solo dei risultati e di alcune cose interessanti di cui non ho parlato allora.

I risultati sono:

• Migrazione riuscita e più di un anno il sistema sta già lavorando in produzione.
• La produttività e la flessibilità sono aumentate. Dei 10 miliardi di record che potremmo permetterci di archiviare al giorno e quindi per un breve periodo, LifeStreet ora archivia 75 miliardi di record al giorno e può farlo per 3 mesi o più. Se conti al picco, allora questo è fino a un milione di eventi al secondo. Più di un milione di query SQL al giorno arrivano in questo sistema, principalmente da diversi robot.
• Nonostante il fatto che per ClickHouse siano stati utilizzati più server che per Vertica, hanno anche risparmiato sull'hardware, poiché in Vertica sono stati utilizzati dischi SAS piuttosto costosi. ClickHouse ha utilizzato SATA. E perché? Perché in Vertica l'inserimento è sincrono. E la sincronizzazione richiede che i dischi non rallentino troppo, e anche che la rete non rallenti troppo, cioè un'operazione piuttosto costosa. E in ClickHouse l'inserimento è asincrono. Inoltre, puoi sempre scrivere tutto in locale, non ci sono costi aggiuntivi per questo, quindi i dati possono essere inseriti in ClickHouse molto più velocemente che in Vertika, anche su unità più lente. E leggere è più o meno lo stesso. Leggendo su SATA, se sono in RAID, allora è tutto abbastanza veloce.
• Non limitato dalla licenza, ovvero 3 petabyte di dati in 60 server (20 server è una replica) e 6 trilioni di record in fatti e aggregazioni. Niente del genere poteva essere offerto a Vertica.

Passo ora alle cose pratiche in questo esempio.

• Il primo è uno schema efficiente. Molto dipende dallo schema.
• Il secondo è la generazione SQL efficiente.

Una tipica query OLAP è seleziona. Alcune colonne vengono raggruppate per, altre colonne vengono destinate a funzioni aggregate. C'è dove, che può essere pensato come una fetta di cubo. L'intero gruppo può essere pensato come una proiezione. Ed è per questo che si chiama analisi dei dati multivariata.

E spesso questo è modellato in forma di schema a stella, quando c'è un fatto centrale e caratteristiche di questo fatto lungo i lati, lungo i raggi.

E in termini di design fisico, come si adatta al tavolo, di solito fanno una rappresentazione normalizzata. Puoi denormalizzare, ma è costoso su disco e non molto efficiente nelle query. Pertanto, di solito fanno una rappresentazione normalizzata, cioè una tabella dei fatti e molte, molte tabelle delle dimensioni.

Ma non funziona bene in ClickHouse. Ci sono due ragioni:

• Il primo è perché ClickHouse non ha join molto buoni, cioè ci sono join, ma sono cattivi. Mentre male.
• Il secondo è che le tabelle non vengono aggiornate. Di solito in questi segni che si trovano attorno al diagramma stellare bisogna cambiare qualcosa. Ad esempio, nome del cliente, nome dell'azienda, ecc. E non funziona.

E c'è una via d'uscita da questo in ClickHouse. anche due:

• Il primo è l'uso dei dizionari. I dizionari esterni sono ciò che aiuta al 99% a risolvere il problema con lo schema a stella, con gli aggiornamenti e così via.
• Il secondo è l'uso di matrici. Gli array aiutano anche a sbarazzarsi di join e problemi con la normalizzazione.

• Non è necessario unire.
• Aggiornabile. Da marzo 2018 è apparsa un'opportunità non documentata (non la troverai nella documentazione) per aggiornare parzialmente i dizionari, ad es. quelle voci che sono cambiate. In pratica, è come un tavolo.
• Sempre in memoria, quindi i join con un dizionario funzionano più velocemente che se fosse una tabella che si trova su disco e non è ancora un dato di fatto che sia nella cache, molto probabilmente no.

• Non hai nemmeno bisogno di join.
• Questa è una rappresentazione compatta 1-a-molti.
• E secondo me, gli array sono fatti per i geek. Queste sono funzioni lambda e così via.

Questo non è per le parole rosse. Questa è una funzionalità molto potente che ti permette di fare molte cose in modo molto semplice ed elegante.

Esempi tipici che aiutano a risolvere gli array. Questi esempi sono abbastanza semplici e chiari:

• Cerca per tag. Se hai hashtag lì e vuoi trovare alcuni post per hashtag.
• Ricerca per coppie chiave-valore. Ci sono anche alcuni attributi con un valore.
• Archiviazione di elenchi di chiavi che è necessario tradurre in qualcos'altro.

Tutte queste attività possono essere risolte senza array. I tag possono essere inseriti in qualche riga e selezionati con un'espressione regolare o in una tabella separata, ma poi devi fare i join.

E in ClickHouse non devi fare nulla, è sufficiente descrivere l'array di stringhe per gli hashtag o creare una struttura nidificata per i sistemi di valore-chiave.

La struttura nidificata potrebbe non essere il nome migliore. Si tratta di due array che hanno una parte comune nel nome e alcune caratteristiche correlate.

Ed è molto facile cercare per tag. Avere una funzione has, che controlla che la matrice contenga un elemento. Tutti, trovate tutte le voci che riguardano la nostra conferenza.

La ricerca per subid è un po' più complicata. Dobbiamo prima trovare l'indice della chiave, quindi prendere l'elemento con questo indice e verificare che questo valore sia quello di cui abbiamo bisogno. Ma comunque molto semplice e compatto.

L'espressione regolare che vorresti scrivere se la tenessi tutta in una riga, sarebbe, in primo luogo, goffa. E, in secondo luogo, ha funzionato molto più a lungo di due array.

Un altro esempio. Hai un array in cui memorizzi l'ID. E puoi tradurli in nomi. Funzione arrayMap. Questa è una tipica funzione lambda. Passi le espressioni lambda lì. E tira fuori dal dizionario il valore del nome per ogni ID.

La ricerca può essere eseguita allo stesso modo. Viene passata una funzione di predicato che controlla a cosa corrispondono gli elementi.

Queste cose semplificano notevolmente il circuito e risolvono una serie di problemi.

Ma il prossimo problema che stiamo affrontando, e che vorrei menzionare, sono le query efficienti.

• ClickHouse non ha un pianificatore di query. Assolutamente no.
• Tuttavia, le query complesse devono ancora essere pianificate. In quali casi?
• Se ci sono più join nella query, li avvolgi in sottoselezioni. E l'ordine in cui vengono eseguiti è importante.
• E il secondo - se la richiesta è distribuita. Perché in una query distribuita, solo la sottoselezione più interna viene eseguita distribuita e tutto il resto viene passato a un server a cui ti sei connesso ed eseguito lì. Pertanto, se hai distribuito query con molti join (join), devi scegliere l'ordine.

E anche nei casi più semplici, a volte è anche necessario eseguire il lavoro dello scheduler e riscrivere un po 'le query.

Ecco un esempio. Sul lato sinistro c'è una query che mostra i primi 5 paesi. E ci vogliono 2,5 secondi, secondo me. E sul lato destro, la stessa query, ma leggermente riscritta. Invece di raggruppare per stringa, abbiamo iniziato a raggruppare per chiave (int). Ed è più veloce. E poi abbiamo collegato un dizionario al risultato. Invece di 2,5 secondi, la richiesta impiega 1,5 secondi. Questo è buono.

Un esempio simile con i filtri di riscrittura. Ecco una richiesta per la Russia. Funziona per 5 secondi. Se lo riscriviamo in modo tale da confrontare ancora una volta non una stringa, ma numeri con un insieme di quelle chiavi che si riferiscono alla Russia, allora sarà molto più veloce.

Ci sono molti di questi trucchi. E ti consentono di velocizzare in modo significativo le query che ritieni siano già in esecuzione veloce o, al contrario, in esecuzione lenta. Possono essere realizzati ancora più velocemente.

• Massimo lavoro in modalità distribuita.
• Ordinamento per tipi minimi, come ho fatto per ints.
• Se sono presenti join (join), dizionari, è meglio eseguirli come ultima risorsa, quando i dati sono già raggruppati almeno parzialmente, quindi l'operazione di join o la chiamata al dizionario verranno chiamate meno volte e sarà più veloce .
• Sostituzione filtri.

Ci sono altre tecniche, e non solo quelle che ho dimostrato. E tutti a volte possono accelerare notevolmente l'esecuzione delle query.

Passiamo al prossimo esempio. Azienda X dagli Stati Uniti. Cosa sta facendo?

C'era un compito:

• Collegamento offline di transazioni pubblicitarie.
• Modellazione di diversi modelli di rilegatura.

Qual è lo scenario?

Un normale visitatore arriva al sito, ad esempio, 20 volte al mese da annunci diversi, o semplicemente così a volte arriva senza pubblicità, perché ricorda questo sito. Guarda alcuni prodotti, li mette nel cestino, li tira fuori dal cestino. E, alla fine, qualcosa compra.

Domande ragionevoli: "Chi dovrebbe pagare per la pubblicità, se necessario?" e "Quale pubblicità lo ha influenzato, se del caso?". Cioè, perché ha comprato e come convincere anche persone come questa persona a comprare?

Per risolvere questo problema, è necessario collegare gli eventi che si verificano sul sito nel modo corretto, cioè creare in qualche modo una connessione tra loro. Quindi vengono trasferiti per l'analisi a DWH. E sulla base di questa analisi, costruisci modelli di chi mostrare quale pubblicità.

Una transazione pubblicitaria è un insieme di eventi utente correlati che iniziano dalla visualizzazione di un annuncio, quindi accade qualcosa, quindi forse un acquisto e quindi potrebbero esserci acquisti all'interno di un acquisto. Ad esempio, se si tratta di un'applicazione mobile o di un gioco mobile, di solito l'installazione dell'applicazione avviene gratuitamente e, se viene fatto qualcosa lì, potrebbe essere necessario denaro per questo. E più una persona spende nell'applicazione, più è preziosa. Ma per questo è necessario collegare tutto.

Ci sono molti modelli vincolanti.

I più popolari sono:

• Ultima interazione, dove l'interazione è un clic o un'impressione.
• First Interaction, ovvero la prima cosa che ha portato una persona sul sito.
• Combinazione lineare: tutti allo stesso modo.
• Attenuazione.
• Eccetera.

E come ha funzionato tutto in primo luogo? C'erano Runtime e Cassandra. Cassandra è stata utilizzata come archivio delle transazioni, ovvero tutte le transazioni correlate sono state archiviate al suo interno. E quando un evento arriva in Runtime, ad esempio, mostrando una pagina o qualcos'altro, allora è stata fatta una richiesta a Cassandra: c'è una persona simile o no. Quindi sono state ottenute le transazioni che lo riguardano. E la connessione è stata fatta.

E se è fortunato che la richiesta abbia un ID transazione, allora è facile. Ma di solito senza fortuna. Pertanto, era necessario trovare l'ultima transazione o la transazione con l'ultimo clic, ecc.

E tutto ha funzionato molto bene fintanto che la rilegatura è stata fino all'ultimo clic. Perché ci sono, diciamo, 10 milioni di clic al giorno, 300 milioni al mese, se impostiamo una finestra per un mese. E poiché in Cassandra deve essere tutto in memoria per funzionare velocemente, poiché il Runtime deve rispondere rapidamente, ci sono voluti circa 10-15 server.

E quando hanno voluto collegare una transazione al display, si è rivelato subito non così divertente. E perché? Si può vedere che è necessario memorizzare un numero di eventi 30 volte superiore. E, di conseguenza, hai bisogno di 30 volte più server. E si scopre che questa è una sorta di cifra astronomica. Mantenere fino a 500 server per effettuare il collegamento, nonostante il fatto che in Runtime ci siano molti meno server, è una cifra sbagliata. E hanno cominciato a pensare a cosa fare.

E siamo andati a ClickHouse. E come farlo su ClickHouse? A prima vista, sembra che si tratti di un insieme di anti-schemi.

• La transazione cresce, le colleghiamo sempre più eventi, cioè è mutabile e ClickHouse non funziona molto bene con oggetti mutabili.
• Quando un visitatore viene da noi, dobbiamo estrarre le sue transazioni tramite chiave, tramite il suo ID visita. Anche questa è una query puntuale, non lo fanno in ClickHouse. Di solito ClickHouse ha grandi ... scansioni, ma qui abbiamo bisogno di ottenere alcuni record. Anche un antipattern.
• Inoltre, la transazione era in json, ma non volevano riscriverla, quindi volevano archiviare json in modo non strutturato e, se necessario, tirarne fuori qualcosa. E anche questo è un antipattern.

Cioè, un insieme di antipattern.

Tuttavia, si è rivelato un sistema che ha funzionato molto bene.

Cosa è stato fatto? Apparve ClickHouse, in cui venivano gettati i registri, divisi in record. È apparso un servizio attribuito che ha ricevuto i registri da ClickHouse. Successivamente, per ogni voce, per ID visita, ho ricevuto transazioni che potrebbero non essere state ancora elaborate e più istantanee, ad es. transazioni già collegate, ovvero il risultato di un lavoro precedente. Ne ho già ricavato la logica, ho scelto la transazione corretta, collegato nuovi eventi. Registrato di nuovo. Il registro è tornato a ClickHouse, ovvero è un sistema costantemente ciclico. E inoltre, sono andato a DWH per analizzarlo lì.

Era in questa forma che non funzionava molto bene. E per semplificare le cose a ClickHouse, quando c'era una richiesta per ID visita, hanno raggruppato queste richieste in blocchi di 1-000 ID visita ed hanno estratto tutte le transazioni per 2-000 persone. E poi ha funzionato tutto.

Se guardi all'interno di ClickHouse, ci sono solo 3 tavoli principali che servono tutto questo.

La prima tabella in cui vengono caricati i log e i log vengono caricati quasi senza elaborazione.

Secondo tavolo. Attraverso la vista materializzata, da questi registri, gli eventi che non sono stati ancora attribuiti, cioè quelli non correlati, sono stati tagliati fuori. E attraverso la visualizzazione materializzata, le transazioni sono state estratte da questi registri per creare un'istantanea. Cioè, una vista materializzata speciale ha creato un'istantanea, vale a dire l'ultimo stato accumulato della transazione.

Ecco il testo scritto in SQL. Vorrei commentare alcune cose importanti in esso.

La prima cosa importante è la possibilità di estrarre colonne e campi da json in ClickHouse. Cioè, ClickHouse ha alcuni metodi per lavorare con json. Sono molto, molto primitivi.

visitParamExtractInt ti consente di estrarre attributi da json, ovvero il primo colpo funziona. E in questo modo puoi estrarre l'ID della transazione o l'ID della visita. Questa volta.

In secondo luogo, qui viene utilizzato un campo materializzato complicato. Cosa significa? Questo significa che non puoi inserirlo nella tabella, cioè non viene inserito, viene calcolato e memorizzato al momento dell'inserimento. Quando incolli, ClickHouse fa il lavoro per te. E ciò di cui hai bisogno in seguito è già stato estratto da json.

In questo caso, la vista materializzata è per le righe non elaborate. E viene appena utilizzata la prima tabella con registri praticamente grezzi. E cosa fa? In primo luogo, cambia l'ordinamento, ad es. l'ordinamento ora passa per ID visita, perché dobbiamo estrarre rapidamente la sua transazione per una persona specifica.

La seconda cosa importante è index_granularity. Se hai visto MergeTree, di solito è 8 per default index_granularity. Cos'è? Questo è il parametro di scarsità dell'indice. In ClickHouse l'indice è scarso, non indicizza mai ogni voce. Lo fa ogni 192. E questo va bene quando è necessario calcolare molti dati, ma male quando sono pochi, perché c'è un grande overhead. E se riduciamo la granularità dell'indice, riduciamo l'overhead. Non può essere ridotto a uno, perché potrebbe non esserci memoria sufficiente. L'indice è sempre memorizzato.

Snapshot utilizza anche alcune altre interessanti funzionalità di ClickHouse.

Innanzitutto, è AggregatingMergeTree. E AggregatingMergeTree memorizza argMax, ovvero questo è lo stato della transazione corrispondente all'ultimo timestamp. Le transazioni vengono generate continuamente per un determinato visitatore. E nell'ultimo stato di questa transazione, abbiamo aggiunto un evento e abbiamo un nuovo stato. Ha colpito di nuovo ClickHouse. E attraverso argMax in questa vista materializzata, possiamo sempre ottenere lo stato attuale.

• L'associazione è "disaccoppiata" dal runtime.
• Vengono archiviate ed elaborate fino a 3 miliardi di transazioni al mese. Questo è un ordine di grandezza maggiore che in Cassandra, cioè in un tipico sistema transazionale.
• Cluster di server ClickHouse 2x5. 5 server e ogni server ha una replica. Questo è ancora meno di quanto non fosse in Cassandra per eseguire l'attribuzione basata sui clic, e qui abbiamo basato sulle impressioni. Cioè, invece di aumentare il numero di server di 30 volte, sono riusciti a ridurli.

E l'ultimo esempio è la società finanziaria Y, che ha analizzato le correlazioni delle variazioni dei prezzi delle azioni.

E il compito era:

• Ci sono circa 5 condivisioni.
• Sono note quotazioni ogni 100 millisecondi.
• I dati sono stati accumulati in 10 anni. A quanto pare, per alcune aziende di più, per altre di meno.
• Ci sono circa 100 miliardi di righe in totale.

Ed era necessario calcolare la correlazione dei cambiamenti.

Ecco due azioni e le loro quotazioni. Se uno sale e l'altro sale, allora questa è una correlazione positiva, cioè uno sale e l'altro sale. Se uno sale, come alla fine del grafico, e l'altro scende, allora questa è una correlazione negativa, cioè quando uno sale, l'altro scende.

Analizzando questi cambiamenti reciproci, si possono fare previsioni sul mercato finanziario.

Ma il compito è difficile. Cosa si sta facendo per questo? Abbiamo 100 miliardi di record che hanno: tempo, stock e prezzo. Dobbiamo calcolare i primi 100 miliardi di volte la differenza corrente dall'algoritmo del prezzo. RunningDifference è una funzione in ClickHouse che calcola in sequenza la differenza tra due stringhe.

Dopodiché, devi calcolare la correlazione e la correlazione deve essere calcolata per ogni coppia. Per 5 azioni, le coppie sono 000 milioni. E questo è molto, ad es. 12,5 volte è necessario calcolare proprio una tale funzione di correlazione.

E se qualcuno ha dimenticato, allora ͞x e ͞y è uno scacco matto. aspettativa di campionamento. Cioè, è necessario non solo calcolare le radici e le somme, ma anche un'altra somma all'interno di queste somme. Una serie di calcoli deve essere eseguita 12,5 milioni di volte e persino raggruppata per ore. Abbiamo anche molte ore. E devi farlo in 60 secondi. È uno scherzo.

Era necessario avere tempo almeno in qualche modo, perché tutto questo ha funzionato molto, molto lentamente prima che arrivasse ClickHouse.

Hanno provato a calcolarlo su Hadoop, su Spark, su Greenplum. E tutto questo era molto lento o costoso. Cioè, era possibile in qualche modo calcolare, ma poi era costoso.

E poi è arrivata ClickHouse e le cose sono andate molto meglio.

Ti ricordo che abbiamo un problema con la località dei dati, perché le correlazioni non possono essere localizzate. Non possiamo mettere alcuni dati su un server, altri su un altro e calcolare, dobbiamo avere tutti i dati ovunque.

Cosa hanno fatto? Inizialmente, i dati sono localizzati. Ogni server memorizza i dati sul prezzo di un determinato insieme di condivisioni. E non si sovrappongono. Pertanto, è possibile calcolare logReturn in parallelo e in modo indipendente, tutto ciò finora avviene in parallelo e distribuito.

Quindi abbiamo deciso di ridurre questi dati, pur non perdendo espressività. Ridurre utilizzando matrici, ad es. per ogni periodo di tempo, crea una matrice di azioni e una matrice di prezzi. Pertanto, occupa molto meno spazio dati. E sono un po' più facili da lavorare. Si tratta di operazioni quasi parallele, ovvero leggiamo parzialmente in parallelo e poi scriviamo sul server.

Successivamente, può essere replicato. La lettera "r" significa che abbiamo replicato questi dati. Cioè, abbiamo gli stessi dati su tutti e tre i server: questi sono gli array.

E poi con uno script speciale da questo insieme di 12,5 milioni di correlazioni che devono essere calcolate, puoi creare pacchetti. Ovvero, 2 attività con 500 coppie di correlazioni. E questa attività deve essere calcolata su uno specifico server ClickHouse. Ha tutti i dati, perché i dati sono gli stessi e può calcolarli in sequenza.

Ancora una volta, questo è quello che sembra. Innanzitutto, abbiamo tutti i dati in questa struttura: tempo, azioni, prezzo. Quindi abbiamo calcolato logReturn, ovvero dati della stessa struttura, ma al posto del prezzo abbiamo già logReturn. Quindi sono stati rifatti, ad es. abbiamo ottenuto il tempo e il gruppoArray per azioni e prezzi. Replicato. Successivamente, abbiamo generato una serie di attività e le abbiamo fornite a ClickHouse in modo che le conteggiasse. E funziona.

Sulla prova del concetto, l'attività era una sottoattività, ovvero sono stati presi meno dati. E solo tre server.

Queste prime due fasi: il calcolo di Log_return e il wrapping negli array hanno richiesto circa un'ora.

E il calcolo della correlazione è di circa 50 ore. Ma 50 ore non bastano, perché prima lavoravano per settimane. È stato un grande successo. E se conti, allora 70 volte al secondo tutto è stato contato su questo cluster.

Ma la cosa più importante è che questo sistema è praticamente privo di colli di bottiglia, ovvero scala quasi linearmente. E l'hanno controllato. Ridimensionato con successo.

• Lo schema giusto è metà del successo. E lo schema giusto è l'uso di tutte le tecnologie ClickHouse necessarie.
• Summing/AggregatingMergeTrees sono tecnologie che consentono di aggregare o considerare un'istantanea dello stato come un caso speciale. E semplifica notevolmente molte cose.
• Le viste materializzate consentono di aggirare il limite di un indice. Forse non l'ho detto molto chiaramente, ma quando abbiamo caricato i log, i log grezzi erano nella tabella con un indice e i log degli attributi erano nella tabella, cioè gli stessi dati, solo filtrati, ma l'indice era completamente altri. Sembra essere gli stessi dati, ma un ordinamento diverso. E le viste materializzate ti consentono, se ne hai bisogno, di aggirare tale limitazione di ClickHouse.
• Ridurre la granularità dell'indice per le query puntuali.
• E distribuisci i dati in modo intelligente, prova a localizzare i dati il ​​più possibile all'interno del server. E cercare di garantire che le richieste utilizzino il più possibile anche la localizzazione.

E riassumendo questo breve discorso, possiamo dire che ClickHouse ha ormai saldamente occupato il territorio sia dei database commerciali che dei database open source, ovvero specificamente per l'analisi. Si inserisce perfettamente in questo paesaggio. E per di più, inizia lentamente a spiazzare gli altri, perché quando hai ClickHouse, non hai bisogno di InfiniDB. Vertika potrebbe non essere necessario presto se forniscono il normale supporto SQL. Godere!

-Grazie per la segnalazione! Molto interessante! Ci sono stati paragoni con Apache Phoenix?

No, non ho sentito nessuno confrontare. Noi e Yandex cerchiamo di tenere traccia di tutti i confronti di ClickHouse con diversi database. Perché se all'improvviso qualcosa si rivela più veloce di ClickHouse, allora Lesha Milovidov non riesce a dormire la notte e inizia ad accelerarlo rapidamente. Non ho sentito parlare di un simile confronto.

• (Aleksey Milovidov) Apache Phoenix è un motore SQL basato su Hbase. Hbase è principalmente per lo scenario di lavoro chiave-valore. Lì, in ogni riga, può esserci un numero arbitrario di colonne con nomi arbitrari. Questo si può dire di sistemi come Hbase, Cassandra. E sono proprio le query analitiche pesanti che non funzioneranno normalmente per loro. Oppure potresti pensare che funzionino bene se non hai avuto alcuna esperienza con ClickHouse.

• Grazie

  • Buon pomeriggio Sono già abbastanza interessato a questo argomento, perché ho un sottosistema analitico. Ma quando guardo ClickHouse, ho la sensazione che ClickHouse sia molto adatto per l'analisi degli eventi, mutevole. E se ho bisogno di analizzare molti dati aziendali con un mucchio di tabelle di grandi dimensioni, allora ClickHouse, per quanto ho capito, non è molto adatto a me? Soprattutto se cambiano. È corretto o ci sono esempi che possono confutarlo?

  • È giusto. E questo è vero per la maggior parte dei database analitici specializzati. Sono fatti su misura per il fatto che ci sono una o più tabelle grandi che sono mutabili e per molte piccole che cambiano lentamente. Cioè, ClickHouse non è come Oracle, dove puoi mettere tutto e creare query molto complesse. Per utilizzare ClickHouse in modo efficace, è necessario creare uno schema che funzioni bene in ClickHouse. Cioè, evita un'eccessiva normalizzazione, usa i dizionari, cerca di creare meno collegamenti lunghi. E se lo schema è costruito in questo modo, attività aziendali simili possono essere risolte su ClickHouse in modo molto più efficiente rispetto a un database relazionale tradizionale.

Grazie per la segnalazione! Ho una domanda sull'ultimo caso finanziario. Avevano analisi. Era necessario confrontare il modo in cui salgono e scendono. E capisco che hai costruito il sistema appositamente per questa analisi? Se domani, ad esempio, hanno bisogno di qualche altro rapporto su questi dati, devono ricostruire lo schema e caricare i dati? Cioè, per fare una sorta di pre-elaborazione per ottenere la richiesta?

Naturalmente, questo è l'uso di ClickHouse per un'attività molto specifica. Potrebbe essere risolto più tradizionalmente all'interno di Hadoop. Per Hadoop, questo è un compito ideale. Ma su Hadoop è molto lento. E il mio obiettivo è dimostrare che ClickHouse può risolvere compiti che di solito vengono risolti con mezzi completamente diversi, ma allo stesso tempo farlo in modo molto più efficiente. È su misura per un'attività specifica. È chiaro che se c'è un problema con qualcosa di simile, allora può essere risolto in modo simile.

È chiaro. Hai detto che sono state elaborate 50 ore. È fin dall'inizio, quando hai caricato i dati o ottenuto i risultati?

Sì, sì.

Ok grazie mille.

Questo è su un cluster di 3 server.

Saluti! Grazie per la segnalazione! Tutto è molto interessante. Non chiederò poco sulla funzionalità, ma sull'uso di ClickHouse in termini di stabilità. Cioè, ne avevi, hai dovuto ripristinare? Come si comporta ClickHouse in questo caso? E per caso avevi anche una replica? Ad esempio, abbiamo riscontrato un problema con ClickHouse quando esce ancora dal limite e cade.

Naturalmente non esistono sistemi ideali. E anche ClickHouse ha i suoi problemi. Ma hai sentito parlare di Yandex.Metrica che non funziona da molto tempo? Probabilmente no. Funziona in modo affidabile dal 2012-2013 su ClickHouse. Posso dire lo stesso della mia esperienza. Non abbiamo mai avuto fallimenti completi. Potrebbero accadere alcune cose parziali, ma non sono mai state abbastanza critiche da influenzare seriamente il business. Questo non è mai successo prima. ClickHouse è abbastanza affidabile e non si blocca in modo casuale. Non devi preoccuparti di questo. Non è una cosa cruda. Ciò è stato dimostrato da molte aziende.

Ciao! Hai detto che devi pensare subito allo schema dei dati. E se fosse successo? I miei dati continuano a scorrere. Passano sei mesi e capisco che è impossibile vivere così, devo ricaricare i dati e fare qualcosa con loro.

Questo dipende ovviamente dal tuo sistema. Ci sono diversi modi per farlo praticamente senza sosta. Ad esempio, puoi creare una vista materializzata in cui creare una struttura dati diversa se può essere mappata in modo univoco. Cioè, se consente la mappatura utilizzando ClickHouse, ovvero estrarre alcune cose, modificare la chiave primaria, modificare il partizionamento, quindi è possibile creare una vista materializzata. Sovrascrivi lì i tuoi vecchi dati, quelli nuovi verranno scritti automaticamente. E poi passa semplicemente all'utilizzo della vista materializzata, quindi cambia il record e uccidi il vecchio tavolo. Questo è generalmente un metodo non-stop.

Grazie.

Fonte: habr.com