InfluxDB 3.0开源计划的概述
作者：Paul Dix / 产品
2023年9月21日
导航到
InfluxDB 3.0的商业版本是一个为实时分析工作负载而构建的分布式、可扩展的时序数据库。它支持无限基数，以SQL和InfluxQL作为原生查询语言，并作为Apache Parquet文件高效管理数据。它显著提高了数据摄取效率、可扩展性、数据压缩、存储成本和查询性能。到目前为止，今年我们已宣布推出三种不同的InfluxDB 3.0版本：InfluxDB Cloud Serverless（适用于小型工作负载的多租户按使用量计费）、InfluxDB Cloud Dedicated（适用于中大型工作负载的管理单租户提供）、以及InfluxDB Clustered（适用于中大型工作负载的自托管）。在这篇文章中，我们宣布了推出开源InfluxDB 3.0的计划，我们称之为InfluxDB Edge。
关于开源InfluxDB 3.0的讨论将揭开许多其他话题的序幕，人们可能会因此产生疑问。因此，我们将详细探讨多个相关话题，以下是重点：
- 开源的InfluxDB 3.0将被命名为InfluxDB Edge，开发将在现有的InfluxDB代码库中进行，继续采用MIT或Apache2许可协议。
- InfluxDB Edge发布后，我们将创建一个名为InfluxDB Community的免费社区版，它将包含Edge中不包含的额外功能（这项开发工作将不在InfluxDB代码库中）。
- InfluxDB Community可以升级到包含Edge或Community中未提供功能的InfluxDB的商业版本。
- InfluxDB IOx代码库已被复制到InfluxDB代码库中，在这次提交下。IOx代码库将在一周后变为私有。
- Flux处于维护模式。我们将继续支持并为客户运行它，包括安全和关键修复，但我们目前的重点是核心SQL和InfluxQL查询引擎。
我将在以下各节中详细说明这些主题，以及关于InfluxDB 3.0（以前称为IOx）、Flux以及我们如何到达这里的反思。每个部分都有标题，以便于您在对此文的后期部分更感兴趣时跳过前面的内容。
InfluxDB Edge：开源InfluxDB 3.0
InfluxDB Edge将是一个独立进程，优化提供可查询的、实时缓冲区，其中包括所有类型的时序和观测数据，这些数据以Parquet文件形式存储在对象存储或本地磁盘上。它将包含一个嵌入式虚拟机，用于连接第三方系统以将数据拉入其缓冲区，或用于在数据到达时对其进行转换和操作，定期按计划或在数据以Parquet文件形式持久化时。
我们相信，Parquet作为一种适用于各种观测和分析数据的标准化格式，将彻底改变数据科学、分析、传感器数据、数据仓库以及各种重要数据任务的领域。目前所缺乏的是一种简单的方法，在将数据写入更大的不可变Parquet文件之前，能够将数据以查询方式存入这种格式。我们认为InfluxDB Edge可以作为一个时间序列数据库，位于数据的前沿，同时使这些数据可供第三方系统协作并围绕Parquet和对象存储进行构建。
从API的角度来看，它将支持InfluxDB 1.x和2.x的写入API（使用行协议），InfluxQL查询API（与之前两个主要版本的InfluxDB相同），以及为3.0版本专门构建的所有新API，包括通过FlightSQL或Apache Arrow Flight使用行业标准SQL进行查询的能力。对于熟悉InfluxDB 1.x和2.x的用户来说，这应该在一定程度上与之前的版本相似，但同时也有很大的不同。
InfluxDB 3.0的数据库架构不包括InfluxDB 1.x和2.x所围绕构建的倒排索引（TSI）或时间序列合并树（TSM）存储引擎。其存储系统旨在组织大量数据块，这些数据块可以快速处理并存储在高度压缩的Parquet文件中。这意味着它针对对数据前沿和特定的时间序列以及分析查询的查询进行了优化。InfluxDB 3.0 Edge将不包括用于重新组织数据以进行删除或查询优化（针对更长的时间段）的压缩器，这意味着它的最佳用途是收集和查询最近的数据。
“嵌入虚拟机的加入将使InfluxDB Edge除了是一个领先的时间序列数据库之外，还能作为一个强大的数据收集、处理和监控代理。”
我们并不打算让InfluxDB 3.0 Edge取代或成为我们商业集群式、分布式数据库产品的一个“轻量”版本，或者完全取代InfluxDB 1.x或2.x开源的所有用例。在功能上可能存在一些交集，但随着时间的推移，它将在任何处理大规模时间序列数据的公司的工具和基础设施中占据不同的位置。我们希望InfluxDB 3.0 Edge在满足之前版本的一些需求的同时，也能拓展到新的领域。嵌入虚拟机的加入将使InfluxDB Edge成为一个强大的数据收集、处理和监控代理，同时也是一个领先的时间序列数据库。
InfluxDB社区：InfluxDB 1.x和2.x的后继者
在Edge的最初发布之后，我们打算发布另一个版本的InfluxDB 3.0，它将适用于更多历史和长时间段的时间序列工作负载：InfluxDB社区。它将免费使用，并可升级到名为InfluxDB的商业版本。免费使用的版本将包括压缩器等功能，这将增加删除和重新组织文件的能力，以优化对比InfluxDB Edge更长时间段数据的查询。对于那些不完全适合Edge功能的InfluxDB 1.x和2.x用户来说，社区将是他们选择的工具。
我们可能在InfluxDB 3.0的商业单服务器版本中包含以下功能
- 与第三方身份验证提供商的集成
- 基于属性和角色的访问控制（ABAC & RBAC）
- 为高可用性提供副本
- 跨多个边缘或社区节点进行联合查询
我们的目标是尽可能让1.x和2.x的开源用户群迁移到Edge或免费社区版本，同时保持我们发布单服务器InfluxDB商业版本的能力。如果您想了解有关即将推出的InfluxDB版本的更新，请在此处注册。
针对不同用例的项目
今天，我们公布了我们产品线的长期愿景以及我们预计将实现的不同功能。我们定义了以下产品
- InfluxDB Edge（MIT/Apache2开源，即将发布的产品）
- InfluxDB Community（免费使用，在Edge之后发布）
- InfluxDB（付费许可，与社区同时或之后发布）
- InfluxDB Clustered（自主管理，年费订阅，现已上市）
- InfluxDB Cloud Serverless（多租户，按使用量计费，现已上市）
- InfluxDB Cloud Dedicated（单租户，资源计费，现已上市）
所有这些产品都将支持InfluxDB 1.x和2.x的写入API、InfluxQL查询API、FlightSQL以及通过嵌入式VM相关的数据写入、查询和后台处理未来3.0 API。这些API和InfluxDB数据模型构成了所有这些产品中的公共接口集。此外，Parquet作为批量共享数据的格式，使得数据可以从一个产品迁移到另一个产品。
“InfluxDB Community将提供Edge的所有功能，同时使查询较长时间范围的数据更高效，并增加删除功能。”
InfluxDB Edge将用于收集和转换时序和观测数据，同时提供领先的边缘实时数据库。它将在边缘很有用，但也适用于数据中心。它可以独立运行，也可以作为由许多边缘节点向更大的InfluxDB专用或集群安装发送数据的更大基础设施的一部分。
InfluxDB Community将提供Edge的所有功能，同时使查询较长时间范围的数据更高效，并增加删除功能。我们预计InfluxDB 1.x和2.x的许多用户在升级到3.0之前将需要这些功能。这将在我们发布Edge的初始版本之后为他们提供一个免费途径。这对于作为历史时间序列数据库很有用，其中高可用性或扩展性不是问题。
InfluxDB付费版将提供Edge和Community的所有功能，并添加数据库工作组的可用性和安全性功能。InfluxDB Community可以通过许可来启用付费功能。InfluxDB单服务器商业版本对于不需要扩展并希望在无需Kubernetes开销和复杂性的裸VM上运行的环境来说非常理想。对于需要安全或高可用性的中小型生产工作负载，这将是一个理想的选择。
最后，InfluxDB Cloud Dedicated 和 InfluxDB Clustered 代表了我们旗舰级的分布式、动态可扩展、安全且最可靠的数据库产品。这些产品基于相同的 InfluxDB 分布式核心，在 Kubernetes 内运行，并通过工作负载隔离将数据摄取、查询和压缩分开。所有服务层都可以相互独立扩展，我们计划在未来的版本中添加分布式缓存和查询工作负载隔离。对于跨多个团队使用同一后端或中等至大型工作负载的环境，InfluxDB Cloud Dedicated 或 InfluxDB Clustered 将是理想的选择。
InfluxDB 3.0（原名 IOx）的历史
最初，我们在 2020 年初启动了 InfluxDB 3.0 的发展，将其作为一项研究项目来回答一些问题
- 一个支持无限基数且数据存储在对象存储中的新数据库架构会是什么样子？
- 我们能否围绕现有的 SQL 引擎来构建，以增加对该语言的支持并获得性能提升？
- 我们可以围绕哪些标准来构建，以实现更多第三方集成以及与更广泛工具生态系统的兼容性？
当我们深入研究实现所有这些目标所需进行的更改时，我们意识到我们面临着几乎重写核心数据库的局面。到目前为止，InfluxDB 是用 Go 编写的，其数据库架构将两种类型的数据库结合在一起：一个倒排索引和一个时间序列存储。我们意识到，这种格式无法满足我们对 InfluxDB 未来版本中预期的更分析型工作负载的服务。
当我们于 2020 年 11 月宣布正在对 InfluxDB 进行重大更新时，我们将该项目命名为 InfluxDB IOx，这是一个用 Rust 编写的 InfluxDB 新核心，基于 Apache Arrow、Apache DataFusion、Apache Parquet 和 Arrow Flight 构建。在那个阶段，它仍然是一个非常早期的项目，前方还有很长的开发之路。随着时间的推移，我们选择的基础工具逐渐演变成了构建分析系统的高级堆栈。我们认为，这些构建块是开放数据系统、实时分析、湖仓和数据仓库架构的未来。
当时我们表示，我们将构建两个软件组件：一个开源的无共享数据平面和一个商业封闭源代码的控制平面，我们将将其作为云托管产品或自托管软件提供。在接下来的三年软件开发中，我们对架构进行了重大改变。当我们做出这些改变时，我们在 InfluxDB IOx 存储库中公开进行了这些更改。
在完成这项开发的同时，我们一直没有明确 InfluxDB 3.0 开源构建中最终将包含什么。今天，随着这一宣布，我们声明了我们打算在开源中包含的内容。作为第一步，我们已经将 IOx 存储库中的所有代码复制到 InfluxDB 开源存储库的主分支（新默认分支）中，该分支继续使用许可的 MIT & Apache2 许可证。从今天起一周后，我们将关闭 IOx 存储库。对于任何从该存储库拉取代码的人，从今天起他们应该指向InfluxDB 存储库中的此提交。
IOx 存储库中的内容并非我们打算放入最终 InfluxDB 3.0 构建，但我们希望将代码移至一个单一的位置，以便依赖它的人可以引用它。IOx 代码库中的许多库将成为 InfluxDB 3.0 Edge 的基础。截至今天，InfluxDB 存储库的主分支是我们开源工作的家。
“鉴于该格式的强大功能和其在数据和分析系统中的日益广泛使用，我们认为现在是 InfluxDB 3.0 Edge 帮助用户在数据存储到 Parquet 文件时实时收集和查询数据的正确时机。”
最终，由于必要的架构变更，我们关于开放数据平面和商业控制平面的愿景不可行，因此我们必须重新思考InfluxDB 3.0将是什么样子。在我们开发这个新版本的InfluxDB期间，我们看到了Parquet得到更广泛的应用。目前似乎缺少的是更多用于收集和将数据转换成Parquet文件的有用工具。鉴于该格式强大的功能和它在数据和分析系统中的日益增多使用，我们认为现在是InfluxDB 3.0 Edge帮助用户在数据存入Parquet文件时实时收集和查询数据的最佳时机。
Flux处于维护模式
Flux是我们为InfluxDB 2.0开发的定制脚本和查询语言的一部分。虽然我们将继续支持我们的客户使用Flux，但它明显地没有出现在InfluxDB 3.0的描述中。用Go编写的Flux，我们希望它能够得到广泛的应用，并赋予用户使用数据库进行之前不可能做的事情的能力。虽然我们提供了一种处理时间序列数据的新方法，但许多用户发现Flux是数据库的采用障碍。
从2018年开始，我们投入了数年的开发者精力在Flux上。这项工作的规模——包括创建新的语言、VM、查询规划器、解析器、优化器和执行引擎——是巨大的。我们最终无法给予语言功能、工具、整体可用性和开发者体验我们希望给予的关注。我们一直在努力提高性能，但由于我们从零开始构建一切，所有的工作都落在我们这个小型团队身上。我们认为这最终阻止了我们进行那些有助于Flux获得更广泛采用的可用性改进。
对于InfluxDB 3.0，我们有一个观点，即建立在一个现有的引擎之上将使我们能够更快地发展，并随着时间的推移提供更多功能，性能更好。我们选择了Apache Arrow DataFusion，一个现有的查询解析器、规划器和执行器。这是一个在2020年中我们做出这个选择时仍在早期阶段的项目，但在过去三年中，它得到了一个活跃且不断壮大的社区的显著贡献。虽然我们仍然是该项目的重大贡献者，但它不断地从全球开发者池中获取功能增强和性能改进。我们在Flux实现上的努力无法跟上大量DataFusion开发者的步伐。
由于InfluxDB 3.0是在新语言（从Go到Rust）中对数据库的从头重写，我们无法将Flux实现带进来。对于InfluxQL，我们能够通过用Rust编写语言解析器并在Rust中将其转换成逻辑计划来实现原生支持，这些逻辑计划是我们新的本地查询引擎Apache Arrow DataFusion可以理解和处理的。我们还必须添加查询引擎的新功能，以支持InfluxQL所支持的一些时间序列查询。这项工作历时一年多，至今仍在进行中。这种方法意味着对DataFusion的贡献也成为了InfluxQL的改进，因为它们共享底层引擎。
最初，我们计划通过数据库提供的底层API在3.0版本中支持Flux。在我们的Cloud2产品中，Flux进程通过gRPC API连接到InfluxDB 1和2的TSM存储引擎。我们在InfluxDB 3.0中构建了对这一支持，并开始与镜像生产工作负载进行测试。我们很快发现，这个接口性能不佳，存在未预见的错误，因此将其排除作为Flux用户将脚本迁移到3.0的可行选项。这是因为API是围绕TSM存储引擎的非常具体的格式设计的，而3.0引擎无法快速提供。
我们将继续为我们的用户和客户支持Flux。鉴于Flux除了作为查询语言外，还是一种脚本语言、规划器、优化器和执行引擎，其范围非常广泛，因此一个Rust原生的版本可能难以实现。而且，由于语言表面范围很大，这样的努力很可能不会产生一个足够兼容的版本，可以运行现有的Flux查询而无需修改或重写，这从一开始就消除了努力的意义。
为了让Flux有前进的道路，我们认为最好的计划是更新核心引擎，使其能够使用FlightSQL与InfluxDB 3.0通信。这将使独立进程能够将Flux脚本中的查询部分转换为SQL查询。然后，该查询将发送到InfluxDB 3.0进程，由Flux引擎进行后处理。
这可能不是一个小工程，因为Flux引擎是围绕InfluxDB 2.0的TSM存储引擎以及所有数据作为单独时间序列的表示构建的。InfluxDB 3.0没有保持系列的概念，所以SQL查询要么做大量工作来返回单个系列，要么Flux引擎需要与查询响应的结果一起工作来构建系列。目前，我们专注于在InfluxDB 3.0和DataFusion中改进核心SQL（以及由此扩展的InfluxQL）查询引擎和体验。
我们可能将来会回到这个项目，但我们不希望阻止社区自行组织起来推进Flux。Flux运行时和语言已作为许可的开源项目在此存在https://github.com/influxdata/flux。我们还创建了一个Flux社区分支，社区可以自行组织并推进开发，而无需我们的代码审查流程。已经有几个社区成员正在研究这条潜在的前进道路。如果您有兴趣帮助这项工作，请在这个跟踪问题上发表意见。
我们意识到Flux仍然有一个热情（虽然规模不大）的用户群体，我们希望找出为这些用户提供最佳前进道路。目前，鉴于我们的资源有限，我们认为将我们的努力集中在改进Apache Arrow DataFusion以及InfluxDB 3.0对其的使用上，是服务于愿意转换为InfluxQL或SQL的用户最佳的方式。在此期间，我们将继续为我们的用户和客户维护Flux，提供安全和关键修复。
对开源的持续承诺
在InfluxDB 3.0中，我们以Apache Arrow、Apache DataFusion、Apache Parquet和FlightSQL为核心，进一步扩大了对开源的承诺。我们不仅积极贡献，有时甚至领导这些上游项目，还致力于InfluxDB 3.0的开发。当我们于2020年夏天将赌注下在这批项目成为InfluxDB 3.0的核心时，还没有明显迹象表明它们会被如此广泛地采用和贡献。
我们认为，Apache Arrow生态系统（包括Parquet、DataFusion和Rust）将成为未来OLAP和大规模数据处理系统的基础。除了InfluxDB 3.0之外，我们将开源努力投入到这些标准中，以便社区持续增长，Apache Arrow项目组合的使用更加方便，功能更加丰富。
我们对InfluxDB Edge的未来充满期待，希望您能跟随我们在开源InfluxDB仓库上的努力。
