作者丨Andrew Mills

編譯丨諾亞

出品 | 51CTO技術棧（微信號：blog51cto）

關于Kafka到底能否被認為是數(shù)據庫的討論由來已久。支持方認為，Kafka不應該僅僅是一個消息隊列，其工作機制涉及到海量數(shù)據的存儲與處理，根據需求Kafka 是可以作為數(shù)據庫來使用的。而反對方則表示，Kafka 沒有傳統(tǒng)數(shù)據庫的數(shù)據模型，也不能很好地支持查詢優(yōu)化，而且Kafka沒有嚴格的隔離機制，也就無從保證在并發(fā)讀寫情況下的數(shù)據準確。

本文作者Andrew Mills是開源數(shù)據庫公司Instaclustr的高級解決方案架構師，在他看來，將Kafka作為一個數(shù)據庫來使用并不能解決問題。2016年，Andrew開始了他的數(shù)據流之旅，此后他設計和實現(xiàn)了幾個以Kafka為核心的大數(shù)據管道，對Apache Kafka及其生態(tài)系統(tǒng)有了深厚的沉淀。       

企業(yè)總是在與其現(xiàn)有的關系數(shù)據庫的性能和可伸縮性限制作斗爭。負責尋找新解決方案的團隊，著眼于事件驅動架構，發(fā)現(xiàn)了Apache Kafka，驚嘆：“這就是我們需要的數(shù)據庫解決方案！”它速度快、可擴展、高可用，正是他們期待的完美新解法。

這些團隊將Kafka設置為他們的數(shù)據庫，并期望它作為他們的可信單一數(shù)據源（SSOT），存取他們可能需要的所有數(shù)據。但是，這就是問題開始的時候。核心問題是Kafka實際上并不是一個數(shù)據庫，使用它作為數(shù)據庫并不能解決他們所遇到的可擴展性和性能問題。

1、“什么是數(shù)據庫”正在被挑戰(zhàn)   

當開發(fā)人員來定義一個數(shù)據庫時，他們通常會想到具有二級索引和表的數(shù)據存儲，就像大多數(shù)SQL和NoSQL解決方案一樣。另一個傳統(tǒng)需求是遵循ACID原則：即原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）。

然而，關于數(shù)據庫定義的傳統(tǒng)思維正在不斷受到挑戰(zhàn)。例如，Redis沒有表，RocksDB沒有二級索引。兩者都不遵循ACID。但是，兩者通常都被稱為數(shù)據庫。還有，比如Apache Cassandra被稱為NoSQL數(shù)據庫，但它同樣不遵循ACID。  

我在Kafka上劃清了界限，我認為它不是數(shù)據庫，而且在很大程度上不應該被用作數(shù)據庫。冒昧地說，我覺得Kafka社區(qū)大部分人在很大程度上都持有相似的觀點。

Kafka沒有查詢語言。你可以訪問特定時間段的特定記錄，但是你訪問的是預寫日志。Kafka確實有偏移量和主題，但它們不能替代索引和表。而且，Kafka不符合ACID原則。雖然可以使用Kafka作為數(shù)據存儲或創(chuàng)建自己版本的數(shù)據庫，但Kafka本身并不是數(shù)據庫。

這就引出了一系列問題：千方百計地使用Kafka作為數(shù)據庫是否有意義？你的用例真的需要它嗎？從長遠來看，迫使Kafka像數(shù)據庫一樣運行，你又是否有足夠的專業(yè)知識來承擔隨之而來的技術債務?對于大多數(shù)用戶和用例，我的答案是堅決的否定。

2、Kafka取代不了關系數(shù)據庫

為用例選擇正確的技術，關鍵都在于，讓解決方案與你試圖解決的問題相匹配。Kafka旨在作為一個分布式事件流平臺，僅此而已。雖然它可以用作長期數(shù)據存儲(技術上)，但這樣做意味著在訪問這些數(shù)據時需要進行重大權衡。

Kafka生態(tài)系統(tǒng)中的工具，比如ksqlDB，可以讓Kafka感覺更像一個數(shù)據庫，但這種方法只適用于中等規(guī)模的用例。大多數(shù)選擇實現(xiàn)Apache Kafka的企業(yè)都有高速數(shù)據，而ksqlDB無法滿足他們的需求。

正確的策略是讓Kafka做它最擅長的事情，即以快速可靠的方式接收和分發(fā)事件。例如，考慮一個帶有API的電子商務網站，該API通常會將所有數(shù)據直接保存到具有大量表的關系數(shù)據庫中，因此性能、可擴展性和可用性都很差。引入Kafka，我們可以設計一個高級的事件驅動生態(tài)系統(tǒng)，將API中的數(shù)據作為事件推送到Kafka。

這種事件驅動的方法將處理分離為單獨的組件。一個事件可能包含客戶數(shù)據，另一個事件可能包含訂單數(shù)據，等等——支持多個作業(yè)同時獨立地處理事件。這種方法是企業(yè)架構的下一個發(fā)展方向。我們已經從單體到微服務，現(xiàn)在又發(fā)展到事件驅動架構，它擁有與微服務相同的諸多優(yōu)點，比如，具有更高的可用性和更快的速度。

一旦事件被保存在Kafka中，你就可以非常靈活地處理它們。如果有需要將原始事件存儲在關系數(shù)據庫中，那么可以使用Kafka Connect這樣的生態(tài)系統(tǒng)工具來簡化這一過程。   

關系數(shù)據庫仍然是現(xiàn)代企業(yè)架構中的一個關鍵工具，特別是當你考慮到，使用熟悉的工具和成熟的生態(tài)系統(tǒng)的優(yōu)勢是有優(yōu)勢的。Kafka并不是我們所熟悉的這些工具的替代品。它只是使我們能夠處理我們所看到的大量涌入的數(shù)據。

3、可插拔且多功能，但不是一個數(shù)據庫

Kafka在支持數(shù)據聚合和實時指標等用例方面提供了最大的價值。使用Kafka和Apache生態(tài)系統(tǒng)工具(如Spark、Flink或KStreams)，開發(fā)人員可以對流數(shù)據進行聚合和轉換，然后將這些數(shù)據推送到所需的數(shù)據庫。其中一些工具還可以以時間序列或窗口方式聚合數(shù)據，并將其推送到報告引擎以獲得實時指標。

如果開發(fā)人員希望將某些數(shù)據保存到緩存中——可能是為了支持網站或CRM系統(tǒng)——很簡單，可以利用Kafka數(shù)據流并將數(shù)據推送到Redis或一個壓縮的Kafka主題。來自Kafka的數(shù)據流允許團隊添加他們認為合適的各種組件，而不用擔心服務的降級，因為Kafka具有非常好的可擴展性、可靠性和可用性。這包括將數(shù)據輸入任何數(shù)據存儲，無論是Apache Cassandra、大數(shù)據平臺、數(shù)據湖，還是幾乎任何其他選擇。

如果數(shù)據是現(xiàn)代企業(yè)的命脈，那么Kafka應該是數(shù)據生態(tài)系統(tǒng)的核心。使用Kafka，用戶可以將數(shù)據傳輸?shù)饺魏涡枰牡胤?。通過這種方式，Kafka是你的數(shù)據庫的補充，但不應該是你的數(shù)據庫。正確利用Kafka的方式應該包括“按其預期使用”的方向作為，這意味著將它視為一個強大的消息代理，事件流的處理中心、組織的核心數(shù)據管道。

參考鏈接：https://www.infoworld.com/article/3711181/dont-make-apache-kafka-your-database.html