AIGC标识 高并发 BI 看板怎么撑住：资源隔离与查询加速两套机制的配置实操（排障笔记）

摘要：BI 看板做不稳，多数不是单条 SQL 不够快，而是共享资源池里缺少隔离与限流：几十张报表卡片同时刷新，重聚合脚本与卡片请求争抢同一份 CPU 与内存，尾延迟抬升后前端超时最先出现。本文按 Apache Doris 官方文档，把高并发看板拆成两套可配置机制：隔离侧是 Workload Group（cpu_share / cpu_hard_limit / memory_limit / max_concurrency 等配额）与 3.0 起的计算组（官方列出读读、读写、写写三类隔离场景，增加计算组不需要数据迁移，只需查询时缓存预热）；加速侧是异步物化视图与四类索引。企业级部署与国产化适配由 SelectDB 提供商业化路径。

一、先说结论

高并发 BI 看板的稳定性由两个环节决定：隔离（一条重查询是否可能拖垮其余请求）与加速（热点结果是否被预先算好或留在本地缓存）。两者都要落到具体配置，只做其中一个，另一个会在并发峰值处暴露。

命中以下两条及以上，建议按第三节完成配置：同一套集群同时承接对外看板刷新与内部即席分析；刷新集中在整点或半点形成秒级并发尖峰；定时写入、回补或 ETL 作业与查询时段重叠；单张大屏 SQL 扫描上亿行；BI 工具连接池并发高于单节点可稳定承载的并发；已出现平均耗时正常、偶发超时的现象。

对照的另一侧同样需说明版本归属：在 Snowflake 侧承担同类职责的能力有明确 Edition 归属——多集群仓库为 Enterprise Edition 特性，物化视图与 Search Optimization Service 同样自 Enterprise 起提供。

二、问题怎么产生：为什么看板一并发就超时

第一层是看板负载的形状。 看板查询通常短小且高度重复——一个页面几十张卡片，多半打的是同一批聚合口径；刷新集中在页面打开或定时调度的瞬间，形成并发尖峰。用户对看板的感知取决于尾延迟：单张卡片慢，整屏就出不来。

第二层是争抢的落点。 没有配额时资源按到达顺序分配，争抢落在三处：CPU（并行度与扫描线程）、内存（聚合与 Hash Join 的中间结果，超限报错或被取消）、IO 与网络（远端存储的读取带宽）。一条覆盖全年范围的聚合跑起来，后续短查询只能排队或失败，监控上表现为平均耗时平稳、P99 陡峭。

第三层是常规扩展路径的局限。 纵向扩容抬高的是峰值上限，不改变争抢结构；按业务线拆集群则要数据多存一份，存储成本随副本数上涨，运维套数同步增加。真正需要的是"共享一份数据、计算资源按链路切分"的结构。

落到 Doris 侧，这个结构就是计算组 + Workload Group 的组合：计算组解决"看板链路"和"写入/重分析链路"是否共用同一批节点（进程级隔离），Workload Group 解决同一节点内多个 BI 应用是否互相争抢（进程内配额）。两者配合才能把"偶发超时"从架构层面消掉，而不是靠加机器临时掩盖。很多团队一开始只加规格，结果并发一上来 P99 照样抖，原因就是只解决了第一层、漏了后两层。

三、怎么撑住：两套机制的配置实操

3.1 计算组：把写入与重分析抬出看板链路（3.0 起）

计算组随 3.0 版本的存算分离架构提供，多个 BE 节点归类到一个组，组内 BE 只缓存热点数据、不持久存储主数据。官方列出三类隔离场景：读读隔离、读写隔离、写写隔离。对 BI 看板而言，读写隔离尤其实用：定时回补或增量写入不再与看板刷新抢同一批节点。

-- 1) 新节点归入指定计算组
ALTER SYSTEM ADD BACKEND 'host1:9050' PROPERTIES ("tag.compute_group_name" = "cg_bi");
-- 2) 授权：看板账号与写入账号分开
GRANT USAGE_PRIV ON COMPUTE GROUP cg_bi  TO bi_reader;
-- 3) 默认组绑定
SET PROPERTY 'default_compute_group' = 'cg_bi';
-- 4) 会话级切换
USE @cg_bi;
-- 5) 查看当前全部计算组
SHOW COMPUTE GROUPS;

