InfluxDB 3.0：系统架构

InfluxDB 3.0：系统架构

作者： Nga Tran Paul Dix Andrew Lamb Marko Mikulicic / 2023 年 6 月 27 日 / InfluxDB

InfluxDB 3.0（以前称为 InfluxDB IOx）是一个（云）可扩展数据库，为数据加载和查询提供高性能，并专注于时间序列用例。本文介绍了数据库的系统架构。

图1展示了InfluxDB 3.0的架构，包括四个主要组件和两个主存储。

这四个组件几乎独立运行，负责：

• 数据摄取以蓝色显示，
• 数据查询以绿色显示，
• 数据压缩以红色显示，以及
• 垃圾收集分别用粉红色绘制。

对于这两种存储类型，一种专门用于名为Catalog 的集群元数据，另一种则更大，用于存储实际数据并名为Object Storage，例如 Amazon AWS S3。除了这些主要存储位置之外，还有更小的数据存储，称为预写日志(WAL)，摄取组件仅将其用于数据加载期间的崩溃恢复。

图中箭头表示数据流向；如何进行通信以拉取或推送数据超出了本文的范围。对于已经持久化的数据，我们将系统设计为将目录和对象存储作为唯一状态，并使每个组件只能读取这些存储，而不需要与其他组件进行通信。对于尚未持久化的数据，数据摄取组件管理状态以在查询到达时发送到数据查询组件。让我们通过逐一浏览每个组件来深入研究该架构。

图1 InfluxDB 3-0架构

图1：InfluxDB 3.0架构

数据摄取

图 2 演示了 InfluxDB 3.0 中数据摄取的设计。用户将数据写入摄取路由器，摄取路由器将数据分片到其中一台摄取器。集群中接收器的数量可以根据数据工作负载来增加和减少。我们使用这些扩展原则来分割数据。每个摄取器都有一个附加存储，例如 Amazon EBS，用作崩溃恢复的预写日志 (WAL)。

每个摄取器都会执行以下主要步骤：

• 识别数据表：与许多其他数据库不同，用户在将数据加载到 InfluxDB 之前不需要定义其表和列模式。它们将被摄取者发现并隐式添加。
• 验证数据模式：用户写入中提供的数据类型与写入请求同步严格验证。这可以防止类型冲突传播到系统的其余部分，并为用户提供即时反馈。
• 对数据进行分区：在像InfluxDB这样的大型数据库中，对数据进行分区有很多好处。摄取器负责分区作业，目前它在“时间”列上按天对数据进行分区。如果摄取数据没有时间列，则摄取路由器会隐式添加该列并将其值设置为数据加载时间。
• 重复数据删除：在时间序列用例中，经常会看到相同的数据被多次摄取，因此 InfluxDB 3.0 执行重复数据删除过程。摄取器为重复数据删除作业构建高效的多列排序合并计划。由于 InfluxDB 使用DataFusion进行查询执行并使用Arrow作为其内部数据表示，因此构建排序合并计划只需将 DataFusion 的排序和合并运算符放在一起即可。在多个列上有效运行排序合并计划是 InfluxDB 团队为 DataFusion 贡献的工作的一部分。
• 保存数据：处理和排序的数据然后作为Parquet文件保存。因为如果数据在最小基数列上排序，则数据会被非常有效地编码/压缩，因此摄取器会为上述排序的排序顺序找到并选择最小基数列。因此，文件的大小通常比原始形式小 10-100 倍。
• 更新目录：然后，摄取器会更新有关新创建文件是否存在的目录。这是一个信号，让其他两个组件（查询器和压缩器）知道新数据已到达。

即使摄取器执行许多步骤，InfluxDB 3.0 也会优化写入路径，将写入延迟保持在毫秒级的最低限度。这可能会导致系统中出现很多小文件。然而，我们不会将它们保留太久。稍后部分中描述的压缩器会在后台压缩这些文件。

摄取器还支持容错，这超出了本文的范围。摄取器的详细设计和实现值得专门撰写博客文章。

