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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　行列混存—混合負(fù)載的正確打開方式

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

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

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

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

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

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