Teoria e prática do uso do ClickHouse em aplicações reais. Alexandre Zaitsev (2018)

Apesar do fato de que agora existem muitos dados em quase todos os lugares, os bancos de dados analíticos ainda são bastante exóticos. Eles são pouco conhecidos e ainda pior capazes de usá-los de forma eficaz. Muitos continuam a "comer cacto" com MySQL ou PostgreSQL, que são projetados para outros cenários, sofrem com NoSQL ou pagam demais por soluções comerciais. ClickHouse muda as regras do jogo e reduz significativamente o limiar para entrar no mundo do DBMS analítico.

Relatório da BackEnd Conf 2018 e é publicado com a permissão do palestrante.

Quem sou eu e por que estou falando da ClickHouse? Sou diretor de desenvolvimento da LifeStreet, que usa o ClickHouse. Além disso, sou o fundador da Altinity. É um parceiro Yandex que promove o ClickHouse e ajuda o Yandex a tornar o ClickHouse mais bem-sucedido. Também pronto para compartilhar conhecimento sobre ClickHouse.

E eu não sou irmão de Petya Zaitsev. Muitas vezes me perguntam sobre isso. Não, não somos irmãos.

“Todo mundo sabe” que ClickHouse:

• Muito rápido,
• Muito confortável
• Usado em Yandex.

Um pouco menos se sabe em quais empresas e como é usado.

Vou lhe dizer por que, onde e como o ClickHouse é usado, exceto Yandex.

Vou contar como tarefas específicas são resolvidas com a ajuda do ClickHouse em diferentes empresas, quais ferramentas ClickHouse você pode usar para suas tarefas e como elas foram usadas em diferentes empresas.

Peguei três exemplos que mostram o ClickHouse de diferentes ângulos. Acho que será interessante.

A primeira pergunta é: “Por que precisamos da ClickHouse?”. Parece ser uma pergunta bastante óbvia, mas há mais de uma resposta para ela.

• A primeira resposta é para desempenho. ClickHouse é muito rápido. O Analytics no ClickHouse também é muito rápido. Muitas vezes, pode ser usado onde algo está muito lento ou muito ruim.
• A segunda resposta é custo. E, antes de tudo, o custo de dimensionamento. Por exemplo, Vertica é um banco de dados absolutamente excelente. Funciona muito bem se você não tiver muitos terabytes de dados. Mas quando se trata de centenas de terabytes ou petabytes, o custo de uma licença e suporte chega a um valor bastante significativo. E é caro. E o ClickHouse é gratuito.
• A terceira resposta é o custo operacional. Esta é uma abordagem ligeiramente diferente. RedShift é um ótimo analógico. No RedShift, você pode tomar uma decisão muito rapidamente. Vai funcionar bem, mas ao mesmo tempo, a cada hora, todos os dias e todos os meses, você pagará muito caro à Amazon, porque este é um serviço significativamente caro. Google BigQuery também. Se alguém usou, sabe que lá você pode fazer vários pedidos e receber uma fatura de centenas de dólares de repente.

ClickHouse não tem esses problemas.

Onde o ClickHouse é usado agora? Além do Yandex, o ClickHouse é usado em vários negócios e empresas diferentes.

• Em primeiro lugar, esta é a análise de aplicativos da web, ou seja, este é um caso de uso que veio do Yandex.
• Muitas empresas de AdTech usam o ClickHouse.
• Inúmeras empresas que precisam analisar logs de transações de diferentes fontes.
• Várias empresas usam ClickHouse para monitorar logs de segurança. Eles os carregam no ClickHouse, fazem relatórios e obtêm os resultados de que precisam.
• As empresas estão começando a utilizá-lo na análise financeira, ou seja, gradativamente grandes empresas também estão se aproximando do ClickHouse.
• cloudflare. Se alguém segue a ClickHouse, provavelmente já ouviu falar do nome dessa empresa. Este é um dos colaboradores essenciais da comunidade. E eles têm uma instalação ClickHouse muito séria. Por exemplo, eles criaram o Kafka Engine para ClickHouse.
• As empresas de telecomunicações começaram a usar. Várias empresas usam o ClickHouse como prova de conceito ou já em produção.
• Uma empresa usa o ClickHouse para monitorar os processos de produção. Eles testam microcircuitos, eliminam vários parâmetros, são cerca de 2 características. E depois analisam se o jogo é bom ou ruim.
• Análise de blockchain. Existe uma empresa russa como Bloxy.info. Esta é uma análise da rede ethereum. Eles também fizeram isso no ClickHouse.

E o tamanho não importa. Existem muitas empresas que usam um pequeno servidor. E ele permite que eles resolvam seus problemas. E ainda mais empresas usam grandes clusters de muitos servidores ou dezenas de servidores.

E se você olhar para os registros, então:

