乐趣区

关于程序员:海量数据分析更快更稳更准GaussDBfor-MySQL-HTAP只读分析特性详解

jiezi

本文作者康祥，华为云数据库内核开发工程师，研究生阶段次要从事 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 只读剖析会持续为用户提供海量数据的高效解决方案，助力企业数字化转型。注：该性能目前在邀请测试阶段，想体验的小伙伴们欢送评论区留言！

本文由华为云公布

退出移动版