大資料已經成為當代經濟增長的重要驅動力

數字經濟，已經成為當今經濟發展中非常重要的一部分。

與農業經濟、工業經濟如出一轍，數字經濟活動需要土地、勞動力、資本、技術以及相應配套基礎設施。不同之處在於：第一，很多要素都需要數字化；第二，會產生“資料”這一新的生產要素。

在資料要素市場化配置上升為國家政策的當下，大資料已經成為推動經濟高質量發展的新動能。由於物聯網，工業網際網路和各種智慧裝置的廣泛應用，智慧化裝置所產生的資料日益龐大。而要支撐如此體量和型別多樣的資料採集，儲存, 應用及市場化離不開大資料技術。

大資料技術仍然只有少數大型企業能掌握

時至今日，大資料概念不再晦澀，其技術已經發展了近 20 年。網路新聞，線上購物，網際網路打車等場景都是大資料常見的應用。

然而在產業側，企業對大資料的應用落地卻不盡如人意。大資料技術棧的複雜性和落地成本讓絕大部分中小企業望而生畏。

有不少盲目上馬資料平臺/資料中臺專案的企業最後竹籃打水一場空，為什麼企業應用大資料技術如此之難呢？讓我們通過兩個典型的資料平臺案例來一探究竟。

案例 1：大資料營銷系統

大資料營銷系統常見於網際網路行業，零售行業，金融行業。

核心是在平臺採集大量使用者行為資訊後，對使用者喜好打上一定標籤，同時把同類型的廣告或者產品分發到對應類別使用者終端上，以提升整體銷量或者廣告點選率。構建這類大資料營銷應用相當複雜。

典型的營銷資料平臺架構如下圖所示。

其中分成離線和實時兩套鏈路。離線鏈路負責大批量的資料計算，例如對歷史存量的訂單或者使用者行為進行分析。實時鏈路負責對流式的資料進行快速的資料分析，例如使用者的點選流，瀏覽行為等等。

這套架構涉及到的核心元件需要 6-10 個，周邊元件多達數十個。資料的儲存產生多份冗餘，流轉鏈路中的可靠性經常無法得到保證。由此，資料工程師經常耗費大量時間檢查資料一致性。

圖-典型營銷大資料平臺技術架構

做這樣一個營銷大資料平臺，團隊配置難度更甚架構構建，往往需要兩個團隊的 20 多位專業工程師來共同建設。

團隊一負責資料基礎，如果將大資料應用類比成餐廳，這就是建房子和裝修廚房的團隊。團隊二負責資料應用，對餐廳來說，這就是做菜和上菜的團隊。

如此，團隊配置的成本必然是非常高昂。在騰訊、阿里這種頂級網際網路公司中，內部冠有“資料平臺”名字的團隊就有數個，少的團隊 10-20 人，多的團隊高達數百人。

案例 2:智慧製造資料中臺

自“中國製造 2025”提出，數字化轉型和實踐走到今天，取得了非常多成果，也帶來了很多新的挑戰。

近年來由於政策的驅動和行業認知的進步，大量的智慧製造專案開始上馬。在“中臺思想”的流行下，經常會同時上馬一個數據中臺子專案。打造智慧製造資料中臺，難度也是非常大的。

我們來看下圖中展示的一個典型的製造業企業的整體 IT 系統架構和其中需要用到的資料庫元件。

圖-製造業典型 IT 系統架構

• 在底層與生產裝置打交道的是自動控制系統，為了採集高頻的裝置資料，製造業企業往往會用到如 PI 這樣的專用實時資料庫或者 InfluxDB 這樣的時序資料庫。

• 其次是製造執行的 MES 系統，MES 系統是將人員，物料，裝置等進行有效協作和管理的系統。因此往往依賴於一個或多個關係型資料庫，一般預算較高的用 Oracle，SQL Server，預算較低的用開源的 MySQL，PostgreSQL。

• 再上層是企業的 ERP 系統，其中會涉及更多維度的資料，包括供應鏈，銷售，庫存，財務等等。而這個也依賴於強大的關係型資料庫，根據預算從 SAP Hana，Oracle 到 MySQL 都很常見。

• 最上層就是各種所謂的 BI 智慧化應用，包括各類指標報表的監控，各類產量，質量，耗能等分析應用，甚至一些機器學習預測演算法應用。

要實現一整套智慧製造的資料中臺就需要將上述多層的 IT 系統進行打通，將其中多個業務資料庫的資料匯聚上來，同時建立多條 ETL 管道將相關的資料進行整合和處理，同時選用不同的資料庫元件進行高效能或者海量分析應用。下圖是一個典型的智慧製造資料中臺架構。

圖-智慧製造資料中臺架構

建設這樣一套資料中臺實際上與之前營銷大資料的案例類似，元件繁多與資料流轉的問題同樣也存在，而且在另外幾個方面甚至會更有挑戰。

• 第一，製造業的某些應用往往有非常強的實時性要求，因為產線每停一段時間就會有很大的經濟損失，因此可能某個查詢或者分析必須在很短的時間裡出結果。

