Introdução ao histórico
ByConity é adequado para uma variedade de cenários de negócios e tem desempenho muito bom em acesso a dados em tempo real, consultas de agregação de tabelas grandes e amplas, análises e cálculos complexos sob dados massivos e consultas de correlação de várias tabelas. Vamos usar um cenário de negócios real para apresentar este sistema de análise de comportamento. Este sistema de análise de comportamento é baseado em uma plataforma multidimensional de análise de comportamento do usuário e fornece vários métodos e cenários de análise, como análise de eventos, análise de retenção, análise de conversão, agrupamento de usuários e. retenção de usuários. Este artigo apresentará os problemas e desafios encontrados por esta plataforma multidimensional de análise do comportamento do usuário ao usar o cluster ClickHouse original e como resolver esses problemas e trazer benefícios para o negócio após a migração do ByConity.
Figura 1
Projeto de arquitetura
do sistema de análise comportamental
questões e desafios
No início, este sistema foi implantado no cluster ClickHouse. Por um lado, devido ao rápido desenvolvimento do negócio, a quantidade de dados aumentava a cada dia. O máximo de novos dados diários ultrapassava 320 TB, o número diário de. novas linhas ultrapassaram 2,3 trilhões e as dimensões de dados do usuário ultrapassaram 20.000. Por outro lado, as necessidades de consulta do usuário são mais flexíveis e diversificadas e precisam oferecer suporte a consultas detalhadas, consultas agregadas e consultas de análise interativas; e fornecer resultados de resposta rápida. Além disso, à medida que a quantidade de dados continua a aumentar (crescimento anual de 35%), devemos não só ser capazes de suportar os desafios trazidos por um aumento tão grande de dados, mas também controlar a taxa de crescimento dos custos dentro de um determinado intervalo.
Mas é difícil fazer isso no cluster ClickHouse existente. A razão é que ClickHouse é baseado em uma arquitetura Shared-Nothing. Cada nó é independente e não compartilha recursos de armazenamento. Portanto, os recursos de computação e de armazenamento estão fortemente acoplados, o que levará aos seguintes problemas:
-
O custo do aumento e da redução torna-se mais elevado e envolve a migração de dados, o que nos impede de aumentar e diminuir em tempo real conforme necessário, o que também conduz a um desperdício de recursos e a custos incontroláveis.
-
A arquitetura fortemente acoplada fará com que vários locatários interajam entre si em um ambiente de cluster compartilhado, fazendo com que as consultas dos usuários afetem umas às outras.
-
Como a leitura e a gravação dos nós do cluster são concluídas no mesmo nó, a leitura e a gravação afetam uma à outra.
-
O suporte de desempenho para consultas complexas, como operações de junção de múltiplas tabelas, não é muito bom e não pode atender às diversas necessidades de consulta dos usuários.
Seleção de tecnologia
Portanto, no início de 2022, a empresa passou a utilizar ByConity com uma arquitetura de separação de computação e armazenamento como principal mecanismo OLAP. ByConity é um data warehouse nativo da nuvem de código aberto que adota uma arquitetura de separação de armazenamento de computação e oferece suporte a vários recursos importantes, como separação de armazenamento de computação, expansão e contração elástica, isolamento de recursos multilocatários e forte consistência de leitura e gravação de dados . Ao utilizar otimizações de mecanismo OLAP convencionais, como armazenamento de coluna, execução vetorizada, execução MPP, otimização de consulta, etc., ByConity pode fornecer excelente desempenho de leitura e gravação.
Figura 2
Diagrama de arquitetura técnica de três camadas
ByConity
ByConity é uma atualização baseada na arquitetura ClickHouse de código aberto. Ele introduz uma arquitetura que separa computação e armazenamento. Ele transforma a arquitetura original na qual a computação e o armazenamento são gerenciados localmente em cada nó em um gerenciamento unificado de todas as tarefas em todo o cluster. armazenamento distribuído A arquitetura de dados torna cada nó de computação um nó de computação puro sem estado e usa os recursos de expansão do armazenamento distribuído e as características sem estado dos nós de computação para obter expansão e contração dinâmicas. É justamente por causa dessa melhoria que o ByConity conta com as seguintes características importantes:
-
Isolamento de recursos : Isole recursos para diferentes locatários para que os locatários não sejam afetados uns pelos outros.
-
Separação de leitura e gravação : os recursos de computação e os recursos de armazenamento são dissociados para garantir que as operações de leitura e gravação não afetem umas às outras.
-
Expansão e contração elásticas : Suporta expansão e contração elásticas e pode expandir e contrair recursos de computação em tempo real e sob demanda para garantir a utilização eficiente dos recursos.
-
Forte consistência de dados : Forte consistência de leitura e gravação de dados garante que os dados estejam sempre atualizados e não haja inconsistência entre leitura e gravação.
-
Alto desempenho : adota a otimização do mecanismo OLAP convencional, como armazenamento de coluna, execução vetorizada, execução MPP, otimização de consulta, etc., para fornecer excelente desempenho de leitura e gravação
receita de negócios
Após a introdução do ByConity, o desempenho geral pode chegar a 91% e todas as consultas dos usuários podem ser concluídas em 10 segundos. Por meio da pesquisa de feedback dos usuários, esse indicador de desempenho também está dentro da faixa aceitável de usuários. Aqui está um resumo dos benefícios gerais e da experiência trazida pela nossa migração para ByConity:
-
Evite a preempção de recursos e garanta que o desempenho da consulta seja 100% estável :
No cluster ClickHouse original, frequentemente encontramos o problema de aglomeração de recursos. Como o ClickHouse não alcançava o isolamento de recursos e o isolamento de inquilinos, quando vários usuários compartilhavam o cluster para consulta, quando um usuário consultava recursos, a sobrecarga seria muito alta, o que seria. envolver A preempção de recursos faz com que todas as consultas de usuários compartilhadas neste cluster sejam instáveis e a qualidade do serviço não possa ser satisfeita. No entanto, após a migração para ByConity, como o grupo de computação está completamente isolado fisicamente, o isolamento de recursos naturais e o isolamento de locatários podem ser alcançados. As consultas de diferentes usuários não são afetadas entre si. O desempenho geral da consulta pode atingir 91%. pode ser concluído em 10 segundos. Além disso, ByConity fornece links de consulta complexos autodesenvolvidos, cache de disco autodesenvolvido para reduzir a leitura fria de dados e índices usados com frequência. Além disso, a eficiência de leitura a quente também é melhor do que a do cluster ClickHouse original. Cluster ClickHouse, ByConity A perda de desempenho no cluster está dentro de 10%.
-
Baixos custos de operação e manutenção e nós defeituosos podem ser substituídos em segundos :
Originalmente, no cluster Clickhouse, se um nó do cluster estiver quebrado, toda a máquina precisará ser desativada para reparos. Isso ocorre porque os recursos de computação, recursos de armazenamento e informações de metadados do ClickHouse estão todos neste nó, que. é equivalente a um pequeno cluster. Um recurso de computação é perdido e uma cópia de armazenamento é perdida. Antes de substituir um novo nó, o disco local do nó quebrado precisa ser copiado e migrado para o novo nó. elevado e a consistência dos dados é difícil de garantir. Para ByConity, se o grupo de computação estiver quebrado, uma vez que o grupo de computação não armazena dados e contém apenas nós de computação sem estado, ele só precisa ser substituído por um novo grupo de computação. A confiabilidade e consistência dos dados são fornecidas pelo HDFS. garantir que a perda de cache de dados de leitura a quente local seja controlável no desempenho da consulta de negócios, esta parte se beneficia principalmente do armazenamento ByConity e da arquitetura de separação de computação.
-
Expansão e contração sem sensor , economizando custos de recursos:
ByConity pode alcançar expansão e contração contínuas. É uma implantação modular e em contêiner baseada na escalabilidade elástica do Kubernetes. Se houver máquinas suficientes, pode ser expandido indefinidamente. se preocupar porque o nó do ByConity é apenas um nó de computação sem estado e removê-lo diretamente terá pouco impacto em todo o cluster. Além disso, o agendamento adaptativo é usado para evitar nós lentos, melhorar os recursos de rendimento e melhorar a utilização dos recursos do nó. Ao mesmo tempo, a taxa de compactação da ByConity é extremamente alta. Tomando como exemplo um de seus negócios, 460 TB de dados são adicionados todos os dias, atingindo 100 TB após a compactação, com uma taxa de compactação de 65%. ZSTD e outros métodos de compressão, que consomem mais armazenamento em casos extremos, menos que o parquet.
-
A consistência dos dados é fortemente garantida e a complexidade de manutenção é próxima de zero :
Após migrar para ByConity, resolvemos completamente o problema de consistência de dados, porque ByConity não tem problema de sincronização mestre-escravo local, e o problema de consistência de dados é resolvido diretamente pelo armazenamento de objeto subjacente, como HDFS/S3, etc. Desta forma, a complexidade da manutenção da consistência é bastante reduzida e a probabilidade de erro também é menor. Atualmente, poucos usuários relatam problemas de consistência de dados. Mas isso já foi encontrado com frequência antes, porque o cluster ClickHouse é mantido por várias cópias por meio de comunicação entre nós e os problemas de consistência são mantidos por meio de filas de consistência. A implementação também é muito complicada e propensa a erros. Além disso, ByConity pode acessar diretamente arquivos de dados por meio de HDFS. Diferentes mecanismos de computação se adaptam a diferentes conectores para ler dados e possuem recursos universais.
perspectiva futura
Após um ano e meio de exploração prática, ByConity se tornou o principal mecanismo OLAP usado internamente. Um grande número de usuários e dados serão transferidos posteriormente e, eventualmente, substituirá o cluster ClickHouse original. Pode-se observar que o ByConity, como mecanismo OLAP com computação e armazenamento separados, tem as vantagens de alto desempenho, alta escalabilidade e alta estabilidade, podendo atender às necessidades de processamento e análise de dados em larga escala. Ao mesmo tempo, através da comunicação na comunidade e da discussão do Roteiro divulgada pela comunidade https://github.com/ByConity/ByConity/issues/26, ByConity se concentrará principalmente nas seguintes direções no futuro:
-
Suporta execução em vários estágios, recursos ETL, etc. da camada de execução
-
Suporta consultas federadas de data lake, como Hudi, Iceberg, etc.
A comunidade ByConity tem um grande número de usuários e é uma comunidade muito aberta. Convidamos todos a discutir a co-construção conosco no Github. Você também pode participar do nosso grupo WeChat, grupo Feishu ou Discord.
GitHub: https://github.com/ByConity/ByConity
{{o.nome}}
{{m.nome}}