在Apache Kudu上对时间序列工作负载进行基准测试

时间序列作为对快速数据的快速分析

自2015年开放源代码发布Apache Kudu以来，它自称是用于对快速数据进行快速分析的存储。其常规任务包含许多不同的工作负载，但是增长最快的用例之一是时间序列分析。时间序列有几个关键要求：

• 高性能流式摄取– 时序工作负载越来越需要以高采样率从成千上万的数据源中摄取数据。存储系统需要支持每秒插入数百万条记录，而无需昂贵的硬件投资。

• 摄取后可立即获得数据 -有时最有价值的时间序列数据是最近几秒内摄取的数据。等待批处理管道将数据提取到存储系统中以获取静态数据（例如，公有云块存储）不是一种选择。

• 高性能扫描-吸收了数百万或数十亿个数据点后，通常有必要对它们进行汇总分析。例如，可以跨时间或跨实体计算汇总和汇总，并且可以构建机器学习模型以查找异常或预测未来行为。时间序列存储需要支持在廉价的硬件配置上每秒检索数十亿个单元。在某些情况下，预聚合和下采样可以减少此要求，但在其他情况下，则需要访问粒度数据。

• 高性能、低延迟的随机查找– 除了扫描大量数据外，在线操作案例（如仪表板或实时监控）还需要能够以非常低的延迟和高吞吐量获取短期数据。例如，为给定实体获取一小时的数据可能具有10ms的第95个百分位延迟SLA。

乍看起来，这些要求将需要专门为时间序列构建的专用数据库系统。实际上，近年来涌现出了诸如InfluxDB 和VictoriaMetrics 之类的 系统来应对这一利基。像Kudu这样的通用系统是否有可能与这些目标设计竞争？

在此博客文章中，我们将使用时间序列基准套件 （TSBS）将Kudu与其他三个存储系统进行比较，该套件 是数据的开源集合和代表IT操作时间序列工作负载的查询生成工具。

Kudu-TSDB体系结构

由于Kudu是没有任何内置查询语言的存储系统，因此我开发了一个新的守护程序kudu-tsdbd 的原型 。该守护程序提供与InfluxDB的REST协议兼容的HTTP端点，并包括InfluxQL查询语言子集的解析器和执行程序。这样，TSBS对基准InfluxDB的支持可以重新用于基准基于Kudu的实现。

请注意，此体系结构增加了一个额外的“跃点”。每个查询都将提交到时间序列守护程序，进行解析和计划，然后转换为一个或多个对存储在基础Kudu群集中的表的“扫描”调用。然后将所有基础数据从Kudu传输回TSDB流程，以进行聚合和处理。尽管如此，如后续图所示，与单片时间序列系统相比，Kudu提供了竞争性的且通常是优越的性能。

基准目标系统

这篇博客文章针对四个目标系统评估了TSBS基准：

• InfluxDB 1.7.10 – InfluxDB是由InfluxData开发的开源时间序列数据库，用Go编写。开源版本仅支持单节点操作，但群集版本可作为付费产品使用。

• VictoriaMetrics 1.34.2 – VictoriaMetrics是Prometheus的开源时间序列数据库和长期远程存储。单节点和群集产品均可用。

• ClickHouse 20.1.6.30 – ClickHouse是一个开源的列式SQL数据库。像Kudu一样，它是常规数据存储，不仅限于时间序列数据。

• Kudu-tsdbd – 以上时间序列后台驻留程序，冒充InfluxDB，在同一主机上的单节点Kudu群集上运行。如本文底部所述，经过测试的 Kudu 版本 包括一些优化，这些优化将在未来几个月内合并到Apache Kudu中。

基准硬件

在此ClickHouse TSBS Benchmark 的示例之后，我们使用一个具有以下规范的EC2 r5.2xlarge节点：

• 8个vCPU

• 64G内存

• 200GB的预配置IOPS EBS（注意：此基准测试中的数据集足够小，因此磁盘性能似乎不是重要因素）

• Ubuntu 18.04.1 LTS

该硬件的价格约为每天12美元。

TSBS客户端以及目标系统都在同一主机上运行，从而消除了结果数据在网络上的传输瓶颈。

基准设置

遵循与VictoriaMetrics 和ClickHouse 之前的博客文章中所使用的相同的基准设置，我们使用以下配置：

• 仅用于TSBS cpu的工作负载– 该工作负载来自InfluxData自己的 influx 比较 基准工具，用于Influx 与 Cassandra ，Influx 与 OpenTSDB 等比较 的系列数据库。

• 比例因子4000（3天） –模拟4000主机，每10秒生成10个CPU指标。这导致数据集中总共有大约10亿个数据点。

