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

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

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

　　近十年來,，我國在數(shù)據(jù)庫領域真正做到了厚積薄發(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技術的基石,，不僅支撐了新一代分布式架構體系,，而且實現(xiàn)了海量數(shù)據(jù)高效存儲和快速計算。2012年,，Google發(fā)表了一篇論文——Spanner: Google's Globally-Distributed Database,，將同時支持大數(shù)據(jù)量下做事務交易的數(shù)據(jù)庫提取出來，既支持TP的操作,，也可以在上面作一些分析類的操作,。在Google提出Spanner架構的基礎上，2014年,，Gartner對HTAP進行了正式定義,，這便是混布式數(shù)據(jù)庫的產生緣起。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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