最佳实践—如何分析数据分布不均衡

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介: 本文将介绍如何分析和处理数据倾斜的问题。

概述

PolarDB-X是由阿里巴巴自主研发的云原生分布式数据库,在物理资源上是由多个节点所组成的分布式集群。通过数据分区的方式,可以将数据分布到集群中的多个存储节点,发挥多个节点的存储和计算能力。

当存储节点的数据分布不均匀,大部分数据集中在一两个节点时,将导致节点负载过高、查询缓慢,甚至造成节点故障,这种现象称之为数据倾斜。这类问题无法通过扩容来解决,本文将介绍如何分析和处理数据倾斜的问题。9..png

问题分析

数据倾斜问题可以按照分库级、分表级、分区级的思路由浅入深进行分析排查。

分库级数据倾斜

执行show db status 语句,能够显示当前数据库中的所有物理库的数据大小,部分参数说明如下:

  • PHYSICAL_DB:物理库名
  • SIZE_IN_MB :数据大小
  • RATIO :数据比例

示例:


MySQL polardbx_root@127.1:test_polarx> show db status;
+----+---------------------------+--------------------+---------------------------+------------+--------+----------------+
| ID | NAME                      | CONNECTION_STRING  | PHYSICAL_DB               | SIZE_IN_MB | RATIO  | THREAD_RUNNING |
+----+---------------------------+--------------------+---------------------------+------------+--------+----------------+
| 1  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | TOTAL                     |  0.875     | 100%   | 1              |
| 2  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | hehe_000000               |  0.203125  | 23.21% |                |
| 3  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | hehe_000001               |  0.203125  | 23.21% |                |
| 4  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | hehe_000002               |  0.203125  | 23.21% |                |
| 5  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | hehe_000003               |  0.203125  | 23.21% |                |
| 6  | hehe@polardbx-polardbx    | 100.82.20.151:3306 | hehe_single               |  0.0625    | 7.14%  |                |
+----+---------------------------+--------------------+---------------------------+------------+--------+----------------+
6 rows in set

在数据倾斜的情况下,多个物理库的“SIZE_IN_MB"和"RATIO”会相差较大。对于其中数据量较多的分库,可以通过分表级的信息进一步分析。

分表级数据倾斜

执行show table status语句,查看当前库的所有数据表大小。部分参数说明如下:

  • ROWS : 近似的数据行数
  • DATA_LENGTH: 近似的数据量


MySQL polardbx@127.1:test_polarx> show table status;

+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
| NAME | ENGINE | VERSION | ROW_FORMAT | ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME | UPDATE_TIME | CHECK_TIME | COLLATION | CHECKSUM | CREATE_OPTIONS | COMMENT |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
| test_tb | InnoDB | 10 | Dynamic | 0 | 0 | 131072 | 0 | 131072 | 0 | 100000 | 2021-08-19 07:40:07 | <null> | <null> | utf8mb4_general_ci | <null> | | |
| test_tb1 | InnoDB | 10 | Dynamic | 0 | 0 | 65536 | 0 | 65536 | 0 | 100000 | 2021-08-19 07:52:24 | <null> | <null> | utf8mb4_general_ci | <null> | | |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+
2 rows in set

执行show table info from $TABLE语句,查看分表级的数据大小,示例如下:


