Confluent聯合創始人兼CEO Jay Kreps發表了一篇博文，給出了Kafka的真正定位——它不只是個消息系統，它還是個存儲系統，而它的終極目標是要讓流式處理成為現代企業的主流開發范式。以下內容翻譯自作者的博文，查看原文It’s Okay To Store Data In Apache Kafka。
人們總是問是否可以把Kafka作為長期的數據存儲來使用，很顯然，如果把數據保留策略設置為“永久”或者啟用主題的日志壓縮功能，那么數據就可以被永久保存下來。但我覺得人們其實真正想知道的是，這樣做是不是很瘋狂。
簡而言之，這樣做不算瘋狂。實際上，人們一直都在這么做，而且Kafka的設計意圖之一就是要將它作為數據存儲系統。不過問題是，為什么我們要把Kafka作為數據存儲呢？
你可能在構建一個基于事件溯源的應用程序，需要一個數據存儲來保存變更日志。理論上，你可以使用任何一種存儲系統。Kafka已經解決了不可變（immutable）日志和基于這些日志生成“物化視圖”的問題，既然這樣，為什么不直接使用Kafka呢？紐約時報已經在他們的CMS系統里使用Kafka來保存他們的文章。你可能在應用程序里使用了緩存，并從Kafka上獲取數據來更新緩存。你可以將Kafka的主題設置為壓縮型日志，應用程序每次在重啟時就可以從零偏移量位置重新刷新緩存。你的流式作業數據流來自Kafka，在流式作業的邏輯發生變更后，需要重新計算結果。最簡單的辦法就是將偏移量重置為零，讓新代碼重新計算結果。Kafka經常被用于捕獲和分發數據庫的變更事件（通常被稱為CDC，Change Data Capture）。應用程序可能只需要最新的數據庫變更，但卻要處理完整的數據快照，而這是相當耗時的操作。如果啟用主題的日志壓縮功能，就可以讓應用程序直接從零偏移量位置重新加載數據。像這樣在Kafka里存儲數據并不是什么瘋狂事，Kafka本來就是設計用來存儲數據的。數據經過校驗后被持久化在磁盤上，并通過復制副本提升容錯能力。再多的數據都不會拖慢Kafka，在生產環境中，有些Kafka集群甚至已經保存超過1 TB的數據。
那么人們為什么會對使用Kafka來存儲數據心存疑問呢？
我想，人們更多的是把Kafka當成了消息隊列系統。消息隊列有一些不成文的規則，比如“不要在消息隊列里保存消息”。傳統的消息系統之所以不能用來保存消息，是因為：
消息被讀取后就會被刪除伸縮性差缺乏健壯的復制機制（如果broker崩潰，數據也就丟失了）傳統的消息系統在設計上存在很多不足。從根本上講，任何一個異步消息系統都會保存消息，只是時間很短，有時候只有幾秒鐘，直到消息被消費為止。假設有一個服務向消息隊列發送消息，并希望有一種機制可以保證其他服務能夠收到這個消息，那么消息就需要被保存在某個地方，直到其他服務讀取它。如果消息系統不擅長存儲消息，也就談不上給消息“排隊”了。你可能覺得無所謂，因為你并不打算長時間地保留消息。但不管怎樣，如果消息系統持續地處理負載，總會有一些未被消費的消息需要保存下來。一旦消息系統發生崩潰，如果沒有有效的容錯存儲機制，數據就會丟失。消息存儲是消息系統的基礎，但人們總是忽略這一點。
實際上，Kafka并非傳統意義上的消息隊列，它與RabbitMQ等消息系統并不一樣。它更像是一個分布式的文件系統或數據庫。Kafka與傳統消息系統之間有三個關鍵區別。
Kafka持久化日志，這些日志可以被重復讀取和無限期保留Kafka是一個分布式系統：它以集群的方式運行，可以靈活伸縮，在內部通過復制數據提升容錯能力和高可用性Kafka支持實時的流式處理以上三點足以將Kafka與傳統的消息隊列區別開，我們甚至可以把它看成是流式處理平臺。
我們可以這樣來看待消息系統、存儲系統和Kafka之間的關系。消息系統傳播的是“未來”的消息：你連接到broker上，并等待新消息的到來。存儲系統保存的是過去寫入的數據：你查詢或讀取的結果是基于過去所做的更新。而流式處理可以把這二者結合起來，既可以處理過去的數據，也可以處理未來的消息。這也就是為什么Kafka的核心就是一個持續的、基于時間排序的日志。它是一種結構化的“文件”，而且從邏輯上看，它沒有終點，會一直持續下去。應用程序不需要區分已有的舊數據和即將生成的新數據，它們都存在于一條持續的流中。Kafka提供了統一的協議和API來保存過去的數據和傳播未來的消息，Kafka因此成為一種非常好的流式處理平臺。
日志就像是分布式文件系統中的一個文件，在這個系統里，日志被復制到多臺機器上，被持久化到磁盤，并支持高吞吐的線性讀取和寫入。當然，日志也像是一個消息系統，支持高吞吐的并發寫入和低延遲的多消費者。
從實現方面來看，日志非常適合用來作為數據存儲。Kafka本身就是使用復制日志作為存儲，所以你也不例外！在Kafka內部，偏移量被保存在一個壓縮主題上，Kafka Streams API使用壓縮主題來記錄應用程序的處理狀態。
當然，把Kafka作為存儲系統來用并不會給你帶來新的門檻。存儲系統包攬了正確性、運行時間和數據完整性等方面的工作。如果一個系統成為數據的標準來源，人們就會對它的正確性和運維標準提出很高的要求。我們花了大量的精力在提升Kafka的正確性上，我們每天在數百臺機器上運行數個小時的分布式測試以及數千個常規性的單元測試，但我們覺得還有很多事情要做。除了測試之外，我們還需要知道如何做好運維工作，以及了解系統的局限性。
有時候，人們也會問我，這是不是就意味著Kafka可以取代其他存儲引擎。答案當然是否定的。
首先，數據庫提供大量的查詢，而Kafka并不打算在日志上增加隨機訪問的特性。Kafka保存數據可以被復制到其他數據庫、緩存、流式處理器、搜索引擎、圖存儲引擎和數據胡（data lake）上，這些存儲引擎都各自的優缺點，我們也無法做出一個可以打敗其他所有引擎的系統。
如果說Kafka并不想取代這些系統，那它存在的意義是什么？你可以把數據中心看成是一個大型的數據庫，Kafka是這個系統里的提交日志，而其他存儲引擎則是索引或視圖。Kafka是構建數據庫的基礎，至于查詢方面的工作可以交給索引和視圖。
Kafka Streams API提供了交互式的查詢功能。基于Kafka Streams開發的應用就是一個Kafka消費者，只不過它們可以維護計算狀態，而且這些狀態可以直接保存到外部的存儲系統，這種物化視圖讓Kafka具備了低延遲的查詢能力。Kafka集群保存日志，Streams API保存物化視圖并處理查詢請求。后來我們引入了KSQL——Kafka的流式SQL引擎。有了KSQL，用戶可以直接使用SQL語句從Kafka上獲得物化視圖。
我們不打算為Kafka提供查詢API的另一個原因是因為我們有其他更重要的事情要做。我們希望流式處理成為主流的開發模式，讓流式平臺成為現代數字業務的中心系統。我們希望能夠達成這個讓人激動不已的目標，而不只是創建一種新的數據庫系統。我們相信，在現代企業里，流式平臺將會成為移動和處理數據的黑馬。要實現這個目標，我們還有很多事情要做。
京公網安備 11010502049343號