Pinterest从OpenTSDB切换到他们自己的时间序列数据库

从2014年开始，Pinterest工程团队就一直使用 OpenTSDB 存储和查询指标。由于指标数据量的增长导致了各种性能问题，所以他们使用C++开发了自己的时间序列数据库 Goku ，并且兼容OpenTSDB API。

Pinterest开发团队使用一个名为Statsboard的系统——这是一个仪表板，使用YAML中的声明式配置集成了来自Graphite、 Ganglia 和OpenTSDB的指标。早在2012年，Pinterest的监控使用了Ganglia，它只收集系统指标而不收集任何应用程序指标。那年年底，他们 部署了Graphite 以及statsd，用于收集应用程序指标，然后部署了一个Graphite集群。2014年，他们部署了OpenTSDB以及一个自定义指标代理，把数据推送到Kafka集群，然后从那里通过一个处理管道推送到 OpenTSDB和Graphite 。几年前，他们在OpenTSDB中已经达到了每秒150万点的吞吐量。Pinterest的团队面临着 Java 垃圾收集问题以及HBase频繁崩溃，OpenTSDB把它作为后端存储。这里有一点需要注意，Pinterest有一个 规模很大的HBase部署 ，供他们的许多服务使用。

他们自主开发的时间序列数据库引擎Goku试图改进OpenTSDB中的某些具体方面，其中包括使用一个反向索引代替HBase扫描、更好的数据点压缩、集群聚合查询以及更快的序列化格式。Goku使用 Facebook Gorilla 内存存储引擎存储最新数据，持久存储在NFS上。Pinterest 托管在EC2上 ，但是，文中并没有清楚说明，他们是否使用了AWS EFS或自托管解决方案。作者提到，Goku会在重新启动时把数据从磁盘读回到内存中。

Goku的查询模型和OpenTSDB的完全一样。其团队编写了自己的查询聚合层，向分片扇出查询或聚合分片查询。Goku使用了一种两层分片策略——基于指标名称，然后是标签键-值对。这些查询由Goku代理处理，它会把查询发送给单个的Goku分片。这些分片使用反向索引取得请求的时间序列的ID，并获取数据，运行单个的聚合器（下采样、求和等），然后发回代理。该代理会在第二轮聚合之后把它发给客户端。Goku的另一项改进是使用Apache Thrift的 二进制数据类型 代替了OpenTSDB的JSON格式。

Pinterest使用Goku降低了延迟、资源需求以及数据集规模。Goku是用C++编写的，兼容 OpenTSDB API 。Goku和Pinterest另外一个名为 Yuvi 的项目非常类似，那个项目是用Java编写的。其他工程团队也编写或定制了他们自己的时间序列指标集和查询系统，包括Vivint、 Uber 、 Improbable 和 Criteo 。

查看英文原文： Pinterest Switches From OpenTSDB to Their Own Time Series Database