Teoria i pràctica de l'ús de ClickHouse en aplicacions reals. Alexander Zaitsev (2018)

Malgrat que ara hi ha moltes dades a gairebé tot arreu, les bases de dades analítiques encara són força exòtiques. Són poc coneguts i encara pitjor poden utilitzar-los amb eficàcia. Molts continuen "menjant cactus" amb MySQL o PostgreSQL, que estan dissenyats per a altres escenaris, pateixen amb NoSQL o pagan de més per solucions comercials. ClickHouse canvia les regles del joc i redueix significativament el llindar per entrar al món dels DBMS analítics.

Informe de BackEnd Conf 2018 i es publica amb el permís del ponent.

Qui sóc i per què parlo de ClickHouse? Sóc director de desenvolupament de LifeStreet, que utilitza ClickHouse. A més, sóc el fundador d'Altinity. És un soci de Yandex que promou ClickHouse i ajuda Yandex a fer que ClickHouse tingui més èxit. També disposat a compartir coneixements sobre ClickHouse.

I no sóc el germà de Petya Zaitsev. Sovint em pregunten sobre això. No, no som germans.

"Tothom sap" que ClickHouse:

• Molt ràpid,
• Molt còmode
• S'utilitza a Yandex.

Se sap una mica menys en quines empreses i com s'utilitza.

Us explicaré per què, on i com s'utilitza ClickHouse, excepte Yandex.

Us explicaré com es resolen tasques específiques amb l'ajuda de ClickHouse en diferents empreses, quines eines ClickHouse podeu utilitzar per a les vostres tasques i com es van utilitzar en diferents empreses.

Vaig recollir tres exemples que mostren ClickHouse des de diferents angles. Crec que serà interessant.

La primera pregunta és: "Per què necessitem ClickHouse?". Sembla una pregunta bastant òbvia, però hi ha més d'una resposta.

• La primera resposta és per al rendiment. ClickHouse és molt ràpid. Analytics a ClickHouse també és molt ràpid. Sovint es pot utilitzar quan una altra cosa és molt lenta o molt dolenta.
• La segona resposta és el cost. I, en primer lloc, el cost de l'escala. Per exemple, Vertica és una base de dades absolutament fantàstica. Funciona molt bé si no teniu molts terabytes de dades. Però quan es tracta de centenars de terabytes o petabytes, el cost d'una llicència i assistència ascendeix a una quantitat força important. I és car. I ClickHouse és gratuït.
• La tercera resposta és el cost operatiu. Aquest és un enfocament lleugerament diferent. RedShift és un gran anàleg. A RedShift, podeu prendre una decisió molt ràpidament. Funcionarà bé, però al mateix temps, cada hora, cada dia i cada mes, pagareu a Amazon bastant car, perquè aquest és un servei molt car. Google BigQuery també. Si algú l'utilitza, sap que allà podeu fer diverses sol·licituds i rebre una factura per centenars de dòlars de sobte.

ClickHouse no té aquests problemes.

On s'utilitza ara ClickHouse? A més de Yandex, ClickHouse s'utilitza en un munt de diferents negocis i empreses.

• En primer lloc, es tracta d'analítica d'aplicacions web, és a dir, aquest és un cas d'ús que prové de Yandex.
• Moltes empreses d'AdTech utilitzen ClickHouse.
• Nombroses empreses que necessiten analitzar registres de transaccions de diferents fonts.
• Diverses empreses utilitzen ClickHouse per controlar els registres de seguretat. Els pengen a ClickHouse, fan informes i obtenen els resultats que necessiten.
• Les empreses comencen a utilitzar-lo en l'anàlisi financera, és a dir, a poc a poc les grans empreses també s'apropen a ClickHouse.
• cloudflare. Si algú segueix ClickHouse, probablement hagi escoltat el nom d'aquesta empresa. Aquest és un dels col·laboradors essencials de la comunitat. I tenen una instal·lació de ClickHouse molt seriosa. Per exemple, van fer Kafka Engine per a ClickHouse.
• Les empreses de telecomunicacions van començar a utilitzar. Diverses empreses utilitzen ClickHouse com a prova de concepte o ja en producció.
• Una empresa utilitza ClickHouse per supervisar els processos de producció. Proven microcircuits, anoten un munt de paràmetres, hi ha unes 2 característiques. I després analitzen si el joc és bo o dolent.
• Analítica Blockchain. Hi ha una empresa russa com Bloxy.info. Aquesta és una anàlisi de la xarxa ethereum. També ho van fer a ClickHouse.

I la mida no importa. Hi ha moltes empreses que utilitzen un servidor petit. I els permet resoldre els seus problemes. I encara més empreses utilitzen grans clústers de molts servidors o desenes de servidors.

I si mireu els registres, aleshores:

