直到21世紀初，我國數(shù)據(jù)庫產(chǎn)業(yè)發(fā)展還比較緩慢，基本處在西方數(shù)據(jù)庫博覽會的狀態(tài)，很少有拿得出手的國產(chǎn)數(shù)據(jù)庫產(chǎn)品。1989年，Oracle決定進軍中國，恰好趕上中國電信建設(shè)“九七工程”的風口，在順利拿下東北三省郵電管理局的大單之后，Oracle在中國市場站穩(wěn)了腳跟。后來Sybase于1991年進入大陸，IBM隨后也帶著Db2、Informix等數(shù)據(jù)庫產(chǎn)品大舉入華。在這之后的十幾年時間里，中國數(shù)據(jù)庫市場格局逐漸成形，金融行業(yè)中以Db2、Sybase為主，電信、電力行業(yè)中則基本由Oracle一統(tǒng)江湖。

　　然而，風云起，時代變，一切局勢都在潛移默化中開始扭轉(zhuǎn)。以十年前的開心農(nóng)場偷菜場景為例，隨著C端客戶爆炸式增長，中國IT人瞬間意識到，傳統(tǒng)西方的IOE（IBM小型機、Orcale數(shù)據(jù)庫、EMC存儲）技術(shù)架構(gòu)根本無法支持如此海量的并發(fā)，而由IOE帶來的高昂IT支出也令人瞠目結(jié)舌。正是在這樣的大背景下，核心技術(shù)的自主掌控成了業(yè)界共識，打造自己的數(shù)據(jù)庫成了中國程序員們的夢想。

　　雷濤對HTAP數(shù)據(jù)庫的深入解讀

　　近十年來，我國在數(shù)據(jù)庫領(lǐng)域真正做到了厚積薄發(fā)。從單節(jié)點到分布式，從單一用途的TP、AP庫到混合式HTAP，從獨立的數(shù)據(jù)倉庫、數(shù)據(jù)湖到湖倉一體，從SQL、NoSQL再到NewSQL……可以說，數(shù)據(jù)庫的各方面都迎來了突破性進展。

　　下面，本文就HTAP數(shù)據(jù)庫進行深入解讀。

　　Google File System、Google BigTable、Google MapReduce——這三駕馬車是現(xiàn)在大數(shù)據(jù)平臺Hadoop技術(shù)的基石，不僅支撐了新一代分布式架構(gòu)體系，而且實現(xiàn)了海量數(shù)據(jù)高效存儲和快速計算。2012年，Google發(fā)表了一篇論文——Spanner: Google's Globally-Distributed Database，將同時支持大數(shù)據(jù)量下做事務(wù)交易的數(shù)據(jù)庫提取出來，既支持TP的操作，也可以在上面作一些分析類的操作。在Google提出Spanner架構(gòu)的基礎(chǔ)上，2014年，Gartner對HTAP進行了正式定義，這便是混布式數(shù)據(jù)庫的產(chǎn)生緣起。

　　目前，數(shù)據(jù)庫基本分為兩大流派，一個是非關(guān)系型（NoSQL）數(shù)據(jù)庫，一般使用KV技術(shù)，主要用于用戶畫像、業(yè)務(wù)報表等海量數(shù)據(jù)挖掘的AP場景。另一個是關(guān)系型數(shù)據(jù)庫（SQL），針對個別記錄增、刪、改、查的速度很快，一般用于聯(lián)機交易的TP場景。簡而言之，TP庫處理速度快，AP庫處理數(shù)據(jù)量級高。

　　之前，AP與TP的應(yīng)用場景井水不犯河水，相互之間沒有太多交集，然而隨著數(shù)字化轉(zhuǎn)型的不斷深入，直播帶貨這樣的新場景不斷涌現(xiàn)，在直播過程中既需要處理聯(lián)機交易，又需要對客戶進行實時畫像，而傳統(tǒng)單一TP或者AP數(shù)據(jù)庫難以應(yīng)對這樣的混合式場景。近幾年來，某些國產(chǎn)混合負載數(shù)據(jù)庫以行列混存方式，打破了AP與TP兩種場景之間的鴻溝。

　　數(shù)據(jù)的神奇旅行

　　在梳理數(shù)據(jù)存儲模型演進歷史后，明顯可以發(fā)現(xiàn)這是一個隨著數(shù)據(jù)量級不斷擴大，數(shù)據(jù)模型在不斷變換的過程。

