編者薦語：

本文作者為祁國(guó)輝，加入石原子科技前，祁國(guó)輝老師曾任 Oracle 云平臺(tái)事業(yè)部電信行業(yè)技術(shù)總監(jiān)，擁有超過 25 年數(shù)據(jù)庫和數(shù)據(jù)倉庫 HK 經(jīng)驗(yàn)。這篇文章將從專業(yè)的角度剖析 HTAP 的價(jià)值所在，分析得客觀且中肯。

StoneDB，已在 HTAP 路上~

以下文章來源于ITPUB?，作者祁國(guó)輝

?

目前業(yè)界和學(xué)術(shù)界都對(duì)HTAP 有非常大的熱度， HTAP的快速發(fā)展也是指日可待。HTAP，到底是不是最終解決方案呢？

作者?|?祁國(guó)輝

責(zé)編?|?韓? ?楠

對(duì)于數(shù)據(jù)庫領(lǐng)域的人士來說， OLAP和OLTP都耳熟能詳了。

OLTP 說的是在線事務(wù)處理，強(qiáng)調(diào)小數(shù)據(jù)量快速處理，要求高并發(fā)， 低延時(shí)，對(duì)于數(shù)據(jù)一致性有極高的要求，一般用IOPS來衡量性能。

OLAP 指的則是在線分析處理， 重點(diǎn)是大量數(shù)據(jù)的統(tǒng)計(jì)分析，要求大數(shù)據(jù)量的快速處理和匯總，數(shù)據(jù)可以容忍少量滯后，一般用IO Throught來評(píng)價(jià)這種大塊IO的性能。

在企業(yè)的應(yīng)用場(chǎng)景中，一般而言， 核心業(yè)務(wù)系統(tǒng)都是屬于 OLTP， 比如 CRM、訂單系統(tǒng)、銷售系統(tǒng)等等。而報(bào)表和分析， 都會(huì)被劃為 OLAP， 典型就是數(shù)據(jù)倉庫， 而我們通常講的多維數(shù)據(jù)庫， 那更是典型中的典型， OLAP 中的 OLAP（hyperion）。

HTAP 的前世今生

前面簡(jiǎn)單講了一下OLTP和OLAP，因?yàn)樗鼈兊膫?cè)重點(diǎn)不同， 自然對(duì)數(shù)據(jù)庫和軟硬件系統(tǒng)有了不太一樣的要求。

在投資有限不能兼顧的時(shí)候， 就會(huì)適當(dāng)有所取舍， 比如OLTP系統(tǒng)， 容量就不是第一要求。有條件的話， 磁盤選擇最快的， 容量小一點(diǎn)無所謂， 絕大多數(shù)的OLTP系統(tǒng)數(shù)據(jù)量都在100TP以下，甚至有些企業(yè)的核心系統(tǒng)為了高性能， 控制在10TB以下。

而OLAP類的系統(tǒng)， 都會(huì)有一個(gè)巨大的體量， 100TB只是開始， PB級(jí)別的系統(tǒng)比比皆是，這時(shí)候再追求磁盤速度就有點(diǎn)強(qiáng)人所難了。

有了這樣的需求， 自然也會(huì)催生出對(duì)應(yīng)的產(chǎn)品。OLTP領(lǐng)域，因?yàn)橐话愣际瞧髽I(yè)核心數(shù)據(jù)，數(shù)據(jù)庫會(huì)進(jìn)一步向高穩(wěn)定、高并發(fā)、高可靠的方向推進(jìn)， 企業(yè)的投資也會(huì)更大。Oracle、Mysql 基本上在這個(gè)領(lǐng)域處于主導(dǎo)地位。

相對(duì)而言， OLAP領(lǐng)域的空間更大一些， 選擇的因素也會(huì)更多樣化， 有通過海量數(shù)據(jù)預(yù)處理來實(shí)現(xiàn)快速報(bào)表生成的， 有利用大量硬件并發(fā)處理的MPP數(shù)據(jù)庫， 當(dāng)然某種角度上， Hadoop 也是一類OLAP的應(yīng)用， 采用的大量集群來實(shí)現(xiàn)海量數(shù)據(jù)處理。

