作者丨Andrew Mills
編譯丨雲昭
調整或擴展Kafka以獲得最佳成本和性能的第一步是了解數據流平台如何使用資源。這裡給一些實用的建議。
實現Apache Kafka的團隊，或者擴展他們對強大的開源分布式事件流平台的使用，通常需要幫助理解如何根據他們的需求正確地調整和擴展Kafka資源。這可能很棘手。
無論您是在考慮雲資源還是預處理硬體資源，了解Kafka集群將如何利用CPU、RAM和存儲（並了解應遵循的最佳實踐），都將使您處於一個更好的位置，可以立即獲得正確的規模。結果將是成本和性能之間的優化平衡。讓我們來看看Kafka是如何使用資源的，瀏覽一個有指導意義的用例，以及優化Kafka部署的最佳實踐。
1、Kafka如何利用CPU的？
一般來說，Apache Kafka在CPU利用率方面比較輕。在選擇基礎設施時，我傾向於擁有更多的核心而不是更快的核心，以提高並行化水平。影響CPU使用量的因素有很多，其中最主要的是SSL身份驗證和日誌壓縮。其他考慮因素是每個代理擁有的分區數量、有多少數據將進入磁碟、Kafka消費者的數量（此處詳細介紹），以及這些消費者離實時性有多近。如果您的數據消費者正在獲取舊數據，那麼從磁碟獲取數據將花費CPU時間。我們將在下一節中對此進行深入探討。
了解CPU使用背後的這些基本驅動因素對於幫助團隊正確確定可用CPU功率至關重要。
2、Kafka如何使用RAM的？
RAM需求主要取決於需要在內存中保留多少「熱」數據並可用於快速訪問。一旦收到消息，Kafka就會將數據交給底層作業系統的頁面緩存，後者負責將數據保存到磁碟。
從大小和可伸縮性的角度來看，RAM的正確數量取決於您的用例的數據訪問模式。如果您的團隊將Kafka部署為實時數據流（使用轉換並公開消費者將在幾秒鐘內提取的數據），則RAM需求通常很低，因為只需要在內存中存儲幾秒鐘的數據。或者，如果您的Kafka消費者需要提取幾分鐘或幾小時的數據，那麼您需要考慮RAM中需要多少數據。
CPU和RAM利用率之間的關係很重要。如果Kafka可以訪問RAM中的數據，那麼它就不必花費CPU資源從磁碟中獲取數據。如果RAM中沒有可用的數據，代理程序將從磁碟中提取數據，從而消耗CPU資源，並在數據傳遞中增加一些延遲。實現Kafka的團隊在調整CPU和RAM資源時應該考慮到這種關係。
3、Kafka如何使用存儲
有幾個因素會影響Kafka存儲需求，如保留時間、數據轉換和適當的複製因素。考慮這個例子：每天有幾TB的數據落在一個Kafka主題上，使用Kafka對該數據執行六次轉換以保留中間數據，每個主題保留數據三天，複製因子設置為3。很容易看出，團隊可以根據使用Kafka的方式，將存儲的數據需求快速增加一倍、三倍或四倍。您需要充分了解這些因素才能正確確定存儲大小。
4、Kafka預定大小示例
以下是我們工作中的一個真實例子，幫助媒體娛樂行業的服務提供商正確確定預先部署的Kafka的規模。該業務的峰值吞吐量入口為每秒10GB。組織需要存儲10%的數據（每天總計9TB），並將這些數據保留30天。從複製的角度來看，該公司將存儲該數據的三個拷貝，總存儲需求為810TB。為了應對潛在的峰值，明智的做法是在預期需求的基礎上增加30-40%的空間，這意味著組織應該有1.2PB的可用存儲空間。它們不使用SSL，而且大多數消費者都需要實時數據，因此CPU和RAM需求不如存儲重要。他們確實有一些批處理進程在運行，但延遲不是一個問題，所以數據來自磁碟是安全的。
雖然這個特定的用例仍在構建中，但該示例演示了使用基本數據計算給定Kafka實現的最小有效規模的過程，然後從中探索擴大場景的潛在需求。
5、Kafka容量規劃最佳實踐
了解給定用例的特定體系結構——主題設計、消息大小、消息量、數據訪問模式、消費者數量等——可以提高預測大小的準確性。在考慮每個代理的適當存儲密度時，請考慮在由於熱點或代理丟失而重新分配分區期間重新流式傳輸數據所需的時間。如果你將100TB連接到Kafka代理，但它失敗了，那麼你正在重新傳輸大量數據。這可能會導致網絡飽和，從而阻礙入口或出口流量，並導致生產商失敗。有一些方法可以抑制回流，但你會發現平均恢復時間顯著增加。
6、常見的誤解
現在，越來越多的供應商為Kafka提供專有的分層存儲，並將Kafka作為資料庫或數據湖。卡夫卡不是一個資料庫。雖然您可以使用Kafka進行長期存儲，但您必須了解其中的權衡。
從Kafka作為實時數據流引擎到充當資料庫或數據湖的演變屬於一種熟悉的模式。專門為特定用例設計的技術有時會成為某些用戶的錘子，然後每個問題都像釘子一樣。這些用戶將嘗試修改專門構建的工具以適應他們的用例，而不是查看已經解決問題的其他技術。
這讓我想起了Apache Cassandra意識到來自關係世界的用戶正在努力理解數據模型在扁平行中的重要性。用戶在開始存儲數據之前不習慣理解訪問模式，他們只會在現有表上添加另一個索引。在Cassandra v3.0中，該項目公開了物化視圖，類似於索引關係表，但實現方式不同。從那時起，這個功能就充滿了問題，並被標記為實驗性的。我覺得Kafka作為資料庫或數據湖的想法註定會有類似的命運。
7、找到合適的尺寸以獲得最佳成本和Kafka性能
在沒有首先了解Kafka資源利用率的情況下匆忙進入Kafka實現的團隊經常會遇到問題和障礙，這些問題和障礙教會了他們艱難的道路。通過花時間了解Kafka的資源需求，團隊將實現更高效的成本和性能，他們將能夠更有效地支持他們的應用程式。
參考連結： https://www.infoworld.com/article/3708250/how-to-size-and-scale-apache-kafka-without-tears.html