　　目前我們提到的數(shù)據(jù)庫一般都是指關(guān)系型數(shù)據(jù)庫，從關(guān)系型的視角來看，數(shù)據(jù)庫被定義為工廠的車間，數(shù)據(jù)則是原材料。車間為了進行原材料加工，部署大量的操作設(shè)備，原材料也會隨時被重塑修改，從建模原理上可以看出TP數(shù)據(jù)庫的數(shù)據(jù)加工車間適合快速零件加工，但不適合進行大量材料的儲存。

　　而關(guān)系型TP數(shù)據(jù)庫在大量數(shù)據(jù)存儲方面的短板直接催生了Hadoop等大數(shù)據(jù)技術(shù)的革命。從大數(shù)據(jù)視角看，AP數(shù)據(jù)庫自身就是儲存?zhèn)}庫，而數(shù)據(jù)已經(jīng)是加工完成的成品，沒有被重塑、修改等的更新需求。比如在Hadoop技術(shù)棧中的HDFS存儲實現(xiàn)，就是所有數(shù)據(jù)只能寫入一次，無法修改，這其實是犧牲數(shù)據(jù)的寫入和更新特性，以換取海量數(shù)據(jù)的儲存與查詢性能的做法。

　　而隨著大數(shù)據(jù)應(yīng)用的進一步拓展，業(yè)界發(fā)現(xiàn)價值密度更低的非結(jié)構(gòu)化數(shù)據(jù)也有儲存及挖掘的必要。比如客服的對話方式可能是語音、文字甚至是圖像、視頻，這都不是傳統(tǒng)意義上數(shù)據(jù)庫、數(shù)據(jù)倉庫可以處理的結(jié)構(gòu)化數(shù)據(jù)，因此用于儲存非結(jié)構(gòu)化的數(shù)據(jù)湖出現(xiàn)了，在數(shù)據(jù)湖中數(shù)據(jù)標準化、結(jié)構(gòu)化的特性也退化了。從關(guān)系型數(shù)據(jù)庫到數(shù)據(jù)湖，各種大數(shù)據(jù)技術(shù)棧相互獨立，但隨著移動互聯(lián)網(wǎng)時代的到來，這種情況發(fā)生了改變。

　　聯(lián)機性能和實時分析真的是“魚與熊掌不可兼得”嗎？

　　權(quán)威咨詢公司IDC對于大數(shù)據(jù)的定義是：滿足種類多（Variety）、流量大（Velocity）、容量大（Volume）、價值高（Value）等指標的數(shù)據(jù)稱為大數(shù)據(jù)。從歷史來看，在谷歌提出大數(shù)據(jù)三駕馬車的論文時，當時的關(guān)系型數(shù)據(jù)庫技術(shù)就難以處理大規(guī)模的數(shù)據(jù)。而在當下各行各業(yè)不斷上云的大背景下，數(shù)據(jù)的量級必然還將不斷創(chuàng)新高。從我了解到的情況，整個IT行業(yè)存儲的數(shù)據(jù)量級正在以年化80%左右的速度增長，傳統(tǒng)SQL數(shù)據(jù)庫難以處理這樣的數(shù)據(jù)量。

　　很多用戶在實際工作中也會把大表關(guān)聯(lián)的查詢?nèi)蝿?wù)放在傳統(tǒng)TP數(shù)據(jù)庫上進行，這樣的查詢雖然效率很低，但考慮到從TP數(shù)據(jù)庫導入AP數(shù)據(jù)倉庫所需要的超長時間，直接在TP數(shù)據(jù)庫上跑查詢可以理解。其實，這個例子也深刻說明了目前大數(shù)據(jù)技術(shù)棧面臨的窘境，各個TP與AP數(shù)據(jù)庫像是一座座數(shù)據(jù)孤島，打破孤島之間的邊界簡直比登天還難。正如前文所說，SQL與NoSQL兩種產(chǎn)品底層構(gòu)建模型并不相同，彼此兼容性不佳。想保證聯(lián)機交易處理時效，就要犧牲數(shù)據(jù)分析的性能，而想要實時數(shù)據(jù)分析，快速完成用戶畫像就不能再依靠原有技術(shù)棧。

　　處理時效與實時用戶畫像的平衡可能是數(shù)據(jù)庫工程師與產(chǎn)品經(jīng)理之間永遠無法達成的協(xié)議。目前大多商業(yè)銀行都使用以O(shè)racle為代表的TP數(shù)據(jù)庫作為核心系統(tǒng)，但Oracle只能處理流程性的交易數(shù)據(jù)，不能做數(shù)據(jù)挖掘。要想把數(shù)據(jù)價值做二次表達，就需要每天做ETL，跑批作業(yè)，存到數(shù)據(jù)倉庫中。然后在數(shù)據(jù)倉庫中建模、挖掘、數(shù)據(jù)集市、ODS，一層一層地構(gòu)建起數(shù)據(jù)倉庫報表。

