作者 | Andreas Evers

編譯 | 言征

長期以來，數(shù)據(jù)庫一直充當著記錄系統(tǒng)，它們以可靠且持久的方式存儲和管理關(guān)鍵數(shù)據(jù)，也贏得了大多數(shù)公司的信賴。

但時代在變。許多新興趨勢正在影響當今數(shù)據(jù)的存儲和管理方式，不得不讓一些技術(shù)決策者們重新考慮數(shù)據(jù)存儲究竟還有哪些創(chuàng)新途徑。或許，關(guān)系型數(shù)據(jù)庫開始變得不合時宜了。

本篇文章為諸君提供了一種“跳出框框”的記錄系統(tǒng)的新玩法——為什么組織需要以不同的方式思考數(shù)據(jù)存儲、使用 Kafka 作為記錄系統(tǒng)的好處以及有哪些好的實現(xiàn)思路等，希望對諸君有所啟發(fā)。

1、用Kafka替代關(guān)系數(shù)據(jù)庫

KOR Financial是一家金融服務(wù)初創(chuàng)公司，他們?yōu)楹螘x擇Kafka，而不是依賴關(guān)系數(shù)據(jù)庫來存儲數(shù)據(jù)呢？該公司的首席技術(shù)官Andreas，曾在Pivotal Software和VMware任職，主導過全球范圍內(nèi)的應用程序轉(zhuǎn)型架構(gòu)實踐，他的這一決策有什么玄機？

先說結(jié)果，使用Kafka方案，能夠“經(jīng)濟高效、安全地存儲數(shù)十甚至數(shù)百PB的數(shù)據(jù)，并且保留數(shù)十年。”Andreas稱，“采用這種方法不僅為數(shù)據(jù)架構(gòu)提供了巨大的靈活性和可擴展性，而且還實現(xiàn)了精益和敏捷的運營。”

2、打破定式：數(shù)據(jù)庫沒有為規(guī)模設(shè)計

時代變了！身處數(shù)字化轉(zhuǎn)型時代，數(shù)據(jù)驅(qū)動決策要求企業(yè)具備現(xiàn)代靈活的數(shù)據(jù)架構(gòu)。而要實現(xiàn)這樣的架構(gòu)，成功的關(guān)鍵就在于，數(shù)據(jù)存儲能否做到強大、可靠和靈活。

誠然，也看到了近二十年來，大數(shù)據(jù)、分布式系統(tǒng)、云計算和實時數(shù)據(jù)處理的興起，但傳統(tǒng)的數(shù)據(jù)庫就成了掣肘的瓶頸，已無法跟上每秒生成數(shù)據(jù)的速度和數(shù)量。

首先，這是因為數(shù)據(jù)庫并不是為規(guī)模而設(shè)計的。它們固有的僵化結(jié)構(gòu)只會阻礙企業(yè)數(shù)據(jù)架構(gòu)所需的靈活性。

作為服務(wù)全球企業(yè)金融貿(mào)易存儲庫以及互補模塊化服務(wù)的運營商，數(shù)據(jù)的處理級別堪比煉獄。KOR Financial創(chuàng)新式地采取了數(shù)據(jù)流優(yōu)先的方法，這也是它區(qū)別于競爭對手的地方。“的目標：徹底改變衍生品市場和全球監(jiān)管機構(gòu)對交易報告、數(shù)據(jù)管理和合規(guī)性的思考方式。”

以Kafka為架構(gòu)核心，是一個思考方式上“質(zhì)”的變化：因為這種架構(gòu)能夠捕獲事件而不僅僅是狀態(tài)。“將數(shù)據(jù)存儲在Kafka而不是數(shù)據(jù)庫中，并將其用作記錄系統(tǒng)，就可以實現(xiàn)跟蹤所有這些事件、處理它們并根據(jù)現(xiàn)在或?qū)淼挠美齽?chuàng)建數(shù)據(jù)的物化視圖。”

