Teoría e práctica do uso de ClickHouse en aplicacións reais. Alexander Zaitsev (2018)

A pesar de que agora hai moitos datos en case todas partes, as bases de datos analíticas aínda son bastante exóticas. Son pouco coñecidos e aínda peor poden utilizalos con eficacia. Moitos seguen "comendo cactus" con MySQL ou PostgreSQL, que están deseñados para outros escenarios, sofren con NoSQL ou pagan de máis por solucións comerciais. ClickHouse cambia as regras do xogo e reduce significativamente o limiar para entrar no mundo do DBMS analítico.

Informe de BackEnd Conf 2018 e publícase co permiso do relator.

Quen son eu e por que falo de ClickHouse? Son director de desenvolvemento en LifeStreet, que usa ClickHouse. Ademais, son o fundador de Altinity. É un socio de Yandex que promove ClickHouse e axuda a Yandex a que ClickHouse teña máis éxito. Tamén está preparado para compartir coñecementos sobre ClickHouse.

E non son o irmán de Petya Zaitsev. Moitas veces me preguntan por isto. Non, non somos irmáns.

"Todo o mundo sabe" que ClickHouse:

• Moi rápido,
• Moi cómodo
• Usado en Yandex.

Sábese un pouco menos en que empresas e como se utiliza.

Vouche dicir por que, onde e como se usa ClickHouse, excepto Yandex.

Contareivos como se resolven tarefas específicas coa axuda de ClickHouse en diferentes empresas, que ferramentas de ClickHouse podes utilizar para as túas tarefas e como se utilizaron en diferentes empresas.

Collín tres exemplos que mostran a ClickHouse desde diferentes ángulos. Creo que será interesante.

A primeira pregunta é: "Por que necesitamos ClickHouse?". Parece unha pregunta bastante obvia, pero hai máis dunha resposta para ela.

• A primeira resposta é para o rendemento. ClickHouse é moi rápido. A analítica en ClickHouse tamén é moi rápida. Moitas veces pódese usar onde outra cousa é moi lenta ou moi mala.
• A segunda resposta é o custo. E, en primeiro lugar, o custo da escala. Por exemplo, Vertica é unha base de datos absolutamente xenial. Funciona moi ben se non tes moitos terabytes de datos. Pero cando se trata de centos de terabytes ou petabytes, o custo dunha licenza e soporte ascende a unha cantidade bastante importante. E é caro. E ClickHouse é gratuíto.
• A terceira resposta é o custo operativo. Este é un enfoque lixeiramente diferente. RedShift é un gran analóxico. En RedShift, podes tomar unha decisión moi rapidamente. Funcionará ben, pero ao mesmo tempo, cada hora, todos os días e cada mes, pagarás a Amazon bastante caro, porque este é un servizo moi caro. Google BigQuery tamén. Se alguén o usou, entón sabe que alí pode realizar varias solicitudes e obter unha factura por centos de dólares de súpeto.

ClickHouse non ten estes problemas.

Onde se usa agora ClickHouse? Ademais de Yandex, ClickHouse utilízase nunha serie de negocios e empresas diferentes.

• En primeiro lugar, trátase de análise de aplicacións web, é dicir, este é un caso de uso procedente de Yandex.
• Moitas empresas de AdTech usan ClickHouse.
• Numerosas empresas que precisan analizar rexistros de transaccións de diferentes fontes.
• Varias empresas usan ClickHouse para supervisar os rexistros de seguridade. Súbenos a ClickHouse, elaboran informes e obteñen os resultados que necesitan.
• As empresas comezan a utilizalo na análise financeira, é dicir, pouco a pouco as grandes empresas tamén se achegan a ClickHouse.
• cloudflare. Se alguén segue a ClickHouse, probablemente escoitou o nome desta empresa. Este é un dos colaboradores esenciais da comunidade. E teñen unha instalación de ClickHouse moi seria. Por exemplo, fixeron Kafka Engine para ClickHouse.
• As empresas de telecomunicacións comezaron a utilizar. Varias empresas usan ClickHouse como proba de concepto ou xa está en produción.
• Unha empresa usa ClickHouse para supervisar os procesos de produción. Proban microcircuítos, eliminan unha morea de parámetros, hai unhas 2 características. E despois analizan se o xogo é bo ou malo.
• Análise Blockchain. Hai unha empresa rusa como Bloxy.info. Esta é unha análise da rede ethereum. Tamén o fixeron en ClickHouse.

E o tamaño non importa. Hai moitas empresas que usan un servidor pequeno. E permítelles resolver os seus problemas. E aínda máis empresas usan grandes clústeres de moitos servidores ou decenas de servidores.

E se miras os rexistros, entón:

