流式數(shù)據(jù)已成為企業(yè)構(gòu)建和運營出色數(shù)據(jù)產(chǎn)品的必要條件，而 Apache Kafka 已成為實時流式傳輸?shù)臉藴省?/p>

雖然采用 Kafka 變得至關(guān)重要，但在如何部署 Kafka 時，數(shù)據(jù)團隊有多種選擇。

Kafka 最初是安裝在服務(wù)器上的開源軟件。復(fù)雜且高度可配置的 Kafka 早期使用者親身感受了管理 Kafka 集群的困難、耗時和昂貴。那些還在使用本地 Kafka 的用戶正在采用諸如“數(shù)據(jù)可觀測性平臺”之類的解決方案，以賦予他們對環(huán)境的自動可見性和控制權(quán)。

除此之外，其他公司正在轉(zhuǎn)向云計算，其中有很多選擇，每一種都為 Kafka 提供不同級別的VIP服務(wù)。為此，我們可以將 Kafka 服務(wù)分為兩個基本類別：

1.Kafka即服務(wù)：用戶的 Kafka 集群被提升并轉(zhuǎn)移到托管服務(wù)提供商，如 AWS、Cloudera、Red Hat (IBM) 或 Azure，后者處理大部分基礎(chǔ)設(shè)施管理，包括供應(yīng)、配置和維護服務(wù)器。為了保障安全，每個用戶的 Kafka 實例都托管在他們自己的物理服務(wù)器上，采用單租戶架構(gòu)。盡管在云中，用戶仍然保留對其 Kafka 環(huán)境的大部分控制權(quán)——這意味著用戶仍然有責任對 Kafka 環(huán)境進行管理。

2.完全托管的 Kafka：由Confluent Cloud首創(chuàng)。Confluent Cloud 幾乎消除了運行 Kafka 的所有操作麻煩，同時提供了開發(fā)人員喜歡的即時可擴展性和簡單可靠的可靠性。正如Confluent Cloud 發(fā)布者 Kai Waehner 自夸的那樣：“如果 Kafka 軟件是汽車引擎，那么托管 Kafka 或 Kafka-as-a-service 就是汽車，這使得 Confluent Cloud 相當于一輛自動駕駛汽車”。

Confluent Cloud可減少

企業(yè)運營Kafka的成本

作為完全托管 Kafka 的標準承載者，Confluent Cloud 確實提供了用戶想要的任何風格的 Kafka，包括本地、混合和托管即服務(wù)。Confluent Cloud 認識到，許多用戶根本沒有準備好從一個極端（Kafka 的完全手動控制和可定制性）跳到另一個極端（在無服務(wù)器 Confluent Cloud 中對 Kafka 的控制較少，甚至可見性更低）。

Kafka 的成本，除了硬件之外，還包括管理和開發(fā)應(yīng)用程序的成本。因此，對于公司而言，仍有大量機會簡化其 Kafka 環(huán)境并優(yōu)化其成本提高性價比。

在Kafka-as-a-single-tenant-service（Kafka單租戶服務(wù)）的情況下，用戶的操作復(fù)雜性仍然很高。盡管托管服務(wù)提供商會自動執(zhí)行任務(wù)，例如引入新的 Kafka 集群，但仍需要監(jiān)控很多儀表板、做出部署決策、優(yōu)化數(shù)據(jù)瓶頸、修復(fù)數(shù)據(jù)錯誤以及進行存儲管理等。為了減輕運營負擔并提高動態(tài) Kafka 環(huán)境的性價比，本地和混合用戶的連續(xù)數(shù)據(jù)可觀測性可以使托管的 Kafka 用戶從中獲益。

完全托管的 Kafka 用戶是否面臨相同的運營成本？Confluent Cloud 回復(fù)說：“并不會。Confluent Cloud 的后端規(guī)模經(jīng)濟、近乎零的管理要求、即時和自動的用戶彈性可以幫助用戶節(jié)省巨額的總擁有成本 (TCO) 轉(zhuǎn)化為巨大的總擁有成本 (TCO) 。從Forrester TEI 的2022報告可知，相較于自我管理和部署Kafka，使用Confluent Cloud可幫助企業(yè)在三年內(nèi)節(jié)省 260 萬美元。