• Yandex: mais de 500 servidores, eles armazenam 25 bilhões de registros por dia lá.
• LifeStreet: 60 servidores, aproximadamente 75 bilhões de registros por dia. Existem menos servidores, mais registros do que no Yandex.
• CloudFlare: 36 servidores, eles salvam 200 bilhões de registros por dia. Eles têm ainda menos servidores e armazenam ainda mais dados.
• Bloomberg: 102 servidores, cerca de um trilhão de entradas por dia. Recordista.

Geograficamente, isso também é muito. Este mapa aqui mostra um mapa de calor de onde o ClickHouse está sendo usado no mundo. Rússia, China, América se destacam claramente aqui. Existem poucos países europeus. E há 4 clusters.

Esta é uma análise comparativa, não há necessidade de buscar números absolutos. Esta é uma análise dos visitantes que lêem materiais em inglês no site da Altinity, porque não há nenhum de língua russa lá. E Rússia, Ucrânia, Bielo-Rússia, ou seja, a parte da comunidade que fala russo, são os usuários mais numerosos. Depois vêm os EUA e o Canadá. A China está se recuperando muito. Quase não havia China lá seis meses atrás, agora a China já ultrapassou a Europa e continua crescendo. A velha Europa também não fica muito atrás, e o líder no uso do ClickHouse é, curiosamente, a França.

Por que estou contando tudo isso? Para mostrar que o ClickHouse está se tornando uma solução padrão para análise de big data e já é usado em muitos lugares. Se você usá-lo, você está na tendência certa. Se você ainda não está usando, não pode ter medo de ficar sozinho e ninguém vai te ajudar, porque muitos já estão fazendo isso.

Estes são exemplos de uso real do ClickHouse em diversas empresas.

• O primeiro exemplo é uma rede de anúncios: migração de Vertica para ClickHouse. E conheço algumas empresas que fizeram a transição da Vertica ou estão em processo de transição.
• O segundo exemplo é o armazenamento transacional no ClickHouse. Este é um exemplo construído sobre antipadrões. Tudo o que não deve ser feito no ClickHouse por conselho dos desenvolvedores é feito aqui. E é feito de forma tão eficaz que funciona. E funciona muito melhor do que a solução transacional típica.
• O terceiro exemplo é a computação distribuída no ClickHouse. Houve uma pergunta sobre como o ClickHouse pode ser integrado ao ecossistema Hadoop. Mostrarei um exemplo de como uma empresa fez algo semelhante a um contêiner de redução de mapa no ClickHouse, acompanhando a localização de dados etc., para calcular uma tarefa nada trivial.

• A LifeStreet é uma empresa Ad Tech que possui toda a tecnologia que acompanha uma rede de anúncios.
• Ela está envolvida em otimização de anúncios e lances programáticos.
• Muitos dados: cerca de 10 bilhões de eventos por dia. Ao mesmo tempo, os eventos podem ser divididos em vários subeventos.
• Existem muitos clientes desses dados, e não são apenas pessoas, muito mais - são vários algoritmos envolvidos em lances programáticos.

A empresa percorreu um caminho longo e espinhoso. E falei sobre isso no HighLoad. Primeiro, a LifeStreet mudou do MySQL (com uma breve parada na Oracle) para a Vertica. E você pode encontrar uma história sobre isso.

E tudo foi muito bom, mas rapidamente ficou claro que os dados estão crescendo e o Vertica é caro. Portanto, várias alternativas foram buscadas. Alguns deles estão listados aqui. E, de fato, fizemos provas de conceito ou, às vezes, testes de desempenho de quase todos os bancos de dados disponíveis no mercado do 13º ao 16º ano e eram aproximadamente adequados em termos de funcionalidade. E também falei sobre alguns deles no HighLoad.

A tarefa era migrar do Vertica em primeiro lugar, porque os dados cresceram. E eles cresceram exponencialmente ao longo dos anos. Então eles foram para a prateleira, mas mesmo assim. E prevendo esse crescimento, os requisitos de negócios para a quantidade de dados nos quais algum tipo de análise precisava ser feito, ficou claro que os petabytes logo seriam discutidos. E pagar por petabytes já é muito caro, então estávamos procurando uma alternativa para onde ir.

Onde ir? E por muito tempo não ficou claro para onde ir, porque por um lado existem bancos de dados comerciais, parecem funcionar bem. Alguns funcionam quase tão bem quanto o Vertica, outros piores. Mas são todos caros, não foi possível encontrar nada mais barato e melhor.

Por outro lado, existem soluções de código aberto, que não são muito numerosas, ou seja, para análises, podem ser contadas nos dedos. E eles são gratuitos ou baratos, mas lentos. E muitas vezes carecem da funcionalidade necessária e útil.

E não havia nada que combinasse o bom que há nos bancos de dados comerciais e tudo o que há de gratuito no código aberto.

Não havia nada até que, inesperadamente, Yandex tirou ClickHouse, como um mágico de um chapéu, como um coelho. E foi uma decisão inesperada, eles ainda fazem a pergunta: “Por quê?”, Mas mesmo assim.

