跳到正文

更多文章

数据周刊|BigQuery 开始回流数据库,AI 问数也终于能看 token 账单 上游只改 1 个字段,17 张报表一起报错:先查哪 3 层依赖 财务月结后订单金额少了 12 万:分析师用 5 张对账表定位差异 仓库说缺货,系统却显示还有 800 件:零售分析师先核对哪 4 个库存时间点 数据负责人要删 3 年日志,审计和成本各说各话:用 4 个维度定保留期限
供应商文件每天准时到,3 个字段却悄悄变了:数据分析师用 9 条门槛验收外部数据

早上九点零七分,群里先来了一句:“文件没迟到。”

数据分析师小林刚把昨晚供应商发来的门店销售文件接进仓库,经营群里就有人追问:为什么华东区的“已完成订单”突然少了两成?供应商查了传输记录,文件在凌晨两点准时落到 SFTP,大小也和前几天差不多。任务绿了,行数有了,报表自然跟着更新。

十几分钟后,小林才找到三个小变化:store_id 从六位字符变成了不补零的数字,订单状态里多了一个 PARTIAL_DONE,金额字段开始包含原本单列的服务费。

三个字段,没有一个让文件传输失败。可是它们足够让门店关联丢失、完成订单被漏算、销售额和财务口径错开。文件确实准时到了,只是到的已经不是昨天那份数据。

这类场景我见过不止一次。大家花很多力气约定“每天几点前交付”,却很少约定“交付的东西必须保持什么含义”。于是数据 SLA 只管门铃有没有准时响,不管门口来的是快递,还是一只拴着绳子的山羊。

外部数据验收真正要守住的,不是“文件收到”这一件事,而是它能不能安全地进入下游决策。下面这 9 条门槛,就是给这段路装上九道不太漂亮、但很有用的门。

外部数据从准时送达走到可用于经营分析,需要跨过九道验收门槛

先把交付、验收和使用分开

很多事故从目录结构就已经开始了。

供应商文件一落地,任务便直接覆盖生产表;生产表一更新,看板和模型立刻读取。交付、验收、发布被塞进一条直线,任何异常都只能在读者看到错数之后再补救。此时即使十分钟内修好,也已经有人截了图、开了会,甚至据此做了补货判断。

更稳妥的路径至少有三层:

  1. 原始区:保存供应商原文件、文件名、到达时间、校验值和批次号,不改内容。
  2. 隔离区:运行结构、内容和业务检查;失败批次留在这里,不覆盖上一版可用数据。
  3. 发布区:只有达到约定门槛的批次才能进入,并生成一份验收结果。

这三层不一定对应三套昂贵平台。小团队用三个目录、三张表也能做。关键不是工具,而是让“收到”与“可用”之间有一道明确的停顿。

W3C 的 Data Quality Vocabulary 提醒了一件很朴素的事:数据质量并没有脱离场景的唯一答案,发布者需要提供质量度量、政策和来源信息,让使用者判断数据是否适合自己的用途。换到供应数据场景,就是不能只说“这是一份 CSV”,还要说明它通过了什么检查,在哪些条件下可以拿来做经营判断。

第一组:先确认收到的是哪一批东西

前三道门管的是交付物本身。它们看起来基础,却最容易被“任务成功”四个字糊弄过去。

门槛 1:批次身份必须唯一

每个交付批次至少要有四个身份字段:数据日期、生成时间、供应商批次号、文件版本。只靠文件名里的日期不够,因为供应商可能重发、补发,也可能在同名文件里改内容。

验收时要问:

  • 这是 8 月 4 日的全量,还是 8 月 4 日 23:00 前的增量?
  • 重发批次是替换上一批,还是在上一批基础上追加?
  • 同一批次号再次出现时,文件校验值是否变化?

如果批次身份说不清,后面所有对账都会变成猜谜。最小做法是建立一张交付登记表,把 data_dategenerated_atbatch_idversionreceived_at 一起记下来。

门槛 2:文件必须完整且可重现

“能打开”不等于完整。传输中断、重复拼接、压缩包内部缺文件,都可能留下一份看起来像样的半成品。

至少检查文件数量、压缩包清单、字节数、行数和校验值。校验值可以用 SHA-256 一类摘要算法:同一内容会得到同一串摘要,内容哪怕只改一个字节,结果也会变化。它不能证明业务正确,但能证明你验收和留档的是同一份东西。

这里还要保留原文件。否则两周后供应商说“我们当时发的不是这版”,团队只能围着聊天记录互相回忆。人的记忆在对账会上很有戏剧性,可惜不太适合当证据。

门槛 3:交付窗口与数据窗口都要合格

文件在凌晨两点前到达,只能说明传输准时。还要检查数据覆盖到什么时候。

例如供应商 01:50 交付,但文件里的最大业务时间只到前一天 20:00;从传输 SLA 看它满分,从经营日报看却少了四个小时。验收记录应该同时包含:

  • 约定到达时间与实际到达时间;
  • 约定数据截止时间与实际最大业务时间;
  • 是否缺少应有的日期、小时、门店或分区。

把“准时交付”和“数据新鲜”拆开,才不会出现文件守时、内容迟到的怪事。

原始区、隔离区和发布区把收到文件与真正可用分开

第二组:确认结构没有在黑暗里换骨头

第四到第六道门处理 schema,也就是字段结构和表达规则。字段名没变,不代表含义没变;字段类型变了,也不一定会立刻报错。最麻烦的变化往往“还能跑”。

门槛 4:字段集合与顺序变化必须被识别

先比较字段新增、删除、重命名和顺序变化。对按列位置读取的旧程序,顺序变化可能把“数量”读成“金额”;对按字段名读取的程序,删除字段会直接失败,悄悄新增字段则可能长期无人处理。

验收规则不要只有“字段数等于 38”。更有用的是保存一份明确的字段清单,并为每种变化指定动作:

变化默认动作允许条件
删除必需字段拒收
重命名字段拒收双方确认迁移窗口并提供映射
新增可选字段暂停发布补齐定义、类型和生效日期后放行
调整字段顺序告警或拒收读取方式已验证不依赖位置

PRO 会员专属

本文为 PRO 会员专属内容,成为会员即可阅读全文。

PRO ¥199/年 · Pro 专属文章 + 2300+ 知识文档 + 会员社群

Elazer (石头)
Elazer (石头)

11 年数据老兵,从分析师到架构专家。用真实经历帮数据人少走弯路。

加入免费社群

和数据从业者一起交流成长

了解详情 →

成为会员

解锁全部内容 + 知识库

查看权益 →

1v1 咨询

有具体职业困惑?一小时说清楚

预约咨询 →
← 上一篇 数据负责人要删 3 年日志,审计和成本各说各话:用 4 个维度定保留期限 下一篇 → 仓库说缺货,系统却显示还有 800 件:零售分析师先核对哪 4 个库存时间点