InfluxDB和Kafka：InfluxData如何在生产中使用Kafka

作者：Anais Dotis-Georgiou / 产品，用例，开发者
2019年8月14日

导航到

在CTO Paul Dix最初发布的InfluxDB 2.0发布公告以及InfluxDB Cloud 2.0公开测试版新版本发布之后，我认为社区会对了解InfluxData如何提供多租户、水平可扩展的时序存储感兴趣。

本系列的第一部分介绍了Kafka和一些基本概念。我们还了解了Wayfair和Hulu如何使用InfluxDB和Kafka创建容错、可扩展、快速的数据管道。结果证明，Hulu和Wayfair并不是唯一利用Kafka解决方案的公司。InfluxData在生产中使用Kafka作为InfluxDB Cloud 2.0的高级预写日志（Write-Ahead-Log），与多家其他公司一道。

本系列博客的第二部分包括

  • Kafka解决的问题概述
  • 为什么Kafka是一个好的解决方案
  • 使用Kafka作为InfluxDB Cloud 2.0内部解决方案的优势总结

WAL是什么？

预写日志（Write-Ahead-Log）或WAL是几乎每个高性能数据库的常见做法，包括时序数据库。它是对将要执行到数据库中的操作的一种日志，一种只追加的文件。WAL有几个优点，但它们主要用于在数据库系统中维护写入的持久性和原子性。

持久性 - 在WAL中首先持久化操作可以确保即使数据库崩溃，这些操作也将被执行。通过在修改内存表示之前将操作记录在WAL中，如果需要，可以恢复和重新应用这些操作，从而确保写入的持久性。

原子性 - 原子性指的是数据库系统的一个属性，它保证会完全发生。如果一个服务器在执行各种操作的过程中崩溃，数据库可以查看WAL来找到它停止的地方并完成工作，从而保证该操作会完全执行。

此外，采用WAL批处理也比每个WAL同步执行精确的一个变更快得多，这可以节省客户端的长等待时间。包括Prometheus、Cassandra、Timescale和InfluxDB在内的多家时序数据库公司都使用WAL。然而，WAL也有一些缺点。

  • 它们不可扩展，因为它们的大小只能与ram一样大；对于多租户云解决方案的请求量来说，这还不够大。
  • 尽管WAL很快，但它的速度并不快——Kafka要快得多。
  • WAL的持久性仅与它所使用的文件系统一样。没有副本；所以如果磁盘损坏，就会丢失所有数据。

InfluxDB Cloud 2.0使用Kafka作为WAL来克服这些缺点。

InfluxDB Cloud 2.0和Kafka解决的问题——从1.x到2.0的变化

WAL在Cloud 1.x上运行良好，因为它只需要对单个租户进行扩展。Cloud 2.0不仅支持多租户，而且其存储节点类似于OSS存储节点——它们是独立的、单独的存储引擎，彼此之间不进行通信。尽管如此，Cloud 2.0更具弹性和健壮性（提供99%的SLA）。那么，如何实现多租户和高效的横向扩展呢？通过复杂的数据分区。这种数据分区由Kafka处理。Kafka分区被用作WAL，Kafka代理节点提供InfluxDB Cloud 2.0所需的持久性、可扩展性和效率。Kafka充当一个非常大的分布式WAL。

是什么让Kafka成为InfluxDB Cloud 2.0的良好解决方案？

InfluxDB Cloud 2.0满足了几项InfluxDB Cloud 1.x未满足的要求。InfluxDB Cloud 2.0包括以下要求里程碑

  1. 多租户 – 在集群中很好地处理多个租户。处理授权方面的性能问题。
  2. 弹性 – 存储层是横向可扩展的。
  3. 高效 – 存储层应尽可能利用跨租户的硬件资源。租户应共享资源。
  4. 健壮 – 数据完整性应能够抵抗故障。
  5. 容错 – 当必要时（故障、部署等），应容易替换存储层中的节点。
  6. 隔离 – 应确保租户无法访问其他租户的数据或对其他租户产生不利影响。

