【Grafana】Grafana Mimir在海量时间序列指标中的优化

前言

事实上我也是最近看Grafana的博客时才了解到Mimir的。

Grafana Mimir 是 Grafana Labs 新开源的项目，用来为 Prometheus 提供持久化存储，开源许可协议是 AGPL-3.0。此前 Grafana 开源了 Cortex，但 Grafana Cloud 使用的还是内部商用的存储，因此 Grafana 团队需要维护两套代码。也许是维护两套代码太累了，所以干脆将 Grafana Cloud 使用的存储开源了，就是 Grafana Mimir。

Grafan给出了一些使用Mimir的原因：

• 100%和prometheus兼容；
• 多副本高可用
• 水平拓展、分片实现快速查询
• 多租户及资源隔离
• 分布式架构，动态拓展

未来Grafana还计划对更多的数据源进行兼容。

简单了解了Mimir，本文主要是阅读了开发团队发布的最新博文后写的，感兴趣的可以直接看原文，可能有些地方理解不够的或者理解有误的，还请指正：

原文地址: How Grafana Mimir’s split-and-merge compactor enables scaling metrics to 1 billion active series

正文

指标采集的挑战

大量数据的产生

根据原文所说，Cortex在进行指标拉取的时候所面临的一个挑战就是越多的指标需要越多的摄取组件实例，同时考虑到3副本的情况下，若每个摄取器能够处理1kw的时间序列，10亿的时间序列就需要300个实例；

OK，随着摄取器实例的增多，面临的新问题是这么多的实例，每2小时生成一个TSDB块，一天会新增3600个TSDB块，一天大约会产生20TB的数据；如此大体量的数据，使用Grafana进行可视化的时候会明显感觉到延迟，Mimir通过压缩解决了数据膨胀以及重复数据的问题；

块压缩缓慢

对于Cortex和Prometheus存在两个问题，第一个是数据块存储压缩流程，在Cortex中，压缩是单线程任务，因此这个过程会很慢，而且未压缩的块给查询器和存储网关增加了压力，而且它们的查询速度很慢；

TSDB的限制

另一个问题是，Prometheusde TSDB规则是总索引大小限制为64gib，每个索引段限制为4gib，上述压缩出来的块会打破这个限制。

Mimir的优化

特性一：对输入的块进行分组

针对上述的大量数据的问题，Mimir对输入的数据块进行了分组然后并行处理的方式，而不是一次性压缩所有摄入数据；例如，运行15个小的压缩，而不是一个包含300个块的大压缩，每个合并20个块，这虽然解决了大量输入数据的问题，但是大量数据中的重复数据删除并没有得到很好的处理；

特性二：对数据进行分片

在压缩过程中，Mimir会对指标序列进行分片，以达到将不同块中的相同序列压缩在一起的目的；这个过程中，输入数据会根据其hash值以及配置的输出块数量来进行分片，比如，原本压缩为一个输出块的情况，现在会压缩成3个，这将会避免超出Prometheus的TSDB限制：

整体来说，这样有三个好处：

• 可配置的分片数量允许容纳一个原先无法放入单个块的、非常大的活跃序列；
• 能够准确的知道每个block中存在哪些时间序列；
• 合并多个具有相同分片ID的块将会维持他们的分片ID，比如"5_of_32" ；

特性三：如何合并分片

上一部分提到过

并多个具有相同分片ID的块将会维持他们的分片ID

假设现在有一个块包含的时间跨度为6-8点，today from 6:00 to 8:00, with shard ID 5_of_32，另一个块包含的时间跨度为8-10点，today between 8:00 and 10:00, shard ID 5_of_32，可以将这两个块合并为一个更大的快，即today from 6:00 to 10:00, shard ID 5_of_32；

合并之后，对于这个块中包含的每个系列，属性series.hash() mod 32 == 5仍然有效，该功能允许将传统的块合并为多个分片的12小时或24小时块，这是一个可重复的操作，对相同的数据再做一次会产生相同的结果，也就是说多个摄取器拿到的数据做过合并后的块依旧是相同的副本

该设计保证了多副本的重复数据的清理能够有效进行，因为相同的数据一定存在于相同的分片中

此操作依赖于模操作，上文的mod为32，mod32的分片只能和mod32的合并，如果更改为mod48了，那就不能进行合并了，因为无法再保证数据存在于相同分片

Mimir如何进行压缩

说完了Mimir的一些优化特性，就开始看Mimir如何进行压缩工作了；对于Mimir来说，每个compactor(压缩器)会运行一个planner(计划器)，计划器会聚焦于存储载体上的所有可用块，找到需要被压缩的块，然后计算压缩工作。

压缩器会执行两种工作：

• Split Job：拆分工作，摄取器产生的块会先备份组，每个组的块稍后会被分别单独压缩（特性一），在这个压缩过程中，同时会对输出的块做分片（特性二）；
• Merge Job：合并工作会对相同分片的块做合并（特性三），如果一个块没有被拆分split，它将拥有一个可用于匹配和合并的空的分片ID；

每个压缩器实例运行的计划器会计算所有拆分和合并作业，这取决于计划器运行时存储块的当前状态。然而，一个压缩器实例只会运行器"拥有的"工作，这将取决于Mimir的hash环，具体可查看官网原文：Grafana Mimir hash rings

Grafana Mimir的拆分合并压缩器可以轻松地在许多压缩器实例中分配拆分和合并工作，加快整体压缩过程，简而言之：更多的压缩器，更快的速度！