GBase 8a 资源管理与连接隔离：多业务共用集群的资源治理实践

当一套 GBase 8a 集群同时承载报表查询、ETL 加载、即席分析、数据对账等多类业务时，资源争抢是最常见的运维痛点。一条失控的大查询可以把整个集群的内存吃满，让其他所有业务卡住。本文从连接层、查询层、资源层三个维度讲解如何在 GBase 8a 中实现合理的资源隔离，让不同优先级的业务在同一套集群上稳定共存。

---

一、资源争抢的根源分析

在讨论解决方案之前，需要先理解 GBase 8a 多业务场景下资源争抢的具体机制，才能知道在哪里干预最有效。

GBase 8a 的每条分析查询在执行时，会在所有 gnode 上同时启动 Fragment 线程并占用内存。当内存缓冲区（heap_large、buffer_hj 等）被某个大查询占满时，其他查询的 Fragment 会进入等待状态，等待内存释放——这就是"一条大查询拖慢整个集群"的底层原因。与此同时，磁盘 I/O 也是共享资源，加载任务和查询任务同时进行时，I/O 竞争会让两者都变慢。

在连接层，gcluster 的总连接数是有限的（由 max_connections 控制）。如果 ETL 程序用了大量连接做批量写入，正常的业务查询连接可能被拒绝，出现"Too many connections"错误。反过来，如果大量 BI 用户同时打开仪表盘，每个用户触发几条查询，连接数很快耗尽，ETL 任务也无法连接。

理解了这些机制，就能明白资源治理的目标：在连接层控制各类业务的连接配额，防止某类业务独占连接池；在查询层设置查询超时和资源上限，防止单条失控查询拖垮集群；在调度层区分业务优先级，确保高优先级业务的资源得到保障。

---

二、连接层：分账号的连接配额管理

GBase 8a 通过用户级别的最大连接数来实现连接配额，这是最简单也最基础的隔离手段。不同的业务使用不同的数据库账号，每个账号设置与其业务并发需求相匹配的连接上限，防止任何一类业务独占全部连接资源。

这种分账号的做法还有一个重要的副作用：在 gcluster system.log 中，每条 SQL 都带有执行账号的信息。当出现性能问题时，可以通过账号快速判断是哪类业务引发的，缩短问题定位时间。如果用同一个账号承载所有业务，日志里的查询来源就无从区分。

-- 创建各业务专用账号，并设置连接上限

-- 报表查询账号：并发用户多但单查询资源消耗可控
CREATE USER 'bi_user'@'10.168.10.%'
    IDENTIFIED BY 'Bi#Pwd!2024'
    WITH MAX_USER_CONNECTIONS 30;

-- ETL 加载账号：并发连接少但单次操作耗时长
CREATE USER 'etl_user'@'10.168.10.%'
    IDENTIFIED BY 'Etl#Pwd!2024'
    WITH MAX_USER_CONNECTIONS 5;

-- 即席分析账号：数据工程师使用，查询复杂度高
CREATE USER 'analyst'@'10.168.10.%'
    IDENTIFIED BY 'Ana#Pwd!2024'
    WITH MAX_USER_CONNECTIONS 10;

-- 监控账号：专用于 DBA 巡检和监控脚本
CREATE USER 'monitor'@'10.168.10.%'
    IDENTIFIED BY 'Mon#Pwd!2024'
    WITH MAX_USER_CONNECTIONS 5;

-- 紧急维护账号：DBA 专用，不限连接数，确保集群异常时 DBA 能连入
CREATE USER 'dba_admin'@'10.168.10.50'
    IDENTIFIED BY 'Dba#Admin!2024';
    -- 不设 MAX_USER_CONNECTIONS，保证 DBA 在任何情况下都能连接

设置连接配额后，需要定期验证各账号的实际连接使用情况，判断配额是否合理：

-- 查看当前各账号的连接数分布
SELECT
    user,
    COUNT(*)                                    AS current_connections,
    MAX(time)                                   AS max_idle_seconds,
    SUM(CASE WHEN command='Query' THEN 1 ELSE 0 END) AS active_queries
FROM information_schema.processlist
GROUP BY user
ORDER BY current_connections DESC;

-- 查看某账号的最大连接数设置
SELECT user, host, max_user_connections
FROM gclusterdb.user
WHERE user IN ('bi_user', 'etl_user', 'analyst');

如果某个账号长期处于连接上限（current_connections = max_user_connections），说明该账号的配额设置过低，需要调整；如果某个账号长期只用了配额的 10%，说明配额设置过于宽松，可以适当降低以留出余量给其他业务。配额管理不是一次性配置，需要根据业务增长和实际使用情况定期复查调整。

---

三、查询层：超时控制与查询熔断

