面向場景，HTAP到底是剛需還是炒作？

前面簡單講了一下OLTP和OLAP，因為它們的側重點不同， 自然對資料庫和軟硬體系統有了不太一樣的要求。

在投資有限不能兼顧的時候， 就會適當有所取捨， 比如OLTP系統， 容量就不是第一要求。 有條件的話， 磁碟選擇最快的， 容量小一點無所謂， 絕大多數的OLTP系統資料量都在100TP以下，甚至有些企業的核心繫統為了高效能， 控制在10TB以下。

而OLAP類的系統， 都會有一個巨大的體量， 100TB只是開始， PB級別的系統比比皆是，這時候再追求磁碟速度就有點強人所難了。

有了這樣的需求， 自然也會催生出對應的產品。OLTP領域，因為一般都是企業核心資料，資料庫會進一步向高穩定、高併發、高可靠的方向推進， 企業的投資也會更大。Oracle、Mysql 基本上在這個領域處於主導地位。

相對而言， OLAP領域的空間更大一些， 選擇的因素也會更多樣化， 有透過海量資料預處理來實現快速報表生成的， 有利用大量硬體併發處理的MPP資料庫， 當然某種角度上， Hadoop 也是一類OLAP的應用， 採用的大量叢集來實現海量資料處理。

但，萬事無絕對。

我們可能找出一個100%的OLAP系統， 它只處理OLAP的需求， 但是我們很難說某個OLTP系統是100%的OLTP。因為，任何業務系統， 發展到一定階段， 都會有一個簡單的子系統來處理即時報表。 

更有甚者， 有些業務自帶大量的統計查詢， 舉個例子，為了要求手機號碼實名制， 甚至控制一人多號的情況發生。

當一個人去開設新的手機號碼時， 首先需要統計該身份證下在全國範圍內有多少個電話號碼，另外還需要查之前的號碼是否有欠費等行為，如此等等，不一而足， 我印象中， 曾經有一個使用者鑑權過程，包含多達40+項的驗證 。

更不提， 還有大量的新興企業， 還在快速的原始積累， 市場擴充， 沒有時間和精力去架構企業級的資料倉儲系統。

就像每次去吃西餐，我們發現面前赫然擺著好幾副刀叉和勺子， 大多數人是沒法分辨到底應用用哪個叉子吃沙拉？哪個叉子切牛排？西餐禮儀固然重要， 但是絕大多數時間吃西式簡餐的時候， 我們還是一副刀叉吃完全程。

因為剛提到的這種場景屢見不鮮， 所以就催生出一個在OLAP和OLTP之間的灰色地帶，該如何處理的問題。架構師們一般都傾向於尋找一個平衡點， 切分OLTP和OLAP， 這樣有利於將來的整個企業架構，更加清晰可持續發展。

不過 站在業務的角度， 是希望用最簡單的方法， 直接解決這些接踵而至的即時分析需求。 因此HTAP應運而生。

在這個過程中，有一個小插曲， 因為我們一直說某個資料庫是適合OLTP， 某個資料庫適合OLAP。自然也就會有OLTP資料庫和OLAP資料庫的說法， 這時候， 有的資料庫也會說， 我的資料庫既可以支援OLTP， 也可以支援OLAP， 所以我們的資料庫就是HTAP。

基於這樣的共識和定義， 我們也需要進一步去理解HTAP中的一些關鍵技術點， 把握了這些技術點， 我們才可以對HTAP有深入的瞭解。

◆  記憶體/快閃記憶體技術

首先，就是 記憶體/快閃記憶體技術 。隨著技術的發展， 摩爾定律一直在推動著IT技術的飛速發展， 計算機的記憶體從KB 到了TB， 快閃記憶體的容量也在不斷地重新整理，雖然這使得一些老牌程式設計師非常失落， 他們認為只有認真考慮過640k記憶體使用的程式設計師，才是真正的程式設計師。

但是，這些新的技術使很多之前的不可能變成了可能，目前最新技術， 快閃記憶體容量已經突破單片容量2TB， 這對於很多企業的核心資料庫來說， 已經綽綽有餘了。怎樣利用記憶體/快閃記憶體技術進一步突破資料處理效率， 自然也是技術人員孜孜以求的目標。

那既然記憶體都這麼大了， 為什麼不把所有的資料都存在記憶體裡， 那不是就一下解決所有問題了嗎？究其原因， 還是有幾個相關的考慮：

首先是資料持久化的問題， 大家都知道， 記憶體是透過電路來實現資料儲存的。當記憶體掉電， 所有內容會消失，下次加電，資料需要重新裝載， 對於企業的核心資料， 一方面， 不能接受這樣的風險， 另一方面，資料加電之後的資料裝載也需要很長時間， 比如100TB的資料載入進記憶體， 然後記憶體中重新建立索引， 怎麼也需要幾十分鐘的時間， 這就是一個硬傷。

