使用数据可观测性减少Confluent Cloud Kafka 运营成本的五种方式-德赢Vwin官网网

Kafka 服务类别

流式数据已成为企业构建和运营出色数据产品的必要条件，而 Apache Kafka 已成为实时流式传输的标准。

虽然采用 Kafka 变得至关重要，但在如何部署 Kafka 时，数据团队有多种选择。

Kafka 最初是安装在服务器上的开源软件。复杂且高度可配置的 Kafka 早期使用者亲身感受了管理 Kafka 集群的困难、耗时和昂贵。那些还在使用本地 Kafka 的用户正在采用诸如“数据可观测性平台”之类的解决方案，以赋予他们对环境的自动可见性和控制权。

除此之外，其他公司正在转向云计算，其中有很多选择，每一种都为 Kafka 提供不同级别的VIP服务。为此，我们可以将 Kafka 服务分为两个基本类别：

1.Kafka即服务：用户的 Kafka 集群被提升并转移到托管服务提供商，如 AWS、Cloudera、Red Hat (IBM) 或 Azure，后者处理大部分基础设施管理，包括供应、配置和维护服务器。为了保障安全，每个用户的 Kafka 实例都托管在他们自己的物理服务器上，采用单租户架构。尽管在云中，用户仍然保留对其 Kafka 环境的大部分控制权——这意味着用户仍然有责任对 Kafka 环境进行管理。

2.完全托管的 Kafka：由Confluent Cloud首创。Confluent Cloud 几乎消除了运行 Kafka 的所有操作麻烦，同时提供了开发人员喜欢的即时可扩展性和简单可靠的可靠性。正如Confluent Cloud 发布者 Kai Waehner 自夸的那样：“如果 Kafka 软件是汽车引擎，那么托管 Kafka 或 Kafka-as-a-service 就是汽车，这使得 Confluent Cloud 相当于一辆自动驾驶汽车”。

Confluent Cloud可减少

企业运营Kafka的成本

作为完全托管 Kafka 的标准承载者，Confluent Cloud 确实提供了用户想要的任何风格的 Kafka，包括本地、混合和托管即服务。Confluent Cloud 认识到，许多用户根本没有准备好从一个极端（Kafka 的完全手动控制和可定制性）跳到另一个极端（在无服务器 Confluent Cloud 中对 Kafka 的控制较少，甚至可见性更低）。

Kafka 的成本，除了硬件之外，还包括管理和开发应用程序的成本。因此，对于公司而言，仍有大量机会简化其 Kafka 环境并优化其成本提高性价比。

在Kafka-as-a-single-tenant-service（Kafka单租户服务）的情况下，用户的操作复杂性仍然很高。尽管托管服务提供商会自动执行任务，例如引入新的 Kafka 集群，但仍需要监控很多仪表板、做出部署决策、优化数据瓶颈、修复数据错误以及进行存储管理等。为了减轻运营负担并提高动态 Kafka 环境的性价比，本地和混合用户的连续数据可观测性可以使托管的 Kafka 用户从中获益。

完全托管的 Kafka 用户是否面临相同的运营成本？Confluent Cloud 回复说：“并不会。Confluent Cloud 的后端规模经济、近乎零的管理要求、即时和自动的用户弹性可以帮助用户节省巨额的总拥有成本 (TCO) 转化为巨大的总拥有成本 (TCO) 。从Forrester TEI 的2022报告可知，相较于自我管理和部署Kafka，使用Confluent Cloud可帮助企业在三年内节省 260 万美元。

Confluent Cloud Kafka

用户面临的成本问题

Confluent的承诺也反映了 Snowflake的—承诺其三年的投资回报率为2100万美元。低运维、高度可扩展的云数据仓库已被开发人员和数据驱动的公司所采纳。由于云数据仓具有敏捷性特征，可以大大加快企业产品上市时间，用户将“低运维”误认为是“无运维”。这是因为他们忽略了价值工程和云计算运营的基本原则，也忽略了运营监督，例如监控成本、设置成本护栏等。

在Snowflake 使用中有一个著名的案例，该案例错误地配置了一个长达 7 小时的代码测试，导致Snowflake收取用户 72,000 美元的费用。同时，其他 Snowflake 用户发现成本优化不是自动的，仍然需要他们付出大量的努力和监督成本。

基于此，Snowflake 用户被迫尝试各种解决方案，从 Snowflake 的内置资源监视器到可视化的第三方仪表板和报告以及许多其他工具。然而，即使将这些工具拼凑在一起，也无法为用户提供持续的可见性、预测性和成本控制功能，更不用说数据可靠性和数据性能等其他应用了。

同样，在 Confluent Cloud 的“动态即用即付”收费模式中优化成本既不简单，也不会自动进行。流数据量可以瞬间飙升至每秒10 GB。要想监控和防止这种潜在的成本超支，非常不容易。虽然 Confluent Cloud Console 可以实时显示初步使用情况，但实际上，用户的成本将滞后6到24小时。

