第2.4章:StarRocks表设计--分区分桶与副本数

本文详细介绍了StarRocks的分区、分桶和副本数的概念及其作用。分区通过RANGE()设置,用于数据裁剪和管理;分桶使用HASH()进行数据打散,确保数据均匀分布;副本数用于数据冗余和容错。动态分区允许自动创建和删除,适应数据生命周期管理。此外,文章还讨论了如何合理设置分区和分桶,以及如何修改和管理这些参数。最后,提到了冷热分区策略,以优化存储成本和查询性能。

StarRocks采用Range-Hash的组合数据分布方式,也就是我们一直在提的分区分桶方式。

1分区

StarRocks中的分区是在建表时通过PARTITION BY RANGE()语句设置,用于分区的列也被称之为分区键,当前分区键仅支持日期类型和整数类型(支持一列或多列)。例如前文中表table01中“PARTITION BY RANGE(event_time)”,event_time即为分区键。若建表时我们不进行分区,StarRocks会将整个table作为一个分区(这个分区的名称和表名相同)。

StarRocks会将数据使用分区进行裁剪,例如按天分区时,每天的数据都会单独存储在一个分区内,当我们使用where查找某天的数据时,就会只去搜索对应分区的数据,减少数据扫描量。

分区的另一个目的是可以将分区作为单独的管理单元,我们可以直接为某个分区设置存储策略,比如副本数、冷热策略和存储介质等。

StarRocks支持在一个集群内使用多种存储介质(HDD/SSD)。我们就可以为分区设置不同的存储介质,比如将最新数据所在的分区放在SSD上,利用SSD的随机读写性能来提高查询性能。而老的数据可以放在HDD中,以节省数据存储的成本。

2分桶

对每个分区的数据,StarRocks还会再进行Hash分桶。我们在建表时通过DISTRIBUTED BY HASH()语句来设置分桶,用于分桶的列也被称之为分桶键。分桶键可以是一列或多列,例如前文中表table06的user_id就是分桶键。在聚合模型和更新模型\主键模型下,分桶键必需是排序键中的列。

分桶键Hash值对分桶数取模得到桶的序号(Bucket Seq),假设一个Table的分桶数为8,则共有[0, 1, 2, 3, 4, 5, 6, 7]共8个分桶(Bucket)。同一分区内,分桶键哈希值相同的数据形成(Tablet)子表。

分桶的目的就是将数据打散为一个个逻辑分片(Tablet),以Tablet作为数据均衡的最小单位,使数据尽量均匀的分布在集群的各个BE节点上,以便在查询时充分发挥集群多机多核的优势。

在StarRocks中,Partition是数据导入和备份恢复的最小逻辑单位,Tablet是数据复制和均衡的最小物理单位。表(Table)、分区(Partition)、逻辑分片(Tablet)的关系如下图:

3副本数

StarRocks中的副本数就是同一个Tablet保存的份数,在建表时通过replication_num参数指定,也可以后面修改。默认不指定时,StarRocks使用三副本建表,也即每个Tablet会在不同节点存储三份(StarRocks的副本策略会将某个tablet的副本存储在与其不同IP的节点)。

为方便理解,我们假设当前有一个3BE节点的集群,有表Table A和Table B,表A和表B建表时都未设置分区(视为一个大分区),分桶数为3,副本数replication_num为2,则表A和表B在集群中数据分布的一种可能如下图:

 

总结一下:分区是针对表的,是对表的数据取段。分桶是针对每个分区的,会将分区后的每段数据打散为逻辑分片Tablet。副本数是针对Tablet的,是指Tablet保存的份数。那么我们不难发现,对某一个数据表,若每个分区的分桶数一致,其总Tablet数:

总Tablet数=分区数*分桶数*副本数

以table01为例,我们为其设置了3个分区,为每个分区设置了20个分桶,又对分桶后的tablet设置了1副本,则table01的总tablet数=3*20*1=60个。查看table01的tablet信息,发现确实共有60个tablet:

mysql> show tablet from table01;

…………

60 rows in set (0.01 sec)

4设置规范

理清了分区分桶和副本数的概念,我们再来研究一下该如何规范的进行分区分桶。

4.1分区规范