• Yandex: máis de 500 servidores, almacenan alí 25 millóns de rexistros ao día.
• LifeStreet: 60 servidores, aproximadamente 75 mil millóns de rexistros por día. Hai menos servidores, máis rexistros que en Yandex.
• CloudFlare: 36 servidores, aforran 200 millóns de rexistros ao día. Teñen aínda menos servidores e almacenan aínda máis datos.
• Bloomberg: 102 servidores, preto dun billón de entradas por día. Titular do récord.

Xeograficamente, isto tamén é moito. Este mapa mostra un mapa de calor de onde se está a usar ClickHouse no mundo. Aquí destacan claramente Rusia, China e América. Hai poucos países europeos. E hai 4 grupos.

Trátase dunha análise comparativa, non hai que buscar cifras absolutas. Esta é unha análise dos visitantes que len materiais en inglés no sitio web de Altinity, porque alí non hai ningún rusofalante. E Rusia, Ucraína, Bielorrusia, é dicir, a parte rusofalante da comunidade, estes son os usuarios máis numerosos. Despois veñen EEUU e Canadá. China está a poñerse moi ao día. Hai seis meses case non había China alí, agora China xa superou a Europa e segue medrando. A vella Europa tampouco se queda atrás, e o líder no uso de ClickHouse é, curiosamente, Francia.

Por que estou contando todo isto? Para demostrar que ClickHouse se está a converter nunha solución estándar para a análise de big data e que xa se usa en moitos lugares. Se o usas, estás na tendencia correcta. Se aínda non o estás a usar, non podes ter medo de quedarte só e ninguén o axudará, porque moitos xa o están facendo.

Estes son exemplos de uso real de ClickHouse en varias empresas.

• O primeiro exemplo é unha rede publicitaria: migración de Vertica a ClickHouse. E coñezo algunhas empresas que pasaron de Vertica ou están en proceso de transición.
• O segundo exemplo é o almacenamento transaccional en ClickHouse. Este é un exemplo construído sobre antipatróns. Todo o que non se debe facer en ClickHouse baixo o consello dos desenvolvedores faise aquí. E faise tan eficazmente que funciona. E funciona moito mellor que a solución transaccional típica.
• O terceiro exemplo é a computación distribuída en ClickHouse. Houbo unha pregunta sobre como se pode integrar ClickHouse no ecosistema de Hadoop. Vou amosar un exemplo de como unha empresa fixo algo semellante a un contedor de redución de mapas en ClickHouse, facendo un seguimento da localización de datos, etc., para calcular unha tarefa moi pouco trivial.

• LifeStreet é unha empresa de tecnoloxía publicitaria que ten toda a tecnoloxía que inclúe unha rede publicitaria.
• Dedícase á optimización de anuncios, licitacións programáticas.
• Moitos datos: uns 10 millóns de eventos por día. Ao mesmo tempo, os eventos alí pódense dividir en varios subeventos.
• Hai moitos clientes destes datos, e estes non son só persoas, moito máis: son varios algoritmos que se dedican a licitacións programáticas.

A empresa percorreu un camiño longo e espiñento. E falei diso en HighLoad. En primeiro lugar, LifeStreet trasladouse de MySQL (cunha pequena parada en Oracle) a Vertica. E podes atopar unha historia sobre iso.

E todo estaba moi ben, pero axiña quedou claro que os datos están crecendo e Vertica é caro. Por iso, buscáronse diversas alternativas. Algúns deles están enumerados aquí. E de feito, fixemos probas de concepto ou, ás veces, probas de rendemento de case todas as bases de datos que estaban dispoñibles no mercado desde o ano 13 ata o 16 e que eran aproximadamente adecuadas en canto a funcionalidade. E tamén falei dalgúns deles en HighLoad.

A tarefa era migrar desde Vertica en primeiro lugar, porque os datos creceron. E creceron exponencialmente ao longo dos anos. Despois foron ao andel, pero así e todo. E predicindo este crecemento, os requisitos comerciais para a cantidade de datos sobre os que había que facer algún tipo de análise, estaba claro que os petabytes pronto se discutirían. E pagar por petabytes xa é moi caro, así que buscabamos unha alternativa onde ir.

Onde ir? E durante moito tempo non estaba nada claro a onde ir, porque por unha banda hai bases de datos comerciais, parecen funcionar ben. Algúns funcionan case tan ben como Vertica, outros peor. Pero todos son caros, non se puido atopar nada máis barato e mellor.

Por outra banda, hai solucións de código aberto, que non son moi numerosas, é dicir, para as analíticas, pódense contar cos dedos. E son gratuítos ou baratos, pero lentos. E moitas veces carecen da funcionalidade necesaria e útil.

E non había nada que combinar o ben que hai nas bases de datos comerciais e todo o gratuíto que hai en código aberto.

Non houbo nada ata que, inesperadamente, Yandex sacou ClickHouse, como un mago dun sombreiro, como un coello. E foi unha decisión inesperada, seguen facendo a pregunta: “Por que?”, pero con todo.

