InfluxDB将赌注押在Rust和Apache Arrow的下一代数据存储上

2013年11月12日，我做了第一次关于InfluxDB的公开演讲，题目是：InfluxDB，一个开源的分布式时间序列数据库。在那次演讲中，我介绍了InfluxDB，并概述了我谈到时间序列时的意思：具体地说，它是您在一段时间内可能会问到的任何数据。作为例子，我提供了指标(这是人们在谈论时间序列时通常会想到的)，以及金融市场数据、用户分析数据、日志数据、事件，甚至Twitter时间线。更广泛地说，我声称你分析的所有数据都是时间序列数据。这意味着，任何时候你在做数据分析，你要么是随着时间的推移而做的，要么是作为时间的快照来做的。

在这篇文章中，我将对InfluxDB的未来进行展望，并向您介绍一个将构成其基础的新项目：InfluxDB IOx(发音为Eye-ox，是氧化铁的缩写)。正如帖子的标题所说，这个新项目是以阿帕奇之箭为核心用铁锈(氧化铁，自然)写成的。在深入研究该项目及其底层技术之前，我想先了解一下InfluxDB最初的目标是什么，以及自七年前引入InfluxDB以来，情况发生了怎样的变化。

但首先，以下是你在阅读标题时可能会遇到的一些问题的答案：

InfluxDB IOx将支持SQL(本机)、InfluxQL和Flux(通过2.0和带有单独守护进程的API)。

在未来的单点版本中，InfluxDB IOx将成为InfluxDB的可选存储后端。

InfluxDB Cloud客户将在明年初将InfluxDB IOx作为新存储桶的可选后端。

InfluxDB Cloud客户将在2021年的某个时候无缝、零停机过渡到这项新技术。

InfluxDB Enterprise客户将在2021年下半年拥有商业支持版本的InfluxDB IOx和InfluxDB Enterprise。

InfluxDB IOx将拥有自己的版本，并且可以独立于平台的其余部分运行。

我对InfluxDB的最初设想是，它将用于所有类型的分析任务，既有实时的，也有更大规模的。它将用于服务器和应用程序性能监控、传感器数据应用程序和其他分析应用程序。基本的见解是，时间序列是在这些领域构建应用程序的有用抽象，而InfluxDB将形成这些应用程序的核心基础设施。

目前的InfluxDB对于度量用例来说是一个很棒的数据库。它也非常适合分析，但需要注意的是，您没有重要的基数数据。也就是说，您定义的标记没有太多的唯一值。随着Flux作为一种轻量级查询和脚本语言的添加，您现在可以在数据库中执行复杂的分析，甚至可以在查询时与其他第三方API和数据库交互。

随着用户在数据库中执行的操作越来越多，对基数的限制作为拦截器出现的频率也越来越高。例如，我们希望能够存储和使用分布式跟踪数据，但这种类型的用例对于当前的底层InfluxDB架构来说是无法实现的。我们还希望欢迎更广泛的用户，他们可能更喜欢使用SQL和其他脚本语言工作。

在分布式方面，目前存在于开放源码中的InfluxDB不是分布式数据库，也没有为用户提供使用它创建分布式操作环境的工具。我们在我们的云和企业产品中为我们的商业产品保留了这一功能。从我们的开源努力的角度来看，这在当时是一个不幸但必要的限制，因为我们需要建立一个能够支持我们所做的所有开源工作的企业。

在引入InfluxDB的七年中，我们看到许多其他时间序列数据库被添加到开放和封闭源代码环境中。我们还看到了基础设施软件领域的重大变化，Kubernetes的崛起，Hadoop的衰落，以及更通用的对象存储的兴起，在上面构建了更灵活的软件计算堆栈。

随着更广泛的生态系统中的所有这些变化和我们用户日益增长的需求，我们仔细考虑了InfluxDB应该向何处发展，并确定了一组更高级别的需求来努力。

没有基数限制。编写任何类型的事件数据，不用担心标记或字段是什么。

将计算与存储和分层数据存储分开。数据库应该使用更便宜的对象存储作为其长期持久存储。

操作员控制内存使用。操作员应该能够定义缓冲、缓存和查询处理各自使用了多少内存。