Kafka是一个良好的解决方案，因为它帮助InfluxDB Cloud 2.0以下列方式满足这些要求

  1. 多租户 – 单批数据分布在某个主题的Kafka分区中。每个存储引擎运行一个Kafka消费者，负责从分区日志中读取消息。由于在Kafka的生产端使用批处理，从分区日志中读取的消息通常包含多个租户的目标点。
  2. 弹性 – 在InfluxDB Cloud 2.0平台中，写入路径由两个主要组件组成：预写日志和存储引擎。Cloud 2.0中的WAL由Kafka分区表示，这些分区可扩展且经过实战考验。分区和存储引擎是分布式的，可以独立扩展。与InfluxDB 1.x不同，在那里WAL和存储引擎在同一个进程中，在InfluxDB Cloud 2.0中它们是独立的、分布式的进程。当WAL与存储层解耦时，存储层就可以独立扩展。如果存储层只需要支持更重的读负载，当写负载保持不变时，同时扩展存储层和WAL并不高效。将WAL从存储层解耦，使InfluxDB Cloud 2.0能够在需要时仅高效地扩展存储层。
  3. 高效 – 当客户端将一批点写入Kafka层时，数据会分布到拥有分区的Kafka生产者，在那里它被短暂保留，不会立即写入Kafka分区。Kafka生产者持有数据，直到生产者有足够大的批次可以写入。Kafka生产者在同时将其他批次数据写入Kafka分区的同时保留增长中的批次，这使得存储引擎能够高效地处理大量数据，而不是从单个客户端处理小批量数据。此外，当客户端向WAL写入时，它们不会被阻塞，等待写入在存储层中持久化。
  4. 健壮 – 通过Kafka生产者捕获所有提交的写入和删除操作，并以追加方式在外部系统上归档，可以减轻几种可能的缺陷。如果发生缺陷或用户错误，则可以通过将归档命令重放回WAL来恢复桶。这种架构可以防止由于不正确的数据序列化、丢失的写入、拒绝的写入、不正确的压缩、静默删除或意外数据删除（用户错误）而产生的任何缺陷。
  5. 容错 – 存储层被设计为能够容忍Kafka层的完全丢失。在这种情况下，存储层仍然可用于读取。每个分区在多个存储节点上复制，因此存储层可以容忍部分存储节点不可用，而不会影响读取。
  6. 隔离 – 在2.x中，存储引擎和存储节点互不感知。

InfluxDB Cloud 2.0存储层架构

让我们看一下InfluxDB Cloud 2.0存储层架构，以更好地理解Kafka是如何帮助InfluxDB满足这些要求的。

The InfluxDB Cloud 2.0 storage tier architecture

  • 通过系列键将点数据均匀分布到各个分区。
  • 每个分区复制3次。因此，一个Kafka代理节点丢失不会导致其分区数据的丢失。
  • 生产者写入单个领导者以实现负载均衡，以便每个写入都可以由单独的代理和机器提供服务。
  • Kafka管理跨节点的复制。客户端只需要写入一个节点。该节点是领导者，领导者是按分区划分的。如果节点不可用，具有副本的节点将成为必要分区的新的领导者。
  • 存储层的写入API（未显示）将一批点写入Kafka层，在那里它被保留，直到批次包含最佳数量的点，以确保对分区的写入是高效的。
  • 多个存储引擎消耗同一个分区。
  • 存储节点有多个存储引擎，每个存储引擎消耗一个Kafka分区。
  • 由于有多个副本数据源可供读取，分区的消费可以以不同的速率发生。一个数据源可能比另一个数据源领先。查询层使用存储层的Kafka消费进度来确定哪个副本是最新的。具有最高偏移量或日志最远的分区用于确定查询层应该从哪里读取，因为它是最新的。
  • 一些存储引擎负责将数据同步到对象存储。

使用Kafka作为高级WAL的优点总结

使用Kafka作为高级WAL将InfluxDB Cloud转变为水平可扩展和多租户的时间序列数据库。Kafka既持久又快速。Kafka的持久性提供了用户写入安全可靠的信心。Kafka的速度消除了瓶颈并节省了客户端的长时间等待。我希望这篇帖子能让你对InfluxDB Cloud 2.0或至少Kafka感到兴奋。如果你有任何问题，请在我们的社区网站或Slack频道上发布。