导读:在Pinterest,开发人员依靠Statsboard来监控系统并发现问题,因此,可靠有效的监控系统对于开发速度来说非常重要。之前,Pinterest使用OpenTSDB来提取和提供指标数据。然而,随着Pinterest的发展,服务器也从数百个增加到数千个,每秒产生数百万个数据点,而且这个数字还在继续增长。

虽然OpenTSDB在功能上运行良好,但其性能随着Pinterest的增长而降低,导致运营开销(例如严重的GC问题和HBase经常崩溃)。为了解决这个问题,Pinterest开发了自己的内部时间序列数据库——Goku,其中包含用C ++编写的OpenTSDB兼容API,以支持高效的数据提取和成本昂贵的时间序列查询。

正文:

(使用Goku进行两级分片)

时间序列数据模型

时间序列数据

Goku遵循OpenTSDB的时间序列数据模型。时间序列由一个键和一系列时间数字数据点组成。key = metric name +一组标记键值对。例如,“tc.proc.stat.cpu.total.infra-goku-a-prod {host = infra-goku-a-prod-001,cell_id = aws-us-east-1}”。数据点=键+值。值是时间戳和值对。例如,(1525724520,174706.61),(1525724580,173456.08)。

时间序列查询

除了开始时间和结束时间之外,每个查询都由以下部分或全部组成:度量标准名称、过滤器、聚合器、降采样器、速率选项。

1)度量名称示例:“tc.proc.stat.cpu.total.infra-goku-a-prod”。

2)对标记值应用过滤器,以减少在查询或组中拾取系列的次数,并在各种标记上聚合。Goku支持的过滤器示例包括:完全匹配、通配符、Or、Not或Regex。

3)聚合器规定将多个时间序列合并为单个时间序列的数学方法。Goku支持的聚合器示例包括:Sum、Max / Min、Avg、Zimsum、Count、Dev。

4)降采样器需要一个时间间隔和一个聚合器。聚合器用于计算指定时间间隔内所有数据点的新数据点。

5)速率选项可选择计算变化率。有关详细信息,请参阅OpenTSDB数据模型(http://opentsdb.net/docs/build/html/user_guide/query/index.html)。

挑战

Goku解决了OpenTSDB中的许多限制,包括:

1)不必要的扫描:Goku用倒排索引引擎取代了OpenTSDB的低效扫描。

2)数据大小:OpenTSDB中的数据点是20字节。Pinterest采用Gorilla压缩来实现12倍压缩。

3)单机聚合:OpenTSDB将数据读取到一个服务器上并进行聚合,而Goku的新查询引擎是将计算迁移到更接近存储层的位置,该存储层在叶节点上进行并行处理,然后在根节点上聚合部分结果。

4)序列化:OpenTSDB使用JSON,当有太多数据点要返回时,JSON会很慢;Goku使用thrift二进制代替。

架构

存储引擎

Goku在内存存储引擎中使用了Facebook Gorilla来存储过去24小时内的最新数据。

(存储引擎简介。请查看Gorilla论文及其GitHub存储库来了解详细信息)

如上所述,在存储引擎中,时间序列被分成称为BucketMap的不同分片。对于一个时间序列,也被分为可以调整时长的 bucket(Pinterest内部以每2小时为一个 bucket)。在每个BucketMap中,每个时间序列都被分配一个唯一的ID并链接到一个BucketTimeSeries对象。BucketTimeSeries将最新的可修改缓冲区存储区和存储ID保存到BucketStorage中的不可变数据存储区。在配置存储 bucket 时间之后,BucketTimeSeries中的数据将被写入BucketStorage,变为不可变数据。

为了实现持久性,BucketData也会写入磁盘。当Goku重新启动时,它会将数据从磁盘读入内存。Pinterest使用NFS来存储数据,从而实现简单的分片迁移。

分片和路由

我们使用两层分片策略。首先,我们对度量名称进行散列,以确定某一时间序列属于哪个分片组。我们在度量名称+标记键值集上进行散列,以确定时间序列在所在组中的哪个分片。此策略可确保数据在分片之间保持平衡。同时,由于每个查询仅进入一个组,因此扇出保持较低水平,以减少网络开销和尾部延迟。另外,我们可以独立地扩展每个分片组。

查询引擎

倒排索引

Goku通过指定标记键和标记值来支持查询。例如,如果我们想知道一个主机host1的CPU使用率,我们可以进行查询cpu.usage {host = host1}。为了支持这种查询,Pinterest实现了倒排索引。(在Pinterest内部,它是从搜索项到位集的散列映射。)搜索项可以是像cpu.usage这样的度量名称,也可以是像host = host1这样的标记键值对。使用这个倒排索引引擎,我们可以快速执行ANDORNOTWILDCARDREGEX操作,与原始的基于OpenTSDB扫描的查询相比,这也减少了许多不必要的查找。

聚合

从存储引擎检索数据后,开始进行聚合和构建最终结果的步骤。

Pinterest最初尝试了OpenTSDB的内置查询引擎。结果发现,由于所有原始数据都需要在网络上运行,性能会严重下降,而且这些短期对象也会导致很多GC。

因此,Pinterest在Goku中复制了OpenTSDB的聚合层,并尽可能地早地进行计算,以尽量减少线上的数据。

典型的查询流程如下:

  • 用Statsboard客户端查询(Pinterest的内部度量监控UI)任何代理goku实例
  • 代理goku基于分片配置将查询扇出到同一组内的相关goku实例
  • 每个goku读取倒排索引以获取相关的时间序列ID并获取其数据
  • 每个goku基于查询聚合数据,如聚合器、降采样器等
  • 代理goku在收集每个goku的结果并返回客户端后进行第二轮聚合

性能

与之前使用的OpenTSDB / HBase解决方案相比,Goku在几乎所有方面都表现更好。

另一个在使用Goku前后高基数查询延迟对比图,如下图所示:

下一步

基于磁盘的长期数据存储

Goku最终将支持超过一天时间数据的查询。对于像一年这样的时长查询,Pinterest将不会过分强调一秒钟内发生的事情,而是关注整体趋势。因此,Pinterest将进行降采样和压缩,把以小时计的bucket合并为更长期的时长,从而减小数据量并提高查询性能。

(Goku 阶段#2——基于磁盘:数据包括索引数据和时间序列数据)

复制

目前,Pinterest有两个goku集群进行双行写入。此设置提高了可用性:当一个集群中存在问题时,可以轻松地将流量切换到另一个集群。但是,由于这两个集群是独立的,因此很难确保数据的一致性。例如,如果写入一个集群成功而另一个未成功时,则数据写入失败,数据由此变得不一致。另一个缺点是故障转移总是在集群层面发生。为此,Pinterest正在开发基于日志的集群内复制,以支持主从分片。这将提高读取可用性,保持数据一致性,并支持分片级的故障转移。

分析用例

所有行业都需要广泛的分析,Pinterest也不例外,例如面临询问实验和广告推广效果等问题。目前,Pinterest主要采用离线作业和HBase进行分析,这意味着不会有实时数据产生,并避免大量不必要的预聚合。由于时间序列数据的性质,Goku可以很容易地适应它,不仅可以提供实时数据,还可以提供按需聚合。

Pinterest表示将继续探索Goku的用例,如果你对此类项目感兴趣,请查看 https://careers.pinterest.com/careers/engineering

 

Comments are closed.