操作员控制的复制。操作员应该能够在每台服务器上设置细粒度的复制规则。

操作员控制的分区。操作员应该能够定义数据如何在多台服务器之间以每台服务器为基础进行拆分。

操作员对拓扑的控制，包括拆分和分离服务器任务以进行写缓冲和订阅、查询处理，以及用于长期存储的排序和索引。

设计用于在短暂的集装箱化环境中运行。也就是说，它应该能够在没有本地连接存储的情况下运行。

更广泛的生态系统兼容性。在可能的情况下，我们应该致力于使用和接受数据和分析生态系统中的新兴标准。

这是一组相当宽泛的要求。此外，像复制和分区这样的需求目前不属于我们的开源保护伞。尝试按照这些要求进行构建会产生许多后果。首先，我想谈一谈许可问题。

我们在InfluxData上生产的开源软件是按照麻省理工学院的许可许可使用的。我们一直认为，我们的开源代码应该是真正开放的，我们的商业代码应该是独立的和封闭的。正如我之前提到的，我们已经推迟了商业产品的高可用性和集群功能。鉴于我们的新需求涉及复制、数据分区和其他分布式方面，我们不得不重新考虑这一决定。

我们首先创建InfluxDB的原因之一是，当涉及到分布式时间序列数据库时，我们看到许多开发人员和组织都在重新创建相同的轮子。我们当时认为，就像我们现在所做的那样，时间序列是一个特定的用例，它明确地受益于为它设计的系统。

这是我在Cassandra、Redis和其他系统上构建时间序列API时的经验。最后，我不得不编写大量的应用程序级别代码来实现我需要的功能。我认为InfluxDB可以成为共享的基础设施。

然而，在核心开源项目中没有分布式特性，这在市场上留下了很大的空白。过去几年出现了如此之多的时间序列数据库就证明了这一点。如果我们希望InfluxDB成为未来需要大规模使用和操作时间序列的项目的构建块，我们需要找到一种方法来更多地而不是更少地开放源代码。

此外，这部作品必须在真正的开放源码许可下进行许可，这是允许的。如果大公司不能采用它，他们最终会自己发明它。如果其他公司不能在它的基础上建立自己的业务并将其API公开给他们的用户，他们最终将自己建立它。如果云提供商不愿意托管它，他们最终将创建自己的版本，这些版本可能不兼容，也可能不是基于开放API构建的。

在可用源代码或受限许可下发放许可证的基础设施项目本质上是进化的死胡同。只有有限的一群用户可以采用该软件，而更有限的一群用户实际上可以在它的基础上开发一款产品。他们通常可以将受限许可项目用于内部目的，但通常不能用于外部面向客户的项目。这些限制意味着许多开发人员别无选择，只能从头开始或从其他实际开放源码的项目开始构建其他东西。

我理解公司为什么选择走这条路，但它的局限性很大。这也令人遗憾，因为他们中的许多人都是从一开始就是开源的核心构建起来的。社区和开源并不在于你的公司能获得多少价值。开源是关于创造寒武纪的软件爆炸，创造的价值远远超过单一供应商设法实现的货币化。开源不是零和游戏。更大的社区和生态系统为所有供应商带来更多机会。

我们的愿景是，InfluxDB将成为无数分析、传感器、监控和数据分析项目和公司的基础。这可能成为现实的唯一途径是，如果我们从一个任何人都可以扩展、采用和商业化的起点出发。

为了实现这一更大的目标，InfluxDB IOx将在麻省理工学院和Apache2下不受限制地获得双重许可。

话虽如此，InfluxDB IOx被设计为作为松散联合的无共享架构运行。操作员应该完全控制各个服务器的行为。这也意味着，任何涉及多台服务器的生产场景都可能需要额外的软件来进行操作。

在最基本的场景中，这可能与一些Shell脚本和cron作业一样简单。在涉及瞬息万变的环境和许多服务器的更复杂场景中，这可能是一款复杂的软件。这个可操作的工具就是我们将拥有商业产品的地方。这将首先出现在我们的云产品中，然后作为InfluxDB Enterprise的一部分作为内部部署产品。

