面對 Kafka 規模快速增長帶來的成本、效率和穩定性挑戰時，小紅書大數據儲存團隊采取雲原生架構實踐：透過引入冷熱數據分層儲存、容器化技術以及自研的負載均衡服務「Balance Control」，成功實作了集群儲存成本的顯著降低、分鐘級的集群彈性遷移、高效能的數據存取策略和自動化的資源排程。
這些技術革新不僅極大提升了 Kafka 集群的運維效率，還為小紅書業務帶來了更優質的服務體驗，同時為未來在存算分離、多活容災等方向的進一步最佳化奠定了基礎。
一、背景介紹
1、小紅書 Kafka 的發展現狀
小紅書 Kafka 集群規模伴隨著公司業務的蓬勃發展而顯著擴張。目前，集群的峰值吞吐量已經達到 TB 級別，並且隨著 AI 大模型和大數據技術的持續擴充套件，數據量仍在快速增長。
盡管經典的 Apache Kafka 架構在提供高吞吐、高效能數據傳輸方面表現出色，但也逐漸暴露出了一些弊端。一方面，基於多副本和雲盤/SSD 的模式，Apache Kafka 的儲存成本居高不下，難以滿足業務長期儲存數據的需要；另一方面，數據與計算節點之前的強繫結關系，嚴重阻礙了集群的擴縮容效率，在彈性和排程能力方面受到了很大的挑戰。
2、面臨的問題
隨著小紅書 Kafka 集群規模的持續擴大，一系列挑戰也隨之而來，涉及成本、能效、運維和系統穩定性等多個方面：
成本：
儲存成本昂貴： Kafka 的儲存成本較高，按當前內部機器規格配比，在充分利用頻寬的情況下，數據儲存的生命周期非常有限。
算力資源浪費： Kafka 的效能瓶頸主要集中在 IO 操作上，存在大量的 CPU 資源處於閑置狀態。加之現有的虛擬機器部署方式在資源共享和隔離方面表現不佳，進一步限制了 CPU 資源的有效分配。
效率：
集群運維耗時長： 因磁盤和節點繫結，Kafka 集群的擴縮容需要搬遷海量數據，這不僅速度緩慢，而且耗時可能從數天到數周不等。
排程能力弱： 因虛機部署，缺乏靈活的資源排程能力，一旦壞機，補貨效率低。
穩定性：
應急能力差： 緩慢的擴縮容速度導致效能指標在高負載下顯著下降，請求響應時間可能延長至正常情況的兩倍，影響整體服務品質。
追趕讀期間穩定性受損： 在追趕讀操作期間，系統資源的大量消耗會使得資源使用率飆升，從而影響到即時讀寫任務的穩定性
綜上所述，Kafka 集群面臨的主要痛點可歸納為兩個核心問題：存算一體化架構的局限性，以及虛擬機器部署方式帶來的運維和資源排程難題。解決這些問題，對於提升 Kafka 集群的整體效能和運維效率，具有重要意義。
3、解決方案
1）如何解決「存算一體化」帶來的問題？
為了解決存算一體化架構弊端，我們需要引入「Cloud-Native」彈性架構模式，來解耦儲存與計算，下述為方案對比：
①自研存算分離（on ObjectStore）：
該方案透過物件儲存作為統一的儲存基礎，實作了計算層與數據繫結關系的解耦。儲存層利用物件儲存的糾刪碼技術和規模經濟效應，能同時獲得秒級彈性與成本兩大收益，是較為理想的解決方案。
然而，物件儲存本身延遲較高，想要達到整體較高的效能，需要有獨立的讀寫加速層配合，這一部份也需要考慮彈性化的架構設計。整體架構復雜度較高，因此方案研發周期會比較長。
②冷熱分層儲存（on ObjectStore）：
冷熱分層的概念，即為本地僅保留少量的熱數據，將大部份冷數據解除安裝到較為便宜的物件儲存中，以實作成本節約。Kafka 和其他 MQ 類社群，近年來陸續提出該概念並進行發展。
此架構不改變數據核心的寫入流程和高可用性（HA）機制，而是異步解除安裝數據以減少對核心架構的改動，實作難度較低。不過弊端也正是因為沒有觸動核心的副本機制，數據與計算節點之間仍然存在部份的耦合，在彈效能力方面稍遜一籌。
③Apache Pulsar
Apache Pulsar 是近年來非常火熱的一款雲原生訊息引擎，它天生支持存算分離架構，具備快速的彈性擴充套件特性，同樣是一個選擇。不過其底下的儲存底座 Bookkeeper 仍然基於磁盤儲存，單節點受限於磁盤容量，在儲存成本上沒有明顯收益（但 Pulsar 近期也引入了分層儲存能力）。此外，考慮到歷史大量的存量作業，轉向 Pulsar 可能面臨較高的推廣難度和替換周期，眼下難以快速拿到收益。
在當前階段，「成本」是我們最關心的問題。如何獲得大量成本節省？如何縮短收益獲取周期？都是需要核心考慮的因素。 在經過大量對比和取舍後，「分層儲存」架構依靠其低成本、中等彈性、短落地周期的特點，成為了我們當下的最佳選擇。
與社群版本相比，小紅書分層架構經過了完全的重新設計，解決了原有方案的多項問題，並顯著提升了數據遷移速度和冷數據讀取效能。在新架構上線六個月內，我們已完成線上 80% 的集群升級覆蓋，充分地獲得了新架構帶來的各項收益。
2）如何解決「虛機部署」帶來的問題？
為了解決虛機部署帶來的問題，關鍵在於提升混部與排程能力、最佳化算力資源的使用、以及增強自動化運維的水平。以下是幾種方案的對比分析：
綜合考慮，采用小紅書容器底座結合 PaaS 平台托管的新型容器化架構，不僅能夠平滑地將 Kafka 遷移至雲端，還能顯著提升算力資源的利用率，加強運維自動化。
二、雲原生Kafka的設計與實作
1、整體架構
小紅書 Kafka 雲原生架構共分為四層：
接入層： 小紅書 Kafka 特色 SDK，提供鑒權、限流、服務發現等豐富功能，實作更加靈活和安全的數據流管理
計算層： Kafka Broker 基於「分層儲存」技術，實作本地數據「弱狀態化」，有效地解決了系統的彈性問題，保障系統的穩定性和可延伸性
排程層： 負載均衡排程器向北可均衡 Broker 間流量負載，向南結合容器實作自動化彈性擴縮容，保障系統能夠根據實際需求動態調整資源，實作 「彈性伸縮、按量付費」
基建層： 容器和物件儲存底座，為整個系統提供了強大的 PaaS 平台化運維管理排程能力和低成本無限儲存能力
2、分層儲存
分層儲存作為 Kafka 雲原生化的核心能力，提供成本最佳化、消費隔離、彈性擴充套件等多重優勢。其整體架構如下圖所示。基本原理是基於冷熱分層，即將近即時的熱數據保留在高效能雲盤中，而將冷數據下沈至低成本、可靠性極高的物件儲存中。
物件儲存具有無限擴充套件、低成本、可靠性極高的特點。透過利用物件儲存來儲存數據，我們能夠從根本上解決不斷增長的數據儲存需求，擺脫了傳統數據儲存所帶來的諸多煩惱。物件儲存的架構設計理念，使其在處理大規模數據時表現出色，同時確保了數據的高可用性和安全性，為 Kafka 架構的雲原生化提供了強大的支撐。
1）儲存成本最佳化
在大數據場景下，業務方經常需要回溯過去多天的數據，以進行各種分析、回溯和審計等操作。然而，傳統的基於雲盤的 Kafka 儲存解決方案不僅成本高昂，而且在儲存能力上也存在限制，只能滿足短期數據的儲存需求，這對於需要長期數據保留的業務場景構成了重大挑戰。
為了突破這一瓶頸，我們采用基於物件儲存的分層儲存架構。這一創新舉措顯著降低了儲存成本並提升了數據儲存的靈活性。物件儲存的低成本特性，結合其出色的擴充套件能力，使得小紅書 Kafka 能夠經濟高效地儲存大量數據，同時保證了數據的高可靠性和安全性。
在實施分層儲存架構的過程中，我們采取了以下策略：
冷數據儲存： 將不常存取的冷數據遷移到成本更低的物件儲存中，從而大振幅減少儲存開支。
熱數據儲存： 對於頻繁存取的熱數據，繼續使用效能較高的雲盤儲存（EBS），但透過最佳化儲存策略，將儲存容量減少了75%。
透過這種新型的儲存架構，小紅書 Kafka 實作了儲存成本的大振幅降低——最高可達 60%。此外，這種架構還允許 Topic 的儲存時間從原來的 1 天延長至 7 天或更久，極大地增強了業務數據的回溯能力，為業務數據驅動決策提供更加堅實的基礎。
2）分鐘級彈性遷移
在 Kafka 原生架構中，集群擴容是一個復雜且耗時的過程。由於冷數據儲存在磁盤上，擴容時需要搬遷海量數據，這不僅會導致磁盤和網路 IO 的負載達到極限，也會對集群的穩定性造成影響。
我們引入了分層儲存機制後，Topic 的所有副本可以共享同一份冷數據。這意味著對於 Topic 的新副本，在集群擴容時不再需要復制 Leader 原生的所有熱數據，而只需拷貝遠端尚未擁有的部份，通常是 Leader 本地儲存的最後一個 segment。
這種最佳化顯著減少了遷移數據的量，從而將 Topic 遷移的時間從天級別縮短到分鐘級別。在實際套用場景中，即使是對於具有 10GB/s 吞吐量的 Topic，在流量高峰期的遷移過程也僅需 5 分鐘即可完成。
3）高效能緩存策略
引入物件儲存後，雖然解決了儲存成本和彈性等問題，但也面臨了一些挑戰，主要包括存取速度和延遲等方面，具體表現為：
存取速度： 物件儲存的總吞吐上限理論只受頻寬限制，但單執行緒存取速度較低，遠遠低於傳統磁盤儲存。
延遲： 目前物件儲存主要透過 HTTP 協定進行存取，因此存在較高的延遲，包括建立連線等操作的延遲可達到 20 毫秒級別，對於部份小檔存取極不友好。
針對這些問題，我們采取了以下最佳化策略：
批次讀取： 以 8MB 對齊的方式讀取 Segment 數據，減少存取次數，從而提升數據讀取的效率。
緩存預載入： 結合數據存取的局部性原理和訊息佇列的順序讀特性，實作了並行的預讀機制，以提高數據的存取速度和響應性。同時，透過記憶體隔離技術，避免了 pagecache 被汙染的問題。
這些策略的實施帶來了顯著的效能提升：
高緩存命中率： 緩存命中率達到了 99%，有效地提高了數據存取的效率和速度。
效能提升： 冷數據讀取效能相比開源架構提升了 30%，這在大規模數據處理場景中尤為重要。
3、容器化
下圖為小紅書 Kafka 容器化的整體架構：
PaaS 能力托管： 透過小紅書容器化排程 PaaS 平台來托管 Kafka 集群，這不僅簡化了部署和運維流程，降低了運維成本，而且透過圖形化界面實作了集群版本和配置的直觀管理，即所謂的「白屏化操作」。
服務狀態管理： 為了保證有狀態套用服務的連續性和狀態的一致性，我們采用 DupicateSet(StatefulSet) 來管理 Kafka 服務。
異常保護機制：
基於 Supervisord 的行程監控： 在容器內部，Supervisord 作為主要的行程管理工具，監控 Kafka 行程。一旦 Kafka 行程異常結束，Supervisord 能夠迅速重新開機行程，避免了容器級別的重建，從而減少了服務中斷時間。
快速修復（HotFix）： 當基礎環境如數據儲存出現問題時，業務團隊可以直接進入容器進行快速修復，這種即時的幹預能力大大提高了系統的穩定性和恢復速度。
集群狀態的刪除保護： 我們實作了基於 Kafka 集群狀態的刪除防護機制。當集群中掉隊例項的數量超過預設閾值時，透過 Webhook 技術自動拒絕所有可能惡化集群狀態的操作請求，從而保護集群不受進一步損害。
1）狀態管理
在 Kubernetes 環境中部署有狀態服務如 Kafka 時，確保其狀態的永續性和可靠性是至關重要的。
Kafka 的狀態主要包括拓撲狀態和儲存狀態，以下是對這兩部份狀態的管理策略：
拓撲狀態： 拓撲狀態涉及 Pod 的網路和身份標識，確保每個 Pod 具有固定的標識和存取方式。我們透過容器底座提供的能力保障了 Pod IP 不變。
儲存狀態： 儲存狀態包括雲盤數據、日誌數據和配置檔等，這些數據需要在 Pod 遷移、重新開機或升級時保持不變。
持久卷（PV）和持久卷聲明（PVC）： 使用 DupicateSet 使用，為每個 Pod 分配專用的儲存資源，確保儲存狀態的永續性和一致性。
配置管理： 使用 ConfigMap 和環境變量來管理 Kafka 的配置，確保 Pod 即使重新開機，配置也能保持不變。
日誌管理： 將日誌目錄放置在持久化數據卷中，保障日誌數據在 Pod 重新開機或遷移時不會遺失。
2）離線混部
在上雲之前，Kafka 作為儲存產品，面臨著單機 CPU 能效低下的問題，大約只有 10% 的效率，這主要是由於夜間流量低谷以及 IO-bound 特性所致。在這種情況下，往往存在大量的閑置 CPU 資源，導致資源利用率不高。
上雲後透過容器提供的混部能力，我們可以將離線業務排程至 Kafka Kubernetes 機器池中，填平 CPU 低谷，從而保證全天利用率達到一個較高的水平。這種整合策略顯著提升了資源的全天利用率，上雲後的能效利用率提高到了 40% 以上，遠高於之前的水平。
利用容器技術的混部能力，使得我們能夠更加靈活地管理和排程資源，根據實際情況對資源進行動態分配和利用，從而最大限度地提高了系統的整體效能和資源利用率。
3）CA 資源排程
除了上述提及能力外，容器技術還為我們帶來了資源層面的彈性排程能力，其中 Cluster Autoscaler（CA）是一項關鍵技術。
在未采用 Cluster Autoscaler 的傳統模式下，系統工程師（SRE）需要手動執行伺服器的啟動和關閉操作，這不僅效率低下，而且在面對緊急的擴容需求時，現有的流程顯得繁瑣且響應遲緩，無法及時適應業務需求的波動。
引入 Cluster Autoscaler 之後，這一狀況得到了根本性的改善。CA 能夠自動管理業務集群的擴縮容流程，以緩沖區（Buffer）的形式智慧地調整資源分配。它透過即時監控集群的負載情況，動態地增加或減少節點數量，實作了快速且精準的資源彈性排程。這種自動化的排程機制不僅提升了系統的適應力和穩定性，而且顯著降低了運維團隊的工作負擔，確保了業務的持續穩定執行。
4、彈性排程
線上上部署的 Apache Kafka 集群中，流量波動、Topic 的增減以及 Broker 的啟動與關閉是常態。這些動態變化可能導致集群中節點的流量分布不均衡，進而引起資源浪費和影響業務的穩定性。為了解決這一問題，需要對 Topic 的分區進行主動調整，以實作流量和數據的均衡分配。
原生 Apache Kafka 由於磁盤上儲存大量歷史數據，因此在進行均衡排程時會打滿磁盤 IO 和網路頻寬，從而影響即時業務的正常執行，導致集群負載均衡較為困難。
相比之下，分層的彈性架構則為負載均衡提供了可能。這種架構設計使得在進行負載均衡排程時可以避免過多的 IO 壓力，從而減少對即時業務的影響，使得負載均衡的調整更加靈活和高效。
因此，除了分層和容器兩大關鍵 『彈性』 技術，我們還自研了負載均衡服務 「Balance Control」，其能夠充分利用分層和容器的軟硬體彈效能力，實作持續數據平衡和自動彈性擴縮容，使得集群能夠更加靈活地應對流量波動和業務變化，從而保障了系統的穩定性和可靠性。
1）持續數據自平衡（Auto-Balancing）
Balance Control 采用多目標最佳化演算法來實作資源分配的最佳化。其能夠綜合考慮 Topic 副本、網路頻寬、磁盤儲存、計算資源等多種因素，自動調整 Partition 分配，以達到最佳的資源負載平衡。整體自平衡流程如下：
數據采集： Kafka 側 Metrics Reporter 監聽 Kafka 內建的所有指標資訊，並定期對感興趣的指標（如網路進出口流量、CPU 利用率等）進行采樣，並上報指標
指標聚合： 收集的指標用於生成集群狀態快照 ClusterModel，包括 Broker 狀態、Broker 資源容量、各 Broker 管理的 Topic-Partition 流量資訊等
排程決策自平衡： 排程決策器定期獲取集群狀態模型的快照，並根據各個 Broker 的容量和負載資訊，辨識出流量過高或過低的 Broker。隨後，它會嘗試移動或交換分區，以完成流量的重新平衡。
2）自動彈性擴縮容（Auto-Scaling）
原生 Kafka 擴容需要搬遷海量數據，耗時通常為小時甚至天級，幾乎無法做到按需擴縮容。為了維持集群的穩定性，運維團隊不得不提前規劃資源，以應對可能的流量高峰，這種做法往往導致資源的浪費和效率的降低。
雲原生時代，透過借助分層和容器的軟硬體彈效能力，Balance Control 可以在分鐘級自動完成集群的原地擴縮容和流量的重新排程，以適應業務負載的變化， 做到 「彈性伸縮、按量付費」 的目標。 這一關鍵能力我們稱之為 AutoScala。
AutoScala：即時監控 Kafka 集群的負載，並根據預設的策略自動調整集群規模。 例如，當集群負載超過某個閾值（如 70%）並保持一段時間時，系統會自動增加集群規模；從而實作快速、高效的集群擴縮容，最佳化資源利用率。
整體流程如下：
負載監控： Kubernetes 的 Horizontal Pod Autoscaler（HPA）元件根據預設的策略（如定時、資源水位等）來判斷是否需要擴容，並相應地調整集群規模配置。
自動負載均衡： 當 Balance Control 探測到新加入的 Broker，分鐘級完成流量排程平衡。
三、總結與展望
總體來看，雲原生彈性架構為小紅書 Kafka 帶來了巨大的成本收益和運維效率提升。從落地效果上看，我們實作了 60% 的儲存成本節省和 10 倍的擴縮容運維效率提升，並成功實作了「彈性伸縮、按量付費」的商品化模式。
此外，我們正不斷探索和最佳化雲原生訊息引擎的能力，以期提供更穩定和高效的服務。未來，我們計劃持續研究存算分離技術和多活容災方案，以實作極致的系統可延伸性和穩定性，滿足業務日益增長的服務需求。
隨著技術的不斷演進，我們將不斷引入新的技術能力和創新方案，為業務提供更加卓越的訊息引擎服務，期待您加入團隊！
作者介紹
六娃(張億皓)， 小紅書大數據儲存架構團隊負責人，現負責小紅書流儲存引擎 Kafka、分布式檔加速系統等領域建設。
劍塵(黃章衡)， 小紅書訊息引擎內核研發專家，Apache RocketMQ Committer & SOFASTACK SOFAJRaft Committer，現負責小紅書 Kafka 分層儲存、負載均衡、存算分離等技術領域建設。
阿坎(焦南)， 小紅書訊息引擎內核研發專家，現負責小紅書 Kafka 流批一體、容器化等生態探索和建設。
來源丨公眾號： 小紅書技術REDtech （ID： gh_f510929429e3 ）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
