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 可以升级到商业版本的 InfluxDB，其中包含 Edge 或 Community 中均未提供的功能。
- InfluxDB IOx 仓库已复制到 InfluxDB 仓库 在此提交下。IOx 仓库将在一周内设为私有。
- Flux 处于维护模式。我们将继续为我们的客户提供支持和运行，并提供安全和关键修复，但我们目前的重点是我们的核心 SQL 和 InfluxQL 查询引擎。
我将在以下部分中介绍所有这些主题，并回顾 InfluxDB 3.0（以前称为 IOx）、Flux 的开发以及我们是如何走到今天的。每个部分都有标题，以便您更容易跳过，如果这篇文章的后面部分对您更感兴趣。
InfluxDB Edge：开源 InfluxDB 3.0
InfluxDB Edge 将是一个独立的进程，经过优化，可提供可查询的实时缓冲区，用于存储各种时序和观测数据，这些数据以 Parquet 文件的形式存储在对象存储或本地磁盘中。它将具有嵌入式 VM，用于连接到第三方系统，以将数据拉入其缓冲区，或用于在数据到达时、定期按计划或在数据持久化到 Parquet 文件中时转换和处理数据。
我们相信 Parquet – 作为各种观测和分析数据的标准格式 – 将对数据科学、分析、传感器数据、数据仓库和各种重要数据任务产生变革性影响。目前缺少的是一种简单的方法，可以将数据转换为这种格式，同时在数据写入更大的不可变 Parquet 文件之前使其可用于查询。我们认为 InfluxDB Edge 可以充当数据前沿的时序数据库，同时使这些数据可供第三方系统协作并围绕 Parquet 和对象存储构建。
从 API 的角度来看，它将支持 InfluxDB 1.x 和 2.x 写入 API（使用 Line Protocol）、InfluxQL 查询 API（与之前的两个主要 InfluxDB 版本相同）以及专门为 3.0 构建的所有新 API，包括通过 FlightSQL 使用行业标准 SQL 或通过 Apache Arrow Flight 使用 InfluxQL 进行查询的功能。对于熟悉 InfluxDB 1.x 和 2.x 的用户来说，这在某些方面听起来应该与之前的版本相似，但同时又非常不同。
InfluxDB 3.0 的数据库架构不包括 InfluxDB 1.x 和 2.x 构建所依据的倒排索引 (TSI) 或时序合并树 (TSM) 存储引擎。其存储系统旨在将数据组织成可以快速处理并保存在高度压缩的 Parquet 文件中的大块数据。这意味着它针对针对数据前沿和时序以及特别是分析查询的查询进行了优化。InfluxDB 3.0 Edge 将不包含用于重新组织数据以进行删除或在较长时间段内进行查询优化的压缩器，这意味着它的最佳应用场景将是收集和查询最近的数据。
“嵌入式 VM 的加入将使 InfluxDB Edge 成为收集、处理和监控数据的强大代理，此外，它还是领先的时序数据库。”
我们不打算让 InfluxDB 3.0 Edge 成为我们商业集群式分布式数据库产品的替代品或“轻量级”版本，也不打算完全替代 InfluxDB 1.x 或 2.x 开源的所有用例。在功能上会存在一些交叉，但随着时间的推移，它将在任何大规模处理时序数据的公司的工具箱和基础设施中占据不同的位置。我们希望 InfluxDB 3.0 Edge 能够满足以前版本的一些相同需求，同时扩展到新的领域。嵌入式 VM 的加入将使 InfluxDB Edge 成为收集、处理和监控数据的强大代理，此外，它还是领先的时序数据库。
InfluxDB Community：InfluxDB 1.x 和 2.x 的继任者
在 Edge 的初始版本发布后，我们计划发布另一个版本的 InfluxDB 3.0，它将对更长历史时间范围内的数据的时序工作负载有用：InfluxDB Community。它将免费使用，并且可以升级到名为 InfluxDB 的商业版本。免费使用版本将包含诸如压缩器之类的功能，这将增加删除和重新组织文件的能力，以优化对 InfluxDB Edge 更长时间范围内的数据的查询。对于不太适合 Edge 功能范围的 InfluxDB 1.x 和 2.x 用户，Community 将是他们的首选工具。
我们可能在商业单服务器版本的 InfluxDB 3.0 中包含的功能可能包括
- 与第三方身份验证提供商集成
- 基于属性和角色的访问控制（ABAC 和 RBAC）
- 用于高可用性的副本
- 跨多个 Edge 或 Community 节点的联合查询
我们的目的是使尽可能多的 1.x 和 2.x 开源用户群能够迁移到 Edge 或免费的 Community 版本，同时保持我们交付商业单服务器 InfluxDB 版本的能力。如果您有兴趣获取有关即将推出的 InfluxDB 版本的更新，请在此处注册。
针对不同用例的不同项目
通过今天的公告，我们正在规划我们产品线的长期愿景，以及我们期望在何处实现不同的功能。我们定义了以下产品
- InfluxDB Edge（MIT/Apache2 开源，下一个要发布的产品）
- InfluxDB Community（免费使用，在 Edge 之后发布）
- InfluxDB（付费许可证，与 Community 同时或之后发布）
- 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 将用于收集和转换时序和观测数据，同时提供领先的前沿实时数据库。它在 Edge 和数据中心内都很有用。它可以独立运行，也可以作为更大的基础设施的一部分运行，该基础设施具有许多 Edge 节点，这些节点将数据发送到更大的 InfluxDB Dedicated 或 Clustered 安装。
InfluxDB Community 将提供 Edge 的所有功能，但也会使对更长时间范围内数据的查询更有效率，同时增加删除功能。我们预计，许多 InfluxDB 1.x 和 2.x 用户在升级到 3.0 之前将需要这些功能。当我们发布 Edge 的初始版本后发布它时，这将为他们提供免费的升级途径。这对于高可用性或规模不是问题的历史时序数据库很有用。
InfluxDB 付费版本将提供 Edge 和 Community 的所有功能，同时为使用数据库的团队增加高可用性和安全功能。InfluxDB Community 将能够通过许可启用付费功能。商业版本的 InfluxDB 单服务器非常适合不需要横向扩展并且喜欢在裸虚拟机上运行而无需 Kubernetes 的开销和复杂性的环境。对于需要安全或高可用性的中小型生产工作负载，这将是理想的选择。
最后，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，它是 InfluxDB 的新核心，用 Rust 编写，并使用 Apache Arrow、Apache DataFusion、Apache Parquet 和 Arrow Flight 构建。在那个阶段，它仍然是一个非常早期的项目，未来的开发道路还很长。随着时间的推移，我们对基础工具的选择演变成用于构建分析系统的复杂堆栈。我们认为这些构建块是开放数据系统、实时分析、Lakehouse 和数据仓库架构的未来。
当时，我们表示我们将将其构建为两部分软件：开源、无共享的数据平面和商业闭源控制平面，我们将以云托管产品或自 управля 软件的形式提供。在接下来的三年软件开发中，我们大幅更改了架构。当我们进行这些更改时，我们在 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 的描述中明显缺少它。Flux 用 Go 编写，我们构建 Flux 是希望它能得到广泛采用，并使用户能够使用数据库做以前不可能的事情。虽然我们提供了一种处理时序数据的强大新方法，但许多用户发现 Flux 是数据库采用的阻碍因素。
我们从 2018 年开始在 Flux 上投入了多年的开发者精力。这项工作的规模非常庞大 – 包括创建一种新语言、VM、查询计划器、解析器、优化器和执行引擎。我们最终无法投入我们希望投入的那种关注来改进更多语言功能、工具以及整体可用性和开发者体验。我们一直在性能方面努力，但由于我们是从头开始构建一切，因此所有努力都完全落在我们的小团队身上。我们认为这最终使我们无法致力于那些能够帮助 Flux 获得更广泛采用的可用性改进。
对于 InfluxDB 3.0，我们有一个理念，即基于现有引擎构建可以使我们更快地发展，并在更长的时间内交付更多功能和更优性能。我们选择了 Apache Arrow DataFusion，一个现有的查询解析器、计划器和执行器。当我们在 2020 年年中做出这个选择时，它还是一个处于早期阶段的项目，但在过去的三年中，来自一个活跃且不断壮大的社区的贡献显著增加。虽然我们仍然是该项目的主要贡献者，但它仍在不断从全球开发者群体中获得功能增强和性能改进。我们在 Flux 实现方面所做的努力根本无法与规模更大的 DataFusion 开发者群体相提并论。
由于 InfluxDB 3.0 是用一种新语言（从 Go 到 Rust）对数据库进行的彻底重写，因此我们无法将 Flux 实现一起引入。对于 InfluxQL，我们能够通过用 Rust 编写语言解析器，然后将 InfluxQL 查询转换为我们的新原生查询引擎 Apache Arrow DataFusion 可以理解和处理的逻辑计划，从而原生支持它。我们还必须为查询引擎添加新功能，以支持 InfluxQL 启用的一些时间序列查询。这项工作历时一年多，并且仍在进行中。这种方法意味着，对 DataFusion 的贡献也将成为 InfluxQL 的改进，因为它们共享底层引擎。
最初，我们在 3.0 中支持 Flux 的计划是通过数据库将提供的较低级别 API 来实现。在我们的 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 通信。这将创建一个架构，其中服务 InfluxDB 2.x 查询 API（即 Flux）的独立进程将能够将 Flux 脚本中作为查询的部分转换为 SQL 查询。然后，该查询将被发送到 InfluxDB 3.0 进程，结果将由 Flux 引擎进行后处理。
这可能不是一项轻松的工作，因为 Flux 引擎是围绕 InfluxDB 2.0 的 TSM 存储引擎构建的，并将所有数据表示为单个时间序列。InfluxDB 3.0 不保留序列的概念，因此 SQL 查询要么必须做大量工作来返回单个序列，要么 Flux 引擎将使用生成的查询响应来构建序列。目前，我们专注于改进核心 SQL（以及扩展的 InfluxQL）查询引擎以及 InfluxDB 3.0 和 DataFusion 中的体验。
我们将来可能会重新回到这项工作，但我们不想阻止社区自发组织起来推进 Flux 的发展。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 代码库 上的工作。
