一、Matrixone 的早期架構與難題

MatrixOne 早期的架構與現在有很大區別。早期的架構可以總結為兩個詞：一個是 NewSQL，一個是 MPP。

NewSQL 是當年谷歌的幾篇論文衍生出來的分布式數據庫的一套理論體系。其中最重要的一點就是分布式架構，解決的是傳統數據庫的高可用以及水平擴展的難題。另外一點就是多引擎，用不同的引擎來做不同的事情。

MPP 或者叫大規模并行計算，主要的用途是通過分布式的方式將一些規模比較大的計算任務分布到不同的節點，并且在計算完成之后匯總。充分利用了分布式架構的算力資源。

我們早年的架構確實也是這個樣子。上面有一個負責分發負載均衡的 proxy。下面是 MatrixOne Server，每一個 Server 下面有自己的存儲。是一個存算一體的架構，每個節點看似是對等的。當然這里面存在著一些問題。

再來看一下組件詳解。

最上面這一層我們叫 SQL 前端，是為了兼容 MySQL 的語法協議，無論用 MySQL client，還是 JDBC 都可以直接連。

計算層是傳統的 SQL Parser，支持語法樹的解析，以及多方言的 SQL。

最下面就是我們自己寫的 MPP SQL 執行器，針對基礎引擎做了一些向量化的加速，部分操作甚至用匯編語言做了改寫。當時使用了一個比較獨到的因子化加速的能力。

當時這套架構有著相當不錯的性能表現。

分布式框架這一層，叫做 MatrixCube，是一個開源的項目。提供了一個對于多臺機器的分布式存儲框架。具備高可用多副本，負載均衡強力制等基礎能力。當時設想是用它來為 Matrix 計算提供分布式事務的支持能力。里面有 Raft 協議，而且中間會有一個調度器叫做 Prophet。

最下面是計算層和存儲層。存儲層除了引擎接口之外，有三個引擎。

最中間的叫 AOE，不支持事務，可以往里寫數據，但是對于事務、去重等基本上是不支持的。最左邊的叫 TPE，用來保存元數據 catalog，它是一個非常繁忙的引擎。最右邊的叫TAE，是一個典型的列式存儲，能夠提供完整的 ACID，同時我們希望它能夠去支持比較大規模的 OLAP 能力。所以早期的一個問題是三個存儲運行，這也是后來我們為什么從架構層面整個進行重構的一個原因。

接下來講一講原有架構存在的問題。

擴展性：

• 存算不分離，每擴展一個單位的節點，就要去擴展相應的存和算兩種資源。
• 因為數據以3副本形式保存，只要一個節點加進去，想要真正接管計算任務的時候要先把整個存儲完成同步，預熱的時間非常長。比如我們大概有 1TB 的數據，要先等著 1TB 數據的3副本完成在這個節點上的同步，才能去開始提供所有的計算負載。

性能：

• 因為 Raft 協議一定是有一個 leader， leader 節點容易成為熱點，很多的調度任務都從它這里走。
• 在性能比較差的存儲下，整體性能下降會超過預期。比如我們用 SSD 做 benchmark 測試時，預計其性能是10，我們最早預想 HDD 能跑到5或者6，但是實際情況是我們在HDD 上可能跑出來的結果只有3或者4，這成為了一個性能上的瓶頸。
• TPE、 AOE、TAE三個引擎，用途不同而且性能也不一樣，經常會出現在某一個業務場景三個引擎當中的一個成為了整個性能的瓶頸。

成本：

• 節點規模越大，成本線性增長，負擔越來越重，到了公有云上，有的公有云提供了一個高可用的方案，就成了殼子套殼子，就不是線性而是指數級增長了。可能我要用3個節點的時候，數據庫里存了9副本。然后在公有云又可能做了一個3層冗余那就是27層。到后面客戶所承擔的成本負擔實在是太重了。
• 只有高配存儲才能發揮出預期，性能較差的存儲架構發揮不出來我們想要的性能特性的時候，只能通過不斷增加存儲成本的方式來滿足需求。

二、Matrixone 架構升級之路