E de inmediato, no verán de 2016, comezamos a ver o que é ClickHouse. E resultou que ás veces pode ser máis rápido que Vertica. Probamos diferentes escenarios en diferentes solicitudes. E se a consulta só utilizaba unha táboa, é dicir, sen ningunha unión (unir), entón ClickHouse foi o dobre de rápido que Vertica.

Non era moi preguiceiro e mirei as probas de Yandex o outro día. Alí pasa o mesmo: ClickHouse é o dobre de rápido que Vertica, polo que adoitan falar diso.

Pero se hai unións nas consultas, entón todo resulta non moi inequívoco. E ClickHouse pode ser dúas veces máis lento que Vertica. E se corrixes lixeiramente a solicitude e a reescribes, entón son aproximadamente iguais. Non está mal. E gratuíto.

E despois de recibir os resultados das probas e mirando desde diferentes ángulos, LifeStreet foi a ClickHouse.

Este é o 16o ano, recórdovos. Era como unha broma sobre os ratos que choraban e se picaban, pero seguían comendo o cacto. E isto foi descrito en detalle, hai un vídeo sobre isto, etc.

Polo tanto, non vou falar sobre iso en detalle, só falarei dos resultados e algunhas cousas interesantes das que non falei entón.

Os resultados son:

• Migración exitosa e máis dun ano o sistema xa funciona en produción.
• A produtividade e a flexibilidade aumentaron. Dos 10 millóns de discos que podíamos permitirnos almacenar ao día e logo durante un curto período de tempo, LifeStreet agora almacena 75 millóns de rexistros ao día e pode facelo durante 3 meses ou máis. Se contas no pico, isto supón ata un millón de eventos por segundo. Máis dun millón de consultas SQL ao día chegan a este sistema, na súa maioría de diferentes robots.
• A pesar de que se usaron máis servidores para ClickHouse que para Vertica, tamén se aforraron en hardware, porque en Vertica utilizáronse discos SAS bastante caros. ClickHouse usou SATA. E por que? Porque en Vertica inserir é sincrónico. E a sincronización require que os discos non se ralentice demasiado, e tamén que a rede non se ralentice demasiado, é dicir, unha operación bastante cara. E en ClickHouse a inserción é asíncrona. Ademais, sempre podes escribir todo localmente, non hai custos adicionais para iso, polo que os datos pódense inserir en ClickHouse moito máis rápido que en Vertika, incluso en unidades máis lentas. E ler é case o mesmo. Lendo en SATA, se están en RAID, todo isto é o suficientemente rápido.
• Non limitado pola licenza, é dicir, 3 petabytes de datos en 60 servidores (20 servidores son unha réplica) e 6 billóns de rexistros en feitos e agregacións. Nada como isto se podía permitir en Vertica.

Agora vou a cousas prácticas neste exemplo.

• O primeiro é un esquema eficiente. Depende moito do esquema.
• O segundo é a xeración eficiente de SQL.

Unha consulta OLAP típica é unha selección. Algunhas das columnas van para agrupar por, algunhas das columnas van para funcións agregadas. Hai onde, que se pode representar como unha porción dun cubo. Todo o grupo por pode ser pensado como unha proxección. E por iso chámase análise de datos multivariante.

E moitas veces isto é modelado en forma de esquema de estrelas, cando hai un feito central e características deste feito ao longo dos lados, ao longo dos raios.

E en canto ao deseño físico, como encaixa sobre a mesa, adoitan facer unha representación normalizada. Podes desnormalizar, pero é caro no disco e non é moi eficiente nas consultas. Polo tanto, adoitan facer unha representación normalizada, é dicir, unha táboa de feitos e moitas, moitas táboas de dimensións.

Pero non funciona ben en ClickHouse. Hai dúas razóns:

• O primeiro é porque ClickHouse non ten unións moi boas, é dicir, hai unións, pero son malas. Aínda que mal.
• A segunda é que as táboas non están actualizadas. Normalmente nestas placas, que están ao redor do circuíto estelar, hai que cambiar algo. Por exemplo, nome do cliente, nome da empresa, etc. E non funciona.

E hai unha saída a isto en ClickHouse. ata dous:

• O primeiro é o uso de dicionarios. Os dicionarios externos son os que axudan ao 99% a resolver o problema co esquema estrela, con actualizacións, etc.
• O segundo é o uso de matrices. As matrices tamén axudan a desfacerse das unións e problemas coa normalización.

• Non é necesario unirse.
• Actualizable. Desde marzo de 2018 apareceu unha oportunidade sen documentar (non atoparás isto na documentación) para actualizar parcialmente os dicionarios, é dicir, aquelas entradas que cambiaron. Practicamente, é como unha mesa.
• Sempre na memoria, polo que se une cun dicionario máis rápido que se fose unha táboa que está en disco e aínda non é un feito que estea na caché, o máis probable é que non.

