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

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即可提供日志服务。