be_tablets 聚合的表大小和行数与 tables有较大差异,4000多张表中大概有400多张表是不一样的, 有时候be_tablets 查询的表大小和行数都为0,但是tables不是,

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】通过如下sql 查询表的信息,发现问题就是 be_tablets 聚合的表大小和行数与 tables有较大差异,4000多张表中大概有400多张表是不一样的, 有时候be_tablets 查询的表大小和行数都为0,但是tables不是,通过 show partitions 和show tablet 查询发现有分区大小不为0,有tablet大小不为0, 感觉be_tablets 那边数据会慢,对吗?
`
– 计算每个分区的总数据量
WITH partitiondata AS (
SELECT
pm.db_name, – 数据库名称
pm.table_name, – 表名称
pm.partition_name, – 分区名称
pm.replication_num, – 分区副本数 – 一般情况下每个表的副本数是相同的
COALESCE(SUM(tbt.data_size), 0) AS partition_data_size, – 分区大小(多副本)
COALESCE(SUM(tbt.index_disk), 0) AS partition_index_disk, – 分区索引大小(多副本)
COALESCE(SUM(tbt.num_row), 0) AS partition_num_row, – 分区数据量条数(多副本)
COALESCE(SUM(tbt.num_segment), 0) AS partition_num_segment, – 分区 segment 数(多副本)
COUNT(tbt.tablet_id) AS tablet_count, – 统计分区的tablet 数量(多副本)
CASE
WHEN pm.table_name = pm.partition_name THEN 0 – 如果分区名称等于表名称,则不是分区表
ELSE 1 – 否则是分区表
END AS is_partitioned, – 是否是分区表
CASE
WHEN pm.partition_name = ‘$shadow_automatic_partition’ THEN 1 – 如果有这个分区 ,需要在最后给处理一下
ELSE 0 – 否则不是shadow分区
END AS is_shadow_partition – 是否是shadow分区
FROM
information_schema.partitions_meta pm
LEFT JOIN
information_schema.be_tablets tbt
ON pm.partition_id = tbt.partition_id
GROUP BY
pm.db_name,
pm.table_name,
pm.partition_name,
pm.replication_num – 一般情况下每个表的副本数是相同的
),
tablestats AS ( – 计算每个表的总数据量、tablet 数量、最大分区容量和分桶数
SELECT
pd.db_name,
pd.table_name,
SUM(pd.tablet_count) AS tablet_count, – 表的 tablet 数量 (多副本)
SUM(pd.partition_num_row) AS total_num_row, --表总条数(多副本)
SUM(pd.partition_data_size) AS total_data_size, – 表总数据量 – 可以后面加一个 平均每个 tablet 的数据量
SUM(pd.partition_index_disk) AS total_index_disk, – 表总索引大小(多副本)
SUM(pd.partition_num_segment) AS total_num_segment, – 表总 segment 数(多副本)
SUM(pd.is_shadow_partition) AS total_num_shadow_partition, – 表总shadow分区数(多副本)
MAX(pd.partition_data_size) AS max_partition_size, – 最大分区容量
COUNT(DISTINCT pd.partition_name) AS partition_count, – 分区数量
tc.distribute_bucket AS buckets, – 分桶数
pd.replication_num, – 一般情况下每个表的副本数是相同的
pd.is_partitioned – 是否是分区表
FROM
partitiondata pd
JOIN
information_schema.tables_config tc
ON pd.db_name = tc.table_schema
AND pd.table_name = tc.table_name
GROUP BY
pd.db_name,
pd.table_name,
tc.distribute_bucket,
pd.replication_num,
pd.is_partitioned
)
SELECT
ts.db_name, – 数据库名称
ts.table_name, – 表名称
%s AS write_time, – Python 传入日期字符串 CURDATE() - INTERVAL 0 DAY as write_time, – 写入时间(年月日)
ts.tablet_count, – tablet 数量
ts.total_num_row, – 表总条数 (多副本) 真实条数需要除以副本数
ts.total_index_disk, – 表总索引大小 (多副本)
ts.total_num_segment, – 表总 segment 数 (多副本)
ts.total_data_size, – 表总数据量 (多副本,不加索引大小) 真实表大小需要加索引大小
ts.partition_count, – 分区数量
ts.replication_num, – 一般情况下每个表的副本数是相同的
ts.total_num_shadow_partition, – shadow分区数量
tbs.table_catalog, – 表目录 来源 tables 表
tbs.table_type, – 表类型 来源 tables 表
tbs.table_rows, – 表行数 来源 tables 表
tbs.data_length AS table_data_length, – 表数据长度 来源 tables 表
tbs.create_time AS table_create_time, – 表创建时间 来源 tables 表
tbs.update_time AS table_update_time, – 表更新时间 来源 tables 表
CASE
WHEN ts.partition_count > 1 THEN ts.max_partition_size – 分区表显示最大分区容量
ELSE NULL
END AS max_partition_size, – 最大分区容量
ts.buckets, – 分桶数
ts.is_partitioned – 是否是分区表
FROM
tablestats ts
LEFT JOIN
information_schema.tables tbs
ON ts.db_name = tbs.table_schema
AND ts.table_name = tbs.table_name
ORDER BY
ts.tablet_count DESC;

`