• Yandex: més de 500 servidors, hi emmagatzemen 25 milions de registres al dia.
• LifeStreet: 60 servidors, aproximadament 75 milions de registres per dia. Hi ha menys servidors, més registres que a Yandex.
• CloudFlare: 36 servidors, estalvien 200 milions de registres al dia. Tenen encara menys servidors i emmagatzemen encara més dades.
• Bloomberg: 102 servidors, aproximadament un bilió d'entrades per dia. Titular del record.

Geogràficament, això també és molt. Aquest mapa mostra un mapa de calor d'on s'utilitza ClickHouse al món. Rússia, Xina, Amèrica destaquen clarament aquí. Hi ha pocs països europeus. I hi ha 4 grups.

Es tracta d'una anàlisi comparativa, no cal buscar xifres absolutes. Aquesta és una anàlisi dels visitants que llegeixen materials en anglès al lloc web d'Altinity, perquè no n'hi ha de parla russa. I Rússia, Ucraïna, Bielorússia, és a dir, la part de la comunitat de parla russa, aquests són els usuaris més nombrosos. Després vénen els EUA i el Canadà. La Xina s'està posant molt al dia. Fa sis mesos gairebé no hi havia Xina, ara la Xina ja ha superat Europa i segueix creixent. La vella Europa tampoc es queda enrere, i el líder en l'ús de ClickHouse és, curiosament, França.

Per què dic tot això? Per demostrar que ClickHouse s'està convertint en una solució estàndard per a l'anàlisi de big data i que ja s'utilitza en molts llocs. Si l'utilitzeu, esteu a la tendència correcta. Si encara no l'estàs utilitzant, no pots tenir por que et quedis sol i ningú t'ajudarà, perquè molts ja ho estan fent.

Aquests són exemples d'ús real de ClickHouse en diverses empreses.

• El primer exemple és una xarxa publicitària: migració de Vertica a ClickHouse. I conec algunes empreses que han fet la transició de Vertica o estan en procés de transició.
• El segon exemple és l'emmagatzematge transaccional a ClickHouse. Aquest és un exemple construït sobre antipatrons. Tot el que no s'hauria de fer a ClickHouse segons els consells dels desenvolupadors es fa aquí. I es fa de manera tan efectiva que funciona. I funciona molt millor que la solució transaccional típica.
• El tercer exemple és la informàtica distribuïda a ClickHouse. Hi havia una pregunta sobre com es pot integrar ClickHouse a l'ecosistema Hadoop. Mostraré un exemple de com una empresa va fer alguna cosa semblant a un contenidor de reducció de mapes a ClickHouse, fent un seguiment de la localització de dades, etc., per calcular una tasca molt no trivial.

• LifeStreet és una empresa de tecnologia publicitària que té tota la tecnologia que inclou una xarxa publicitària.
• Es dedica a l'optimització d'anuncis i a les ofertes programàtiques.
• Moltes dades: uns 10 milions d'esdeveniments al dia. Al mateix temps, els esdeveniments es poden dividir en diversos subesdeveniments.
• Hi ha molts clients d'aquestes dades, i no només són persones, sinó molt més: es tracta de diversos algorismes que participen en ofertes programàtiques.

L'empresa ha recorregut un camí llarg i espinós. I n'he parlat a HighLoad. Primer, LifeStreet es va traslladar de MySQL (amb una breu parada a Oracle) a Vertica. I en pots trobar una història.

I tot va anar molt bé, però ràpidament es va veure que les dades creixen i Vertica és cara. Per tant, es van buscar diferents alternatives. Alguns d'ells s'enumeren aquí. I, de fet, vam fer proves de concepte o, de vegades, proves de rendiment de gairebé totes les bases de dades que estaven disponibles al mercat entre els anys 13 i 16 i que eren aproximadament adequades pel que fa a la funcionalitat. I també n'he parlat d'alguns a HighLoad.

La tasca era migrar des de Vertica en primer lloc, perquè les dades van créixer. I van créixer exponencialment al llarg dels anys. Després van anar a la prestatgeria, però tanmateix. I predicant aquest creixement, els requisits empresarials per a la quantitat de dades sobre les quals calia fer algun tipus d'anàlisi, era evident que aviat es parlarien de petabytes. I pagar per petabytes ja és molt car, així que buscàvem una alternativa on anar.

On anar? I durant molt de temps no estava gens clar cap a on anar, perquè d'una banda hi ha bases de dades comercials, sembla que funcionen bé. Alguns funcionen gairebé tan bé com Vertica, altres pitjor. Però tots són cars, no es pot trobar res més barat i millor.

D'altra banda, hi ha solucions de codi obert, que són poc nombroses, és a dir, per a l'anàlisi, es poden comptar amb els dits. I són gratuïts o barats, però lents. I sovint no tenen la funcionalitat necessària i útil.

I no hi havia res per combinar el bé que hi ha a les bases de dades comercials i tot el gratuït que hi ha en codi obert.

No hi va haver res fins que, inesperadament, Yandex va treure ClickHouse, com un mag d'un barret, com un conill. I va ser una decisió inesperada, encara es fan la pregunta: “Per què?”, però tanmateix.