面對這些問題，從2022年3月開始，我們對整個架構進行了升級。其實我們是從0.5開始的，0.1到0.4還是在探索，不斷思考不斷試錯，直到0.5的時候，我們終于意識到這個架構走不下去了。

原有架構存在三座大山。

第一座是分布式框架：

• 多副本存儲帶來存儲成本的飆升。
• Leader 選舉，人為制造了熱點。

第二座是引擎眾多：

• 三個存儲引擎彼此之間的代碼復用率非常低，一個新的功能，代碼的維護量是3倍。
• 因子化算法過于激進，除了主開能夠駕馭這個算法，其他同事參與度非常低，只能做一些輔助，加一個功能都會非常困難。

第三座是資源分配：

• 存算不分，做各種資源配比的時候，不同業務場景的隔離性非常差。
• Share-nothing 架構，擴展性非常差。必須同時擴展存和算兩種資源。

在總結出這三大根本問題之后，我們開始做架構升級。

左側圖可以看到，一層套一層，各層之間又是強依賴的關系，所以第一步就要先把各層徹底打散，做一個更加靈活解耦的整體架構。

最后我們將存儲層單獨做了一層，可以使用各種存儲，并把所有的cache服務放在存儲層來做。

最上面是計算層。所有的 MPP 以上的無論是前端還是 Parser，或是執行器，全都放到計算層。

中間我們開發了一個新的層，叫做事務層，可以看作 log service。與傳統關系數據庫中的 Redo 或者 PG 里的 WAL 日志非常類似。而我們還有一個事務節點 DN，專門用來做事務服務，因為我們是一個分布式數據庫，涉及到分布式的事務裁決，包括去重、落盤等任務。所以最終選擇開發一個單獨的事務層來專門處理這些東西。

三個存儲引擎中，我們認為留下 TAE 最合適，它能夠提供基于列存的 TP 引擎，并且可以做到完整的事務的原子性、一致性、隔離性和數據一致性，完整的 OLAP 能力，所以是最適合用于新架構的一個引擎，剩下兩個引擎的一些功能想辦法融到TAE里。所以最終我們看到的是 TAE，它是用列式的編碼來存 column family，可以在行和列之間靈活切換。這樣做的好處是，可以同時運行 TP 和 AP 的負載，因為我們經常說行存更適合 TP，列存更適合 AP，現在做一個轉換之后，行和列就都能夠兼顧到了。另外，所有的表都能夠實現表級別的快照事務隔離。并且支持主鍵、唯一鍵排序、外鍵索引。

前文提到，數據要保存三副本，而且每個副本在數據庫里面是以分片的形式保存，用操作系統自帶的 cache 來完成冷熱數據的管理。新架構有一個新的要求，就是冷熱數據盡量分離，讀寫請求分離，實現對存儲的精細化管理。所以最后我們選擇了 AWS 的 S3 對象存儲，私有化部署提供 S3 的協議兼容的對象存儲。熱數據保存在計算節點的緩存cache 上，所有的節點都實現了無狀態。并發能力可以通過多啟動幾個計算節點來線性提升。三個層級之間不再過度依賴。

分布式存儲完成之后，就是計算層。之前是因子化算法構建執行計劃，做復雜的查詢加速，主要是提高AP性能。但表達式和節點的抽象與表述過于復雜，增加修改功能難度很大。并且多個引擎之間的代碼復用率太低，導致工作量成倍增長。所以我們開發了新的 MPP 執行引擎，基于 DAG 來構建執行計劃，能夠實現節點內和節點之間的自適應調度。同時能夠滿足并行和并發兩種請求，因為我們都知道并行是 AP，并發是 TP，通常大家會這么去處理。而且 SQL 能力得到了完善，具備了子查詢、窗口函數、CTE，還有內存溢出等能力。未來的優化空間更大，無論是我們的主開還是其他的計算組成員都可以進行優化加新功能。

下面來看一下現在總體的架構。