虽然 Confluent Cloud 使用户能够围绕数据性能问题创建实时触发器和警报，且不会造成成本超支。但如果开发人员忘记关闭大容量测试流数据管道，或者采取保守的归档策略导致存储费用增加，这可能是Confluent Cloud将面临的问题。同时，Confluent Cloud 用户在支付每月使用费前，不会注意到这个问题。

数据可观测性如何帮助用户减少

Confluent Cloud Kafka运营成本

对于想要认真监控和管理其 Confluent Cloud 环境的用户，Confluent建议他们寻找第三方提供商，而像HK-Acceldata这样的企业数据可观测性平台就可以为其服务。

HK-Acceldata 通过 Confluent Cloud 的 API 获取成本和性能指标，通过自己的监控生成额外的分析，然后将两者结合起来以创建进一步的见解、警报和建议。下面介绍一下HK-Acceldata 帮助用户防止成本超支并优化成本的五种方式：

1)为 Confluent Cloud 数据管道的性能和使用情况提供持续可见性和警报。在实时数据流下，处理、发送和存储的事件量会急剧增加，尤其是在 Confluent Cloud 的即时、多 GB 可扩展的情况下。HK-Acceldata的计算可观察性有助于监控可能造成的数据瓶颈以及导致进程崩溃的数据峰值。HK-Acceldata 还提供实时视图，帮助用户选择正确数量的分区和主题，以优化用户的性价比。

2）生产者-主题-沿袭可见性。HK-Acceldata 的Kapxy工具可让 Confluent Cloud 用户进一步了解 Kafka 的三个关键组件——生产者、主题和消费者。因此，用户可以从端到端更精细地跟踪数据。通过深入了解数据的实际流动方式，用户可以准确计算管道、应用程序或企业各部门的使用情况和成本，不仅可以实现准确的成本退款、ROI 计算，还可以支持数据管道重用和其他价值工程工作。

使用 HK-Acceldata 跟踪 Confluent Cloud 中的数据路径

3）监控和防止消费者滞后。Kafka中最大的潜在问题之一是摄取的数据与下游应用程序或使用者接收的数据存在差距。如果差距过大，那么存储在Kafka代理中的数据可能会在传输成功之前就自动过期。HK-Acceldata 提供高级别的可见性，可在用户的整个Confluent Cloud数据管道中查找潜在问题，例如找到离线和复制不足的分区、最大和最偏斜的主题、不同步的副本数量是否在增长以及滞后最多的消费者组等。用户也可以深入了解消费者组或查看单个事件，所有这些可见性都可以帮助用户防止成本滞后，不需要用户通过昂贵的计算或存储来解决这个问题。

HK-Acceldata 的 Kafka 仪表板图表有助于防止代价高的消费者滞后

‍4) 防止数据丢失。如上所述，Consumer Lag和其他瓶颈不仅会直接增加用户的处理成本，还会导致数据丢失。这是因为用户可以控制 Kafka Brokers（服务器）存储数据的时间长度。如果数据瓶颈或延迟持续时间过长，则代理可能会在数据成功传输到消费者应用程序之前清除数据。HK-Acceldata 的监控仪表板可帮助用户诊断数据丢失的原因，而Kapxy等工具可以精确定位丢失的数据及其的位置。

5) 清理、验证和转换流数据。将HK-Acceldata与Kafka和Confluent Cloud 管道一起使用，可以实时摄取、验证和转换事件以提高用户的数据质量和可靠性。同时，还减少了搜索和修复数据错误的时间，用户也不需要对有问题的数据管道和应用程序进行故障排除，这大大降低了企业的运营成本，投资回报率显著提升。

总结

上述企业数据可观测性平台HK-Acceldata 5个优势也有助于简化旧 Kafka 环境到 Confluent Cloud 的迁移过程。因为Confluent Cloud与本地或托管的单租户Kafka集群有很大不同，任何迁移对用户的环境而言都是从头开始，而不是简单的提升和转移。HK-Acceldata 的自动化数据准备和监控可以使迁移变得轻松且顺利，同时也可以调整资源以匹配工作区和 SLA 要求，从而平衡性能与成本。

总之，如果使用完全托管的 Confluent Cloud ，公司仍然需要对运营成本进行监督，而HK-Acceldata Data Observability for Kafka 解决方案可以很好的解决这一问题。Confluent Cloud 的用户可以使用HK-Acceldata等连续数据可观测性平台为其提供的额外可见性和监控，从而降低用户的总拥有成本（TCO）。

审核编辑黄昊宇

声明：本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人，不代表德赢Vwin官网网立场。文章及其配图仅供工程师学习之用，如有内容侵权或者其他违规问题，请联系本站处理。举报投诉

虹科电子

虹科电子

