海量數據分析更快、更穩、更準！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)?并發處理數據，恰恰彌補了?Row Store?存儲方式的缺陷，尤其在大寬表（屬性很多）的時候，查詢效率明顯提升。此外，列存方式相鄰數據類型相同，因此天然適合數據壓縮，從而達到極致的數據壓縮比。

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; md RAID-5 on 8 6TB SATA HDD; ext4.

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

盡管?ClickHouse?擁有如此極致的性能，但實踐生產過程中仍然面臨一些困境。比如存在數據類型不支持，全量復制性能問題等方面的挑戰。此外也有一些與引擎本身設計有關的性能問題：比如?FINAL?去重導致的查詢性能問題等，給用戶使用過程帶來一些不好的體驗。

全量并行復制

MaterializeMySQL?引擎通過消費?BinLog?的方式來訂閱?MySQL?數據。數據同步過程分為三個步驟，首先是檢驗源端?MySQL?參數是否符合規范，然后是全量和增量復制階段。ClickHouse?數據同步的全量復制過程是單線程的，在數據量較大時復制時延較高。GaussDB(for MySQL) 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 字段 )

MaterializeMySQL?引擎當前不提供?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.huaweicloud.com/product/gaussdb_mysql.html

注：該功能目前在邀請測試階段，想體驗的小伙伴們歡迎評論區留言！

MySQL 數據倉庫服務 GaussDB(DWS) 數據挖掘

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。