FAQ系列之Kafka

关于 Kafka 主题的常见问题集。

什么是Kafka？

Kafka 是一个流式消息平台。进一步分解一下：

“流媒体”：发布者（“生产者”）经常发送的大量消息（想想数万或数十万）。许多订阅者（“消费者”）经常进行消息轮询。

“消息”：从技术角度来看，键值对。从非技术角度来看，字节数相对较少（想想几百到几千字节）。

如果这不是您计划的用例，Kafka可能不是您正在寻找的解决方案。联系您最喜欢的 Cloudera 代表进行讨论和了解。最好事先了解您可以做什么和不可以做什么，而不是根据一些热情的任意供应商信息继续使用最终无法满足您期望的解决方案。

Kafka 是为什么而设计的？

Kafka 在 LinkedIn 被设计为一个横向扩展的发布订阅系统。它在系统和消息级别提供了大量可配置性来实现这些性能目标。有充分记录的案例展示了当一切都做得正确时 Kafka 的扩展能力。

Kafka 不适合什么（或权衡是什么）？

在不考虑权衡的情况下，很容易陷入 Kafka 可以用来做的所有事情。Kafka 配置也不是自动的。您需要了解每个用例，以确定可以使用哪些配置属性来为每个用例调整（和重新调整！）Kafka。

在配置时需要深入了解和小心的一些更具体的示例是：

• 使用 Kafka 作为您的微服务通信中心

Kafka 可以替代软件基础设施的消息队列和服务发现部分。然而，这通常以增加一些延迟以及需要监控新的复杂系统（即您的 Kafka 集群）为代价。

• 使用 Kafka 作为长期存储

虽然 Kafka 确实有一种配置消息保留的方法，但它主要是为低延迟消息传递而设计的。Kafka 不支持通常与文件系统相关的功能（例如元数据或备份）。因此，建议改用某种形式的长期摄取，例如 HDFS。

• 使用 Kafka 作为端到端解决方案

Kafka 只是解决方案的一部分。在您充分利用它之前，有许多最佳实践需要遵循和支持工具来构建（请参阅这篇明智的LinkedIn 帖子）。

• 在没有正确支持的情况下部署 Kafka

优步为他们的工程组织提供了一些数字。这些数字可以帮助您了解达到这种规模所需的条件：1300 台微服务器、2000 名工程师。

我在哪里可以获得 Kafka 的一般概述？

阅读Kafka Introduction和Kafka Architecture，其中涵盖了 Kafka 的基础知识和设计。这应该是一个很好的起点。如果您还有任何问题，请访问此常见问题解答或与您最喜欢的 Cloudera 代表讨论培训或最佳实践深入探讨。

Kafka 在哪里适合分析数据库解决方案？

分析数据库部署受益于 Kafka，将其用于数据摄取。然后，数据可以为各种分析工作负载填充表。对于临时 BI，实时方面不太重要，但能够利用实时应用程序、BI 和分析中使用的相同数据的能力是 Cloudera 平台提供的一个好处，因为您将拥有 Kafka 用于这两个目的，已经集成、安全、治理和集中管理。

Kafka 在哪里适合操作数据库解决方案？

Kafka 常用于实时的、任务关键型的操作数据库部署领域。它用于摄取数据并允许通过 Kudu 或 HBase 立即为其他应用程序和服务提供服务。在 Cloudera 平台中为操作数据库使用 Kafka 的好处是集成、安全、治理和集中管理。您可以避免孤立架构的风险和成本，并提供“另一种解决方案”来支持。

什么是Kafka消费者？

如果 Kafka 是存储消息的系统，那么消费者就是从 Kafka 读取这些消息的系统的一部分。

虽然 Kafka 确实附带了一个可以充当消费者的命令行工具，但实际上，您很可能会使用 KafkaConsumer API 为您的生产系统编写 Java 代码。

什么是Kafka生产者？

当消费者从 Kafka 集群读取时，生产者写入 Kafka 集群。

与消费者类似（请参阅上一个问题），您的生产者也是针对您的特定用例的自定义 Java 代码。

您的生产者可能需要对写入性能和 SLA 保证进行一些调整，但通常比您的消费者更简单（错误情况更少）。

我可以在我的 Kafka Java 代码中调用哪些功能？

获取有关可以在 Kafka Java 代码中调用哪些功能的更多信息的最佳方法是查看 Java 文档。并且仔细阅读！