• Tampouco precisas unións.
• Esta é unha representación compacta de 1 a moitos.
• E na miña opinión, as matrices están feitas para frikis. Estas son funcións lambda e así por diante.

Isto non é para palabras vermellas. Esta é unha funcionalidade moi poderosa que che permite facer moitas cousas dun xeito moi sinxelo e elegante.

Exemplos típicos que axudan a resolver matrices. Estes exemplos son sinxelos e suficientemente claros:

• Busca por etiquetas. Se tes hashtags alí e queres atopar algunhas publicacións por hashtag.
• Busca por pares clave-valor. Tamén hai algúns atributos cun valor.
• Almacenando listas de claves que precisa traducir noutra cousa.

Todas estas tarefas pódense resolver sen matrices. As etiquetas pódense poñer nalgunha liña e seleccionarse cunha expresión regular ou nunha táboa separada, pero entón tes que facer unións.

E en ClickHouse, non precisa facer nada, abonda con describir a matriz de cadeas para os hashtags ou facer unha estrutura aniñada para os sistemas de clave-valor.

A estrutura anidada pode non ser o mellor nome. Trátase de dúas matrices que teñen unha parte común no nome e algunhas características relacionadas.

E é moi doado buscar por etiqueta. Ter unha función has, que verifica que a matriz conteña un elemento. Todos, atoparon todas as entradas relacionadas coa nosa conferencia.

A busca por subid é un pouco máis complicada. Necesitamos primeiro atopar o índice da clave, e despois tomar o elemento con este índice e comprobar que este valor é o que necesitamos. Non obstante, é moi sinxelo e compacto.

A expresión regular que che gustaría escribir se o mantiveses todo nunha liña, sería, en primeiro lugar, torpe. E, en segundo lugar, funcionou moito máis tempo que dúas matrices.

Outro exemplo. Tes unha matriz onde almacenas o ID. E podes traducilos en nomes. Función arrayMap. Esta é unha función lambda típica. Pasas expresións lambda alí. E ela saca o valor do nome para cada ID do dicionario.

A busca pódese facer do mesmo xeito. Pásase unha función de predicado que verifica cales coinciden os elementos.

Estas cousas simplifican moito o circuíto e solucionan unha morea de problemas.

Pero o seguinte problema ao que nos enfrontamos, e que me gustaría mencionar, son as consultas eficientes.

• ClickHouse non ten un planificador de consultas. Absolutamente non.
• Non obstante, aínda hai que planificar consultas complexas. En que casos?
• Se hai varias unións na consulta, engádesas en subseleccions. E a orde en que se executan importa.
• E o segundo - se a solicitude é distribuída. Porque nunha consulta distribuída, só se executa distribuída a subselección máis interna e todo o demais pásase a un servidor ao que conectou e executou alí. Polo tanto, se distribuíu consultas con moitas unións (unir), entón cómpre escoller a orde.

E mesmo en casos máis sinxelos, ás veces tamén é necesario facer o traballo do planificador e reescribir un pouco as consultas.

Aquí tes un exemplo. No lado esquerdo hai unha consulta que mostra os 5 países principais. E leva 2,5 segundos, na miña opinión. E no lado dereito, a mesma consulta, pero lixeiramente reescrita. En lugar de agrupar por cadea, comezamos a agrupar por clave (int). E é máis rápido. E despois conectamos un dicionario ao resultado. En lugar de 2,5 segundos, a solicitude leva 1,5 segundos. Isto é bo.

Un exemplo semellante con filtros de reescritura. Aquí está unha solicitude para Rusia. Funciona durante 5 segundos. Se o reescribimos de forma que volvamos a comparar non unha cadea, senón números con algún conxunto desas claves que se relacionan con Rusia, entón será moito máis rápido.

Hai moitos trucos deste tipo. E permítenche acelerar significativamente as consultas que pensas que xa se están executando rápido ou, pola contra, lentamente. Pódense facer aínda máis rápido.

• Máximo traballo en modo distribuído.
• Ordenando por tipos mínimos, como fixen por int.
• Se hai unións (join), dicionarios, entón é mellor facelo como último recurso, cando xa tes datos agrupados polo menos parcialmente, entón a operación de unión ou a chamada de dicionario chamarase menos veces e será máis rápido. .
• Substitución de filtros.

Hai outras técnicas, e non só as que eu demostrei. E todos eles ás veces poden acelerar significativamente a execución das consultas.

Pasemos ao seguinte exemplo. Empresa X de USA. Que está facendo ela?

Houbo unha tarefa:

• Ligazón offline de transaccións publicitarias.
• Modelado de diferentes modelos de encadernación.

Cal é o escenario?

