矩陣起源是一家專注于為企業用戶提供簡捷強大的數據操作系統的數據基礎軟件公司。公司創始團隊來自騰訊云、Snowflake等國內外一流的互聯網企業、軟件公司、數字化企業和開源社區，核心團隊為產品、研發、解決方案、生態和開源社區等領域的專家，在分布式架構、數據庫、云計算、大數據及人工智能等領域積累了豐富經驗。

MatrixOne 是矩陣起源（MatrixOrigin）開源的一款超融合 HTAP 云原生數據庫，借助于全新設計和研發的統一分布式計算和存儲框架，使數據庫同時具備 TP、AP和Streaming三種能力，幫助客戶徹底打破數據孤島問題，成為企業智能化核心的數據基礎設施。得益于這一創新的架構設計，用戶可以在公有云、私有云、數據中心和邊緣節點上部署和使用MatrixOne。秉承“One Size Fits Most”的產品理念，MatrixOne將運維工作簡化到極致，使得數據應用開發變得極為簡捷，同時也保證了數據處理的極致性能。

推翻三座大山

分布式框架

MatrixCube作為當時的分布式框架，提供了多副本存儲模式，每一份數據都保存3副本并且以分片（shard）形式保存，使得存儲的成本飆升。而基于Raft選舉的Leader節點，頻繁成為了熱點，各類操作都需要通過Leader節點進行分發，在極端業務場景下，Leader節點的負載會數倍于普通節點。

引擎眾多

早期的MatrixOne內置了三種存儲引擎，三個引擎之間代碼復用率較低，使得對功能的維護需要投入更多人力。而基于因子化算法的Plan構建方式過于激進和抽象，在計算組內部對其完全理解的程序員數量有限，往往添加功能時仍舊需要主開一人完成，新功能添加緩慢。

資源分配

舊架構采用了存算不分離的架構，這個架構導致了擴展性較差。每擴展一個單位的計算節點必須同步擴展存儲資源。由于存儲采用了shard分片，使得在shard較大時影響了OLTP的性能，在shard較小時，又會影響OLAP性能。

在找到了三座大山之后，接下來要做的事情就是一一扳倒它們，田豐博士結合MatrixOne的產品愿景以及未來的技術趨勢，對于實驗架構進行了總結，并提出了MatrixOne獨有的架構設想，從整個架構的現狀來看，要分三步走：

第一步，將舊架構share nothing的框架破除，完成更靈活的解耦；

第二步，將多種引擎合二歸一，實現內部引擎的大一統；

第三部，重構計算引擎，留有足夠的空間給未來的產品發展。

重生后的MatrixOne

新架構通過解耦，最終實現了三個各自獨立的層級，每個層級有自己的對象單元與分工，不同類型的節點可以靈活伸縮，不再受到其他層的制約：

計算層 ，以計算節點Compute Node為單位，實現了計算和事務處理的Serverless化，又有自己的Cache，可以實現任意重啟與擴縮容；

事務層 ，以數據庫節點Database Node為與日志節點Log Service為單位，提供完整的日志服務以及元數據信息，內置Logtail用于保存最近數據；

存儲層 ，全量數據保存在以S3為代表的對象存儲中，實現了低成本的無線伸縮存儲方式，以File Service命名的統一文件操作服務，實現了不同節點對底層存儲的無感知操作。

在確定了以TAE作為唯一存儲引擎之后，對融合后的TAE引擎又做了諸多設計上的調整，才有了后來融合后的TAE存儲引擎。完成了單一引擎完成所有數據庫存儲行為的目標，并且具備了如下優勢：

列存管理 ，統一的列存與壓縮，對于OLAP業務有著先天的性能優勢；

事務處理 ，共享日志與DN節點共同完成對計算節點的事務支持；

冷熱分離 ，使用File Service以S3對象存儲作為目標，每個計算節點都有自己的Cache。

多次運行測試，得出置信度較高的結果：

早期的計算引擎中，兼容MySQL的大目標沒有變化，但是對于節點調度、執行計劃、SQL能力又有著更高的要求。重構后的高性能計算引擎，既具備了實驗架構中計算引擎的MPP，又彌補了過去的諸多不足：

