海量資料分析更快、更穩、更準!GaussDB(for MySQL) HTAP只讀分析特性詳解

語言: CN / TW / HK

本文作者康祥,華為雲資料庫核心開發工程師,研究生階段主要從事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只讀分析會繼續為使用者提供海量資料的高效解決方案,助力企業數字化轉型。

注:該功能目前在邀請測試階段,想體驗的小夥伴們歡迎評論區留言!

點選“ 閱讀原文 ”,瞭解更多

「其他文章」