Un visitante común chega ao sitio, por exemplo, 20 veces ao mes de diferentes anuncios, ou así ás veces chega sen ningún anuncio, porque lembra este sitio. Mira uns produtos, méteos na cesta, sácaos da cesta. E, ao final, algo compra.

Preguntas razoables: "Quen debe pagar a publicidade, se é necesario?" e “¿Que publicidade lle influíu, se a houbera?”. É dicir, por que comprou e como conseguir que xente coma esta tamén compre?

Para resolver este problema, cómpre conectar os eventos que ocorren no sitio web do xeito correcto, é dicir, construír de algunha maneira unha conexión entre eles. Despois envíanse para a súa análise a DWH. E con base nesta análise, constrúe modelos de quen e que anuncios mostrar.

Unha transacción publicitaria é un conxunto de eventos de usuario relacionados que comezan a mostrar un anuncio, despois sucede algo, quizais unha compra e despois pode haber compras dentro dunha compra. Por exemplo, se se trata dunha aplicación móbil ou dun xogo para móbiles, normalmente a instalación da aplicación realízase de xeito gratuíto e, se se fai algo alí, é posible que se necesite diñeiro para iso. E canto máis gasta unha persoa na aplicación, máis valiosa é. Pero para iso necesitas conectar todo.

Hai moitos modelos de encadernación.

Os máis populares son:

• Última interacción, onde a interacción é un clic ou unha impresión.
• Primeira interacción, é dicir, o primeiro que trouxo unha persoa ao sitio.
• Combinación lineal - todos por igual.
• Atenuación.
• Etcétera.

E como funcionou todo en primeiro lugar? Estaban Runtime e Cassandra. Cassandra utilizouse como almacenamento de transaccións, é dicir, todas as transaccións relacionadas foron almacenadas nel. E cando se produce algún evento en Runtime, por exemplo, mostrando algunha páxina ou outra cousa, entón fíxose unha solicitude a Cassandra: existe esa persoa ou non. Despois obtivéronse as transaccións que se relacionan con el. E a conexión fíxose.

E se ten sorte que a solicitude teña un ID de transacción, é fácil. Pero normalmente non hai sorte. Polo tanto, foi necesario atopar a última transacción ou a transacción co último clic, etc.

E todo funcionou moi ben sempre que a encadernación fose ata o último clic. Porque hai, digamos, 10 millóns de clics ao día, 300 millóns ao mes, se establecemos unha xanela para un mes. E dado que en Cassandra ten que estar todo na memoria para funcionar rápido, porque o Runtime ten que responder rapidamente, necesitou uns 10-15 servidores.

E cando querían vincular unha transacción á pantalla, inmediatamente resultou que non era tan divertido. E por que? Pódese ver que hai que almacenar 30 veces máis eventos. E, en consecuencia, necesitas 30 veces máis servidores. E resulta que esta é unha especie de figura astronómica. Para manter ata 500 servidores para facer a ligazón, a pesar de que hai moito menos servidores en Runtime, esta é unha especie de cifra incorrecta. E comezaron a pensar que facer.

E fomos a ClickHouse. E como facelo en ClickHouse? A primeira vista, parece que este é un conxunto de antipatróns.

• A transacción crece, conectamos cada vez máis eventos a ela, é dicir, é mutable e ClickHouse non funciona moi ben con obxectos mutables.
• Cando un visitante chega a nós, necesitamos sacar as súas transaccións mediante a chave, coa súa identificación de visita. Esta tamén é unha consulta de puntos, non o fan en ClickHouse. Normalmente, ClickHouse ten grandes ... dixitalizacións, pero aquí necesitamos obter algúns rexistros. Tamén un antipatrón.
• Ademais, a transacción estaba en json, pero non querían reescribila, polo que querían almacenar json de forma non estruturada e, se é necesario, sacar algo del. E isto tamén é un antipatrón.

É dicir, un conxunto de antipatróns.

Pero con todo resultou facer un sistema que funcionou moi ben.

Que se fixo? Apareceu ClickHouse, no que se botaron rexistros, divididos en rexistros. Apareceu un servizo atribuído que recibiu rexistros de ClickHouse. Despois diso, para cada entrada, por identificación de visita, recibín transaccións que aínda non se procesaron e ademais de instantáneas, é dicir, transaccións xa conectadas, é dicir, o resultado do traballo anterior. Xa fixen lóxica con eles, escollín a transacción correcta, conectei novos eventos. Rexistrouse de novo. O rexistro volveu a ClickHouse, é dicir, é un sistema constantemente cíclico. E ademais fun a DWH para analizalo alí.

Foi nesta forma que non funcionou moi ben. E para facilitarlle a ClickHouse, cando había unha solicitude por ID de visita, agruparon estas solicitudes en bloques de 1-000 ID de visita e sacaron todas as transaccións para 2-000 persoas. E entón todo funcionou.

