2. 实时监控体系架构:数据采集层、实时计算层、存储层、展示层整体架构设计

催收触达看板的实时监控体系,本质是一条从“原始事件”到“业务决策”的低延迟数据管道。本章将体系拆解为四个核心层次:数据采集层、实时计算层、存储层与展示层。每一层承担明确的职责,层与层之间通过标准协议解耦,确保整体架构可水平扩展、可故障恢复。

架构设计原则:催收场景对延迟极度敏感——从坐席外呼动作发生到看板指标刷新,端到端延迟必须控制在 5 秒以内。因此,本架构优先采用流式处理(Streaming)而非批处理(Batch),并避免在关键路径上引入磁盘 I/O 瓶颈。

2.1 四层架构总览

下图展示了实时监控体系的完整数据流向。从催收系统产生的原始事件日志,经过采集、计算、存储,最终在展示层以看板形式呈现给风控与运营人员。

实时监控体系四层架构 数据采集层 催收系统事件日志(外呼、短信、IVR、AI语音) 采集组件:Filebeat / Flume / Kafka Connect 实时计算层 流处理引擎:Apache Flink / Spark Streaming 核心逻辑:窗口聚合、异常检测、指标计算、规则匹配 存储层 实时指标存储:Redis / Apache Druid / ClickHouse 明细日志存储:Elasticsearch / HDFS(离线归档) 展示层:Grafana / Superset / 自研看板

2.2 数据采集层:事件捕获与缓冲

采集层是管道的起点,负责从催收系统的各个模块中无侵入地捕获原始事件。催收系统产生的典型事件包括:坐席外呼开始/结束、短信发送状态回执、IVR按键轨迹、AI语音对话节点等。

事件类型 数据源 采集方式 典型字段
外呼事件 CTI 日志 / SIP 信令 日志文件采集(Filebeat) 坐席ID、客户ID、开始时间、结束时间、结果码
短信事件 短信网关 API 回调 HTTP 推送 → Kafka 手机号、模板ID、发送时间、状态(成功/失败)
IVR 事件 IVR 平台日志 Syslog / Flume 通话ID、按键值、节点ID、持续时间
AI 语音事件 AI 对话引擎日志 Kafka Connect 会话ID、意图标签、情绪评分、转写文本
关键设计要点:所有采集组件必须支持 断点续传(offset 管理)和 至少一次语义(At-Least-Once)投递。采集端引入 Kafka 作为统一缓冲层,既削峰填谷,又为下游多消费者提供数据重放能力。

2.3 实时计算层:流处理与异常检测

实时计算层是整个架构的“大脑”。它从 Kafka 消费原始事件,执行窗口聚合、指标计算、规则匹配等核心逻辑。催收场景下,计算层需要处理两类主要任务:

  • 常规指标计算:按 1 分钟/5 分钟窗口,统计坐席外呼量、接通率、承诺还款率、短信送达率等 KPI。
  • 异常波动检测:基于历史基线(如过去 7 天同一时段均值),判断当前指标是否超出阈值(如接通率骤降 20%),触发告警。

以下是一个基于 Flink 的窗口聚合伪代码示例,展示如何计算每分钟的坐席外呼接通率:

DataStream<CallEvent> events = env
    .addSource(new FlinkKafkaConsumer<>("call_events", ...));

events
    .keyBy(event -> event.getAgentId())
    .window(TumblingProcessingTimeWindows.of(Time.minutes(1)))
    .aggregate(new AggregateFunction<CallEvent, AgentStats, AgentMetrics>() {
        @Override
        public AgentStats createAccumulator() {
            return new AgentStats();
        }
        @Override
        public AgentStats add(CallEvent event, AgentStats stats) {
            stats.totalCalls++;
            if ("ANSWERED".equals(event.getResultCode())) {
                stats.answeredCalls++;
            }
            return stats;
        }
        @Override
        public AgentMetrics getResult(AgentStats stats) {
            double connectRate = stats.totalCalls > 0
                ? (double) stats.answeredCalls / stats.totalCalls * 100
                : 0.0;
            return new AgentMetrics(stats.totalCalls, connectRate);
        }
    })
    .map(metrics -> {
        // 异常检测:如果接通率低于历史基线 20%,标记为异常
        double baseline = getBaseline(metrics.getAgentId());
        if (metrics.getConnectRate() < baseline * 0.8) {
            metrics.setAnomaly(true);
        }
        return metrics;
    })
    .addSink(new FlinkKafkaProducer<>("metrics_output", ...));
注意:实时计算层必须设计 状态后端(如 RocksDB)来维护窗口状态和基线数据。同时,建议将异常检测规则外置到配置中心(如 Apollo/Nacos),支持热更新,避免因规则变更而重启作业。

2.4 存储层:分层存储与查询优化

存储层需要同时满足低延迟查询(看板秒级刷新)和高吞吐写入(每秒数万事件)两个矛盾需求。因此,采用分层存储策略:

存储类型 存储内容 选型方案 查询场景
热存储 最近 1 小时的聚合指标 Redis(Hash + Sorted Set) 看板实时曲线、Top-N 坐席排名
温存储 最近 7 天的分钟级聚合数据 Apache Druid / ClickHouse 趋势分析、同比/环比对比
冷存储 原始事件日志(全量) Elasticsearch / HDFS 明细追溯、离线分析、审计

下图展示了存储层内部的数据流转与查询路径:

存储层分层架构与查询路径 实时计算输出 热存储:Redis 1小时聚合指标 温存储:Druid/ClickHouse 7天分钟级聚合 冷存储:ES/HDFS 全量原始日志 展示层:Grafana / 自研看板

2.5 展示层:看板渲染与交互

展示层直接面向风控运营人员、团队主管和高级管理层。它从存储层查询数据,以图表、表格、告警列表等形式呈现。催收触达看板的展示层需要支持以下核心能力:

  • 实时曲线:每秒刷新外呼量、接通率、承诺还款率等关键指标,支持按坐席、队列、产品线等维度下钻。
  • 异常告警弹窗:当计算层检测到异常波动时,看板顶部弹出告警条,并高亮对应指标。
  • 历史对比:支持选择“今日 vs 昨日”或“今日 vs 上周同期”的叠加曲线。
  • 明细跳转:点击聚合指标可跳转到对应的原始事件明细列表(从 ES 查询)。
选型建议:如果团队技术栈以 Java/大数据为主,推荐 Grafana + Druid/ClickHouse 组合,Grafana 原生支持实时刷新和告警。如果团队有前端自研能力,可基于 ECharts + WebSocket 构建定制化看板,实现更灵活的交互逻辑。

2.6 架构关键指标总结

层次 核心组件 延迟要求 扩展性策略
数据采集层 Filebeat / Flume / Kafka < 1 秒(端到端入 Kafka) Kafka 分区扩展 + 采集端水平扩容
实时计算层 Flink / Spark Streaming < 3 秒(事件到指标输出) TaskManager 并行度调整 + 状态后端优化
存储层 Redis / Druid / ClickHouse / ES < 1 秒(查询响应) 读写分离 + 数据分片 + 冷热数据自动迁移
展示层 Grafana / 自研看板 < 1 秒(页面渲染) CDN 静态资源加速 + 查询缓存