+关注

关注
0

文章
601

浏览量
14339
kafka

kafka

+关注

关注
0

文章
51

浏览量
5214

超详细“零”基础kafka入门篇

，类似于消息队列或企业消息传递系统。以容错的持久方式存储记录流。记录发生时处理流。（2）Kafka通常用于两大类应用：构建可在系统或应用程序之间可靠获取数据的实时流数据

发表于 12-18 09:50 •131次阅读

华为云全栈可观测平台——9 月 10 月新功能特性

数据等多维度可观测性数据源，提供应用资源统一管理、一站式可观测性分析和自动化运维方案，帮助用户及

发表于 12-01 16:12 •315次阅读

eBPF技术实践之virtio-net网卡队列可观测

时，这一路径难以进行观测。一些复杂的网络抖动问题很可能是由于网卡队列不正常工作引起的。为了解决这类问题，我们基于eBPF技术扩展了网卡队列的可观测能力，使得virtio网卡前后端的定界问题不再困扰。 virtio-net 前后端驱动简介 virtio-net （后面称为

发表于 11-14 11:18 •192次阅读

破局新生丨基调听云可观测性与应用安全技术研讨会在平潭圆满举办

2024年10月24日，由中国信通院稳定性保障实验室、华为云、基调听云联合主办的“破局新生·可观测性与应用安全技术研讨会”在福建平潭隆重举行。本次研讨会以技术研讨为本，以创新发展为翼，汇集了来自金融

发表于 10-29 16:01 •380次阅读

【质量视角】可观测性背景下的质量保障思路

目前质量团队正在积极建设和完善应用监控能力，旨在能及时发现并解决问题，为线上服务稳定性保驾护航。随着可观测性概念的逐渐普及，监控的建设也有了新的挑战和使命。本文将探讨在可观测性背景下，

发表于 10-25 17:21 •249次阅读

Kafka高性能背后的技术原理

Kafka 是一款性能非常优秀的消息队列，每秒处理的消息体量可以达到千万级别。

发表于 10-23 09:37 •314次阅读

华为云发布全栈可观测平台 AOM，以 AI 赋能应用运维可观测

应用可用性与稳定性。该平台发布标志着华为云在推动数字化转型和智能化运维领域的又一重大突破，全栈可观测平台的推出不仅为企业提供了更加全面和深入的系统监控和数据分析能力，还通过集成先进的人工智能技术，实现了对复杂应用环境的实时优化

发表于 10-15 09:54 •515次阅读

Commvault Cloud平台提供Cloud Rewind功能

混合云企业网络弹性和数据保护解决方案领先提供商Commvault（纳斯达克代码：CVLT）宣布在Commvault Cloud平台上提供Cloud Rewind功能。这项独特的产品集成了通过收购

发表于 10-15 09:21 •349次阅读

DataDog和Dynatrace缺席，观测云成为中国峰会的明星

在亚马逊云科技中国峰会的圆满落幕之际，国内监控观测服务的佼佼者——观测云，以其在中国可观测性领域的杰出表现，荣获了中国峰会独家荣誉。尽管全球知名的监控

发表于 06-04 17:13 •415次阅读

面试官：Kafka会丢消息吗？

许多开发人员普遍认为，Kafka 的设计本身就能保证不会丢失消息。然而，Kafka 架构和配置的细微差别会导致消息的丢失。我们需要了解它如何以及何时可能丢失消息，并防止此类情况的发生。

发表于 04-29 17:32 •1012次阅读

少走弯路不踩坑 Datadog 的替代品来了

年十大战略技术趋势之一。可观测性技术在国外的应用已非常成熟，通常构建可观测性最快速和高效的方式是使用云厂商或者第三方平台企业提供的解决方案

发表于 03-05 09:45 •467次阅读

Redis流与Kafka相比如何？

我们先来看看Kafka的基本架构。基本的数据结构是主题。它是一个按时间排序的记录序列，只需追加。使用这种数据结构的好处在Jay Kreps的经典博文The Log中得到了很好的描述。

发表于 02-21 16:09 •464次阅读

如何构建APISIX基于DeepFlow的统一可观测性能力呢？

随着应用组件的可观测性逐渐受到重视，Apache APISIX 引入插件机制丰富了可观测数据源。

发表于 01-18 10:11 •976次阅读

kafka基本原理详解

今天浩道跟大家分享一篇关于kafka相关原理的硬核干货，可以说即使你没有接触过kafka，也可以秒懂，一起看看！

发表于 01-03 09:57 •882次阅读

kafka支持哪些消息交付语义？

在读完kafka官方文档，kafka设计里的消息交付语义一章后，给我的第一印象是内容很抽象，于是草拟和总结了给个副标题，并把相关内容进行了归类；有些生涩的句子，尽量用大白话和举例进行说明，并加入了总结。

发表于 12-22 11:27 •485次阅读