• 我们将运行所有受支持的查询， 除非另有说明：

• lastpoint，groupby-orderby-limit – kudu-tsdbd或VictoriaMetrics不支持。由ClickHouse和Influx提供的非常低的性能支持。这些查询难以有效支持，因为它们需要许多存储引擎中未实现的反向扫描功能。

• high-cpu- * – VictoriaMetrics不支持，而kudu-tsdbd部分支持。Kudu-TSDB缺乏支持的原因是InfluxQL执行引擎中的一个小缺陷，而不是任何缺少的底层存储引擎功能。

查询分为两类：

• 轻量查询–在所有系统上，这些查询的响应时间均在200毫秒或更短时间内，我们会同时测量吞吐量（QPS）以及第95和第99个百分位数的延迟，以此来衡量性能是否稳定。

• 繁重的查询-这可能需要几秒钟的时间，并且会聚集大量数据，我们以每分钟查询（QPM）的吞吐量来衡量

这些工作负载都使用8个客户端线程（等于CPU数量）和16个客户端线程来运行。后一种配置在遇到过载情况时测试系统的健壮性。在第一篇文章中，我们将重点介绍“轻型”查询。在后续文章中，我们将分析“大量”查询的性能。

可以使用github 上的脚本 来复制所有基准测试结果。

结果：数据加载性能

这篇文章简介中提到的要求之一是高性能加载。在这里，我们绘制每个系统在数据加载期间每秒的指标数量：

在这里，我们看到Kudu，ClickHouse和VictoriaMetrics大致可比，平均速率在370万至390万个指标/秒之间。InfluxDB明显落后，平均每秒130万个指标，因此加载测试数据集所需的时间大约是原来的3倍。此处的加载时间与ClickHouse 团队的基准报告中 的加载时间非常相似 。

结果：轻量查询，8个客户端线程

在短期查询的吞吐量方面，VictoriaMetrics令人印象深刻，特别是在最简单的查询（single-groupby-1-1-1）上，该查询仅从单个主机上获取单个指标一个小时（360点） 。在其他查询中，Kudu在某些情况下会将其排除在外。在每种查询类型中，Kudu的性能都优于ClickHouse，并且比InfluxDB快5-10倍。

对于轻量级查询，查看百分位数也很有趣：单个仪表板在完全呈现之前可能会运行成百上千个此类简短查询，因此呈现时间受这些高百分位数离群值支配。

在这张第99个百分位数的延迟图中，较短的条形表示响应时间更快，我们看到Kudu和VictoriaMetrics再次在竞争中胜出一个数量级，在大多数情况下，Kudu处于领先地位，有时甚至有相当大的差距。

结果：轻量查询，16个客户端线程

在评估系统时，查看负载下系统性能如何下降也很有用。如果我们将客户端数量增加一倍，那么每个核心不再有一个客户端，而是每个核心现在有两个客户端，那么我们就不希望吞吐量增加一倍，但是我们也希望避免任何实质性的降级.InfluxDB的速度要慢5-10倍在每种情况下。

对于轻量级查询，查看百分位数也很有趣：单个仪表板在完全呈现之前可能会运行成百上千个此类简短查询，因此呈现时间受这些高百分位数离群值支配。下表显示了这种情况下轻查询的吞吐量：

在这里，Kudu显示了在8到16个客户端之间的吞吐量方面的轻微改进。这是由于Kudu内的各种摊销和批处理效果以及8客户端级别的未充分利用。相反，在过载时，VictoriaMetrics的吞吐量显着下降。在这种情况下，ClickHouse的吞吐量也略有下降。

在延迟方面，我们看到了相同的效果：Kudu的p99延迟仍然很低，而其他系统在过载时表现出明显的降级：

繁重查询的性能

基准测试中的“繁重”查询将扫描数据集中的所有数据一天，计算出1、5或全部10列的时间窗汇总。这将导致扫描超过30M，150M或300M的单元以计算查询结果。这些查询显示了大型扫描的相对性能，还可能与将数据导出到其他工作负载（例如机器学习或异常检测）中的性能相关。

对于这些查询，我们看到的结果参差不齐，除了一个常数，InfluxDB比数据包的其余部分慢几个数量级。随着扫描大小从1列增加到10列，Kudu会比其他列领先。

注意：鉴于Kudu和Kudu-TSDB的体系结构，这些查询在内核中花费了大部分CPU周期，将数据从Kudu平板电脑服务器进程传输到时间序列守护程序。未来优化此问题的努力（例如，通过允许有限的计算向下推入Kudu进程本身）将大大改善Kudu。

