你真的瞭解HTAP嗎

HTAP是目前資料庫領域談得最多的一個詞，也是我們存在最多誤解的詞。曾經有一個企業的IT主管和我說，如果我選一款HTAP資料庫產品，是不是我都可以把資料倉儲拆了，今後只有線上交易系統和大資料平臺就行了。這裡面實際上包含了對HTAP的巨大的誤解。HTAP=OLTP+OLAP，上面的這個公式真的成立嗎?今天我們來簡單地瞭解一下傳統的OLTP和OLAP是什麼樣的。

上面是一個傳統的交易域和數倉域分離的傳統資料倉儲架構。大量的線上交易系統首先把資料複製到貼貼源層的ODS，然後經過ETL工具載入到資料倉儲中，同時資料倉儲中還會儲存一些來自外部的資料，甚至一些外購的資料。儲存在資料倉儲中的是高價值資料，經過處理後形成一系列的資料集市，供業務系統使用。這種架構中將線上交易與資料分析兩種截然不同的負載區分開來，避免相互干擾。

不過這種架構最大的問題是，ETL的延時比較大，很多需要及時分析的業務無法得到保證。因此縮短線上交易系統到資料倉儲之間的延時就十分重要了。

Oracle公司推出了一套基於準實時ETL產品ODI的解決方案。生產系統使用ORACLE的交易型資料庫模式，透過ODI捕獲生產系統的變化，並透過定義好的轉換規則，準實時進行ETL操作，複製資料到ORACLE OLAP模式的資料倉儲中。上面的最佳化模式雖然能解決一部分資料倉儲的延時問題，但是對於實時性要求更高的一些業務就無法滿足了。

因此在線上交易系統中支撐比較強大的資料分析功能的需求就應運而生了，這個需求就是HTAP計算模式。不過聰明的朋友可能也看出來了，這種HTAP計算並不等同於線上交易+資料倉儲業務。因為如果我們要把一個企業的所有高價值資料都儲存在一個資料庫裡，才能實現這個替代資料倉儲的目標。而這種設計會讓單一的資料庫太重了，一旦這個資料庫出現一點點問題，可能就會影響整個企業的業務，這是我們無法承受的。企業需要的HTAP能力不需要完全覆蓋資料倉儲業務，僅僅需要對核心業務需要的線上分析能力做一定的提升就可以了。因此在HTAP資料庫中需要儲存的就是OLTP系統本身的資料以及部分分析必須的從外部提取過來的高價值資料。

上面的圖看上去是不是簡單多了，不過這個簡化了的業務需求也並不容易實現。這是因為TP系統跑的是穩定，高併發，低延時，大多數透過索引訪問，大量寫操作的小業務，對於併發寫入量較大的表，儘可能減少不必要的索引;而AP系統跑的是隨機性大，資源開銷極大，大部分需要對大表進行並行掃描，持續時間很長的的以讀為主的分析類業務。讀寫操作之間會有相互影響，大量的寫操作希望索引越少越好，而大量的讀操作希望索引越豐富越好。AP操作的臨時性資源開銷可能會導致TP業務的延時出現經常性的抖動，這些都是會讓TP業務無法忍受的。TP業務經常需要訪問一張表中的多個欄位，從而實現複雜的業務邏輯，因此用行儲存的方式效能最佳。AP業務經常對某一列的資料做掃描分析，因此如果資料按列儲存具有較好的效能。這些業務之間的矛盾都使一個資料庫中承載混合的HTAP負載十分困難。

而實際上，我們的OLTP系統中，真的都需要HTAP工作負載嗎?答案是否定的。大多數OLTP系統中僅僅需要一定量的批處理負載，用於對資料進行一些複雜的加工。在一個設計的比較好的OLTP系統中，透過定期自動彙總資料，物化檢視等方式，可以大幅度減少開銷極大的AP工作負載。只有極少數的系統是真的必須有複雜的準實時OLAP需求的。而對於AP的實時性要求，如果透過更實時的資料複製和ETL，大部分問題是可以解決的。此外，分散式SQL引擎的效率、OLTP/OLAP的資源隔離與防干擾措施、資料儲存格式、大型叢集管理、讀寫副本的使用方式、主副本切換帶來的效能抖動等都會影響資料庫的HTAP能力。

