Scheduled SQL： SLS 大规模日志上的全局分析与调度

简介： 本文总结了大规模日志全局分析的需求，讨论SLS上现有的典型分析方案，并延伸到 SLS 原生数据处理方案，介绍 Schedueld SQL 功能与最佳实践。

大规模日志全局分析的需求

数据大规模与时效性

基于时间的数据（日志、指标）在日积月累后的数量是惊人的。以 SLB 七层访问日志为例，每一个HTTP/HTTPS 访问请求会记录一条 access log，假设每天产生1000万条数据，则一年为36亿条数据。一方面，长时间的数据存储需要巨大的存储空间，而通过减少存储周期的方式降低存储空间，虽然控制了存储成本，但也丢失了有价值的历史数据。另一方面，大量的数据将造成分析上的性能压力。

大部分时序数据具有时效性特征。历史数据可以接受分钟或小时级别的精度，而新产生的数据需要更高的精度（例如监控、线上问题调查）。数据运营、分析师需要存储全量的数据以备分析，历史数据直接 TTL 删除是可能最差的选择。

例如 Elasticsearch rollup、时序数据库的降精度用于解决这部分问题。

一份数据在多种场景使用

对于同一份日志，可能被多种用户角色在多种场景下使用到：

• 实时的数据，需要支持关键词告警、时序数据 ML 巡检、日志上下文查询。
• 亚秒级延迟粒度上，有全文关键词的查询、交互式 SQL 统计分析的需求。
• 以天为单位，需要对日志做运营分析，计算转化率、设计运营策略。
• 一周前的产生的数据，大部分时候不再会被触碰到，在支持偶尔的历史指标查看以外，审计场景下对全量日志的存储也是必须项。

一份数据，多处使用，既要满足业务需求，成本也是需要关心的。

自定义业务分析

云上日志设施面对的客户群呈现多样化，自定义的业务需求举例如下：

• 电商：计算七日留存率，业务访问 SQL 审计日志对用户信息脱敏，等等。
• 在线教育：多平台终端（android、ios、PC）埋点数据的规整，直播课堂生命周期内的异常诊断，等等。
• 游戏：按游戏的数据分发存储，全文搜索支持工单调查，等等。

阿里云 SLS 是云原生观测分析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务，一站式提供数据采集、加工、分析、告警可视化与投递功能。我们将以业务为目标的数据处理归纳为两类需求：

• ETL：将非结构化的日志做预处理，为日志信息添加业务字段，数据脱敏与分发等。
• 分析：全局数据大表上的查询和 SQL 分析，支持布尔搜索、window、aggregate 操作等。

SLS 上的典型分析方案

对于 ETL、分析这两类计算任务，除了交互式分析以外，还需要常驻作业模式来处理结果落盘。

根据不同的业务需求，这里总结了几种常见的 SLS 数据分析方案。

数仓 "T+1"

对于结果实时性不敏感的业务，有较多采用数仓方案：

1. 数据通过 SLS 实时入库，集中化存储。
2. 全托管数据投递到 MaxCompute。
3. 业务规划小时级或天级的计算任务，生成下游表，产出业务报表等结果。

流计算

以 Flink、Spark Streaming（continuous mode）、Kafka Streams 为代表的实时计算系统，在数据处理语义（exactly-once）、计算结果修正上的能力强大。该方案会用到 SLS 百 ms 秒级端到端延迟的 pub/sub 能力：

1. 数据实时推送到 SLS 日志库。
2. 启动流计算任务，从多个 shard 实时消费数据。
3. 流计算任务根据算子组合情况（stateless、statefull、groupby 等）切分多个拓扑执行，可能涉及到数据 shuffle、watermark、state store 等机制。

这个方案在算子丰富度、实时能力、性能上综合表现全面，是一把牛刀，例如在电商实时大屏场景上是非常好的选择。

如果抱着挑刺的眼光来看：

• 计算引擎层面做得均衡，但缺乏存储层的优化。例如：一个 logstore 上运行 10 个流计算作业，无论实际需要纳入计算范围的数据有多少，最终需要 10 遍全部数据流量的订阅，从业务角度上看存在网络、计算资源上的浪费。
• 对于日志用户来说，在参数配置、性能调优、问题 Debug 有复杂性ÿ