作者丨Andrew Mills

編譯丨云昭

調(diào)整或擴展Kafka以獲得最佳成本和性能的第一步是了解數(shù)據(jù)流平臺如何使用資源。這里給一些實用的建議。

實現(xiàn)Apache Kafka的團隊，或者擴展他們對強大的開源分布式事件流平臺的使用，通常需要幫助理解如何根據(jù)他們的需求正確地調(diào)整和擴展Kafka資源。這可能很棘手。

無論您是在考慮云資源還是預處理硬件資源，了解Kafka集群將如何利用CPU、RAM和存儲（并了解應遵循的最佳實踐），都將使您處于一個更好的位置，可以立即獲得正確的規(guī)模。結(jié)果將是成本和性能之間的優(yōu)化平衡。讓我們來看看Kafka是如何使用資源的，瀏覽一個有指導意義的用例，以及優(yōu)化Kafka部署的最佳實踐。

1、Kafka如何利用CPU的？

一般來說，Apache Kafka在CPU利用率方面比較輕。在選擇基礎(chǔ)設(shè)施時，我傾向于擁有更多的核心而不是更快的核心，以提高并行化水平。影響CPU使用量的因素有很多，其中最主要的是SSL身份驗證和日志壓縮。其他考慮因素是每個代理擁有的分區(qū)數(shù)量、有多少數(shù)據(jù)將進入磁盤、Kafka消費者的數(shù)量（此處詳細介紹），以及這些消費者離實時性有多近。如果您的數(shù)據(jù)消費者正在獲取舊數(shù)據(jù)，那么從磁盤獲取數(shù)據(jù)將花費CPU時間。我們將在下一節(jié)中對此進行深入探討。

了解CPU使用背后的這些基本驅(qū)動因素對于幫助團隊正確確定可用CPU功率至關(guān)重要。

2、Kafka如何使用RAM的？

RAM需求主要取決于需要在內(nèi)存中保留多少“熱”數(shù)據(jù)并可用于快速訪問。一旦收到消息，Kafka就會將數(shù)據(jù)交給底層操作系統(tǒng)的頁面緩存，后者負責將數(shù)據(jù)保存到磁盤。

從大小和可伸縮性的角度來看，RAM的正確數(shù)量取決于您的用例的數(shù)據(jù)訪問模式。如果您的團隊將Kafka部署為實時數(shù)據(jù)流（使用轉(zhuǎn)換并公開消費者將在幾秒鐘內(nèi)提取的數(shù)據(jù)），則RAM需求通常很低，因為只需要在內(nèi)存中存儲幾秒鐘的數(shù)據(jù)。或者，如果您的Kafka消費者需要提取幾分鐘或幾小時的數(shù)據(jù)，那么您需要考慮RAM中需要多少數(shù)據(jù)。

CPU和RAM利用率之間的關(guān)系很重要。如果Kafka可以訪問RAM中的數(shù)據(jù)，那么它就不必花費CPU資源從磁盤中獲取數(shù)據(jù)。如果RAM中沒有可用的數(shù)據(jù)，代理程序?qū)拇疟P中提取數(shù)據(jù)，從而消耗CPU資源，并在數(shù)據(jù)傳遞中增加一些延遲。實現(xiàn)Kafka的團隊在調(diào)整CPU和RAM資源時應該考慮到這種關(guān)系。

3、Kafka如何使用存儲

有幾個因素會影響Kafka存儲需求，如保留時間、數(shù)據(jù)轉(zhuǎn)換和適當?shù)膹椭埔蛩亍？紤]這個例子：每天有幾TB的數(shù)據(jù)落在一個Kafka主題上，使用Kafka對該數(shù)據(jù)執(zhí)行六次轉(zhuǎn)換以保留中間數(shù)據(jù)，每個主題保留數(shù)據(jù)三天，復制因子設(shè)置為3。很容易看出，團隊可以根據(jù)使用Kafka的方式，將存儲的數(shù)據(jù)需求快速增加一倍、三倍或四倍。您需要充分了解這些因素才能正確確定存儲大小。

