隨著數(shù)字經(jīng)濟(jì)加速發(fā)展，企業(yè)數(shù)字化轉(zhuǎn)型正向更深層次推進(jìn)。基于數(shù)字技術(shù)，企業(yè)通過數(shù)據(jù)驅(qū)動，有望實(shí)現(xiàn)創(chuàng)新產(chǎn)品服務(wù)、變革運(yùn)營方式和迭代資源組織模式。而這一切都是建立在企業(yè) IT 基礎(chǔ)設(shè)施之上。

對企業(yè)而言，當(dāng)今正值新一輪科技革命迅猛發(fā)展階段，數(shù)據(jù)規(guī)模爆炸性增長、數(shù)據(jù)類型愈發(fā)豐富、數(shù)據(jù)應(yīng)用快速深化，數(shù)據(jù)庫 / 大數(shù)據(jù)平臺在企業(yè) IT 基礎(chǔ)設(shè)施中發(fā)揮著越來越重要的作用。

— 01 —單模型數(shù)據(jù)庫“落伍”，多模型大數(shù)據(jù)平臺應(yīng)運(yùn)而生

在數(shù)字化轉(zhuǎn)型早期，企業(yè)的數(shù)據(jù)采集、存儲、分析、決策和應(yīng)用場景往往相對單一、成熟，企業(yè)只需購買市面上對應(yīng)的數(shù)據(jù)庫產(chǎn)品即可滿足自身需求。這個階段，對企業(yè)來說，單模型數(shù)據(jù)庫基本夠用。

但是，隨著數(shù)字化轉(zhuǎn)型的深入和企業(yè)的快速發(fā)展，當(dāng)面對業(yè)務(wù)擴(kuò)展、不可預(yù)測的需求變化和企業(yè)管理標(biāo)準(zhǔn)的提高等各類情況出現(xiàn)時，單模型數(shù)據(jù)庫就會“失效”，因?yàn)槠髽I(yè)可能需要使用關(guān)系型存儲、文本存儲、圖存儲、對象存儲、搜索引擎、地理空間存儲、鍵值存儲、寬表存儲、時序數(shù)據(jù)存儲、事件存儲等更豐富的數(shù)據(jù)存儲模型。

問題在于企業(yè)各自獨(dú)立的大數(shù)據(jù)和數(shù)據(jù)庫產(chǎn)品如同一個個數(shù)據(jù)孤島，成為不同場景、項(xiàng)目、業(yè)務(wù)和部門間數(shù)據(jù)互通的壁壘。并且，企業(yè)使用多種單模型數(shù)據(jù)庫將會導(dǎo)致數(shù)據(jù)冗余、數(shù)據(jù)一致性治理難、數(shù)據(jù)跨庫分析難、資源配置難等一系列問題。同時，多產(chǎn)品的語言與接口不統(tǒng)一，學(xué)習(xí)成本高，運(yùn)維成本高，系統(tǒng)的總擁有成本也會不斷升高。

簡言之，這些各自獨(dú)立的大數(shù)據(jù)和數(shù)據(jù)庫產(chǎn)品已經(jīng)不適應(yīng)企業(yè)發(fā)展的需求。

越來越多的企業(yè)逐漸意識到，未來的大數(shù)據(jù)平臺，既要為不同的項(xiàng)目場景配置不同數(shù)據(jù)模型以保障其高性能，又要讓數(shù)據(jù)操作和運(yùn)維更便捷、更統(tǒng)一。在這樣的需求推動下，在一個統(tǒng)一平臺中用多種數(shù)據(jù)模型的“多模型大數(shù)據(jù)架構(gòu)”應(yīng)運(yùn)而生，開始快速發(fā)展。