但，萬事無絕對(duì)。

我們可能找出一個(gè)100%的OLAP系統(tǒng)， 它只處理OLAP的需求， 但是我們很難說某個(gè)OLTP系統(tǒng)是100%的OLTP。因?yàn)?，任何業(yè)務(wù)系統(tǒng)， 發(fā)展到一定階段， 都會(huì)有一個(gè)簡(jiǎn)單的子系統(tǒng)來處理即時(shí)報(bào)表。?

更有甚者， 有些業(yè)務(wù)自帶大量的統(tǒng)計(jì)查詢， 舉個(gè)例子，為了要求手機(jī)號(hào)碼實(shí)名制， 甚至控制一人多號(hào)的情況發(fā)生。

當(dāng)一個(gè)人去開設(shè)新的手機(jī)號(hào)碼時(shí)， 首先需要統(tǒng)計(jì)該身份證下在全國(guó)范圍內(nèi)有多少個(gè)電話號(hào)碼，另外還需要查之前的號(hào)碼是否有欠費(fèi)等行為，如此等等，不一而足， 我印象中， 曾經(jīng)有一個(gè)用戶鑒權(quán)過程，包含多達(dá)40+項(xiàng)的驗(yàn)證 。

更不提， 還有大量的新興企業(yè)， 還在快速的原始積累， 市場(chǎng)拓展， 沒有時(shí)間和精力去架構(gòu)企業(yè)級(jí)的數(shù)據(jù)倉庫系統(tǒng)。

就像每次去吃西餐，我們發(fā)現(xiàn)面前赫然擺著好幾副刀叉和勺子， 大多數(shù)人是沒法分辨到底應(yīng)用用哪個(gè)叉子吃沙拉？哪個(gè)叉子切牛排？西餐禮儀固然重要， 但是絕大多數(shù)時(shí)間吃西式簡(jiǎn)餐的時(shí)候， 我們還是一副刀叉吃完全程。

因?yàn)閯偺岬降倪@種場(chǎng)景屢見不鮮， 所以就催生出一個(gè)在OLAP和OLTP之間的灰色地帶，該如何處理的問題。架構(gòu)師們一般都傾向于尋找一個(gè)平衡點(diǎn)， 切分OLTP和OLAP， 這樣有利于將來的整個(gè)企業(yè)架構(gòu)，更加清晰可持續(xù)發(fā)展。

不過站在業(yè)務(wù)的角度， 是希望用最簡(jiǎn)單的方法， 直接解決這些接踵而至的即時(shí)分析需求。因此HTAP應(yīng)運(yùn)而生。

在這個(gè)過程中，有一個(gè)小插曲， 因?yàn)槲覀円恢闭f某個(gè)數(shù)據(jù)庫是適合OLTP， 某個(gè)數(shù)據(jù)庫適合OLAP。自然也就會(huì)有OLTP數(shù)據(jù)庫和OLAP數(shù)據(jù)庫的說法， 這時(shí)候， 有的數(shù)據(jù)庫也會(huì)說， 我的數(shù)據(jù)庫既可以支持OLTP， 也可以支持OLAP， 所以我們的數(shù)據(jù)庫就是HTAP。

當(dāng)然這個(gè)話題也無可厚非， 投資足夠的前提下，是完全可行的。這個(gè)我們后面也會(huì)有描述， 但是目前業(yè)界已經(jīng)約定俗成的HTAP概念， 還是利用內(nèi)存技術(shù)，實(shí)現(xiàn)在同一個(gè)應(yīng)用中OLTP和OLAP并行的技術(shù)。

把握 HTAP 的關(guān)鍵技術(shù)點(diǎn)

基于這樣的共識(shí)和定義， 我們也需要進(jìn)一步去理解HTAP中的一些關(guān)鍵技術(shù)點(diǎn)， 把握了這些技術(shù)點(diǎn)， 我們才可以對(duì)HTAP有深入的了解。

◆?內(nèi)存/閃存技術(shù)

