Kafka Tiered Storage：面試如何設計本地與遠端保留策略？
題幹與適用場景
面試官可能會問：「如果 Kafka 主題需要保留多年歷史資料，你會如何設計 Tiered Storage 的本地與遠端保留策略？」
題目核心不是背一個設定名稱，而是解釋日誌段在本地層和遠端層之間的生命週期。KIP-405 的模型保留 Kafka broker 上的本地層，同時把完成的日誌段上傳到外部儲存；本地保留時間或大小可以短於遠端保留，以降低 broker 磁碟壓力。回答還必須涵蓋遠端物件儲存故障、歷史讀取延遲、刪除責任和回滾路徑。
面試官考察點
- 是否理解 tiered storage 是日誌段級別的冷熱分層，而非把 Kafka 直接變成物件儲存。
- 是否能區分叢集級能力、主題級
remote.storage.enable和本地/遠端保留策略。 - 是否能估算熱資料磁碟、遠端容量、上傳落後和歷史讀取頻寬。
- 是否考慮遠端儲存不可用、元資料一致性、分區遷移和消費者重播。
- 是否明確遠端資料刪除的責任邊界，避免誤刪或無限增長。
回答前需要釐清的問題
- 哪些主題需要遠端歷史，是否所有主題都啟用？
- 熱讀延遲目標和歷史回放吞吐是多少？
- 本地磁碟預算、遠端儲存類別、跨區域要求和合規保留期是什麼？
- 遠端物件儲存故障時，生產、即時消費和歷史消費分別如何降級？
- 刪除策略按時間、大小、合規事件還是租戶保留策略執行？
30 秒回答框架
可以這樣回答：
我會把 Kafka 的本地層當作低延遲熱快取，把已完成日誌段複製到遠端層，再分別定義本地和遠端保留。主題按需要開啟 remote.storage.enable，先用本地保留時間控制 broker 磁碟，再用遠端保留滿足稽核和回放期限。設計中要量化上傳落後、遠端讀取延遲、物件儲存故障和分區遷移，並明確遠端物件由誰清理。即時消費走本地路徑，歷史重播接受額外延遲並設定限速和監控。
分步驟深入解答
先建立兩層生命週期
Kafka 仍以分區日誌段為基本單位。活躍段寫入本地層；滾動完成後，遠端日誌管理元件把段及其索引資訊寫入設定的遠端儲存。客戶端不應假設每個歷史位元組都還在 broker 本地磁碟：
producer -> leader broker local segment
| segment roll
v
remote object store
consumer <---- local cache or remote fetch本地層適合低延遲消費，遠端層承擔較長保留期。上傳完成和本地刪除之間需要可觀測的安全窗口，不能因為「物件已建立」就忽略索引或元資料狀態。
用主題級開關控制範圍
Apache Kafka 文件說明叢集側完成設定後，主題仍需透過 remote.storage.enable 選擇是否使用 tiered storage。回答時應說明預設關閉或按主題啟用的治理方式，避免把所有主題都遷移到遠端而放大成本與故障面。
分離本地與遠端保留
本地保留可以按時間或大小設定較小窗口，保證熱資料和重平衡所需的讀取能力；遠端保留覆蓋稽核、回放和合規期限。兩個窗口必須滿足業務不變量：在遠端上傳確認、元資料可讀和恢復演練通過之前，不能刪除本地唯一副本。遠端刪除也要有獨立稽核和失敗重試。
設計讀取路徑與故障降級
即時消費者優先讀取本地層，跨越本地窗口的 offset 觸發遠端讀取。遠端變慢時，限制歷史回放並保護即時流量；遠端不可用時，明確哪些 offset 暫不可讀、如何告警和如何恢復。分區遷移、leader 變更和 broker 重啟都應驗證本地快取與遠端元資料的重建時間。
高品質示範回答
我先確認主題的熱讀窗口、歷史回放吞吐、保留期和合規要求。架構上按 KIP-405 把 broker 本地層作為熱快取，日誌段滾動後上傳到遠端物件儲存；只有需要歷史的主題開啟 remote.storage.enable。本地保留按磁碟預算和即時重播需求設定，遠端保留按稽核期限設定，兩者之間以「遠端物件、索引和元資料可驗證」為刪除前置條件。消費者讀取本地窗口時保持原有低延遲，超出窗口的回放走遠端並限速，防止拖垮即時流。我會監控上傳落後、遠端讀取延遲、快取命中、物件與元資料不一致、刪除失敗和不可讀 offset，並演練物件儲存故障、broker 重啟和分區遷移。遠端物件清理必須有明確 owner、稽核和恢復流程，不能依賴 broker 磁碟刪除自動完成。
常見錯誤
- 說 tiered storage 會把所有 Kafka 資料即時寫入物件儲存，忽略日誌段滾動和本地熱層。
- 只給叢集級開關，不提主題級
remote.storage.enable。 - 只計算物件儲存成本，不估算遠端讀取延遲、上傳落後和回放頻寬。
- 認為刪除 broker 本地檔案會自動刪除遠端物件，忽略 KIP-405 的清理責任。
- 遠端故障時讓歷史回放搶占即時消費資源。
- 沒有物件、索引和遠端元資料一致性的監控與恢復演練。
追問及應對
1. 本地保留時間應如何確定？
從即時消費者最大回溯窗口、磁碟預算、重平衡恢復時間和故障期間安全餘量倒推。不要只按平均消費延遲設定；應覆蓋峰值回放和 broker 維護窗口。
2. 遠端物件儲存短暫不可用怎麼辦？
暫停或限速跨窗口讀取，保留本地可讀範圍並告警上傳和讀取失敗。生產與即時消費繼續按已驗證的本地容量運作，遠端恢復後再補償歷史讀取；對不可讀 offset 提供明確狀態，不能偽造空資料。
3. 如何驗證刪除不會造成資料遺失？
在刪除本地段前驗證遠端物件、索引和元資料可讀取，並記錄段範圍。刪除遠端物件時執行保留策略稽核、抽樣讀取和恢復演練；把刪除失敗、孤兒物件和元資料缺口納入告警與定期盤點。