日志 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 支出降本的目标。