作者丨Andrew Mills

編譯丨諾亞

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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