分区键选择:当前分区键仅支持日期类型和整数类型,为了让分区能够更有效的裁剪数据,我们一般也是选取时间列作为分区键。

分区粒度选择:StarRocks的分区粒度视数据量而定,单个分区原始数据量建议维持在100G以内。

4.2分桶规范

分桶键选择:分桶的目的我们一直在说是为了将数据打散,所以分桶键就需要选择高基数的列(去重后数据量最大的列)。分桶后的数据如果出现严重的数据倾斜,就可能导致系统局部的性能瓶颈,所以我们也可以视情况使用两个或三个列作为分桶键,尽量的将数据均匀分布。我们可以show语句查看表中的数据分布情况:

mysql> show tablet from tablename;

分桶数:分桶数的设置需要适中,如果分桶过少,查询时查询并行度上不来(CPU多核优势体现不出来)。而如果分桶过多,会导致元数据压力比较大,数据导入导出时也会受到一些影响。

分桶数的设置通常也建议以数据量为参考,从经验来看,每个分桶的原始数据建议不要超过5个G,考虑到压缩比,也即每个分桶的大小建议在100M-1G之间。

若不好估算数据量,我们也可以将分桶数设为:分桶数=“BE个数*BE节点CPU核数”或者“BE个数*BE节点CPU核数/2”,这样一般也不会有什么问题。这里需要注意的是,已创建分区的分桶数不能修改(有其他方式能实现,但比较麻烦),所以前期设定合适的分桶数非常重要。

5动态分区

在StarRocks中,必须先有分区,才能将对应的数据导入进来,不然导入就会报错(提示there is a row couldn’t find a partition)。比如使用日期作为分区,那就需要先创建每天的分区,再进行数据导入。在日常业务中,除了每日会新增数据,我们还会对旧的历史数据进行清理。动态分区就是StarRocks用来实现新分区自动创建以及过期分区自动删除的方式。

动态分区由后台常驻进程调度,默认调度周期为10分钟一次,由FE配置文件中的dynamic_partition_check_interval_seconds参数控制(单位是秒,配置文件中默认没有该配置),所以并不是创建动态分区表后所有分区就立刻被创建,我们还需要等待不超过10分钟让后台调度生效。

咱们创建一个动态分区表table07:

