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

48次阅读

共计 6674 个字符,预计需要花费 17 分钟才能阅读完成。

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

本文由华为云公布

正文完
 0