MySQL polardbx@127.1:test_polarx> show create table test_tb\G
[ 1. row ]**
Table | test_tb
Create Table | CREATE TABLE `test_tb` (
`id` int(11) DEFAULT NULL,
`c1` bigint(20) DEFAULT NULL,
`c2` varchar(100) DEFAULT NULL,
KEY `auto_shard_key_id` USING BTREE (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 2
MySQL polardbx@127.1:test_polarx> show table info from test_tb;
+----+--------------------+----------------+------------+
| ID | GROUP_NAME | TABLE_NAME | SIZE_IN_MB |
+----+--------------------+----------------+------------+
| 0 | test_polarx_000000 | test_tb_hg6z_0 | 0.03125 |
| 1 | test_polarx_000000 | test_tb_hg6z_1 | 0.03125 |
| 2 | test_polarx_000001 | test_tb_hg6z_2 | 0.03125 |
| 3 | test_polarx_000001 | test_tb_hg6z_3 | 0.03125 |
| 4 | test_polarx_000002 | test_tb_hg6z_4 | 0.03125 |
| 5 | test_polarx_000002 | test_tb_hg6z_5 | 0.03125 |
| 6 | test_polarx_000003 | test_tb_hg6z_6 | 0.03125 |
| 7 | test_polarx_000003 | test_tb_hg6z_7 | 0.03125 |
+----+--------------------+----------------+------------+
8 rows in set

test_tb表的拆分是dbpartition by hash(id)tbpartition by hash(id) tbpartitions 2,因此有4个分库,8个分表。以上的show table info from test_tb命令中, SIZE_IN_MB即每个分表的数据大小。

如果分表之间的数据容量相差较多,那么即发生了分表的数据倾斜,可能是由于tbpartition by的拆分不当导致的。

分区级数据倾斜

对于PolarDB-X 2.0的分区表来说,支持更灵活的数据拆分方式,即LIST/HASH/RANGE分区,以及灵活的分区分裂、合并、迁移。

对于分区表来说,同样支持通过show table info from $TABLE命令查询每个分表的物理大小。

除此之外,分区表还支持通过select * from information_schema.table_detail where logical_table='test_tb' 查询分区级的详细信息,部分参数说明如下:

  • PARTITION_NAME :分区名
  • TABLE_ROWS : 分区的数据行数
  • DATA_LENGTH :分区的数据大小
  • PERCENT :分区的数据比例


+-------------+------------------+---------------+----------------+---------------+----------------+------------+-------------+--------------+----------------------------------------------+------------------------------------+
| SCHEMA_NAME | TABLE_GROUP_NAME | LOGICAL_TABLE | PHYSICAL_TABLE | PARTITION_SEQ | PARTITION_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH | BOUND_VALUE | PERCENT |
+-------------+------------------+---------------+----------------+---------------+----------------+------------+-------------+--------------+----------------------------------------------+------------------------------------+
| partdb_test | tg73 | test_tb | test_tb_00000 | 0 | p1 | 0 | 16384 | 16384 | [MINVALUE, -6917529027641081843) | 0.00%├-------------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00001 | 1 | p2 | 1 | 16384 | 16384 | [-6917529027641081843, -4611686018427387893) | 9.09%├███-----------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00002 | 2 | p3 | 1 | 16384 | 16384 | [-4611686018427387893, -2305843009213693943) | 9.09%├███-----------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00003 | 3 | p4 | 0 | 16384 | 16384 | [-2305843009213693943, 7) | 0.00%├-------------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00004 | 4 | p5 | 6 | 16384 | 16384 | [7, 2305843009213693957) | 54.55%├██████████████------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00005 | 5 | p6 | 2 | 16384 | 16384 | [2305843009213693957, 4611686018427387907) | 18.18%├█████---------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00006 | 6 | p7 | 1 | 16384 | 16384 | [4611686018427387907, 6917529027641081857) | 9.09%├███-----------------------┤ |
| partdb_test | tg73 | test_tb | test_tb_00007 | 7 | p8 | 0 | 16384 | 16384 | [6917529027641081857, 9223372036854775807) | 0.00%├-------------------------┤ |
+-------------+------------------+---------------+----------------+---------------+----------------+------------+-------------+--------------+----------------------------------------------+------------------------------------|
8 rows in set

在以上示例中,分区p5的数据量明显多于其他分区,存在数据倾斜。

解决方案

数据倾斜通常是由于数据拆分的方式不当造成的,常见原因如下:

  • 使用了不恰当的拆分函数,例如UNI_HASH ,但拆分键不具备均匀分布的特征;
  • 拆分键的区分度过低,例如HASH分区,按照省份拆分,但省份实际较少,容易造成数据不均;
  • 某些拆分键存在较多的数据,例如订单表按照卖家id进行拆分,部分的大卖家可能存在较多的数据。

拆分方式调整

对于拆分方式选择不当导致的数据倾斜问题,通常需要调整拆分方式,包括以下两方面:

  • 调整拆分函数:分库分表可以选择HASH/UNI_HASH/STR_HASH等拆分函数;分区表可采用HASH/KEYS/RANGE/RANGE COLUMN等拆分方式;
  • 调整拆分键:
    • 选择较为均匀,不存在热点的拆分键;
    • 选择区分度较高的拆分键,避免HASH结果不均匀;
    • 大部分查询都通过拆分键做等值查询,尽量避免查询多个分片。

在选择好数据拆分方式之后,可以通过如下方法对数据表进行调整:

  • 重建表:重建另一个新的表,将旧表的数据导入。
    说明 此方法需要先停止业务写入。
  • 在线调整分区:通过变更表类型及拆分规则在线修改分区方式;无需停止业务写入,但此过程仍然需要重写全表数据,开销较大,需要在业务低峰期执行。

示例:用户发现test_tb表存在数据倾斜,原因在于数据拆分键使用不当,因此可以通过以下语句将拆分键调整成hash(order_id):


ALTER TABLE test_tb dbpartition BY hash(`order_id`);

分区调整

在PolarDB-X 2.0中,实现了更灵活的基于分区表的数据分布,因此可以实现分区级的分裂及迁移,解决数据倾斜问题。分区调整能够解决的场景主要是分区过大导致的数据倾斜,不适用于拆分函数选择不当等问题。

以Range分区举例:

  1. 建表时指定两个分区,p0和p1,其范围分别是 [-inf, 1000), [1000, 2000);
  2. 发现分区p0数据过多,存在数据倾斜,因此将分区p0进行分裂,使其分布到多个节点;
  3. 默认新建的分区会创建到数据量最少的节点上,如果不满足需求,可另外进行分区迁移。


CREATE TABLE `table_range` (
`id` int(11) DEFAULT NULL
) PARTITION BY RANGE(`id`)
(PARTITION p0 VALUES LESS THAN (1000),
PARTITION p1 VALUES LESS THAN (2000)
) / tablegroup = `tg110` / ;
ALTER TABLEGROUP tg110 SPLIT PARTITION p0 INTO
(partition p0_1 values less than (500),
partition p0_2 values less than (1000) );
相关文章
|
存储 编译器 C语言
【深入理解函数栈帧:探索函数调用的内部机制】
【深入理解函数栈帧:探索函数调用的内部机制】
379 0
|
存储 缓存 监控
安谋科技(Arm China)马闯:Arm架构下性能分析与优化介绍
2023年9月19日,系列课程第九节《Arm®架构下性能分析与优化介绍》正式上线,由安谋科技 (Arm China)主任工程师马闯主讲,内容涵盖:Arm架构下性能监控单元 (PMU) 介绍、Arm统计性能分析扩展 (SPE) 介绍、Arm性能分析工具介绍、Arm架构下性能优化案例分享,本期节目在阿里云官网、阿里云微信视频号、阿里云钉钉视频号、InfoQ官网、阿里云开发者微信视频号、阿里云创新中心直播平台 & 微信视频号同步播出,同时可以点击【https://developer.aliyun.com/topic/ecs-yitian】进入【倚天实例迁移课程官网】了解更多内容。
|
消息中间件 关系型数据库 Kafka
一种小资源情况下RDS数据实时同步StarRocks方案
使用一台4C8 G服务器轻松实现2个MySQL实例中通过负责分库分表规则之后的5000多张表的数据实时同步到StarRocks
571 67
|
人工智能 Java API
Spring AI Fluent API:与AI模型通信的流畅体验
【11月更文挑战第24天】随着人工智能(AI)技术的飞速发展,越来越多的应用场景开始融入AI技术以提升用户体验和系统效率。在Java开发中,与AI模型通信成为了一个重要而常见的需求。为了满足这一需求,Spring AI引入了ChatClient,一个提供流畅API(Fluent API)的客户端,用于与各种AI模型进行通信。本文将深入探讨ChatClient的底层原理、业务场景、概念、功能点,并通过Java代码示例展示如何使用Fluent API与AI模型进行通信。
454 0
|
分布式计算 DataWorks MaxCompute
DataWorks产品使用合集之怎么更改ODPS表的生命周期为永久
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
机器学习/深度学习 自然语言处理 搜索推荐
深度学习之分类网络
深度学习的分类网络(Classification Networks)是用于将输入数据分配到预定义类别的神经网络。它们广泛应用于图像分类、文本分类、语音识别等任务。以下是对深度学习分类网络的详细介绍,包括其基本概念、主要架构、常见模型、应用场景、优缺点及未来发展方向。
1107 4
|
Java 数据库连接 数据库
Spring Boot 集成 MyBatis-Plus 总结
Spring Boot 集成 MyBatis-Plus 总结
1435 3
|
运维 监控 负载均衡
Spring Cloud(四)《服务响应性能成功率监控 Hystrix》
Hystrix Dashboard | 断路器仪表盘,Hystrix 依赖服务一段时间窗内的请求调用情况来判断并操作断路器的链接和熔断状态保护系统快速失败服务降级,而这些请求情况的指标信息都是 HystrixCommand 和 HystrixObservableCommand 服务实例在执行过程中记录的重要指标信息,它们除了 Hystrix 断路器实现中使用之外,对于系统运维也有非常大的帮助。这些指标信息会以 “滚动时间窗” 与 “桶” 结合的方式进行汇总,并在内存中驻留一段时间,以供内部或外部进行查询使用,Hystrix Dashboard 就是这些指标内容的消费者之一。
303 0
Spring Cloud(四)《服务响应性能成功率监控 Hystrix》

热门文章

最新文章