“胖數據庫，瘦中臺”：超融合數據庫讓工程師做更有意義的事

　　超融合數據庫將交易型數據庫（OLTP）、分析型數據庫（OLAP）和大數據/數據湖能力融為一體，并以一種全新的視角展現。如今，包括Teradata、Greenplum、Snowflake在內的主流OLAP數據庫都支持事務（ACID），故本文稱OLTP為交易型數據庫而非事務型數據庫。

　　過去十幾年，分布式技術和數據庫技術都有長足發展，很多產品都在自身原有優勢基礎之上不同程度的探索能力延伸的邊界，并取得了良好的進展。在這種大趨勢之下，超融合數據庫出現。超融合數據庫博采OLTP數據庫、OLAP數據庫和大數據/數據湖眾家之長集于一身，形成一種新的技術形態。

　　而這，或許正改變著相關人士對數據、產品、算法、存儲之間關系的看法。

　　數據平臺

　　一場大數據時代的進化史

　　數據平臺的目的是服務，而最直接的使用者是業務開發人員，開發人員開發出通用的業務系統（譬如CRM、ERP、BI、報表和可視化系統）或者專用的業務系統（譬如某電商的推薦系統、某銀行的客戶畫像系統）供業務人員或用戶使用。數據平臺最根本的設計目標是支撐業務、提高開發運維效率。

　　自上世紀七八十年代以來，關系數據庫一直是數據處理平臺的核心。關系數據庫很好的劃分了業務處理和數據處理的邊界：業務邏輯由業務代碼實現，數據處理邏輯由數據庫實現，兩者之間使用標準SQL進行對話。SQL標準不斷迭代，從早期的SQL-1992標準到SQL-1999、SQL-2003、SQL-2008、SQL-2011、SQL-2013、SQL-2016、SQL-2019，SQL標準文檔逐漸變成了大部頭，應用中常用的數據處理邏輯不斷的被加入到SQL標準中去，SQL從一種關系語言演進成了數據處理語言（transformation language）。關系數據庫解決了數據處理的復雜度問題，開發人員專注在業務邏輯上，效率高、迭代快。

　　2000年后互聯網蓬勃發展，也為數據處理帶來新的挑戰，傳統的單節點關系數據庫無法滿足業務快速發展的需要。起初大型互聯網公司例如Google、eBay采用MySQL集群或者Oracle集群來滿足快速發展的業務；后來發現這種模式僅僅把MySQL、Oracle當做數據存儲使用，而不需要關系數據庫的很多特性，基于此洞察出現了一批NoSQL數據庫，分別從不同的角度解決某種大數據問題，使開發人員可以應對業務的快速發展，典型的產品有HDFS、Hive、HBase、MongoDB、ElasticSearch等。NoSQL數據庫承擔了數據處理的部分復雜度，特別是性能方面，同時也把數據處理的部分復雜度留給了開發運維人員。開發人員把這些數據庫當做存儲用，簡單的增刪改查（CRUD）由NoSQL數據庫實現，復雜點的數據處理邏輯需要由應用代碼實現，應用開發效率低。此外產品眾多、組合眾多，運維復雜。

　　隨著業務發展，大量相似的數據處理邏輯和模式在各種應用內反復出現。為了解決這樣的問題，很多團隊開始抽取相似的數據處理邏輯封裝起來供應用開發人員調用。這也是數據中臺的雛形。數據中臺旨在把復雜度封裝起來，把NoSQL留給開發人員的復雜度收回來，讓開發人員專注在業務上，提升開發效率。發展到今天，大多數數據中臺封裝各類軟件以滿足不同應用需求，撥開其層層封裝，核心以開源軟件為主。這個時期數據中臺比較胖，集成諸多產品實現各種各樣的數據處理，包括存儲、批處理、流式數據處理、OLTP查詢、OLAP查詢、ML、數據治理等。數據中臺一定程度上回收復雜度，提升開發人員的效率，然而由于數據中臺缺乏強大的查詢優化和執行引擎，故而很多可以使用現代SQL實現的能力需要用代碼實現，這一定程度制約了開發人員的效率。此外運維的復雜度沒有降低反而隨著集成的產品增加而增加。

