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