Page 81 - 《软件学报》2021年第5期

尤勇 等:一种监控系统的链路跟踪型日志数据的存储设计 1305

1.3 难点与挑战
CAT 的日志数据同样也是一种链路跟踪型日志数据.在美团的线上真实环境中,一条 LogView 日志数据单
条字节量可能仅几十字节,也可能达到几兆字节;并且在美团线上服务中,CAT 所监控的所有软件系统每秒产生
的 LogView 日志达到了百万条.所以,如何对海量日志数据进行分布式存储、如何提高存储效率、如何节省磁
盘空间以及在查询时如何快速获取日志数据,都是存储设计方案所面临的难点与挑战.此类型链路跟踪型数据
存在以下两点特征.
• 具有唯一的 id 标识;
• 单条日志数据的字节量相差很大,单条 LogView 字节量最小仅几 KB,最大可达几 MB.
本文存储方案考虑将 id 标识值利用起来创建索引结构,并通过数据文件存储日志数据、索引文件存储索
引信息的方式来实现.此外,在真实的线上业务需求中,在 LogView 的写入与查询方面具有不同的性能要求,同样
也是设计的挑战.
• LogView 写入.在美团的真实业务中,每秒产生的 LogView 量可达上万条,所以要求存储方案在存储方
面具备较高的 TPS(transaction per second),例如:通过批量写入来减少磁盘 IO 以提高写入效率,使得存
储方案的写入性能满实际的业务需求.
• LogView 查询.相对于 LogView 高频的写入操作,LogView 的查询操作是偶发的、离散的.偶发性:日志
查询请求的频率是相对很低的,在实际业务中查询完整 LogView 的请求每秒仅上百次;离散性:在较小
时间窗口内,对同一条 LogView 进行查询操作的情况很少发生.所以对于查询并不要求很高的性能,只
要求单次查询能够在 100ms 内完整获取到原始的 LogView 数据即可.
2 相关技术方案分析

本节主要对现有的存储方案进行分析,以及分析可选的主流索引结构的优缺点,提出了本文存储方案的各
项设计目标.
2.1 现有存储方案
LogView 日志在生成时,会创建一个全局唯一的 id 值,用于区分每一条日志.同时也需要注意:线上实际业务
中,每天 LogView 数据量会达到上百 TB;另一方面,为了方便业务进行故障定位和复盘,数据至少需要保存 2 周
时间,这样就需要维护 PB 级数据量的存储和查询.下面介绍几种主流的数据库以及日志存储方案,并根据日志
的数据特征解释它们是否适合 LogView 存储.
2.1.1 MySQL
MySQL [10] 是目前主流的关系型数据库管理系统,默认使用 Innodb 存储引擎,通过建表的方式存储数据.如
果使用 MySQL 存储 LogView 日志数据,建表时需要创建“id”字段与“日志数据”字段,存储日志数据时,以行的格
式插入 LogView 的 id 值与对应的字节数即可,并使用 id 字段作为主键创建索引以提高查询的效率.如使用
VARCHAR 类型存放 LogView,在 MySQL 5.7 版本中,每行最大可存放 65 535 字节(即 64KB)数据.而 LogView
日志的数据最大字节量可达 MB 级别,64KB 大小的空间无法满足所有日志数据的大小,此类型数据不合适存储
LogView 数据.
MySQL 提供了 Blob 与 Text 类型两种类型的数据 [11] ,存储大对象与字符串类型的数据.此类型的数据原则
上可以用于存储 LogView 数据,但是前面提到:在实际业务中.LogView 每天写入会达到上百 TB 数据量,高峰期
的 TPS 超过百万.为了应对这种大流量的数据写入,使用 MySQL 必然需要进行分库分表,并且搭建多个存储集
群来支持,同时也需要维护一套分库分表的策略关系,在储存进行扩容或者缩容时,需要做好历史数据访问的兼
容,增加整个系统搭建成本和复杂度;另一方面,MySQL 应对的储存场景比较丰富,支持数据的增删改查、事务
等,所以 MySQL 整个架构的设计就比较复杂,并且数据存储时会自动额外增加很多隐形字段来支持实时的删
除、修改.对于 LogView 的存储场景是不涉及数据的修改和删除,MySQL 提供的诸多能力对于此种场景是一种