Se miras dentro de ClickHouse, só hai 3 mesas principais que serven todo isto.

A primeira táboa na que se cargan os rexistros e os rexistros cárganse case sen procesar.

Segunda mesa. A través da vista materializada, a partir destes rexistros mordéronse acontecementos que aínda non foron atribuídos, é dicir, non relacionados. E a través da vista materializada, as transaccións foron retiradas destes rexistros para crear unha instantánea. É dicir, unha vista materializada especial construíu unha instantánea, é dicir, o último estado acumulado da transacción.

Aquí está o texto escrito en SQL. Gustaríame comentar algunhas cousas importantes nel.

O primeiro importante é a capacidade de sacar columnas e campos de json en ClickHouse. É dicir, ClickHouse ten algúns métodos para traballar con json. Son moi, moi primitivos.

visitParamExtractInt permítelle extraer atributos de json, é dicir, o primeiro hit funciona. E deste xeito podes sacar o ID de transacción ou visitar o ID. Esta vez.

En segundo lugar, aquí úsase un campo materializado complicado. Qué significa? Isto significa que non pode inserilo na táboa, é dicir, non está inserido, calcúlase e gárdase ao inserilo. Ao pegar, ClickHouse fai o traballo por ti. E o que necesitas máis tarde xa está sacado de json.

Neste caso, a vista materializada é para filas en bruto. E só se usa a primeira táboa con rexistros practicamente crus. E que fai? En primeiro lugar, cambia a clasificación, é dicir, a clasificación agora vai pola ID de visita, porque necesitamos sacar rapidamente a súa transacción para unha persoa específica.

A segunda cousa importante é index_granularity. Se viches MergeTree, normalmente é 8 por defecto index_granularity. Que é? Este é o parámetro de escaseza do índice. En ClickHouse o índice é escaso, nunca indexa todas as entradas. Faino cada 192 8. E isto é bo cando se requiren moitos datos para calcular, pero malo cando son poucos, porque hai unha gran sobrecarga. E se reducimos a granularidade do índice, entón reducimos a sobrecarga. Non se pode reducir a un, porque pode que non haxa memoria suficiente. O índice sempre gárdase na memoria.

Snapshot tamén usa outras funcións interesantes de ClickHouse.

En primeiro lugar, é AggregatingMergeTree. E AggregatingMergeTree almacena argMax, é dicir, este é o estado da transacción correspondente á última marca de tempo. As transaccións xéranse todo o tempo para un determinado visitante. E no último estado desta transacción, engadimos un evento e temos un novo estado. Volveu tocar ClickHouse. E a través de argMax nesta vista materializada, sempre podemos obter o estado actual.

• A ligazón está "desacoplada" do Runtime.
• Almacenan e procesan ata 3 millóns de transaccións ao mes. Esta é unha orde de magnitude máis que en Cassandra, é dicir, nun sistema transaccional típico.
• Clúster de servidores ClickHouse 2x5. 5 servidores e cada servidor ten unha réplica. Isto é aínda menos do que era en Cassandra para facer a atribución baseada en clics, e aquí temos a impresión baseada. É dicir, en lugar de aumentar 30 veces o número de servidores, conseguiron reducilos.

E o último exemplo é a financeira Y, que analizou as correlacións das variacións dos prezos das accións.

E a tarefa foi:

• Hai aproximadamente 5 accións.
• Coñécense citas cada 100 milisegundos.
• Os datos acumuláronse ao longo de 10 anos. Ao parecer, para algunhas empresas máis, para outras menos.
• Hai aproximadamente 100 mil millóns de filas en total.

E foi necesario calcular a correlación de cambios.

Aquí tes dúas accións e as súas cotizacións. Se un sobe e o outro sobe, entón esta é unha correlación positiva, é dicir, un sobe e o outro sobe. Se un sobe, como ao final da gráfica, e o outro baixa, entón esta é unha correlación negativa, é dicir, cando un sobe, o outro baixa.

Analizando estes cambios mutuos, pódese facer predicións no mercado financeiro.

Pero a tarefa é difícil. Que se está a facer para isto? Temos 100 millóns de rexistros que teñen: tempo, stock e prezo. Necesitamos calcular primeiros 100 millóns de veces a diferenza corrente do algoritmo de prezos. RunningDifference é unha función en ClickHouse que calcula secuencialmente a diferenza entre dúas cadeas.

E despois diso, cómpre calcular a correlación e a correlación debe calcularse para cada par. Para 5 accións, os pares son 000 millóns. E isto é moito, é dicir, 12,5 veces é necesario calcular esa función de correlación.

E se alguén se esqueceu, entón ͞x e ͞y son un xaque mate. expectativa de mostraxe. É dicir, é necesario non só calcular as raíces e as sumas, senón tamén unha suma máis dentro destas sumas. Hai que facer un montón de cálculos 12,5 millóns de veces, e mesmo agrupados por horas. Tamén temos moitas horas. E tes que facelo en 60 segundos. É unha broma.