该系统的设计是经过深思熟虑的，既考虑了架构应该如何工作，也考虑了商业化应该如何工作。我们希望我们的云产品能够运行与开源项目完全相同的部分，而不是分支。我们希望内部商业服务是对开源的补充，而不是替代。

康威定律说，你要把你的组织结构图寄给你。迪克斯的格言说，你的许可策略就是你的商业化策略，无论是出于偶然还是有意为之。有了InfluxDB IOx，我们的目标是拥有许可许可的开源软件，该软件对其项目目标最有用，并与补充开源的商业软件相结合。

有几个要求使这项工作成为我们无法逐步实现的目标。在理想情况下，您可以重构并在现有代码库的基础上逐步构建，以达到您想要的目标。这对于进化改进是很好的，但对于重大飞跃来说是困难的。

满足InfluxDB当前构建方式的最严格要求是无限基数。下面是InfluxDB中数据的组织方式。数据通过我们的线路协议发送，如下所示：

这是用于CPU测量的数据，带有主机和区域的标记，以及用户和系统的两个字段，并带有尾随纳秒的纪元时间戳。InfluxDB接收此数据并通过以下方式对其进行索引：

这是一个单独的时间序列，你有一个按时间顺序排列的值，时间对的列表。此外，在倒排索引中索引测量名称、标记键和值以及字段名。因此，InfluxDB的核心实际上是两个数据库：倒排索引和时间序列运行。这使得按测量名称查找时间序列或按标签维度过滤时间序列的速度非常快。

但是，这意味着传入的任何新标记值都会创建一个新系列，并且必须在倒排索引中进行索引。随着时间的推移，这意味着基数越高，倒排索引就越大。在像分布式跟踪这样的病态情况下，您在每一行上都会获得唯一的ID。这意味着您的二级索引将大于基础时间序列数据本身。您还会在这种持续索引上花费大量的CPU周期和内存。

这些用例的一种解决方法是将此数据放入字段中。然而，这导致用户不得不考虑标记和字段，在某些情况下限制了他们在查询时可以做的事情，因为没有以任何方式对字段进行索引。

如果我们想要处理无限基数，倒排索引和时间序列的分离结构将需要改变。然而，这种结构是数据库设计的核心。

严格的内存控制要求也使重构变得困难。这意味着我们不能使用MMAP，这是当前InfluxDB中所有数据和索引文件的使用方式。MMAP是一个很棒的工具，许多现代数据库都是用它建立的。然而，在集装箱化的环境中，使用它是很棘手的。此外，MMAP也不能很好地满足我们的要求，即在没有本地连接磁盘的情况下也能运行。

最后，使用我们构建的底层存储引擎很难满足对象存储作为持久层和大容量数据导入和导出的需求。该设计基本上假设了本地连接的SSD，并且不适合将其中一些文件导出到对象存储，并在稍后查询时导入它们。我们的分叉索引和时间序列数据库结构很难实现海量数据的导入和导出。

这些潜在的变化共同造成了这样一种情况，即我们无法逐步推进InfluxDB的核心。我们需要从根本上重新思考数据库的核心是如何组织的。

一旦我们意识到我们需要对核心的很大一部分进行返工，我们就开始思考我们可以使用什么工具来使这项工作更快、更可靠、更面向社区。作为系统语言的Rust和作为内存分析工具集的Apache Arrow，我都是它的忠实粉丝，这已经不是什么秘密了。我认为这两个是系统软件、OLAP和数据分析的长期未来。在过去的几年里，他们都取得了巨大的进步。

Ruust为我们提供了对运行时行为和内存管理的更细粒度的控制。作为一个额外的好处，它使并发编程变得更容易，并消除了数据竞争。它的包装系统Crates.io非常棒，包括了你开箱即用的一切。随着去年秋天Aync/Await的加入，我认为是时候开始认真考虑它了。

Apache Arrow定义了列式数据的内存格式，以及持久持久化格式Parquet和客户端/服务器框架Flight，Flight是一种客户端/服务器框架和协议，用于“通过网络接口高性能传输大型数据集”。此外，Rust的Apache Arrow工具集中还有DataFusion，这是一个用于Apache Arrow的Rust原生SQL查询引擎。鉴于我们是以DataFusion为核心构建的，这意味着随着DataFusion项目的成熟，通过InfluxData之外的协作者的开发努力，InfluxDB IOx将通过扩展功能来支持SQL的一个开箱即用的子集，以便在InfluxDB IOx和其他地方使用。但是，InfluxDB IOx还支持InfluxQL和Flux。再一次，我们认真对待向后兼容性。

