海量數據分析更快、更穩、更准。GaussDB(for MySQL) HTAP只讀分析特性詳解
本文作者康祥，華為雲數據庫內核開發工程師，研究生階段主要從事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只讀分析會繼續為用戶提供海量數據的高效解決方案，助力企業數字化轉型。
本文由華為雲發佈。
