4、数据源接入与清洗：常见数据源、清洗策略与质量校验

数据源接入，说白了就是让看板能「吃」到数据。这一步要是没做好，后面所有图表都是空中楼阁。我见过太多团队，花了两周搭了个漂亮的看板，结果数据一刷新全是乱码——嗯，源头就没管好。

这一章，我们聊聊怎么把数据从各个地方接进来，怎么洗，怎么验。都是实战里踩过的坑，我尽量说透。

4.1 常见数据源接入方式

治理看板的数据源，无非三大类：关系型数据库、大数据平台、HTTP API。每种接入方式，都有它的脾气。

4.1.1 MySQL 接入

MySQL 是最常见的 OLTP 数据源。我个人习惯用 JDBC 直连，但要注意几个点：

• 连接池配置：别每次查询都新建连接，用 HikariCP 或 Druid 管理
• 只读权限：看板查询一律用只读账号，防止误写
• 超时控制：设置查询超时，避免慢 SQL 拖垮看板

-- 示例：创建只读用户
CREATE USER 'dashboard_ro'@'%' IDENTIFIED BY 'strong_password';
GRANT SELECT ON dashboard_db.* TO 'dashboard_ro'@'%';
FLUSH PRIVILEGES;

4.1.2 Hive 接入

Hive 适合离线大宽表。接入时，我建议用 JDBC + 异步查询 的方式。为什么？因为 Hive 查询慢，同步等的话，看板会卡死。

• 分区裁剪：查询时指定分区字段，避免全表扫描
• 结果缓存：对 T+1 的数据，缓存查询结果，减少重复计算
• 连接数限制：HiveServer2 并发有限，别开太多连接

4.1.3 API 接入

API 接入最灵活，但也最「脏」。常见的有 RESTful 接口、GraphQL、甚至古老的 SOAP。

我总结了一套 API 接入的「三板斧」：

1. 重试机制：网络抖动是常态，指数退避重试 3 次
2. 限流保护：别把对方接口打挂了，用令牌桶控制速率
3. 数据校验：接口返回的字段可能为空、类型不对、甚至缺失

// 伪代码：API 接入模板
function fetchApiData(url, params) {
  const retryCount = 3;
  for (let i = 0; i < retryCount; i++) {
    try {
      const response = await axios.get(url, { params, timeout: 5000 });
      // 校验返回结构
      if (!response.data || !response.data.data) {
        throw new Error('数据格式异常');
      }
      return response.data.data;
    } catch (error) {
      if (i === retryCount - 1) throw error;
      await sleep(Math.pow(2, i) * 1000); // 指数退避
    }
  }
}

4.2 数据清洗策略

数据接进来了，但往往是「脏」的。空值、重复、格式不一致……不清洗，看板就是垃圾进垃圾出。

4.2.1 常见脏数据类型

脏数据类型	典型表现	影响
空值/缺失	NULL、空字符串、'N/A'	聚合计算错误、图表断点
重复数据	完全重复的行、业务主键重复	计数翻倍、趋势失真
格式不一致	日期格式混用、金额单位不统一	排序异常、对比无效
异常值	负数金额、未来日期、超长文本	统计指标被拉偏
逻辑矛盾	下单时间晚于发货时间	业务规则被破坏

4.2.2 清洗策略

清洗不是一刀切。我一般按这个优先级处理：

• 丢弃：对分析无意义的脏数据，直接过滤掉（比如全为空的记录）
• 填充：数值型用均值/中位数填充，类别型用众数或「未知」
• 转换：统一格式，比如日期全部转成 yyyy-MM-dd
• 标记：对可疑数据打标签，保留原始值，供后续人工核查

-- 示例：清洗 SQL（MySQL）
-- 1. 去重
DELETE FROM raw_sales
WHERE id NOT IN (
  SELECT MIN(id) FROM raw_sales GROUP BY order_id, product_id
);

-- 2. 填充空值
UPDATE raw_sales
SET amount = COALESCE(amount, 0)
WHERE amount IS NULL;

-- 3. 标记异常值
UPDATE raw_sales
SET data_quality_flag = '异常-金额为负'
WHERE amount < 0;

4.3 数据质量校验规则

清洗完了，怎么知道数据「能用」？得定规则、做校验。我把它分成三个层次。

4.3.1 完整性校验

检查数据有没有缺胳膊少腿。常用的规则：

• 非空检查：关键字段（如订单ID、时间戳）不能为空
• 记录数检查：今天的数据量不能比昨天少太多（比如少于 80% 就报警）
• 字段覆盖率：每个字段的非空比例要达标

4.3.2 准确性校验

数据对不对，得跟「标准答案」比对。

• 值域检查：年龄在 0-120 之间，金额大于 0
• 格式校验：手机号 11 位，邮箱包含 @
• 业务规则校验：下单时间 ≤ 发货时间 ≤ 签收时间

4.3.3 一致性校验

不同数据源之间，数据得对得上。

• 汇总对比：MySQL 里的订单总数，和 Hive 里的汇总数一致
• 关联校验：订单表的用户 ID，在用户表里都能找到
• 趋势校验：环比波动超过 50% 时，触发人工核查

4.4 数据接入与清洗的整体流程

下面这张图，是我做数据接入时的标准流程。从源头到看板，每一步都有校验，每一步都有记录。

4.5 实战中的几个坑

最后，分享几个我踩过的坑，希望能帮你省点时间。

• 坑一：API 接口突然改字段名。我曾经对接一个第三方数据源，对方悄无声息地把 user_name 改成了 username，看板直接崩了。后来我加了字段映射表和接口 schema 校验，变了就报警。
• 坑二：时区问题。MySQL 存的是 UTC，Hive 存的是东八区，API 返回的是时间戳。不统一时区，看板上的时间线全是乱的。我的做法是：所有数据接入时统一转成 UTC，展示时再转本地时区。
• 坑三：清洗规则「过洗」。有次我写了个清洗规则，把金额为 0 的订单全删了。结果业务方说「0 元订单是活动单，要保留的」——嗯，从那以后，清洗规则上线前我都会拉业务方确认一遍。