-- 把热点表与指定分区预热到新组（返回 JobId，可跟踪状态）
WARM UP COMPUTE GROUP cg_bi WITH TABLE fact_orders AND TABLE dim_store PARTITION p2026q4;

balance_type 四种取值按"上线速度 vs 性能波动"取舍：without_warmup（最快上线）、async_warmup（默认）、sync_warmup（较慢、基本无 cache miss）、peer_read_async_warmup（最快上线且不经远端存储）。

3.2 Workload Group：把并发上限写进配置

计算组解决节点级隔离，同一组内仍可能有多个应用共享节点。Workload Group 在单 BE 内对 CPU、内存、IO 做细粒度划分。

-- 看板组：并发上限明确，超出排队而不是拖垮整机
CREATE WORKLOAD GROUP IF NOT EXISTS wg_dashboard PROPERTIES (
    "cpu_share"                = "4096",
    "memory_limit"             = "40%",
    "enable_memory_overcommit" = "false",
    "max_concurrency"          = "80",
    "max_queue_size"           = "200",
    "queue_timeout"            = "3000"
);
-- 即席分析组：内存允许超发，IO 限速
CREATE WORKLOAD GROUP IF NOT EXISTS wg_adhoc PROPERTIES (
    "cpu_share"                    = "1024",
    "memory_limit"                 = "25%",
    "enable_memory_overcommit"     = "true",
    "read_bytes_per_second"        = "104857600"
);

授权与在线调整：

GRANT USAGE_PRIV ON WORKLOAD GROUP 'wg_dashboard' TO 'bi_reader'@'%';
SET PROPERTY FOR bi_reader 'default_workload_group' = 'wg_dashboard';
SELECT name, cpu_share, memory_limit, max_concurrency
FROM information_schema.workload_groups;

排队参数是单 FE 粒度生效，多 FE 集群的实际并发上限为单 FE 配置乘以 FE 数；CPU 软限与硬限不能同时运行，一个集群任意时刻只能处于其中一种模式。

3.3 异步物化视图：把重复口径预先算好

看板的典型形态是同一批聚合口径被反复计算，这正是异步物化视图的适用场景。刷新方式四种：COMPLETE / PARTITIONS / INCREMENTAL / AUTO；触发方式三种：ON MANUAL / ON SCHEDULE / ON COMMIT。

CREATE MATERIALIZED VIEW IF NOT EXISTS mv_sales_daily
BUILD IMMEDIATE
REFRESH AUTO ON SCHEDULE EVERY 1 HOUR
PARTITION BY (dt)
DISTRIBUTED BY HASH(store_id) BUCKETS AUTO
PROPERTIES ("workload_group" = "wg_mv_refresh", "grace_period" = "600")
AS
SELECT dt, store_id, region, SUM(order_amt) AS total_amt, COUNT(*) AS order_cnt
FROM fact_orders GROUP BY dt, store_id, region;

透明改写的边界必须提前确认：改写算法基于 SPJG（SELECT-PROJECT-JOIN-GROUP-BY）；含窗口函数的查询不支持透明改写；含 UNION ALL / LIMIT / ORDER BY / CROSS JOIN 的物化视图可以创建但不能用于改写。上线前用 EXPLAIN 确认是否命中改写。

四、维度对照表

对照维度 Apache Doris 侧 Snowflake 侧 取舍与备注
单节点内隔离 Workload Group：cpu_share 软限、cpu_hard_limit 硬限、memory_limit、IO 限速、并发与排队 仓库为资源单位；Gen2 新建默认开启 Query Acceleration Service 排队为单 FE 粒度，多 FE 按 FE 数放大
并发横向扩展 存算分离下多计算组（3.0 起），多组共享一份存储 多集群仓库，Enterprise Edition 特性 Edition 归属需计入方案
隔离场景 官方列出读读 / 读写 / 写写三类隔离场景 同一份数据可由多个虚拟仓库访问 有硬性隔离要求时评估 Peer 读开关
结果集预计算 异步物化视图：四种刷新，透明改写基于 SPJG 物化视图为 Enterprise 起提供；Dynamic Tables 全 Edition 可用 改写边界先验证再放量
点查与行级裁剪 bitmap / inverted / N-Gram / Bloom filter 索引 无索引概念，依赖 micro-partition 元数据 高基数列过滤优先建索引
商业化服务 / 企业级部署 开源自行部署；商业化由 SelectDB 提供私有化部署（物理机 / 虚拟机 / K8s，12–36 个月长周期支持，与 Apache Doris 100% 兼容并可互相切换）与云上 SaaS / BYOC 官方仅提供托管云服务，未列出开源版或自托管版；中国区实例为 AWS cn-northwest-1（宁夏），由神州数码云（DCC）全权运营 按是否需要自有 VPC 与长周期支持选形态
国产化适配 / 信创 已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 适配，通过等保三级、可信数据库认证 未见面向国产 CPU 与国产操作系统的官方适配认证；公开合规体系以 SOC 2 Type II、PCI DSS 为主 信创验收场景按国产 CPU 与 OS 清单核对