【业务影响】
【是否存算分离】 不是存算分离
【StarRocks版本】3.2
【集群规模】3fe(1 follower+2observer)+13be(fe与be非混部)

正常来说be_tablets是实时维护的,记录BE上Tablet的详细信息,而tables它仅仅是一份元数据是有更新频率的。
其实在数据写入、删除或进行 Compaction 操作时,Tablet的统计信息就已经发生了变化。而这些变化也会直接同步和聚合到be_tablets中。但是tables中会通过CBO周期性的统计采集方式进行元数据更新。所以原则上者两者是有一定延迟。

好的,谢谢

您好,我在检查一张表的时候,发现 tables 有 表的条数和大小, show data 和show partitions 和show tablets 都有数据,并且有大小,但是通过
select * from information_schema.partitions_meta where db_name=“xxx” and table_name = “xxx”; 拿到 partitions_id 后,根据partitions_id 查询be_tablets表 过滤出来是空的。查询不出来数据。

然后select count() 和 select * limit 10,都能查询该表的数据,

mysql> show data from ods_wsdm.jl_yq_share_2024;
±-----------------±-----------------±-----------±-------------±---------+
| TableName | IndexName | Size | ReplicaCount | RowCount |
±-----------------±-----------------±-----------±-------------±---------+
| jl_yq_share_2024 | jl_yq_share_2024 | 121.928 MB | 9 | 3351571 |
| | Total | 121.928 MB | 9 | |
±-----------------±-----------------±-----------±-------------±---------+
2 rows in set (0.00 sec)

mysql> show partitions from ods_wsdm.jl_yq_share_2024;
±------------±-----------------±---------------±--------------------±-------------------±-------±-------------±------±----------------±--------±---------------±--------------±--------------------±-------------------------±---------±-----------±---------+
| PartitionId | PartitionName | VisibleVersion | VisibleVersionTime | VisibleVersionHash | State | PartitionKey | Range | DistributionKey | Buckets | ReplicationNum | StorageMedium | CooldownTime | LastConsistencyCheckTime | DataSize | IsInMemory | RowCount |
±------------±-----------------±---------------±--------------------±-------------------±-------±-------------±------±----------------±--------±---------------±--------------±--------------------±-------------------------±---------±-----------±---------+
| 173202702 | jl_yq_share_2024 | 8 | 2025-03-13 16:11:28 | 0 | NORMAL | | | ALL KEY | 3 | 3 | SSD | 9999-12-31 23:59:59 | 2025-06-14 01:14:36 | 121.9MB | false | 3351571 |
±------------±-----------------±---------------±--------------------±-------------------±-------±-------------±------±----------------±--------±---------------±--------------±--------------------±-------------------------±---------±-----------±---------+
1 row in set (0.00 sec)

mysql> show tablets from ods_wsdm.jl_yq_share_2024;
±----------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±---------±-------±------------------------±-------------±-----------------±-------------±---------±--------------------------------------------------±----------------------------------------------------------------+
| TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State | LstConsistencyCheckTime | CheckVersion | CheckVersionHash | VersionCount | PathHash | MetaUrl | CompactionStatus |
±----------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±---------±-------±------------------------±-------------±-----------------±-------------±---------±--------------------------------------------------±----------------------------------------------------------------+
| 173202703 | 173202705 | 10004 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117191 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202703 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202703 |
| 173202703 | 208513745 | 200767338 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117191 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202703 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202703 |
| 173202703 | 208522022 | 200776661 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117191 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202703 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202703 |
| 173202707 | 173202709 | 8990247 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117184 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202707 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202707 |
| 173202707 | 173202710 | 8990248 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117184 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202707 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202707 |
| 173202707 | 208516297 | 200767337 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117184 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202707 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202707 |
| 173202711 | 173202712 | 8990249 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117196 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202711 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202711 |
| 173202711 | 173202713 | 103900681 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117196 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202711 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202711 |
| 173202711 | 173202714 | 103891524 | 0 | 8 | 0 | 8 | 0 | -1 | 0 | NULL | 13.5MB | 1117196 | NORMAL | 2025-06-14 01:14:36 | 8 | 0 | 1 | -1 | http://xxxxxxxx:8040/api/meta/header/173202711 | http://xxxxxxxx:8040/api/compaction/show?tablet_id=173202711 |
±----------±----------±----------±-----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------±---------±---------±-------±------------------------±-------------±-----------------±-------------±---------±--------------------------------------------------±----------------------------------------------------------------+

