作者 | 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/