日志查问形式 SLS SPL 更快更强 推出高性能

随着数字化进程的继续深化，可观测性不时是近年来十分炽热的话题，在可观测的三大支柱 Log/Trace/Metric中，日志（Log）数据普通是最为经常出现的，企业迈向可观测性的第一步，也往往始于日志数据的采集上云。日志成功搜集后，最间接的需求就是从海量日志数据中检索剖析出有价值的消息。随着日志数据量的不时增长，数据种类不时增多并日益朝着非结构化、多场景、多模态等方向演进，传统的日志搜查形式曾经越来越难以满足不同场景下多样化、共性化的剖析需求。

日志数据的查问剖析需求是多样化的

日志（Log）数据作为可观测场景中最基础的数据类型之一，具有以下特点 ：

这些起因造成日志数据在采集环节中往往并不存在一个现实的数据模型可以用来预处置日志数据，因此更经常出现的做法是间接采集存储原始的日志数据，这可以称为是一种 Schema-on-Read 的形式，或许是所谓的寿司准则（The Sushi Principle：Raw>

弱，关键就是允许关键词婚配

强，具有丰盛的处置函数和算子，如正则婚配、json提取

输入内容是非结构化的

强，输入的是原文，便于检查

弱，输入的是表格形式，不存在的字段所有要补空值，不利于检查

方便，控制台可以间接点，API传递offset+lines即可

较复杂，要求在SQL中经过limit x,y的形式，并且要指定排序形式

方便，histogram柱状图直观展现出不同时期的散布

较复杂，要求在SQL中依照时期分组求和，再按时期排序，而后再画线图检查

结果中输入一切原文字段

输入的是原文，自然蕴含一切字段

较费事，select * 只能输入建了字段索引的列

可以经过with语句、SQL嵌套，但写起来较为复杂

既然两种形式各有千秋，那么咱们能否可以结合这两种形式的好处，允许一种新的查问语法，既能听从文档模型（间接输入日志原文、不按表格形式、不要求一切输出列有索引），又能允许各种好用的 SQL 算子，同时还能够允许一种更方便的级联处置（而不要求复杂的多层嵌套）呢？

SPL（详见SPL 概览[1]），即 SLS Processing Language，是 SLS 对日志查问、流式生产、数据加工、Logtail 采集、以及数据 Ingestion 等要求数据处置的场景，提供的一致的数据处置语法。

其中 <data-source> 是数据源，关于日志查问的场景，指的就是索引查问语句。<spl-expr> 是 SPL 指令，允许正则取值、字段决裂、字段投影、数值计算等多种丰盛的操作，详细参考 SPL 指令引见。

从语法定义上可以看到，SPL 是允许多个 SPL 指令组成管道级联的。关于日志查问的场景来说，在索引查问语句之后，可以依据要求经过管道符不时追加 SPL 指令，从而取得相似 Unix 管道处置文本数据的体验，对日志启动灵敏的探求式剖析。

挑选字段取得更准确的视图

在查问日志的时刻，往往是带着某个目的去检索，这个时刻普通是只关心其中的局部字段。这时就可以经常使用 SPL 中的 project 指令，只保管自己关心的字段。（或许经常使用 project-away 指令，移除不要求看到的字段）

经常使用 Extend 指令，可以基于已有字段加工提取出新的字段，可以经常使用丰盛的函数（这些大局部是和 SQL 语法通用的）启动标量处置。

Status:200 | extend urlParam=split_part(Uri, '/', 3)

同时也可以依据多个字段计算出新的字段，比如计算两个数字字段的差值。（留意字段自动是被视为 varchar，启动数字类型计算的时刻要先经过 cast 转换类型）

Status:200 | extend timeRange = cast(BeginTime as bigint) - cast(EndTime as bigint)

并且也可以在后续管道中，再对这个计算后的值启动 where 判别过滤：

Status:200| where UserAgent like '%Chrome%'| extend timeRange = cast(BeginTime as bigint) - cast(EndTime as bigint)| where timeRange > 86

自在的开展半结构化数据

SPL 提供了 parse-json、parse-csv 这样的指令，可以将 json、csv 类型的字段，间接齐全开展出为独立的字段，之后就可以间接对这些字段启动操作。省去了书写字段提取函数的开支，在交互式查问场景中这种写法是更为方便的。

SPL 之前曾经在扫描查问形式上全地区允许，详见扫描查问。扫描查问可以不依赖索引，间接扫描原始日志数据计算。下图中这个例子，就是在原始日志数据上，经过 SPL 管道成功了含糊过滤、json 开展、字段提取等多种操作。

扫描形式 SPL 难以处置大规模数据

扫描形式具有很好的灵敏性，但最大的疑问是性能无余，特意是面对大规模数据时难以在有限时期内处置完。现有的扫描查问限度单次最多扫描 10 万行，超出限度后要求控制台手动点击触发下一次性扫描（或许 SDK 触发下一次性调用）。

由于性能受限，造成现有的 SPL 查问在经常使用上存在以下疑问：

这些解放，造成扫描形式下的 SPL，面对具有较大规模的日志数据，经常使用体验较差，也就很难施展出实践用途。

为了从基本上改善 SPL 查问的口头性能，真正施展出 SPL 灵敏计算的好处。咱们从计算架构、口头引擎、IO 效率等多个方面对 SPL 查问启动了严重优化。

首先要在架构上处置水平扩大的疑问。原有的架构下，由于存储节点不具有复杂表白式的计算才干，只能将原始数据全量拉取到计算节点处置，大数据量的读取、传输、序列化是很大的瓶颈。