4、Kafka預定大小示例

以下是我們工作中的一個真實例子，幫助媒體娛樂行業(yè)的服務提供商正確確定預先部署的Kafka的規(guī)模。該業(yè)務的峰值吞吐量入口為每秒10GB。組織需要存儲10%的數(shù)據(jù)（每天總計9TB），并將這些數(shù)據(jù)保留30天。從復制的角度來看，該公司將存儲該數(shù)據(jù)的三個拷貝，總存儲需求為810TB。為了應對潛在的峰值，明智的做法是在預期需求的基礎(chǔ)上增加30-40%的空間，這意味著組織應該有1.2PB的可用存儲空間。它們不使用SSL，而且大多數(shù)消費者都需要實時數(shù)據(jù)，因此CPU和RAM需求不如存儲重要。他們確實有一些批處理進程在運行，但延遲不是一個問題，所以數(shù)據(jù)來自磁盤是安全的。

雖然這個特定的用例仍在構(gòu)建中，但該示例演示了使用基本數(shù)據(jù)計算給定Kafka實現(xiàn)的最小有效規(guī)模的過程，然后從中探索擴大場景的潛在需求。

5、Kafka容量規(guī)劃最佳實踐

了解給定用例的特定體系結(jié)構(gòu)——主題設(shè)計、消息大小、消息量、數(shù)據(jù)訪問模式、消費者數(shù)量等——可以提高預測大小的準確性。在考慮每個代理的適當存儲密度時，請考慮在由于熱點或代理丟失而重新分配分區(qū)期間重新流式傳輸數(shù)據(jù)所需的時間。如果你將100TB連接到Kafka代理，但它失敗了，那么你正在重新傳輸大量數(shù)據(jù)。這可能會導致網(wǎng)絡飽和，從而阻礙入口或出口流量，并導致生產(chǎn)商失敗。有一些方法可以抑制回流，但你會發(fā)現(xiàn)平均恢復時間顯著增加。         

6、常見的誤解

現(xiàn)在，越來越多的供應商為Kafka提供專有的分層存儲，并將Kafka作為數(shù)據(jù)庫或數(shù)據(jù)湖?？ǚ蚩ú皇且粋€數(shù)據(jù)庫。雖然您可以使用Kafka進行長期存儲，但您必須了解其中的權(quán)衡。

從Kafka作為實時數(shù)據(jù)流引擎到充當數(shù)據(jù)庫或數(shù)據(jù)湖的演變屬于一種熟悉的模式。專門為特定用例設(shè)計的技術(shù)有時會成為某些用戶的錘子，然后每個問題都像釘子一樣。這些用戶將嘗試修改專門構(gòu)建的工具以適應他們的用例，而不是查看已經(jīng)解決問題的其他技術(shù)。

這讓我想起了Apache Cassandra意識到來自關(guān)系世界的用戶正在努力理解數(shù)據(jù)模型在扁平行中的重要性。用戶在開始存儲數(shù)據(jù)之前不習慣理解訪問模式，他們只會在現(xiàn)有表上添加另一個索引。在Cassandra v3.0中，該項目公開了物化視圖，類似于索引關(guān)系表，但實現(xiàn)方式不同。從那時起，這個功能就充滿了問題，并被標記為實驗性的。我覺得Kafka作為數(shù)據(jù)庫或數(shù)據(jù)湖的想法注定會有類似的命運。

7、找到合適的尺寸以獲得最佳成本和Kafka性能

在沒有首先了解Kafka資源利用率的情況下匆忙進入Kafka實現(xiàn)的團隊經(jīng)常會遇到問題和障礙，這些問題和障礙教會了他們艱難的道路。通過花時間了解Kafka的資源需求，團隊將實現(xiàn)更高效的成本和性能，他們將能夠更有效地支持他們的應用程序。

參考鏈接： https://www.infoworld.com/article/3708250/how-to-size-and-scale-apache-kafka-without-tears.html