SLS 查询新范式：使用 SPL 对日志进行交互式探索

1. 引言

在构建现代数据和业务系统的过程中，可观测性已经变得至关重要，日志服务（SLS）为 Log/Trace/Metric 数据提供了大规模、低成本、高性能的一站式平台服务，并提供数据采集、加工、投递、分析、告警、可视化等功能，从而全面提升企业在研发、运维、运营和安全等各种场景的数字化能力。

1.1 日志数据天然是非结构化的

日志（Log）数据作为可观测场景中最基础的数据类型之一，其最大的特点在于，日志数据是天然是非结构化的，具体与多种因素有关：

• 来源多样性：日志数据种类繁多，不同来源的数据难以具有统一的 Schema
• 数据随机性：比如异常事件日志、用户行为日志，往往天然就是随机的，难以预测的
• 业务复杂度：不同的参与方对数据的理解不同，比如开发流程中打日志的一般是开发者，但分析日志的往往是运营和数据工程师，写日志过程中难以预见到后期具体的分析需求

这些因素导致很多情况下可能并不存在一个理想的数据模型可以用来预先处理好日志数据，更常见的做法往往是直接存储原始数据，这可以称为是一种 Schema-on-Read 的做法，或者是所谓的寿司原则（The Sushi Principle：Raw data is better than cooked, since you can cook it in as many different ways as you like）。而这种“杂乱无章”的原始日志数据也给分析人员增加了难度，因为往往是需要对数据模型具有一定的先验知识，才能对数据进行比较好的结构化分析。

1.2 来自 Unix 管道的启发：交互式探查

在各种日志分析系统与平台出现之前，开发运维人员最传统的日志分析方式，是直接登录到日志文件所在的机器上去 grep 日志，并配合一系列 Unix 命令对日志进行分析处理。

比如要查看访问日志中 404 的来源 host，可能就会用到这样的命令：

grep 404 access.log | tail -n 10 | awk '{print $2}' | tr a-z A-Z

这条命令中通过 3 个管道操符，将 4 个 unix 命令行工具（关键词查找、日志截断、字段提取、大小写转换）连成了一条完整的处理栈。

值得注意的是，在使用这样的命令的时候，我们往往并不是一次性就写出完整的命令，而是写完一个命令之后就按下回车，观察执行输出的结果，然后再通过管道追加下一步的处理命令，继续执行，如此一直进行下去。

这个过程中充分体现了 Unix 的设计哲学，通过管道将一个个小而美工具组合成强大的程序。同时从日志分析的角度看，我们可以获得这样的启发：