　　當前數據架構痛點

　　復雜、昂貴、可變性低

　　現在數據中心部署的數據產品大體可分為四大類：

　　01

　　交易型數據庫（OLTP）

　　支撐在線交易業務，典型查詢涉及數據行比較少，數據頻繁增刪改查，數據庫追求高并發、低延遲。典型的產品有Oracle、DB2、SQLServer、PostgreSQL、MySQL 等。

　　02

　　分析型數據庫（OLAP）

　　支撐在線分析業務，典型查詢涉及大量數據行，數據以插入和查詢為主，數據清洗后一般不更新或者偶爾更新，數據庫追求復雜查詢的性能。典型的產品有 Teradata、Greenplum、Snowflake等。這類產品也稱為數據倉庫。

　　03

　　專用數據庫

　　支撐某種特定數據處理業務場景，典型產品有時序數據庫、圖數據庫、GIS數據庫、文本檢索產品等。

　　04

　　大數據/數據湖（Data Lake）

　　大數據從2005年左右發展起來，起初主要產品是Hadoop，后來發展成為包含眾多產品的技術棧。近幾年有人提出“數據湖”來描述一種技術和數據處理理念。數據湖的核心理念是“schema on read”，即數據先寫入數據湖，然后通過數據治理使之成為可分析的數據。大數據/數據湖相關的典型的產品有HDFS、Hive、Impala、Tez、Kudu、Presto、Drill、Flink、Spark等。

　　而這也由此衍生出另一個問題——這四大類產品之間需要頻繁的數據搬運，整個技術棧非常復雜。如下圖所示。

　　這種數據架構有諸多問題：

　　01

　　復雜低效

　　產品眾多，且運算環境非常復雜，分布式產品則更甚之，整合在一起復雜度進一步疊加；

　　組合多，數據穿行在不同產品組合間，處理邏輯復雜、易出錯；

　　產品運維挑戰大，易出錯，效率低；

　　開發人員學習曲線陡峭且變化快。

　　02

　　昂貴

　　運維支出極高：開源軟件產品本身雖不用投入，但是開源軟件普遍缺少足夠企業級特性或者企業級特性不開源，運維成本極高。據《Business Intelligence Journal》數據，對系統運維的投入超過其對總系統投入的50%；

　　開發運維人員薪資成本極高：復雜軟件的運維人員普遍稀缺，因而薪資高舉；

　　學習成本極高：用好一套分布式系統就有挑戰，何況試圖駕馭眾多分布式產品；這需要運維人員不斷學習相關知識，以應對數據庫的復雜及多變性；

　　存儲代價極高：同一份數據在不同系統間存儲，副本達8個以上，如果考慮每個系統的備份，副本則高達十幾份，這并不利于數據優化及使用效率。

　　03

　　阻礙業務快速迭代和創新

　　復雜低效的技術架構消耗開發人員大量的時間進行數據處理而不能集中精力于業務之上；

　　復雜的技術棧對人員技能要求高，形成人才匱乏的局面，應用開發和業務人員無法實現快速迭代，對業務創新形成制約。

　　04

　　用戶體驗差

　　用戶、運維人員、開發人員甚至供應商無法駕馭復雜的技術棧，造成用戶使用過程中性能差、故障率高、故障修復時間長等問題。

　　未來數據架構

　　精簡、融合、靈活度高

　　古人云“分久必合，合久必分”，數據處理架構演進亦是如此。事實上，關系數據庫從上世紀70年代就開始出現，十余年后則開始向商業化之路進行探索并取得成功，之后20多年，關系數據庫是商業數據處理應用的核心，也是“one size fits all”的時代。

