<div id="readability-page-1"><div>Coban 是 Grab 的實時數據流平台團隊，一直致力於圍繞 Kafka 構建生態系統，服務於 Grab 各個業務領域。平台作為 Grab 數據湖的入口，從不同服務中採集數據，進行存儲與後續分析。它支持事件的實時處理和分析，這對於許多應用和服務至關重要。平台每小時可處理數 TB 級數據流，具備高吞吐、低延遲與高可用性。<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>https://static001.geekbang.org/infoq/8f/8f217d60d2c921b82733be57918a0c61.webp<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>圖 1：Grab 的數據流平台除了穩定性和性能，成本效率也是團隊非常關注的重點事項。本文將介紹 Coban 團隊是如何通過引入 AutoMQ，提升 Grab 數據流平台的效率並有效降低成本的。<h2>痛點陳述</h2>過去，在數據流平台上遇到的主要挑戰包括以下四個方面：<ul><li>計算資源擴容困難：其中一個主要挑戰是計算資源的擴容問題，尤其是在分區遷移時，容易引發資源使用量激增，影響操作靈活性。</li></ul><ul><li>磁盤無法獨立擴容，導致操作複雜性增加：各個代理節點的磁盤使用情況差異較大，增加存儲空間時，需要集羣擴容或者增加代理節點的磁盤，然而這兩種方案並非理想選擇。</li></ul><ul><li>基於峯值的過度配置，導致資源浪費：目前的資源配置是基於峯值需求，這導致非高峰時段的雲資源未得到最優利用，從而增加成本並降低效率。</li></ul><ul><li>高風險的分區再平衡：在集羣維護期間，分區再平衡往往會導致較長時間的延遲增加，進而影響系統的整體性能和用户體驗。</li></ul>面對這些挑戰，需要一種能夠有效解決上述問題的方案。基於此，團隊提出了以下需求，並選擇了 AutoMQ：<ul><li>良好的彈性：希望能夠動態調整計算資源，既能應對高峰期的需求，又能應對低谷期的變化，且不會造成系統中斷。</li></ul><ul><li>存儲和計算分離：需要具備獨立擴展存儲的能力，以高效應對業務的彈性需求和持續增長。</li></ul><ul><li>與 Kafka 的高度兼容：與 Grab 現有數據流平台的無縫集成至關重要，能夠避免大規模的系統改造和中斷。</li></ul><ul><li>快速穩定的分區遷移能力：在流量激增時，快速重新分配大分區的能力對於保證系統性能和可靠性是至關重要的。</li></ul><ul><li>低延遲：支持現有的延遲敏感型 Kafka 使用場景是優先考慮的事項，確保平穩的用户體驗。</li></ul><img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>https://static001.geekbang.org/infoq/e3/e356763f4edceadd1b6b8c4a0ff23bce.webp<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>圖 2：新數據流平台願望清單<h2>解決方案</h2>為了解決前文提到的挑戰並滿足業務需求，團隊引入了 AutoMQ，一款具備高彈性與卓越性能的雲原生 Kafka 解決方案。<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>https://static001.geekbang.org/infoq/24/24dfdfcd63896c63569eeb33d9d0116f.webp<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>圖 3：採用 AutoMQ 的新數據流架構圖 3 展示了引入 AutoMQ 之後，數據流平台的新架構。由於 AutoMQ 與 Apache Kafka® 100% 兼容，因此可以輕鬆地從原有架構平滑切換至基於 AutoMQ 的新架構。AutoMQ 採用基於 EBS WAL 和 S3 的共享存儲架構。通過使用固定大小的 EBS 作為 WAL，系統可以在不增加額外成本的情況下，提供極高性能和極低延遲的寫入能力。同時，所有寫入的數據都會存儲在 S3 Bucket 中，從而充分利用 S3 所帶來的高可靠性、彈性與成本優勢。<h2>為什麼選擇 AutoMQ?</h2>集羣可快速、高效擴容在過去的架構中，Kafka 採用的是副本機制，然而這種方式下的計算彈性並不理想。當節點之間進行數據遷移時，數據需要在不同的 Broker 間傳輸，往往會帶來性能波動和運維挑戰。而在 AutoMQ 中，數據存儲在跨 Broker 的共享存儲層中。當集羣需要擴容或縮容時，AutoMQ 無需在 Broker 之間遷移分區數據，只需幾秒鐘即可完成分區的重新分配，實現真正快速、平滑的集羣擴展。AutoMQ 採用按需擴展的 S3 共享存儲AutoMQ 通過對象存儲（如 S3）來保存數據。S3 是一種按需擴展的存儲服務，當需要更長的數據保留期時，無需再像以往那樣手動擴展 Broker 或本地磁盤，從而顯著降低了運維成本和操作複雜度。快速的分區重新分配能力使用 AutoMQ 重新分配大規模分區的過程非常迅速，僅需同步少量元數據即可完成切換。這一優勢源自 AutoMQ 的雲原生架構設計。與 Apache Kafka® 依賴 ISR 多副本機制來保障數據持久性不同，AutoMQ 將數據持久化託管給雲存儲服務。由於雲存儲本身具備多副本與糾刪碼機制，天然提供高可靠性和高可用性，因此 AutoMQ 無需在 Broker 層引入多副本結構。AutoMQ 遵循“雲優先（Cloud-First）”的設計理念，將傳統的硬件依賴型架構轉向以雲服務為核心的架構，充分釋放雲端的彈性與性能潛力。低延遲低延遲是 Grab 實時數據流平台提升用户體驗的關鍵。儘管對象存儲服務（如 S3）並非為低延遲寫入而設計，AutoMQ 巧妙地利用固定大小（10GB）的 EBS 塊存儲，實現了毫秒級（個位數毫秒）寫入延遲。它通過使用 Direct I/O 技術繞過文件系統的寫入開銷，並依託雲原生架構避免內部分區副本帶來的網絡開銷，從而實現了極高的寫入性能與穩定性。100% Kafka 兼容性AutoMQ 複用了 Apache Kafka® 的計算層代碼，並通過了所有官方測試用例，真正實現了完全兼容（100% Compatibility）。這意味着可以在不調整現有 Kafka 基礎設施或重寫客户端代碼的情況下，平滑切換至 AutoMQ，從而大幅降低架構遷移的成本與風險。<h2>評估與生產環境部署</h2>為確保 AutoMQ 能夠滿足預期，團隊從性能、可靠性和成本效益三個維度對其進行了全面評估。首先是性能測試。在不同配置下進行了多輪基準測試，例如調整副本因子（replication factor）和生產者確認機制（acknowledgement configuration）等，以評估其在不同負載場景下的表現是否符合需求。通過這些測試，希望深入瞭解 AutoMQ 的性能特性，識別潛在的優化空間或使用中需要注意的細節。在可靠性方面，同樣設計了多種測試用例和基準測試場景，來驗證系統在不同類型故障下的表現。例如，模擬計劃內維護時的平滑切換（graceful failover）以及突發基礎設施故障下的應急恢復，從而確保系統能夠在各種情況下保持穩定運行。最後，評估成本效益。AutoMQ 在各項測試中表現出色，通過了所有基準測試和用例驗證。基於這些結果，團隊對其在生產環境中的可行性充滿信心，並決定在 Grab 的實際業務場景中引入 AutoMQ 進行正式部署。過去，團隊主要使用開源社區的 Kafka Operator Strimzi 在 Kubernetes 上管理和運維 Kafka 集羣。為了支持與 AutoMQ 的集成，擴展了該 Operator 的功能，新增了 WAL Volume 的創建、掛載與授權，並實現了 AutoMQ 與 Strimzi 的無縫對接。此外，團隊還系統學習了 AutoMQ 相關知識，例如 S3 存儲機制、WAL 相關指標等，以便在生產環境中更高效地使用和管理 AutoMQ 集羣。<h2>使用效果 </h2>引入 AutoMQ 後，數據流平台在以下多個方面取得了顯著提升：<ul><li>吞吐量大幅提升：隨着數據複製從 Broker 之間遷移至雲端存儲複製，觀察到單核 CPU 吞吐量提升了 3 倍。就吞吐量而言，該集羣目前已成為 Grab 內部服務矩陣中規模最大的集羣之一。</li></ul><ul><li>成本效益提升：初步統計顯示，整體成本效益提高了 3 倍。</li></ul><ul><li>分區重新分配效率提升：在過去，整個集羣的分區重新分配的耗時可能需要長達 6 小時，而現在不到 1 分鐘即可完成。</li></ul><img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>https://static001.geekbang.org/infoq/17/17478d2ee0722a73c62000a753053d77.webp<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>圖 4：過去設置下擴展 Broker 時的性能表現<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>https://static001.geekbang.org/infoq/77/7728c927ed013f10ff479568556ae134.webp<img src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" original-src="https://imageproxy.pbkrs.com/https://www.infoq.cn/article/null"/>圖 5：新的 AutoMQ 設置下擴展 Broker 時的性能表現圖 4 和圖 5 展示了新舊兩種架構在執行 Broker 彈性伸縮時，關鍵性能指標的變化差異。採用 AutoMQ 的新架構不僅可以極快地完成擴容，同時帶來的性能波動更小，集羣整體更加穩定。在引入 AutoMQ 的共享存儲架構後，與過去的架構相比，實現了極快的分區重新分配——每次分配僅需數秒即可完成。得益於此，Broker 的穩定性也得到了增強，因為在分區遷移的過程中無需再在 Broker 之間複製數據。這意味着 I/O 和網絡利用率都不會再出現激增，數據也無需在 Broker 之間移動，因此集羣更加穩定，在運維操作中也不會出現性能尖峯了。由於分區重新分配的速度非常快，這也顯著減少了對客户端的影響，無論是生產者（Producer）還是消費者（Consumer），在擴容或遷移期間幾乎不再出現延遲上升的現象。此外，得益於共享存儲架構，現在可以獨立擴展存儲資源。在舊架構下，如果需要增加存儲容量，必須新增 Broker 節點或為單個 Broker 擴容磁盤。這不僅導致了不必要的計算資源浪費（新增節點的計算能力往往被閒置），還會在擴容時觸發集羣再平衡。這一操作會造成生產者與消費者客户端的延遲上升和系統穩定性下降。<h2>未來展望 </h2>在引入 AutoMQ 後，已經在多個方面獲得了顯著收益。接下來，團隊還計劃進一步優化整體效率。首先，希望進一步提高計算資源利用率。AutoMQ 內置了一項尚未啓用的功能——自動均衡（Self-Balancing）。這一功能與 Apache Kafka® 常用的一款開源工具 Cruise Control 類似。“自動均衡” 會根據需要定期自動觸發分區再均衡，使集羣的計算能力在高峰與低谷時段都能靈活應對，從而實現更高效的資源調度。其次，將持續優化成本效益。既然現在能夠容忍更頻繁的中斷，並且執行分區重新分配的成本不再高昂或幾乎可以忽略不計，因此可以着眼於自動擴縮容（auto scaling）與搶佔式實例（spot instances），以實現成本節約。在業務高峰期，集羣可以擴容應對；而在非高峰或低負載時段，能夠自動縮容，這將進一步提高資源利用效率和成本效益。團隊還在探索使用 AutoMQ 的 S3 WAL 流式存儲引擎，來減少客户端和 Broker 之間的跨可用區（cross AZ）流量。此外，AutoMQ 還提供了一個名為 Table Topic的功能，它允許 Topic 的流式數據以 Iceberg 表格式直接存儲在 S3 上，並且可以充分利用 AWS 最新發布的 S3 Table 功能。團隊正計劃對此進行深入研究，以便在引入 Table Topic 後，能夠減少一些不再需要的數據管道冗餘。最後，鑑於 AutoMQ 在 Grab 內部的出色表現，團隊計劃在更多業務場景中推廣其應用，將更多數據流用例遷移到 AutoMQ 上，進一步釋放其潛能。</div></div>

GRAB

新加坡出行巨頭 Grab 如何用 AutoMQ 重塑 Kafka 流平台