Prática iQIYI Data Lake - Evolução da arquitetura da plataforma de log baseada em data lake

Wuhan Yuan Chuanghui retorna, vamos falar sobre modelos grandes em 20 de abril”

fundo

Para atender às necessidades de consulta e análise de logs em tempo real dentro da empresa, a equipe de big data da iQiyi desenvolveu a plataforma de serviço de log Venus, que é responsável pela coleta, armazenamento, processamento e análise dos logs de serviço da iQiyi. No início, a arquitetura de análise de armazenamento baseada no ElasticSearch foi adotada. À medida que a escala dos dados continuava a se expandir, surgiram problemas como alto custo, gerenciamento difícil e baixa estabilidade.

A tecnologia de data lake se desenvolveu rapidamente nos últimos anos. Adota uma base unificada de armazenamento de big data e uma arquitetura que separa armazenamento e computação, fornecendo uma solução adequada para cenários como logs com grandes gravações e pequenas consultas. Portanto, Vênus realizou uma transformação arquitetônica baseada no data lake e empurrou os logs para dentro do lago. Depois de entrar no lago, o custo foi reduzido em 70% e a estabilidade melhorou bastante. Este artigo apresenta principalmente o processo de pensamento e construção de Vênus, desde uma arquitetura baseada em ElasticSearch até uma arquitetura baseada em data lake.

Introdução à plataforma de registro Venus

Venus é uma plataforma de serviço de log desenvolvida pela iQiyi. Ela fornece coleta, processamento, armazenamento, análise e outras funções. É usada principalmente para solução de problemas de log, análise de big data, monitoramento e alarmes dentro da empresa. 1. mostrado.

Figura 1 Link Vênus

Este artigo se concentra na evolução arquitetônica do link de solução de problemas de log. Seus links de dados incluem:

Coleta de logs : Ao implantar agentes de coleta em máquinas e hosts de contêineres, os logs de front-end, back-end, monitoramento e outras fontes de cada linha de negócios são coletados, e o negócio também tem suporte para auto-entrega de logs que atendem aos requisitos de formato . Mais de 30.000 agentes foram implantados, oferecendo suporte a 10 fontes de dados, como Kafka, MySQL, K8s e gateways.
Processamento de log : após a coleta de log, ele passa por processamento padronizado, como extração regular e extração de analisador integrado, e é gravado uniformemente no Kafka no formato JSON e, em seguida, gravado no sistema de armazenamento pelo programa de despejo.
Armazenamento de logs : Venus armazena quase 10.000 fluxos de logs de negócios, com um pico de gravação de mais de 10 milhões de QPS e novos logs diários superiores a 500 TB. À medida que a escala de armazenamento muda, a seleção de sistemas de armazenamento passa por muitas mudanças, do ElasticSearch ao data lake.
Análise de consulta : Venus fornece análise de consulta visual, consulta contextual, disco de log, reconhecimento de padrões, download de log e outras funções.

Para atender ao armazenamento e análise rápida de dados de log massivos, a plataforma de log Venus passou por três grandes atualizações de arquitetura, evoluindo gradualmente da arquitetura ELK clássica para um sistema autodesenvolvido baseado em data lakes. durante a transformação da arquitetura e soluções de Vênus.

Venus 1.0: Baseado na arquitetura ELK

O Venus 1.0 começou em 2015 e foi construído com base no então popular ElasticSearch+Kibana, conforme mostrado na Figura 2. ElasticSearch é responsável pelas funções de armazenamento e análise de logs, e Kibana fornece consulta visual e recursos de análise. Você só precisa consumir Kafka e gravar logs no ElasticSearch para fornecer serviços de log.

Figura 2 Arquitetura Vênus 1.0

Como existem limites máximos de rendimento, capacidade de armazenamento e número de fragmentos de índice de um único cluster ElasticSearch, a Venus continua a adicionar novos clusters ElasticSearch para lidar com a crescente demanda de log. Para controlar os custos, a carga de cada ElasticSearch é de alto nível e o índice é configurado com 0 cópias. Problemas como gravação repentina de tráfego, grandes consultas de dados ou falhas de máquina que levam à indisponibilidade do cluster são frequentemente encontrados. Ao mesmo tempo, devido ao grande número de índices no cluster, à grande quantidade de dados e ao longo tempo de recuperação, os logs ficam indisponíveis por um longo período e a experiência de uso do Vênus torna-se cada vez pior.

Vênus 2.0: baseado em ElasticSearch + Hive

Para aliviar os problemas encontrados pelo Vênus 1.0, o Vênus 2.0 introduziu o Hive. A arquitetura é mostrada na Figura 3. As principais melhorias são as seguintes:

Classificação de cluster: os clusters ElasticSearch são divididos em duas categorias: alta qualidade e baixa qualidade. As principais empresas usam clusters de alta qualidade, a carga do cluster é controlada em um nível baixo e o índice é habilitado com uma configuração de 1 cópia para tolerar falhas de nó único. As empresas não-chave usam um cluster de baixa qualidade, a carga; é controlado em alto nível e o índice ainda usa uma configuração de cópia 0.
Classificação de armazenamento: ElasticSearch e Hive de gravação dupla para logs de armazenamento longo. O ElasticSearch salva os logs dos últimos 7 dias e o Hive salva os logs por um período de tempo mais longo, o que reduz a pressão de armazenamento do ElasticSearch e também reduz o risco de o ElasticSearch ser interrompido por grandes consultas de dados. No entanto, como o Hive não pode realizar consultas interativas, os logs no Hive precisam ser consultados por meio de uma plataforma de computação offline, resultando em uma experiência de consulta ruim.
Portal de consulta unificado: fornece um portal visual unificado de consulta e análise semelhante ao Kibana, protegendo o cluster ElasticSearch subjacente. Quando um cluster falha, os logs recém-gravados são agendados para outros clusters sem afetar a consulta e a análise de novos logs. Agende de forma transparente o tráfego entre clusters quando a carga do cluster estiver desequilibrada.

Figura 3 Arquitetura Vênus 2.0

A Venus 2.0 é uma solução de compromisso para proteger as principais empresas e reduzir o risco e o impacto das falhas. Ainda apresenta problemas de custos elevados e de fraca estabilidade:

ElasticSearch tem curto tempo de armazenamento: Devido à grande quantidade de logs, ElasticSearch pode armazenar apenas 7 dias, o que não pode atender às necessidades diárias de negócios.
Existem muitas entradas e fragmentação de dados: mais de 20 clusters ElasticSearch + 1 cluster Hive, existem muitas entradas de consulta, o que é muito inconveniente para consulta e gerenciamento.
Alto custo: embora o ElasticSearch armazene logs apenas por 7 dias, ele ainda consome mais de 500 máquinas.
Leitura e escrita integradas: O servidor ElasticSearch é responsável por ler e escrever ao mesmo tempo, afetando um ao outro.
Muitas falhas: as falhas do ElasticSearch são responsáveis por 80% do total de falhas do Venus. Após as falhas, a leitura e a gravação são bloqueadas, os logs são facilmente perdidos e o processamento é difícil.

Venus 3.0: Nova arquitetura baseada em data lake

Pensando em introduzir o data lake

Após uma análise aprofundada do cenário logístico de Vénus, resumimos as suas características da seguinte forma:

Grande quantidade de dados : quase 10.000 fluxos de log de negócios com capacidade máxima de gravação de 10 milhões de QPS e armazenamento de dados em nível de PB.
Escreva mais e verifique menos : as empresas geralmente consultam os logs apenas quando há necessidade de solução de problemas. A maioria dos logs não tem requisitos de consulta em um dia, e o QPS geral da consulta também é extremamente baixo.
Consulta interativa : os logs são usados principalmente para solucionar problemas urgentes que exigem várias consultas consecutivas e exigem uma experiência de consulta interativa de segundo nível.

Em relação aos problemas encontrados ao usar o ElasticSearch para armazenar e analisar logs, acreditamos que ele não corresponde exatamente ao cenário de log de Vênus pelos seguintes motivos:

Um único cluster tem QPS de gravação e escala de armazenamento limitados, portanto, vários clusters precisam compartilhar o tráfego. Questões complexas de estratégia de agendamento, como tamanho do cluster, tráfego de gravação, espaço de armazenamento e número de índices, precisam ser consideradas, o que aumenta a dificuldade de gerenciamento. Como o tráfego de log de negócios varia muito e é imprevisível, para resolver o impacto do tráfego repentino na estabilidade do cluster, muitas vezes é necessário reservar mais recursos ociosos, resultando em um enorme desperdício de recursos do cluster.
A indexação de texto completo durante a gravação consome muita CPU, levando à expansão de dados e a um aumento significativo nos custos de computação e armazenamento. Em muitos cenários, o armazenamento de registos de análise requer mais recursos do que recursos de serviço em segundo plano. Para cenários como logs em que há muitas gravações e poucas consultas, pré-computar o índice de texto completo é mais luxuoso.
Os dados de armazenamento e os cálculos estão na mesma máquina. Consultas de grandes volumes de dados ou análises agregadas podem facilmente afetar a gravação, causando atrasos na gravação ou até mesmo falhas no cluster.

为了解决上述问题，我们调研了ClickHouse、Iceberg数据湖等替代方案。其中，Iceberg是爱奇艺内部选择的数据湖技术，是一种存储在HDFS或对象存储之上的表结构，支持分钟级的写入可见性及海量数据的存储。Iceberg对接Trino查询引擎，可以支持秒级的交互式查询，满足日志的查询分析需求。

针对海量日志场景，我们对ElasticSearch、ElasticSearch+Hive、ClickHouse、Iceberg+Trino等方案做了对比评估：

通过对比，我们发现基于Iceberg+Trino的数据湖架构最适合Venus日志场景：