　　2005年左右，互聯網蓬勃發展，出現了一批新數據應用，其典型特點是數據量大（Volume）、數據類型多樣化（Variety）、數據產生速度快（Velocity），關系數據庫沒能快速適應互聯網應用對數據處理的新訴求，于是出現了一批新產品，每個產品試圖解決一兩個特定的問題，譬如HDFS解決高可用廉價存儲問題，MapReduce解決批處理并行計算問題，HBase解決寬列數據高效讀寫問題，MongoDB通過文檔模型解決靈活性和讀寫效率問題，ElasticSearch解決文本檢索問題，InfluxDB解決時序數據處理問題，Flink解決流數據處理問題。人們統稱這一類產品為“NoSQL”，是“one size does not fit all”的時代。大數據架構師和開發人員根據需求把這些產品組合在一起來解決業務問題。由于產品眾多，把這些產品整合在一起挑戰大，故而出現了“數據中臺”廠商提供這種整合的數據平臺服務。數據中臺封裝各種各樣的數據產品，為用戶提供通用的、統一的數據存儲和處理能力。數據中臺通常會打包很多開源軟件，是典型的“胖中臺”。

　　與此同時，NoSQL也經歷了“Non-SQL”、“Not Only SQL”、“No, SQL”等不同的解讀，這個詞逐漸淡出大眾視野，因為大多數NoSQL產品要么沒有跟上時代步伐，要么開始支持經典SQL特性，譬如SQL標準、ACID等。之前僅僅解決一兩個特定問題的產品開始提供越來越多的能力，產品之間的界限越來越模糊，譬如Kafka提供了KSQL，ElasticSearch也支持SQL，Spark提供了DeltaLake，MongoDB開始支持Schema Validation和分布式事務，Greenplum支持OLTP業務、JSON半結構化數據和庫內機器學習（In-database machine learning），PipelineDB在關系數據庫內支持流數據處理，MatrixDB在關系數據庫中支持時序數據和GIS數據，ElasticSearch支持機器學習等。各種數據產品越發龐雜，新產品形態呼之欲出。

　　超融合數據庫在這種形勢下應運而生。它博采OLTP數據庫、OLAP數據庫和大數據/數據湖眾家之長集于一身，形成一種新的技術形態。

　　超融合架構的核心是靈活和強大的模塊化與插件化。通過模塊化和插件化，超融合數據庫可以支持不同的場景，譬如可插拔存儲器可以使用行存引擎支持OLTP、使用列存引擎支持OLAP、使用LSM存儲引擎支持時序數據場景，通過多態存儲架構可以同時支持存算一體和存儲計算分離，通過自定義類型、自定義函數和自定義聚集支持庫內機器學習（in-database machine learning）等。

　　超融合數據庫是技術發展的自然走向。2011年，451Research提出的NewSQL為OLTP和大數據的融合 ；2015年，Gartner提出的HTAP為OLTP和OLAP的融合；2020年，Databricks提出的Lakehouse為數據倉庫和數據湖的融合；數據庫發展逐漸從兩兩融合走向超融合；而預計不遠的2022年，超融合數據庫技術將實現產品化和商業化。

　　超融合數據庫通過融合多種技術于一體，可以很好的解決上面提到的四類問題：

　　01

　　架構簡潔

　　大大簡化技術棧，降低系統復雜度，降低運維復雜度，提升開發效率，讓開發人員專注在業務邏輯上，把數據處理工作的主體交給數據庫，實現數據處理和業務邏輯的松散耦合。

　　02

　　性價比高

　　無需采購和運維眾多產品，大幅降低產品開銷和運維開銷，避免數據過量冗余存儲。

　　03

　　業務迭代和創新

　　精簡的技術棧使得應用開發人員集中精力在業務邏輯上而不是數據處理上，業務迭代更快，為業務創新賦能。

　　04

　　提升用戶體驗

　　精簡的技術棧易于駕馭，故障率低，最終用戶體驗好。

　　超融合是一種技術架構，也是一種理念或者說數據處理范式。對于絕大多數客戶，數據量為百TB級別，完全可以使用一套數據庫集群來處理 OLTP、OLAP和大數據分析業務。這種架構開發省力、運維省心、老板省錢，下圖一目了然的展示了超融合數據庫架構的優勢。