如果我关心性能和稳定性，最好的 Kafka 记录大小是多少？

LinkedIn 上有一篇 2014 年的旧博客文章，标题为：基准 Apache Kafka：每秒 200 万次写入（在三台便宜的机器上）。在“消息大小的影响”部分，您可以看到两个图表，它们表明 Kafka 吞吐量从 100 字节到 1000 字节的记录大小开始受到影响，并在 10000 字节左右触底。通常，保持主题特定并故意保持消息大小较小有助于您充分利用 Kafka。

摘自部署 Apache Kafka：实用常见问题解答：

• 如果共享存储可用（HDFS、S3、NAS），将大负载放在共享存储上，并使用 Kafka 发送带有负载位置的消息。
• 通过在写入 Kafka 之前将大消息切分成更小的部分来处理大消息，使用消息密钥确保所有部分都写入同一分区，以便它们被同一个消费者使用，并从其部分重新组装大消息消费时。

我在哪里可以获得 Kafka 培训？

你有很多选择。Cloudera 提供以下两个问题中列出的培训。您还可以请您的常驻解决方案架构师深入了解 Kafka 架构和最佳实践。此外，您可以随时参与社区活动以获取有关特定主题的见解和专业知识。

我在哪里可以获得基本的 Kafka 培训？

Cloudera 培训为 Kafka 提供基本的按需培训，其中涵盖了 Kafka 架构、消息、排序的基础知识，以及旧版 Java API 的一些幻灯片（代码示例）。它还涵盖了使用 Flume + Kafka。有关更多信息，请参阅 Apache Kafka 简介

我在哪里可以获得 Kafka 开发人员培训？

Kafka 开发人员培训包含在 Cloudera 的Apache Spark 和 Hadoop 开发人员培训中。

针对高级用户的有关 Kafka 主题的常见问题集。

和大多数开源项目一样，Kafka 提供了很多配置选项来最大化性能。在某些情况下，如何最好地将您的特定用例映射到这些配置选项并不明显。我们试图解决其中一些情况。

我该怎么做才能确保永远不会丢失 Kafka 事件？

这是一个简单的问题，对您的整个 Kafka 设置有很多深远的影响。完整的答案包括接下来的几个相关常见问题解答及其答案。

为获得最佳可靠性，推荐的节点硬件是什么？

在操作上，您需要确保您的 Kafka 集群满足以下硬件设置：

• 有一个仅运行 Zookeeper 的 3 或 5 节点集群（仅在最大规模时才需要更高）。
• 至少有一个仅运行 Kafka 的 3 节点集群。
• 让 Kafka 集群上的磁盘在 RAID 10 中运行。（对于磁盘故障的弹性是必需的。）
• 为集群中的 Kafka 和 Zookeeper 角色提供足够的内存。（推荐：4GB 用于代理，其余内存由内核自动用作文件缓存。）
• Kafka 集群上有足够的磁盘空间。
• 拥有足够数量的磁盘来处理 Kafka 和 Zookeeper 的带宽需求。
• 您需要的节点数大于或等于您希望使用的最高复制因子。

获得最佳可靠性的网络要求是什么？

Kafka 希望在代理和 Zookeeper 节点之间建立可靠、低延迟的连接：

• Kafka集群和Zookeeper集群之间的网络跳数比较少。
• 拥有高度可靠的网络服务（如 DNS）。

获得最佳可靠性的系统软件要求是什么？

假设您遵循前两个问题的建议，则必须正确配置 Kafka 之外的实际系统。

1. 内核必须配置为 Kafka 所需的最大 I/O 使用率。
   1. 大页面缓存
   2. 最大文件描述
   3. 最大文件内存映射限制
2. Kafka JVM 配置设置：
   1. Broker 通常不需要超过 4GB-8GB 的堆空间。
   2. 使用 Java 8 或更高版本通过 +G1GC 垃圾收集运行。

如何配置 Kafka 以确保可靠地存储事件？

以下对 Kafka 配置设置的建议使得数据丢失的发生极为困难。

• 生产者
  • block.on.buffer.full=true
  • retries=Long.MAX_VALUE
  • acks=all
  • max.in.flight.requests.per.connections=1
  • 请记住在完成或长时间暂停时关闭生产者。
• 经纪人
  • Topic replication.factor >= 3
  • Min.insync.replicas = 2
  • 禁用不洁领导人选举