E logo no verão de 2016, começamos a ver o que é ClickHouse. E descobriu-se que às vezes pode ser mais rápido que o Vertica. Testamos diferentes cenários em diferentes consultas. E se a consulta usasse apenas uma tabela, ou seja, sem nenhum join (join), então o ClickHouse era duas vezes mais rápido que o Vertica.

Eu não estava com preguiça e olhei para os testes do Yandex outro dia. É a mesma coisa lá: o ClickHouse é duas vezes mais rápido que o Vertica, então eles costumam falar sobre isso.

Mas se houver junções nas consultas, tudo não será muito inequívoco. E o ClickHouse pode ser duas vezes mais lento que o Vertica. E se você corrigir ligeiramente a solicitação e reescrevê-la, eles serão aproximadamente iguais. Nada mal. E livre.

E tendo recebido os resultados do teste e olhando de diferentes ângulos, LifeStreet foi para ClickHouse.

Este é o 16º ano, eu te lembro. Era como uma piada sobre ratos que choravam e se picavam, mas continuavam a comer o cacto. E isso foi descrito em detalhes, há um vídeo sobre isso, etc.

Portanto, não vou falar sobre isso em detalhes, vou falar apenas sobre os resultados e algumas coisas interessantes que não falei na época.

Os resultados são:

• Migração bem sucedida e a mais de um ano o sistema já está funcionando em produção.
• A produtividade e a flexibilidade aumentaram. Dos 10 bilhões de registros que poderíamos armazenar por dia e depois por um curto período de tempo, o LifeStreet agora armazena 75 bilhões de registros por dia e pode fazer isso por 3 meses ou mais. Se você contar no pico, isso representa até um milhão de eventos por segundo. Mais de um milhão de consultas SQL por dia chegam a esse sistema, principalmente de diferentes robôs.
• Apesar do fato de que mais servidores foram usados ​​\uXNUMXb\uXNUMXbpara o ClickHouse do que para o Vertica, eles também economizaram em hardware, porque discos SAS bastante caros foram usados ​​​​no Vertica. ClickHouse usado SATA. E porque? Porque no Vertica o insert é síncrono. E a sincronização exige que os discos não fiquem muito lentos e também que a rede não fique muito lenta, ou seja, uma operação bastante cara. E no ClickHouse a inserção é assíncrona. Além disso, você sempre pode escrever tudo localmente, não há custos adicionais para isso, então os dados podem ser inseridos no ClickHouse muito mais rápido do que no Vertika, mesmo em unidades mais lentas. E a leitura é quase a mesma. Lendo em SATA, se eles estiverem em RAID, tudo isso é rápido o suficiente.
• Não limitado por licença, ou seja, 3 petabytes de dados em 60 servidores (20 servidores é uma réplica) e 6 trilhões de registros em fatos e agregações. Nada como isso poderia ser oferecido na Vertica.

Eu agora volto para coisas práticas neste exemplo.

• O primeiro é um esquema eficiente. Depende muito do esquema.
• A segunda é a geração eficiente de SQL.

Uma consulta OLAP típica é uma seleção. Algumas das colunas vão para agrupar por, algumas das colunas vão para agregar funções. Há onde, que pode ser representado como uma fatia de um cubo. Todo o grupo pode ser pensado como uma projeção. E é por isso que se chama análise de dados multivariada.

E muitas vezes isso é modelado na forma de um esquema de estrela, quando há um fato central e características desse fato ao longo dos lados, ao longo dos raios.

E em termos de design físico, como cabe na mesa, eles costumam fazer uma representação normalizada. Você pode desnormalizar, mas é caro no disco e não é muito eficiente nas consultas. Portanto, eles geralmente fazem uma representação normalizada, ou seja, uma tabela de fatos e muitas, muitas tabelas de dimensões.

Mas não funciona bem no ClickHouse. Existem dois motivos:

• A primeira é porque o ClickHouse não tem joins muito bons, ou seja, tem joins, mas são ruins. Enquanto ruim.
• A segunda é que as tabelas não são atualizadas. Normalmente nessas placas, que ficam ao redor do circuito-estrela, algo precisa ser mudado. Por exemplo, nome do cliente, nome da empresa, etc. E não funciona.

E há uma saída para isso no ClickHouse. até dois:

• A primeira é o uso de dicionários. Dicionários externos é o que ajuda 99% a resolver o problema com o esquema em estrela, com atualizações e assim por diante.
• A segunda é o uso de matrizes. Arrays também ajudam a eliminar junções e problemas de normalização.

• Não é necessário ingressar.
• Atualizável. Desde março de 2018, surgiu uma oportunidade não documentada (você não a encontrará na documentação) para atualizar parcialmente os dicionários, ou seja, as entradas que foram alteradas. Na prática, é como uma mesa.
• Sempre na memória, então junções com um dicionário funcionam mais rápido do que se fosse uma tabela que está no disco e ainda não é fato que está no cache, muito provavelmente não.

