自2015年开放源代码发布Apache Kudu以来，它自称是用于对快速数据进行快速分析的存储。其常规任务包含许多不同的工作负载，但是增长最快的用例之一是时间序列分析。时间序列有几个关键要求：
乍看起来，这些要求将需要专门为时间序列构建的专用数据库系统。实际上，近年来涌现出了诸如InfluxDB 和VictoriaMetrics 之类的 系统来应对这一利基。像Kudu这样的通用系统是否有可能与这些目标设计竞争？
在此博客文章中，我们将使用时间序列基准套件 （TSBS）将Kudu与其他三个存储系统进行比较，该套件 是数据的开源集合和代表IT操作时间序列工作负载的查询生成工具。
由于Kudu是没有任何内置查询语言的存储系统，因此我开发了一个新的守护程序kudu-tsdbd 的原型 。该守护程序提供与InfluxDB的REST协议兼容的HTTP端点，并包括InfluxQL查询语言子集的解析器和执行程序。这样，TSBS对基准InfluxDB的支持可以重新用于基准基于Kudu的实现。
请注意，此体系结构增加了一个额外的“跃点”。每个查询都将提交到时间序列守护程序，进行解析和计划，然后转换为一个或多个对存储在基础Kudu群集中的表的“扫描”调用。然后将所有基础数据从Kudu传输回TSDB流程，以进行聚合和处理。尽管如此，如后续图所示，与单片时间序列系统相比，Kudu提供了竞争性的且通常是优越的性能。
这篇博客文章针对四个目标系统评估了TSBS基准：
在此ClickHouse TSBS Benchmark 的示例之后，我们使用一个具有以下规范的EC2 r5.2xlarge节点：
该硬件的价格约为每天12美元。
TSBS客户端以及目标系统都在同一主机上运行，从而消除了结果数据在网络上的传输瓶颈。
遵循与VictoriaMetrics 和ClickHouse 之前的博客文章中所使用的相同的基准设置，我们使用以下配置：
查询分为两类：
这些工作负载都使用8个客户端线程（等于CPU数量）和16个客户端线程来运行。后一种配置在遇到过载情况时测试系统的健壮性。在第一篇文章中，我们将重点介绍“轻型”查询。在后续文章中，我们将分析“大量”查询的性能。
可以使用github 上的脚本 来复制所有基准测试结果。
这篇文章简介中提到的要求之一是高性能加载。在这里，我们绘制每个系统在数据加载期间每秒的指标数量：
在这里，我们看到Kudu，ClickHouse和VictoriaMetrics大致可比，平均速率在370万至390万个指标/秒之间。InfluxDB明显落后，平均每秒130万个指标，因此加载测试数据集所需的时间大约是原来的3倍。此处的加载时间与ClickHouse 团队的基准报告中 的加载时间非常相似 。
在短期查询的吞吐量方面，VictoriaMetrics令人印象深刻，特别是在最简单的查询（single-groupby-1-1-1）上，该查询仅从单个主机上获取单个指标一个小时（360点） 。在其他查询中，Kudu在某些情况下会将其排除在外。在每种查询类型中，Kudu的性能都优于ClickHouse，并且比InfluxDB快5-10倍。
对于轻量级查询，查看百分位数也很有趣：单个仪表板在完全呈现之前可能会运行成百上千个此类简短查询，因此呈现时间受这些高百分位数离群值支配。
在这张第99个百分位数的延迟图中，较短的条形表示响应时间更快，我们看到Kudu和VictoriaMetrics再次在竞争中胜出一个数量级，在大多数情况下，Kudu处于领先地位，有时甚至有相当大的差距。
在评估系统时，查看负载下系统性能如何下降也很有用。如果我们将客户端数量增加一倍，那么每个核心不再有一个客户端，而是每个核心现在有两个客户端，那么我们就不希望吞吐量增加一倍，但是我们也希望避免任何实质性的降级.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和InfluxQL仅限于时间序列应用程序。实际上，这意味着Kudu和ClickHouse允许您将时间序列数据与仓库中的其他关系数据一起进行分析，并可以使用其他工具（例如Apache Spark，Apache Impala，Apache Flink或Python Pandas）进行分析。
此外，Apache Kudu具有广泛的企业级功能集，其中包括：
Apache Kudu作为高价值数据仓库和datamart用例存储的背景也意味着它具有清晰而强大的语义。插入的数据立即可见，可见的数据持久，并且完全支持删除和更新数据等操作。在此进行基准测试的其他系统有一定的惊喜。例如：
在准备此博客文章时，已确定并改进了Apache Kudu本身。以下新功能是在Kudu 的分支 中实现的，并反映在上述基准测试中：
这些改进是对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。
就提供InfluxQL兼容性层的kudu-tsdbd守护程序而言，它目前仅是一个原型，不能用于一般用途。尽管与InfluxDB和其他系统相比，它的性能令人满意，但目前缺少许多功能，例如各种聚合功能，对子查询等更复杂查询的支持等。根据社区的兴趣，我们可能会继续从原型制作成功能齐全的查询层。如果您有兴趣使用或帮助开发此类图层，请联系Kudu 社区 。
原文链接：https://blog.cloudera.com/benchmarking-time-series-workloads-on-apache-kudu-using-tsbs/
