Kafka 中的分層儲存 - Uber 技術部落格摘要

Uber 的技術部落格發表了一篇文章《Uber Kafka 分層儲存簡介》，旨在透過更少的 Kafka 代理和更少的記憶體來最大限度地保留資料。這允許在各種業務應用程式中延長訊息保留時間。

常見的解決方案是手動整合外部存儲，定期將資料同步到外部系統。然而，這涉及大量的開發和維護工作，例如確定如何保存資料、設定同步頻率、觸發流程、獲取資料和使用索引。

因此，Uber提出了一種解決方案，將外部儲存的邏輯封裝起來，透過簡單的配置實現即插即用。此功能正在與 Apache 基金會合作開發，並將在未來版本中提供。

設想

重要的是要了解 Kafka 是一個具有非常高吞吐量能力的僅附加訊息佇列 (MQ) 元件。 Kafka將日誌儲存在broker的本機儲存上，使用者可以配置保留時間或日誌大小。在我之前的公司（聯想），我們使用Flink來持續消費數據。大數據量會導致Kafka超出磁碟儲存限制，導致資料寫入失敗和業務錯誤。為了降低成本，我們只能調整保留時間，而不是部署更多機器。

此外，如果每個公司都開發自己的系統來將舊資料保存到外部存儲，這將涉及大量的開發工作。還有許多與同步和資料一致性相關的問題。

解決方案

本質就是對Broker進行改造，增加遠端日誌管理和儲存管理。

RemoteLogManager：管理遠端日誌段的生命週期，包括複製、清理和取得。

RemoteStorageManager：管理遠端日誌段的操作，包括複製、取得和刪除。與遠端日誌段關聯的元資料包括有關段的開始和結束偏移、時間戳記、生產者狀態快照和領導者紀元檢查點的資訊。
RemoteLogMetadataManager 追蹤此元數據，以確保系統知道每個區段的開始和結束位置，以及資料檢索和管理所需的其他關鍵資訊。

RemoteLogMetadataManager：管理遠端日誌段的元資料生命週期，具有強烈一致性。

其中RemoteLogManager作為控制元件，直接連接Broker中的磁碟來擷取讀取的資料。它還負責回調遠端資料。 RemoteStorageManager是對資料進行操作的實體，RemoteLogMetadataManager負責管理元資料。

Kafka分層儲存三個動作總結

1. 將段複製到遠端儲存
   如果日誌段的結束偏移量（段中最後一條訊息的偏移量）小於分區的last-stable-offset，則認為該日誌段有資格複製到遠端儲存。 （Last-Stable-Offset (LSO)：最高偏移量所有先前的訊息都被所有同步副本完全確認，確保不會遺失資料。）RemoteStorageManager 處理日誌段及其關聯索引、時間戳記、生產者快照和領導者紀元緩存的複製。

2. 清理遠端段
   透過專用執行緒池計算符合條件的段，定期清理遠端資料。這與本地日誌段的非同步清理不同。刪除主題時，遠端日誌段的清理是非同步完成的，不會阻塞現有的刪除操作或重新建立新主題。

3. 從遠端儲存取得段
   RemoteLogManager 透過使用 RemoteLogMetadataManager 查看元資料存儲，根據所需的偏移量和領導紀元確定目標遠端段。它使用 RemoteStorageManager 來尋找段內的位置並開始取得所需的資料。

以上是Kafka 中的分層儲存 - Uber 技術部落格摘要的詳細內容。更多資訊請關注PHP中文網其他相關文章！