聊聊日志硬扫描，阿里 Log Scan 的设计与实践

日志 Scan 的发展与背景

大数据快速增长的需要

泛日志（Log/Trace/Metric）是大数据的重要组成，伴随着每一年业务峰值的新脉冲，日志数据量在快速增长。同时，业务数字化运营、软件可观测性等浪潮又在对日志的存储、计算提出更高的要求。
从时效性角度看日志计算引擎：数仓覆盖 T + 1 日志处理，准实时系统（搜索引擎、OLAP） 瞄准交互式场景，实时需求则加速了 Flink 等流引擎的发展。

再回到用户场景角度，各式各样的数据呼唤多种计算模式，例如本文要讨论的日志搜索场景

• 业务日志搜索、高频词查询：使用全文索引技术，期望低延时。
• 低频日志搜索、schema 不固定场景：通过 Scan（硬扫描）方式实现不依赖 schema（索引结构）的搜索，灵活但延时有所上升。

schema-on-read 技术的发展

顾名思义，Scan 模式过数据硬算，给人第一印象是慢。近些年随着新技术的应用，Scan 模式的性能表现在今天已经得到较大提升：

• 硬件层面：计算资源更加易得，云服务器、K8s 等广泛应用，为软件层提供按需算力布置、弹性扩缩的支持，从而保证了 Scan 对于爆发算力的需求供应。
• 软件层面：一方面是语言的变化，大数据软件过去以 Java 系独大，今天有 ClickHouse、Photon（Databricks）、Velox（Presto）等 C++ 引擎，0-GC、SIMD 加速等技术加持让软件效率得到飞跃。

另外，schema-on-read 技术对 non-schema 有很大的包容性，无需复杂的前期业务规划，其应用的典型场景有：数据湖，日志搜索、分析。

开源日志系统的进展

ELK 是老牌的日志套件 ，Elasticsearch 基于 Lucene 构建倒排索引、DocValue 分别提供搜索、分析能力，性能表现不错，但存储膨胀比例高。

再来看近两年新流行的日志搜索软件：

• PLG：中间的 L 是 Grafana 公司开源的 Loki，其主要思想是用“Label Index + 暴力搜索”来解决大规模日志查询问题，存储膨胀比例很低。
• ClickHouse：以列式存储为基础，选配稀疏索引，用高性能的算子实现，也被用于一些日志 Scan 搜索场景。

日志服务对客户需求的思考

阿里云日志服务（SLS） 为 Log/Metric/Trace 等数据提供大规模、低成本、实时的平台化服务，是目前国内领先的日志套件产品。

SLS 在为公共云数十万客户提供日志服务，并支撑阿里、蚂蚁集团日志基础设施的多年来，通过高性能的索引技术为用户提供亿级秒查能力。

“增效降本”是软件服务的长期价值，也是当前企业客户的客观需求：

• 增效

从数据特性上看，日志打印格式较难统一（尤其是程序日志）。例如，在一个日志文件里出现多个模块的日志内容，有些行包括 a/b/c 三个字段，另一些行是 b/d/e/f/g 五个字段，甚至一些行的内容字段无法确定。面对如此弱 schema 日志，基于字段索引方案，很难在一开始把所有的索引 key 枚举完整，导致在查询时找不到数据。
注：虽然 SLS 提供索引重建功能，这一过程较耗时也花费成本，应对 schema 不确定的情况时，频繁索引操作是一种运维负担。

• 降本

一些日志是写多查少的，数据量很大，从业务上判断可能每周只查一两次。使用者优化日志费用的手段是：在全量索引基础上去掉 50% 不常用的字段索引，达到费用下降近半、高频字段保留低延迟搜索功能的效果。但对于低频字段数据的偶尔查询，没有高效的办法。

SLS 新推出 Scan 功能，让未索引的字段也支持搜索（硬扫描模式），节省全量索引产生的构建和存储费用，同时 Scan 的运行时计算模式对于杂乱结构的日志数据有更好的适配，帮助企业客户实现数字化增效、IT 支出降本的目标。

SLS Scan 能力设计

沿主干树加“技能”点

Grafana Loki 在 2019 年提出区别于 ES 的日志查询方案，是 Sca