4、数据采集层设计：采集框架搭建、定时任务调度、数据格式化处理

好，咱们接着往下聊。上一章我们把通信协议层给捋顺了，数据能收上来了。但收上来之后呢？不能就这么扔在那吧？你得有个“管家”去管它。这个管家，就是今天要讲的数据采集层。

说白了，数据采集层就是整个监控系统的“心脏”。它负责三件事：搭框架、定节奏、做整理。我做了这么多年运维，见过太多系统栽在这一层上。要么是框架太死板，扩展性差；要么是调度乱了套，数据打架；要么是格式五花八门，下游根本没法用。

嗯，咱们一个一个来解决。

4.1 采集框架搭建：别把鸡蛋放一个篮子里

我个人习惯，设计采集框架时，先想清楚一个问题：采集器和被采集设备之间，是什么关系？

一对多？多对一？还是多对多？

基站场景下，通常是一对多。一个采集器（比如一台工控机或边缘网关），要管几十上百个基站设备。所以框架必须支持并发采集，不能一个一个轮询，那效率太低了。

我推荐用生产者-消费者模式。生产者负责下发采集指令，消费者负责接收和处理返回的数据。中间用个队列缓冲一下，避免高并发时把系统打崩。

给你看个简化版的框架结构：

// 伪代码，别纠结语法
class CollectorFramework {
    // 采集任务队列
    Queue<Task> taskQueue;
    
    // 生产者：生成采集任务
    void produceTasks() {
        for (每个基站设备) {
            Task task = new Task(设备ID, 采集指令);
            taskQueue.push(task);
        }
    }
    
    // 消费者：执行采集
    void consumeTasks() {
        while (true) {
            Task task = taskQueue.pop();
            // 开个线程去采集
            new Thread(() -> {
                Result result = execute(task);
                // 结果丢给下一个环节
                resultQueue.push(result);
            }).start();
        }
    }
}
我的小经验：队列长度一定要设上限。我曾经在一个项目里忘了设，结果设备批量掉线，任务积压了几十万条，直接把内存撑爆了。后来我学乖了，队列满了就丢弃旧任务，保新弃旧。

4.2 定时任务调度：别让采集变成“乱采集”

框架搭好了，接下来就是调度。什么时候采？多久采一次？采失败了怎么办？

你想想看，基站设备那么多，不可能所有设备都用同一个采集频率。有些关键参数（比如电压、温度）需要秒级采集，有些统计类数据（比如流量、误码率）分钟级就够了。

我建议用分层调度的思路：

  • 高频层：1-5秒一次，采集告警类、状态类数据
  • 中频层：30秒-5分钟一次，采集性能类数据
  • 低频层：15分钟-1小时一次，采集统计类、配置类数据

调度引擎我常用Quartz或者XXL-JOB。如果你用Java，Quartz很成熟；如果是轻量级场景，自己写个定时器也行。

但要注意一个坑：任务超时处理。

我曾经踩过的坑：有一次，某个基站设备响应特别慢，一个采集任务卡了5分钟。结果后续任务全部排队等待，整个采集链路都堵死了。后来我加了个超时机制，超过30秒没响应就直接标记为失败，丢到重试队列里。

重试策略也得设计好。我一般用指数退避：第一次失败等10秒重试，第二次等20秒，第三次等40秒……最多重试3次。再失败就生成告警，让运维人员去处理。

4.3 数据格式化处理：把“方言”翻译成“普通话”

数据采上来了，但问题来了——不同厂商的基站设备，返回的数据格式五花八门。

有的返回JSON，有的返回XML，还有的返回自定义的二进制流。甚至同一个厂商的不同型号，字段名都不一样。比如A设备叫temperature，B设备叫temp，C设备叫t。

这怎么办？

我的做法是：统一数据模型。不管底层设备怎么传，到了采集层，必须转换成统一的格式。

看个例子：

// 统一数据模型
class UnifiedData {
    String deviceId;      // 设备唯一标识
    String metricName;    // 指标名称（统一命名）
    Double value;         // 数值
    Long timestamp;       // 采集时间戳（统一用毫秒）
    Integer quality;      // 数据质量：0-正常，1-可疑，2-无效
}

然后写个协议适配器，每种设备对应一个适配器。适配器负责把设备原始数据转换成统一模型。

比如：

// 华为设备适配器
class HuaweiAdapter implements DeviceAdapter {
    UnifiedData convert(RawData raw) {
        UnifiedData data = new UnifiedData();
        data.deviceId = raw.get("NE_ID");
        data.metricName = mapMetric(raw.get("PARAM_NAME"));
        data.value = Double.parseDouble(raw.get("VALUE"));
        data.timestamp = System.currentTimeMillis();
        data.quality = 0;
        return data;
    }
}

// 中兴设备适配器
class ZteAdapter implements DeviceAdapter {
    UnifiedData convert(RawData raw) {
        UnifiedData data = new UnifiedData();
        data.deviceId = raw.get("device_id");
        data.metricName = mapMetric(raw.get("metric"));
        data.value = raw.get("val").doubleValue();
        data.timestamp = raw.get("time") * 1000; // 转成毫秒
        data.quality = raw.get("status") == 1 ? 0 : 2;
        return data;
    }
}
核心思想：采集层只负责“采”和“转”，不负责“存”和“用”。把数据格式统一了，下游的存储层、分析层、展示层才能安心干活。

嗯，这里要注意一点：数据质量标记很重要。不是所有采上来的数据都能直接用。比如设备刚重启时，前几秒的数据可能不准；网络抖动时，数据可能丢包。这些都要打上质量标记，让下游自己决定要不要用。

我习惯在格式化处理时，顺便做一下简单的数据清洗：

  • 空值处理：如果某个字段为空，填默认值或标记为无效
  • 范围校验：温度超过100度？明显不合理，标记为可疑
  • 重复去重：同一时间戳的重复数据，只保留最后一条

做完这些，数据才能放心地交给下一层。

好了，数据采集层就聊这么多。总结一下：框架要灵活、调度要分层、格式要统一。这三件事做好了，你的监控系统就成功了一半。下一章咱们讲数据存储层，到时候聊聊怎么把海量数据存得又快又省空间。

← 上一章 📖 返回目录 下一章 →