Criteo使用Cassandra存储后端实现Graphite的规模化

系统架构

摘要： Criteo公司SRE团队的一位成员在上个月召开的FOSDEM大会上做了一个演讲，介绍了他们如何使用Cassandra作为存储后端实现Graphite产品的规模化安装。为实现容错和弹性扩展，Criteo工程团队编写了一个称为“BigGraphite”的Graphite用户化插件，替代了Cassandra默认使用的WhisperDB。

作者： Hrishikesh Barua

正文：

Criteo公司SRE团队的一位成员在上个月召开的FOSDEM大会上做了一个演讲，介绍了他们如何使用Cassandra作为存储后端实现Graphite产品的规模化安装。为实现容错和弹性扩展，Criteo工程团队编写了一个称为“BigGraphite”的Graphite用户化插件，替代了Cassandra默认使用的WhisperDB。

Criteo需要解决容错和弹性扩展问题，这是已被分布式数据库解决的问题。Criteo团队决定使用Graphite的插件架构，编写支持使用Cassandra为存储后端的定制插件。该插件作为“BigGraphite”项目开源。项目在设计中考虑了支持多种后端，但是目前只提供对Cassandra的支持。

Whisper是Graphite推出的默认数据库，它采用固定大小的文件存储数据。文件的大小固定，因为Graphite在存储数据时指定了一个预先配置的保留期限，通常更旧的数据以更低的采集频率存储。Criteo的度量采集横跨具有超过两万台服务器的六个数据中心，每秒写入80万个数据点。团队维护了两千多个仪表盘，以及一千多种报警，每隔五分钟做一次度量评估。Graphite的默认配置（包括存储后端）并不能满足这样配置的需求。据报告介绍，除了“每种度量对应一个文件”模型存在大量浪费的问题之外，Graphite的集群并非十分稳健，也不是“真正可弹性扩展的”。此外，Whisper中操作数据模型所用的命令行工具运行速度慢，性能脆弱。

图片来源：演讲中使用的幻灯片

在BigGraphite架构中，有一个Carbon中继，它将来自于数据中心的事件发送给写入Cassandra的Carbon缓存过程。Carbon中继也实现复制功能，并通过将数据推送给多个Carbon缓存过程实现分片功能，度量数据由Carbon缓存过程写入到磁盘。转移到BigGraphite架构还包括改为使用Graphite Web UI。

演讲中还介绍了Cassandra的时序模式，但是并未详细介绍如何存储或查询给定度量的标签。Cassandra表中的每行数据都包括度量名称和开始时间戳，并以此作为主键，列键使用与开始时间戳的偏移量。Graphite根据数据所处的保留阶段存储度量数据，例如，为期七天并且每分钟采集一次的数据、为期六个月并且每天采集一次的数据，诸如此类。更早期的度量数据使用聚合函数计算，这反映在Criteo团队对Cassandra表的设计中。对于一个给定的度量，实现有多个表，其中每个表用于一个给定的保留阶段，即对于一个给定的时期，应存储何种采集频率的数据点。

除了Cassandra之外，团队还测评了多种时序数据存储，包括OpenTSDB、Cyanite、KairosDB和InfluxDB。Criteo团队并未采用OpenTSDB，因为OpenTSDB采用HBase为后端，但是团队已经为其它用途使用了HBase集群，难以在该集群之外再建立一个HBase集群。其它选项在完成测评时尚未具备部分所需的特性，因此同样未得到采用。

当前Criteo的Cassandra集群运行有20个节点。团队正致力于引入Prometheus，并构建各个系统间的联系纽带。

查看英文原文： Scaling Graphite at Criteo Using a Cassandra Backend