如何大规模高效地管理企业中不同的Kafka集群

如何大规模高效地管理企业中不同的Kafka集群

对于许多组织而言,Apache Kafka 是其现代数据堆栈中的关键层。Uber将事件流平台称为其技术基础设施的“基石”,每天使用 Kafka 处理数万亿条实时消息和数 PB 数据。沃尔玛、推特、腾讯和许多其他公司也是如此。

看起来是一夜成名,但是通常需要数年时间。Kafaka也不例外。Kafka 于 2011 年首次由 LinkedIn 工程师创建并开源,它必须成熟,建立一个生态系统,并抵御不乏竞争对手的事件流和消息队列平台,然后才能成为大规模可靠交付实时数据的流行选择。

同样,大多数企业对 Kafka 的采用既不是直截了当的,也不是总体规划的。大多数企业都是在不经意间开始使用Kafka的,当时个别部门或团队在涉及流媒体数据的紧急业务需求驱动下,绕过IT部门进行部署。

随着由 Google Cloud、AWS 和 Microsoft Azure 等公共云提供商托管的 Kafka 即服务以及 Confluent 提供的完全托管的 Kafka 服务的兴起,这些影子 IT 部署变得更快了。对于业务部门而言,将 Kafka 放入云端更易于部署和管理。即用即付定价也需要较少的前期投资。

规模小和不成熟的Kafka

今天,Kafaka处于一种正在酝酿中的混乱状态,持续威胁连绵不断。那是因为大多数公司仍然拥有各种小型 Kafka 集群。这些集群由不同的部门拥有,使用不同的工具和最佳实践并根据不同的 SLA 进行管理。它们还托管在不同的本地和公共数据中心和/或完全托管的服务中。一个惊人的百分比是默认的 3 节点大小。

通常没有中央团队全面负责 Kafka。如果有的话,他们很少有工具来给他们统一的可见性和控制权。

当然,像 Pinterest 这样的公司也有例外。其中央日志平台团队监督50 多个 Kafka 集群和 3,000 多个代理(服务器),平均 Kafka 集群大小为 600 个服务器节点,都运行相同版本的 Kafka (2.3.1)。

Gartner 开发了所谓的成熟度模型来衡量企业内部如何使用各种技术。Gartner 数据和分析成熟度模型如下所示。

更高的成熟度与更高的投资回报率和商业价值相关。对 Kafka 而言,问题不仅在于大多数企业在使用上并不特别成熟,而且成熟度在组织内部疯狂地乒乓球,从部门到部门,或逐个集群。因此,Kafka 为该企业产生的 ROI 也是如此。

  1. 更高的管理开销。管理 20 个三节点 Kafka 集群比管理单个 60 节点集群需要更多的时间和工作。如上所述,每个集群可能运行不同版本的 Kafka 和应用程序。它们可以使用不同的工具和 SLA 进行管理,和/或分散在各种本地和第三方云位置。Kafka 的复杂性和已经很高的操作要求加剧了这种情况。不合作的团队不会在整个公司范围内开发最佳实践。这会导致更多的工作。这最终会转化为更多的成本。
  2. 没有规模效益。单个统一客户可以将其服务器、存储和云需求捆绑在一起,以协商 Kafka 许可证的批量折扣或服务提供商的托管合同。二十个较小的客户没有这样的机会。更激进的是,公司可以将分散的小型集群整合到一个共享许可证、存储和带宽的集群中。这比必须配置多个集群更容易管理。此外,这减少了当您拥有多个集群并且对它们的可见性低时导致的昂贵重复数据的增加,即数据孤岛。并且可以在不影响安全性的情况下创建这样的多租户系统。
  3. 更多的数据盲点和数据错误。Kafka已经是出了名的难以管理。有太多选项需要手动设置和指标需要观察。即使是最有经验的 Kafka 管理员部署 Kafka 集群,也会随着时间的推移造成消费者滞后,或导致副本不同步,从而导致数据丢失。这不是管理员的错,也不是 Kafka 的错。这是异构数据管道的动态特性,可抽取大量数据并适应快速变化的业务条件。但是,如果没有对 Kafka 生产者-主题-消费者谱系等事物的集中可见性和洞察力,Kafka 管理员就不可能实时收到瓶颈和数据错误的警报。平均解决时间 (MTTR) 也会激增。问题激增,因为管理员缺乏跨基础设施、数据层和管道关联事件并预测未来问题的能力。这使得 Kafka 管理员和您的数据运营团队的其他成员处于持续的救火模式,这最终会摧毁即使是最好的团队的士气。
  4. 没有时间进行创造商业价值、导致创新停滞的变革性项目。Kafka 有可能改变您公司的运营流程和业务模式。客户个性化、供应链管理和物流、欺诈检测和网络安全等实时 Kafka 用例可以将您的公司转变为数据驱动的颠覆者。以公司 ACERTUS 为例,该公司围绕 Kafka 构建了一个自动化的端到端车队管理系统,这在第一年就产生了 1000 万美元的收入,并取代了一个主要是手动的系统。不幸的是,由于上述原因,对于大多数 Kafka 用户来说,这种潜力仍未实现。大多数 Kafka 用户甚至没有时间从过时且低效的 Lambda 架构(具有用于实时和批处理应用程序的多个管道)升级到流线型、以流为中心的 Kappa 架构。 

