本文作者康祥，華為雲資料庫核心開發工程師，研究生階段主要從事SPARQL查詢優化相關工作。目前在華為公司參與華為雲GaussDB(for MySQL) HTAP只讀核心功能設計和研發。

1. 引言

HTAP（Hybrid Transactional/Analytical Processing）這個詞相信大家最近經常會聽到，它能夠同時支撐線上事務處理(On-Line Transactional Processing, 簡稱OLTP) 和線上資料分析 (On-Line Analytical Processing, 簡稱 OLAP)。令人驚喜的是，ClickHouse 作為近年來炙手可熱的大資料分析系統可以通過MaterializeMySQL 引擎掛載為 MySQL 的從庫，作為 MySQL 的 "協處理器"面向 OLAP 場景提供高效資料分析能力，這對解決異構資料庫之間資料共享問題提供了新的途徑。我們可以充分發揮 ClickHouse 的分析效能，結合 TP 類引擎如 MySQL 等提供 HTAP 能力。然而實際應用場景中 ClickHouse 仍然面臨一些挑戰，因此 GaussDB(for MySQL)的HTAP只讀分析應運而生，除了擁有 ClickHouse 本身的極致效能外，GaussDB(for MySQL)的HTAP只讀分析在 MaterilizeMySQL引擎的效能和穩定性等方面具有更優秀的表現，為提供更快更準的資料分析保駕護航。

2. 背景

大資料時代的到來，資料量急劇增長的同時使用者結構也越來越多樣化，這些使用者處理資料時發現，僅僅是建立一個視覺化報表需要經過資料的抽取 (Extract), 轉換 (Transform) 和裝載 (Load), 整個週期可能長達數日甚至數週。事實上，ETL 模式的優點在於能夠結合資料湖等處理多源資料，低成本處理海量資料且生態較完善，當然缺點也十分明顯，傳統的資料倉庫和資料湖等無法支援大量實時併發的更新，資料分析時效性較低。除此之外，ETL 模式應對變化的能力也相對較弱，如上游資料來源發生變化（例如表結構的變化等），整個資料鏈的處理過程都需要做相應的修改，增加了資料維護的難度。

如何追求實時分析呢？答案是 HTAP。HTAP 可以支援大量併發的更新且資料同步時延通常在在秒級或毫秒級，有效避免傳統解決方案中資料抽取，轉換和裝載等繁瑣步驟，極大提升資料處理的時效性。

3.極致效能-ClickHouse

• ClickHouse

ClickHouse 是 Yandex 公司開源的面向 OLAP 的分散式列式資料庫，具有實時查詢、完備的DBMS、高效資料壓縮壓縮，支援批量更新及高可用等特性。此外，ClickHouse 擁有非常完善的SQL支援以及開箱即用等許多特點。在官方公佈的基準測試對比中，ClickHouse 遙遙領先對手。

• Row Store & Column Store

MySQL 儲存採用的 Row Store，表中資料按照 Row 為邏輯儲存單元在儲存介質中連續儲存。這種儲存方式適合隨機的增刪改查操作，對於按行查詢較為友好。但如果選擇查詢的目標只涉及一行中少數幾個屬性，Row 儲存方式也不得不將所有行全部遍歷再篩選出目標屬性，當資料表很寬（表的屬性很多）時，查詢效率通常較低。儘管索引等優化方案在 OLTP 應用場景中能夠提升一定效率，但是在面對海量資料背景的 OLAP 場景仍然顯得有些力不從心。

ClickHouse 則採用的是 Column Store，表中資料按照 Column 為邏輯儲存單元在儲存介質中連續儲存。這種儲存方式適合採用 SIMD(Single Instruction Multiple Data) 併發處理資料，恰恰彌補了 RowStore 儲存方式的缺陷，尤其在大寬表（屬性很多）的時候，查詢效率明顯提升。此外，列存方式相鄰資料型別相同，因此天然適合資料壓縮，從而達到極致的資料壓縮比。