• 第二，製造業中裝置所產生的資料型別非常豐富，其中只有少量資料是結構化的，還有資料是文字，二進位制圖片等非結構化資料。

• 第三，製造業往往對 IT 預算卡的很嚴，通常無法給予比較高的伺服器採購預算，建設團隊必須在很有限的底層硬體資源中實現既定的功能。

• 第四，製造業並不具備如網際網路一樣充分的 IT 人員供給，在網際網路行業中應用相同技術和架構的技術人才獲取門檻更加難以克服。

這一切都註定了在製造業中應用大資料技術是一個挑戰度更高的課題，只有極少數頭部企業能將大資料應用到一定程度。而廣大的中小製造型企業就更加無法享受到大資料技術帶來的收益。

大資料系統的普遍痛點

通過以上兩個行業大資料應用案例，我們可以看到，當前的大資料技術架構普遍有如下 3 類痛點：

1、 昂貴

公司建設一個大資料平臺最少需要一支十人以上的有經驗的資料平臺與應用的工程師團隊。而這樣的工程師本身在行業裡都是稀缺資源，大多集中在網際網路和科技行業，傳統行業即使花大價錢也很難吸引這類團隊。

2、複雜

平均一個公司建設一個大資料平臺需要引入至少 5 個數據元件。大量元件是開源專案，並沒有完整的商業支援，企業需要自己花力氣去調研和學習這些元件。而且每種資料元件都有自己的 API 介面、語言和事務模型，都要各自安裝、監控、補丁和升級。工程師需要花大量時間維護這套架構。企業的內部人員也並非一成不變，複雜的技術棧讓平臺的執行狀態對人員變化更加敏感。

3、低效

企業建設大資料平臺的目的還是為了更好的挖掘資料價值，對業務進行賦能。過於複雜的大資料架構將導致建設週期過長，很多企業管理層開始寄希望於大資料快速能讓業務增長，但發現光搭建技術架構和梳理資料就需要半年甚至更長的時間，很快就失去耐心砍掉專案。此外，過去底層架構的複雜，讓基於大資料平臺的業務應用很難快速迭代。

這些痛點，都導致了當前的大資料技術架構是隻有少數大型企業才能“用的起，玩的轉”的“高階定製時裝”，離行業的普適依然道阻且長。

大資料技術的發展歷程

大資料技術的應用現狀如此複雜，我們不禁要追問，大資料技術是如何逐步發展至今的？以史為鑑，也許我們能找著規律與解法。

自從計算機誕生以來，就有了資料應用。最早是紙帶、卡片等物理介質，後來發展出了檔案系統，但是這些手段都無法滿足資料的增長，以及多使用者共享資料和快速檢索資料的需求。資料庫應運而生。

最早的資料庫所使用的典型資料模型主要有層次資料模型和網狀資料模型，它們可以解決一定的資料儲存和管理問題，但是在資料獨立性和和抽象級別上仍有較大的欠缺。1970 年,IBM 的研究員 Edgar F.Codd 發表了幾篇關於關係資料模型的論文，奠定了關係型資料庫的基礎。

隨著幾個經典的關係型資料庫產品 Ingres（後來演變成 Postgres）, Oracle, DB2 的誕生，關係型資料庫成為了整個資料管理行業的主流。傳統關係型資料庫始終維持了非常簡潔的架構，它劃分了業務處理和資料處理的邊界，業務邏輯由業務程式碼實現，資料處理邏輯由資料庫實現，兩者之間使用標準 SQL。

而 2000 年以來，隨著大型網際網路公司的崛起，傳統關係型資料庫的水平擴充套件能力不足，無法滿足海量資料的處理要求。為解決這個矛盾，在最初的關係型資料庫基礎上，發展出大資料技術體系以滿足高效能查詢、可擴充套件性、海量資料處理等需求。

企業在實際場景使用時，構建資料平臺要同時用到幾種技術棧的組合。比如下圖這張常見的大資料平臺架構圖。

圖-當前常見大資料平臺架構圖

面對如此複雜的系統，促使我們思考。最初的關係型資料庫系統裡僅僅通過 SQL 就隔離和解耦了資料處理和業務模組。簡潔、令人懷念。

今天，為了解決資料處理的問題，業務人員不得不直面數據處理的問題，不斷從大資料社群裡引入一個又一個開源元件，通過一些“膠水”程式碼，將它們組合起來，才能完成資料處理任務。這樣的開發體系和複雜的技術棧，對於業務開發人員要求很高，而企業需要維護這些系統所付出的各種成本也非常高。

超融合資料庫是實現大資料技術普惠的必然選擇

縱觀大資料的發展歷史，我們可以看到，之所以大資料技術只能被少數大型企業所玩轉，本質原因在於大資料技術本身的複雜性。

那破局之道在何處呢？答案還是在大資料技術本身。我們回到資料庫誕生的初衷：解決資料和業務的隔離問題，將資料處理的歸資料庫，將業務處理的歸應用。