完全托管的Kafka的权衡

面对围绕 Kafka 的这些构建问题,一些公司已经投降,逃向完全托管的 Kafka 服务(又名 Confluent Cloud)的安全盾。将 Kafka 基础设施的全部控制权交给第三方可以极大地简化企业的工作,并部分解决上述一些问题。

但是,也有取舍。通过迁移到完全托管的服务,您正在从一个极端(Kafka 的完全手动控制和可定制性)跳跃到另一个极端,您对 Kafka 的控制要少得多,甚至比以前更少的可见性。这可能会对您的其他数据管道产生负面影响。

此外,迁移到托管 Confluent Cloud 并不是简单的迁移到云端,而是完全重构为多租户托管系统。无论有没有计划,这都可能成为长期的大规模中断,可能导致数据管道中断和输出错误。

最后,Confluent Cloud 的低运维要求也意味着用户对您的成本的可见性和控制力较低。如今,随着大量事件通过 Kafka 流式传输,迁移到 Confluent Cloud 的用户面临着类似的风险。

更好的方法:数据可观察性

HongKe提供了一个一站式解决方案,赋予企业对Kafka以及其总是变化的数据管道的持续可见性。我们的 Kafka 仪表板可预测并预防潜在问题,在出现问题时立即提醒您,并使您能够安全地对 Kafka 集群和其他基础设施进行成本优化

例如,HongKe 帮助数据工程师监控可能导致副本在 Kafka 中不同步的不稳定和瓶颈,它们增加数据丢失的机会。如果 Kafka 设置为存档 7 天,而消费者已经滞后 4 天,那么 HongKe 可以主动向 Kafka 管理员发送警报,以便在任何数据丢失之前采取行动

Kafka 集群的另一个常见问题是主题(来自流的事件集合)可能会变得不平衡或倾斜。这是因为 Kafka 尝试在多个 Broker(服务器)之间同步 Topics 以实现容错备份并保持管道性能。使用 HongKe,可以轻松维护失败或减速的经纪人的全局视图,从而导致主题变得倾斜。

我们的最新功能(例如针对主题沿袭的 Kafka 可观察性实用程序 Kapxy)提供了对 Kafka 性能问题和瓶颈的根本原因的精细可见性,并优化了性价比。

客户案例

这是一家遭受上述四个 Kafka 问题的公司的示例,以及它如何使用HongKe解决这些问题。 

‍ PubMatic是美国最大的广告技术公司之一,每天提供 2000 亿次广告展示并处理 2 PB 的新数据。这种实时数据流的核心是 Kafka,它包括 50 个小型 Kafka 集群,每个集群中有 10-15 个以上的节点。 

对于 Pubmatic 来说,这种横向扩展的、完全不同的基础设施是典型的,多年来它一直处于超大规模模式以跟上业务需求。不幸的是,这也意味着 Kafka 和 Hadoop 等关键任务技术(其 150 PB、由 Kafka 提供的 3,000 个节点的服务器)非常脆弱,经常出现中断、性能瓶颈和高 MTTR。日常救火是常态,结果是高昂的运营、基础设施和 OEM 支持成本。   

因此,PubMatic部署了 HongKe的数据可观察性平台,并立即提高了对其复杂、互连的数据管道、存储库和基础设施(包括 Kafka)网络的可见性。这使 Pubmatic 能够预测和防止瓶颈和数据错误,同时还可以优化其数据管道(包括 Kafka)的性能。 

除了消除其工程部门的日常救火工作外,PubMatic 还大力整合了其 Kafka 集群,从而降低了许可证、基础设施和管理成本。PubMatic 还将其总体支持成本降低了 1000 万美元,并将其 Hadoop 存储空间减少了 30%。 

结论

部署数据可观察性平台是获得对不同 Kafka 集群的控制权以便大规模有效管理它们的第一步。

获得这些好处并不需要公司完全集中如何使用和管理 Kafka。对于 Pubmatic 等公司而言,积极整合其 Kafka 集群以减少 Kafka 服务器许可证、重复数据和数据管道的数量以及集中管理是有意义的。 

其他公司可以选择一种不那么激进的方法:在中央数据操作或 IT 团队与个人企业所有者之间共享所有权。团队可以合作创建最具有商业意义的 SLA 和成本模型。鼓励服务器整合和多租户架构,但不是强制性的。 

这种方法(例如JP Morgan Chase 将其称为数据网格)为数据堆栈提供了一种操作替代方案,支持业务敏捷性、规模经济以及 Kafka 服务器和数据管道的优化环境。

此外,公司可以将 HongKe 与完全托管的 Kafka 解决方案(例如 Confluent Cloud)一起使用。HongKe 提供了大量功能,通过自动化数据准备、验证等,使复杂的迁移更加安全和轻松。一旦数据迁移到 Confluent Cloud,HongKe 就可以提供额外的可见性和对性能和成本优化的控制,这是本机缺乏的。

无论您最终对 Kafka 采取哪种方法,HongKe 都将提供巨大的好处。

发表评论