10倍性能提升-SLS Prometheus 时序存储技术演进

可观测近年来一直是非常火热的话题，围绕着可观测国内外诞生了非常多的创业公司，包括老牌的监控、APM、日志厂商也纷纷进入，追求在一个产品上同时支持日志、监控、Trace等多种可观测能力。

回归到可观测概念的本质，是针对各类海量数据（Log/Trace/Metric…）进行的业务创新。而支撑数据创新的核心是一套稳定、强大、普惠的存储计算引擎。

相比业界使用多套方案（例如日志用ES、Trace用ClickHouse、Metric用Prometheus）实现统一的可观测上层能力，SLS则从数据引擎层开始针对所有可观测数据进行统一的架构设计。因此，我们在2018年在Log模型的基础上，发布第一版的PromQL语法支持，验证了PromQL的可行性。随后对存储引擎进行重新设计，能够在一套架构、一个进程内实现对Log/Trace/Metric的统一存储。

SLS时序引擎正式对外收费3年多来，我们对时序的整体架构进行了多次升级，本文将介绍近期SLS Prometheus存储引擎的技术更新，在兼容 PromQL 的基础上实现 10 倍以上的性能提升。同时技术升级带来的成本红利也将回馈给使用SLS 时序引擎的上万内外部客户。

1. 存储层针对时序场景优化格式，减少IO数量和压缩率
2. 在SLS集群Hold Prometheus计算引擎，用户不需要自己准备计算资源
3. 存储和计算层使用时序格式进行数据传输，提升传输效率

1. 快：数据规模超大的情况下，也能让点查的QPS足够高，同时范围查询的延迟进一步降低；
2. 简：使用上更加简单，不需要过多的手动优化，例如HashKey聚合写入、手动降采样、跨Store数据汇总等；
3. 省：降本增效同时进行，希望成本能够进一步下降，快的同时能够再省省；

1. 用户请求进入到任意一个计算节点时，若启动了Cache Feature，会根据Step进行Range修正；
2. 以修正后的Range访问SLS Cache Server，获取命中的Cache Range；
3. 对于没有命中的Range，向SLS后端查询数据并进行计算；
4. 拼接结果返回给客户端，同时将增量的计算结果更新到Cache中。

需要注意的是，这种方式相比标准的PromQL行为有一定的修改（只是会做Range对齐，其他计算逻辑没有修改），实际测试中Range是否对齐对于结果趋势几乎没有影响。我们在MetricStore的配置中，同时支持按照MetricStore开启或按需开启（请求的URL Param控制，例如）。

1. 用户请求进入到任意一个计算节点时，会根据一些策略（例如Query是否支持、用户指定开起、历史查询时间线较多等）决定是否使用并行计算；
2. 若判断使用并行计算，则这个计算节点升级为Master（虚拟角色），将Query进行并行拆分；
3. Master节点将子Query发送到其他Worker节点（虚拟角色）执行；
4. Worker节点执行子Query并将结果返回给Master；
5. Master最终汇总所有结果并进行最终的结果计算。

受限于PromQL的特性，并不是所有的Query都支持并行计算，也并不是所有支持并行计算的Query都能得到很好的效果。但我们分析了实际线上的请求，90%以上都能支持且得到加速。

1. 使用标准的Prometheus Golang计算引擎，支持的Query最丰富，但还是避免不了序列化、反序列化开销；
2. 使用C++实现Prometheus的部分算子，直接在C++侧执行，避免序列化/反序列化的同时，还可以减少GC开销；

• 需要注意的是，计算下推的前提是同一时间线的数据必须存储在一个Shard上，即需要开启聚合写入的功能或者使用SDK手动写入。

1. 用户使用ScheduledSQL功能，定期查询原始指标库，保留最新的/平均值作为降采样的值，存储在新的MetricStore；
2. 查询时，判断查询区间适合的MetricStore，如果是降采样的MetricStore，在查询前还需进行一定的Query改写；
1. 例如降采样的精度是10min，查询是 avg(cpu_util)，由于默认是3分钟的LookBackDelta，10分钟的精度可能查询不出来，因此需要改成 avg(last_over_time(cpu_util[15m]))。

