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