> **此前，透過《[向量化引擎對HTAP的價值與技術思考](https://mp.weixin.qq.com/s/cq4tPEBPfKAesrgviEq1CA)》一文，我們分享了 OceanBase 怎樣看待向量化引擎技術，並介紹了用它解決複雜查詢場景的技術思路。**
>
> **HTAP 的本意是把 OLTP（事務處理）和 OLAP（分析處理）放在一個系統上更好地執行，幫助客戶開展實時業務決策，降低運營成本並提升創新效率。因為 OLTP 、OLAP 使用資源（CPU、記憶體、IO 等）的方式不同，同時執行時容易產生資源干擾。如何將二者的相互影響降到最小，成為實現 HTAP 的關鍵，也是本篇文章中資源隔離技術要解決的問題。**

### 關於作者

**席華鋒**

OceanBase技術專家，11年來持續專注資料庫的高可用和擴充套件性，曾負責 Paxos 協議在OceanBase的落地，是OceanBase TPC-C攻堅專案組成員。目前在OceanBase系統組，負責打造 HTAP的基礎設施，包括如何解決AP和TP的資源隔離問題。

------

我們認為真正的 HTAP 需要完備的資源隔離，資料庫需要提供邏輯隔離能力，與物理資源隔離形成互補，幫助使用者根據實際業務場景進行調整。**需要極致隔離的核心業務採用物理資源隔離，對成本敏感的長尾業務採用邏輯資源隔離。** 本篇文章將分享 OceanBase 對資源隔離技術的思考，闡述為什麼資源隔離技術是實現 HTAP 的必要前提，以及我們如何應對資源隔離的實施挑戰等：

- HTAP 為什麼需要資源隔離；

- 如何實現適合 HTAP 的資源隔離；
- OceanBase 資源隔離的實現效果。

## HTAP為什麼需要資源隔離？

### 資源隔離是 HTAP 的立足根本

為了說明資源隔離的重要性，我們可以把資料庫與作業系統進行比較：這兩者的共同點是複雜性，而複雜性來源於兩方面：一是功能的開放，二是對價效比的極致追求。功能的開放意味著負載不可控，如一個使用者程式可以做任何事，一條 SQL 也可以做任何事；追求價效比則是因為基礎軟體使用者量大，最佳化節省每一點資源都有重要意義。**而追求價效比有很多方法，其中最直接的就是資源隔離技術。**

經過數十年的發展，當前的作業系統都已具備支援多使用者，支援 Docker（虛擬化應用容器）的能力，基於 Docker 的 Kubernetes 已經成為業務部署的事實標準。而資料庫也有多租戶和混合負載的場景需求，比如很多業務把歷史庫和線上庫分開，在歷史庫上執行分析，不僅增加了運維複雜性，也導致 AP 的實時性不夠，無法在有限的硬體資源下實現 TP 和 AP 的動態平衡，未來隨著資料庫的部署例項繼續增加，解決這一問題的價值收益會越來越明顯。

**資源隔離的需求本質來自於負載的差異分組，只要能分組，自然就產生了某種隔離的需求。** 負載的分組：如備份任務和前臺 SQL 任務，兩者存在時效性的差異，OLTP 和 OLAP 對資源的使用方式不同，也會產生分組。只要一個軟體系統要對服務的物件作區別對待，那就自然會產生分組和 QoS（Quality of Service，服務質量）的概念，也就有了資源隔離的需求。

資源隔離對資料庫穩定執行至關重要。這有兩種典型情況：**一是為資料庫內部重要的任務預留資源，避免出現使用者負載高導致資料庫自身垮掉的情況；另一種是使用者原來就有 QoS 要求不同的業務混在一個庫裡，** 比如實時性高的 OLTP 業務，加上少量的重要性低一些的後臺任務，如果使用者願意把這些資訊告訴 DB ，資料庫就可以更穩定地執行。

第二種情況的典型例子就是 OLAP 和 OLTP 兩種負載的隔離。傳統資料庫為了避免 OLTP 和 OLAP 業務間產生干擾，需要配置較多硬體資源分配給不同業務，這樣就會出現資源利用率低的現象。我們可以透過引入 consolidation（資料整合）的概念來解決這一問題，consolidation 透過把原有的多套資料庫聚合到一個物理庫，可以在減少硬體成本的同時降低運維複雜性。

從 OLTP 和 OLAP 兩個庫進化到 HTAP 一個庫，這一進化過程就可以理解為 consolidation 。我們知道作業系統早已實現多使用者和 Docker 的能力，資料庫是否也會隨著技術發展出現共享物力資源的需求呢？我們認為，隨著技術進步和資料庫部署規模繼續變大，邏輯資源隔離的應用場景會越來越多。同時，現實中原本就有不少使用者在一個庫中既服務 OLTP 負載，也執行一些簡單的 OLAP，只是受限於 OLAP 和資源隔離的的能力，限制較多。

比如一個電商的老闆想知道當天賣得最好的商品是什麼。那就需要在線上庫上執行分析，但主流資料庫缺少資源隔離能力，分析類 SQL 可能影響線上交易，為了保證線上交易的穩定性，就需要對資料庫擴容，用更多的物理資源換業務穩定性，即使這樣，也需要對分析類 SQL 做嚴格 review，防止這些 SQL 無限制佔用資源。

### 物理&邏輯隔離，哪個是更優選擇？

資源隔離並不是一個新概念，傳統方式下不共享物理資源，可以理解為物理資源隔離方案。這種方案下不同租戶或同一租戶內 OLAP 和 OLTP 使用不同的副本，行存副本服務 OLTP，列存副本服務 OLAP，兩種業務不共享物理資源。如果不考慮成本，物理資源隔離無疑是更好的選擇。

但現實中，大部分客戶都會考慮硬體成本及其資源利用率。一方面，資料庫硬體的購買和維護成本高昂，而所有硬體都需要定期換新；另一方面，資料庫硬體在進行單項業務處理時，平均佔用率水平較低。如果不能充分利用硬體資源，無疑會造成巨大的資源浪費。

**而要充分利用硬體資源，不同租戶或同一租戶內 OLAP 和 OLTP 共享物理資源的邏輯資源隔離方案，自然脫穎而出。** 同時我們認為，物理資源隔離和邏輯資源隔離不是二選一，而是互為補充的關係。但考量到資源共享可能出現的干擾問題，一些人認為資源共享會導致 QoS 無法保證，因此對使用者價值不大；另一些人也會關注完美的資源隔離是否能實現，如果實現方案過於複雜是否會得不償失等問題。

面對上述問題，我們認為一方面要放棄完美主義，認識到基礎的資源隔離能力對客戶的明顯價值；另一方面要用發展的眼光看問題，瞭解到邏輯資源隔離技術在持續進步。

**因此，適合 HTAP 的資源隔離並不是物理資源隔離或邏輯資源隔離中二選一，理想的資源隔離方案是在完全物理隔離和完全共享中找到平衡點。** 基礎軟體應該給使用者更多自由，幫助使用者在面對各類場景下都可以做出最合適的選擇，資料庫產品有必要同時提供物理隔離、邏輯隔離各級別的資源隔離能力。

## 如何實現適合HTAP的資源隔離？

我們在實施資源隔離前，要先解決兩個問題：

定義資源組，以及資源組的 QoS，對資料庫來說租戶就是最常見的資源組，另外 AP 和 TP 也可以是兩個不同的資源組；

按定義好的 QoS 制定實施資源隔離的策略。

我們先看 DBA（資料庫管理員）的控制介面，然後再分析要對哪些資源做隔離（一般選擇對業務影響最大的資源），最後會以 CPU 時間、IOPS 和網路頻寬為例講述 OceanBase 的隔離方案。

### 定義資源組，做好 OLTP 和 OLAP 的資源規劃

OceanBase 的目標是實現在不同租戶間的資源隔離，以及租戶內 OLTP 和 OLAP 業務的資源隔離。

怎樣描述租戶的資源要求？OceanBase 內部是透過 unit config 實現的，比如建立一個租戶之前要建立 resource pool（資源池） 、resource pool 的規格描述裡就指定了各種資源的限制。對這個概念不太瞭解的可以參考 [OceanBase 的 DBA 手冊](https://www.oceanbase.com/docs/community/observer-cn/V3.1.3/0000000000162749)叢集和多租戶管理這一章。

```
create resource unit box1 max_cpu 4, max_memory 21474836480, max_iops 128, max_disk_size '5G', max_session_num 64, min_cpu=4, min_memory=21474836480, min_iops=128;
```

怎樣描述租戶內 OLTP 和 OLAP 需要的資源規格？OceanBase 參考了 Oracle 經典的 Resource Manager 系統包提供的管理介面。我們觀察到，很多客戶的跑批業務會安排在業務低峰期，如午夜或者凌晨，此時不用過於擔心 OLAP 會影響到 OLTP 類業務，我們可以把叢集絕大部分資源分配給 OLAP 類業務，給 OLTP 留下最小資源保證即可。在白天的業務高峰期，透過調整資源隔離方案，可以確保 OLTP 業務資源充足，同時按照預設資源滿足基本的 AP 類查詢。**在 OceanBase 裡，我們只需要預設兩套資源管理計劃，白天啟用 DAYTIME 計劃，夜間啟用 NIGHT 計劃，就可以實現滿足基本的隔離需求的同時實現資源利用率的最大化。**

![](https://img.alicdn.com/imgextra/i1/O1CN01sX2X4N1mDrohNoWpC_!!6000000004921-2-tps-707-378.png)

比如我們可以用以下語法定義一個白天資源使用計劃（resource plan),並且制定了此計劃下 OLTP (interactive_group）和 OLAP (batch_group) 的資源百分比。80% 的資源用於 TP，剩下 20% 資源用於 AP。

```
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN    => 'DAYTIME',
   COMMENT => 'More resources for OLTP applications');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'interactive_group',
   COMMENT          => 'OLTP group',
   MGMT_P1          => 80,
   UTILIZATION_LIMIT => 100);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
   PLAN             => 'DAYTIME',
   GROUP_OR_SUBPLAN => 'batch_group',
   COMMENT          => 'OLAP group',
   MGMT_P1          => 20,
   UTILIZATION_LIMIT => 20);
```

定義好 資源使用計劃後，可以用以下方式啟用它：

```
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME';
```

按照類似的方式，我們可以定義夜晚的資源使用計劃，並在業務低峰期啟用它。

OceanBase 現在提供了按登入使用者對 SQL 分類的方法，客戶可以建立一個新使用者用於執行 分析 SQL，只要是該使用者發起的 SQL，都會被判定為是 AP 負載，這樣分類簡單有效。同時，OceanBase 會把執行時間超過 5s 的請求識別為當作大查詢，大查詢會被降低優先順序。

### min, max, weight，滿足 QoS 根本訴求的三重定義

QoS（Quality of Service，服務質量）作為一種安全機制，可以在資源過載時保障關鍵程式的平穩執行。以下我們透過權重分配、資源上限和保留資源來描述 QoS。

在不同的時間段，業務的流量會有波動，所以 QoS 描述需要有一定的彈性，如果像公有云上的 ECS 一樣指定一個固定的 CPU 核數和 IO 頻寬，在業務高峰的時候容易出現資料庫容量不夠而導致的故障。

我們假設這樣一個場景：總頻寬是 100M，由租戶 A 和租戶 B 共同使用，基於資源的閒時共享和忙時隔離原則，我們嘗試讓租戶 A 和租戶 B 互不干擾地共同使用總頻寬。

如果兩者的重要程度不同，怎樣保證重要程式的優先執行？此時我們可以每個租戶的重要程度分配使用資源的比例，如給租戶 A 和租戶 B 分配 1:3 的權重比，當這兩個租戶都需要 CPU 時，A 將得到 1 份 CPU 時間，B 將得到 3 份 CPU 時間。這一操作我們稱為權重分配，或<weight>。

有時候物理資源較為充裕，低權重租戶可能會佔用大量並不需要的資源，如何限制它的使用呢？我們可以在權重分配的基礎上給不同的租戶定義資源上限<max>，如租戶 A 按照權重比 1/4 時，能使用的頻寬最多為 25M，當給它設定資源上限引數 20M 後，它最多能使用 20M 的頻寬。

租戶數量增減會引發權重配比改變，如何直觀判斷各租戶最低資源需求的滿足情況？此時我們可以給各租戶設定保留資源<min>，這樣不僅可以保證所有租戶基本功能的執行，也能直觀清晰地描述 QoS。

### 我們希望把更完美的資源隔離，做進 OceanBase 資料庫

資源按照使用情況有剛性和彈性的區別，資源隔離的物件通常是彈性資源。剛性資源是保障程式完成功能必須的資源，一旦被佔用，短時間內也難以釋放。剛性資源的典型是磁碟空間和記憶體空間，連線數等，這類資源做好靜態規劃後，每個組可以使用的資源數量就會固定下來。彈性資源是指和程式功能無關，但是和效能有關的資源，比如 IOPS、CPU 時間、網路頻寬等，這類資源一般可以搶佔或被迅速釋放，因此資源排程策略可以介入，實現閒時共享，忙時隔離。我們需要關注的正是彈性資源的共享機制。

剛性資源比較重要的是記憶體和磁碟空間，彈性資源比較重要的是 CPU 時間，IOPS 和網路頻寬，OceanBase 會優先把這些資源的隔離做好。

#### CPU 隔離

OceanBase 目前已實現 CPU 時間的隔離，未來會加入 CPU cache 的隔離。CPU 隔離有一個特點，那就是隻有在核心態才能做得比較實時，因為一個資源要能排程，前提是要能切分成很多小片，網路 IO 天然就是一個一個的 packet，磁碟 IO 也類似。CPU 時間被作業系統切分成了很多片，但是這個時間片對使用者態是透明的，使用者態無法介入時間片排程。使用者態要排程，那就需要在程式碼中插入很多檢查點，透過檢查點把使用者執行緒的 CPU 時間切分成很多段，同時在檢查點執行排程策略。使用者態插入檢查點切分效果無法保證，如何在一個靜態庫函式里插入檢查點呢？

OceanBase 選擇了核心態解決方案，即 cgroup 的 cpu controller，cgroup 目前能支援 <max>，但不支援 min。這對我們來說不構成問題，因為 CPU 總時間不會波動，按照 weight 分配就可以保證每個組的保留時間片的要求。

CPU 隔離不僅可以隔離使用者負載，也可以隔離系統內部的不同任務。比如對 OBServer 來說，多副本的 leader 選舉是一個高優先順序任務，我們不希望使用者 SQL 把 CPU 打滿最後影響到選舉。我們在 cgroup 的頂層把選舉和使用者 SQL 分到兩個目錄，在使用者 SQL 的目錄進一步分目錄，對應租戶和租戶內的使用者。

#### IOPS 隔離

對於 SSD 磁碟，頻寬可以透過 IOPS 來等價描述（bandwidth = size * iops）。其次不同大小的 IO，我們根據經驗公式可以歸一化，我們設定一次 IO 的標準大小是 16K，那麼一次 2M 的 IO 就可以等價為多次 16K 的 IO。IOPS 隔離要區分裝置，但是把裝置暴露出來會讓配置比較複雜，所以大部分情況下可以讓多個裝置共用一套配置。

OceanBase 從 VMware 用於隔離虛擬機器 IO 的一篇論文《mClock: Handling Throughput Variability for Hypervisor IO Scheduling》中獲得啟發。

在公有云上部署的時候，我們發現雲盤的 IO 能力是會有波動的，OceanBase 可以快速適應雲盤 IO 能力的下降，保障最重要的 TP 業務不受損。同時 OceanBase 的 IO 隔離會和資料庫的塊快取一起聯動，OceanBase 不僅會限制 AP 的 IO 頻寬，還會限制 AP 的快取使用，這樣就能避免 AP 汙染塊快取，最終保障 TP 的低延遲。

#### 網路頻寬隔離

我們可以把 OBServer 之間的 RPC 分為機房內通訊和機房間通訊：前者主要是 SQL 分散式執行以及兩階段提交引起的，後者主要是為了高可用而做的日誌複製和資料備份。不同於機房內通訊，對於機房間通訊的來說，一個機器到不同的機房的延遲和可用頻寬都是不一樣的，通常機房間頻寬是共享資源，所以頻寬的分配和限制需全域性考慮才有意義。關鍵問題就在於全域性的範圍是什麼？比如有多套 OceanBase 叢集，是否要協同考慮；就算只有一套 OceanBase 叢集，如果出現網路分割槽怎麼辦？我們怎麼才能確保拿到全域性檢視？

OceanBase 從 3.2 版本開始支援 region 級別的頻寬控制，接下來，我們的思路是多套 OceanBase 叢集之間不做協調，需要 DBA 靜態劃分資源，也就是要給每個叢集設定機房和機房間的可用頻寬， OceanBase 在叢集內部把頻寬動態分到每個 OBServer，每個 OBServer 內進一步把頻寬按優先順序分給不同的組。

對大部分業務來說，機房內的網路頻寬分配更為關鍵，頻寬的隔離和 IOPS 隔離是非常像的。不過由於通訊目的端眾多，一般不區別通訊目的端，演算法實施的時候把網路卡當作一個 IO 裝置，而不是把通訊目的端當作一個裝置。

網路頻寬隔離問題可以分解為兩部分：首先要對流量分組，或者說打標籤；其次要按設定的要求對打好標籤的流量做隔離。其中第一步只能由應用邏輯提供，第二步可以在應用層解決，或者在核心層面解決。因為 linux 下 tc 提供了非常豐富的限速和優先順序策略，所以 OceanBase 選擇應用層打標，核心態限速的方案。複用核心的能力，同時也是在複用核心的生態，使用者不再需要學習一套新的限速機制。

## OceanBase資源隔離的實現效果

OceanBase 目前實現了記憶體隔離、磁碟空間隔離、CPU 隔離以及 IOPS 隔離，未來還將支援網路頻寬隔離，下文我們會以 CPU 隔離為例，對 OceanBase 資源隔離實現效果進行測試。

在介紹定義資源組的方法時，我們提到可以建一個特殊使用者專門來服務 AP。在本次實驗中，先建立兩個測試使用者：AP@ORACLE 和 TP@ORACLE。我們把 AP 任務繫結到 AP_GROUP，TP 任務繫結到 TP_GROUP。假設這個業務白天的時候 TP 負載高，AP 集中在晚上。**因此我們為白天和晚上設定兩個不同的資源使用計劃，白天的時候我們希望 80% 的資源用於 TP，剩下 20% 資源用於 AP，夜晚的時候希望 50% 的資源用於 TP，剩下 50% 資源用於 TP。**

### 從白天計劃切換到夜晚計劃

從結果上可以看出來，切換為夜晚計劃後，AP 的 CPU 資源佔比變大後，AP 的 QPS 明顯變高，TP 的 QPS 有一些降低。下圖中 AP 和 TP QPS 傳送變化的點就是切換資源使用計劃的時間。

![](https://img.alicdn.com/imgextra/i4/O1CN01Hx9MbT1mhdYvH094d_!!6000000004986-2-tps-1080-521.png)

看起來 TP 的 QPS 降低比較少，和 AP 的 QPS 變化比起來不明顯。這裡要注意，按理想情況來算，TP 的 QPS 變化本來就要比 AP 的變化小，因為 AP 是從 0.3 到 0.5，增加了 66.7%, TP 從 0.7 到 0.5，降了 28.5%，然後實際算一下，TP 下降了 24.7%(19000 到 14300)，和理想值的差距不算特別大。

**CPU 隔離能否起到理想作用，和負載型別有很大關係，如果網路成為瓶頸，那就必須要加上網路頻寬隔離才能起效。** 這個實驗目的也不是為了表明 CPU  隔離就很牛，能解決很多問題，但是它表明了對 CPU bound 的負載，簡單的 CPU 隔離效果還不錯，比如目前我們還沒有考慮 CPU cache 的隔離。隔離能力的建設是個漸進的過程，單純的 CPU 隔離對 TP 加簡單 AP，或者 TP 和 TP 之間的隔離就能直接起效；適當的 IOPS 隔離和網路頻寬隔離加上之後，適應範圍就足夠廣了。

## 寫在最後

本文介紹了 OceanBase 對資源隔離技術的思考和實現方案。HTAP 資料庫要實現不同租戶間、以及同一租戶內 OLTP 和 OLAP 業務的硬體資源共享，對資源隔離提出了很高的要求，我們認為更適合 HTAP 資料庫的資源隔離方案是物理隔離、邏輯隔離兩者互補的方案。展望未來，OceanBase 的資源隔離技術也會不斷演進和完善，更好地滿足使用者對資源隔離的需求。

</max></min></max></weight>

為什麼資源隔離對HTAP至關重要？

相關文章