Kafka 服務(wù)類(lèi)別

流式數(shù)據(jù)已成為企業(yè)構(gòu)建和運(yùn)營(yíng)出色數(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ù)器上的開(kāi)源軟件。復(fù)雜且高度可配置的 Kafka 早期使用者親身感受了管理 Kafka 集群的困難、耗時(shí)和昂貴。那些還在使用本地 Kafka 的用戶正在采用諸如“數(shù)據(jù)可觀測(cè)性平臺(tái)”之類(lèi)的解決方案，以賦予他們對(duì)環(huán)境的自動(dòng)可見(jiàn)性和控制權(quán)。

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

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)。盡管在云中，用戶仍然保留對(duì)其 Kafka 環(huán)境的大部分控制權(quán)——這意味著用戶仍然有責(zé)任對(duì) Kafka 環(huán)境進(jìn)行管理。

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

Confluent Cloud可減少

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

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

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

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

完全托管的 Kafka 用戶是否面臨相同的運(yùn)營(yíng)成本？Confluent Cloud 回復(fù)說(shuō)：“并不會(huì)。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 萬(wàn)美元。

Confluent Cloud Kafka

用戶面臨的成本問(wèn)題

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

在Snowflake 使用中有一個(gè)著名的案例，該案例錯(cuò)誤地配置了一個(gè)長(zhǎng)達(dá) 7 小時(shí)的代碼測(cè)試，導(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)告以及許多其他工具。然而，即使將這些工具拼湊在一起，也無(wú)法為用戶提供持續(xù)的可見(jiàn)性、預(yù)測(cè)性和成本控制功能，更不用說(shuō)數(shù)據(jù)可靠性和數(shù)據(jù)性能等其他應(yīng)用了。

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

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

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

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

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

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

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

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

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

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

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

?4) 防止數(shù)據(jù)丟失。如上所述，Consumer Lag和其他瓶頸不僅會(huì)直接增加用戶的處理成本，還會(huì)導(dǎo)致數(shù)據(jù)丟失。這是因?yàn)橛脩艨梢钥刂?Kafka Brokers（服務(wù)器）存儲(chǔ)數(shù)據(jù)的時(shí)間長(zhǎng)度。如果數(shù)據(jù)瓶頸或延遲持續(xù)時(shí)間過(guò)長(zhǎng)，則代理可能會(huì)在數(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í)間，用戶也不需要對(duì)有問(wèn)題的數(shù)據(jù)管道和應(yīng)用程序進(jìn)行故障排除，這大大降低了企業(yè)的運(yùn)營(yíng)成本，投資回報(bào)率顯著提升。

總結(jié)

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

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

審核編輯 黃昊宇