　　如果數據量很大，譬如10PB級別，一套數據庫集群來處理全部業務是不現實的，此時可以使用多套超融合數據庫來實現，不同的數據庫集群偏向處理某種業務或者某類業務，集群之間可以高效互聯互通。

　　目前，超融合數據庫不會替代專注優化極端場景的的數據庫，例如雙11、春晚微信紅包等數據處理需求系統。但隨著超融合數據庫的成熟與更新，絕大多數數據處理場景可以以超融合數據庫為核心，實現數據處理，“胖數據庫、瘦中臺”時代到來了。

　　超融合數據庫

　　解放開發和運維人員的數據處理

　　本文提到的“胖”、“瘦”比喻如何在整個系統內劃分功能邊界，不帶有褒貶色彩；其次胖與瘦是相對的。胖與瘦的本質是復雜度切分，是把什么樣的復雜度留給誰，或者說誰選擇解決什么樣的復雜度。

　　在“one size fits all”時代，數據處理的復雜度由關系數據庫承擔，開發效率高，運維簡單；在大數據時代，數據處理的復雜度分散在數據庫和應用中，應用開發效率變低，運維變復雜；數據中臺（或者數據處理平臺）出現后試圖把分散在應用中的復雜度收回來由數據中臺承擔，但是目前還沒有出現很好解決這一問題的產品和解決方案。

　　超融合數據庫的出現，把數據處理平臺體系內需要整合多個產品才能解決的問題集成到一個產品內，最大合理限度的把復雜度留給數據庫，解放開發和運維人員。過去五十多年，數據庫經歷了層狀數據庫、網狀數據庫、關系數據庫、對象數據庫、XML數據庫、KV數據庫、文檔數據庫、列族數據庫、時序數據庫、圖數據庫、內存數據庫、并行數據庫和分布式數據庫等不同技術和產品的洗禮，很多優秀技術沉淀下來。發展到今天，模塊化、可插拔的數據庫基礎技術已經比較成熟，在這樣的技術能力之上，通過插拔存儲器、執行器、優化器等方法在超融合數據庫中支持不同的數據類型，包括結構化數據、時序數據、GIS數據、JSON數據、Text等，支持不同的業務場景，包括交易業務、分析業務和流數據處理業務，把數據處理邏輯再次打包到數據庫中，通過現代SQL與應用進行對話，讓開發運維人員聚焦到業務邏輯而不是數據處理邏輯上，這顯然是數據時代的又一次變革性跨越，讓開發運維省心省力。

　　01

　　開發省力

　　超融合數據庫替代多個不同的數據庫，并提供現代SQL能力，開發人員不需要從不同數據庫中讀取數據到內存再進行計算合并聚集關聯等，而是直接使用現代SQL能力進行數據處理，一條SQL語句抵數千行代碼，大大提升效率，降低錯誤率。

　　02

　　運維省心

　　運維管理一套數據庫而不是多套數據庫，無需在不同數據庫之間搬運數據，安裝配置、監控告警、安全保護、備份恢復、擴容、升級等工作量大幅降低。

　　復雜度最大合理限度留給數據庫而解放開發和運維人員，數據庫邊界不斷拓展，逐漸變“胖”，超融合數據庫到來！

　　關 于 我 們

　　yMatrix是全球超融合時序數據庫開創者，專為物聯網、車聯網、工業互聯網和智慧城市提供一站式數據平臺。

　　MatrixDB為首款PB級超融合時空數據庫，基于自主研發的多項專利技術，MatrixDB可以同時完美支持傳統的關系型數據和物聯網海量時空數據的快速采集、高效存儲、實時分析以及深度學習（ML+AI），開創了現代實時數據倉庫方向，為萬物互聯的智能時代提供堅實、簡潔的智能數據核心基礎設施。MatrixDB為公司自主研發的國產數據庫，公司擁有該產品的全部知識產權。