• Você também não precisa de junções.
• Esta é uma representação compacta de 1 para muitos.
• E, na minha opinião, arrays são feitos para geeks. Estas são funções lambda e assim por diante.

Isto não é para palavras vermelhas. Esta é uma funcionalidade muito poderosa que permite fazer muitas coisas de uma forma muito simples e elegante.

Exemplos típicos que ajudam a resolver matrizes. Esses exemplos são simples e claros o suficiente:

• Pesquise por etiquetas. Se você tiver hashtags lá e quiser encontrar alguns posts por hashtag.
• Pesquise por pares chave-valor. Existem também alguns atributos com um valor.
• Armazenar listas de chaves que você precisa traduzir em outra coisa.

Todas essas tarefas podem ser resolvidas sem matrizes. As tags podem ser colocadas em alguma linha e selecionadas com uma expressão regular ou em uma tabela separada, mas aí você tem que fazer junções.

E no ClickHouse você não precisa fazer nada, basta descrever o array de strings para hashtags ou fazer uma estrutura aninhada para sistemas chave-valor.

Estrutura aninhada pode não ser o melhor nome. São dois arrays que possuem uma parte comum no nome e algumas características relacionadas.

E é muito fácil pesquisar por tag. tem uma função has, que verifica se a matriz contém um elemento. Todos, encontraram todas as entradas relacionadas à nossa conferência.

A pesquisa por subid é um pouco mais complicada. Precisamos primeiro encontrar o índice da chave e, em seguida, pegar o elemento com esse índice e verificar se esse valor é o que precisamos. No entanto, é muito simples e compacto.

A expressão regular que você gostaria de escrever se mantivesse tudo em uma linha, seria, em primeiro lugar, desajeitada. E, em segundo lugar, funcionou por muito mais tempo do que duas matrizes.

Outro exemplo. Você tem uma matriz onde armazena o ID. E você pode traduzi-los em nomes. Função arrayMap. Esta é uma função lambda típica. Você passa expressões lambda lá. E ela extrai o valor do nome para cada ID do dicionário.

A pesquisa pode ser feita da mesma maneira. É passada uma função de predicado que verifica a correspondência dos elementos.

Essas coisas simplificam muito o circuito e resolvem vários problemas.

Mas o próximo problema que estamos enfrentando e que gostaria de mencionar são as consultas eficientes.

• ClickHouse não possui um planejador de consulta. Absolutamente não.
• No entanto, consultas complexas ainda precisam ser planejadas. Em quais casos?
• Se houver várias junções na consulta, você as agrupará em subseleções. E a ordem em que são executadas é importante.
• E o segundo - se o pedido for distribuído. Porque em uma consulta distribuída, apenas a subseleção mais interna é executada distribuída e todo o resto é passado para um servidor ao qual você se conectou e executou lá. Portanto, se você distribuiu consultas com muitos joins (join), então você precisa escolher a ordem.

E mesmo em casos mais simples, às vezes também é necessário fazer o trabalho do agendador e reescrever um pouco as consultas.

Aqui está um exemplo. No lado esquerdo há uma consulta que mostra os 5 principais países. E leva 2,5 segundos, na minha opinião. E no lado direito, a mesma consulta, mas ligeiramente reescrita. Em vez de agrupar por string, passamos a agrupar por chave (int). E é mais rápido. E então conectamos um dicionário ao resultado. Em vez de 2,5 segundos, a solicitação leva 1,5 segundos. Isso é bom.

Um exemplo semelhante com filtros de reescrita. Aqui está um pedido para a Rússia. Funciona por 5 segundos. Se reescrevermos de forma que comparemos novamente não uma string, mas números com algum conjunto dessas chaves relacionadas à Rússia, será muito mais rápido.

Existem muitos desses truques. E eles permitem que você acelere significativamente as consultas que você acha que já estão sendo executadas rapidamente ou, inversamente, estão sendo executadas lentamente. Eles podem ser feitos ainda mais rápido.

• Trabalho máximo em modo distribuído.
• Classificando por tipos mínimos, como fiz por ints.
• Se houver junções (join), dicionários, é melhor fazê-los como último recurso, quando você já tiver dados pelo menos parcialmente agrupados, a operação de junção ou chamada de dicionário será chamada menos vezes e será mais rápida .
• Substituindo filtros.

Existem outras técnicas, e não apenas as que demonstrei. E todos eles às vezes podem acelerar significativamente a execução de consultas.

Vamos para o próximo exemplo. Empresa X dos EUA. O que ela esta fazendo?

Havia uma tarefa:

• Vinculação off-line de transações publicitárias.
• Modelagem de diferentes modelos de encadernação.

Qual é o cenário?