首先，就是內(nèi)存/閃存技術(shù)。隨著技術(shù)的發(fā)展， 摩爾定律一直在推動(dòng)著IT技術(shù)的飛速發(fā)展， 計(jì)算機(jī)的內(nèi)存從 KB 到了 TB， 閃存的容量也在不斷地刷新，雖然這使得一些老牌程序員非常失落， 他們認(rèn)為只有認(rèn)真考慮過 640k 內(nèi)存使用的程序員，才是真正的程序員。

但是，這些新的技術(shù)使很多之前的不可能變成了可能，目前最新技術(shù)， 閃存容量已經(jīng)突破單片容量 2TB， 這對(duì)于很多企業(yè)的核心數(shù)據(jù)庫來說， 已經(jīng)綽綽有余了。怎樣利用內(nèi)存/閃存技術(shù)進(jìn)一步突破數(shù)據(jù)處理效率， 自然也是技術(shù)人員孜孜以求的目標(biāo)。

那既然內(nèi)存都這么大了， 為什么不把所有的數(shù)據(jù)都存在內(nèi)存里， 那不是就一下解決所有問題了嗎？究其原因， 還是有幾個(gè)相關(guān)的考慮：

首先是數(shù)據(jù)持久化的問題， 大家都知道， 內(nèi)存是通過電路來實(shí)現(xiàn)數(shù)據(jù)存儲(chǔ)的。當(dāng)內(nèi)存掉電， 所有內(nèi)容會(huì)消失，下次加電，數(shù)據(jù)需要重新裝載， 對(duì)于企業(yè)的核心數(shù)據(jù)， 一方面， 不能接受這樣的風(fēng)險(xiǎn)， 另一方面，數(shù)據(jù)加電之后的數(shù)據(jù)裝載也需要很長(zhǎng)時(shí)間， 比如100TB的數(shù)據(jù)加載進(jìn)內(nèi)存， 然后內(nèi)存中重新建立索引， 怎么也需要幾十分鐘的時(shí)間， 這就是一個(gè)硬傷。

歷史上曾經(jīng)出現(xiàn)過不少純內(nèi)存的產(chǎn)品， 就是這個(gè)原因，一直都沒有占領(lǐng)企業(yè)核心應(yīng)用領(lǐng)域。

不過， 隨著新技術(shù)的發(fā)展， 曙光乍現(xiàn)， 最新的PMem 技術(shù)， 可以保證加載在PMem中的數(shù)據(jù)， 掉電后不丟失， 相信幾年之后， 這個(gè)領(lǐng)域還會(huì)有新的驚喜。

另外一個(gè)方面是，就是下面說的列式存儲(chǔ)技術(shù)。

◆?列式存儲(chǔ)

因?yàn)镺LTP和OLAP的訪問模式不一樣， 對(duì)于OLTP來說， 基本上每次訪問都是某行數(shù)據(jù)的全部?jī)?nèi)容， 但是對(duì)于OLAP來說， 更大幾率是每次查詢分析只涉及部分列， 所以在這種情況下， OLAP應(yīng)用采用列式存儲(chǔ)， 能夠進(jìn)一步提升查詢的效率。

對(duì)比之后，就可以看出， 對(duì)于統(tǒng)計(jì)匯總中的列式存儲(chǔ)， 會(huì)大大減少查詢時(shí)的掃描數(shù)量， 從而大幅提升性能。

◆?數(shù)據(jù)復(fù)制技術(shù)

因?yàn)槲覀兊腛LTP數(shù)據(jù)還是在行式數(shù)據(jù)中存儲(chǔ)，所以，我們需要有一種手段， 保證用戶的每一筆數(shù)據(jù)操作， 在OLTP系統(tǒng)中完成之后，都需要盡快地體現(xiàn)在列式存儲(chǔ)中， 這樣才能使得用戶看到及時(shí)的統(tǒng)計(jì)數(shù)據(jù)。

