MemQ：可替代Kafka的高效、可擴充套件的雲原生PubSub系統

這篇博文介紹了 MemQ，這是一種為 Pinterest 的雲開發的高效、可擴充套件的 PubSub 系統，自 2020 年中期以來一直為我們提供近實時資料傳輸用例，並補充了 Kafka，同時成本效率提高了 90%。

Kafka問題

近十年來，Pinterest 一直依賴 Apache Kafka作為唯一的 PubSub 系統。隨著 Pinterest 的發展，資料量和運營超大規模分散式 PubSub 平臺的挑戰也隨之增加。大規模執行 Apache Kafka 讓我們對如何構建可擴充套件的 PubSub 系統有了很多瞭解。在對我們的 PubSub 環境的操作和可擴充套件性挑戰進行深入調查後，我們得出了以下關鍵要點：

1. 不是每個資料集都需要亞秒級延遲服務，延遲和成本應該成反比（較低的延遲應該花費更多）
2. PubSub 系統的 Storage 和 Serving 元件需要分離，以實現基於資源的獨立可擴充套件性。
3. 讀取而不是寫入的排序為特定的消費者用例提供了所需的靈活性（不同的應用程式對於相同的資料集可以有不同的）
4. 在大多數情況下，Pinterest 不需要嚴格的分割槽排序，並且通常會導致可擴充套件性挑戰。
5. Kafka 中的重新平衡代價高昂，通常會導致效能下降，並對飽和叢集上的客戶產生負面影響。
6. 在雲環境中執行自定義複製的成本很高。

2018 年，我們試驗了一種新型的 PubSub 系統，它可以原生地利用雲。2019 年，我們開始正式探索如何解決我們的 PubSub 可擴充套件性挑戰的選項，並根據運營成本以及現有技術的再造成本評估了多種 PubSub 技術以滿足 Pinterest 的需求。我們最終得出的結論是，我們需要一種 PubSub 技術，該技術建立在 Apache Kafka、Apache Pulsar 和 Facebook LogDevice 的學習基礎上，並且是為雲而構建的。

MemQ出世 

MemQ 是一個新的 PubSub 系統，它增強了 Pinterest 上的 Kafka。它使用類似於Apache Pulsar和Facebook Logdevice的解耦儲存和服務架構；然而，它依賴於一個可插拔的複製儲存層，即物件儲存/DFS/NFS 來儲存資料。最終結果是一個 PubSub 系統：

• 處理 GB/s 流量
• 獨立縮放、寫入和讀取
• 不需要昂貴的重新平衡來處理流量增長
• 比我們的 Kafka 足跡高 90% 的成本效益

特點

MemQ 的祕訣在於它利用微批處理和不可變寫入來建立一個架構，其中儲存層上所需的每秒輸入/輸出操作 (IOPS) 數量顯著減少，從而可以經濟高效地使用雲原生物件像 Amazon S3 一樣儲存。這種方法類似於網路的分組交換（vs 電路交換，即單個大型連續資料儲存，例如 kafka 分割槽）。

MemQ 將連續的日誌流分解為塊（物件），類似於 Pulsar 中的賬本，但不同之處在於它們被寫為物件並且是不可變的。這些“資料包”/“物件”的大小，在 MemQ 內部稱為 Batch，在確定端到端 (E2E) 延遲方面發揮作用。資料包越小，以更高的 IOPS 為代價寫入的速度就越快。因此，MemQ 允許以更高的 IOP 為代價實現可調整的 E2E 延遲。這種架構的一個關鍵效能優勢是實現依賴於底層儲存層的讀寫硬體的分離，允許寫入和讀取作為可以跨儲存層傳播的資料包獨立擴充套件。

這也消除了在 Kafka 中遇到的限制，為了恢復副本，必須從一開始就重新複製分割槽。在MemQ的情況下，底層複製儲存只需要在儲存失敗的情況下恢復由於故障而減少副本計數的特定Batch。但是，由於 Pinterest 的 MemQ 在 Amazon S3 上執行，因此儲存的恢復、分片和擴充套件由 AWS 處理，無需 Pinterest 的任何手動干預。

....

結論

MemQ 為 PubSub 提供了一種靈活、低成本的雲原生方法。MemQ 如今為 Pinterest 的所有 ML 訓練資料的收集和傳輸提供支援。我們正在積極研究將其擴充套件到其他資料集並進一步優化延遲。除了解決 PubSub 之外，MemQ 儲存還可以公開使用 PubSub 資料進行批處理的能力，而不會對效能產生重大影響，從而實現低延遲批處理。