Um visitante comum acessa o site, por exemplo, 20 vezes por mês a partir de anúncios diferentes, ou assim às vezes vem sem nenhum anúncio, porque se lembra deste site. Olha alguns produtos, coloca na cesta, tira da cesta. E, no final, algo compra.

Perguntas razoáveis: "Quem deve pagar pela publicidade, se necessário?" e “Que publicidade o influenciou, se houve?”. Ou seja, por que ele comprou e como fazer com que pessoas como essa pessoa também comprem?

Para resolver esse problema, você precisa conectar os eventos que ocorrem no site da maneira certa, ou seja, de alguma forma criar uma conexão entre eles. Em seguida, são enviados para análise ao DWH. E, com base nessa análise, crie modelos de quem e quais anúncios exibir.

Uma transação de anúncio é um conjunto de eventos de usuário relacionados que começam com a exibição de um anúncio, então algo acontece, então talvez uma compra, e então pode haver compras dentro de uma compra. Por exemplo, se este é um aplicativo móvel ou um jogo para celular, geralmente a instalação do aplicativo ocorre gratuitamente e, se algo for feito lá, pode ser necessário dinheiro para isso. E quanto mais uma pessoa gasta no aplicativo, mais valioso ele é. Mas para isso você precisa conectar tudo.

Existem muitos modelos de encadernação.

Os mais populares são:

• Última interação, em que a interação é um clique ou uma impressão.
• Primeira interação, ou seja, a primeira coisa que trouxe uma pessoa ao site.
• Combinação linear - tudo igualmente.
• Atenuação.
• Etc.

E como tudo funcionou em primeiro lugar? Havia Runtime e Cassandra. O Cassandra foi usado como armazenamento de transações, ou seja, todas as transações relacionadas foram armazenadas nele. E quando algum evento ocorre em tempo de execução, por exemplo, mostrando alguma página ou outra coisa, uma solicitação foi feita a Cassandra - existe essa pessoa ou não. Em seguida, foram obtidas as transações que se relacionam a ele. E a ligação foi feita.

E se for sorte que a solicitação tenha um ID de transação, é fácil. Mas geralmente sem sorte. Portanto, era necessário encontrar a última transação ou a transação com o último clique, etc.

E tudo funcionou muito bem desde que a ligação fosse até o último clique. Porque há, digamos, 10 milhões de cliques por dia, 300 milhões por mês, se definirmos uma janela para um mês. E como no Cassandra tem que estar tudo na memória para rodar rápido, porque o Runtime precisa responder rápido, demorou cerca de 10 a 15 servidores.

E quando eles queriam vincular uma transação ao visor, imediatamente não era tão divertido. E porque? Pode-se observar que 30 vezes mais eventos precisam ser armazenados. E, portanto, você precisa de 30 vezes mais servidores. E acontece que esta é uma espécie de figura astronômica. Manter até 500 servidores para fazer a vinculação, apesar do fato de haver significativamente menos servidores em tempo de execução, isso é algum tipo de figura errada. E eles começaram a pensar no que fazer.

E fomos à ClickHouse. E como fazer isso no ClickHouse? À primeira vista, parece que se trata de um conjunto de antipadrões.

• A transação cresce, conectamos mais e mais eventos a ela, ou seja, é mutável e o ClickHouse não funciona muito bem com objetos mutáveis.
• Quando um visitante vem até nós, precisamos extrair suas transações por chave, por seu ID de visita. Esta também é uma consulta pontual, eles não fazem isso no ClickHouse. Normalmente, o ClickHouse tem grandes … varreduras, mas aqui precisamos obter alguns registros. Também um antipadrão.
• Além disso, a transação estava em json, mas eles não queriam reescrevê-la, então queriam armazenar o json de forma não estruturada e, se necessário, extrair algo dele. E isso também é um antipadrão.

Ou seja, um conjunto de antipadrões.

Mesmo assim, acabou criando um sistema que funcionou muito bem.

O que foi feito? Apareceu o ClickHouse, no qual os logs foram lançados, divididos em registros. Apareceu um serviço atribuído que recebeu logs do ClickHouse. Depois disso, para cada entrada, por id de visita, recebi transações que ainda não foram processadas e mais instantâneos, ou seja, transações já conectadas, ou seja, o resultado do trabalho anterior. Já fiz lógica com eles, escolhi a transação correta, conectei novos eventos. Registrado novamente. O log voltou para ClickHouse, ou seja, é um sistema constantemente cíclico. E além disso, fui ao DWH para analisar lá.

Foi dessa forma que não funcionou muito bem. E para facilitar para a ClickHouse, quando havia uma solicitação por ID de visita, eles agrupavam essas solicitações em blocos de 1 a 000 IDs de visita e retiravam todas as transações de 2 a 000 pessoas. E então tudo funcionou.

Se você olhar dentro do ClickHouse, existem apenas 3 mesas principais que atendem a tudo isso.