I de seguida, l'estiu del 2016, vam començar a mirar què és ClickHouse. I va resultar que de vegades pot ser més ràpid que Vertica. Hem provat diferents escenaris en diferents peticions. I si la consulta utilitzava només una taula, és a dir, sense cap unió (join), aleshores ClickHouse era el doble de ràpid que Vertica.

No era massa mandrós i l'altre dia vaig mirar les proves de Yandex. Allà passa el mateix: ClickHouse és el doble de ràpid que Vertica, així que sovint en parlen.

Però si hi ha unions a les consultes, aleshores tot no és gaire clar. I ClickHouse pot ser el doble de lent que Vertica. I si corregeu lleugerament la sol·licitud i la torneu a escriure, llavors són aproximadament iguals. No està malament. I gratuït.

I després d'haver rebut els resultats de la prova i mirant-ho des de diferents angles, LifeStreet va anar a ClickHouse.

Aquest és el 16è any, us ho recordo. Era com una broma sobre els ratolins que ploraven i es punxaven, però continuaven menjant el cactus. I això es va descriure amb detall, hi ha un vídeo sobre això, etc.

Per tant, no en parlaré en detall, només parlaré dels resultats i d'algunes coses interessants de les quals no vaig parlar aleshores.

Els resultats són:

• Migració reeixida i més d'un any que el sistema ja funciona en producció.
• La productivitat i la flexibilitat han augmentat. Dels 10 milions de registres que ens podríem permetre emmagatzemar al dia i després durant poc temps, LifeStreet ara emmagatzema 75 milions de registres al dia i ho pot fer durant 3 mesos o més. Si compteu al màxim, això suposa fins a un milió d'esdeveniments per segon. Més d'un milió de consultes SQL al dia arriben a aquest sistema, la majoria de diferents robots.
• Malgrat que es van utilitzar més servidors per a ClickHouse que per a Vertica, també es van estalviar en maquinari, perquè a Vertica es van utilitzar discs SAS força cars. ClickHouse utilitzava SATA. I per què? Perquè a Vertica inserir és sincrònic. I la sincronització requereix que els discs no s'alenteixin massa, i també que la xarxa no s'alenteixi massa, és a dir, una operació força costosa. I a ClickHouse la inserció és asíncrona. A més, sempre podeu escriure-ho tot localment, no hi ha costos addicionals per això, de manera que les dades es poden inserir a ClickHouse molt més ràpidament que a Vertika, fins i tot en unitats més lentes. I llegir és més o menys el mateix. Llegint a SATA, si estan en RAID, tot això és prou ràpid.
• No limitat per llicència, és a dir, 3 petabytes de dades en 60 servidors (20 servidors és una rèplica) i 6 bilions de registres en fets i agregacions. No es podia permetre res semblant a Vertica.

Ara passaré a les coses pràctiques en aquest exemple.

• El primer és un esquema eficient. Molt depèn de l'esquema.
• El segon és la generació eficient d'SQL.

Una consulta OLAP típica és una selecció. Algunes de les columnes van a agrupar per, algunes de les columnes van a funcions d'agregació. Hi ha on, que es pot representar com una llesca d'un cub. Tot el grup es pot pensar com una projecció. I per això s'anomena anàlisi de dades multivariant.

I sovint això es modela en forma d'esquema estrella, quan hi ha un fet central i les característiques d'aquest fet al llarg dels costats, al llarg dels raigs.

I pel que fa al disseny físic, com encaixa sobre la taula, solen fer una representació normalitzada. Podeu desnormalitzar, però és car al disc i poc eficient en les consultes. Per tant, solen fer una representació normalitzada, és a dir, una taula de fets i taules de moltes, moltes dimensions.

Però no funciona bé a ClickHouse. Hi ha dos motius:

• El primer és perquè ClickHouse no té unions molt bones, és a dir, hi ha unions, però són dolentes. Tot i que malament.
• La segona és que les taules no estan actualitzades. Normalment, en aquestes plaques, que estan al voltant del circuit estrella, cal canviar alguna cosa. Per exemple, nom del client, nom de l'empresa, etc. I no funciona.

I hi ha una manera de sortir d'això a ClickHouse. fins i tot dos:

• El primer és l'ús de diccionaris. Els diccionaris externs són el que ajuda al 99% a resoldre el problema amb l'esquema estrella, amb actualitzacions, etc.
• El segon és l'ús de matrius. Les matrius també ajuden a eliminar les unions i els problemes amb la normalització.

• No cal unir-se.
• Actualitzable. Des del març de 2018 apareix una oportunitat sense documentació (no la trobareu a la documentació) per actualitzar parcialment els diccionaris, és a dir, aquelles entrades que han canviat. Pràcticament, és com una taula.
• Sempre a la memòria, així que s'uneix amb un diccionari funciona més ràpid que si fos una taula que està en disc i encara no és un fet que estigui a la memòria cau, molt probablement no.