图 2 数据摄取

图 2：数据摄取

数据查询

图3展示了InfluxDB 3.0如何查询数据。用户将SQL或InfluxQL查询发送到查询路由器，查询路由器将它们转发到查询器，查询器读取所需的数据、构建查询计划、运行计划并将结果返回给用户。查询器的数量可以根据查询工作负载使用与接收器设计中相同的扩展原则来扩展和缩减。

每个查询器执行以下主要任务：

• 缓存元数据：为了有效支持高查询工作负载，查询器不断将其元数据缓存与中央目录同步，以获得最新的表及其摄取的元数据。
• 读取并缓存数据：当查询到达时，如果查询器的数据缓存中没有其数据，则查询器首先将数据读取到缓存中，因为从统计中我们知道相同的文件将被读取多次。查询器只缓存回答查询所需的文件内容；根据查询器的修剪策略，查询不需要的文件的其他部分永远不会被缓存。
• 从摄取器中获取尚未持久化的数据：由于摄取器中可能有数据尚未持久化到对象存储中，因此查询器必须与相应的摄取器通信才能获取该数据。通过此通信，查询器还可以从摄取器处了解是否有更新的表和数据可以使其缓存无效并更新其缓存，以获得整个系统的最新视图。
• 构建并执行最佳查询计划：与许多其他数据库一样，InfluxDB 3.0 Querier 包含查询优化器。查询器构建最适合的查询计划（也称为最佳计划），该计划对来自缓存和摄取器的数据执行，并在最短的时间内完成。与摄取器的设计类似，查询器使用DataFusion和Arrow来构建和执行 SQL（以及即将推出的 InfluxQL）的自定义查询计划。查询器利用摄取器中完成的数据分区来并行化其查询计划，并在执行计划之前删除不必要的数据。查询器还应用谓词和投影下推的常见技术来尽快进一步修剪数据。

尽管每个文件中的数据本身不包含重复项，但不同文件中的数据以及从摄取器发送到查询器的尚未持久化的数据可能包含重复项。因此，在查询时重复数据删除过程也是必要的。与摄取器类似，查询器使用与上述相同的多列排序合并运算符来执行重复数据删除作业。与为摄取构建的计划不同，这些运算符只是为执行查询而构建的更大、更复杂的查询计划的一部分。这可确保数据在重复数据删除后流经计划的其余部分。

值得注意的是，即使使用先进的多列排序合并运算符，其执行成本也不是微不足道的。查询器进一步优化计划，仅对可能发生重复的重叠文件进行去重。此外，为了在查询器中提供较高的查询性能，InfluxDB 3.0 通过预先压缩数据来尽可能避免查询期间的重复数据删除。下一节将描述压缩过程。

上面简要描述的查询器任务的详细设计和实现值得他们自己的博客文章。

图3 数据查询

图3：数据查询

数据压缩

如“数据摄取”部分所述，为了减少摄取延迟，摄取器处理并保存到每个文件中的数据量非常小。这会导致对象存储中存储许多小文件，从而在查询期间创建大量 I/O 并降低查询性能。此外，正如“数据查询”部分中所讨论的，重叠文件可能包含在查询期间需要重复数据删除的重复项，这会降低查询性能。数据压缩的工作是将摄取器摄取的许多小文件压缩为更少、更大且不重叠的文件，以获得查询性能。

图4展示了数据压缩的架构，其中包括一个或多个Compactor。每个压缩器都运行一个后台作业，读取新摄取的文件并将它们压缩成更少、更大且不重叠的文件。压缩器的数量可以根据压缩工作负载来增加和减少，压缩工作负载是包含新数据文件的表数量、每个表的新文件数量、文件有多大、新文件有多少现有文件的函数。文件重叠以及表的宽度（即表中有多少列）。

在Compactor：数据库性能的隐藏引擎一文中，我们描述了compactor的详细任务：它如何构建合并数据文件的优化重复数据删除计划、有助于重复数据删除的不同列文件的排序顺序、使用压缩级别以实现非重叠文件，同时最大限度地减少重新压缩，并在查询器中混合非重叠和重叠文件构建优化的重复数据删除计划。