A primeira tabela na qual os logs são carregados e os logs são carregados quase sem processamento.

Segunda mesa. Através da visão materializada, desses logs, foram mordidos os eventos que ainda não foram atribuídos, ou seja, não relacionados. E por meio da visualização materializada, as transações foram extraídas desses logs para criar um instantâneo. Ou seja, uma visão materializada especial construiu um instantâneo, ou seja, o último estado acumulado da transação.

Aqui está o texto escrito em SQL. Gostaria de comentar algumas coisas importantes nele.

A primeira coisa importante é a capacidade de extrair colunas e campos do json no ClickHouse. Ou seja, o ClickHouse possui alguns métodos para trabalhar com json. Eles são muito, muito primitivos.

visitParamExtractInt permite extrair atributos do json, ou seja, o primeiro hit funciona. E desta forma você pode retirar o id da transação ou o id da visita. Desta vez.

Em segundo lugar, um campo materializado complicado é usado aqui. O que isso significa? Isso significa que você não pode inseri-lo na tabela, ou seja, não é inserido, é calculado e armazenado no momento da inserção. Ao colar, ClickHouse faz o trabalho para você. E o que você precisa depois já foi retirado do json.

Nesse caso, a visualização materializada é para linhas brutas. E a primeira tabela com toras praticamente cruas é apenas usada. E o que ele faz? Em primeiro lugar, ele altera a classificação, ou seja, a classificação agora passa pelo ID da visita, porque precisamos retirar rapidamente a transação dele para uma pessoa específica.

A segunda coisa importante é index_granularity. Se você viu MergeTree, geralmente é 8 por padrão index_granularity. O que é isso? Este é o parâmetro de dispersão do índice. No ClickHouse, o índice é esparso, ele nunca indexa todas as entradas. Ele faz isso a cada 192. E isso é bom quando muitos dados precisam ser calculados, mas ruim quando poucos, porque há uma grande sobrecarga. E se reduzirmos a granularidade do índice, reduziremos a sobrecarga. Não pode ser reduzido a um, porque pode não haver memória suficiente. O índice é sempre armazenado na memória.

O Snapshot também usa alguns outros recursos interessantes do ClickHouse.

Primeiro, é AggregatingMergeTree. E AggregatingMergeTree armazena argMax, ou seja, este é o estado da transação correspondente ao último timestamp. As transações são geradas o tempo todo para um determinado visitante. E no último estado desta transação, adicionamos um evento e temos um novo estado. Ele atingiu ClickHouse novamente. E por meio de argMax nessa visão materializada, sempre podemos obter o estado atual.

• A ligação é "desacoplada" do Runtime.
• Até 3 bilhões de transações por mês são armazenadas e processadas. Isso é uma ordem de grandeza maior do que em Cassandra, ou seja, em um sistema transacional típico.
• Cluster de servidores ClickHouse 2x5. 5 servidores e cada servidor possui uma réplica. Isso é ainda menor do que no Cassandra para fazer a atribuição baseada em cliques, e aqui temos a atribuição baseada em impressões. Ou seja, ao invés de aumentar em 30 vezes o número de servidores, conseguiram reduzi-los.

E o último exemplo é a empresa financeira Y, que analisou as correlações das mudanças nos preços das ações.

E a tarefa era:

• São aproximadamente 5 ações.
• Cotações a cada 100 milissegundos são conhecidas.
• Os dados foram acumulados ao longo de 10 anos. Aparentemente, para algumas empresas mais, para outras menos.
• Existem aproximadamente 100 bilhões de linhas no total.

E foi necessário calcular a correlação das mudanças.

Aqui estão duas ações e suas cotações. Se um sobe e o outro sobe, então esta é uma correlação positiva, ou seja, um sobe e o outro sobe. Se um sobe, como no final do gráfico, e o outro desce, então esta é uma correlação negativa, ou seja, quando um sobe, o outro cai.

Analisando essas mudanças mútuas, pode-se fazer previsões no mercado financeiro.

Mas a tarefa é difícil. O que está sendo feito para isso? Temos 100 bilhões de registros que possuem: tempo, estoque e preço. Precisamos calcular primeiro 100 bilhões de vezes a diferença em execução do algoritmo de preço. RunningDifference é uma função no ClickHouse que calcula sequencialmente a diferença entre duas strings.

E depois disso, você precisa calcular a correlação, e a correlação deve ser calculada para cada par. Para 5 ações, os pares são 000 milhões. E isso é muito, ou seja, 12,5 vezes é necessário calcular exatamente essa função de correlação.

E se alguém esqueceu, então ͞x e ͞y é um xeque-mate. expectativa de amostragem. Ou seja, é preciso não só calcular as raízes e somas, mas também mais uma soma dentro dessas somas. Vários cálculos precisam ser feitos 12,5 milhões de vezes e até agrupados por horas. Também temos muitas horas. E você tem que fazer isso em 60 segundos. É uma piada.

