爱奇艺数据湖实战 - 基于数据湖的日志平台架构演进

01

   背景

为了满足公司内日志实时查询分析的需求，爱奇艺大数据团队自研了Venus日志服务平台，负责爱奇艺各服务日志的采集、存储、处理、分析等场景。早期采用基于ElasticSearch的存储分析架构，随着数据规模的不断扩大，出现了成本高、管理困难、稳定性差等问题。

数据湖技术近几年快速发展，其采用了统一大数据存储底座和存算分离的架构，提供了一种适合于日志这种大量写入、少量查询场景的解决方案。因此，Venus进行了基于数据湖的架构改造，并推动日志入湖。入湖后，成本降低了70%，稳定性也大幅提升。本文主要介绍Venus从基于ElasticSearch的架构转向基于数据湖架构的思考及建设过程。

02

   Venus日志平台介绍

Venus是由爱奇艺自研的日志服务平台，提供日志的采集、处理、存储、分析等功能，主要用于公司内部的日志排障、大数据分析、监控报警等场景，整体架构如图1所示。

图1 Venus链路

本文重点讨论日志排障链路的架构演变，其数据环节包括：

• 日志采集：通过在机器、容器宿主机上部署采集Agent，收集各业务线前端、后端、监控等多种来源的日志，也支持业务自行投递符合格式要求的日志。部署了超过3万个 Agent，支持Kafka、MySQL、K8s、网关等10种数据源。

• 日志处理：日志收集后经过正则抽取、内置解析器抽取等标准化处理后以JSON格式统一写入Kafka，再由转存程序写入到存储系统中。

• 日志存储：Venus存储了近万个业务日志流，写入峰值超过1千万QPS，日新增日志超过500TB。随着存储规模的变化，存储系统的选型经历了从ElasticSearch到数据湖的多次变化。

• 查询分析：Venus提供可视化查询分析、上下文查询、日志大盘、模式识别、日志下载等功能。

为了满足海量日志数据的存储与快速分析，Venus日志平台经历了三次大的架构升级，从经典的ELK架构逐步演变到基于数据湖的自研体系，本文将介绍Venus架构转型过程中遇到的问题及解决方案。

03

   Venus 1.0：基于ELK架构

Venus 1.0 始于2015年，基于当时流行的ElasticSearch+Kibana搭建，如图2所示。ElasticSearch承担日志的存储与分析功能，Kibana提供可视化查询分析能力，只需要消费Kafka将日志写入ElasticSearch即可提供日志服务。

图2 Venus 1.0架构

由于单ElasticSearch集群吞吐、存储容量、索引分片数存在上限，Venus通过不断增加新的ElasticSearch集群应对不断增长的日志需求。为了控制成本，每个ElasticSearch的负载都在高位，索引配置的都是0副本，经常遇到突增流量写入、大数据量的查询、或者机器故障导致集群不可用等问题。同时由于集群上索引多、数据量大，恢复时间也很长导致日志长时间不可用，Venus的使用体验变得越来越糟糕。

04

   Venus 2.0：基于ElasticSearch + Hive

为了缓解Venus 1.0遇到的问题，Venus 2.0引入了Hive，架构如图3所示，主要改进点如下：

• 集群分级：将ElasticSearch集群分为高优和低优两类。重点业务使用高优集群，集群的负载控制在低位，索引开启1副本配置，容忍单节点故障；非重点业务使用低优集群，负载控制在高位，索引依然采用0副本配置。

• 存储分级：对于保存时间长的日志双写ElasticSearch和Hive。ElasticSearch保存最近7天的日志，Hive保存更长时间的日志，降低ElasticSearch的存储压力，也可降低大数据量查询将ElasticSearch打挂的风险。但是由于Hive无法做交互式查询，需要通过离线计算平台查询Hive中的日志，查询体验较差。

• 统一查询入口：提供类似Kibana的统一可视化查询分析入口，屏蔽底层ElasticSearch集群。在集群故障时将新写入日志调度到其他集群，不影响新日志的查询分析。在集群负载不均衡时，在集群之间透明调度流量。

图3 Venus 2.0架构

Venus 2.0是一种保障重点业务、降低故障风险与影响的妥协方案，依然有成本高、稳定性差的问题：

• ElasticSearch 存储时间短：由于日志量大，ElasticSearch只能存储 7 天，无法满足日常业务需求

• 入口很多，数据割裂：20 多个 ElasticSearch集群 + 1 个 Hive 集群，查询入口很多，非常不便于查询和管理

• 成本高：ElasticSearch虽然只存7天日志，依旧消耗了 500多台机器

• 读写一体：ElasticSearch服务器同时负责读写，相互影响

• 故障多：ElasticSearch故障占 Venus总故障 80%，故障后读写阻塞，容易丢日志，且处理困难

05

   Venus 3.0：基于数据湖的新架构

• 引入数据湖的思考

深入分析Venus的日志场景，我们总结其有如下特点：

• 数据量大：近万个业务日志流峰值千万QPS的写入，PB级的数据存储。

• 写多查少：通常业务在有排障需求时才去查询日志，大部分日志一天内都没有查询需求，整体看查询QPS也极低。

• 交互式查询：日志主要用于排障这种紧急、需要多次连续查询的场景，需要秒级的交互式查询体验。

针对使用ElasticSearch存储分析日志遇到的问题，我们认为其与Venus的日志场景并不十分匹配，原因如下：

• 单集群写入QPS和存储规模有限，需要多集群分担流量。需考虑集群规模、写入流量、存储空间、索引数量等复杂调度策略问题，增加了管理难度。由于业务日志流量差异大、不可预测，为解决突发流量对集群稳定性的影响，往往需预留较多空闲资源，导致集群资源极大浪费。

• 写入时做全文索引消耗了大量CPU，导致数据膨胀，造成计算存储成本大幅上升。在很多场景下存储分析日志所需的资源比后台服务资源还多。对于日志这种写入多、查询少的场景，做全文索引的预计算比较奢侈。

• 存储数据与计算在相同的机器上，大数据量查询或者聚合分析容易影响写入，造成写入延迟甚至集群故障。

为了解决上述问题，我们调研了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%，大幅节省运维人力。

06

   总结与规划

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

• Iceberg+Trino的数据湖架构支持的查询并发较低，我们将尝试使用Bloomfilter、Zorder等轻量级索引提升查询性能，提高查询并发，满足更多的实时分析的需求。

• 目前Venus存储了近万个业务日志流，日新增日志超过500TB。计划引入基于数据热度的日志生命周期管理机制，及时下线不再使用的日志，进一步节省资源。

• 如图1所示，Venus同时也承载了大数据分析链路的Pingback用户数据的采集与处理，该链路与日志数据链路比较类似，参考日志入湖经验，我们对Pingback数据的处理环节进行基于数据湖的流批一体化改造。目前已完成一期开发与上线，应用于直播监控、QOS、DWD湖仓等场景，后续将继续推广至更多的湖仓场景。详细技术细节将在后续的数据湖系列文章中介绍。

也许你还想看

爱奇艺数据湖实战

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

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