歷史上曾經出現過不少純記憶體的產品， 就是這個原因，一直都沒有佔領企業核心應用領域。

不過， 隨著新技術的發展， 曙光乍現， 最新的PMem 技術， 可以保證載入在PMem中的資料， 掉電後不丟失， 相信幾年之後， 這個領域還會有新的驚喜。

另外一個方面是，就是下面說的列式儲存技術。

◆  列式儲存

因為OLTP和OLAP的訪問模式不一樣， 對於OLTP來說， 基本上每次訪問都是某行資料的全部內容， 但是對於OLAP來說， 更大機率是每次查詢分析只涉及部分列， 所以在這種情況下， OLAP應用採用列式儲存， 能夠進一步提升查詢的效率。

對比之後，就可以看出， 對於統計彙總中的列式儲存， 會大大減少查詢時的掃描數量， 從而大幅提升效能。

◆  資料複製技術

因為我們的OLTP資料還是在行式資料中儲存，所以，我們需要有一種手段， 保證使用者的每一筆資料操作， 在OLTP系統中完成之後，都需要儘快地體現在列式儲存中， 這樣才能使得使用者看到及時的統計資料。

這個時候，就會有一個小小的問題 ， 因為每次轉換都是有額外的開銷， 我們都知道列式資料庫的優勢在於資料查詢， 弱點在於資料的update， 而每次轉換都有可能導致列式資料庫的update。

那麼我們就需要找到一個平衡， 並不是每次新資料來都重新整理列存， 而是積累到一定時候， 統一做一次重新整理， 但是如果OLTP系統的資料重新整理量非常大， 那對HTAP系統來說就是一個巨大的考驗。不同資料庫在此都有獨家的秘方來進行最佳化。

另外一點， 看HTAP的架構， 會有兩種， 一種是在現有系統之上， 透過增加記憶體來實現在原系統之上的HTAP支援， 另外一種是透過日誌等手段， 同步到另一批機器上，實現分系統的HTAP， 這種技術帶來的時延就會更大，我們都知道， 本地記憶體存取的速度和網路訪問的速度，是有巨大的差異。

這種架構下， 資料複製後，帶來的資料延遲就會遠遠大於第一種方式， 但是相應帶來的好處就是有更好的隔離度和擴充套件性。

◆  查詢路由和資源排程

資料準備好了， 那應用程式怎麼知道什麼時候用行存？什麼時候用列存？ 如果這需要應用程式自己選擇， 那和前面舉的例子， 吃西餐時的選叉子一樣，還是不能解決問題。

所以在這裡， 所有的資料庫廠商都會有比較一致的價值觀， 就是透明實現路由切換。當使用者的SQL 進來之後， 由系統的最佳化器來分析， 這個SQL 是需要OLTP操作還是OLAP操作， 因為目前的資料庫，基本都採用了基於成本的最佳化器， 很容易分辨出應用的訪問模式， 在分析完成之後， 系統會自動把SQL 路由到對應的資料儲存中，進行執行， 當資料處理完成之後， 再返回給使用者。

談到自動排程， 那就不得不說資源排程的問題， 當一個系統同時處理OLTP和OLAP的時候。尤其在資源不夠充分的情況下， 如何根據需求來動態決定資源分配，就是一門藝術， 比如通常情況下， 我們都需要OLAP不阻塞OLTP， 查詢分析的優先順序是低於業務處理的優先順序， 但是 如果是一個突發的決策需求， 如何儘快完成？

能否透過自動策略， 實現OLTP和OLAP之間的動態平衡， 這對於 OLAP和OLTP在同一臺機器上的HTAP 就是一個問題。而對於OLTP和OLAP分開在不同機器的HTAP， 就天然不存在這種資源爭用的問題

◆  動態載入和資料壓縮

資料是無限的， 記憶體是有限的，  那 怎麼最大限度地發揮記憶體中列式儲存的優勢呢？  這個時候就有兩個方向， 可以在一定情況下來緩解這個問題。

1.列式資料動態載入 。一般而言， 對於那些資料需要載入在記憶體中的列式資料中，來加速查詢和報表， 這個是可以透過人工來指定， 特定的表， 或者特定表的某個分割槽。但是如果能夠由資料庫系統來自行決定呢？

首先資料庫可以根據歷史SQL的執行情況， 來預估出一個記憶體容量大小對於系統加速的對比曲線， 這樣使用者就可以找到一個最佳的平衡點。