多模型大數(shù)據(jù)架構(gòu)的本質(zhì)是在一個單一軟件平臺內(nèi)，針對不同的應(yīng)用場景配置不同的數(shù)據(jù)模型，并將操作和運(yùn)維等管理工作統(tǒng)一化、標(biāo)準(zhǔn)化，從而在保障數(shù)據(jù)平臺性能的前提下大幅簡化數(shù)據(jù)平臺運(yùn)維管理難度，提升平臺的彈性與可擴(kuò)展性，解決不同業(yè)務(wù)部門間存在的數(shù)據(jù)孤島問題。

— 02 —多模型大數(shù)據(jù)平臺的“進(jìn)化”

在多模型大數(shù)據(jù)架構(gòu)的發(fā)展初期，業(yè)內(nèi)主流產(chǎn)品僅僅是簡單地將多個單模型數(shù)據(jù)庫使用統(tǒng)一的界面組合在一起。這種平臺內(nèi)部依舊保留了多種類型的數(shù)據(jù)庫，如關(guān)系型數(shù)據(jù)庫、文檔存儲、鍵值存儲、圖數(shù)據(jù)庫等，且不同數(shù)據(jù)庫依舊采用各自獨(dú)立的代碼實(shí)現(xiàn)。

換句話說，這種多模型架構(gòu)本質(zhì)上仍然是單模型架構(gòu)的延伸，只是在形式上將數(shù)據(jù)孤島問題隱藏在統(tǒng)一的用戶界面背后。簡言之，它并沒有真正解決問題。

隨著企業(yè)痛點(diǎn)再次凸顯，業(yè)界開始出現(xiàn)原生的多模型大數(shù)據(jù)平臺。在這樣的平臺上，企業(yè)可以將所有業(yè)務(wù)數(shù)據(jù)匯聚起來，通過平臺搭配的工具操作數(shù)據(jù)，從而挖掘數(shù)據(jù)中潛藏的價值。總體而言，原生多模型大數(shù)據(jù)平臺需要具備以下特點(diǎn)：

滿足一站式數(shù)據(jù)處理需求，能幫助用戶完成一個數(shù)據(jù)處理的全鏈路；

處理多種數(shù)據(jù)模型，包括關(guān)系型數(shù)據(jù)、圖數(shù)據(jù)、文本數(shù)據(jù)等；

具備強(qiáng)大的存儲和計算能力，有能力幫助客戶在海量數(shù)據(jù)中探索價值。

相比早期的拼裝式多模型大數(shù)據(jù)架構(gòu)，原生多模型大數(shù)據(jù)平臺具有天然優(yōu)勢：

更強(qiáng)大的數(shù)據(jù)一致性。業(yè)務(wù)需要不同的數(shù)據(jù)模型時，多模型大數(shù)據(jù)平臺天然支持一份邏輯數(shù)據(jù)實(shí)現(xiàn)多種數(shù)據(jù)建模，并應(yīng)用于多個不同場景，避免了使用多個單一數(shù)據(jù)模型產(chǎn)品時需要面對的數(shù)據(jù)一致性、數(shù)據(jù)導(dǎo)入導(dǎo)出延時、數(shù)據(jù)冗余等問題。

更靈活的資源彈性。多模型大數(shù)據(jù)平臺將不同模型的存儲和計算資源池化，可以根據(jù)業(yè)務(wù)需要隨時增減數(shù)據(jù)模型的種類，靈活部署和回收計算和存儲資源，真正做到按需分配，用完回收，更靈活、更充分的使用好存儲計算資源。

更簡潔的操作與運(yùn)維。多個單模型數(shù)據(jù)庫產(chǎn)品往往接口不同、語法各異，開發(fā)人員學(xué)習(xí)成本高昂，專業(yè)技能門檻高。使用統(tǒng)一的多模型大數(shù)據(jù)平臺時，開發(fā)人員只用學(xué)習(xí)統(tǒng)一的語言、統(tǒng)一的接口來操作多個數(shù)據(jù)模型，難度顯著降低。