• Tampoc necessites unions.
• Aquesta és una representació compacta d'1 a molts.
• I al meu entendre, les matrius estan fetes per als frikis. Aquestes són funcions lambda i així successivament.

Això no és per a paraules vermelles. Aquesta és una funcionalitat molt potent que permet fer moltes coses d'una manera molt senzilla i elegant.

Exemples típics que ajuden a resoldre matrius. Aquests exemples són prou senzills i clars:

• Cerca per etiquetes. Si teniu hashtags allà i voleu trobar algunes publicacions per hashtag.
• Cerca per parelles clau-valor. També hi ha alguns atributs amb un valor.
• Emmagatzemar llistes de claus que necessiteu traduir a una altra cosa.

Totes aquestes tasques es poden resoldre sense matrius. Les etiquetes es poden posar en alguna línia i seleccionar-se amb una expressió regular o en una taula separada, però després heu de fer unions.

I a ClickHouse, no cal que feu res, n'hi ha prou amb descriure la matriu de cadenes per als hashtags o fer una estructura imbricada per als sistemes de valor-clau.

Pot ser que l'estructura imbricada no sigui el millor nom. Es tracta de dues matrius que tenen una part comuna en el nom i algunes característiques relacionades.

I és molt fàcil cercar per etiqueta. Tenir una funció has, que comprova que la matriu contingui un element. Tots i totes, hem trobat totes les entrades relacionades amb la nostra conferència.

La cerca per subid és una mica més complicada. Primer hem de trobar l'índex de la clau, i després agafar l'element amb aquest índex i comprovar que aquest valor és el que necessitem. No obstant això, és molt senzill i compacte.

L'expressió regular que voldríeu escriure si ho mantinguéssiu tot en una línia, seria, en primer lloc, maldestre. I, en segon lloc, va funcionar molt més que dues matrius.

Un altre exemple. Tens una matriu on emmagatzemes l'ID. I els pots traduir en noms. Funció arrayMap. Aquesta és una funció lambda típica. Passeu expressions lambda allà. I treu el valor del nom de cada identificació del diccionari.

La cerca es pot fer de la mateixa manera. Es passa una funció de predicat que verifica quins elements coincideixen.

Aquestes coses simplifiquen molt el circuit i resolen un munt de problemes.

Però el següent problema al qual ens enfrontem, i que m'agradaria esmentar, són les consultes eficients.

• ClickHouse no té un planificador de consultes. Absolutament no.
• No obstant això, encara s'han de planificar consultes complexes. En quins casos?
• Si hi ha diverses unions a la consulta, les embolcalleu en subseleccions. I l'ordre en què s'executen importa.
• I el segon - si la sol·licitud es distribueix. Perquè en una consulta distribuïda, només s'executa distribuïda la subselecció més interna i tota la resta es passa a un servidor al qual us heu connectat i executat allà. Per tant, si heu distribuït consultes amb moltes unions (join), heu de triar l'ordre.

I fins i tot en casos més senzills, de vegades també cal fer la feina del planificador i reescriure una mica les consultes.

Aquí teniu un exemple. Al costat esquerre hi ha una consulta que mostra els 5 països principals. I triga 2,5 segons, al meu entendre. I al costat dret, la mateixa consulta, però lleugerament reescrita. En lloc d'agrupar per cadena, vam començar a agrupar per clau (int). I és més ràpid. I després vam connectar un diccionari al resultat. En lloc de 2,5 segons, la sol·licitud triga 1,5 segons. Això és bo.

Un exemple similar amb els filtres de reescriptura. Aquí hi ha una petició per a Rússia. Funciona durant 5 segons. Si el tornem a escriure de manera que tornem a comparar no una cadena, sinó números amb algun conjunt d'aquestes claus relacionades amb Rússia, serà molt més ràpid.

Hi ha molts trucs així. I us permeten accelerar significativament les consultes que creieu que ja s'executen ràpidament o, per contra, s'executen lentament. Es poden fer encara més ràpid.

• Màxim treball en mode distribuït.
• Ordenant per tipus mínims, com vaig fer per int.
• Si hi ha unions (join), diccionaris, és millor fer-les com a últim recurs, quan ja teniu dades agrupades almenys parcialment, aleshores l'operació d'unió o la trucada de diccionari es cridarà menys vegades i serà més ràpid. .
• Substitució de filtres.

Hi ha altres tècniques, i no només les que he demostrat. I tots ells de vegades poden accelerar significativament l'execució de consultes.

Passem al següent exemple. Empresa X dels EUA. Què està fent?

Hi havia una tasca:

• Enllaç fora de línia de transaccions publicitàries.
• Modelatge de diferents models d'enquadernació.

Quin és l'escenari?

Un visitant normal ve al lloc, per exemple, 20 vegades al mes des de diferents anuncis, o així de vegades ve sense cap anunci, perquè recorda aquest lloc. Mira alguns productes, els posa a la cistella, els treu de la cistella. I, al final, alguna cosa compra.

