作者 | Andreas Evers

編譯 | 言征

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

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

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

1、用Kafka替代關系數據庫

KOR Financial是一家金融服務初創公司，他們為何會選擇Kafka，而不是依賴關系數據庫來存儲數據呢？該公司的首席技術官Andreas，曾在Pivotal Software和VMware任職，主導過全球范圍內的應用程序轉型架構實踐，他的這一決策有什么玄機？

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

2、打破定式：數據庫沒有為規模設計

時代變了！身處數字化轉型時代，數據驅動決策要求企業具備現代靈活的數據架構。而要實現這樣的架構，成功的關鍵就在于，數據存儲能否做到強大、可靠和靈活。

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

首先，這是因為數據庫并不是為規模而設計的。它們固有的僵化結構只會阻礙企業數據架構所需的靈活性。

作為服務全球企業金融貿易存儲庫以及互補模塊化服務的運營商，數據的處理級別堪比煉獄。KOR Financial創新式地采取了數據流優先的方法，這也是它區別于競爭對手的地方。“的目標：徹底改變衍生品市場和全球監管機構對交易報告、數據管理和合規性的思考方式。”

以Kafka為架構核心，是一個思考方式上“質”的變化：因為這種架構能夠捕獲事件而不僅僅是狀態。“將數據存儲在Kafka而不是數據庫中，并將其用作記錄系統，就可以實現跟蹤所有這些事件、處理它們并根據現在或將來的用例創建數據的物化視圖。”

雖然其他貿易存儲庫和中介服務提供商經常使用Oracle Exadata 等數據庫來滿足其數據存儲需求，但它可能非常昂貴并帶來數據管理挑戰。雖然它允許執行 SQL 查詢，但挑戰在于管理大型SQL數據庫并確保這些系統內的數據一致性。

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

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

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

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

3、會整活的Kafka：重播事件、回放數據

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

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

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

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

鑒于業務的監管要求，必須以不可變的方式存儲所有內容。需要捕獲并保留最初收到的所有數據。雖然大多數數據庫（包括SQL）都允許修改，但 Kafka 在設計上禁止對其不可變日志進行任何更改。

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

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

4、靈活性征服一切 

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

以客戶數據管理為例。可以使用專門為該用例設計的圖數據庫，而無需圍繞圖數據庫構建整個系統，因為它只是基于 Kafka 的視圖或投影。

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

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

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

5、切換技術的背后：事件驅動思維

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

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

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

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

6、寫在最后：Kafka可以取代數據庫嗎？

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

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

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

不過，倡導的打破傳統數據庫的思維定式去重新設計底層架構的方法，值得反思和借鑒。

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