• 消费者
  • 禁用 enable.auto.commit
  • 在您的消费者客户端处理消息后提交偏移量。

如果您有 3 个以上的主机，您可以在需要更多数据丢失保护的主题上适当增加代理设置。

一旦我遵循了之前的所有建议，我的集群就永远不会丢失数据，对吗？

Kafka不保证永远不会发生数据丢失。有以下权衡：

• 吞吐量与可靠性。例如，复制因子越高，您的设置对数据丢失的弹性就越大。但是，制作这些额外的副本需要时间并且会影响吞吐量。
• 可靠性与可用磁盘空间。由于复制而产生的额外副本耗尽了原本用于存储事件的磁盘空间。

除了上述设计权衡之外，还存在以下问题：

• 为确保事件被消费，您需要监控您的 Kafka 代理和主题，以验证是否有足够的消费率来满足您的摄取要求。
• 确保在需要消费保证的任何主题上启用复制。这可以防止 Kafka 代理故障和主机故障。
• Kafka 旨在在定义的持续时间内存储事件，之后事件将被删除。您可以将事件保留的持续时间增加到支持的存储空间量。
• 除非向集群添加更多节点，否则您将始终耗尽磁盘空间。

我的 Kafka 事件必须按顺序处理。我怎样才能做到这一点？

在您的主题配置了分区后，Kafka 将每条记录（基于键/值对）发送到基于键的特定分区。因此，对于任何给定的键，相应的记录在分区内都是“有序的”。

对于全局排序，您有两个选择：

• 您的主题必须包含一个分区（但更高的复制因子可能对冗余和故障转移有用）。但是，这将导致非常有限的消息吞吐量。
• 您使用少量分区配置主题，并在消费者拉取数据后执行排序。这不会导致保证排序，但是，给定足够大的时间窗口，可能是等效的。

相反，最好在设计 Kafka 设置时考虑 Kafka 的分区设计，而不是依赖于事件的全局排序。

如何调整主题大小？或者：主题的“正确”分区数是多少？

为主题选择合适的分区数量是实现读写高度并行和分配负载的关键。在分区上均匀分布负载是获得良好吞吐量（避免热点）的关键因素。做出一个好的决定需要根据每个分区的生产者和消费者的预期吞吐量进行估计。

例如，如果您希望能够读取 1 GB/秒，但您的消费者只能处理 50 MB/秒，那么您至少需要 20 个分区和消费者组中的 20 个消费者。同理，如果要为生产者实现同样的效果，而1个生产者只能以100 MB/秒的速度写入，则需要10个分区。在这种情况下，如果您有 20 个分区，则可以保持 1 GB/秒的速度来生成和使用消息。您应该将分区的确切数量调整为消费者或生产者的数量，以便每个消费者和生产者实现其目标吞吐量。

所以一个简单的公式可以是：

#Partitions = max(NP, NC)

在哪里：

• NP 是通过计算确定的所需生产者数量：TT/TP
• NC 是通过计算确定的所需消费者数量：TT/TC
• TT 是我们系统的总预期吞吐量
• TP 是单个生产者对单个分区的最大吞吐量
• TC 是单个分区中单个消费者的最大吞吐量

此计算为您提供了分区数的粗略指示。这是一个很好的起点。在系统就位后，请记住以下有关增加分区数量的注意事项：

• 可以在主题创建时或之后指定分区数。
• 增加分区数也会影响打开的文件描述符数。因此，请确保正确设置文件描述符限制。
• 重新分配分区可能非常昂贵，因此过度配置比不足配置要好。
• 更改基于键的分区数量具有挑战性，并且涉及手动复制。
• 当前不支持减少分区数。相反，创建一个具有较少分区数量的新主题并复制现有数据。
• 关于分区的元数据以 znodes. 拥有大量分区会对 ZooKeeper 和客户端资源产生影响：
  • 不需要的分区给 ZooKeeper 带来了额外的压力（更多的网络请求），并且如果代理宕机，可能会延迟控制器和/或分区领导者的选举。
  • 生产者和消费者客户端需要更多内存，因为他们需要跟踪更多分区并缓冲所有分区的数据。
• 作为最佳性能的准则，每个代理的分区不应超过 4000 个，集群中的分区不应超过 200,000。