雖然其他貿(mào)易存儲庫和中介服務(wù)提供商經(jīng)常使用Oracle Exadata 等數(shù)據(jù)庫來滿足其數(shù)據(jù)存儲需求，但它可能非常昂貴并帶來數(shù)據(jù)管理挑戰(zhàn)。雖然它允許執(zhí)行 SQL 查詢，但挑戰(zhàn)在于管理大型SQL數(shù)據(jù)庫并確保這些系統(tǒng)內(nèi)的數(shù)據(jù)一致性。

從事全球強制貿(mào)易報告業(yè)務(wù)，意味著要為多個管轄區(qū)提供服務(wù)，每個管轄區(qū)都有自己獨特的數(shù)據(jù)模型和解釋。如果將所有數(shù)據(jù)合并到單個架構(gòu)或模型中，統(tǒng)一管理的任務(wù)就會變得越來越復雜。如果沒有數(shù)據(jù)的歷史概覽，模式演變就具有挑戰(zhàn)性，因為它是在特定版本的狀態(tài)中具體化的，這進一步加劇了數(shù)據(jù)管理的困境。

另外，在處理大量數(shù)據(jù)時，傳統(tǒng)數(shù)據(jù)庫的可擴展性受到限制。相比之下，將Confluence Cloud用于Kafka及其無限存儲，就可以允許用戶在Kafka中存儲任意數(shù)量的數(shù)據(jù)，只要需要，就可以存儲任意長時間，而只需為所使用的存儲付費。

雖然分區(qū)數(shù)量是一個考慮因素，但可以放入 Confluence Cloud 中的數(shù)據(jù)量是無限的，并且存儲空間會根據(jù)需要自動增長，并且保留時間不受限制。

它使技術(shù)人員能夠完全抽象出數(shù)據(jù)在底層的存儲方式，并提供一種經(jīng)濟高效的方式來保存所有數(shù)據(jù)。更好地是，這使企業(yè)能夠以一種不受限制的方式擴展自身的運維，并以想要的任何表示方式來解釋事件，自由度很高。

3、會整活的Kafka：重播事件、回放數(shù)據(jù)

使用Kafka作為記錄系統(tǒng)的顯著優(yōu)勢之一在于它能夠回放數(shù)據(jù)，這是傳統(tǒng)數(shù)據(jù)庫所缺乏的原生功能。對于金融場景來說來說，此功能與“存儲事件與狀態(tài)”的偏好非常契合，這對于準確計算交易狀態(tài)至關(guān)重要。

“我們收到一大堆delta（增量），我們稱之為提交或消息，它們在給定的時間點對貿(mào)易狀態(tài)有貢獻。每個傳入的消息或事件都會修改交易并更改其當前狀態(tài)。如果在我們的流處理邏輯過程中發(fā)生任何錯誤，都可能導致不正確的狀態(tài)輸出。”

如果該信息直接存儲在固定表示或傳統(tǒng)數(shù)據(jù)庫中，則導致該狀態(tài)的事件就會丟失。即使對這些事件的解釋不正確，也無法重新審視導致該解釋的背景。

然而，通過在不可變且僅追加的日志中保留事件的歷史順序，Kafka 提供了重播這些事件的能力。

鑒于業(yè)務(wù)的監(jiān)管要求，必須以不可變的方式存儲所有內(nèi)容。需要捕獲并保留最初收到的所有數(shù)據(jù)。雖然大多數(shù)數(shù)據(jù)庫（包括SQL）都允許修改，但 Kafka 在設(shè)計上禁止對其不可變?nèi)罩具M行任何更改。

使用 Kafka 作為記錄系統(tǒng)并擁有無限存儲意味著可以回到過去，分析事情是如何展開的，更改的解釋，管理時間點歷史更正并創(chuàng)建替代表示，而不會影響當前的操作工作負載。

這種靈活性提供了顯著的優(yōu)勢，尤其是在高度監(jiān)管的市場中運營時，能及時有效地糾正錯誤，這一點至關(guān)重要。

4、靈活性征服一切

使用 Kafka 作為記錄系統(tǒng)為的數(shù)據(jù)架構(gòu)帶來了顯著的靈活性。可以針對每個用例建立特定的視圖，并使用與這些需求精確一致的專用數(shù)據(jù)庫或技術(shù)，然后讀取包含這些事件來源的 Kafka 主題。

