導讀：文本介紹了矩陣起源技術(shù)副總裁秦姝琦對MatrixOne設(shè)計和研發(fā)過程中的思考。矩陣起源是一家數(shù)據(jù)智能領(lǐng)域的創(chuàng)新企業(yè)，MatrixOne是矩陣起源研發(fā)的超融合異構(gòu)云原生數(shù)據(jù)庫。

HSTAP 為何會被提出

一個技術(shù)概念之所以被提出，究其根本還是為了解決某一類痛點問題。

秦姝琦拿一個典型的融合型場景為例，一款股票 APP 本身是交易系統(tǒng)，所以它需要一個 OLTP 數(shù)據(jù)庫做支撐，但是用戶又希望其提供股市的預(yù)測和分析，這里自然就出現(xiàn)了對 OLAP 系統(tǒng)的需求，即在做大規(guī)模交易的同時，還需要基于交易數(shù)據(jù)和用戶行為數(shù)據(jù)進行分析建模。

要想解決上述問題，常規(guī)的技術(shù)方案是怎樣的呢？如下圖所示，企業(yè)需要用到非常多的中間件來搭建一個復(fù)雜的數(shù)據(jù)系統(tǒng)，其中包括 OLTP 數(shù)據(jù)庫、OLAP 數(shù)據(jù)庫，消息隊列、流引擎、ETL 工具等等，這樣一來，會導致系統(tǒng)變得非常復(fù)雜，難以保證穩(wěn)定性；其次，數(shù)據(jù)流轉(zhuǎn)的鏈路也變得很長，實時性無法保證，數(shù)據(jù)血緣管理難度很大，這種基于“縫合”方式搭建的系統(tǒng)，在穩(wěn)定性、實時性以及運維管理成本和開發(fā)成本上存在很多痛點。

在剛剛結(jié)束的 2022 re:Invent 大會中，亞馬遜云科技提出了一個新的名詞——“Zero-ETL”，其本質(zhì)也是識別到了數(shù)據(jù)流轉(zhuǎn)已經(jīng)成為企業(yè)很大的痛點。不難看出，簡化復(fù)雜架構(gòu)，降低運維使用成本的需求正在不斷增長。為了讓企業(yè)只用一款數(shù)據(jù)庫，就能把最基礎(chǔ)的業(yè)務(wù)中臺和數(shù)據(jù)中臺以最低的成本建設(shè)好，矩陣起源對 HTAP 進行了重新定義，融入了串聯(lián) AP 和 TP 的 Streaming 能力。因此，在秦姝琦看來，HSTAP 的出現(xiàn)便是為了簡化數(shù)據(jù)系統(tǒng)的復(fù)雜性，提供極簡的用戶體驗，降低數(shù)據(jù)使用的難度，讓企業(yè)可以將精力從繁雜的技術(shù)細節(jié)中釋放出來，專注于數(shù)據(jù)價值的挖掘，最終達到降本增效的目標。

MatrixOne 的自研之路

MatrixOne 從設(shè)計之初便放棄了一條相對容易的路，選擇從 0 開始自研，用時七個月將 Share Nothing 遷移到云原生架構(gòu)，從 AOE（Append Optimized Engine）存儲切換到 TAE（Transactional Analytical Engine），重寫了計算引擎（Parser，執(zhí)行計劃，優(yōu)化器等），并且完成了分布式事務(wù)框架和高性能日志服務(wù)的研發(fā)，累計刪除代碼 30 萬行，新增 20 萬行。

回憶起 MatrixOne 的起步期，秦姝琦提到：“在真正設(shè)計開發(fā)這樣一款云原生 HSTAP 數(shù)據(jù)庫的時候，我們面臨非常多的艱難選擇。”

具體來說，用戶對于 TP 和 AP 數(shù)據(jù)庫系統(tǒng)的需求基本可以歸納為以下五點：ACID，并發(fā)性能，吞吐，成本和數(shù)據(jù)新鮮度。HSTAP 數(shù)據(jù)庫若想兼容以上能力，實現(xiàn)起來卻沒那么容易，由于高并發(fā)、短時延的 OLTP 負載與帶寬密集型、高時延的 OLAP 負載的訪問模式不同且它們互相干擾，把他們?nèi)诤系揭粋€系統(tǒng)里存在很多的沖突點。

談及如何平衡上述矛盾，秦姝琦以通信領(lǐng)域中兩個耳熟能詳?shù)母拍顬槔侯l分復(fù)用和時分復(fù)用，即當突破資源粒度劃分得足夠小，資源隔離做得足夠好，調(diào)度能力足夠強時，就可以把一些看似矛盾的功能平衡起來。“因此，在設(shè)計 HSTAP 數(shù)據(jù)庫時，我們不會追求以上提到的五點在同一時間都做到 100 分，而是基于統(tǒng)一存儲引擎，對象存儲，自適應(yīng)計算優(yōu)化，計算存儲獨立擴縮容，全局的資源調(diào)度和資源隔離策略動態(tài)平衡這五個看似矛盾的特性，來適應(yīng)不同的負載場景需求。”