通过监控消费者滞后，确保消费者不会落后于生产者。要检查消费者在消费者组中的位置（即他们落后于日志末尾多远），请使用以下命令：

$ kafka-consumer-groups --bootstrap-server BROKER_ADDRESS --describe --group CONSUMER_GROUP --new-consumer

如何扩展已部署在生产中的主题？

回想一下关于Kafka的以下事实：

• 创建主题时，您可以设置分区数。分区数越高，并行性越好，并且事件在集群中的分布越均匀。
• 在大多数情况下，当事件进入 Kafka 集群时，具有相同键的事件进入同一个分区。这是使用散列函数来确定哪个键去哪个分区的结果。

现在，您可能认为扩展意味着增加主题中的分区数量。但是，由于散列的工作方式，简单地增加分区数量意味着您将丢失“具有相同键的事件进入相同分区”这一事实。

鉴于此，有两种选择：

1. 您的集群可能无法很好地扩展，因为分区负载没有正确平衡（例如，一个代理有四个非常活跃的分区，而另一个没有）。在这些情况下，您可以使用kafka-reassign-partitions脚本手动平衡分区。
2. 创建具有更多分区的新主题，暂停生产者，从旧主题复制数据，然后将生产者和消费者转移到新主题。这在操作上可能有点棘手。

如何重新平衡我的 Kafka 集群？

当新节点或磁盘添加到现有节点时，就会出现这种情况。分区不会自动平衡。如果一个主题已经有许多节点等于复制因子（通常为 3），那么添加磁盘无助于重新平衡。

kafka-reassign-partitions添加新主机后使用该命令是推荐的方法。

注意事项

使用此命令有几个注意事项：

• 强烈建议您尽量减少副本更改量，以确保集群保持健康。假设不是用一个命令移动十个副本，而是一次移动两个。
• 无法使用此命令将不同步的副本制作到领导分区中。
• 如果移动了太多副本，则可能会对集群性能产生严重影响。使用该kafka-reassign-partitions命令时，请查看分区计数和大小。从那里，您可以测试各种分区大小和--throttle标志，以确定可以复制的数据量，而不会显着影响代理性能。
• 鉴于之前的限制，最好仅在所有代理和主题都健康时才使用此命令。

如何监控我的 Kafka 集群？

Cloudera Manager 监控 Kafka 集群。

目前，还有三个 GitHub 项目提供额外的监控功能：

• Doctor Kafka (Pinterest, Apache 2.0 License)
• Kafka Manager (Yahoo, Apache 2.0 License)
• Cruise Control (LinkedIn, BSD 2-clause License)

这些项目是 Apache 兼容的许可，但不是开源的（没有社区、错误归档或透明度）。

关于消费者 group.id 的最佳实践是什么？

这group.id只是一个字符串，可以帮助 Kafka 跟踪哪些消费者是相关的（通过具有相同的组 ID）。

• 一般来说，时间戳作为 的一部分group.id是没有用的。因为每个 group.id对应多个消费者，所以不能为每个消费者拥有唯一的时间戳。
• 添加任何有用的标识符。这可能与组（例如，交易、营销）、目的（欺诈、警报）或技术（Flume、Spark）有关。

如何监控消费者群体滞后？

这通常是使用kafka-consumer-groups命令行工具完成的。直接从上游文档复制，我们有这个示例输出（重新格式化以提高可读性）：

$ bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group
TOPIC  PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID       HOST     CLIENT-ID
my-topic   0           2             4         2  consumer-1-69d6 /127.0.0.1  consumer-1
my-topic   1           2             3         1  consumer-1-69d6 /127.0.0.1  consumer-1
my-topic   2           2             3         1  consumer-2-9bb2 /127.0.0.1  consumer-2

在一般情况下，如果一切都与一个特定的话题很顺利，每个消费者的 CURRENT-OFFSET应达最新或即将更新到最新与 LOG-END-OFFSET。通过此命令，您可以确定特定主机或特定分区是否在跟上数据速率方面存在问题。

如何将消费者偏移重置为任意值？

这也是使用kafka-consumer-groups命令行工具完成的。这通常是一种管理功能，用于绕过损坏的记录、数据丢失或从代理或主机的故障中恢复。除了这些特殊情况外，不建议为此目的使用命令行工具。