重新把資料處理和業務處理解耦開，才能讓大資料技術變得像當年網際網路上風靡的 LAMP（Linux+Apache+MySQL+PHP）一樣簡單而普惠。

而要做到這一點，目前有三條技術路線：

第一條技術路線，在眾多大資料元件的基礎上，根據需要處理業務的特點，抽象一層通用的介面。把複雜的資料處理封裝在通用介面之下，業務人員只使用通用介面來解決業務問題。可以一定程度緩解前面提到的各種問題，但是由於底層使用的還是現在大資料體系下的元件，難以高效整合，且一旦業務發生變化，之前的抽象就可能發生變化。因此大部分專案在系統可靠性、相容性和可維護性以及資料冗餘度、一致性和實時性等方面，無法令人滿意。

第二條技術路線是在資料庫層面提供整合，即傳統的多模資料庫。通過在多種資料庫元件的上面，封裝一層，提供統一對外的 SQL 介面，讓開發者使用起來像用一個數據庫一樣，從而大幅簡化系統設計複雜度。查詢時如果需要多模查詢，就是把查詢打到幾個資料庫元件上進行聯邦查詢。這個方案風格，比較類似於分散式 OLTP 資料庫裡面的分庫分表中介軟體的方案。由於背後的多個數據庫元件在日誌、事務、一致性和高可用等實現方式並不相同，導致這種強行“縫合”的多模資料庫並不好用。

第三條技術路線是提供融合型資料庫產品。業內在這個方向上已經取得了一些進展，許多產品已經出現了能力互相融合的情況。2014 年，Gartner 提出了 HTAP 的概念，以 Greenplum，TiDB 和 Oceanbase 為代表的資料庫系統都具備 HTAP 能力:同時支援交易和分析型操作的支援，在確保事務能力的同時提供實時的資料分析能力。2021 年的 DTCC 大會上，更有國內的資料庫廠商提出了超融合時序資料庫的概念:融合了傳統的關係型資料庫、時序資料庫和分析型資料庫為一體。由此可見，資料庫產品不斷走向融合的歷史趨勢已經形成。

也正是在第三條技術路線的指引下，成立於 2021 年的矩陣起源公司致力於打造 MatrixOne 超融合異構雲原生資料庫，為開發者、商業和組織打造極簡的大資料建設工具。在思考了當前大資料體系的問題和未來資料處理技術的發展趨勢之後，我們認為新一代的超融合資料庫應該具備以下的能力:

• 使用者互動方式上，能夠支援標準的 SQL 操作

• 支援業務場景上，能夠支援 TP、AP，也就是 HTAP 的能力

• 處理負載方式上，要能夠同時支援流和批量兩種計算，也就是流批一體的能力

• 支援資料型別上，要能夠支援時序資料、時空資料和機器學習特徵資料等多種負載，也就是多模的能力

• 除去確保高可用的資料副本，儘量避免在系統內引入冗餘

• 可提供強一致的分散式事務;可根據業務規模，提供線上水平擴充套件支援海量資料儲存

• 存算分離，儲存節點、計算節點、元資料節點甚至排程節點全部解耦，都可以獨立擴縮容

• 一套方案支援在公有云和私有化部署，公有云部署是雲原生架構，支援雲上的廉價共享儲存和容器編排，且能做到公有云部署和私有化部署互聯互通，真正做到雲邊協同，甚至雲邊一體。

如果用一句話來描述其能力的話，可以這樣總結:流批一體，TP / AP 一體，雲邊一體。那麼，有這樣能力的超融合資料庫系統，給我們帶來的是什麼?

• 使用者無需為了解決海量資料分析，搭建如此複雜的一套大資料平臺，從而極大簡化了系統複雜度

• 單一系統，更加穩定，運維更加容易，技術人員的學習成本更低，使用者體驗更好

• 避免冗餘儲存，冗餘傳輸，冗餘處理，降低硬體投入成本

• 融合多功能資料庫引擎，兼顧效能與功能

而之前給出的複雜大資料平臺架構，就可以簡化為:

圖-理想的資料平臺架構圖

資料庫與大資料技術已經發展數十年，在技術上已經枝繁葉茂，但是隨著資料規模的增大，使用者處理資料的難度也越來越大。

我們相信超融合資料庫的出現，將能有效的解決當前的這一矛盾。16 年前資料庫領域的圖靈獎獲得者 Michael Stonebraker 提出了一套資料庫系統無法適用所有資料處理場景的論斷，也就是"One size doesn't fit all"。但是，在那篇文章的最後，Stonebraker 展望了未來資料庫系統架構的幾個演進方向，其中最後一個也是我們認同的方向:從頭開始設計和實現一個可以適合多種場景的資料庫系統。16 年後的今天，我們認為新一代超融合資料庫可以做到 "One size doesn't fit all, but most"。

未來企業應用超融合資料庫建設大資料平臺會像使用關係型資料庫一樣簡單，超融合資料庫也是真正實現大資料技術普惠的必然選擇。