Confluent Cloud Kafka

用戶面臨的成本問題

Confluent的承諾也反映了 Snowflake的—承諾其三年的投資回報率為2100萬美元。低運維、高度可擴展的云數(shù)據(jù)倉庫已被開發(fā)人員和數(shù)據(jù)驅(qū)動的公司所采納。由于云數(shù)據(jù)倉具有敏捷性特征，可以大大加快企業(yè)產(chǎn)品上市時間，用戶將“低運維”誤認為是“無運維”。這是因為他們忽略了價值工程和云計算運營的基本原則，也忽略了運營監(jiān)督，例如監(jiān)控成本、設(shè)置成本護欄等。

在Snowflake 使用中有一個著名的案例，該案例錯誤地配置了一個長達 7 小時的代碼測試，導(dǎo)致Snowflake收取用戶72,000 美元的費用。同時，其他 Snowflake 用戶發(fā)現(xiàn)成本優(yōu)化不是自動的，仍然需要他們付出大量的努力和監(jiān)督成本。

基于此，Snowflake 用戶被迫嘗試各種解決方案，從 Snowflake 的內(nèi)置資源監(jiān)視器到可視化的第三方儀表板和報告以及許多其他工具。然而，即使將這些工具拼湊在一起，也無法為用戶提供持續(xù)的可見性、預(yù)測性和成本控制功能，更不用說數(shù)據(jù)可靠性和數(shù)據(jù)性能等其他應(yīng)用了。

同樣，在 Confluent Cloud 的“動態(tài)即用即付”收費模式中優(yōu)化成本既不簡單，也不會自動進行。流數(shù)據(jù)量可以瞬間飆升至每秒10 GB。要想監(jiān)控和防止這種潛在的成本超支，非常不容易。雖然 Confluent Cloud Console 可以實時顯示初步使用情況，但實際上，用戶的成本將滯后6到24小時。

雖然 Confluent Cloud 使用戶能夠圍繞數(shù)據(jù)性能問題創(chuàng)建實時觸發(fā)器和警報，且不會造成成本超支。但如果開發(fā)人員忘記關(guān)閉大容量測試流數(shù)據(jù)管道，或者采取保守的歸檔策略導(dǎo)致存儲費用增加，這可能是Confluent Cloud將面臨的問題。同時，Confluent Cloud 用戶在支付每月使用費前，不會注意到這個問題。

數(shù)據(jù)可觀測性如何幫助用戶減少

Confluent Cloud Kafka運營成本

對于想要認真監(jiān)控和管理其 Confluent Cloud 環(huán)境的用戶，Confluent建議他們尋找第三方提供商，而像HK-Acceldata這樣的企業(yè)數(shù)據(jù)可觀測性平臺就可以為其服務(wù)。

HK-Acceldata 通過 Confluent Cloud 的 API 獲取成本和性能指標，通過自己的監(jiān)控生成額外的分析，然后將兩者結(jié)合起來以創(chuàng)建進一步的見解、警報和建議。下面介紹一下HK-Acceldata 幫助用戶防止成本超支并優(yōu)化成本的五種方式：

1)為 Confluent Cloud 數(shù)據(jù)管道的性能和使用情況提供持續(xù)可見性和警報。在實時數(shù)據(jù)流下，處理、發(fā)送和存儲的事件量會急劇增加，尤其是在 Confluent Cloud 的即時、多 GB 可擴展的情況下。HK-Acceldata的計算可觀察性有助于監(jiān)控可能造成的數(shù)據(jù)瓶頸以及導(dǎo)致進程崩潰的數(shù)據(jù)峰值。HK-Acceldata 還提供實時視圖，幫助用戶選擇正確數(shù)量的分區(qū)和主題，以優(yōu)化用戶的性價比。