　　如果還是回答不出更細節(jié)、隱含的問題，比如非線性問題，還要把數(shù)據(jù)復(fù)制到SAS中做機器學習，再做統(tǒng)計的指標體系，去進一步挖掘。數(shù)據(jù)要在這里搬動三次，復(fù)制三份冗余，還要管理數(shù)據(jù)一致性，每天數(shù)據(jù)中心運維的大量工作都在做數(shù)據(jù)遷移。而數(shù)據(jù)在這種低效的轉(zhuǎn)運遷移過程中，很多價值就白白消耗了，且正如前文所說，TP與AP兩套體系的組件兼容性很差，能讓兩大體系協(xié)同工作已屬不易，如果再考慮災(zāi)備高可用方面的需求，則是難上加難。

　　行列混存—混合負載的正確打開方式

　　目前，各行業(yè)數(shù)據(jù)中心都迫切尋找一棧式解決方案，通過屏蔽大數(shù)據(jù)技術(shù)底層組件的差別，尋找“All Data In One”的解決方案，只有如此才能降本增效。

　　TP與AP的巨大差異，在于行存與列存在不同使用場景下的效能表現(xiàn)。在計算機世界中，數(shù)據(jù)吞吐速率往往受數(shù)據(jù)訪問局部性原理支配。我們知道，現(xiàn)代硬盤、內(nèi)存工作原理是當用戶讀某一區(qū)域的數(shù)據(jù)時，其鄰接的數(shù)據(jù)也會被調(diào)入上一級高速緩存，讀1KB數(shù)據(jù)和連續(xù)的64MB數(shù)據(jù)的代價基本相同，用戶在讀取連續(xù)的磁盤或者內(nèi)存信息時，其速度往往比隨機讀取快一個數(shù)量級。因此，行存儲大多用在SQL的TP場景，而列存儲基本用在NoSQL的AP場景。

　　這背后的原因也很簡單，還是以銀行業(yè)作為案例，在聯(lián)機交易的TP場景下，比如當客戶取款時，會校驗用戶、賬號、密碼、余額等信息，這些信息都是以“行”為單位存儲的，聯(lián)機交易中的數(shù)據(jù)經(jīng)常是以“行”為單位訪問的，把數(shù)據(jù)放在一行就會有訪問速度的優(yōu)勢。但在統(tǒng)計、分析營業(yè)報表，進行數(shù)據(jù)挖掘等AP場景下，往往只需要關(guān)注交易金額、賬戶余額等少量維度的信息，而不需要用戶、賬號、密碼等數(shù)據(jù)，在這種場景下，將同一維度信息放在一起的列存儲方案就有很大的速度優(yōu)勢了。

　　將行、列進行混存，綜合兩者的優(yōu)勢，這方面業(yè)界也有不少嘗試，但往往都不是很成功，最大的問題還是在于性能。對于聯(lián)機TP交易場景來說，列式存儲的寫入性能太低了。所以一般來說，傳統(tǒng)的方案往往還是退化成為行式存儲TP數(shù)據(jù)庫，在交易量少的日終結(jié)算時刻，將數(shù)據(jù)吐給列式存儲AP數(shù)據(jù)庫進行數(shù)據(jù)挖掘。

　　如圖1所示，邏輯上，業(yè)務(wù)場景主要分為兩類：聯(lián)機交易OLTP和數(shù)據(jù)分析OLAP。HTAP數(shù)據(jù)庫不僅支持使用SQL進行傳統(tǒng)的關(guān)系模型計算，更是將圖計算和AI建模納入了邏輯計劃中，可進行高階計算。在數(shù)據(jù)存儲層，通過行列混合的方式，按需支持OLAP和OLTP場景，這樣就做到了一種存儲架構(gòu)兼容所有場景。

　　這種邏輯計劃及存儲融合，也稱“All Data In One”，是對數(shù)據(jù)庫基礎(chǔ)底座的重新定義。在資源調(diào)度層，通過AI-Native的方式探查出需要使用的調(diào)度引擎，并在實際計算時，做好資源隔離。這種架構(gòu)可以更有效地支撐數(shù)據(jù)計算，最終實現(xiàn)一個數(shù)據(jù)庫融合所有場景的終極目標。相信未來的國產(chǎn)HTAP數(shù)據(jù)庫，還將繼續(xù)朝著“All Data In One”的道路前進，發(fā)展特色不斷創(chuàng)新，降低系統(tǒng)運維成本，發(fā)揮數(shù)據(jù)的最大價值。