既然HTAP負載並不是業務系統一定要追求的，那麼為什麼現在我們隨便看到一個分散式資料庫，就一定說自己是HTAP資料庫呢?這實際上是和分散式資料庫的發展歷史分不開的。分散式資料庫剛剛出現的時候，主要還是為了高併發的OLTP寫入業務。因此這些資料庫產品的多表關聯，複雜分析功能是很弱的。分佈資料庫廠家也在不斷地最佳化產品，努力提升這方面的能力。因此為了標榜自己的技術優勢，大家都在HTAP能力上開展起軍備競賽了。

雖然如此，如果真的有一個HTAP能力極強的資料庫產品放在我們面前，對於使用者和軟體開發商來說，肯定是一件好事情。這會讓我們的管理系統，交易系統的功能變得更加豐富。對於某些行業的業務系統來說，可能會促進業務的革命性變革。比如說能源行業鼓吹了多年的源網核儲互動，因為我們的資料處理能力不足，不及時，導致我們在電力生產、消費、儲能、排程等方面的資料無法及時進行處理分析，大大降低了能源的綜合利用率。

目前來說，電是不可大規模儲存的資源，而且電源側發出的電必須平衡的被消耗掉，否則多發出來的電必須被儘快消耗掉，而某個區域性網路上的電能不足時，就只能拉閘限電，確保電能在網路上整個是平衡的。當電源側發電量過大，或者用電需求過大，供給不足或者電力排程不及時，導致用電缺口達到一定程度的時候，電網會因為不平衡而解裂，2013年洛杉磯大停電或者前幾年美國德州大停電的慘劇就會重演了。

我們國家這些年沒有出現過類似的情況，這說明我國的大電網排程運營水平是很高的。不過這種水平很高並不意味著很高效。我們的電網排程十分依賴於相對穩定的電源，比如火力發電。而水電、光伏、風能這些清潔能源因為其不穩定，會大大加大電網排程的難度。因此目前我國棄風棄光的比例一直是高於西方已開發國家的。

為了完成碳中和目標，加大清潔能源供給是必然的，因此源網核儲互動能力的提升十分關鍵。而要提升源網核儲互動的效率，精準及時的資料採集與資料分析是關鍵。我們必須提高電能表採集的頻率(歐洲最先進的電網計量已經實現了5分鐘全量採集，而我們目前的主流水平還只是重點電錶15分鐘間隔採集)，提升與發電企業之間的資料交換的水平，對氣候、社會熱點、製造業增長態勢、外貿等資料進行更廣泛的採集與處理分析，這樣才能逐步提升電網排程計劃的水平。以目前電能採集系統到大資料平臺資料複製的一天時延來看，要實現這個任務是幾乎不可能的。

具有強大HTAP處理能力的資料庫是解決這個計算難題的十分關鍵的IT基礎設施，這是一個十分現實的HTAP計算場景。十分可惜的是，在我們為這個場景選擇資料庫產品的時候，還沒有找到一款國產資料庫產品具備處理這個業務場景的能力。

其他行業中，也可以找出很多類似這樣的計算場景，在提升企業效率，降低企業成本的業務創新中，這種需求也會越來越多。因此資料庫產品發展HTAP能力是十分重要的。只是說，目前我們的國產資料庫的HTAP能力建設還處於初級階段，目前大多數國產資料庫能夠提供的HTAP能力大部分可以透過業務系統最佳化來避開，而真正對HTAP強需求的場景，我們的產品的支撐能力還略顯不足。

關於HTAP話題太複雜了，一篇文章無法講清楚，下一回，我們再來分析目前主要的資料庫產品中是如何實現HTAP的。