這個(gè)時(shí)候，就會(huì)有一個(gè)小小的問題， 因?yàn)槊看无D(zhuǎn)換都是有額外的開銷， 我們都知道列式數(shù)據(jù)庫的優(yōu)勢(shì)在于數(shù)據(jù)查詢， 弱點(diǎn)在于數(shù)據(jù)的update， 而每次轉(zhuǎn)換都有可能導(dǎo)致列式數(shù)據(jù)庫的update。

那么我們就需要找到一個(gè)平衡， 并不是每次新數(shù)據(jù)來都刷新列存， 而是積累到一定時(shí)候， 統(tǒng)一做一次刷新， 但是如果OLTP系統(tǒng)的數(shù)據(jù)刷新量非常大， 那對(duì)HTAP系統(tǒng)來說就是一個(gè)巨大的考驗(yàn)。不同數(shù)據(jù)庫在此都有獨(dú)家的秘方來進(jìn)行優(yōu)化。

另外一點(diǎn)， 看HTAP的架構(gòu)， 會(huì)有兩種， 一種是在現(xiàn)有系統(tǒng)之上， 通過增加內(nèi)存來實(shí)現(xiàn)在原系統(tǒng)之上的HTAP支持， 另外一種是通過日志等手段， 同步到另一批機(jī)器上，實(shí)現(xiàn)分系統(tǒng)的HTAP， 這種技術(shù)帶來的時(shí)延就會(huì)更大，我們都知道， 本地內(nèi)存存取的速度和網(wǎng)絡(luò)訪問的速度，是有巨大的差異。

這種架構(gòu)下， 數(shù)據(jù)復(fù)制后，帶來的數(shù)據(jù)延遲就會(huì)遠(yuǎn)遠(yuǎn)大于第一種方式， 但是相應(yīng)帶來的好處就是有更好的隔離度和擴(kuò)展性。

◆?查詢路由和資源調(diào)度

數(shù)據(jù)準(zhǔn)備好了， 那應(yīng)用程序怎么知道什么時(shí)候用行存？什么時(shí)候用列存？如果這需要應(yīng)用程序自己選擇， 那和前面舉的例子， 吃西餐時(shí)的選叉子一樣，還是不能解決問題。

所以在這里， 所有的數(shù)據(jù)庫廠商都會(huì)有比較一致的價(jià)值觀， 就是透明實(shí)現(xiàn)路由切換。當(dāng)用戶的SQL 進(jìn)來之后， 由系統(tǒng)的優(yōu)化器來分析， 這個(gè)SQL 是需要OLTP操作還是OLAP操作， 因?yàn)槟壳暗臄?shù)據(jù)庫，基本都采用了基于成本的優(yōu)化器， 很容易分辨出應(yīng)用的訪問模式， 在分析完成之后， 系統(tǒng)會(huì)自動(dòng)把SQL 路由到對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)中，進(jìn)行執(zhí)行， 當(dāng)數(shù)據(jù)處理完成之后， 再返回給用戶。

談到自動(dòng)調(diào)度， 那就不得不說資源調(diào)度的問題， 當(dāng)一個(gè)系統(tǒng)同時(shí)處理OLTP和OLAP的時(shí)候。尤其在資源不夠充分的情況下， 如何根據(jù)需求來動(dòng)態(tài)決定資源分配，就是一門藝術(shù)， 比如通常情況下， 我們都需要OLAP不阻塞OLTP， 查詢分析的優(yōu)先級(jí)是低于業(yè)務(wù)處理的優(yōu)先級(jí)， 但是如果是一個(gè)突發(fā)的決策需求， 如何盡快完成？

能否通過自動(dòng)策略， 實(shí)現(xiàn)OLTP和OLAP之間的動(dòng)態(tài)平衡， 這對(duì)于 OLAP和OLTP在同一臺(tái)機(jī)器上的HTAP 就是一個(gè)問題。而對(duì)于OLTP和OLAP分開在不同機(jī)器的HTAP， 就天然不存在這種資源爭(zhēng)用的問題

◆?動(dòng)態(tài)加載和數(shù)據(jù)壓縮