原生多模型大數(shù)據(jù)平臺一誕生，很快獲得企業(yè)青睞。據(jù)悉，在 2020 年前，業(yè)內(nèi)主流的多模型大數(shù)據(jù)架構(gòu)主要分為三種實(shí)現(xiàn)路徑，但是各有各的問題。具體而言：

第一種：以? DB2 和 Oracle DB 為代表，分別支持 6 個和 3 個模型種類。這一實(shí)現(xiàn)路徑為每一種新數(shù)據(jù)模型開發(fā)獨(dú)立完整的存算策略。其缺點(diǎn)是存算耦合，支持的模型越多，系統(tǒng)的開發(fā)量和復(fù)雜度就越高，消耗的存算資源也較多。

第二種：以 MongoDB 和 MySQL 為代表，均支持 3 個模型種類。該路徑用單一存儲引擎支撐多個存儲模型。缺點(diǎn)是由于不同計算數(shù)據(jù)模型對存儲的要求不同，單一存儲引擎無法隨之匹配適合的存儲策略，從而限制了多模型數(shù)據(jù)庫的性能。

第三種：以 Couchbase 和 MarkLogic 為代表，分別支持 2 個和 4 個模型種類。第三條路徑在多種獨(dú)立數(shù)據(jù)庫之上提供統(tǒng)一的用戶界面，對底層多個數(shù)據(jù)庫進(jìn)行轉(zhuǎn)發(fā)。缺點(diǎn)是由于底層多個數(shù)據(jù)庫開發(fā)語言不一致，導(dǎo)致實(shí)際開發(fā)時的高難度，排除故障的成本也較高。

為解決上述三條傳統(tǒng)實(shí)現(xiàn)路徑存在的問題，星環(huán)科技于 2020 年實(shí)現(xiàn)了基于分層設(shè)計的第四種多模型大數(shù)據(jù)統(tǒng)一架構(gòu)：提供了統(tǒng)一接口層、統(tǒng)一的計算引擎層 、統(tǒng)一的分布式存儲管理層以及統(tǒng)一的資源調(diào)度層，基于存算解耦支持 10 種數(shù)據(jù)模型。

— 03 —不一樣的多模型大數(shù)據(jù)架構(gòu)：多模型統(tǒng)一架構(gòu)

多模型統(tǒng)一架構(gòu)采用“異構(gòu)存儲，四層統(tǒng)一”設(shè)計，利用統(tǒng)一語言、計算、存儲、資源重構(gòu)大數(shù)據(jù)軟件棧，在一個平臺上支持十種數(shù)據(jù)模型，有效降低數(shù)據(jù)開發(fā)和運(yùn)維的難度，極大提升了用戶開發(fā)效率。

從星環(huán)科技最近發(fā)布的大數(shù)據(jù)基礎(chǔ)平臺 TDH9.0，我們可以一窺其特性：

統(tǒng)一接口層。統(tǒng)一的 SQL 編譯器 Transwarp Quark 可以實(shí)現(xiàn)統(tǒng)一接口，處理不同的業(yè)務(wù)和不同數(shù)據(jù)模型，只需簡單的 SQL 語句即可完成各種復(fù)合跨模型數(shù)據(jù)查詢，無需訪問不同接口即可操作不同的數(shù)據(jù)模型。場景切換、數(shù)據(jù)庫切換造成的接口、開發(fā)語言切換問題不復(fù)存在，開發(fā)和遷移成本大大降低。

統(tǒng)一計算引擎層。分布式計算引擎 Transwarp Nucleon 可以根據(jù)不同的存儲引擎自動匹配高性能算法，不僅可以支持批處理、流處理等不同類型計算任務(wù)，還能支持不同模型數(shù)據(jù)的流轉(zhuǎn)與關(guān)聯(lián)，方便用戶在一個 SQL 中使用不同模型的數(shù)據(jù)，降低開發(fā)難度，提升開發(fā)效率。