最下面是 File Service，這是一個統一的文件讀寫的服務接口，它能夠從 S3 對象存儲去讀數據，并且把這些數據推給日志、計算節點或者事務節點等等。而且事務節點和計算節點的日志又可以通過它去寫 S3。所有的節點只需要與 File Service 打交道，就能夠完成對存儲的讀寫。全量的存儲都可以保存在 S3 上，公有云版的 S3 成本非常低，并且可以無限伸縮。上面的事務層，有兩個 DN 節點專門負責管理日志服務和元數據。平時會在里面緩存元數據，做一些事務裁決，并且會指揮 log service 的日志服務來落盤寫數據。它自己就是通過三副本的方式來保證從日志級別上的高可用，這里還有一個 Logtail，后面會詳細解釋 Logtail 和現在的落盤的數據之間是如何共同完成數據寫的過程的。

最上面是我們所有 Severless 的計算節點，叫 CN 節點。計算節點是完全無狀態的，每個計算節點有自己的 cache，好處是如果計算的負載比較高就可以多起幾個 CN，如果業務比較少，就可以把節點全都宕機，節省一些成本。

存儲層 TAE 完全實現了列存。大家可看到從數據庫到表，再到 segment，再往下是很多列，列的單位是列級別的 block。一次讀的時候，會從一個列里面去讀一些行作為一個 block，推給上面的計算節點或者日志節點。

大家可能會比較關心如何在 AP 和 TP 之間找到一個平衡點，現在默認建一張表，都是列。如果某些表想要強化一下行存的性能，我們建一個叫做 column family，對某一些行做一些特殊的優化，對一些可能需要頻繁在上面做索引，或者需要更新的列，通過 column family 列的方式能夠大幅提升其TP性能，最終只需要存一個副本。我們在表上做好一些優化之后，就可以實現行存和列存在各自性能上的優勢。這個 column family 現在還正在開發當中，會在未來的一兩個版本迭代之后推出一個最初的版本。

計算方面，實現了節點之間的調度。上圖中可以看到，所有的計算節點之間都有個雙箭頭，含義是比如從最左邊的計算節點進來，需要去做一個數據的查詢，但是我發現 cache 里面沒有想要的數據，就會遍歷所有其它計算節點去找想要的數據；如果找到，就直接在那個節點里面把計算任務完成，再把結果返回到最初的接受請求的節點。這樣的好處是最大限度地利用了不同節點緩存不同的熱數據。對于一些常用的查詢，會有非常大的性能提升。而且現在我們的計算節點，除了緩存以外，上面還有一個自己寫的pipeline，將很多的 SQL 請求拆解成為物理執行計劃來執行。上面是目前正在開發的一個優化器，而最上面就是我們一直在迭代的代碼復用最多的 MySQL 級別的 Parser。能夠對語法做一些解析，同時還能夠去做一些方言上的支持。比如對 PG 的語法和方言的支持，其實都是用 MySQL Parser 來做的。

三、Matrixone 架構升級的困難與收獲

接下來介紹我們在架構升級中遇到的困難，和解決方案。

第一個難題是如何尋找一個能夠對高性能計算引擎匹配的存儲。兩個核心的需求：

• 一個是更少的冗余。
• 一個是更低的使用成本。

經過很多的論證之后我們發現，AWS 的 S3 對象存儲能夠完美地匹配我們這兩個核心需求。比如我們現在整個單副本，在AWA基本上是一點幾個副本。多了約20%的冗余，成本比起之前的三副本大幅下降。使用上，現在匹配 S3 的各種接口，各種方式開發都已經慢慢的成熟起來，還有 S3 自帶的冷熱分離，一方面將冷數據放在 S3 里面降低成本，而熱數據放到計算節點上，基本上完成了用更低的成本來實現冷熱數據分離。

第二個難題就是事務層的分工，分布式數據庫的分布式事務始終是一個非常大的難點，一開始我們希望我們的 CN，即計算節點只負責計算，所有的事務 ID 生成，事務裁決，還有一致性隔離性，包括數據的讀寫全都由 DN 也就是事務節點來完成。所有的沖突檢測、約束完整性也都由 DN 來完成。但是后來發現，DN 會成為瓶頸。因為我們平時啟動的事務節點的數量遠遠少于計算節點的數量，如果事務節點起的多了，在事務裁決上多個事物節點之間同步又會出現問題。所以當時 DN 成為了一個瓶頸。