1. 用户对降采样库，只需要配置降采样的间隔和指标存储时间即可；
2. 内部SLS会定期将数据按照配置进行降采样（保留降采样范围内最新的点，相当于last_over_time）并存储到新的指标库；
3. 查询时，会根据查询的Step和时间范围，自动选择适配的指标库；
1. 例如指标精度分别为1m、10m、1h，Step为30m则会选择10m的库；
2. 例如原始指标库只存3天，降采样存30天，查询7天则会选择降采样库；
4. 如果查询降采样库，SLS计算引擎会自动对Query进行改写或对数据进行拟合计算，无需手动修改Query；

1. Union MetricStore 支持关联同一账号下多个Project、MetricStore；
2. Union MetricStore 支持完整的PromQL；

• 注意：由于合规问题，UnionStore并不支持跨国的Project。

• 上述是在4万条左右时间线下，SLS不同计算模式的性能对比；
• 受限于本地浏览器->Grafana后端 -> SLS后端的网络延迟，带cache的功能看起来还是有略微延迟，实际如果命中缓存时后端延迟在微秒级别；

• 上述是在最高200万+时间线下，SLS不同计算模式的性能对比；
• 200万+时间线情况下，SLS 普通模式报错原因：防止一个Query直接把标准Prometheus计算节点打OOM；

• 注意：测试时，我们并没有打开全局Cache和降采样的功能，主要是这两个场景在命中时的性能提升过于巨大，放到同一象限进行对比意义不大。
• 注意：上述SLS的并行计算和计算下推的PromQL还是完全兼容PromQL语法，兼容性测试通过率为100%，下述是市面上开源、商业版Prometheus的兼容性结果

• 开源数据源：Prometheus Benchmark

• Prometheus：单机部署在一台32C128G ECS，存储PL1 ESSD
• Thanos：相关组件部署在5台32C128G ECS，存储PL1 ESSD + OSS
• VictoriaMetrics：相关组件部署在5台32C128G ECS，存储PL1 ESSD
• SLS：三个不同场景，分别为4、16、64个Shard

• 100 Target：同一时刻时间线上限 2.56W，汰换率 1%（每10分钟更新一次）
• 1000 Target：同一时刻时间线上限：25.6W，汰换率 40%（每10分钟更新一次）
• 5000 Target：同一时刻时间线上线：128W，汰换率 80%（每10分钟更新一次）
• 注意：汰换率用于表示指标更新速度，在传统场景通常变化不大，但在微服务、云原生、机器学习等场景，由于Pod、服务、Job 等生命周期短且会动态变化（每次生成一个新的 ID，也即新的时间线），指标汰换速度都会特别快（相关概念和时间线膨胀基本一致）

• sls-normal：SLS Prometheus引擎基础版本，即完全使用开源Prometheus的计算引擎，存储用SLS；
• sls-parallel-32：SLS Prometheus并行计算版本，32个并发度的并行计算（计算引擎还是开源Prometheus）；
• sls-pushdown：SLS 计算下推版本，常见Query使用C++实现的Prometheus计算引擎。

1. 得益于使用自有逻辑实现了PromQL（兼容性较低），VictoriaMetrics整体的性能都还不错，尤其是时间线少的情况下，延迟很低；
2. sls-normal版本由于和开源Prometheus使用相同计算引擎且都是单协程计算，两者性能基本一致；
3. thanos相对更关注在分布式的解决方案，PromQL计算性能较一般，大Query会超时或者OOM掉；
4. sls-pushdown在超大规模时间线下提升较为明显，整体相比sls-normal版本都有10倍以上的提升（完全下推场景下实际会有百倍的性能提升）；

后续会有详细的测试报告发出，本文就不多占篇幅

1. 聚合写入：通过聚合写入，大大节省了SLS后端存储、计算资源，单位数据下的成本更低；
2. 降采样：通过降采样配置，高精度时序数据无需长期保存，整体成本下降明显；

注意：价格调整相关工作正在进行中，敬请期待。