直到21世紀初，我國數據庫產業發展還比較緩慢，基本處在西方數據庫博覽會的狀態，很少有拿得出手的國產數據庫產品。1989年，Oracle決定進軍中國，恰好趕上中國電信建設“九七工程”的風口，在順利拿下東北三省郵電管理局的大單之后，Oracle在中國市場站穩了腳跟。后來Sybase于1991年進入大陸，IBM隨后也帶著Db2、Informix等數據庫產品大舉入華。在這之后的十幾年時間里，中國數據庫市場格局逐漸成形，金融行業中以Db2、Sybase為主，電信、電力行業中則基本由Oracle一統江湖。
然而，風云起，時代變，一切局勢都在潛移默化中開始扭轉。以十年前的開心農場偷菜場景為例，隨著C端客戶爆炸式增長，中國IT人瞬間意識到，傳統西方的IOE（IBM小型機、Orcale數據庫、EMC存儲）技術架構根本無法支持如此海量的并發，而由IOE帶來的高昂IT支出也令人瞠目結舌。正是在這樣的大背景下，核心技術的自主掌控成了業界共識，打造自己的數據庫成了中國程序員們的夢想。
雷濤對HTAP數據庫的深入解讀
近十年來，我國在數據庫領域真正做到了厚積薄發。從單節點到分布式，從單一用途的TP、AP庫到混合式HTAP，從獨立的數據倉庫、數據湖到湖倉一體，從SQL、NoSQL再到NewSQL……可以說，數據庫的各方面都迎來了突破性進展。
下面，本文就HTAP數據庫進行深入解讀。
Google File System、Google BigTable、Google MapReduce——這三駕馬車是現在大數據平臺Hadoop技術的基石，不僅支撐了新一代分布式架構體系，而且實現了海量數據高效存儲和快速計算。2012年，Google發表了一篇論文——Spanner: Google's Globally-Distributed Database，將同時支持大數據量下做事務交易的數據庫提取出來，既支持TP的操作，也可以在上面作一些分析類的操作。在Google提出Spanner架構的基礎上，2014年，Gartner對HTAP進行了正式定義，這便是混布式數據庫的產生緣起。
目前，數據庫基本分為兩大流派，一個是非關系型（NoSQL）數據庫，一般使用KV技術，主要用于用戶畫像、業務報表等海量數據挖掘的AP場景。另一個是關系型數據庫（SQL），針對個別記錄增、刪、改、查的速度很快，一般用于聯機交易的TP場景。簡而言之，TP庫處理速度快，AP庫處理數據量級高。
之前，AP與TP的應用場景井水不犯河水，相互之間沒有太多交集，然而隨著數字化轉型的不斷深入，直播帶貨這樣的新場景不斷涌現，在直播過程中既需要處理聯機交易，又需要對客戶進行實時畫像，而傳統單一TP或者AP數據庫難以應對這樣的混合式場景。近幾年來，某些國產混合負載數據庫以行列混存方式，打破了AP與TP兩種場景之間的鴻溝。
數據的神奇旅行
在梳理數據存儲模型演進歷史后，明顯可以發現這是一個隨著數據量級不斷擴大，數據模型在不斷變換的過程。
目前我們提到的數據庫一般都是指關系型數據庫，從關系型的視角來看，數據庫被定義為工廠的車間，數據則是原材料。車間為了進行原材料加工，部署大量的操作設備，原材料也會隨時被重塑修改，從建模原理上可以看出TP數據庫的數據加工車間適合快速零件加工，但不適合進行大量材料的儲存。
而關系型TP數據庫在大量數據存儲方面的短板直接催生了Hadoop等大數據技術的革命。從大數據視角看，AP數據庫自身就是儲存倉庫，而數據已經是加工完成的成品，沒有被重塑、修改等的更新需求。比如在Hadoop技術棧中的HDFS存儲實現，就是所有數據只能寫入一次，無法修改，這其實是犧牲數據的寫入和更新特性，以換取海量數據的儲存與查詢性能的做法。
而隨著大數據應用的進一步拓展，業界發現價值密度更低的非結構化數據也有儲存及挖掘的必要。比如客服的對話方式可能是語音、文字甚至是圖像、視頻，這都不是傳統意義上數據庫、數據倉庫可以處理的結構化數據，因此用于儲存非結構化的數據湖出現了，在數據湖中數據標準化、結構化的特性也退化了。從關系型數據庫到數據湖，各種大數據技術棧相互獨立，但隨著移動互聯網時代的到來，這種情況發生了改變。
聯機性能和實時分析真的是“魚與熊掌不可兼得”嗎？
權威咨詢公司IDC對于大數據的定義是：滿足種類多（Variety）、流量大（Velocity）、容量大（Volume）、價值高（Value）等指標的數據稱為大數據。從歷史來看，在谷歌提出大數據三駕馬車的論文時，當時的關系型數據庫技術就難以處理大規模的數據。而在當下各行各業不斷上云的大背景下，數據的量級必然還將不斷創新高。從我了解到的情況，整個IT行業存儲的數據量級正在以年化80%左右的速度增長，傳統SQL數據庫難以處理這樣的數據量。
很多用戶在實際工作中也會把大表關聯的查詢任務放在傳統TP數據庫上進行，這樣的查詢雖然效率很低，但考慮到從TP數據庫導入AP數據倉庫所需要的超長時間，直接在TP數據庫上跑查詢可以理解。其實，這個例子也深刻說明了目前大數據技術棧面臨的窘境，各個TP與AP數據庫像是一座座數據孤島，打破孤島之間的邊界簡直比登天還難。正如前文所說，SQL與NoSQL兩種產品底層構建模型并不相同，彼此兼容性不佳。想保證聯機交易處理時效，就要犧牲數據分析的性能，而想要實時數據分析，快速完成用戶畫像就不能再依靠原有技術棧。
處理時效與實時用戶畫像的平衡可能是數據庫工程師與產品經理之間永遠無法達成的協議。目前大多商業銀行都使用以Oracle為代表的TP數據庫作為核心系統，但Oracle只能處理流程性的交易數據，不能做數據挖掘。要想把數據價值做二次表達，就需要每天做ETL，跑批作業，存到數據倉庫中。然后在數據倉庫中建模、挖掘、數據集市、ODS，一層一層地構建起數據倉庫報表。
如果還是回答不出更細節、隱含的問題，比如非線性問題，還要把數據復制到SAS中做機器學習，再做統計的指標體系，去進一步挖掘。數據要在這里搬動三次，復制三份冗余，還要管理數據一致性，每天數據中心運維的大量工作都在做數據遷移。而數據在這種低效的轉運遷移過程中，很多價值就白白消耗了，且正如前文所說，TP與AP兩套體系的組件兼容性很差，能讓兩大體系協同工作已屬不易，如果再考慮災備高可用方面的需求，則是難上加難。
行列混存—混合負載的正確打開方式
目前，各行業數據中心都迫切尋找一棧式解決方案，通過屏蔽大數據技術底層組件的差別，尋找“All Data In One”的解決方案，只有如此才能降本增效。
TP與AP的巨大差異，在于行存與列存在不同使用場景下的效能表現。在計算機世界中，數據吞吐速率往往受數據訪問局部性原理支配。我們知道，現代硬盤、內存工作原理是當用戶讀某一區域的數據時，其鄰接的數據也會被調入上一級高速緩存，讀1KB數據和連續的64MB數據的代價基本相同，用戶在讀取連續的磁盤或者內存信息時，其速度往往比隨機讀取快一個數量級。因此，行存儲大多用在SQL的TP場景，而列存儲基本用在NoSQL的AP場景。
這背后的原因也很簡單，還是以銀行業作為案例，在聯機交易的TP場景下，比如當客戶取款時，會校驗用戶、賬號、密碼、余額等信息，這些信息都是以“行”為單位存儲的，聯機交易中的數據經常是以“行”為單位訪問的，把數據放在一行就會有訪問速度的優勢。但在統計、分析營業報表，進行數據挖掘等AP場景下，往往只需要關注交易金額、賬戶余額等少量維度的信息，而不需要用戶、賬號、密碼等數據，在這種場景下，將同一維度信息放在一起的列存儲方案就有很大的速度優勢了。
將行、列進行混存，綜合兩者的優勢，這方面業界也有不少嘗試，但往往都不是很成功，最大的問題還是在于性能。對于聯機TP交易場景來說，列式存儲的寫入性能太低了。所以一般來說，傳統的方案往往還是退化成為行式存儲TP數據庫，在交易量少的日終結算時刻，將數據吐給列式存儲AP數據庫進行數據挖掘。
如圖1所示，邏輯上，業務場景主要分為兩類：聯機交易OLTP和數據分析OLAP。HTAP數據庫不僅支持使用SQL進行傳統的關系模型計算，更是將圖計算和AI建模納入了邏輯計劃中，可進行高階計算。在數據存儲層，通過行列混合的方式，按需支持OLAP和OLTP場景，這樣就做到了一種存儲架構兼容所有場景。
這種邏輯計劃及存儲融合，也稱“All Data In One”，是對數據庫基礎底座的重新定義。在資源調度層，通過AI-Native的方式探查出需要使用的調度引擎，并在實際計算時，做好資源隔離。這種架構可以更有效地支撐數據計算，最終實現一個數據庫融合所有場景的終極目標。相信未來的國產HTAP數據庫，還將繼續朝著“All Data In One”的道路前進，發展特色不斷創新，降低系統運維成本，發揮數據的最大價值。
