服务咨询
全天高效服务
- Tel:13533491614
对于许多组织而言,Apache Kafka 是其现代数据堆栈中的关键层。Uber将事件流平台称为其技术基础设施的“基石”,每天使用 Kafka 处理数万亿条实时消息和数 PB 数据。沃尔玛、推特、腾讯和许多其他公司也是如此。
看起来是一夜成名,但是通常需要数年时间。Kafaka也不例外。Kafka 于 2011 年首次由 LinkedIn 工程师创建并开源,它必须成熟,建立一个生态系统,并抵御不乏竞争对手的事件流和消息队列平台,然后才能成为大规模可靠交付实时数据的流行选择。
同样,大多数企业对 Kafka 的采用既不是直截了当的,也不是总体规划的。大多数企业都是在不经意间开始使用Kafka的,当时个别部门或团队在涉及流媒体数据的紧急业务需求驱动下,绕过IT部门进行部署。
随着由 Google Cloud、AWS 和 Microsoft Azure 等公共云提供商托管的 Kafka 即服务以及 Confluent 提供的完全托管的 Kafka 服务的兴起,这些影子 IT 部署变得更快了。对于业务部门而言,将 Kafka 放入云端更易于部署和管理。即用即付定价也需要较少的前期投资。
今天,Kafaka处于一种正在酝酿中的混乱状态,持续威胁连绵不断。那是因为大多数公司仍然拥有各种小型 Kafka 集群。这些集群由不同的部门拥有,使用不同的工具和最佳实践并根据不同的 SLA 进行管理。它们还托管在不同的本地和公共数据中心和/或完全托管的服务中。一个惊人的百分比是默认的 3 节点大小。
通常没有中央团队全面负责 Kafka。如果有的话,他们很少有工具来给他们统一的可见性和控制权。
当然,像 Pinterest 这样的公司也有例外。其中央日志平台团队监督50 多个 Kafka 集群和 3,000 多个代理(服务器),平均 Kafka 集群大小为 600 个服务器节点,都运行相同版本的 Kafka (2.3.1)。
Gartner 开发了所谓的成熟度模型来衡量企业内部如何使用各种技术。Gartner 数据和分析成熟度模型如下所示。
更高的成熟度与更高的投资回报率和商业价值相关。对 Kafka 而言,问题不仅在于大多数企业在使用上并不特别成熟,而且成熟度在组织内部疯狂地乒乓球,从部门到部门,或逐个集群。因此,Kafka 为该企业产生的 ROI 也是如此。
面对围绕 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 都将提供巨大的好处。