Preguntes raonables: "Qui ha de pagar la publicitat, si cal?" i “Quina publicitat el va influir, si n'hi ha cap?”. És a dir, per què va comprar i com fer que gent com aquesta persona també compri?

Per resoldre aquest problema, cal connectar els esdeveniments que es produeixen al lloc web de la manera correcta, és a dir, establir d'alguna manera una connexió entre ells. Després s'envien per analitzar-los a DWH. I a partir d'aquesta anàlisi, creeu models de qui i quins anuncis mostrar.

Una transacció publicitària és un conjunt d'esdeveniments relacionats amb l'usuari que comencen a mostrar un anunci, després passa alguna cosa, potser una compra i després hi pot haver compres dins d'una compra. Per exemple, si es tracta d'una aplicació per a mòbils o d'un joc per a mòbils, normalment la instal·lació de l'aplicació es fa de manera gratuïta i, si s'hi fa alguna cosa, és possible que es requereixin diners per a això. I com més gasta una persona en l'aplicació, més valuosa és. Però per això cal connectar-ho tot.

Hi ha molts models d'enquadernació.

Els més populars són:

• Última interacció, on la interacció és un clic o una impressió.
• Primera interacció, és a dir, la primera cosa que va portar una persona al lloc.
• Combinació lineal: tots per igual.
• Atenuació.
• Etcètera.

I com va funcionar tot en primer lloc? Hi havia Runtime i Cassandra. Cassandra es va utilitzar com a emmagatzematge de transaccions, és a dir, totes les transaccions relacionades s'hi emmagatzemaven. I quan arriba algun esdeveniment en temps d'execució, per exemple, mostrant alguna pàgina o una altra cosa, es va fer una sol·licitud a Cassandra: hi ha aquesta persona o no? Després es van obtenir les transaccions que s'hi relacionen. I la connexió es va fer.

I si té sort que la sol·licitud tingui un identificador de transacció, és fàcil. Però normalment no hi ha sort. Per tant, calia trobar l'última transacció o la transacció amb l'últim clic, etc.

I tot va funcionar molt bé sempre que l'enquadernació fos fins a l'últim clic. Perquè hi ha, per exemple, 10 milions de clics al dia, 300 milions al mes, si establim una finestra per a un mes. I com que a Cassandra ha d'estar tot a la memòria per poder funcionar ràpidament, perquè el Runtime ha de respondre ràpidament, es van necessitar uns 10-15 servidors.

I quan volien enllaçar una transacció a la pantalla, immediatament no va resultar tan divertit. I per què? Es pot veure que cal emmagatzemar 30 vegades més esdeveniments. I, en conseqüència, necessiteu 30 vegades més servidors. I resulta que aquesta és una mena de figura astronòmica. Per mantenir fins a 500 servidors per fer l'enllaç, malgrat que hi ha molt menys servidors en temps d'execució, aquesta és una xifra incorrecta. I van començar a pensar què fer.

I vam anar a ClickHouse. I com fer-ho a ClickHouse? A primera vista, sembla que es tracta d'un conjunt d'anti-patrons.

• La transacció creix, hi connectem cada cop més esdeveniments, és a dir, és mutable i ClickHouse no funciona molt bé amb objectes mutables.
• Quan un visitant ve a nosaltres, hem de treure les seves transaccions per clau, amb el seu identificador de visita. Aquesta també és una consulta de punts, no ho fan a ClickHouse. En general, ClickHouse té grans ... exploracions, però aquí necessitem obtenir alguns registres. També un antipatró.
• A més, la transacció estava en json, però no volien reescriure-la, així que volien emmagatzemar json d'una manera no estructurada i, si calia, treure'n alguna cosa. I això també és un antipatró.

És a dir, un conjunt d'antipatrons.

Però tanmateix va resultar fer un sistema que funcionava molt bé.

Què es va fer? Va aparèixer ClickHouse, on es van llançar registres, dividits en registres. Va aparèixer un servei atribuït que va rebre registres de ClickHouse. Després d'això, per cada entrada per identificador de visita, vaig rebre transaccions que encara no s'havien pogut processar i més instantànies, és a dir, transaccions ja connectades, és a dir, el resultat del treball anterior. Ja els vaig fer lògica, vaig triar la transacció correcta, vaig connectar nous esdeveniments. S'ha tornat a iniciar sessió. El registre va tornar a ClickHouse, és a dir, és un sistema constantment cíclic. I a més, vaig anar a DWH per analitzar-ho allà.

Va ser en aquesta forma que no va funcionar gaire bé. I per facilitar-ho a ClickHouse, quan hi havia una sol·licitud per identificador de visita, van agrupar aquestes sol·licituds en blocs d'1-000 identificadors de visites i van treure totes les transaccions per a 2-000 persones. I després tot va funcionar.

Si mireu dins de ClickHouse, només hi ha 3 taules principals que serveixen tot això.

La primera taula a la qual es carreguen els registres i els registres es carreguen gairebé sense processar-los.