以客戶數(shù)據(jù)管理為例?？梢允褂脤ｉT為該用例設(shè)計的圖數(shù)據(jù)庫，而無需圍繞圖數(shù)據(jù)庫構(gòu)建整個系統(tǒng)，因為它只是基于 Kafka 的視圖或投影。

這種方法允許根據(jù)用例使用不同的數(shù)據(jù)庫，而無需將它們指定為的記錄系統(tǒng)。相反，它們充當數(shù)據(jù)的表示，使能夠保持靈活性。否則，就將被插入數(shù)據(jù)庫、數(shù)據(jù)湖或數(shù)據(jù)倉庫，這些都是僵化的，不允許將數(shù)據(jù)轉(zhuǎn)換為針對特定用例優(yōu)化的表示形式。

從初創(chuàng)公司的角度來看，這種靈活性也使能夠避免過早地被鎖定在某個特定的技術(shù)方向。KOR成立于2021年，遵循將決策推遲到最后一個負責時刻的架構(gòu)最佳實踐，可以推遲對特定技術(shù)選擇的承諾，直到它是必要的并且符合的要求。這種方法意味著，可以隨著業(yè)務(wù)需求的發(fā)展而調(diào)整和發(fā)展的技術(shù)環(huán)境，并實現(xiàn)未來的可擴展性和靈活性。

除了靈活性之外，模式注冊表（Schema Registry）的使用還確保了數(shù)據(jù)的一致性，因此開發(fā)者就可以知道數(shù)據(jù)的來源和與之相關(guān)的模式。Confluence Cloud 還允許通過架構(gòu)注冊表設(shè)置明確的演進策略。例如，如果將所有數(shù)據(jù)放入數(shù)據(jù)湖中，那么管理該數(shù)據(jù)的所有不同版本、不同模式和不同表示就會變得更加困難。

5、切換技術(shù)的背后：事件驅(qū)動思維

放棄數(shù)據(jù)庫，而采用 Kafka 作為存儲數(shù)據(jù)的記錄系統(tǒng)，看起來是一件非常新鮮的做法。

并不是所有公司上來就能接受這種做法，Andreas認為，這需要公司培育“事件驅(qū)動模型”的文化，并且這種思維轉(zhuǎn)變還應該擴展到通過流處理開發(fā)應用程序的方式，不然就會引起兼容性不匹配的問題。

這樣做的目的，是幫助團隊成員意識到：他們正在處理不可變的數(shù)據(jù)，如果他們編寫了某些內(nèi)容，他們就不能直接進去更改它。

Andreas還建議道，要實現(xiàn)以Kafka為核心的架構(gòu)，可以從理解“流處理和事件作為證明系統(tǒng)的重要性”的團隊開始。通過展示該團隊內(nèi)的優(yōu)勢，他們可以充當其他團隊的大使，鼓勵采用事件作為最終真相，并采用以狀態(tài)作為最終表示的流處理。

6、寫在最后：Kafka可以取代數(shù)據(jù)庫嗎？

早在2017年，Apache Kafka和Confluent的共同創(chuàng)始人Jay Kreps就明確表示過“ 可以在Apache Kafka中存儲數(shù)據(jù) ”。

而且，數(shù)據(jù)可以在Kafka中想保存多久就保存多久?！都~約時報》的Apache Kafka發(fā)布是用Kafka永遠存儲數(shù)據(jù)的著名例子。Kafka被用來存儲《紐約時報》曾經(jīng)發(fā)布的所有文章，并取代了他們基于API的方式。

那么Kafka可以取代數(shù)據(jù)庫嗎？顯然并不現(xiàn)實，即便文中提到了許多傳統(tǒng)數(shù)據(jù)庫的“不合時宜”之處，比如，“數(shù)據(jù)庫并不是為規(guī)模設(shè)計的”等觀點，但也僅限于金融等強實時性場景中的方案。

不過，倡導的打破傳統(tǒng)數(shù)據(jù)庫的思維定式去重新設(shè)計底層架構(gòu)的方法，值得反思和借鑒。

原文鏈接：https://thenewstack.io/ditching-databases-for-apache-kafka-as-system-of-record/