连接配额控制了并发连接数，但无法阻止单条查询占用过多资源。一条没有合理 WHERE 条件的即席查询，扫描几十亿行数据，在 gnode 上持续占用内存和 CPU 数小时，会让所有其他查询都处于等待状态。查询层的熔断机制是应对这类"流氓查询"的必要手段。

3.1 超时参数配置

GBase 8a 通过多个超时参数共同控制查询的最大执行时间。对于不同类型的业务账号，可以在会话建立时动态设置超时参数，实现差异化的超时策略。

# gcluster 的 gbase.cnf：全局默认超时配置

# 客户端等待 SQL 结果的最长时间（秒）
# 报表类业务：设为 120 秒，超时则返回错误，避免用户长期等待
# ETL 类业务：设为 7200 秒，长时间加载任务需要宽松超时
# 全局值设为报表标准，ETL 账号在连接时动态覆盖
gcluster_connect_net_read_timeout  = 120
gcluster_connect_net_write_timeout = 120

# 锁等待超时（秒）：防止 DDL 操作长期等待锁
gcluster_lock_timeout = 30

-- ETL 账号在连接后立即设置更宽松的超时
-- 通常在 ETL 脚本的初始化阶段执行
SET SESSION gcluster_connect_net_read_timeout  = 7200;
SET SESSION gcluster_connect_net_write_timeout = 7200;

在 JDBC 层面，不同业务的数据源连接字符串应该使用不同的 socketTimeout 值：

// 报表查询数据源：2 分钟超时
String biUrl = "jdbc:gbase://host:5258/db?socketTimeout=120000";

// ETL 数据源：2 小时超时
String etlUrl = "jdbc:gbase://host:5258/db?socketTimeout=7200000";

3.2 主动终止失控查询

当发现某条查询已经运行了不合理的时间，DBA 需要能够主动终止它，而不是任其继续占用资源。

-- 查找运行时间超过 10 分钟的查询
SELECT
    id,
    user,
    host,
    db,
    time,
    state,
    LEFT(info, 200) AS sql_snippet
FROM information_schema.processlist
WHERE time > 600
  AND command = 'Query'
ORDER BY time DESC;

-- 终止指定的查询（需要 SUPER 权限或 PROCESS 权限）
KILL QUERY 12345;   -- 只终止查询，保留连接
KILL 12345;         -- 终止连接（查询也随之终止）

主动终止查询应该谨慎操作，在终止之前确认：这条查询是否是业务系统的关键链路（比如是报表刷新的主查询，终止后会影响用户体验）；终止后的重试机制是否健全（应用层会自动重试还是会产生异常）；这条查询慢的根因是什么，终止后是否需要立即优化才能避免重复发生。

3.3 自动化慢查询熔断脚本

对于运维资源有限的团队，可以部署一个定时运行的自动化脚本，当检测到超长时间查询时自动终止并告警，而不是等 DBA 人工发现：

#!/bin/bash
# auto_kill_slow_queries.sh：自动终止超时查询，每 5 分钟执行一次

GCCLI="gccli -u dba_admin -p'Dba#Admin!2024'"
MAX_QUERY_TIME=1800   # 超过 30 分钟的查询自动终止
WEBHOOK="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY"