Era preciso ter tempo pelo menos de alguma forma, porque tudo isso funcionava muito, muito devagar antes da chegada do ClickHouse.

Eles tentaram calculá-lo no Hadoop, no Spark, no Greenplum. E tudo isso era muito lento ou caro. Ou seja, dava para calcular de alguma forma, mas aí era caro.

E então o ClickHouse apareceu e as coisas ficaram muito melhores.

Lembro que temos um problema com a localidade dos dados, porque as correlações não podem ser localizadas. Não podemos colocar alguns dados em um servidor, alguns em outro e calcular, devemos ter todos os dados em todos os lugares.

O que eles fizeram? Inicialmente, os dados são localizados. Cada servidor armazena dados sobre o preço de um determinado conjunto de ações. E eles não se sobrepõem. Portanto, é possível calcular logReturn em paralelo e de forma independente, tudo isso até agora em paralelo e distribuído.

Então decidimos reduzir esses dados, sem perder a expressividade. Reduza usando matrizes, ou seja, para cada período de tempo, faça uma matriz de estoques e uma matriz de preços. Portanto, ocupa muito menos espaço de dados. E eles são um pouco mais fáceis de trabalhar. Essas são operações quase paralelas, ou seja, lemos parcialmente em paralelo e depois gravamos no servidor.

Depois disso, pode ser replicado. A letra "r" significa que replicamos esses dados. Ou seja, temos os mesmos dados nos três servidores - esses são os arrays.

E então, com um script especial desse conjunto de 12,5 milhões de correlações que precisam ser calculadas, você pode criar pacotes. Ou seja, 2 tarefas com 500 pares de correlações. E esta tarefa deve ser calculada em um servidor ClickHouse específico. Ele tem todos os dados, porque os dados são os mesmos e ele pode calculá-los sequencialmente.

Mais uma vez, é assim que parece. Primeiro, temos todos os dados dessa estrutura: tempo, ações, preço. Em seguida, calculamos logReturn, ou seja, dados da mesma estrutura, mas em vez do preço já temos logReturn. Em seguida, eles foram refeitos, ou seja, obtivemos o time e o groupArray para ações e preços. Replicado. E depois disso, geramos um monte de tarefas e as alimentamos no ClickHouse para que ele as contasse. E funciona.

Na prova de conceito, a tarefa era uma subtarefa, ou seja, menos dados foram obtidos. E apenas três servidores.

Esses dois primeiros estágios: calcular Log_return e agrupar em arrays levaram cerca de uma hora.

E o cálculo da correlação é de cerca de 50 horas. Mas 50 horas não são suficientes, porque costumavam trabalhar por semanas. Foi um grande sucesso. E se você contar, então 70 vezes por segundo tudo foi contado neste cluster.

Mas o mais importante é que esse sistema praticamente não tem gargalos, ou seja, escala de forma quase linear. E eles verificaram. Ampliado com sucesso.

• O esquema certo é metade da batalha. E o esquema certo é o uso de todas as tecnologias ClickHouse necessárias.
• Summing/AggregatingMergeTrees são tecnologias que permitem agregar ou considerar um instantâneo de estado como um caso especial. E simplifica muito muitas coisas.
• Visualizações materializadas permitem ignorar o limite de um índice. Talvez eu não tenha dito muito claramente, mas quando carregamos os logs, os logs brutos estavam na tabela com um índice e os logs de atributos estavam na tabela, ou seja, os mesmos dados, apenas filtrados, mas o índice foi completamente outros. Parece ser os mesmos dados, mas classificação diferente. E as visualizações materializadas permitem, se necessário, contornar essa limitação do ClickHouse.
• Reduza a granularidade do índice para consultas pontuais.
• E distribua os dados de maneira inteligente, tente localizar os dados dentro do servidor o máximo possível. E tente garantir que as solicitações também usem a localização sempre que possível.

E resumindo este breve discurso, podemos dizer que a ClickHouse já ocupou firmemente o território tanto das bases de dados comerciais quanto das bases de dados de código aberto, ou seja, especificamente para análises. Ele se encaixa perfeitamente nessa paisagem. E mais, lentamente começa a afastar os outros, porque quando você tem o ClickHouse, não precisa do InfiniDB. O Vertika pode não ser necessário em breve se eles fizerem suporte SQL normal. Aproveitar!

-Obrigado pelo relatório! Muito interessante! Houve alguma comparação com o Apache Phoenix?

Não, eu não ouvi ninguém comparar. Nós e o Yandex tentamos acompanhar todas as comparações do ClickHouse com diferentes bancos de dados. Porque se de repente algo se tornar mais rápido que o ClickHouse, Lesha Milovidov não consegue dormir à noite e começa a acelerá-lo rapidamente. Eu não ouvi falar de tal comparação.