• Performance

下表是 Yandex 公司官方公佈的效能測試資料，資料集 100 million，從上至下的三條資料分別表示：Cold Cache，Second Round，Third Round 的查詢響應時間，可以看出 ClickHouse 的效能遙遙領先各大資料庫引擎，相比於MySQL而言，效能甚至高達600多倍。

注：以下實驗資料均為單節點：2 * Intel (R) Xeon (R) CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; mdRAID-5 on 8 6TB SATA HDD; ext4.

4. 巨人肩膀上的 GaussDB(for MySQL) HTAP只讀分析

儘管 ClickHouse 擁有如此極致的效能，但實踐生產過程中仍然面臨一些困境。比如存在資料型別不支援，全量複製效能問題等方面的挑戰。此外也有一些與引擎本身設計有關的效能問題：比如 FINAL 去重導致的查詢效能問題等，給使用者使用過程帶來一些不好的體驗。

• 全量並行複製

Materialize MySQL 引擎通過消費 BinLog 的方式來訂閱 MySQL 資料。資料同步過程分為三個步驟，首先是檢驗源端 MySQL 引數是否符合規範，然後是全量和增量複製階段。ClickHouse 資料同步的全量複製過程是單執行緒的，在資料量較大時複製時延較高。GaussDB(forMySQL) HTAP只讀分析對全量複製進行了並行化處理，優化後的複製效能平均提升 8-10 倍，對實際生產實踐是十分有意義的。

• MVCC & Snapshot

MaterializeMySQL 引擎在 DDL 轉化過程中預設增加了2個隱藏欄位：_sign (-1刪除,1插入/更新) 和 _version (資料版本)。下方是同一張表在 MySQL 和 ClickHouse 裡的 DDL：

