time-series - Apache Kudu vs InfluxDB 在时间序列数据上的快速分析

Question

对于需要快速分析(例如机器人技术)的物联网传感器数据，Apache Kudu 与 InfluxDB 相比如何？

Kudu 最近发布了 v1.0 我有几个关于 Kudu 如何处理以下内容的具体问题:

1. 分片？
2. 数据保留政策(将数据保留指定数量的数据点或时间，然后聚合/丢弃数据)？
3. 是否有汇总/聚合功能(例如，将 1 秒间隔数据转换为 1 分钟间隔数据)？
4. 是否支持连续查询(即数据的物化 View - 持续查询以查看 60 秒)？
5. 数据如何存储在磁盘和内存之间？
6. 是否可以从不规则时间序列推导出规则时间序列(将不规则事件数据转换为规则时间间隔)？

Kudu 和 InfluxDB 之间还有其他明显的优势和/或劣势吗？

Answer 1

Kudu 是比 InfluxDB 级别低得多的数据存储。它更像是一个分布式文件系统，提供一些类似数据库的功能，而不是一个完整的数据库。它目前依赖于 Impala 等查询引擎来查找存储在 Kudu 中的数据。

Kudu 也相当年轻。有可能构建一个时间序列数据库，将 kudu 作为其下的分布式存储，但目前最接近的实现是 this proof of concept project。 .

至于你的问题的答案。

1) Kudu 将数据存储在 tablet 中，并提供两种分区数据的方式:Range Partitions and Hash based Partitioning

2) Nope尽管如果数据是用范围分区结构化的，删除一个 tablet 应该是一个有效的操作(类似于 InfluxDB 在删除数据时如何删除整个分片)。

3) 与 Kudu 一起工作的查询引擎能够做到这一点，例如 impala 或 spark。

4) Impala 确实支持 views

5) 数据以类似于 Parquet 的柱状格式存储，但是 Kudu 的最大卖点是 Kudu 允许柱状数据可变，这对于当前的 parquet 文件来说是非常困难的。

6) 虽然我确定您可以获得 spark 或 impala 来执行此操作，但它不是内置功能。<​​/p>

Kudu 仍然是一个新项目，它并不是真正设计来与 InfluxDB 竞争，而是为像 InfluxDB 这样的服务提供高度可扩展和高性能的存储层。将数据附加到类似 parquet 的数据结构的能力确实令人兴奋，因为它可以消除对 lambda 架构的需求。