• (Aleksey Milovidov) Apache Phoenix é um mecanismo SQL alimentado por Hbase. Hbase é principalmente para cenário de trabalho de chave-valor. Lá, em cada linha, pode haver um número arbitrário de colunas com nomes arbitrários. Isso pode ser dito sobre sistemas como Hbase, Cassandra. E são precisamente consultas analíticas pesadas que não funcionarão normalmente para eles. Ou você pode pensar que eles funcionam bem se você não tiver nenhuma experiência com o ClickHouse.

• Obrigado

  • Boa tarde Já estou bastante interessado neste tema, pois possuo um subsistema analítico. Mas quando olho para ClickHouse, tenho a sensação de que ClickHouse é muito adequado para análise de eventos, mutável. E se eu precisar analisar muitos dados de negócios com várias tabelas grandes, o ClickHouse, pelo que entendi, não é muito adequado para mim? Principalmente se eles mudarem. Isso está correto ou existem exemplos que podem refutar isso?

  • Isso é certo. E isso é verdade para a maioria dos bancos de dados analíticos especializados. Eles são adaptados para o fato de haver uma ou mais tabelas grandes que são mutáveis ​​e para muitas tabelas pequenas que mudam lentamente. Ou seja, o ClickHouse não é como o Oracle, onde você pode colocar tudo e construir algumas consultas bem complexas. Para usar o ClickHouse de forma eficaz, você precisa criar um esquema que funcione bem no ClickHouse. Ou seja, evite a normalização excessiva, use dicionários, tente fazer menos links longos. E se o esquema for construído dessa maneira, tarefas de negócios semelhantes poderão ser resolvidas no ClickHouse com muito mais eficiência do que em um banco de dados relacional tradicional.

Obrigado pelo relatório! Eu tenho uma pergunta sobre o caso financeiro mais recente. Eles tinham análises. Era necessário comparar como eles sobem e descem. E eu entendo que você construiu o sistema especificamente para esta análise? Se amanhã, por exemplo, eles precisarem de algum outro relatório sobre esses dados, eles precisam reconstruir o esquema e carregar os dados? Ou seja, fazer algum tipo de pré-processamento para receber a requisição?

Claro, este é o uso do ClickHouse para uma tarefa muito específica. Poderia ser mais tradicionalmente resolvido dentro do Hadoop. Para Hadoop, esta é uma tarefa ideal. Mas no Hadoop é muito lento. E meu objetivo é demonstrar que o ClickHouse pode resolver tarefas que normalmente são resolvidas por meios completamente diferentes, mas ao mesmo tempo fazê-lo com muito mais eficiência. Isso é feito sob medida para uma tarefa específica. É claro que, se houver um problema com algo semelhante, ele poderá ser resolvido de maneira semelhante.

Está claro. Você disse que 50 horas foram processadas. É desde o início, quando você carregou os dados ou obteve os resultados?

Sim, sim.

Ok, muito obrigado.

Isso está em um cluster de 3 servidores.

Saudações! Obrigado pelo relatório! Tudo é muito interessante. Não vou perguntar um pouco sobre a funcionalidade, mas sobre o uso do ClickHouse em termos de estabilidade. Ou seja, você tinha algum, você teve que restaurar? Como a ClickHouse se comporta nesse caso? E por acaso você também tinha uma réplica? Por exemplo, encontramos um problema com o ClickHouse quando ele ainda sai do limite e cai.

Claro, não existem sistemas ideais. E o ClickHouse também tem seus próprios problemas. Mas você já ouviu falar que o Yandex.Metrica não funciona há muito tempo? Provavelmente não. Tem funcionado de forma confiável desde 2012-2013 no ClickHouse. Posso dizer o mesmo sobre a minha experiência. Nunca tivemos falhas completas. Algumas coisas parciais podiam acontecer, mas nunca eram críticas o suficiente para afetar seriamente os negócios. Isso nunca aconteceu. O ClickHouse é bastante confiável e não trava aleatoriamente. Você não precisa se preocupar com isso. Não é uma coisa crua. Isso foi comprovado por muitas empresas.

Olá! Você disse que precisa pensar sobre o esquema de dados imediatamente. E se isso acontecesse? Meus dados estão caindo e caindo. Seis meses se passaram e eu entendo que é impossível viver assim, preciso recarregar os dados e fazer algo com eles.

Isso depende, é claro, do seu sistema. Existem várias maneiras de fazer isso praticamente sem parar. Por exemplo, você pode criar uma Visualização Materializada na qual criar uma estrutura de dados diferente se ela puder ser mapeada exclusivamente. Ou seja, se permitir o mapeamento usando o ClickHouse, ou seja, extrair algumas coisas, alterar a chave primária, alterar o particionamento, então você pode fazer uma Visualização Materializada. Substitua seus dados antigos lá, os novos serão gravados automaticamente. E então apenas mude para usar a Visualização Materializada, então mude o registro e mate a tabela antiga. Este é geralmente um método ininterrupto.

Obrigado.

Fonte: habr.com