Era necesario ter tempo polo menos dalgún xeito, porque todo isto funcionaba moi, moi lentamente antes de que chegase ClickHouse.

Intentaron calculalo en Hadoop, en Spark, en Greenplum. E todo isto foi moi lento ou caro. É dicir, era posible calcular dalgún xeito, pero despois era caro.

E entón chegou ClickHouse e as cousas melloraron moito.

Lémbrovos que temos un problema coa localización dos datos, porque non se poden localizar as correlacións. Non podemos poñer algúns dos datos nun servidor, outros noutro e calcular, debemos ter todos os datos en todas partes.

Que fixeron? Inicialmente, os datos están localizados. Cada servidor almacena datos sobre o prezo dun determinado conxunto de accións. E non se solapan. Polo tanto, é posible calcular logReturn en paralelo e de forma independente, todo isto ocorre ata agora en paralelo e distribuído.

Entón decidimos reducir estes datos, sen perder expresividade. Reduce usando matrices, é dicir, para cada período de tempo, fai unha matriz de accións e unha matriz de prezos. Polo tanto, ocupa moito menos espazo de datos. E son un pouco máis fáciles de traballar. Son operacións case paralelas, é dicir, lemos parcialmente en paralelo e despois escribimos no servidor.

Despois diso, pódese replicar. A letra "r" significa que replicamos estes datos. É dicir, temos os mesmos datos nos tres servidores: estas son as matrices.

E despois, cun guión especial deste conxunto de 12,5 millóns de correlacións que hai que calcular, podes facer paquetes. É dicir, 2 tarefas con 500 pares de correlacións. E esta tarefa debe calcularse nun servidor ClickHouse específico. Ten todos os datos, porque os datos son iguais e pode calculalos secuencialmente.

Unha vez máis, isto é o que parece. En primeiro lugar, temos todos os datos nesta estrutura: tempo, accións, prezo. Despois calculamos logReturn, é dicir, datos da mesma estrutura, pero en lugar do prezo xa temos logReturn. Despois refixíronse, é dicir, obtivemos o tempo e groupArray para as existencias e os prezos. Sreplicado. E despois diso, xeramos un montón de tarefas e alimentámolas a ClickHouse para que as contase. E funciona.

En proba de concepto, a tarefa era unha subtarefa, é dicir, tomáronse menos datos. E só tres servidores.

As dúas primeiras etapas: calcular Log_return e envolver en matrices levaron aproximadamente unha hora.

E o cálculo da correlación é dunhas 50 horas. Pero 50 horas non son suficientes, porque adoitaban traballar durante semanas. Foi un gran éxito. E se contas, 70 veces por segundo todo se contou neste clúster.

Pero o máis importante é que este sistema está practicamente sen embotellamentos, é dicir, escala case linealmente. E comprobárono. Ampliouse correctamente.

• O esquema correcto é a metade da batalla. E o esquema correcto é o uso de todas as tecnoloxías ClickHouse necesarias.
• Summing/AggregatingMergeTrees son tecnoloxías que che permiten agregar ou considerar unha instantánea de estado como un caso especial. E simplifica moito moitas cousas.
• As vistas materializadas permítenche ignorar o límite dun índice. Quizais non o dixen moi claramente, pero cando cargamos os rexistros, os rexistros en bruto estaban na táboa cun índice e os rexistros de atributos estaban na táboa, é dicir, os mesmos datos, só filtrados, pero o índice estaba completamente. outros. Parece que son os mesmos datos, pero unha ordenación diferente. E Vistas materializadas permítelle, se o precisa, evitar esa limitación de ClickHouse.
• Reducir a granularidade do índice para consultas por puntos.
• E distribúe os datos de forma intelixente, tenta localizar os datos dentro do servidor o máximo posible. E tentar asegurarse de que as solicitudes tamén usen a localización na medida do posible.

E resumindo este breve discurso, podemos dicir que ClickHouse ocupou agora firmemente o territorio tanto das bases de datos comerciais como das bases de datos de código aberto, é dicir, especificamente para a analítica. Encaixa perfectamente nesta paisaxe. Ademais, pouco a pouco comeza a expulsar aos demais, porque cando tes ClickHouse, non necesitas InfiniDB. É posible que Vertika non se necesite pronto se fan soporte SQL normal. Disfruta!

-Grazas polo informe! Moi interesante! Houbo algunha comparación con Apache Phoenix?

Non, non oín comparar a ninguén. Nós e Yandex tratamos de facer un seguimento de todas as comparacións de ClickHouse con diferentes bases de datos. Porque se de súpeto algo resulta máis rápido que ClickHouse, Lesha Milovidov non pode durmir pola noite e comeza a aceleralo rapidamente. Non oín falar de tal comparación.