Segona taula. A través de la visió materialitzada, els esdeveniments que encara no s'han atribuït, és a dir, no relacionats, van ser mossegats d'aquests registres. I a través de la vista materialitzada, les transaccions es van extreure d'aquests registres per crear una instantània. És a dir, una vista materialitzada especial va crear una instantània, és a dir, l'últim estat acumulat de la transacció.

Aquí teniu el text escrit en SQL. M'agradaria comentar-hi algunes coses importants.

El primer important és la possibilitat de treure columnes i camps de json a ClickHouse. És a dir, ClickHouse té alguns mètodes per treballar amb json. Són molt, molt primitius.

visitParamExtractInt us permet extreure atributs de json, és a dir, el primer cop funciona. I d'aquesta manera podeu treure l'identificador de transacció o visitar l'identificador. Aquesta vegada.

En segon lloc, aquí s'utilitza un camp materialitzat complicat. Què vol dir? Això vol dir que no el podeu inserir a la taula, és a dir, no s'insereix, es calcula i s'emmagatzema en inserir-lo. Quan enganxeu, ClickHouse fa la feina per vosaltres. I el que necessiteu més endavant ja s'ha extret de json.

En aquest cas, la vista materialitzada és per a files en brut. I s'acaba d'utilitzar la primera taula amb troncs pràcticament crus. I què fa? En primer lloc, canvia l'ordenació, és a dir, l'ordenació ara passa per l'identificador de visita, perquè hem de treure ràpidament una transacció per a una persona específica.

La segona cosa important és index_granularity. Si heu vist MergeTree, normalment és 8 per defecte index_granularity. Què és això? Aquest és el paràmetre de dispersió de l'índex. A ClickHouse l'índex és escàs, mai indexa totes les entrades. Ho fa cada 192 8. I això és bo quan cal calcular moltes dades, però és dolent quan hi ha una mica, perquè hi ha una gran sobrecàrrega. I si reduïm la granularitat de l'índex, reduïm la sobrecàrrega. No es pot reduir a un, perquè potser no hi ha prou memòria. L'índex s'emmagatzema sempre a la memòria.

Snapshot també utilitza algunes altres funcions interessants de ClickHouse.

En primer lloc, és AggregatingMergeTree. I AggregatingMergeTree emmagatzema argMax, és a dir, aquest és l'estat de la transacció corresponent a la darrera marca de temps. Les transaccions es generen tot el temps per a un visitant determinat. I en l'últim estat d'aquesta transacció, hem afegit un esdeveniment i tenim un nou estat. Va tornar a tocar ClickHouse. I mitjançant argMax en aquesta vista materialitzada, sempre podem obtenir l'estat actual.

• L'enllaç està "desacoblat" del temps d'execució.
• S'emmagatzemen i processen fins a 3 milions de transaccions al mes. Això és un ordre de magnitud més que a Cassandra, és a dir, en un sistema transaccional típic.
• Clúster de servidors ClickHouse 2x5. 5 servidors i cada servidor té una rèplica. Això és encara menys que a Cassandra per fer l'atribució basada en clics, i aquí tenim la funció d'impressió. És a dir, en comptes d'augmentar el nombre de servidors en 30 vegades, van aconseguir reduir-los.

I l'últim exemple és l'empresa financera Y, que va analitzar les correlacions de canvis en els preus de les accions.

I la tasca era:

• Hi ha aproximadament 5 accions.
• Es coneixen les cotitzacions cada 100 mil·lisegons.
• Les dades s'han acumulat durant 10 anys. Pel que sembla, per a algunes empreses més, per a altres menys.
• Hi ha aproximadament 100 milions de files en total.

I calia calcular la correlació de canvis.

Aquí hi ha dues accions i les seves cotitzacions. Si un puja i l'altre puja, llavors aquesta és una correlació positiva, és a dir, un puja i l'altre puja. Si un puja, com al final del gràfic, i l'altre baixa, és una correlació negativa, és a dir, quan un puja, l'altre baixa.

Analitzant aquests canvis mutus, es poden fer prediccions al mercat financer.

Però la tasca és difícil. Què s'està fent per això? Tenim 100 milions de registres que tenen: temps, estoc i preu. Hem de calcular primers 100 milions de vegades la diferència corrent de l'algoritme de preus. RunningDifference és una funció de ClickHouse que calcula de manera seqüencial la diferència entre dues cadenes.

I després d'això, cal calcular la correlació i la correlació s'ha de calcular per a cada parell. Per a 5 accions, les parelles són 000 milions. I això és molt, és a dir, 12,5 vegades és necessari calcular aquesta funció de correlació.

I si algú ho oblida, aleshores ͞x i ͞y són un escac i mat. expectativa de mostreig. És a dir, no només cal calcular les arrels i les sumes, sinó també una suma més dins d'aquestes sumes. Cal fer un munt de càlculs 12,5 milions de vegades, i fins i tot agrupats per hores. També tenim moltes hores. I ho has de fer en 60 segons. És una broma.