統(tǒng)一的分布式存儲管理系統(tǒng)。TDH 可以為不同存儲引擎提供公共的存儲管理服務(wù)，保障數(shù)據(jù)一致性，實(shí)現(xiàn)數(shù)據(jù)統(tǒng)一管理運(yùn)維和高可用。它接入了 9 款存儲引擎，支持 10 種數(shù)據(jù)模型的存儲。用戶不需要為不同模型建立單獨(dú)的存儲系統(tǒng)，而是通過統(tǒng)一的存儲管理，降低運(yùn)維管理成本，也避免了數(shù)據(jù)孤島。分布式數(shù)據(jù)管理系統(tǒng)的插件特性也方便后續(xù)業(yè)務(wù)的靈活擴(kuò)展，可以根據(jù)需要接入其他存儲引擎。

統(tǒng)一的資源調(diào)度層。TCOS 是星環(huán)科技自主研發(fā)的云原生操作系統(tǒng)，提供統(tǒng)一的資源調(diào)度框架，通過容器化編排能統(tǒng)一調(diào)度計算、存儲、網(wǎng)絡(luò)等各基礎(chǔ)資源。TCOS 還支持靈活、按需的異構(gòu)硬件（X86、ARM 混合部署）、異構(gòu)操作系統(tǒng)的水平擴(kuò)展，支持單獨(dú)擴(kuò)展計算或存儲資源的水平擴(kuò)展，避免因業(yè)務(wù)數(shù)據(jù)增長帶來的資源緊張而需進(jìn)行繁瑣的擴(kuò)容、遷移等工作。TCOS 也提供了相比虛擬機(jī)損耗更低的資源隔離能力，使不同租戶、不同應(yīng)用，資源隔離互不影響。

此外，星環(huán)多模型統(tǒng)一架構(gòu)還提供了實(shí)時流計算引擎 Slipstream，滿足實(shí)時監(jiān)測和實(shí)時 ETL 需求；數(shù)據(jù)科學(xué)平臺 Sophon Discover，滿足數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)需求。

TDH 9.0 的統(tǒng)一分布式數(shù)據(jù)管理系統(tǒng) TDDMS 和分布式文件系統(tǒng) TDFS 提供更穩(wěn)定的小文件管理能力和訪問性能，提升了存儲可靠性。星環(huán)分布式交易型數(shù)據(jù)庫 KunDB 則提供了更高性能、更加可靠的元數(shù)據(jù)處理服務(wù)。

— 04 —多模型統(tǒng)一架構(gòu) VS 開源多模型方案

在大數(shù)據(jù)領(lǐng)域，其實(shí)業(yè)界有不少相對成熟的開源產(chǎn)品，很多企業(yè)干脆選用開源產(chǎn)品直接組合成自己的大數(shù)據(jù)解決方案。但是，開源產(chǎn)品也有自己的局限：一是傳統(tǒng)行業(yè)業(yè)務(wù)發(fā)展久，復(fù)雜系統(tǒng)可優(yōu)化點(diǎn)多，技術(shù)功能較集中的開源產(chǎn)品很難系統(tǒng)解決全局問題；二是開源社區(qū)大多由國外技術(shù)人員主導(dǎo)，對國內(nèi)場景缺少針對性調(diào)研和解決策略。

既然開源產(chǎn)品無法解決問題，那么企業(yè)就要考慮其他選擇。相比傳統(tǒng)的開源多模型方案，星環(huán)科技自主研發(fā)的多模型統(tǒng)一架構(gòu)則是更好的選擇，它具備架構(gòu)復(fù)雜度低、開發(fā)成本低、運(yùn)維成本低、數(shù)據(jù)安全性高、數(shù)據(jù)處理效率高等優(yōu)勢。