存储空间大：Iceberg底层数据存储在大数据统一的存储底座HDFS上，意味着可以使用大数据的超大存储空间，不需要再通过多个集群分担存储，降低了存储的维护代价。
存储成本低：日志写入到Iceberg不做全文索引等预处理，同时开启压缩。HDFS开启三副本相比于ElasticSearch的三副本存储空间降低近90%，相比ElasticSearch的单副本存储空间仍然降低30%。同时，日志存储可以与大数据业务共用HDFS空间，进一步降低存储成本。
计算成本低：对于日志这种写多查少的场景，相比于ElasticSearch存储前做全文索引等预处理，按查询触发计算更能有效利用算力。
存算隔离：Iceberg存储数据，Trino分析数据的存算分离架构天然的解决了查询分析对写入的影响。

基于数据湖架构的建设

通过上述评估，我们基于Iceberg和Trino构建了Venus 3.0。采集到Kafka中的日志由转存程序写入Iceberg数据湖。Venus查询平台通过Trino引擎查询分析数据湖中的日志。架构如图4所示。

图4 Venus 3.0架构

日志存储

如图4所示，数据湖中的日志存储包含三个层次，分别是HDFS数据存储层、Alluxio缓存层及Iceberg表格式层。对读写可见的是Iceberg表格式层，日志流以表的形式写入，并持久化存储到HDFS。对于查询性能要求高的日志流会开启Alluxio缓存，日志流同时写入Alluxio和HDFS，查询时优先读取Alluxio的数据，加快数据加载速度。所有日志都存在一个Iceberg库下，一个日志流对应一张Iceberg表。表的schema由日志的格式决定，按日志中的时间戳字段做小时级分区，并按业务需求配置TTL。Iceberg的数据可见性由写入时提交周期决定，我们按需每分钟或者每5分钟做一次提交。

查询分析

Venus日志平台将用户的查询分析请求翻译成SQL，通过Trino查询Iceberg，所有SQL的执行由一个Trino集群承担。对于10亿行日志，字符串匹配的查询5秒左右返回结果，聚合查询30秒内返回结果，满足大部分的日志使用场景。

对日志查询性能要求更高的表，我们开启了Alluxio缓存。如图5所示，对于慢查询，使用Alluxio后查询速度有大幅的提升，P99耗时降低84%。

图5 日志查询性能对比

转存程序

Venus转存程序将Kafka中的数据写入数据湖中，采用了对Iceberg支持比较好的Flink计算引擎，通过Flink SQL消费Kafka写入Iceberg。每个日志流运行一个转存程序，单核支持16MB/s的写入，是写入ElasticSearch的3倍。在爱奇艺，Flink程序部署在YARN集群上，最小的CPU调度粒度为1个核，加上Flink Master，运行起来至少需要2个核。Venus接入的近万个日志采集中95%的日志流量低于16MB/s，相当大比例的日志流量在KB/s级别，部署在YARN上将造成巨大的资源浪费。因此，我们选择了大小流量调度策略，将资源需求大于1核的转存程序部署在YARN上，资源需求小于1核的转存程序，以Flink单机运行模式部署在K8S上，将部署资源粒度降低到0.1核。与写入ElasticSearch的转存程序相比，计算资源消耗降低了70%。

落地效果

得益于Venus 提供的统一查询分析入口，从ElasticSearch到数据湖的切换过程对业务几乎透明。相比旧架构，整体成本降低70%以上，每年节省上千万元，同时故障率降低了85%：

存储空间 ：日志的物理存储空间降低30%，考虑到ElasticSearch集群的磁盘存储空间利用率较低，实际存储空间降低50%以上。
计算资源 ：Trino使用的CPU核数相比于ElasticSearch减少80%，转存程序资源消耗降低70%。
稳定性提升：迁移到数据湖后，故障数降低了85%，大幅节省运维人力。

总结与规划

目前基于数据湖的Venus架构已稳定上线一年，为业务提供高性价比的日志服务。未来Venus将在以下几个方面进一步探索：

Iceberg+Trino的数据湖架构支持的查询并发较低，我们将尝试使用Bloomfilter、Zorder等轻量级索引提升查询性能，提高查询并发，满足更多的实时分析的需求。
目前Venus存储了近万个业务日志流，日新增日志超过500TB。计划引入基于数据热度的日志生命周期管理机制，及时下线不再使用的日志，进一步节省资源。
如图1所示，Venus同时也承载了大数据分析链路的Pingback用户数据的采集与处理，该链路与日志数据链路比较类似，参考日志入湖经验，我们对Pingback数据的处理环节进行基于数据湖的流批一体化改造。目前已完成一期开发与上线，应用于直播监控、QOS、DWD湖仓等场景，后续将继续推广至更多的湖仓场景。详细技术细节将在后续的数据湖系列文章中介绍。

也许你还想看

爱奇艺数据湖实战

爱奇艺大数据加速 - 从Hive到Spark SQL

爱奇艺数据湖实战 - 广告数据湖应用

本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。