兼容MySQL ，既有對MySQL協議的支持，又包含了對MySQL語法的支持；

融合引擎 ，基于DAG重新構建執行計劃，可以同時執行TP和AP；

節點調度 ，未來可支持自適應節點內和節點間調度，同時滿足并發和并行執行；

完善SQL能力，支持子查詢、窗口函數、CTE、Spill內存溢出處理等。

積跬步以至千里

回顧歷時數月的架構升級之路，充滿了各種辛酸和痛苦。無論考慮的多么充分，在實際開發中，總會遇到各種各樣意想不到的問題出現，尤其是在一些關鍵問題上的困難，讓研發團隊從開始的一籌莫展，到偶爾的靈光乍現，再到很后面的零之曙光，走向最終的黎明時刻。個中三昧，不言而喻。

這些難題中，主要圍繞在存儲、事務、負載隔離與資源配比幾個方面。

尋找更合適的存儲

在意識到三副本存儲帶來的問題后，如何尋找一個新的存儲適配新架構，成為了當時一大難題，而這個新的存儲必須滿足兩個核心需求，低成本與冷熱數據分離。

在對市面上的諸多存儲進行了調研以及試驗之后，AWS S3成為了最終的選擇。單一副本，自帶的冷熱數據分離。

事務分工的調整

最初的新架構中，計算節點CN與數據庫節點DN之間的分工是CN負責計算，計算結果推給DN，由DN完成事務。隨著開發進度的不斷推進，這個分工開始出現了問題，DN對事務的處理能力成為整個系統的瓶頸。因此，對于CN和DN的分工，必須做重新定義：

CN負責所有的計算以及事務邏輯，DN負責保存元數據信息、日志信息以及事務裁決，DN不再成為瓶頸；

在日志中引入Logtail對象，用于保存最近日志中的關聯數據，定期將Logtail的數據寫入S3中，CN擴容可以實時將Logtail數據同步至Cache，實現了部分數據共享；

為事務大小設置閾值，超過閾值上限的事務直接寫S3，日志只保存記錄寫入記錄，未超過閾值的事務繼續由DN寫入，極大增加了吞吐量。

實現HTAP的工作負載隔離

作為HTAP數據庫，如何實現不同類型的工作負載隔離，是一個必須解決的問題。在完成了對舊的實驗架構的靈活解耦之后，工作負載的隔離也得以實現：

服務器級別的隔離，硬件資源充裕的情況下，各個組件分別在不同的物理機運行，接入同一個對象存儲；

容器級別的隔離，硬件資源有限的情況下，利用所有節點無狀態的特性，以容器作為各個節點的隔離手段。

實現資源配比的靈活調整

作為HTAP數據庫，日常業務中，不同業務場景的比例是在動態變化中，對于資源的配比也有著更高的要求，而舊架構下的資源分配模式注定無法實現靈活調整，需要對各個節點實現更加精細化的管理，包含但不限于：

CN節點的分工，允許用戶對CN進行劃分，用于TP或AP業務，其中某項業務資源出現瓶頸之后，對CN進行水平擴容；

在不類業務的CN組之間，動態判斷各組的負載情況，當前兩類業務的負載差異較大時，可以自動將閑置資源分配至繁忙組內；

通過租戶（account）的邏輯概念，實現邏輯資源的完全隔離，不同的租戶可以以獨享或共享的方式使用指定的CN資源。

寫在最后

矩陣起源作為一家數據智能領域的創新企業致力于成為數字世界的核心技術提供者。 矩陣起源專注建設開放的技術開源社區和生態系統、打造世界級的團隊、并通過業界領先的技術創新和工程能力，實現數據在數字世界中的任意存儲和任意計算，幫助用戶釋放數據的潛力和創新力（Store Anywhere, Compute Anywhere, Innovate Anywhere）。

整個MatrixOne的架構升級之路，始于0.4迭代，在0.6迭代初步完成，歷時半年多，數十位一線研發與測試工程師投入其中，最終完成了今天的新分布式HTAP架構，團隊與產品共同獲得了成長。在今年，MatirxOne 將會推出第一個 GA 版本，為開發者持續創造價值。

免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據。