為什么星環(huán)多模型統(tǒng)一架構(gòu)優(yōu)于開源多模型方案？這是因?yàn)橐环矫妫黔h(huán)多模型統(tǒng)一架構(gòu)高度重視創(chuàng)新技術(shù)的適用性和落地能力，相比開源方案更加重視傳統(tǒng)企業(yè)場景中原有業(yè)務(wù)能否順利遷移的問題；另一方面，其計算引擎以 JVM 為主，存儲引擎以 C++ 編寫，兼顧了性能、功能和上手門檻等方面的客戶需求，相比開源方案具備更高的靈活性和實(shí)用性。同時，它的智能運(yùn)維模塊能夠結(jié)合大數(shù)據(jù)技術(shù)特征與業(yè)務(wù)最佳實(shí)踐，通過對 TDH 平臺上大數(shù)據(jù)服務(wù)特征指標(biāo)的收集，基于智能運(yùn)維規(guī)則庫匹配判斷，提供集群改善運(yùn)維建議，保障集群長期高效穩(wěn)定運(yùn)行。

此外，星環(huán)多模型統(tǒng)一架構(gòu)結(jié)合自身基礎(chǔ)安全組件以及大數(shù)據(jù)開發(fā)工具 TDS，讓用戶在數(shù)據(jù)開發(fā)過程中可以得到全生命周期的數(shù)據(jù)安全防護(hù)，方便用戶建立起數(shù)據(jù)安全環(huán)境與操作流程，保障數(shù)據(jù)安全。

開源大數(shù)據(jù)方案為實(shí)現(xiàn)不同業(yè)務(wù)需求，通常要部署多個不同產(chǎn)品，為此用戶需要學(xué)習(xí)適配多個產(chǎn)品的不同接口，開發(fā)成本較高。這些產(chǎn)品還會使用各自獨(dú)立的計算引擎和存儲方案，數(shù)據(jù)存儲在各自的生態(tài)中難以互通，ETL 流轉(zhuǎn)效率低，也難以保證數(shù)據(jù)的準(zhǔn)確性、一致性和實(shí)效性，最終影響業(yè)務(wù)準(zhǔn)確性。各自獨(dú)立的計算引擎若部署在同一節(jié)點(diǎn)上，也可能會引起計算資源競爭問題。

相比之下，多模型統(tǒng)一架構(gòu)把多種數(shù)據(jù)模型的接口層、計算引擎層和分布式存儲管理均抽象出來，避免了多個接口標(biāo)準(zhǔn)不統(tǒng)一、計算資源搶占、存儲不統(tǒng)一等問題。一個 SQL 就可以實(shí)現(xiàn)不同數(shù)據(jù)模型的操作和查詢、模型轉(zhuǎn)化流轉(zhuǎn)以及跨模型關(guān)聯(lián)分析，解決了不同模型數(shù)據(jù)之間的組合使用問題。

以跨模型聯(lián)合分析應(yīng)用場景為例。這個場景需要研究 30 歲人群的消費(fèi)習(xí)慣和喜好，為此將該人群消費(fèi)的商品評價作為參考。為獲得該人群對某商品的評價數(shù)據(jù)，需要進(jìn)行三次檢索，用到圖數(shù)據(jù)庫中的人群關(guān)系型數(shù)據(jù)、關(guān)系型數(shù)據(jù)庫中的人群消費(fèi)記錄數(shù)據(jù)，以及搜索引擎中消費(fèi)商品評價數(shù)據(jù)。

定位 30 歲的人群。首先連接到圖數(shù)據(jù)庫中，使用圖數(shù)據(jù)庫查詢語言，找出 30 歲人群一度關(guān)系的人群 ID 集合；

獲取該人群的消費(fèi)記錄。連接到關(guān)系型數(shù)據(jù)庫中，使用 SQL 查詢語言，用第一步獲取的人群 ID 作為過濾條件，獲取該人群消費(fèi)商品 ID，找出這些人群消費(fèi)了哪些商品；

獲取包含特定關(guān)鍵詞的商品評價。接入搜索引擎，編寫 RESTful API 請求，使用前兩步獲取的人群 ID 和消費(fèi)商品 ID，檢索商品評價。