mysql> select * from information_schema.partitions_meta where db_name=“ods_wsdm” and table_name = “jl_yq_share_2024”;
±---------±-----------------±-----------------±-------------±----------------±----------------±---------------------±-------------±--------------±----------------±-----------------±--------±----------------±---------------±--------------------±----------------------------±-------------±--------±----------±----------±-----------------±-------±-------±-------±-------------+
| DB_NAME | TABLE_NAME | PARTITION_NAME | PARTITION_ID | COMPACT_VERSION | VISIBLE_VERSION | VISIBLE_VERSION_TIME | NEXT_VERSION | PARTITION_KEY | PARTITION_VALUE | DISTRIBUTION_KEY | BUCKETS | REPLICATION_NUM | STORAGE_MEDIUM | COOLDOWN_TIME | LAST_CONSISTENCY_CHECK_TIME | IS_IN_MEMORY | IS_TEMP | DATA_SIZE | ROW_COUNT | ENABLE_DATACACHE | AVG_CS | P50_CS | MAX_CS | STORAGE_PATH |
±---------±-----------------±-----------------±-------------±----------------±----------------±---------------------±-------------±--------------±----------------±-----------------±--------±----------------±---------------±--------------------±----------------------------±-------------±--------±----------±----------±-----------------±-------±-------±-------±-------------+
| ods_wsdm | jl_yq_share_2024 | jl_yq_share_2024 | 173202702 | 0 | 8 | 2025-03-13 16:11:28 | 9 | | | ALL KEY | 3 | 3 | SSD | 9999-12-31 23:59:59 | 2025-06-14 01:14:36 | 0 | 0 | 121.9MB | 3351571 | 0 | 0 | 0 | 0 | |
±---------±-----------------±-----------------±-------------±----------------±----------------±---------------------±-------------±--------------±----------------±-----------------±--------±----------------±---------------±--------------------±----------------------------±-------------±--------±----------±----------±-----------------±-------±-------±-------±-------------+
1 row in set (4.23 sec)

mysql>

mysql> select * from information_schema.be_tablets where partition_id = “173202702”;
Empty set (0.80 sec)

mysql>

表结构如下:

| jl_yq_share_2024 | CREATE TABLE jl_yq_share_2024 (
trade_account_no varchar(50) NULL COMMENT “”,
trust_channel_account varchar(50) NULL COMMENT “”,
fund_code varchar(6) NULL COMMENT “”,
balance decimal(16, 2) NULL COMMENT “”,
compare_diff decimal(16, 2) NULL COMMENT “”,
total decimal(16, 2) NULL COMMENT “”,
available_volume decimal(16, 2) NULL COMMENT “”,
share_date varchar(8) NULL COMMENT “”,
tp_type varchar(50) NULL COMMENT “”,
gen_time datetime NULL DEFAULT CURRENT_TIMESTAMP COMMENT “数据生成时间”
) ENGINE=OLAP
DUPLICATE KEY(trade_account_no)
DISTRIBUTED BY RANDOM
PROPERTIES (
“replication_num” = “3”,
“in_memory” = “false”,
“enable_persistent_index” = “false”,
“replicated_storage” = “true”,
“compression” = “LZ4”
); |

可能这不仅仅是“慢”的问题,更可能是信息同步的延迟或者BE有点异常,你可以根据当时的资源判断下,比如CPU,内存,IO这些基础指标看下当时集群是否存在压力。因为FE和BE之间的还存在一层信息同步和缓存机制,你可以参考"tablet_stat_update_interval_second"这个参数,默认是300秒。
所以说如果BE节点未能正确地向FE报告Tablet信息,那么 information_schema.be_tablets 就会不完整或为空。不排除是由于BE节点本身的问题。

大佬,这个问题奇怪的地方在 表的最后更新日期是 2025年 而不是当前,同步延迟的话有点不太可能吧。
还有个疑问就是show tablet 查询不通过 be_tablets 表嘛?而是直接查询be的吗?
我还在看还有其他表是不是也有类似的问题。

你可以这样理解,be_tablets是一个视图,它从BE节点收集Tablet的统计信息并聚合展示出来的
而show tablets就是一个内部命令,它直接向FE请求最新的Tablet元数据信息,FE再从其维护的元数据中获取并返回。