Calia tenir temps almenys d'alguna manera, perquè tot això funcionava molt i molt lentament abans que arribés ClickHouse.

Van intentar calcular-ho a Hadoop, a Spark, a Greenplum. I tot això va ser molt lent o car. És a dir, d'alguna manera era possible calcular, però després era car.

I després va aparèixer ClickHouse i les coses van millorar molt.

Us recordo que tenim un problema amb la localitat de les dades, perquè les correlacions no es poden localitzar. No podem posar algunes de les dades en un servidor, algunes en un altre i calcular, hem de tenir totes les dades a tot arreu.

Que van fer? Inicialment, les dades estan localitzades. Cada servidor emmagatzema dades sobre el preu d'un determinat conjunt d'accions. I no es superposen. Per tant, és possible calcular logReturn en paral·lel i de manera independent, tot això passa fins ara en paral·lel i distribuït.

Aleshores vam decidir reduir aquestes dades, sense perdre expressivitat. Reduïu l'ús de matrius, és a dir, per a cada període de temps, feu una matriu d'existències i una matriu de preus. Per tant, ocupa molt menys espai de dades. I és una mica més fàcil de treballar amb ells. Són operacions gairebé paral·leles, és a dir, llegim parcialment en paral·lel i després escrivim al servidor.

Després d'això, es pot replicar. La lletra "r" significa que hem replicat aquestes dades. És a dir, tenim les mateixes dades als tres servidors: aquestes són les matrius.

I després amb un script especial d'aquest conjunt de 12,5 milions de correlacions que cal calcular, podeu fer paquets. És a dir, 2 tasques amb 500 parells de correlacions. I aquesta tasca s'ha de calcular en un servidor ClickHouse específic. Té totes les dades, perquè les dades són les mateixes i pot calcular-les seqüencialment.

Una vegada més, aquest és el que sembla. En primer lloc, tenim totes les dades en aquesta estructura: temps, accions, preu. Després hem calculat logReturn, és a dir, dades de la mateixa estructura, però en comptes del preu ja tenim logReturn. Després es van tornar a fer, és a dir, vam obtenir el temps i el grup Array per a les existències i els preus. Sreplicat. I després d'això, vam generar un munt de tasques i les vam donar a ClickHouse perquè les comptés. I funciona.

En prova de concepte, la tasca era una subtasca, és a dir, es van agafar menys dades. I només tres servidors.

Les dues primeres etapes: calcular Log_return i embolicar en matrius van trigar aproximadament una hora.

I el càlcul de la correlació és d'unes 50 hores. Però amb 50 hores no n'hi ha prou, perquè treballaven durant setmanes. Va ser un gran èxit. I si compteu, aleshores 70 vegades per segon es va comptar tot en aquest clúster.

Però el més important és que aquest sistema pràcticament no té colls d'ampolla, és a dir, escala gairebé linealment. I ho van comprovar. S'ha ampliat correctament.

• L'esquema correcte és la meitat de l'èxit. I l'esquema correcte és l'ús de totes les tecnologies ClickHouse necessàries.
• Summing/AggregatingMergeTrees són tecnologies que us permeten agregar o considerar una instantània d'estat com un cas especial. I simplifica moltíssimes coses.
• Les vistes materialitzades us permeten ometre el límit d'un índex. Potser no ho vaig dir molt clar, però quan vam carregar els registres, els registres en brut estaven a la taula amb un índex i els registres d'atributs estaven a la taula, és a dir, les mateixes dades, només filtrades, però l'índex estava completament. altres. Sembla que són les mateixes dades, però una ordenació diferent. I les vistes materialitzades us permeten, si ho necessiteu, evitar aquesta limitació de ClickHouse.
• Reduïu la granularitat de l'índex per a les consultes de punts.
• I distribuïu les dades de manera intel·ligent, intenteu localitzar les dades dins del servidor tant com sigui possible. I intenteu assegurar-vos que les sol·licituds també utilitzin la localització, sempre que sigui possible, tant com sigui possible.

I resumint aquest breu discurs, podem dir que ara ClickHouse ha ocupat amb fermesa el territori tant de les bases de dades comercials com de les bases de dades de codi obert, és a dir, específicament per a l'anàlisi. Encaixa perfectament en aquest paisatge. I, a més, a poc a poc comença a expulsar els altres, perquè quan teniu ClickHouse, no necessiteu InfiniDB. És possible que Vertika no sigui necessari aviat si fan suport SQL normal. Gaudeix!

-Gràcies pel reportatge! Molt interessant! Hi ha hagut comparacions amb Apache Phoenix?

No, no he sentit a ningú comparar. Nosaltres i Yandex intentem fer un seguiment de totes les comparacions de ClickHouse amb diferents bases de dades. Perquè si de sobte alguna cosa resulta més ràpid que ClickHouse, aleshores Lesha Milovidov no pot dormir a la nit i comença a accelerar-ho ràpidament. No he sentit a parlar d'aquesta comparació.