于是我們做的第一件事情是引入了 Logtail 的概念。我們平時寫數據時首先把數據這個操作寫到日志里，然后再落盤去寫。這樣的好處是如果寫的過程當中發生宕機，我們只需要回放日志，就可以保證數據最終還是可以落盤的。現在在日志里保存數據 Logtail，然后 Logtail 會定期把這部分數據寫入到 S3 對象存儲，就不需要頻繁地去寫。這樣的好處就是我們在寫的時候，不再局限于整個 DN 的寫的性能。DN 只需要攢夠一大批一起往里寫一次。當 DN 不怎么忙的時候，可以選擇在自己不怎么忙的時候把它寫進去。忙的話就全都緩存在 Logtail 里，這樣 CN 只需要負責所有的事務和事務邏輯，還有計算。DN 既保留最近一段的數據，同時又負責日志服務，這樣就把 DN 在一定程度上解放了出來，使得寫入動作的上限被打破了。但是還面臨一個問題，就是事務量非常大的時候怎么樣保證寫的性能。當時我們選擇一個新的策略，如果批量寫入一大批數據，比如一下寫入幾百兆的數據的時候，我們不再通過日志，而是直接往對象S3里寫。只是告訴日志服務我要通過什么樣的操作，在哪個文件里寫什么東西。而那些比較小的事務，比如只是更新一兩行數據，或者插入一個新數據，仍然還是走原來的從計算節點到事務節點再到對象存儲這樣一個過程。并且現在我們將約束完整性和沖突檢測，都放在了 CN 來做。就在一定程度上讓事務 DN 節點更加的靈活，整個的負載更輕。寫入性能可以得到明顯的提升。

現在還面臨一個問題，就是我們如何實現不同業務類型的負載工作。工作負載的隔離，按照現在的架構，首先計算節點先把數據推給事務節點，事務節點再通過日志寫到 S3 里。如果是 OLAP 負載，可能直接從 S3 里面去讀數據來進行計算就可以了。我們現在選擇的方式是用不同的 CN 節點來跑不同的東西。比如成立第一個 CN 組，只跑 TP 業務，第二個 CN 組，只跑 AP 業務，實現計算節點之間的隔離。當然如果系統比較重要，預算比較充裕，那可以選擇用機器做服務器級別的隔離，用物理機來部署不同的計算節點。如果想用低成本的機器跑，我們也提供了容器級別的隔離，容器級別可以實現數據和負載的完全隔離。

我們現在首先做了標簽化。比如圖中有三個打了 AP 的標簽，一個打了 TP 的標簽。當一個會話進來的時候，優化器會先去判斷它是一個 AP 請求還是 TP 請求。如果是 TP 請求，就進TP的計算節點，如果是 AP 就進 AP 的計算節點。這樣的好處就是不會出現兩種業務上的資源公用。哪邊業務更高，我就選擇對哪一邊分配更多的資源。未來還會實現自動的負載均衡。比如利用優化器，通過某一段時間的統計信息來判斷最近可能TP業務更多一些，那么就自動擴容一些 TP 的計算節點，AP 更多的話就自動擴容一些AP的節點。目前公測的0.8版，主要提供給用戶的是手動的通過配置標簽的方式，讓用戶把自己的不同類型的負載打到不同的計算節點上來實現。

我們在整個升級過程中，進行了一些技術上的復盤，總結了其中的收獲。

我們對一條 SQL 從客戶端進入服務器再到完成執行的整個過程進行了重構。對 SQL 的執行有了更深刻的理解，對執行計劃、SQL 標準有了更多的認識。

之前我們是多引擎，有的引擎開發的時候不需要考慮事務的 ACID。現在則不同，每一條都要考慮事務的四個特性。

在開發事務層的時候，對 CN 和 DN 的適配有了更多的經驗積累。作為分布式事務到底該怎么分工，既能夠保證完成事務的 ACID，同時又能夠保證讓系統的架構和系統的負載不會出現明顯的短板。我們經過反復的驗證，最終引入 Logtail。并且 CN 和 DN 一個只負責元數據，另外一個負責計算和邏輯以及去重。我們還發現 Logtail 還有一個好處，就是可以實現不同的計算節點對這一部分數據的共享，不需要再從對象存儲里直接 load。