數(shù)據(jù)是無限的， 內(nèi)存是有限的， ?那怎么最大限度地發(fā)揮內(nèi)存中列式存儲(chǔ)的優(yōu)勢(shì)呢？?這個(gè)時(shí)候就有兩個(gè)方向， 可以在一定情況下來緩解這個(gè)問題。

1.列式數(shù)據(jù)動(dòng)態(tài)加載。一般而言， 對(duì)于那些數(shù)據(jù)需要加載在內(nèi)存中的列式數(shù)據(jù)中，來加速查詢和報(bào)表， 這個(gè)是可以通過人工來指定， 特定的表， 或者特定表的某個(gè)分區(qū)。但是如果能夠由數(shù)據(jù)庫系統(tǒng)來自行決定呢？

首先數(shù)據(jù)庫可以根據(jù)歷史SQL的執(zhí)行情況， 來預(yù)估出一個(gè)內(nèi)存容量大小對(duì)于系統(tǒng)加速的對(duì)比曲線， 這樣用戶就可以找到一個(gè)最佳的平衡點(diǎn)。

更進(jìn)一步， 甚至可以容許系統(tǒng)在運(yùn)行的過程中， 自行決定把一些很少用到的數(shù)據(jù)移出內(nèi)存， 把一些沒有命中的數(shù)據(jù)從磁盤加載到內(nèi)存中， 以避免出現(xiàn)查詢的時(shí)候緩存擊穿的問題。這個(gè)技術(shù)存在一定的風(fēng)險(xiǎn)， 目前還不是特別完善。

2.列式數(shù)據(jù)的壓縮。我們都知道， 當(dāng)數(shù)據(jù)以列式來管理的時(shí)候， 單個(gè)列中重復(fù)數(shù)據(jù)的出現(xiàn)幾率會(huì)遠(yuǎn)大于行式存儲(chǔ)， 所以內(nèi)存中的列式存儲(chǔ)， 天然具備可壓縮的能力， 所以在內(nèi)存的列式數(shù)據(jù)庫中， 采用壓縮， 也是提高空間利用率的一大法寶。

??數(shù)據(jù)塊越大， 數(shù)據(jù)重復(fù)的幾率越高， 所以， 盡量采用大數(shù)據(jù)塊；

??表寬度要小， 因?yàn)楸硖珜挘?一個(gè)數(shù)據(jù)塊中相同的數(shù)據(jù)都可能出現(xiàn)不了幾次；

??盡量在入庫前按照重復(fù)率高的大字段進(jìn)行排序， 這樣相同的數(shù)據(jù)就可以出現(xiàn)在相鄰的位置。

幾種 HTAP 場(chǎng)景的技術(shù)解析

下面我們根據(jù)不同的場(chǎng)景，來看看幾種最常見的HTAP場(chǎng)景。

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

把Exadata 拿來做HTAP， 也許會(huì)有人持有不同意見， 但是因?yàn)镋xadata天生利用了大量的軟硬件結(jié)合和內(nèi)存技術(shù)， 而且能夠在同一個(gè)系統(tǒng)中，同時(shí)支持高并發(fā)數(shù)據(jù)更新和海量數(shù)據(jù)查詢，說它是HTAP并不過分。

天下武功， 唯快不破。我們之所以提出HTAP， 都是在預(yù)算有限的環(huán)境下，采用多種技術(shù)結(jié)合的方式，來實(shí)現(xiàn)揚(yáng)長(zhǎng)避短， Exadata的Smart Scan ， 混合列壓縮， 內(nèi)存， Pmem， 閃存和硬盤的多級(jí)存儲(chǔ)技術(shù)， 給用戶帶來了極高的性能，極大的便利性。

一言以蔽之， 如果你不想那么復(fù)雜， 又有足夠的投資， Exadata 應(yīng)該是最好的選擇， 誰用誰知道。具體特性就不贅述了。

◆?不換手機(jī)不換號(hào)， 一鍵上5G