与摄取器和查询器的设计一样，压缩器使用 DataFusion 和 Arrow 来构建和执行自定义查询计划。实际上，所有三个组件共享相同的压缩子计划，涵盖重复数据删除和合并。

必须删除压缩为较大且非重叠文件的小文件和/或重叠文件以回收空间。为了避免删除查询器正在读取的文件，压缩器不会硬删除任何文件。相反，它将文件在目录中标记为软删除，另一个名为垃圾收集器的后台服务最终会删除软删除的文件以回收存储。

图4 数据压缩

图 4：数据压缩

垃圾收集

图 5 说明了负责数据保留和空间回收的 InfluxDB 3.0 垃圾收集的设计。垃圾收集器运行安排软删除和硬删除数据的后台作业。

数据保留：

InfluxDB 为用户提供了一个选项来定义其数据保留策略并将其保存在目录中。垃圾收集器的计划后台作业会读取超出保留期的表的目录，并将其文件在目录中标记为软删除。这向查询器和压缩器发出信号，表明这些文件不再可分别用于查询和压缩。

空间回收：

垃圾收集器的另一个计划后台作业读取某个时间前软删除的文件的元数据目录。然后，它从对象存储中删除相应的数据文件，并从目录中删除元数据。

请注意，软删除的文件来自不同的来源：压缩器删除的压缩文件、垃圾收集器本身删除的保留期限之外的文件以及通过 InfluxDB 3.0 计划将来支持的删除命令删除的文件。硬删除作业不需要知道软删除来自哪里，并对它们进行相同的处理。

软删除和硬删除是另一个大主题，涉及摄取器、查询器、压缩器和垃圾收集器中的工作，值得单独撰写博客文章。

图 5 垃圾收集

图 5：垃圾收集

InfluxDB 3.0集群设置

除了查询器向相应的摄取器发出尚未持久化数据的请求之外，这四个组件不会直接相互通信。所有通信都是通过目录和对象存储完成的。摄取器和查询器甚至不知道压缩器和垃圾收集器的存在。然而，正如上面所强调的，InfluxDB 3.0 的设计目的是让所有四个组件共存以提供高性能数据库。

除了这些主要组件之外，InfluxDB 还提供其他服务，例如根据客户的使用情况向客户计费的计费服务。

目录存储

InfluxDB 3.0 目录包括数据的元数据，例如数据库（也称为命名空间）、表、列和文件信息（例如文件位置、大小、行数等）。InfluxDB 使用 Postgres 兼容数据库来管理其目录。例如，本地集群设置可以使用 PostgreSQL，而 AWS 云设置可以使用 Amazon RDS。

对象存储

InfluxDB 3.0 数据存储仅包含 Parquet 文件，这些文件可以存储在本地磁盘上以进行本地设置，也可以存储在 Amazon S3 中以进行 AWS 云设置。该数据库还适用于 Azure Blob 存储和 Google 云存储。

InfluxDB 3.0集群运行

InfluxDB 3.0 客户可以设置多个专用集群，每个集群独立运行，以避免“吵闹的邻居”问题并包含潜在的可靠性问题。每个集群都利用自己的专用计算资源，并且可以在单个或多个 Kubernetes 集群上运行。这种隔离还包含可靠性问题的潜在爆炸半径，这些问题可能由于另一个集群中的活动而在集群内出现。

我们的基础设施升级创新方法结合了整个 Kubernetes 集群的就地更新和完整的蓝/绿部署。InfluxDB 3.0 集群中的大部分状态都存储在 Kubernetes 集群外部（例如 S3 和 RDS 中），这一事实促进了这一过程。

我们的平台工程系统使我们能够协调数百个集群的操作，并为客户提供对控制性能和成本的特定集群参数的控制。持续监控每个集群的运行状况是我们运营的一部分，允许小团队在快速发展的软件环境中有效管理大量集群。