深入starrocks-多列联合统计一致性探查与策略(YY一下)

接上篇，意淫一下，官方都说了多列联合统计信息需要手动触发，所以一定是延迟的。那么......

当多列联合统计信息依赖手动触发 时，统计信息与实际数据不一致的情况必然存在------ 核心原因是手动操作无法实时响应数据变化（如批量写入、删除、更新），导致统计信息滞后于真实数据，进而引发基数估算偏差、执行计划劣化（如错误选择 JOIN 顺序、不当的 Shuffle 策略）。

一、先明确：统计信息与实际数据不一致的核心场景

[二、优化方案：从 "手动依赖" 到 "自动化 + 精准化"](#二、优化方案：从 “手动依赖” 到 “自动化 + 精准化”)

[1. 第一层：用 "自动化触发" 替代纯手动，消除人为滞后](#1. 第一层：用 “自动化触发” 替代纯手动，消除人为滞后)

[2. 第二层：优化更新策略，平衡 "时效性" 与 "资源消耗"](#2. 第二层：优化更新策略，平衡 “时效性” 与 “资源消耗”)

[3. 第三层：准确性校验，及时发现不一致](#3. 第三层：准确性校验，及时发现不一致)

[4. 第四层：运维监控与告警，形成闭环](#4. 第四层：运维监控与告警，形成闭环)

三、总结：最优实践组合

要解决这一问题，需从 "减少手动依赖 "、"提升更新时效性 "、"保障准确性" 三个维度设计优化方案，结合 StarRocks 的功能特性落地具体策略

一、先明确：统计信息与实际数据不一致的核心场景

在手动触发模式下，以下情况会直接导致不一致：

数据高频变更后未触发更新 如每日凌晨批量写入百万级订单数据，但未重新采集(user_id, order_date)的联合统计信息，此时统计信息仍反映旧数据的 NDV（唯一值数量），导致查询优化器误判 "WHERE order_date = '2025-01-01'的结果集大小"。
数据删除 / 更新导致分布变化 若执行DELETE FROM orders WHERE user_id = 10086删除大量数据，或UPDATE修改order_date字段，联合统计信息中的 "user_id与order_date的组合唯一值" 会与实际不符，可能导致聚合操作的资源分配不足。
抽样采集的固有偏差 手动触发时若使用默认抽样策略（而非全量），当数据分布不均匀（如某user_id对应 10 万条订单，其他仅 10 条），抽样结果可能高估 / 低估联合 NDV，进一步放大不一致性。

二、优化方案：从 "手动依赖" 到 "自动化 + 精准化"

针对上述问题，可通过 "自动化触发 ""优化更新策略 ""准确性校验 ""运维监控" 四层方案解决，充分利用 StarRocks 的原生功能：

1. 第一层：用 "自动化触发" 替代纯手动，消除人为滞后

StarRocks 虽默认不自动采集多列联合统计信息，但可通过CREATE ANALYZE创建定时任务 或事件触发任务，将手动操作转化为自动化流程，从根源减少滞后。

（1）定时自动采集：适配周期性数据变更

若数据变更有固定周期（如每日凌晨 3 点完成 ETL），可创建按日 / 按小时的定时任务 ，在数据更新后自动触发统计信息采集。示例：对orders表的(user_id, order_date)列，每天凌晨 4 点（ETL 后 1 小时）自动采集联合统计信息：

sql 复制代码

-- 创建每日定时任务，异步采集（不阻塞业务）
CREATE ANALYZE orders 
COLLECT STATS FOR COLUMNS (user_id, order_date)  -- 指定多列组合
PROPERTIES (
    "frequency" = "DAILY",          -- 周期：每日
    "start_time" = "04:00:00",      -- 触发时间（ETL后）
    "async" = "true",               -- 异步执行，避免阻塞
    "statistic_sample_collect_rows" = "1000000"  -- 抽样行数（大表建议100万+）
);

-- 查看已创建的自动任务
SELECT * FROM information_schema.analyze_jobs;

（2）事件触发采集：适配非周期性高频变更

若数据变更无固定周期（如实时写入的交易数据），可通过脚本 + StarRocks API实现 "数据变更阈值触发"：

步骤 1：监控表的增量数据量（如通过SHOW PARTITIONS查看新增分区的行数，或监听 Kafka 消费进度）；
步骤 2：当增量行数超过阈值（如 10 万行），通过 StarRocks 的 HTTP API 或 JDBC 执行ANALYZE语句；

示例 API 调用（触发异步采集）：

bash 复制代码

curl -X POST -u root:password \
http://starrocks-fe:8030/api/ddl/db1/orders/analyze \
-d '{"columns":["user_id","order_date"], "async":true}'

2. 第二层：优化更新策略，平衡 "时效性" 与 "资源消耗"

全量采集大表的联合统计信息会消耗大量 CPU/IO（如 100GB 表全量扫描需数小时），需通过 "分区级采集 ""增量更新 ""抽样调优" 降低成本，确保更新可落地。

（1）分区级采集：只更新变更的分区

若表是分区表 （如按order_date分区），++数据变更通常集中在新分区或少数历史分区++，此时无需全表采集，仅针对变更分区触发统计信息更新，资源消耗可降低 80% 以上。示例：仅采集orders表 2025 年 1 月的分区（p202501）的联合统计信息：

sql 复制代码

-- 分区级手动采集（自动化任务也可指定分区）
ANALYZE TABLE orders 
PARTITION (p202501)  -- 仅更新目标分区
COLLECT STATS FOR COLUMNS (user_id, order_date) 
ASYNC;  -- 异步执行，不影响业务

（2）增量更新：避免重复扫描未变更数据

StarRocks 自 v3.5.0 起支持统计信息增量更新 （需开启配置），仅对 "新增 / 修改的数据" 重新计算联合 NDV，而非全表扫描。开启方式：

sql 复制代码

-- 开启增量统计信息更新（FE配置，需重启生效）
ADMIN SET FRONTEND CONFIG ("enable_incremental_statistic_collect" = "true");

-- 触发增量采集（仅扫描上次采集后变更的数据）
ANALYZE TABLE orders 
COLLECT STATS FOR COLUMNS (user_id, order_date) 
PROPERTIES ("incremental" = "true");  -- 关键参数：增量模式

（3）抽样调优：大表用 "精准抽样" 平衡速度与准确性

对 TB 级大表，全量采集不现实，需通过调整抽样参数提升抽样结果的准确性：

增大抽样行数：将statistic_sample_collect_rows从默认 10 万行提升至 100 万 - 1000 万行（根据表大小调整），降低抽样偏差；
分层抽样：对数据倾斜的表（如某user_id占比 30%），通过PROPERTIES ("sample_strategy" = "stratified")开启分层抽样，确保每个 "高占比分组" 都被采样到；
小表全量：对行数 < 100 万的小表，强制全量采集（PROPERTIES ("sample_ratio" = "1.0")），避免抽样误差。

3. 第三层：准确性校验，及时发现不一致

即使自动化触发，仍可能因 "采集失败""数据突发变更" 导致不一致，需通过统计信息健康度检查 和结果校验及时发现问题。

（1）查询统计信息状态：判断是否过期

通过 StarRocks 的系统视图information_schema.COLUMN_STATS_USAGE和_statistics_.multi_column_statistics，查看统计信息的 "更新时间" 和 "数据变更比例"：

sql 复制代码

-- 查看多列联合统计信息的基本状态
SELECT 
    table_name,
    column_names,  -- 联合列组合
    joint_ndv,     -- 联合NDV值
    update_time,   -- 最后更新时间
    data_change_ratio  -- 数据变更比例（>0.2表示可能过期）
FROM _statistics_.multi_column_statistics
WHERE table_id = (SELECT table_id FROM information_schema.tables WHERE table_name = 'orders');

-- 查看统计信息的使用情况（是否被优化器依赖）
SELECT 
    table_name,
    column_name,
    last_used_time,  -- 最后被查询使用的时间
    usage_count      -- 被使用次数
FROM information_schema.COLUMN_STATS_USAGE
WHERE table_name = 'orders' AND column_name IN ('user_id', 'order_date');

若update_time早于最近一次数据变更时间，或data_change_ratio>0.2（数据变更超过 20%），说明统计信息可能过期，需重新采集。

（2）校验联合 NDV 准确性：对比真实值

对关键表，可通过 "手动计算真实联合 NDV " 与统计信息中的joint_ndv对比，判断偏差是否在可接受范围（如 < 10%）：

sql 复制代码

-- 手动计算真实联合NDV（小表可用，大表慎用）
SELECT COUNT(DISTINCT CONCAT(user_id, '#', order_date)) AS real_joint_ndv
FROM orders;

-- 对比统计信息中的joint_ndv（假设统计信息中的值为stat_joint_ndv）
-- 偏差率 = |real_joint_ndv - stat_joint_ndv| / real_joint_ndv
-- 若偏差率>10%，需重新采集并调整抽样参数

4. 第四层：运维监控与告警，形成闭环

将 "统计信息不一致" 纳入日常运维监控，通过日志监控 和自定义告警实现问题自动告警，避免人工遗漏。

sql 复制代码

-- 查看集群全部自定义采集任务。
SHOW ANALYZE JOB

-- 查看数据库 `test` 下的自定义采集任务。
SHOW ANALYZE JOB where `database` = 'test';

三、总结：最优实践组合

针对 "手动触发导致的统计信息不一致"，最终推荐的优化组合是：

自动化触发 ：用CREATE ANALYZE创建定时任务（适配周期变更）+ 脚本触发（适配高频变更），90% 场景替代手动操作；
精准更新：分区级采集（大表）+ 增量更新（变更数据）+ 分层抽样（倾斜数据），平衡性能与准确性；
健康度监控：通过系统视图检查更新时间和变更比例，结合自定义脚本告警，及时发现过期统计信息；
小表全量 + 大表抽样：小表强制全量采集（无误差），大表用 100 万行以上分层抽样（偏差 < 10%）。

通过YY这套方案，可将统计信息与实际数据的不一致率控制在 5% 以内，同时避免过度消耗集群资源，确保查询优化器始终基于 "接近真实" 的统计信息生成最优执行计划。

另：通常来说对于特征比较恒定的业务表来说，不用把以上所有策略都上马，甚至对于极其稳定的数据表，每周/每月统计一次都可以的。

以上内容，主要描述思路，供参考，starrocks当前未必已完全实现。

(欢迎关注，欢迎订阅 -数据湖专栏**** )