• (Aleksey Milovidov) Apache Phoenix é un motor SQL impulsado por Hbase. Hbase é principalmente para o escenario de traballo de clave-valor. Alí, en cada liña, pode haber un número arbitrario de columnas con nomes arbitrarios. Isto pódese dicir sobre sistemas como Hbase, Cassandra. E son precisamente as consultas analíticas pesadas as que non funcionarán normalmente para elas. Ou pode pensar que funcionan ben se non tivo experiencia con ClickHouse.

• Grazas

  • Boas tardes Xa estou bastante interesado neste tema, porque teño un subsistema analítico. Pero cando miro ClickHouse, teño a sensación de que ClickHouse é moi axeitado para a análise de eventos, mutable. E se teño que analizar moitos datos empresariais cunha morea de táboas grandes, entón ClickHouse, polo que entendo, non é moi axeitado para min? Sobre todo se cambian. É correcto ou hai exemplos que poidan refutar isto?

  • Isto é certo. E isto é certo da maioría das bases de datos analíticas especializadas. Están adaptados ao feito de que hai unha ou máis mesas grandes que son mutables, e para moitas pequenas que cambian lentamente. É dicir, ClickHouse non é como Oracle, onde podes poñer todo e construír consultas moi complexas. Para poder usar ClickHouse de forma eficaz, debes crear un esquema que funcione ben en ClickHouse. É dicir, evitar unha normalización excesiva, utilizar dicionarios, tentar facer menos ligazóns longas. E se o esquema se constrúe deste xeito, as tarefas comerciais similares pódense resolver en ClickHouse de forma moito máis eficiente que nunha base de datos relacional tradicional.

Grazas polo informe! Teño unha pregunta sobre o último caso financeiro. Tiñan analíticas. Había que comparar como suben e baixan. E entendo que construíu o sistema específicamente para esta análise? Se mañá, por exemplo, necesitan algún outro informe sobre estes datos, teñen que reconstruír o esquema e cargar os datos? É dicir, facer algún tipo de preprocesamento para obter a solicitude?

Por suposto, este é o uso de ClickHouse para unha tarefa moi específica. Podería resolverse máis tradicionalmente dentro de Hadoop. Para Hadoop, esta é unha tarefa ideal. Pero en Hadoop é moi lento. E o meu obxectivo é demostrar que ClickHouse pode resolver tarefas que adoitan resolverse por medios completamente diferentes, pero ao mesmo tempo facelo de forma moito máis eficiente. Está adaptado a unha tarefa específica. Está claro que se hai un problema con algo semellante, entón pódese resolver dun xeito similar.

Está claro. Vostede dixo que se tramitaron 50 horas. É dende o principio, cando cargaches os datos ou obtiveches os resultados?

Si, si.

OK moitas grazas.

Isto está nun clúster de 3 servidores.

Saúdos! Grazas polo informe! Todo é moi interesante. Non vou preguntar un pouco sobre a funcionalidade, senón sobre o uso de ClickHouse en termos de estabilidade. É dicir, tiñas algunha, tiñas que restaurala? Como se comporta ClickHouse neste caso? E ocorreu que tamén tiñas unha réplica? Por exemplo, atopamos un problema con ClickHouse cando aínda sae do seu límite e cae.

Por suposto, non hai sistemas ideais. E ClickHouse tamén ten os seus propios problemas. Pero xa escoitaches falar de Yandex.Metrica que non funciona durante moito tempo? Probablemente non. Funciona de forma fiable desde 2012-2013 en ClickHouse. Podo dicir o mesmo da miña experiencia. Nunca tivemos fracasos completos. Algunhas cousas parciais poderían ocorrer, pero nunca foron o suficientemente importantes como para afectar seriamente o negocio. Nunca pasou. ClickHouse é bastante fiable e non falla ao azar. Non tes que preocuparte por iso. Non é unha cousa bruta. Isto foi demostrado por moitas empresas.

Ola! Dixeches que tes que pensar no esquema de datos de inmediato. E se pasase? Os meus datos están a verter e verter. Pasan seis meses, e entendo que é imposible vivir así, teño que volver cargar os datos e facer algo con eles.

Isto depende, por suposto, do teu sistema. Hai varias formas de facelo sen parar practicamente. Por exemplo, pode crear unha vista materializada na que crear unha estrutura de datos diferente se se pode mapear de forma única. É dicir, se permite mapear usando ClickHouse, é dicir, extraer algunhas cousas, cambiar a chave primaria, cambiar a partición, entón podes facer unha Vista materializada. Sobreescribe alí os teus datos antigos, os novos escribiranse automaticamente. E despois simplemente cambia a usar a Vista materializada, despois cambia o rexistro e elimina a táboa antiga. Este é xeralmente un método sen parar.

Grazas.

Fonte: www.habr.com