存儲層，積累了對S3對象存儲的開發經驗。另外，我們現在自己的file service文件服務基本上已開發完成，很多時候使用不同類型的存儲，不再需要考慮接口要怎么寫，或是兼容性和性能，統一交給file service去實現即可。

四、總結

最后進行一下總結。

首先，實現了從存算一體到計算、事務、存儲三層解耦。存算一體的分布式架構有著其自身的優勢，但是存在一些問題，比如容易制造熱點，成本較高等等。我們完成了三層的解耦之后，每一個層級可以自行進行擴縮容，不再依賴于其它層面。這種靈活解耦的架構，在不同的業務需求上，可以得到不同的最佳實踐。比如有些業務，可能需要更多的計算資源，可以直接加計算資源。

第二，實現了從多引擎到單一 TAE 的 HTAP 融合引擎。多引擎要維護大量代碼，并且要考慮每個引擎的特性之間如何搭配。而單引擎，無論工作量還是成本都有所降低。

第三，實現了因子化算法到 DAG。

第四，實現了從多副本存儲到對象存儲與 Logtail 的引入。存儲成本降到了原來的1/3左右。

第五，實現了靈活調整節點分配帶來的資源隔離。一方面存算分離，可以更加靈活地分配資源。另外通過標簽的方式，將一些請求強制隔離到不同的節點上，避免了不同業務類型對資源的征用。

如果希望進一步了解或探討，歡迎大家關注我們的企業服務號或加入微信群，會有很多干貨，以及我們最新的進展在上面發布。

最后，介紹一下我們公司現在在做的 Beta Program 用戶體驗計劃。這是我們為一些即將有合作意向的客戶提供的一個專屬的計劃。參與該計劃，可以獲得最新的功能發布信息；并且可能得到匹配您的業務場景的定制；甚至可以參與到產品的設計當中。

目前0.8版本，處于 Beta program 階段，我們會在第三季度發布正式版。我們現在也提供了公有云版，處于公開招募階段。如果感興趣，也可以申請使用。目前我們使用的是serverless計劃，可以在上面跑一些 TBC 或者 TBCC 這種比較常見的 benchmark。如果您有一些基于 MySQL 開發的應用程序，可以在我們的產品上面進行測試。

以上就是本次分享的內容，謝謝大家。

五、Q&A

Q1.：后期有沒有計劃接入更多的存儲引擎，比如 minio，或者是 HDFS 之類的引擎？

A1：我們現在私有化的場景就是以 minio 作為私有化部署的方案，當然整個對象存儲也會越來越多。在 minio 比較成熟以后，我們也會選擇更多的存儲對象來支持。現階段我們的標準的私有化版本是 minio，公有云版本是 S3 或者阿里云的 OSS。

Q2：對企業級用戶是否有定制化的支持，比如對于解決方案的設計，運維的設計等等。

A2：是有的。首先我們現在企業付費用戶，會有一個單獨的運維工具，可以更好地進行集群管理、私有管控等等。如果需要定制化的設計開發，或者一些應用程序的優化等需求，也可以聯系我們。

Q3：為什么設計成單獨的存儲，Logtail 不放在統一的存儲層？

A3：我們給 Logtail 配的是比較好的存儲，直接在里面緩存的時候，往里寫的性能比S3要更好。相當于起到一個中轉作用。另外，Logtail 存在 DN 里面的話，不同的 CN 只要數據沒有落盤沒有被 truncate 之前，所有的 CN 都可以共享。比如恰好就需要 Logtail 數據的時候，直接從 Logtail 里讀不需要再走 S3，這樣在一定程度上也就實現了對 CN 的加速。

Q4：怎么體現冷熱跟讀寫分離？

A4：首先，S3 自身提供了一個冷熱數據分離的機制。它可能讀取速度會比冷數據稍微快一些。其次，我們在每一個節點上，不管是 DN 還是 CN，也放了自己的緩沖區。允許用戶把一些常用的數據放在自己的內存里，如果除了內存以外，在每個節點上再配一塊高性能盤，再緩存一些數據，其實也可以做。實際上冷熱數據實現了多機分離。