• (Aleksey Milovidov) Apache Phoenix és un motor SQL impulsat per Hbase. Hbase és principalment per a un escenari de treball clau-valor. Allà, a cada línia, hi pot haver un nombre arbitrari de columnes amb noms arbitraris. Això es pot dir sobre sistemes com Hbase, Cassandra. I són precisament les consultes analítiques pesades les que no els funcionaran normalment. O potser penseu que funcionen bé si no heu tingut cap experiència amb ClickHouse.

• Gràcies

  • Bona tarda Aquest tema ja m'interessa força, perquè tinc un subsistema analític. Però quan miro ClickHouse, tinc la sensació que ClickHouse és molt adequat per a l'anàlisi d'esdeveniments, mutable. I si necessito analitzar moltes dades empresarials amb un munt de taules grans, llavors ClickHouse, pel que entenc, no és molt adequat per a mi? Sobretot si canvien. És correcte o hi ha exemples que puguin refutar-ho?

  • Això està bé. I això passa amb la majoria de bases de dades analítiques especialitzades. Estan fets a mida perquè hi ha una o més taules grans que són mutables, i per a moltes taules petites que canvien lentament. És a dir, ClickHouse no és com Oracle, on pots posar-ho tot i construir consultes molt complexes. Per utilitzar ClickHouse de manera eficaç, heu de crear un esquema d'una manera que funcioni bé a ClickHouse. És a dir, evitar una normalització excessiva, utilitzar diccionaris, intentar fer menys enllaços llargs. I si l'esquema es construeix d'aquesta manera, tasques empresarials similars es poden resoldre a ClickHouse de manera molt més eficient que en una base de dades relacional tradicional.

Gràcies pel reportatge! Tinc una pregunta sobre l'últim cas financer. Tenien analítiques. Calia comparar com pujaven i baixaven. I entenc que heu creat el sistema específicament per a aquesta anàlisi? Si demà, per exemple, necessiten algun altre informe sobre aquestes dades, han de reconstruir l'esquema i pujar les dades? És a dir, fer algun tipus de preprocessament per obtenir la sol·licitud?

Per descomptat, aquest és l'ús de ClickHouse per a una tasca molt específica. Es podria resoldre de manera més tradicional a Hadoop. Per a Hadoop, aquesta és una tasca ideal. Però a Hadoop és molt lent. I el meu objectiu és demostrar que ClickHouse pot resoldre tasques que normalment es resolen per mitjans completament diferents, però al mateix temps fer-ho de manera molt més eficient. Està dissenyat per a una tasca específica. Està clar que si hi ha un problema amb alguna cosa semblant, llavors es pot resoldre d'una manera semblant.

Està clar. Vostè va dir que es van tramitar 50 hores. És des del principi, quan vau carregar les dades o obtenir els resultats?

Sí sí.

OK moltes gràcies.

Això és en un clúster de 3 servidors.

Salutacions! Gràcies pel reportatge! Tot és molt interessant. No preguntaré una mica sobre la funcionalitat, sinó sobre l'ús de ClickHouse en termes d'estabilitat. És a dir, n'has tingut algun, n'has hagut de restaurar? Com es comporta ClickHouse en aquest cas? I va passar que també tenies una rèplica? Per exemple, hem trobat un problema amb ClickHouse quan encara surt del seu límit i cau.

Per descomptat, no hi ha sistemes ideals. I ClickHouse també té els seus propis problemes. Però, heu sentit a dir que Yandex.Metrica no funciona durant molt de temps? Probablement no. Funciona de manera fiable des de 2012-2013 a ClickHouse. Puc dir el mateix de la meva experiència. Mai hem tingut fracassos complets. Podien passar algunes coses parcials, però mai van ser prou crítiques com per afectar seriosament el negoci. No va passar mai. ClickHouse és bastant fiable i no es bloqueja a l'atzar. No us heu de preocupar per això. No és una cosa crua. Això ho han demostrat moltes empreses.

Hola! Heu dit que heu de pensar immediatament en l'esquema de dades. I si ha passat? Les meves dades s'estan abocant. Passen sis mesos, i entenc que és impossible viure així, necessito tornar a pujar les dades i fer alguna cosa amb elles.

Això depèn, per descomptat, del vostre sistema. Hi ha diverses maneres de fer-ho pràcticament sense parar. Per exemple, podeu crear una vista materialitzada en la qual crear una estructura de dades diferent si es pot mapejar de manera única. És a dir, si permet mapejar mitjançant ClickHouse, és a dir, extreure algunes coses, canviar la clau primària, canviar la partició, aleshores podeu fer una Vista materialitzada. Sobreescriu les teves dades antigues allà, les noves s'escriuran automàticament. I després només canvieu a utilitzar la Vista materialitzada, després canvieu el registre i mateu la taula antiga. Aquest és generalment un mètode sense parar.

Gràcies.

Font: www.habr.com