📚 课程目录第4章巡检架构

4. 巡检架构：多集群Catalog容量巡检系统的整体架构设计与组件职责

在多集群环境下，Catalog 容量巡检系统需要具备跨集群数据采集、统一存储、策略驱动分析、分级告警与可视化四大核心能力。本章从系统分层视角出发，定义各组件职责与交互流程，确保巡检系统可水平扩展、故障隔离且运维成本可控。

4.1 整体架构分层模型

系统采用四层架构：采集层 → 存储与计算层 → 分析决策层 → 展示与告警层。每层职责明确，层间通过标准 API 或消息队列解耦。

层级	核心组件	主要职责
采集层	Agent / Exporter / 定时任务	从各集群 Catalog 元数据服务拉取库、表、分区、文件数、存储量等原始指标
存储与计算层	时序数据库 + 对象存储 + 流/批计算引擎	持久化指标、聚合降采样、计算水位趋势与基线
分析决策层	规则引擎 + 容量模型 + 异常检测模块	基于阈值、同比、环比、预测模型判断水位是否超限
展示与告警层	Dashboard + 告警中心 + 工单系统	可视化水位大盘、分级推送告警、触发自动扩缩容或清理流程

架构设计原则：采集层无状态，支持水平扩缩；存储层使用多副本保障高可用；分析层策略可热加载；展示层支持多租户隔离。

4.2 核心组件职责详解

4.2.1 采集层组件

Catalog Agent：部署在每个集群的边缘节点，通过 JDBC / Thrift / REST API 连接 Hive Metastore、Trino、Spark Catalog 等元数据服务，定时（默认 5 分钟）采集以下指标：

库/表/分区数量
总存储量（GB/TB）
文件数 & 平均文件大小
分区时间分布（冷热数据比例）
最近访问时间戳

指标转换器：将原始元数据转换为统一指标模型（Metric Schema），添加集群标签、Catalog 类型、环境标签等维度。
数据发送器：通过 Kafka / gRPC 将指标推送到中心存储层，支持失败重试与背压控制。

4.2.2 存储与计算层组件

时序数据库（VictoriaMetrics / Thanos）：存储水位指标，保留 90 天原始数据，支持 PromQL 查询与降采样。
对象存储（MinIO / S3）：存储全量快照与历史备份，用于离线分析与审计。
流计算引擎（Flink / Spark Streaming）：实时聚合多集群指标，计算每分钟/每小时/每日的容量水位汇总。
批处理引擎（Spark / Presto）：每日凌晨运行全量容量报告，生成趋势预测与异常检测模型。

4.2.3 分析决策层组件

规则引擎：支持 YAML 配置的多级阈值规则，例如：

rules:
  - name: "表存储量超限"
    condition: "catalog_storage_bytes > 1TB"
    severity: "warning"
    action: "notify_owner"
  - name: "分区数激增"
    condition: "partition_count_delta > 1000 && time_window=1h"
    severity: "critical"
    action: "auto_trigger_compaction"

容量模型：基于历史数据建立线性回归或 Holt-Winters 预测模型，输出未来 7/30 天的水位预测。
异常检测模块：使用 3-sigma 或 MAD 算法检测突发增长或异常下降，避免误告警。

4.2.4 展示与告警层组件

Grafana Dashboard：按集群、Catalog、库、表四级下钻展示水位热力图、趋势曲线、Top-N 大表。
告警中心：对接钉钉/企微/邮件/PagerDuty，支持告警静默、升级、聚合与认领。
工单系统：自动创建容量治理工单，关联责任人、SLA 与操作记录。

4.3 系统交互流程

定时触发：中心调度器（如 Airflow / Quartz）每 5 分钟下发采集任务到各集群 Agent。
数据采集：Agent 并行拉取 Catalog 元数据，转换为统一指标格式，发送至 Kafka。
实时写入：Flink 消费 Kafka 消息，写入 VictoriaMetrics 并同时备份到对象存储。
规则匹配：规则引擎实时查询 VictoriaMetrics，匹配阈值规则，产生告警事件。
预测分析：每日凌晨 Spark 作业读取历史数据，更新容量预测模型，生成日报。
展示与处置：Grafana 展示水位大盘，告警中心分发事件，工单系统跟踪治理进度。

实战建议：在采集层增加 health_check 端点，用于监控 Agent 自身状态；若 Agent 连续 3 次采集失败，自动切换至备用 Catalog 连接串，避免单点故障导致数据缺失。

4.4 架构示意图

下图展示了多集群 Catalog 容量巡检系统的完整组件拓扑与数据流方向：

4.5 多集群数据流与隔离设计

针对多集群场景，系统在采集层和存储层引入租户隔离与数据路由机制：

集群标签：每个 Agent 上报指标时携带 cluster=prod-01、region=cn-beijing 等标签，VictoriaMetrics 按标签分区存储。
写入限流：每个集群的 Agent 有独立的 Kafka Topic 分区，避免某个集群数据量突增影响其他集群。
查询隔离：Grafana 数据源配置 cluster 变量，不同团队只能查看所属集群的水位数据。

避坑提醒：不要将所有集群的 Catalog 指标写入同一个时序表而不加标签分区。当集群数量超过 20 个时，查询性能会急剧下降，且误告警难以定位。务必在采集层就做好标签标准化。

4.6 组件高可用与容错策略

组件	高可用策略	故障恢复时间目标（RTO）
Catalog Agent	多副本部署 + 健康检查 + 自动重启	< 30 秒
Kafka	3 副本 + ISR 机制 + 跨 AZ 部署	< 1 分钟
VictoriaMetrics	多副本 + 数据复制 + 自动故障转移	< 2 分钟
规则引擎	无状态 + 负载均衡 + 热加载配置	< 10 秒
告警中心	主备模式 + 消息队列持久化	< 1 分钟

通过上述架构设计与组件职责划分，多集群 Catalog 容量巡检系统能够实现分钟级数据采集、实时水位分析、精准告警与自动化治理，为大规模数据平台提供可靠的容量保障能力。