流式數據已成為企業構建和運營出色數據產品的必要條件，而 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）。

審核編輯：劉清