對(duì)于那些在原來業(yè)務(wù)系統(tǒng)上， 通過在內(nèi)存中開辟一塊空間， 在內(nèi)存中進(jìn)行列式存儲(chǔ)以加速 OLAP 應(yīng)用的產(chǎn)品，用戶可以對(duì)應(yīng)用不做任何修改 ， 也不需要更換硬件平臺(tái)；應(yīng)用系統(tǒng)無感升級(jí)， 用戶 SQL 通過優(yōu)化器自動(dòng)路由到相應(yīng)的存儲(chǔ)的技術(shù)， 代表產(chǎn)品有 Oracle?的 DBIM 和 SQL Server。

對(duì)于這種技術(shù)， 我經(jīng)常和客戶做這樣一個(gè)比喻，就是不換手機(jī)不換號(hào)， 一鍵上5G。

在這里我們吧，可以簡(jiǎn)單地以 Oracle DBIM 為例， 來深入了解一下這種技術(shù)。

首先， 所有數(shù)據(jù)在硬盤上是以傳統(tǒng)行式進(jìn)行存儲(chǔ)的， 這個(gè)是最基本的。

除了傳統(tǒng)的內(nèi)存中的 ?Buffer Cache 之外，Oracle DBIM 在內(nèi)存中單獨(dú)開辟了一個(gè)部分， 叫做 In-Memory Column Store， 在這片區(qū)域中， 數(shù)據(jù)是以列的方式進(jìn)行存儲(chǔ)的， 用戶的查詢會(huì)在優(yōu)化器的干預(yù)下，自動(dòng)路由到相應(yīng)的區(qū)域。

進(jìn)一步， 我們看一下這片內(nèi)存中的數(shù)據(jù)存儲(chǔ)格式。

所有的數(shù)據(jù)的DML操作， 為了保證數(shù)據(jù)的完整性和一致性， 都是先通過行式處理進(jìn)行保存， 保存完畢之后， 再同步到in ?memory 區(qū)域。而在in-memory中的數(shù)據(jù)是由兩部分組成， 第一部分是列式存儲(chǔ)IMCU， 另外一部分記錄最新數(shù)據(jù)變化的SMU。

對(duì)于列式數(shù)據(jù)的查詢是遍歷IMCU和SMU之后的組合結(jié)果， 當(dāng)數(shù)據(jù)增量達(dá)到一定的值， 就會(huì)進(jìn)行合并。

在合并的時(shí)候， 首先標(biāo)記當(dāng)前IMCU為舊數(shù)據(jù)， 然后結(jié)合IMCU和SMU的數(shù)據(jù)， 生成新的IMCN， 同時(shí)生成空的SMU， 而舊的IMCU 會(huì)在不再使用或者空間不足的時(shí)候，自動(dòng)刪除， 這樣就避免了新的數(shù)據(jù)進(jìn)來之后， 對(duì)列式數(shù)據(jù)存儲(chǔ)的頻繁更新。

但是， 即使采用這種技術(shù)， 合并的時(shí)候還是會(huì)有額外開銷， 當(dāng)數(shù)據(jù)刷新量巨大的時(shí)候， 會(huì)造成OLAP性能的抖動(dòng)。

◆?兄弟齊心， 其利斷金

上面這種方式的優(yōu)點(diǎn)在于架構(gòu)變化小， 但是缺點(diǎn)在于硬件需求加大， 因?yàn)樵谕粋€(gè)系統(tǒng)中， 首先要額外的內(nèi)存。另外， OLTP和OLAP混合， 會(huì)造成資源的沖突和爭(zhēng)用。在X86化大行其道的今天，出現(xiàn)了新的架構(gòu)。

方法就是保持原始系統(tǒng)不動(dòng)， 在相鄰增加一批計(jì)算資源專門負(fù)責(zé) OLAP 計(jì)算， 然后通過日志傳輸?shù)燃夹g(shù)， 把數(shù)據(jù)同步到相鄰的 OLAP 集群中，OLTP 系統(tǒng)將會(huì)在遷移耗費(fèi)資源的 OLAP 請(qǐng)求后，性能和穩(wěn)定性有大幅提高， 同時(shí) OLAP 集群可以采用分布式技術(shù)，實(shí)現(xiàn)橫向的擴(kuò)展。