# 查找超时查询
SLOW_QUERIES=$($GCCLI -e "
    SELECT id, user, time, LEFT(info, 100) AS sql_snippet
    FROM information_schema.processlist
    WHERE time > $MAX_QUERY_TIME
      AND command = 'Query'
      AND user != 'etl_user'   -- ETL 账号豁免，允许长时间运行
    " 2>/dev/null | grep -v "^id" | grep -v "^$")

if [ -n "$SLOW_QUERIES" ]; then
    # 提取查询 ID 并终止
    KILL_IDS=$(echo "$SLOW_QUERIES" | awk '{print $1}' | grep -E '^[0-9]+$')
    
    for qid in $KILL_IDS; do
        $GCCLI -e "KILL QUERY $qid" 2>/dev/null
        echo "[$(date)] 已终止查询 ID=$qid"
    done
    
    # 发送告警
    MSG="【GBase 8a 慢查询告警】以下查询已被自动终止（超过 ${MAX_QUERY_TIME} 秒）:\n${SLOW_QUERIES}"
    curl -s -X POST "$WEBHOOK" \
        -H "Content-Type: application/json" \
        -d "{\"msgtype\":\"text\",\"text\":{\"content\":\"$MSG\"}}"
fi

这个脚本有一个重要设计细节：ETL 账号被豁免，不会被自动终止。这是因为 ETL 的大批量加载任务天然需要较长时间，不应该被当作失控查询处理。对于不同账号的超时策略，通常的分级是：BI 查询 2~5 分钟、即席分析 15~30 分钟、ETL 不限制（由 DBA 人工判断）。

---

四、资源层：Virtual Cluster 的物理隔离

当连接配额和查询超时无法满足更严格的隔离需求时，GBase 8a 的 Virtual Cluster（VC）提供了物理层面的资源隔离——不同业务使用不同的 gnode 节点集合，CPU、内存、磁盘 I/O 完全不共享。VC 的详细配置在第 16 篇已有完整介绍，这里着重讨论资源管理视角下的 VC 划分策略。

VC 划分的基本原则是按业务的资源竞争程度和优先级差异来分组，而不是按业务数量来分组。几个需要配合的小业务放在一个 VC 里共享资源，互相争抢是可接受的；一个会产生大量 I/O 的 ETL 加载业务和一个要求低延迟响应的报表查询业务，必须放在不同的 VC 里，否则加载的 I/O 峰值会严重影响报表的响应时间。

典型的 VC 划分方案：

VC1（高性能节点，SSD）：在线报表和即席查询，低延迟优先
  - 账号：bi_user、analyst
  - gnode 配置：高内存（128GB）、NVMe SSD

VC2（标准节点，HDD）：ETL 加载和数据处理，吞吐量优先
  - 账号：etl_user
  - gnode 配置：大容量（HDD）、高 I/O 并发

VC3（低配节点）：数据质量检查、对账、统计信息更新等后台任务
  - 账号：qa_user、monitor
  - gnode 配置：低配置节省成本

这种分法让不同特性的工作负载在物理上互相隔离，VC1 的报表查询再复杂也不会影响 VC2 的 ETL 加载速度，VC2 的加载 I/O 再高也不会让 VC1 的报表响应时间变差。

---

五、调度层：错峰执行的时间窗口管理

除了空间维度的资源隔离，时间维度的错峰调度也是降低资源竞争的有效手段，而且不需要任何额外的集群配置。

ETL 加载任务通常在凌晨业务低峰期执行，这与报表查询的高峰期（白天工作时间）天然错峰。但在某些场景下，ETL 任务和报表查询会在同一时间窗口内共存：ETL 任务加载到一半、报表用户开始上班；或者日报刷新的查询与当天首批 ETL 加载重叠。这种情况下，在调度系统（如 Airflow、DolphinScheduler）中设置合理的任务依赖和时间约束，能大幅减少非必要的资源竞争：

在调度层面，通常的时间窗口划分建议是：凌晨 0 点到 6 点是 ETL 加载的独占时间窗口，不安排任何对外的分析查询；早上 6 点到 8 点是数据质量检查和统计信息更新的窗口，ETL 已完成，报表用户还未上班；白天 8 点到 18 点是报表查询的主要时间，避免安排大规模 ETL 加载；傍晚 18 点到 24 点是次要 ETL 和对账任务的窗口，报表查询量开始减少。这套时间窗口当然需要根据实际业务的数据更新和使用节奏来调整，不是一成不变的框架，而是一个规划起点。

---

六、资源使用情况的持续监控

资源管理配置上线后，需要持续监控实际效果，才能及时发现配置不合理的地方并调整。以下是几个关键的资源监控 SQL，建议纳入日常巡检：

-- 实时资源使用概览：连接数、活跃查询数、最长运行时间
SELECT
    user,
    COUNT(*)                                         AS total_connections,
    SUM(CASE WHEN command = 'Query'   THEN 1 ELSE 0 END) AS active_queries,
    SUM(CASE WHEN command = 'Sleep'   THEN 1 ELSE 0 END) AS idle_connections,
    MAX(CASE WHEN command = 'Query' THEN time ELSE 0 END) AS longest_query_sec
FROM information_schema.processlist
GROUP BY user
ORDER BY active_queries DESC;

-- 各节点内存使用情况（需开启 _gbase_session_memory_stat）
SELECT
    node_name,
    ROUND(SUM(memory_used) / 1073741824, 2) AS total_mem_gb,
    COUNT(DISTINCT session_id)               AS active_sessions
FROM gclusterdb.session_memory_stat
GROUP BY node_name
ORDER BY total_mem_gb DESC;

-- 过去 1 小时各账号的慢查询分布
SELECT
    SUBSTRING_INDEX(user_host, '[', 1)       AS user_name,
    COUNT(*)                                  AS slow_query_count,
    ROUND(AVG(query_time), 2)                AS avg_sec,
    ROUND(MAX(query_time), 2)                AS max_sec,
    SUM(rows_examined)                        AS total_rows_scanned
FROM gclusterdb.slow_log
WHERE start_time >= NOW() - INTERVAL 1 HOUR
GROUP BY user_name
ORDER BY slow_query_count DESC;

通过长期积累这些监控数据，能够发现资源使用的规律性模式：哪个时间段是资源高峰、哪个账号的慢查询最多、哪个节点的内存经常接近上限。这些数据是优化连接配额、调整查询超时、以及制定 VC 扩容计划的重要依据。资源管理不是一次性的工程，而是一个基于数据持续迭代的运维过程。