摘要：除了擁有 ClickHouse 本身的極致性能外，GaussDB(for MySQL)的HTAP只讀分析在 MaterilizeMySQL引擎的性能和穩定性等方面具有更優秀的表現，為提供更快更准的數據分析保駕護航。
引言
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引擎的性能和穩定性等方面具有更優秀的表現，為提供更快更准的數據分析保駕護航。
背景
大數據時代的到來，數據量急劇增長的同時用戶結構也越來越多樣化，這些用戶處理數據時發現，僅僅是創建一個可視化報表需要經過數據的抽取 (Extract), 轉換 (Transform) 和裝載 (Load), 整個周期可能長達數日甚至數周。事實上，ETL 模式的優點在於能夠結合數據湖等處理多源數據，低成本處理海量數據且生態較完善，當然缺點也十分明顯，傳統的數據倉庫和數據湖等無法支持大量實時並發的更新，數據分析時效性較低。除此之外，ETL 模式應對變化的能力也相對較弱，如上游數據源發生變化（例如表結構的變化等），整個數據鏈的處理過程都需要做相應的修改，增加了數據維護的難度。
如何追求實時分析呢？答案是 HTAP。HTAP 可以支持大量並發的更新且數據同步時延通常在在秒級或毫秒級，有效避免傳統解決方案中數據抽取，轉換和裝載等繁瑣步驟，極大提升數據處理的時效性。
極致性能-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.
巨人肩膀上的 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：
MaterializeMySQL 引擎當前不提供 MySQL 數據的事務一致性視圖，數據行以批量插入的方式同步到 ClickHouse 中，引擎底層使用的是 ReplacingMergeTree。如果數據發生了修改，獲取最新的數據時需要指定 FINAL（類似於 GROUP BY）去重，並使用過濾器隱藏已刪除的行。然而當數據規模很大時，FINAL 操作的性能往往不太理想。
為了感知事務，GaussDB(for MySQL) HTAP只讀分析實現了事務一致性並提供四種隔離級別，用戶可以根據具體使用場景選擇不同的隔離級別。此外，GaussDB(for MySQL) HTAP只讀分析還提供了快照功能，優化 FINAL 帶來的查詢性能問題。
FINAL 性能優化
前面提到 MaterializeMySQL 底層使用的是 ReplacingMergeTree，該引擎后台會按照一定規則執行 Merge 操作，用戶想要獲得最新數據則必須通過 FINAL 操作去重。除了采用 MVCC + Snapshot 機制保障查詢性能外，GaussDB(for MySQL) HTAP只讀分析從索引以及過濾策略等方面對 ReplacingMergeTree 引擎本身的 FINAL 操作進行了優化，即使不依賴 MVCC + Snapshot 也能提供不錯的查詢性能。
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只讀分析更加穩定，更容易幫助用戶發覺潛在問題的根源。
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 引擎用戶提供了如下操作：
表定義重寫 Override
為了提供個性化的建庫同步操作，GaussDB(for MySQL) HTAP只讀分析為 MaterializeMySQL 引擎增加了 Over Write 功能，用戶可以覆蓋指定表的列並添加新列，添加索引並覆蓋 PARTITION BY 或 SAMPLE 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只讀分析針對這個問題設計了黑/白名單的過濾，允許用戶自定義需要復制的表，這在生產應用是十分有意義的，用法參考如下：
場景示例
前文分析了許多 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 分層存儲方案，將熱數據溫數據和冷數據分別存在不同的存儲介質中，進一步降低存儲成本。
小結
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
注：該功能目前在邀請測試階段，想體驗的小伙伴們歡迎評論區留言！