代表產(chǎn)品，就是 MySQL 的 Heatwave 和 StoneDB 的 Tianmu， 我們以 Heatwave 為例， 簡(jiǎn)單看看其中的技術(shù)要點(diǎn)。

HeatWave 本身是 InnoDB 的子引擎， OLTP 系統(tǒng)的數(shù)據(jù)， 會(huì)利用 binlog 投遞到HeatWave 集群， 而查詢優(yōu)化器會(huì)自動(dòng)把用戶的 OLAP 查詢路由到 HeatWave 中進(jìn)行執(zhí)行。

HeatWave 目前 Oracle 只在?Cloud 上部署銷售， 希望本地部署的用戶， 其實(shí)可以考慮其他國(guó)內(nèi)的開源 HTAP 產(chǎn)品（比如 StoneDB 等）， 原理上都是一致的。

HTAP 是不是最終解決方案

談了這么多， 大家也看到了， 目前業(yè)界和學(xué)術(shù)界都對(duì) HTAP 有非常大的熱度， HTAP 的快速發(fā)展也是指日可待， 但是 HTAP 是不是最終解決方案呢？

實(shí)質(zhì)上，HTAP 還是有自身的一些限制， 首先從架構(gòu)上來說， HTAP是定位單個(gè)系統(tǒng)， 在一個(gè)獨(dú)立系統(tǒng)中同時(shí)存在 OLTP 和 OLAP， 這個(gè)很常見。但是絕大多數(shù)的企業(yè)， 并不僅僅存在一套系統(tǒng)，尤其在現(xiàn)在單元化、中臺(tái)化之后， 單個(gè)系統(tǒng)支撐企業(yè)的場(chǎng)景是越來越少了。

其次， 除了簡(jiǎn)單報(bào)表， 絕大多數(shù)的企業(yè)決策支持需求， 都需要來自企業(yè)內(nèi)外多種渠道的數(shù)據(jù)， 進(jìn)行整合加工之后， 才能構(gòu)成企業(yè)級(jí)的決策支持信息。

數(shù)據(jù)倉庫需要繁瑣的 ETL 和建模，最終才能生成決策信息， 隨著實(shí)時(shí)數(shù)倉的技術(shù)快速發(fā)展， HTAP 的實(shí)時(shí)分析場(chǎng)景，會(huì)遇到實(shí)時(shí)數(shù)倉的挑戰(zhàn)。

所以， HTAP 更大程度上是基于部門級(jí)的戰(zhàn)術(shù)工具， 可以在中小規(guī)模的數(shù)據(jù)庫上， 短平快地實(shí)現(xiàn)數(shù)據(jù)分析。各種部門級(jí)的應(yīng)用， 小范圍的數(shù)據(jù)匯總統(tǒng)計(jì)在基層非常常見。

萬事開頭難， 大量的中小企業(yè)在初期， 沒有精力物力來實(shí)現(xiàn)大規(guī)模的企業(yè)級(jí)數(shù)據(jù)倉庫，利用HTAP來解決迫在眉睫的分析問題， 這些也是HTAP 可以提供助力的地方。

寫在最后

HTAP 作為一輪新的技術(shù)熱點(diǎn)， 帶來了更多的機(jī)會(huì)和挑戰(zhàn)。?在各個(gè)企業(yè)都有大量的使用場(chǎng)景，雖然不是重量級(jí)的解決方案， 但是市場(chǎng)和前途還是挺有看頭的。

▼

作者介紹

祁國(guó)輝

前 Oracle 云平臺(tái)事業(yè)部電信行業(yè)技術(shù)總監(jiān)

現(xiàn)就職于杭州石原子科技有限公司

【作者介紹】網(wǎng)名"atiger"，前 Oracle 云平臺(tái)事業(yè)部電信行業(yè)技術(shù)總監(jiān)。擁有超過25年數(shù)據(jù)庫和數(shù)據(jù)倉庫HK經(jīng)驗(yàn)。曾創(chuàng)辦著名數(shù)據(jù)倉庫網(wǎng)站：數(shù)據(jù)倉庫之路。