更進一步， 甚至可以容許系統在執行的過程中， 自行決定把一些很少用到的資料移出記憶體， 把一些沒有命中的資料從磁碟載入到記憶體中， 以避免出現查詢的時候快取擊穿的問題。這個技術存在一定的風險， 目前還不是特別完善。

2.列式資料的壓縮 。我們都知道， 當資料以列式來管理的時候， 單個列中重複資料的出現機率會遠大於行式儲存， 所以記憶體中的列式儲存， 天然具備可壓縮的能力， 所以在記憶體的列式資料庫中， 採用壓縮， 也是提高空間利用率的一大法寶。

下面我們根據不同的場景，來看看幾種最常見的HTAP場景。

◆  一快破萬法， O記神器 Exadata

把Exadata 拿來做HTAP， 也許會有人持有不同意見， 但是因為Exadata天生利用了大量的軟硬體結合和記憶體技術， 而且能夠在同一個系統中，同時支援高併發資料更新和海量資料查詢，說它是HTAP並不過分。

天下武功， 唯快不破。我們之所以提出HTAP， 都是在預算有限的環境下，採用多種技術結合的方式，來實現揚長避短， Exadata的Smart Scan ， 混合列壓縮， 記憶體， Pmem， 快閃記憶體和硬碟的多級儲存技術， 給使用者帶來了極高的效能，極大的便利性。

一言以蔽之， 如果你不想那麼複雜， 又有足夠的投資， Exadata 應該是最好的選擇， 誰用誰知道。具體特性就不贅述了。

◆  不換手機不換號， 一鍵上5G

對於那些在原來業務系統上， 透過在記憶體中開闢一塊空間， 在記憶體中進行列式儲存以加速OLAP應用的產品，使用者可以對應用不做任何修改 ， 也不需要更換硬體平臺；應用系統無感升級， 使用者SQL透過最佳化器自動路由到相應的儲存的技術， 代表產品有Oracle的 DBIM 和 SQL Server。

對於這種技術， 我經常和客戶做這樣一個比喻，就是不換手機不換號， 一鍵上5G。

在這裡我們吧，可以簡單地以Oracle DBIM 為例， 來深入瞭解一下這種技術。

首先， 所有資料在硬碟上是以傳統行式進行儲存的， 這個是最基本的。

除了傳統的記憶體中的  Buffer Cache之外，Oracle DBIM 在記憶體中單獨開闢了一個部分， 叫做 In-Memory Column Store， 在這片區域中， 資料是以列的方式進行儲存的， 使用者的查詢會在最佳化器的干預下，自動路由到相應的區域。

進一步， 我們看一下這片記憶體中的資料儲存格式。

所有的資料的DML操作， 為了保證資料的完整性和一致性， 都是先透過行式處理進行儲存， 儲存完畢之後， 再同步到in  memory 區域。而在in-memory中的資料是由兩部分組成， 第一部分是列式儲存IMCU， 另外一部分記錄最新資料變化的SMU。

對於列式資料的查詢是遍歷IMCU和SMU之後的組合結果， 當資料增量達到一定的值， 就會進行合併。

在合併的時候， 首先標記當前IMCU為舊資料， 然後結合IMCU和SMU的資料， 生成新的IMCN， 同時生成空的SMU， 而舊的IMCU 會在不再使用或者空間不足的時候，自動刪除， 這樣就避免了新的資料進來之後， 對列式資料儲存的頻繁更新。

但是， 即使採用這種技術， 合併的時候還是會有額外開銷， 當資料重新整理量巨大的時候， 會造成OLAP效能的抖動。

◆  兄弟齊心， 其利斷金

上面這種方式的優點在於架構變化小， 但是缺點在於硬體需求加大， 因為在同一個系統中， 首先要額外的記憶體。另外， OLTP和OLAP混合， 會造成資源的衝突和爭用。在X86化大行其道的今天，出現了新的架構。

方法就是保持原始系統不動， 在相鄰增加一批計算資源專門負責OLAP計算， 然後透過日誌傳輸等技術， 把資料同步到相鄰的OLAP叢集中，OLTP系統將會在遷移耗費資源的OLAP請求後，效能和穩定性有大幅提高， 同時OLAP叢集可以採用分散式技術，實現橫向的擴充套件。

代表產品，就是MySQL的Heatwave 和TiDB的Tikv， 我們以Heatwave為例， 簡單看看其中的技術要點。

HeatWave 本身是InnoDB的子引擎， OLTP系統的資料， 會利用binlog投遞到HeatWave叢集， 而查詢最佳化器會自動把使用者的OLAP查詢路由到HeatWave中進行執行。

HeatWave 目前只在Cloud上部署銷售， 希望本地部署的使用者， 其實可以考慮其他國內的開源HTAP產品， 原理上都是一致的。