2）生產(chǎn)者-主題-沿襲可見性。HK-Acceldata 的Kapxy工具可讓 Confluent Cloud 用戶進一步了解 Kafka 的三個關(guān)鍵組件——生產(chǎn)者、主題和消費者。因此，用戶可以從端到端更精細地跟蹤數(shù)據(jù)。通過深入了解數(shù)據(jù)的實際流動方式，用戶可以準確計算管道、應(yīng)用程序或企業(yè)各部門的使用情況和成本，不僅可以實現(xiàn)準確的成本退款、ROI 計算，還可以支持數(shù)據(jù)管道重用和其他價值工程工作。

使用 HK-Acceldata 跟蹤 Confluent Cloud 中的數(shù)據(jù)路徑

3）監(jiān)控和防止消費者滯后。Kafka中最大的潛在問題之一是攝取的數(shù)據(jù)與下游應(yīng)用程序或使用者接收的數(shù)據(jù)存在差距。如果差距過大，那么存儲在Kafka代理中的數(shù)據(jù)可能會在傳輸成功之前就自動過期。HK-Acceldata 提供高級別的可見性，可在用戶的整個Confluent Cloud數(shù)據(jù)管道中查找潛在問題，例如找到離線和復(fù)制不足的分區(qū)、最大和最偏斜的主題、不同步的副本數(shù)量是否在增長以及滯后最多的消費者組等。用戶也可以深入了解消費者組或查看單個事件，所有這些可見性都可以幫助用戶防止成本滯后，不需要用戶通過昂貴的計算或存儲來解決這個問題。

HK-Acceldata 的 Kafka 儀表板圖表有助于防止代價高的消費者滯后

?4) 防止數(shù)據(jù)丟失。如上所述，Consumer Lag和其他瓶頸不僅會直接增加用戶的處理成本，還會導(dǎo)致數(shù)據(jù)丟失。這是因為用戶可以控制 Kafka Brokers（服務(wù)器）存儲數(shù)據(jù)的時間長度。如果數(shù)據(jù)瓶頸或延遲持續(xù)時間過長，則代理可能會在數(shù)據(jù)成功傳輸?shù)较M者應(yīng)用程序之前清除數(shù)據(jù)。HK-Acceldata 的監(jiān)控儀表板可幫助用戶診斷數(shù)據(jù)丟失的原因，而Kapxy等工具可以精確定位丟失的數(shù)據(jù)及其的位置。

5) 清理、驗證和轉(zhuǎn)換流數(shù)據(jù)。將HK-Acceldata與Kafka和Confluent Cloud 管道一起使用，可以實時攝取、驗證和轉(zhuǎn)換事件以提高用戶的數(shù)據(jù)質(zhì)量和可靠性。同時，還減少了搜索和修復(fù)數(shù)據(jù)錯誤的時間，用戶也不需要對有問題的數(shù)據(jù)管道和應(yīng)用程序進行故障排除，這大大降低了企業(yè)的運營成本，投資回報率顯著提升。

總結(jié)

上述企業(yè)數(shù)據(jù)可觀測性平臺HK-Acceldata 5個優(yōu)勢也有助于簡化舊 Kafka 環(huán)境到 Confluent Cloud 的遷移過程。因為Confluent Cloud與本地或托管的單租戶Kafka集群有很大不同，任何遷移對用戶的環(huán)境而言都是從頭開始，而不是簡單的提升和轉(zhuǎn)移。HK-Acceldata 的自動化數(shù)據(jù)準備和監(jiān)控可以使遷移變得輕松且順利，同時也可以調(diào)整資源以匹配工作區(qū)和 SLA 要求，從而平衡性能與成本。

總之，如果使用完全托管的 Confluent Cloud ，公司仍然需要對運營成本進行監(jiān)督，而HK-Acceldata Data Observability for Kafka 解決方案可以很好的解決這一問題。Confluent Cloud 的用戶可以使用HK-Acceldata等連續(xù)數(shù)據(jù)可觀測性平臺為其提供的額外可見性和監(jiān)控，從而降低用戶的總擁有成本（TCO）。

審核編輯：劉清