為完成這個業(yè)務(wù)，用戶需要搭建 3 個獨(dú)立的數(shù)據(jù)庫，并在應(yīng)用適配 3 種數(shù)據(jù)庫的連接方式和查詢語言，同時還要求開發(fā)人員同時了解這 3 種數(shù)據(jù)庫的開發(fā)技術(shù)，整個流程非常復(fù)雜，技術(shù)要求非常高。此外，3 個獨(dú)立系統(tǒng)的數(shù)據(jù)可能存在不一致，比如消費(fèi)記錄更新到了關(guān)系型數(shù)據(jù)庫，但相應(yīng)的評價沒有更新到搜索引擎中，導(dǎo)致分析語句的結(jié)果不準(zhǔn)確。

而基于星環(huán)多模型統(tǒng)一技術(shù)架構(gòu)，用戶只需一句 SQL 就能同時訪問這 3 種存儲模型進(jìn)行聯(lián)合分析，替代之前的三段代碼。一句 SQL 同時對圖數(shù)據(jù)人群關(guān)系表、關(guān)系型數(shù)據(jù)消費(fèi)記錄表、全文數(shù)據(jù)商品評價表進(jìn)行跨模型關(guān)聯(lián)，大大簡化了開發(fā)復(fù)雜度。同時，數(shù)據(jù)仍保留在原存儲引擎中，無需對數(shù)據(jù)進(jìn)行導(dǎo)入導(dǎo)出或者轉(zhuǎn)換，不存在數(shù)據(jù)不一致或數(shù)據(jù)冗余存儲等問題。

— 05 —寫在最后

面對愈加復(fù)雜的企業(yè)大數(shù)據(jù)應(yīng)用需求，多模型統(tǒng)一架構(gòu)具備易開發(fā)、易運(yùn)維、低成本、高性能、可擴(kuò)展、強(qiáng)安全性等多方面的優(yōu)勢，能有效打通企業(yè)不同業(yè)務(wù)部門之間的數(shù)據(jù)孤島，充分挖掘海量數(shù)據(jù)中潛藏的價值，為企業(yè)提供一站式的大數(shù)據(jù)業(yè)務(wù)解決方案。

自 2013 年以來，星環(huán)科技的 TDH 大數(shù)據(jù)基礎(chǔ)平臺已經(jīng)基于多模型統(tǒng)一架構(gòu)走過了 9 年的迭代升級道路，成為一款國產(chǎn)自主可控的多企業(yè)級大數(shù)據(jù)基礎(chǔ)平臺，可以替代 Oracle、DB2、Teradata 等傳統(tǒng)主流數(shù)據(jù)庫在分析型場景中的應(yīng)用，替代 ElasticSearch 在分布式搜索場景中的應(yīng)用，并在政府、金融、能源、制造業(yè)等十多個行業(yè)內(nèi)落地。TDH 還完成了與主流信創(chuàng)生態(tài)廠商的適配互認(rèn)工作，滿足信創(chuàng)驗(yàn)收要求。

最近，星環(huán)科技基于多模型統(tǒng)一架構(gòu)對多模型處理能力進(jìn)一步加強(qiáng)，從整體上進(jìn)一步提升了平臺綜合性能、可靠性、易用性以及安全性，為企業(yè)數(shù)字化轉(zhuǎn)型構(gòu)建了統(tǒng)一、高性能、高可靠，更全面、更便捷、更智能、更安全的新型數(shù)字底座，為企業(yè)數(shù)字化轉(zhuǎn)型注入更強(qiáng)動力。未來，星環(huán)科技將持續(xù)自主研發(fā)與技術(shù)創(chuàng)新，強(qiáng)化大數(shù)據(jù)平臺統(tǒng)一多模型處理能力，為大數(shù)據(jù)社區(qū)與人才培養(yǎng)提供領(lǐng)先的技術(shù)力量，挖掘大數(shù)據(jù)技術(shù)的更大潛力。