通过使用--execute --reset-offsets标志，您可以根据每个分区日志的开始/结束或固定时间戳将消费者组（甚至所有组）的消费者偏移更改为特定设置。键入kafka-consumer-groups不带参数的 命令将为您提供完整的帮助输出。

如何配置 MirrorMaker 以实现跨 DC 的双向复制？

Mirror Maker 是从源 Kafka 集群到目标 Kafka 集群的一个或多个主题的单向复制。鉴于 Mirror Maker 的这种限制，您需要运行两个实例，一个从 A 复制到 B，另一个从 B 复制到 A。

此外，请考虑以下事项：

• Cloudera 建议对 Mirror Maker 使用“拉”模型，这意味着写入目标的 Mirror Maker 实例正在目标集群“附近”的主机上运行。
• 主题在被复制的两个集群中必须是唯一的。
• 在安全集群上，源集群和目标集群必须在同一个 Kerberos 领域中。

消费者最大重试与超时如何工作？

使用较新版本的 Kafka，消费者可以通过两种方式与代理进行通信。

• 重试：这通常与读取数据有关。当消费者从代理读取数据时，该尝试可能会因间歇性网络中断或代理上的 I/O 问题等问题而失败。为了提高可靠性，消费者max.retries在实际读取日志偏移量失败之前重试（达到配置的值）。
• 超时。这个术语有点含糊，因为有两个与消费者相关的超时：
  • 轮询超时：这是对 的调用之间的超时 KafkaConsumer.poll()。此超时是根据您的特定用例需要的任何读取延迟要求设置的。
  • 心跳超时：新的消费者有一个“心跳线程”，它向代理（实际上是代理中的组协调器）发出心跳，让代理知道消费者还活着。这种情况定期发生，如果代理在超时期限内未收到至少一个心跳，则假定消费者已死亡并断开连接。

如何调整 Kafka 集群的大小？

调整 Kafka 集群的大小有几个注意事项。

• 磁盘空间

磁盘空间将主要由您的 Kafka 数据和代理日志组成。在调试模式下，代理日志会变得非常大（10 到 100 GB），因此保留大量空间可以为您节省一些未来的麻烦。

对于 Kafka 数据，您需要对消息大小、主题数和冗余进行估计。还请记住，您将对 Kafka 的数据使用 RAID10，因此您的一半硬盘将用于冗余。从那里，您可以计算需要多少驱动器。

通常，您希望拥有比驱动器数量建议的最少数量更多的主机。这为增长和一些可扩展性留下了空间。

• Zookeeper 节点

一个节点适用于测试集群。三是大多数 Kafka 集群的标准。在大规模上，五个节点对于可靠性来说是相当普遍的。

• 查看领导分区计数/带宽使用情况

这可能是具有最高可变性的指标。如果任何 Kafka 代理有太多的领导分区，它都会过载。在最坏的情况下，每个领导分区都需要高带宽、高消息速率，或两者兼而有之。对于其他主题，领导者分区将是经纪人可以处理的一小部分（受软件和硬件的限制）。要估计每个主机的平均值，请尝试按分区数据吞吐量要求对主题进行分组，例如 2 个高带宽数据分区、4 个中带宽数据分区、20 个小带宽数据分区。从那里，您可以确定需要多少主机。

如何将 Kafka 与 Flume 结合以摄取到 HDFS？

我们有两篇关于在 Flume 中使用 Kafka 的博文：

• 原帖：Flafka：Apache Flume 遇到 Apache Kafka 进行事件处理
• CDH 5.8/Apache Kafka 0.9/Apache Flume 1.7 的此更新版本：Cloudera Enterprise 5.8 中的新功能：Flafka 对实时数据摄取的改进

如何构建使用来自 Kafka 的数据的 Spark 流应用程序？

您需要设置开发环境以使用 Spark 库和 Kafka 库：

• 构建 Spark 应用程序
• Cloudera 的公共 GitHub 上的kafka-examples目录有一个 example pom.xml。

从那里，您应该能够使用 KafkaConsumer 类读取数据并使用 Spark 库进行实时数据处理。博客文章从 Apache Kafka 安全地读取数据到 Apache Spark有一个指向包含字数示例的 GitHub 存储库的指针。

有关更多背景信息，请阅读博客文章使用 Apache Hadoop 进行近实时数据处理的架构模式。

原文链接：https://docs.cloudera.com/cdp-private-cloud-base/7.1.6/kafka-overview/topics/kafka-overview-faq.html