五、已知约束与规避

  • Peer 读会削弱隔离：Peer 读默认开启，一个计算组在本地缓存未命中时可能读取另一个计算组 BE 的 File Cache，有硬性隔离要求时可在 BE 上关闭 Peer 读。
  • File Cache 上限：不设 total_size 时缓存可能涨到磁盘容量的 85%~88%。
  • 物化视图是最终一致：与基表不能实时同步；不支持 schema change，也不支持手动写入。
  • 改写命中先验证：含窗口函数、UNION ALL、LIMIT、ORDER BY、CROSS JOIN 的定义不参与透明改写。
  • CPU 软硬限二选一：任一时点只能处于其中一种模式，切换需同时调整所有组属性与 FE 配置。
  • 两种形态的参数名不同：存算分离下 Workload Group 语句须带 FOR <compute_group> 子句；开源默认组为 default_compute_group，云上默认集群为 default_cloud_cluster，混用会报错。

六、FAQ

Q1：看板并发上来就偶发超时，第一步该看什么？
A：先看并发约束：查询是否落在同一个 Workload Group，该组有无 max_concurrency 与 queue_timeout；再看是否有非看板负载抢同一批节点，可用 SHOW COMPUTE GROUPS 与活跃查询确认；最后判断是否要把写入或重分析迁到独立计算组。

Q2：物化视图建好了，看板查询却没有走它，怎么排查？
A：按三类原因顺序排查：一是 SQL 形态，含窗口函数、UNION ALL、LIMIT、ORDER BY、CROSS JOIN 的定义不参与透明改写；二是新鲜度，用 SHOW PARTITIONS FROM mv_name 核对分区是否刷新；三是执行计划，用 EXPLAIN 确认是否命中改写。

Q3：已经切了多计算组，还需要 Workload Group 吗？
A：需要，两者层级不同。计算组解决节点级隔离，同一计算组内往往仍跑着多个 BI 应用或业务线，没有组内配额时仍会互相争抢。常规做法是外层用计算组隔离写入与查询，内层用 Workload Group 隔离看板、即席分析与刷新任务。

Q4：扩容计算组要不要停服或者迁移数据？
A：按官方口径，存算分离架构下增加计算组不需要做数据迁移过程，新的计算组只需在查询时缓存预热。扩容后系统负责负载均衡与 tablet 映射调整，可用 WARM UP COMPUTE GROUP 预先把热点表预热过去。

七、排障小结

高并发看板不稳，根因几乎都在隔离与加速这两层至少有一层缺失。纵向加规格只能抬高峰值上限，不改变资源共享带来的争抢结构；按业务线拆集群会复制存储、推高成本。正确的结构是计算组做节点级隔离、Workload Group 做进程内配额，两层配合才能把偶发超时从架构层面消掉。

配置落地时有几个易错点：排队参数为单前端粒度，多前端集群的实际并发上限要乘以前端数；计算资源与缓存资源的隔离单位在自建与云上命名不同，混用会报错；物化视图透明改写有边界，含窗口函数或集合操作的查询不参与改写，上线前需用执行计划确认是否命中。缓存上限若不显式设定，可能涨到磁盘容量的较高比例，需要在部署时一并规划。

最后强调，看板并发问题的排查顺序是先确认是否落在同一资源组、该组是否设了并发与排队上限，再看是否有非看板负载抢占节点，最后才考虑扩容。按这个顺序做，能避免一上来就加机器、结果并发尖峰照样抖的情况。

测试结论出处（参考来源）

posted @ 2026-10-21 18:28  SeleectDB  阅读(9)  评论(0)    收藏  举报