该体系结构的最后一部分是数据库的结构。我们的赌注是，针对时间序列优化的列式数据库可以用作未来InfluxDB的基础。这就是Apache Arrow和DataFusion的结构，与我们实现更广泛的生态系统兼容性的目标非常一致。下面是我们如何将InfluxDB的数据模型映射到列式数据库模型：

标记和字段成为这些表中的列(因此它们的作用域是按度量值划分的)。

除了这个组织方案，我们还选择了拼花作为长期持久化格式。每个Parquet文件包含单个表格的一些数据，这意味着每个文件都包含单个测量的数据。通过我们的研究，我们发现，与使用我们自己的TSM引擎相比，使用Parquet作为持久化格式可以实现与我们自己的TSM引擎一样好甚至更好的真实数据压缩。

此外，我们将所有数据划分为分区。如何将数据分割为分区由操作员或用户在创建数据库时定义。最常见的分区方案将简单地基于时间(例如：每2小时)。

对于每个分区，我们都会汇总它可以保存在内存中的内容。此摘要包括存在哪些表、它们的列以及这些列的最小值和最大值。这意味着查询规划者只需查看分区元数据，就可以在执行之前排除数据集的大部分。

这种分区方案还使我们更容易使用对象存储作为长期存储，并管理从内存到对象存储再到索引的Parquet文件的数据生命周期。

栏目数据库并不新鲜，那么为什么我们还要构建另一个数据库呢？我们在开放源码中找不到针对时间序列进行优化的。在查询方面，我们需要一流的字典支持和窗口聚合，并对其进行优化。在持久性方面，我们需要一些旨在将计算与存储分开的东西。

这个项目没有任何具体的内容是革命性的。在过去几十年左右的时间里，柱状数据库得到了广泛的研究。使用对象存储将计算与存储分离是过去十年中发展势头不断增强的另一件事。Snowflake代表了封闭源码领域中最近比较明显的例子之一。

我们认为，在开源服务器项目中，以Apache Arrow为核心的这些工具的组合和组合代表了开源世界中一种新的有趣的产品。我们认为这是未来实时和大规模的分析和监控项目可能会用到的东西。

我们已经回馈给《铁锈与围棋》中的箭了。这使我们在那里的承诺加倍。然而，我们的一些需求超出了阿帕奇之箭的目标。例如，我们需要一个可以将压缩数据保存在内存中并使用延迟物化对其执行查询的系统。为此，我们正在创建对DataFusion的扩展，它将使InfluxDB IOx能够处理内存中比我们原本能够处理的更多的时间序列数据。

这个项目还处于非常早期的阶段。我们目前没有生成版本，除了InfluxDB IOx项目自述文件之外，没有其他文档。该团队是一个由高级工程师组成的小而专注的团队，我们的努力与我们更大的工程组织在平台其余部分的所有努力是平行的。我们的目标是在明年初生产开源版本，并在InfluxDB Cloud中提供Alpha版本。

我们现在谈论这件事是因为我们认为让社区知道我们的发展方向很重要。我们也想开放这个项目，这样其他对它感兴趣的人就可以跟随它，甚至做出贡献。

对于开源InfluxDB 2.0用户来说，这不会立即产生影响。这项工作还为时尚早，很可能在一段时间内还不能投入生产使用。可以预期，未来的InfluxDB 2.x点版本将能够使用InfluxDB IOx作为可选的存储和查询后端。

在InfluxDB IOx开发期间和之后，InfluxDB 2.x系列的工作将继续进行。这并不代表对API的重大更改。然而，随着时间的推移，2.xAPI中的附加功能将陆续落地，社区将在其可用时使用这些功能。InfluxDB IOx的开发和采用周期应该是增量的，而不是像从1.x到2.0的发布周期那样一次完成。

对于我们的InfluxDB Cloud客户，他们将可以选择使用这项新技术作为新存储桶的后端。

.