CREATE TABLE starrocks.table07(

<think>我们正在处理一个数据库错误,错误代码为1105,errCode=2,详细信息是"There is no scanNode Backend available.[10059: not alive]"。根据引用[1]中的错误信息,虽然具体错误信息不完全相同(引用[1]是10002,这里是10059),但都是关于scanNode Backend不可用的问题。我们可以参考类似错误的解决思路。 可能的原因和解决方案: 1. 后端节点(Backend)不可用:错误信息明确提到“not alive”,说明负责执行扫描任务的后端节点已经宕机或失去连接。 - 解决方案:检查后端节点的状态,确保所有节点都正常运行。如果是布式数据库,使用管理命令查看节点状态(例如,在Doris中,可以通过`SHOW BACKENDS;`命令检查BE节点状态)。如果有节点宕机,尝试重启该节点。 2. 网络问题:节点间通信故障可能导致节点被标记为不可用。 - 解决方案:检查节点之间的网络连通性,特别是报错的节点其他节点(包括FE和BE)之间的网络。 3. 资源不足:如果后端节点资源(如内存、CPU)耗尽,也可能导致节点无法被配任务。 - 解决方案:检查后端节点的资源使用情况,释放资源或增加资源。 4. 黑名单问题:引用[1]的错误提到“in black list”,虽然这里的错误没有明确,但可能是由于节点被加入黑名单导致不可用。 - 解决方案:检查是否有节点被加入黑名单,如果有,需要析被加入黑名单的原因(如频繁失败),解决问题后移除黑名单。 5. 元数据不一致:如果集群的元数据信息不一致,可能导致调度器无法正确配任务到后端节点。 - 解决方案:检查元数据状态,必要时进行修复。 步骤建议: 1. 首先确认后端节点的状态,使用数据库系统提供的管理命令(如Doris的`SHOW BACKENDS;`)查看节点状态。检查Alive列是否为true,以及是否有错误信息。 2. 如果发现节点宕机,尝试重启该节点。 3. 检查网络连接,确保所有节点之间可以互相通信。 4. 检查系统资源(内存、磁盘、CPU)使用情况,确保没有过载。 5. 查看日志:后端节点的日志可能包含更详细的错误信息,帮助定位问题。 由于具体的数据库系统可能不同(如Doris、TiDB等),上述命令和操作可能有所差异,请根据实际使用的数据库系统进行调整。 注意:引用[2]提供了一些测试数据插入的SQL语句,但本错误无关,可以忽略。 如果以上步骤仍不能解决问题,需要结合具体的数据库系统版本和日志进行深入排查。 相关问题: 1. 如何检查布式数据库后端节点的状态? 2. 如何重启布式数据库的后端节点? 3. 如何查看布式数据库的日志以诊断问题? 4. 如何解决数据库节点被加入黑名单的问题? </think>### 错误代码 1105 的解决方案 根据您提供的错误信息 `errCode=2 detailMessage=There is no scanNode Backend available.[10059: not alive]`,这是一个典型的布式数据库后端节点不可用错误。结合引用内容和布式系统原理,以下是完整的排查步骤和解决方案: #### 核心问题诊断 错误代码 `10059: not alive` 表明: 1. **后端节点故障**:扫描节点(scanNode Backend)宕机或失去响应 2. **连接异常**:网络中断或节点被标记为不可用状态 3. **资源不足**:节点资源(CPU/内存)耗尽导致服务不可用 --- ### 解决方案步骤 #### 第一步:检查后端节点状态 ```sql -- 查看所有BE节点状态(以Doris/StarRocks为例) SHOW BACKENDS\G ``` 重点关注: - `Alive` 字段是否为 `true` - `LastStartTime` 是否最近有更新 - `ErrMsg` 列是否有异常信息[^1] #### 第二步:重启故障节点 ```bash # 登录到对应BE节点进行操作 ./bin/start_be.sh --daemon # 启动BE服务 tail -f log/be.INFO # 查看实时日志 ``` 若节点持续崩溃,检查: - 磁盘空间(`df -h`) - 内存占用(`free -m`) - OOM错误(`dmesg | grep -i kill`) #### 第三步:网络诊断 1. 验证FE-BE连通性: ```bash # 从FE节点执行 telnet <BE_IP> <HEARTBEAT_PORT> # 默认端口 9050 ``` 2. 检查防火墙规则: ```bash iptables -L -n | grep 9050 ``` #### 第四步:黑名单检查(如适用) 若错误日志包含 `in black list`(如引用[1]所示): ```sql SHOW PROC '/backends_blacklist'; ``` 手动移除黑名单: ```sql ADMIN SET FRONTEND CONFIG ("black_list" = ""); ``` #### 第五步:数据片恢复 当节点长期离线时: ```sql -- 检查数据片状态 ADMIN SHOW REPLICA STATUS FROM <db_name> PROPERTIES("backendid" = "<故障BE_ID>"); -- 触发自动修复(需Alive节点满足副本数) ADMIN REPAIR TABLE <table_name>; ``` --- ### 预防措施 1. **心跳监控**:配置 `heartbeat_timeout_second` > 网络延迟 2. **资源隔离**:为BE进程设置cgroup限制 3. **高可用架构**: - 部署≥3个BE节点 - 设置副本数 `replication_num` ≥ 2 ```sql ALTER TABLE <table_name> SET ("replication_num" = "2"); ``` --- ### 典型故障场景析 | 现象 | 原因 | 解决方案 | |------|------|-----------| | 间歇性报错 | 网络抖动 | 增大 `heartbeat_timeout_second` | | 新增节点不可用 | 端口冲突 | 修改 `be.conf` 中的 `brpc_port` | | 查询时报错 | 数据副本丢失 | 执行 `ADMIN REPAIR` 命令 | | 批量导入失败 | 内存不足 | 调高 `load_process_max_memory_limit_bytes` | > **关键提示**:该错误通常集群状态相关,需结合 `show proc '/backends'` 和 BE 日志 `log/be.WARNING` 综合析[^1]。 --- ### 相关问题 1. 如何区 BE 节点宕机和网络分区故障? 2. 数据副本修复的底层原理是什么? 3. 如何配置布式数据库的自动化故障转移? 4. 心跳超时参数应该如何优化调整? 5. 哪些监控指标可提前预测节点故障?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值