在查问场景下，实践单次恳求每次要求的最终结果行数是比拟少的（普通单次恳求 100 行以内，超出后经过翻页恳求失掉），关键在于当 SPL 语句中蕴含 where 条件的时刻，就存在从少量数据中计算 where条件过滤的环节。为了能够处置大规模数据并缩小传输开支，咱们就要求将 where 条件的计算下推到各个 shard所在的存储节点上处置。相应的，也就必定要求存储节点具有对 SPL 中丰盛算子的高效处置才干。

为此咱们在存储节点上，引入 C++ 向量化计算引擎，在存储节点上读取了原始的数据后，间接原地就可以启动高效的过滤计算。只要对满足 where 条件的日志，才要求启动残余的 SPL 计算并输入最终结果。

计算下推之后，整个的处置才干就可以随着 shard 数目水平扩大，同时也大幅缩小了存储节点和计算节点之间的数据传输、网络序列化开支。

向量化计算，多级火箭减速

计算下推处置了按 shard 水平扩大的疑问，接上去咱们还要进一步的大幅优化每个 shard 上的处置才干。

扫描形式的 SPL，最大性能瓶颈还是在于间接扫描读取原始的行数据。这样读加大会比拟严重，IO 效率很低。正如经常使用 SQL剖析才干时要求开启字段索引（并开启统计），这些字段的数据就可以被高效的读取和计算，那 SPL 雷同也可以基于字段索引来启动高性能的数据IO，而后再基于 SIMD 向量化技术启动高性能计算，同时在环节中尽或许缩小额外计算量。

以图中的 SPL 为例，在下推到存储节点后，会经过“多级火箭”启动层层减速：

经过这些优化之后，高性能 SPL 的口头性能相比扫描形式，失掉了质的飞跃。

咱们以单个 shard 处置 1 亿行数据为例，来评价高性能 SPL 的性能体现。在线上实在环境创立一个 Logstore，10 个 shard，查问时期范围内有 10 亿数据。（服务访问日志数据）

选取如下几个典型的场景：

场景 1：经过字符串函数处置后过滤

场景 2：短语查问、含糊查问

场景 3：json提取子字段，而后再过滤

在上述语句当选用不同的比拟参数，结构出不同的命中率的场景（比如命中率 1%，指的是原始 10 亿条数据中，有 1000 万条满足 where 条件的结果数据），并恳求前 20 条满足条件数据（对应 GetLogs 接口的 API 参数是 offset=0, lines=20），测试平均耗时。

控制台交互更新，展现过滤后结果的直方图

高性能形式 SPL，由于计算性能有了大幅优化，因此控制台展现 histogram，间接展现的是整个 SPL 语句过滤后的结果散布。（象征着整个范围内的数据也启动了全量的计算）

相应的，和纯索引查问形式下的交互齐全相反，高性能形式 SPL 允许随机翻页，也允许点击柱状图间接跳转到对应区间的查问结果。

在高性能 SPL 形式下，调用 GetLogs 经过 SPL 语句查问日志时，offset 间接示意的就是过滤后的结果偏移量，从而大大简化了 API 调用形式。也就是说，经常使用上，和纯索引查问齐全一致。间接依照过滤后最终结果的 offset 来翻页即可。

毋庸显式指定运转形式。当 SPL 语句中一切介入 where 条件计算的列，全都曾经创立了字段索引（并开启了统计），则智能依照高性能形式口头；否则以扫描形式口头。

高性能 SPL 形式，查问自身不发生任何额外费用。

假设没有齐全命中索引列造成走的是扫描形式 SPL（并且 Logstore 是按配置计费形式），则依照查问环节中的扫描原始日志数据量计费。

尽或许参与索引查问语句预过滤

假设无关键词索引过滤条件，尽或许经常使用，放在多级 SPL 管道的第一级。索引查问的效率总是最高的。

复杂过滤场景，倡导经常使用 SPL 替代 SQL

特意是关于含糊婚配、短语婚配、正则婚配、json 提取以及更复杂的各种纯过滤场景，以前只能经常使用 SQL 语法（* | select * where XXX），如今倡导交流为 SPL 语法（* | where XXX）。可以能更好的输入日志原文（而不是表格形式），更方便的看到过滤后的结果柱状图散布，以及更繁复的输入体验。

目前 SPL 仅允许纯查问过滤场景下的经常使用，接上去在日志查问场景下，SPL 语法会进一步允许排序、聚合等操作（聚合后依照表格形式输入），从而使得 SPL 的多级管道级联处置才干更弱小、更完善，能够更好的对日志启动更灵敏的查问剖析。

企业的日志数据上云后，从海量日志中搜查出想要的消息，是一项最基本的需求。SLS 推出 SPL 查问语法，允许相似 Unix 管道的级联语法，并允许 SQL的各种丰盛的函数。同时，基于计算下推、向量化计算等优化，允许高性能形式 SPL 查问，可以在数秒内处置亿级数据，并且允许 SPL过滤后最终结果的散布直方图、随机翻页等特性，具有和纯索引查问形式相似的体验。关于含糊、短语、正则、json 提取以及各种复杂过滤场景，介绍经常使用SPL 语句来启动查问。

高性能形式 SPL 目前正在按区域逐渐颁布中，有任何经常使用上的疑问或许需求，可以经过工单或许间接在 SLS 的钉钉群咨询。SLS 会不时继续不时的优化，提供更弱小、更好用的可观测存储剖析引擎。