Create Table: CREATE TABLE `runoob_tbl` (
`runoob_id` int unsigned NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`runoob_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
---------------------------------------------------------------
ATTACH TABLE _ UUID '14dbff59-930e-4aa8-9f20-ccfddaf78077'
(
`runoob_id` UInt32,
`_sign` Int8 MATERIALIZED 1, /// _sign 欄位
`_version` UInt64 MATERIALIZED 1 /// _version 欄位

Materialize MySQL 引擎當前不提供 MySQL 資料的事務一致性檢視，資料行以批量插入的方式同步到 ClickHouse 中，引擎底層使用的是 ReplacingMergeTree。如果資料發生了修改，獲取最新的資料時需要指定 FINAL（類似於 GROUP BY）去重，並使用過濾器隱藏已刪除的行。然而當資料規模很大時，FINAL 操作的效能往往不太理想。

為了感知事務，GaussDB(for MySQL) HTAP只讀分析實現了事務一致性並提供四種隔離級別，使用者可以根據具體使用場景選擇不同的隔離級別。此外，GaussDB(for MySQL) HTAP只讀分析還提供了快照功能，優化 FINAL帶來的查詢效能問題。

read_uncommitted: 不提供 MVCC 支援，可能會引入髒讀
read_committed: 提供 MVCC 支援（包括SubQuery），讀最新已 commit 的資料
query_snapshot: 規避 SELECT + FINAL 查詢中的 Merge 開銷，直接查詢快照
query_raw: 不做任何優化，返回所有資料（包括已刪除和更新的不同版本）

• FINAL 效能優化

前面提到 MaterializeMySQL 底層使用的是 ReplacingMergeTree，該引擎後臺會按照一定規則執行 Merge 操作，使用者想要獲得最新資料則必須通過 FINAL 操作去重。除了採用 MVCC + Snapshot 機制保障查詢效能外，GaussDB(for MySQL) HTAP只讀分析從索引以及過濾策略等方面對ReplacingMergeTree 引擎本身的 FINAL 操作進行了優化，即使不依賴 MVCC + Snapshot 也能提供不錯的查詢效能。

5. GaussDB(for MySQL) HTAP只讀分析相容性及穩定性

• 型別支援增強

MySQL 和 ClickHouse 的基本資料型別之間都有對應的對映關係（見下表），值得一提的是 ClickHouse 將不支援的 MySQL 資料型別都轉換為 String 型別儲存。MySQL 不支援的 ClickHouse 型別也都被轉換為 MYSQL_TYPE_STRING 型別。從下表中不難看出，ClickHouse 仍有一部分資料型別還未支援，而這部分資料型別在實際應用場景中是有可能出現的，因此 GaussDB(for MySQL) HTAP只讀分析針對常用的資料型別例如 BIT 和 TIME 以及 YEAR 等做了適配，解決部分使用者的剛要需求。

• Unique Key 同步支援

MaterializeMySQL 引擎當前僅支援含有 Primary Key 的表同步，現實生產過程中是可能存在一些表格沒有主鍵，但卻含有 Unique Key 的，因此有必要支援這種表的資料同步。GaussDB(for MySQL) HTAP只讀分析對僅含有 Unique Key (NOT NULL) 的表單獨處理，使用 Unique Key 進行分割槽。

• 優雅的複製中斷重連

實際應用過程中，全量資料複製的資料規模通常較大，同步時間較長，複製中斷（網路，MySQL服務端宕機等）的情況是有可能發生的，ClickHouse 遇到上述情況時選擇終止當前庫的同步並返回錯誤。為了提升資料同步的穩定性，GaussDB(for MySQL) HTAP只讀分析針對MaterializeMySQL 引擎設計了重連，當中斷髮生時清理現場並在一定時間間隔內進行重連。與全量複製中斷重連不同的是，增量複製中斷後不需要清理現場，這與增量複製的方式有關，增量複製基於 BinLog Event，已經增量同步成功的資料不需要重新再來一次，重新建立連線後會根據全域性 GTID 找到最新的同步點開始同步。

• 更完備的異常處理機制

GaussDB(for MySQL) HTAP只讀分析不僅引入了 MVCC +Snapshot 以及並行複製等新特性，也為核心嵌入了更完備的異常處理機制。以全量並行複製為例，GaussDB(for MySQL) HTAP只讀分析為所有並行執行緒維護獨立的異常處理資訊和堆疊。在新的異常處理機制下 GaussDB(for MySQL) HTAP只讀分析更加穩定，更容易幫助使用者發覺潛在問題的根源。

6. GaussDB(for MySQL) HTAP只讀分析個性化定製

• Show Slave Status 支援

GaussDB(for MySQL) HTAP只讀分析為使用者提供了類似 MySQL 主備間的 SHOW SLAVE STATUS 指令，通過該指令可以直觀地獲取 MaterializeMySQL 引擎同步的資料庫狀態。這些狀態資訊除了反應同步執行緒是否異常之外，還涵蓋了當前複製的 BinLog 位點，GITD 以及Second Behind Master 等有價值的資訊，為使用者運維提供極大方便。

• ALTER Database 支援

Alter Database 為 MaterializeMySQL 引擎使用者提供瞭如下操作：

ALTER DATABASE db MODIFY SETTING ... // 修改庫級 settings
ALTER DATABASE db ADD TABLE OVERRIDE tbl ... // ADD TABLE 且支援 Override
ALTER DATABASE db MODIFY TABLE OVERRIDE tbl ... // MODIFY TABLE 且支援 Override
ALTER DATABASE db DROP TABLE ...

• 表定義重寫 Override

為了提供個性化的建庫同步操作，GaussDB(for MySQL) HTAP只讀分析為 MaterializeMySQL 引擎增加了 Over Write 功能，使用者可以覆蓋指定表的列並新增新列，新增索引並覆蓋PARTITION BY 或 SAMPLE BY 欄位，使用示例如下：

CREATE DATABASE test
ENGINE=MaterializeMySQL('host:port', 'db', 'user', 'pw')
TABLE OVERRIDE table1 (
_staged UInt8 MATERIALIZED 1 // 增加 MATERIALIZED 列，型別為 UInt8
)
PARTITION BY (...) // 覆蓋分割槽欄位

• 適配 MySQL Partition

資料分割槽是提升資料庫使用效能的重要途徑之一，ClickHouse的分割槽策略是優先考慮日期，否則會選擇型別長度較小的欄位做雜湊處理並進行分割槽。可以看到，ClickHouse 的分割槽策略和 MySQL 有一定區別，為了儘可能的支援 MySQL 的分割槽策略，GaussDB(for MySQL) HTAP只讀分析目前支援 Range 分割槽，如果建表語句裡沒有 Range 分割槽，則使用 ClickHouse 預設的分割槽策略。

• 黑/白名單過濾

MaterializeMySQL 引擎建立的資料同步是庫級的，意味著預設情況下會嘗試將該庫所有表全部複製，在某些實際應用場景中往往不需要複製全部的表，或者說有些表本身不適合複製（例如沒有 Primary Key 或者 NOT NULL 的 Unique Key），GaussDB(for MySQL) HTAP只讀分析不希望因為部分表無法複製導致整個庫的複製失敗，而是能夠有選擇的進行復制。GaussDB(for MySQL) HTAP只讀分析針對這個問題設計了黑/白名單的過濾，允許使用者自定義需要複製的表，這在生產應用是十分有意義的，用法參考如下：

CREATE DATABASE test
ENGINE = MaterializeMySQL('host:port', 'db', 'user', 'pw')
SETTINGS black_list='T1,T2' // 將T1、T2加入黑名單

7. 場景示例

前文分析了許多 GaussDB(for MySQL) HTAP只讀分析的優點，那 GaussDB(for MySQL) HTAP只讀分析到底能提供什麼樣的解決方案，為使用者解決資料難題呢？

上圖以 MySQL + GaussDB(for MySQL) HTAP只讀分析為例，使用者既能得到 MySQL 完備的事務保障，又能享受到 GaussDB(for MySQL) HTAP只讀分析的極致分析效能。使用者從不同渠道獲取資料並載入到 MySQL 引擎，GaussDB(for MySQL) HTAP只讀分析作為 MySQL 的 “從庫” 實時同步使用者資料並提供高效的資料分析能力。

• 高實效性

與傳統 ETL(T + 1)方案不同，GaussDB(for MySQL) HTAP只讀分析搭配 MySQL 的 HTAP 解決方案能夠提供秒級資料同步。

• 資料壓縮

GaussDB(for MySQL) HTAP只讀分析底層儲存採取 Column Store，這種儲存形式天然適合資料壓縮，因此GaussDB(for MySQL) HTAP只讀分析擁有極致的資料壓縮比，同等條件下能夠為使用者節約大量儲存成本。

• 歷史備份

相比在 MySQL 中備份，GaussDB(for MySQL) HTAP只讀分析的儲存成本更低，某些場景下更適合用於歷史資料備份。

• 儲存分層

為了進一步降低使用者儲存成本，GaussDB(for MySQL) HTAP只讀分析提供 ESSD + EVS + OBS 分層儲存方案，將熱資料溫資料和冷資料分別存在不同的儲存介質中，進一步降低儲存成本。

8. 小結

HTAP雖然不是一個非常新的概念，但隨著現階段資料業務越來越模糊（AP業務TP化 ，TP業務AP化），這個概念又重新回到了人們的視線。使用者對資料處理和消費需求的不斷迭代和升級，也為 HTAP 的發展創造了更多機會。GaussDB(for MySQL) HTAP只讀分析站在 ClickHouse 極致效能的肩膀上針對實際生產遇到的問題做了一系列優化，獲得更快更好的使用體驗。相信未來 HTAP 的競爭會愈演愈烈，這對 GaussDB(for MySQL) HTAP只讀分析來說既是挑戰也是機會，GaussDB(for MySQL) HTAP只讀分析會繼續為使用者提供海量資料的高效解決方案，助力企業數字化轉型。

本文由華為雲釋出。