本文作者康祥，華為云資料庫內核開發工程師，研究生階段主要從事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只讀分析會繼續為用戶提供海量資料的高效解決方案，助力企業數字化轉型，
本文由華為云發布，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/448134.html
標籤：其他
上一篇：Java基礎——例外