目前業界和學術界都對HTAP 有非常大的熱度， HTAP的快速發展也是指日可待。HTAP，到底是不是最終解決方案呢？
對于資料庫領域的人士來說， OLAP和OLTP都耳熟能詳了。
OLTP 說的是線上事務處理，強調小資料量快速處理，要求高并發， 低延時，對于資料一緻性有極高的要求，一般用IOPS來衡量性能。
OLAP 指的則是線上分析處理， 重點是大量資料的統計分析，要求大資料量的快速處理和彙總，資料可以容忍少量滞後，一般用IO Throught來評價這種大塊IO的性能。
在企業的應用場景中，一般而言， 核心業務系統都是屬于OLTP， 比如CRM、訂單系統、銷售系統等等。而報表和分析， 都會被劃為OLAP， 典型就是資料倉庫， 而我們通常講的多元資料庫， 那更是典型中的典型， OLAP中的OLAP（hyperion）。
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概念， 還是利用記憶體技術，實作在同一個應用中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場景的技術解析
下面我們根據不同的場景，來看看幾種最常見的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産品， 原理上都是一緻的。
HTAP 是不是最終解決方案
談了這麼多， 大家也看到了， 目前業界和學術界都對HTAP 有非常大的熱度， HTAP的快速發展也是指日可待， 但是HTAP是不是最終解決方案呢？
實質上，HTAP 還是有自身的一些限制， 首先從架構上來說， HTAP是定位單個系統， 在一個獨立系統中同時存在OLTP和OLAP， 這個很常見。但是絕大多數的企業， 并不僅僅存在一套系統，尤其在現在單元化、中台化之後， 單個系統支撐企業的場景是越來越少了。
其次， 除了簡單報表， 絕大多數的企業決策支援需求， 都需要來自企業内外多種管道的資料， 進行整合加工之後， 才能構成企業級的決策支援資訊。
資料倉庫需要繁瑣的ETL和模組化，最終才能生成決策資訊， 随着實時數倉的技術快速發展， HTAP的實時分析場景，會遇到實時數倉的挑戰。
是以， HTAP 更大程度上是基于部門級的戰術工具， 可以在中小規模的資料庫上， 短平快地實作資料分析。各種部門級的應用， 小範圍的資料彙總統計在基層非常常見。
萬事開頭難， 大量的中小企業在初期， 沒有精力物力來實作大規模的企業級資料倉庫，利用HTAP來解決迫在眉睫的分析問題， 這些也是HTAP 可以提供助力的地方。
原文連結：https://mp.weixin.qq.com/s/VtRuMETywCSB_omV67ukSg