流式數(shù)據(jù)已成為企業(yè)構(gòu)建和運(yùn)營出色數(shù)據(jù)產(chǎn)品的必要條件，而 Apache Kafka 已成為實(shí)時(shí)流式傳輸?shù)臉?biāo)準(zhǔn)。

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

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

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

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

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

Confluent Cloud可減少

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

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

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

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

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

Confluent Cloud Kafka

用戶面臨的成本問題

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

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

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

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

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

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

Confluent Cloud Kafka運(yùn)營成本

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

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

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

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

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

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

HK-Acceldata 的 Kafka 儀表板圖表有助于防止代價(jià)高的消費(fèi)者滯后

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

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

總結(jié)

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

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

審核編輯：劉清