基于這樣的設(shè)計理念，MatrixOne 引擎的頂層設(shè)計架構(gòu)，可以大致分為三層：計算層、分布式事務(wù)層和共享存儲層。其中，計算層是由多組計算資源組成的，其中計算單元我們稱之為 CN，每個 CN 可以承擔不同的任務(wù)，但無論 CN 用于何種用途它本身是不保存任何狀態(tài)的，以保證計算層是可以任意擴縮容的；再往下面一層是 Transaction Layer，這一層承擔了分布式事務(wù)處理的相關(guān)工作。分布式事務(wù)層選擇了 share-nothing 的模式，由于每個 DN 之間需要處理的數(shù)據(jù)范圍各不相關(guān)，這樣做的好處在于，每個 DN 只需要負責自己這部分數(shù)據(jù)的沖突檢測，從設(shè)計上簡化了 DN 的實現(xiàn)復(fù)雜度和擴縮容的難度；再往下是兩個服務(wù)，一個是 Log service，為 DN 提供高性能的分布式高可用的日志讀寫服務(wù)，它直接決定事務(wù)寫性能的關(guān)鍵；另外一個是共享存儲，這里不僅支持 S3 這類對象存儲，還支持 NFS 以及 HDFS。

此外，為了讓 MatrixOne 在云上和私有化場景能夠保持統(tǒng)一的架構(gòu)和接口，還在底層架構(gòu)中抽象了一層 fileservice 接口，它會將底層不同的共享存儲實現(xiàn)細節(jié)屏蔽掉。比如，在云上選擇S3作為底層共享存儲，那么在私有化場景不一定有 S3，客戶如果能提供 HDFS 集群，就可以通過 fileservice 在保持引擎接口一致的前提下，支持多種的共享存儲。

除此之外，MatrixOneGA版本將會有一個重要的特性——實現(xiàn)了Streaming的方案，即HSTAP中的“S”。秦姝琦坦言，目前的 Streaming 還處于早期階段，團隊關(guān)注的核心問題還是 framework 的設(shè)計、有界數(shù)據(jù)和無界數(shù)據(jù)的處理以及增量計算的優(yōu)化等等。

MO Cloud 的打造

秦姝琦表示，為了給用戶帶來簡單、易用的最終體驗，MatrixOne 也計劃上線全托管 MatrixOne 服務(wù) -MO Cloud，目前已經(jīng)處于開發(fā)階段，目標支持多個國內(nèi)外公有云如 AWS、GCP、華為云、阿里云等，其具備的主要特點是 SaaS 化的使用體驗，免部署、自動化運維、按量計費、成本低。

秦姝琦主要為我們介紹了 MOCloud 在資源隔離方面的實現(xiàn)進展。在數(shù)據(jù)的可見性上，MOCloud 可以保證邏輯上的隔離，一個 Session 只能看到這個租戶權(quán)限范圍內(nèi)的數(shù)據(jù)，在資源隔離上，還計劃用 Proxy+rule engine+CN 來完成一個全局的流控和資源調(diào)度，CN 支持獨占 Set 來滿足更多元化的要求。此外，針對大家關(guān)注的安全問題，MOCloud 也會保證持久化的數(shù)據(jù)是加密的，未來將支持“ bring your own key”的模式，支持租戶維度的數(shù)據(jù)加密。

未來發(fā)展方向

數(shù)據(jù)庫從來都不會單獨被使用，尤其對于初創(chuàng)的數(shù)據(jù)庫廠商而言，完善生態(tài)也是非常重要的工作。秦姝琦透露，在更完整的生態(tài)對接方面，MatirxOne 將在明年陸續(xù)在開源項目上開展對接，還計劃針對制造業(yè)、能源、新興互聯(lián)網(wǎng)等行業(yè)，制定相應(yīng)的解決方案，為此也會在 MatirxOne 中接入相應(yīng)的生態(tài)。

與此同時，她還介紹了 MatirxOne 在未來的產(chǎn)品規(guī)劃。預(yù)計在明年，MatirxOne 將會推出第一個 GA 版本，接下來還將繼續(xù)融入流的能力，力爭通過一個 HSTAP 數(shù)據(jù)庫滿足通用場景的需求。雖然實現(xiàn)起來還需要一定的開發(fā)周期，但我們也很樂于看到，未來有更多的數(shù)據(jù)庫廠商能夠通過創(chuàng)新的架構(gòu)實踐、極簡的設(shè)計理念，來不斷降低企業(yè)使用數(shù)據(jù)系統(tǒng)的復(fù)雜度和門檻。

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