对于这些繁重的查询，我们不再看到VictoriaMetrics的吞吐量大幅下降，但我们再次注意到Kudu的吞吐量提高了10-20％。

基准测试结果汇总

尽管Apache Kudu是通用存储，但它专注于快速数据的快速分析，使其非常适合时间序列工作负载。总结基准测试结果：

• Kudu在数据加载性能方面与ClickHouse和VictoriaMetrics相当。这三个指标均大大优于InfluxDB。

• Kudu和VictoriaMetrics在短期查询的吞吐量（QPS）方面优于ClickHouse和InfluxDB。在某些情况下，Kudu的吞吐量要比VictoriaMetrics高，而在其他情况下，VictoriaMetrics的性能要优于Kudu。

• 对于长期运行的查询，随着度量列数的增加，Kudu将提供优于其他存储的性能，并且在任何查询类型中都不会表现出明显的优势。

• 当客户端线程的数量增加到核心数量的两倍时，Kudu的性能将超过所有其他系统，从而在吞吐量和高百分位数的延迟方面均表现出稳定的性能。

定性差异

除了上面概述的数量差异之外，了解存储之间的质量差异也很重要。特别是Kudu和ClickHouse具有通用存储的特征，而VictoriaMetrics和InfluxQL仅限于时间序列应用程序。实际上，这意味着Kudu和ClickHouse允许您将时间序列数据与仓库中的其他关系数据一起进行分析，并可以使用其他工具（例如Apache Spark，Apache Impala，Apache Flink或Python Pandas）进行分析。

此外，Apache Kudu具有广泛的企业级功能集，其中包括：

• 具有自动故障恢复，故障域识别和重新平衡功能，可扩展到数百个节点

• 安全控制，包括身份验证，在线加密和授权

• 支持在blob存储或HDFS上使用Apache Parquet进行备份和还原

Apache Kudu作为高价值数据仓库和datamart用例存储的背景也意味着它具有清晰而强大的语义。插入的数据立即可见，可见的数据持久，并且完全支持删除和更新数据等操作。在此进行基准测试的其他系统有一定的惊喜。例如：

• 直到摄取后30秒，VictoriaMetrics才可以读取数据。此外，它没有预写日志，因此崩溃的服务器将丢失最近插入的数据。仅通过使用年故障率为0.1-0.2％的永久磁盘（例如EBS）才能进行复制。

• InfluxDB的更新和删除功能受到限制。例如，不支持用 NULL 条目替换值，并且不支持 基于谓词的更新和删除。

Apache Kudu即将进行的改进

在准备此博客文章时，已确定并改进了Apache Kudu本身。以下新功能是在Kudu 的分支 中实现的，并反映在上述基准测试中：

• 列式数据传输– 列式数据传输格式使Kudu平板服务器可以返回扫描的行结果，与当前面向行的结果格式相比，其CPU消耗低得多。就其本身而言，这在我们支持的查询中产生了1.13倍的几何平均改进。

• SIMD-BP128编码–针对整数数据开发了一种新的编码，可实现更高的扫描速度和更好的压缩效果。此编码需要进一步开发以在所有情况下均具有鲁棒性，但最终应取代Kudu使用的默认的整数编码的bithuffle编码。就其本身而言，这在我们支持的查询中产生了1.88倍的几何平均值改进。

• 当结合列式数据传输和BP128编码时，平均改进为2.17倍。

这些改进是对Apache Kudu的master分支（从commit 1cb4a0ae3e开始）已经承诺的其他性能改进的基础，这些性能改进比Kudu 1.11.1的几何平均值提高了1.13倍。包括所有优化，相对于Apache Kudu 1.11.1，几何平均性能提高了约2.5倍。

下图说明了这些更改对性能的影响。每个条形图表示使用8个客户端线程进行测试时QPS的改进，已针对Kudu 1.11.1的性能进行了标准化。

我们希望在接下来的几个月中开始将BP128和列式编码改进并入Apache Kudu。

kudu-tsdbd的未来

就提供InfluxQL兼容性层的kudu-tsdbd守护程序而言，它目前仅是一个原型，不能用于一般用途。尽管与InfluxDB和其他系统相比，它的性能令人满意，但目前缺少许多功能，例如各种聚合功能，对子查询等更复杂查询的支持等。根据社区的兴趣，我们可能会继续从原型制作成功能齐全的查询层。如果您有兴趣使用或帮助开发此类图层，请联系Kudu 社区 。

原文链接：https://blog.cloudera.com/benchmarking-time-series-workloads-on-apache-kudu-using-tsbs/