Autor｜Cheng Wei, engenheiro de pesquisa e desenvolvimento de big data da MetaAPP
ByConity é o data warehouse nativo da nuvem de código aberto da ByteDance. Ele atende às necessidades dos usuários de data warehouse para expansão e contração elástica de recursos, separação de leitura e gravação, isolamento de recursos, forte consistência de dados, etc., ao mesmo tempo que fornece excelente desempenho de consulta e gravação.
A MetaApp é uma desenvolvedora e operadora líder de jogos na China, focada na distribuição eficiente de informações móveis e comprometida em construir um mundo virtual para todas as idades. Em 2023, MetaApp tinha mais de 200 milhões de usuários registrados, colaborou em 200.000 jogos e tem um volume de distribuição cumulativo de mais de 1 bilhão.
MetaApp prestou atenção ao ByConity nos primeiros dias do código aberto e foi um dos primeiros usuários a testá-lo e lançá-lo no ambiente de produção. Com a ideia de compreender os recursos dos projetos de data warehouse de código aberto, a equipe de P&D de big data da MetaApp conduziu um teste preliminar no ByConity. Sua arquitetura de separação de armazenamento-computação e excelente desempenho, especialmente em cenários de análise de log, suporte para consultas complexas em dados de grande escala, atraiu o MetaApp para realizar testes aprofundados do ByConity e, eventualmente, substituiu totalmente o ClickHouse no ambiente de produção, reduzindo custos de recursos em mais de 50%.
Este artigo apresentará principalmente as funções da plataforma de análise de dados MetaApp, os problemas e soluções encontrados em cenários de negócios e a ajuda para introduzir ByConity em seus negócios.
Arquitetura e funções da plataforma de análise de dados MetaApp OLAP
Com o crescimento dos negócios e a introdução de operações refinadas, os produtos apresentam requisitos mais elevados para o departamento de dados, incluindo a necessidade de consultar e analisar dados em tempo real e ajustar rapidamente as estratégias de operação para realizar experimentos AB em um pequeno grupo de pessoas; verificar a eficácia das novas funções Reduz o tempo e a dificuldade de consulta de dados, permitindo que não profissionais analisem e explorem os dados de forma independente. Para atender às necessidades de negócios, MateApp implementou uma plataforma de análise de dados OLAP que integra análise de eventos, análise de conversão, retenção personalizada, agrupamento de usuários, análise de fluxo de comportamento e outras funções .
Esta é uma arquitetura OLAP típica, dividida em duas partes, uma offline e outra em tempo real.
No cenário offline , usamos o DataX para integrar os dados do Kafka ao data warehouse do Hive e, em seguida, gerar relatórios de BI. Os relatórios de BI usam o componente Superset para exibir resultados;
Em um cenário em tempo real , uma linha usa GoSink para integração de dados e integra dados GoSink ao ClickHouse, e a outra linha usa CnchKafka para integrar dados ao ByConity. Por fim, os dados são obtidos através da plataforma de consulta OLAP para consulta.
Comparação de funções entre ByConity e ClickHouse
ByConity é um data warehouse nativo da nuvem de código aberto desenvolvido com base no núcleo ClickHouse e adota uma arquitetura de separação de armazenamento-computação. Ambos possuem as seguintes características:
- A velocidade de gravação é muito rápida, adequada para gravar grandes quantidades de dados, e a quantidade de dados gravados pode chegar a 50 MB - 200 MB/s
- A velocidade da consulta é muito rápida. Em dados massivos, a velocidade da consulta pode atingir 2-30 GB/s.
- Alta taxa de compactação de dados, baixo custo de armazenamento, taxa de compactação pode chegar a 0,2 ~ 0,3
ByConity tem as vantagens do ClickHouse, mantém boa compatibilidade com ClickHouse e foi aprimorado em termos de separação leitura-gravação, expansão e contração elástica e forte consistência de dados . Ambos são aplicáveis aos seguintes cenários OLAP:
- Os conjuntos de dados podem ser grandes – bilhões ou trilhões de linhas
- A tabela de dados contém muitas colunas
- Consultar apenas colunas específicas
- Os resultados devem ser retornados em milissegundos ou segundos
Em compartilhamentos anteriores, a comunidade ByConity comparou os dois [do ponto de vista do uso]
Durante a construção da plataforma OLAP, focamos principalmente no isolamento de recursos, expansão e contração de capacidade , consultas complexas e suporte para transações distribuídas .
Problemas encontrados ao usar ClickHouse
Problema 1: A leitura e a escrita integradas podem facilmente aproveitar recursos e não podem garantir uma leitura/escrita estável.
Durante períodos de pico de negócios, a gravação de dados ocupará uma grande quantidade de recursos de E/S e CPU, fazendo com que as consultas sejam afetadas (os tempos de consulta serão mais longos). O mesmo vale para consultas de dados.
Problema 2: A expansão/redução é problemática e leva muito tempo
- Longo tempo de expansão/redução: Como a máquina está em um IDC e pertence a uma nuvem privada, um dos problemas é que o ciclo de adição de nós é extremamente longo. Leva de uma a duas semanas desde o momento em que a demanda do nó é emitida até a adição real de nós bons, o que afeta os negócios;
- Não é possível aumentar e diminuir rapidamente: os dados precisam ser redistribuídos após o aumento, caso contrário, a pressão do nó será muito alta.
Problema três: A operação e a manutenção são complicadas e o SLA não pode ser garantido durante períodos de pico de negócios.
- Muitas vezes, devido a falhas nos nós de negócios, as consultas de dados são lentas e a gravação dos dados atrasa (de algumas horas a alguns dias);
- Há uma grave escassez de recursos durante os períodos de pico de negócios e é impossível expandir os recursos no curto prazo. A única maneira é excluir os dados de alguns serviços para fornecer serviços de alta prioridade;
- Durante os períodos de baixa atividade, um grande número de recursos fica ocioso e os custos são inflacionados. Embora estejamos no IDC, a compra da máquina IDC também está sujeita ao controle de custos e a expansão do nó não pode ser ilimitada. Além disso, há um certo consumo de custos durante o uso normal;
- Não é possível interagir com recursos da nuvem.
Melhorias após a introdução do ByConity
Em primeiro lugar, a separação dos recursos de computação de leitura e escrita do ByConity pode garantir que as tarefas de leitura e escrita sejam relativamente estáveis. Caso as tarefas de leitura não sejam suficientes, os recursos correspondentes podem ser ampliados para suprir a escassez, inclusive utilizando recursos da nuvem para expansão.
Em segundo lugar, aumentar e diminuir a escala é relativamente simples e pode ser feito ao nível minucioso. Como o armazenamento distribuído HDFS/S3 é usado e a computação e o armazenamento são separados, a redistribuição de dados não é necessária após a expansão e pode ser usada diretamente após a expansão.
Além disso, a implantação, operação e manutenção nativas da nuvem são relativamente simples.
- Os componentes do HDFS/S3 são relativamente maduros e estáveis, com expansão e contração de capacidade, soluções maduras de recuperação de desastres e problemas podem ser resolvidos rapidamente;
- Durante períodos de pico de negócios, o SLA pode ser garantido através da rápida expansão dos recursos;
- Durante períodos de baixo pico de negócios, os custos podem ser reduzidos reduzindo os recursos de armazenamento/computação.
O uso e operação do ByConity
Uso do cluster ByConity
Atualmente, nossa plataforma tem usado ByConity de forma estável em cenários de negócios. Através de sucessivas migrações, ByConity assumiu completamente o controle dos dados do cluster ClickHouse e começou a fornecer serviços de forma estável. Construímos o cluster ByConity usando S3 mais K8s na nuvem. Também usamos uma solução de expansão e contração programada, que pode ser expandida às 10h e reduzida às 20h nos dias de semana. dia. . De acordo com os cálculos, este método reduz os recursos em cerca de 40% a 50% em comparação com o uso direto de assinaturas anuais e mensais. Além disso, também estamos promovendo a combinação de nuvem privada + nuvem pública para atingir o objetivo de reduzir custos e melhorar a estabilidade do serviço.
A figura abaixo mostra nosso uso atual, usando o servidor OLAP para realizar consultas conjuntas no cluster ClickHouse e ByConity na sala de computadores offline do IDC. No curto prazo, o cluster ClickHouse ainda será usado como uma transição para empresas que dependem parcialmente do ClickHouse.
No futuro, iremos consultar e mesclar dados offline, enquanto os recursos consumidos pelo Kafka serão usados online. Ao expandir recursos, você pode expandir os recursos de vw_default e vw_write online e usar racionalmente os recursos da nuvem pública para lidar com o problema de recursos insuficientes. Ao mesmo tempo, a capacidade é reduzida durante picos de negócios baixos para reduzir o consumo da nuvem pública.
Comparação de consultas ByConity e ClickHouse em dados de negócios
Conjunto de dados de teste e configuração de recursos
- Número de itens de dados: particionados por data, 4 bilhões de itens em um único dia, 40 bilhões no total em 10 dias
- Dados tabulares: 2.800 colunas
Como pode ser visto na tabela acima:
Os recursos utilizados pela consulta do cluster ClickHouse são: 400 núcleos e 2560G de memória
Os recursos usados pela consulta do cluster de trabalho ByConity 8 são: 120 núcleos e 880G de memória
Os recursos usados pela consulta do cluster de trabalho ByConity 16 são: 240 núcleos e 1760G de memória
Resumo dos resultados da consulta SQL comercial
O resumo aqui usa o valor médio, como você pode ver:
- OLAP convencional - desduplicação, retenção, conversão e enumeração podem obter o mesmo efeito de consulta que o cluster ClickHouse (400C, 2560G) a um custo de recursos relativamente pequeno (120C, 880G) e podem ser duplicados expandindo os recursos (240C, 1760G ) para obter o efeito de duplicar a velocidade da consulta. Se for necessária maior velocidade de consulta, mais recursos poderão ser expandidos;
- Não estar na filtragem pode exigir um custo moderado de recursos (240C, 1760G) para obter efeitos semelhantes ao cluster ClickHouse (400C, 2560G);
- O bitmap pode exigir maiores custos de recursos para obter efeitos semelhantes aos clusters ClickHouse.
Consulta geral/consulta de análise de eventos
Como pode ser visto na figura acima:
- No cenário de consulta de desduplicação, não há muita diferença entre ativar a otimização ByConity e não ativar a otimização;
- 8 trabalhadores (120C 880G) basicamente atingem tempo de consulta próximo ao ClickHouse;
- Em cenários de desduplicação, a velocidade da consulta pode ser acelerada pela expansão dos recursos computacionais.
Cálculo de retenção
Como pode ser visto na figura acima:
- No cenário de computação retida, o tempo de consulta após ByConity ativar a otimização é de 33% do tempo de consulta sem ativar a otimização;
- 8 trabalhadores (120C 880G) O tempo de consulta com otimização ativada é 30% do tempo de consulta;
- No cenário de computação retida, a velocidade da consulta pode ser acelerada para 16% do tempo de consulta CK expandindo os recursos computacionais + otimização.
Cálculo de conversão
Como pode ser visto na figura acima:
- No cenário de cálculo de conversão, o tempo de consulta após ByConity ser habilitado para otimização é de 60% do tempo de consulta sem otimização;
- O tempo de consulta de 8 trabalhadores (120C 880G) com otimização ativada é próximo ao tempo de consulta do ClickHouse;
- Transformando cenários de computação, a velocidade de consulta pode ser acelerada para 53% do tempo de consulta do ClickHouse, expandindo os recursos de computação + otimização.
não está no filtro
Não na filtragem é usado principalmente em cenários de agrupamento de usuários e cenários de marcação de usuários.
Como pode ser visto na figura acima:
- No cenário sem filtragem, ByConity com otimização ativada é pior do que ByConity com otimização não ativada, portanto, neste cenário usamos diretamente o método de não ativar a otimização;
- O tempo de consulta de 8 trabalhadores (120C 880G) sem otimização é mais lento que o tempo de consulta do ClickHouse, mas não muito;
- Em nenhum cenário de filtragem, a velocidade da consulta pode ser acelerada para 86% do tempo de consulta do ClickHouse, expandindo os recursos de computação.
Clique em cálculo 
Como pode ser visto na figura acima:
- Depois de verificar a cena, é melhor ativar e otimizar o ByConity do que o ByConity não ativar a otimização;
- O tempo de consulta de 8 trabalhadores (120C 880G) sem otimização é próximo ao tempo de consulta do ClickHouse;
- No cenário click-through, a velocidade da consulta pode ser acelerada para 26% do tempo de consulta do ClickHouse, expandindo os recursos de computação e ativando a otimização.
consulta de bitmap
A consulta bitmap é um cenário mais usado em testes AB.
Como pode ser visto na figura acima:
- Na cena de filtragem de bitmap, é melhor ativar a otimização ByConity do que sem a otimização ByConity;
- O tempo de consulta de 8 trabalhadores (120C 880G) sem otimização é muito mais lento que o tempo de consulta do ClickHouse;
- Cena de filtragem de bitmap, expansão de recursos para 16 trabalhadores (240C 1769G) é mais lenta que a consulta ClickHouse.
Ganhos após migração completa da ByConity
Recursos reduzidos
O seguinte não conta as diferenças de CPU, os dados são apenas para referência.
Após migração completa usando ByConity
- A comparação do consumo de recursos de consulta e mesclagem mostra que o consumo de CPU foi reduzido em cerca de 75% em comparação com antes;
- Comparando os recursos de gravação de dados, o consumo de CPU é reduzido em cerca de 35% em comparação com antes;
- Apenas metade dos recursos fixos precisam ser adquiridos, e a outra metade depende da flexibilidade dos dias úteis (10h às 20h). O custo é reduzido em cerca de 25% em relação à aquisição da totalidade dos recursos;
Consumo de uso atual
Como pode ser visto na tabela de resultados atual, as taxas de CPU e memória do ByConity são 34% e 48% do ClickHouse, respectivamente.
Consumo após adicionar armazenamento remoto
Usamos minio para armazenamento de dados no IDC, usando uma CPU de 640 núcleos, memória de 4096G, 16 nós, um único nó com 40 núcleos, 256G e um disco de 36T. Depois de adicionar esses custos ao ByConity, a proporção de CPU e memória do ByConity ainda. inferior ao ClickHouse, respectivamente 48% e 68% do ClickHouse. Pode-se dizer que em termos de utilização de recursos, se calculado anualmente e mensalmente, o ByConity será pelo menos cerca de 50% menor do que antes, se for iniciado e interrompido sob demanda, o custo será reduzido em cerca de 25%; em comparação com a compra integral de recursos .
Custos reduzidos de operação e manutenção
- Maneira mais fácil de gravar dados de configuração. No passado, o serviço de gravação que configuramos especialmente frequentemente apresentava problemas como Muitas peças.
- A expansão da consulta de pico é mais fácil. Basta adicionar o número de pods e você pode expandir rapidamente a capacidade. Ninguém perguntará "Por que os dados não foram divulgados depois de meia hora de verificação?"
Sugestões para substituir ClickHouse por ByConity
- Teste se o seu SQL pode rodar normalmente na plataforma ByConity do seu negócio. Se for compatível, basicamente rodará. Se houver alguns problemas menores em casos individuais, você poderá abordá-los na comunidade para obter feedback rápido;
- Controle os recursos do cluster de teste, teste o tamanho do conjunto de dados e compare os resultados da consulta do cluster ByConity e do cluster ClickHouse para ver se eles atendem às expectativas. Se esperado, a substituição pode ser planejada. Para tarefas mais focadas computacionalmente, o ByConity pode ter um desempenho melhor;
- Com base no tamanho do conjunto de dados de teste, no espaço S3 e HDF consumido, na largura de banda e no uso de recursos de computação QPS, são avaliados os recursos necessários para armazenamento e computação da quantidade total de dados;
- Insira os dados no cluster ByConity ou ClickHouse ao mesmo tempo e inicie a execução dupla por um período de tempo para resolver problemas que surjam durante a execução dupla. Por exemplo, quando nossa empresa não tem recursos suficientes, podemos usá-los com base nos negócios. Podemos primeiro construir um cluster ByConity na nuvem, mover-nos para uma determinada parte do negócio e, em seguida, substituí-lo gradualmente com base no negócio. Recursos da IDC, podemos movê-los. Parte dos dados é migrada offline;
- Você pode cancelar a assinatura do cluster ClickHouse depois que não houver problemas com a execução dupla.
Existem algumas considerações durante este processo:
- A largura de banda de leitura e o QPS do armazenamento remoto S3 e HDFS podem ser maiores e alguns preparativos são necessários. Por exemplo, nosso pico de largura de banda de leitura e gravação por segundo é: gravação de 2,5 GB/leitura de 6 GB, e o pico de QPS por segundo é: 2 ~ 6k;
- Quando a largura de banda do nó de trabalho estiver cheia, isso também causará um gargalo na consulta;
- O disco de cache do nó padrão (ou seja, o nó de computação de leitura) pode ser configurado para ser apropriadamente maior, o que pode reduzir a pressão da largura de banda do S3 durante a consulta e acelerar a consulta.
- Se você encontrar dados não armazenados em cache, poderá ter problemas de inicialização a frio. A ByConity também tem algumas sugestões operacionais para isso, que precisam ser mais integradas ao seu próprio negócio. Por exemplo, utilizamos a pré-verificação pela manhã para amenizar essa parte do problema da partida a frio.
plano futuro
No futuro, promoveremos o teste e implementação da solução de data lake ByConity. Além disso, combinaremos o gerenciamento de indicadores de dados com a teoria do data warehouse, de modo que 80% das consultas recaiam sobre o data warehouse. Todos são bem-vindos para participar da experiência.
GitHub｜https://github.com/ByConity/ByConity
Digitalize o código QR para adicionar o ByConity Assistant
Companheiro de frango, deepin-IDE de "código aberto" e finalmente conseguiu a inicialização! Bom cara, a Tencent realmente transformou o Switch em uma "máquina de aprendizagem pensante" Revisão de falhas e explicação da situação da Tencent Cloud em 8 de abril Reconstrução de inicialização de desktop remoto RustDesk Cliente Web Banco de dados de terminal de código aberto do WeChat baseado em SQLite WCDB inaugurou uma grande atualização Lista de abril TIOBE: PHP caiu para o nível mais baixo, Fabrice Bellard, o pai do FFmpeg, lançou a ferramenta de compressão de áudio TSAC , o Google lançou um grande modelo de código, CodeGemma , isso vai te matar? É tão bom que é de código aberto - ferramenta de edição de imagens e pôsteres de código aberto