数据校验一天跑不完，该把校验下推进仓库还是拉回本机

某天早上报表口径对不上，往前追了三天才定位：上游某个字段悄悄从整型改成了带小数的类型，过滤条件里的等号从此永远匹配不上，日活少算了将近两成。事后补质量校验，团队的第一反应是加机器——单独申请了一台 8 核 32G 的应用服务器跑校验任务，结果还是一天跑不完；而同一时间，数仓那台机器 CPU 大半在空转，晚上八点到凌晨两点才忙一阵。这个画面在数据团队里太常见了：不是算力不够，是算力用错了地方。

校验跑不完的时候，加配置永远是最直觉、也最容易白花钱的一步。真正该先做的是把每条校验规则问一遍：这条规则到底该在哪执行？下面这些判断，是本文后面所有推演的出发点。

一、校验跑不完，多数时候不是机器不够，而是校验被放在了错误的位置。能写成 SQL 的约束却把全表拉到应用服务器内存里算，等于把"扫描"变成了"传输 + 反序列化 + 内存排序"，成本放大一个数量级。

二、把执行位置重排一遍，服务器配置需求会整个变样。同样一批规则，全下推进仓库时你可能只需要扩容仓库的并发配额；全拉到本机时才需要堆内存和本地盘。

三、非空、唯一、值域、枚举、外键存在性这类行内约束，几乎全部应该下推。它们是仓库最擅长的事，拉出来跑属于纯浪费。

四、跨行去重与跨表对账能不能下推，取决于连接键和数据分布，不取决于你的校验框架支持什么功能。键分布好的能下推，键倾斜严重的下推会把仓库拖垮。

五、新鲜度与时效校验基本不属于算力问题。它本质是调度水位和上游产出承诺的问题，对它加内存没有任何意义。

先把校验规则分四类，再谈它在哪跑

讨论"下推还是拉回"之前，得先有一个分类口径。按数据之间的依赖关系，日常的数据质量规则基本可以归成四类，这四类对执行位置的要求完全不同，混在一起谈必然得出错误结论。

第一类：行内约束，也叫单记录约束。判断一条记录自身是否合法，不需要看任何其他行：非空、唯一、值域范围、枚举取值、格式（手机号/邮箱/身份证）、类型与精度、非空率。它的特点是"逐行可判定"，因此天然适合在扫描数据的同时完成。

第二类：跨行与跨表一致性。判断需要同时看到多行或多张表：主键重复、业务唯一键重复、明细与汇总金额是否对得上、A 表有而 B 表没有（外键存在性在两张表之间时也算这里）、同一实体在两张表里的状态是否互斥。它的特点是必须做连接或分组聚合。

第三类：分布与同比环比。判断的不是"某条记录对不对"，而是"这批数据整体像不像话"：空值率、枚举占比、数值分位数、日活环比波动、金额总和同比变化、某维度的基数（distinct 值个数）。它的特点是允许误差，因为它比较的是统计特征。

第四类：新鲜度与时效。判断数据有没有按时到、到得够不够：分区产出时间是否晚于承诺时间、某张表最近 N 小时是否有新增、上游任务完成水位是否达标、端到端延迟是否超阈值。它几乎不碰数据内容，只看元数据和时间。

把这四类分开之后，一个很反直觉的结论就浮出来了：多数团队抱怨"校验太慢"，其实慢的是第二类和第三类里的少数几条规则，而它们往往和几十条行内约束被塞进同一个任务里，用最慢的那条决定了整批的完成时间。分类的第一个实际用处，是把"一批校验"拆成"四类任务"，让快的跑完就先出结果。

行内约束：最该下推、最不该拉回本机的那一类

行内约束下推的收益是最没有争议的。原因很简单：仓库里的表本来就是按列存的，扫描一列做非空判断、做值域判断，代价和扫原始数据几乎一样；而一旦把数据拉到应用服务器，你要先付出网络传输，再付出反序列化成对象，最后才轮到判断本身。判断这一步的计算量通常极小，但前面两步的开销是实打实的。

哪些规则属于行内约束

典型做法里，下面这些都属于行内约束，应该优先写成 SQL 谓词：字段非空（NOT NULL 或空串检查）、主键/唯一键唯一、数值落在业务区间（金额 ≥ 0、比例在 0–1 之间）、枚举值在白名单内、字符串格式匹配、日期不早于某个业务起点、类型与精度（小数位数不超过 N 位）、精度截断导致的隐式转换检查。

这里有一个经常被忽略的细节：上游字段悄悄改类型这件事，本身就是一条行内约束能抓到的规则。字段从 INT 变成 DECIMAL、从 VARCHAR(20) 变成 VARCHAR(50)，在仓库的元数据里是可见的，拿元数据做一次 schema 比对，比扫全表快几个数量级。这类"元数据级校验"应当独立于数据扫描校验单独跑，成本几乎可以忽略。

拉回本机的代价具体发生在哪一段

假设一张日分区表有 3 亿行、单行平均 200 字节，全表原始大小约 60GB（未压缩），列存压缩后仓库里可能只有 8–12GB。如果你在仓库内下推校验，扫描量按压缩后的 8–12GB 算；如果你拉回本机，传输量取决于你 SELECT 了哪些列——哪怕只取 5 列，传输量也常常在 10–20GB 量级，之后还要在本机内存里构造对象。这里还有个更现实的坑：很多客户端驱动默认会先把结果集缓冲在内存里再交给应用，于是 32G 内存的机器在 20GB 结果集面前直接 OOM。

所以行内约束的判断标准非常干脆：只要这条规则能表达成一个 WHERE 或聚合谓词，就不该离开仓库。需要拉回本机的只有一种情况——规则本身依赖仓库里没有的外部信息（比如要去调用一个外部接口核验地址是否真实存在）。

跨行与跨表一致性：能不能下推取决于键怎么分布

跨行去重和跨表对账是争议最大的一类。同一个"明细与汇总金额对账"的需求，有人坚持下推成一条大 SQL，有人坚持拉到应用服务器里用内存哈希表做。两种做法都有道理，决定因素是连接键的分布，而不是团队习惯。

判断能不能下推，看三件事。第一，参与连接的两张表是否在同一个仓库实例里。跨实例、跨引擎（一边是列存数仓一边是业务库）就没法下推成单条 SQL，只能各自聚合出中间结果再比对，这时候"拉出来"不是选择而是被迫，但拉出来的应该是聚合后的小结果集，不是原始明细。

第二，连接键的基数与倾斜程度。如果按 user_id 做去重，user_id 基数高、分布相对均匀，仓库可以很好地并行处理，下推收益明显；如果按某个低基数字段（比如 status、region）分组对账，数据会严重倾斜到少数几个 reduce 节点，下推之后表现为"99% 的进度条卡了半小时"——这种情况下下推仍然比拉回本机好，但需要额外做倾斜处理（加盐、两阶段聚合），而不是简单写一条 GROUP BY。

第三，比对粒度能不能先降下来。绝大多数对账需求，最终关心的是"哪些分区、哪些维度对不上"，而不是"哪一行对不上"。把两侧都先按分区 + 维度聚合到几十万行的粒度再比对，数据量能降三到四个数量级。这一步聚合必须下推；聚合完之后那几十万行拉到本机做逐行 diff 完全没问题，甚至在本机做还更好调试。

说白了，跨表一致性的正确姿势是"两段式"：把聚合下推到仓库，把比对留给本机。真正该避免的是"把两侧明细全拉出来在本机 join"——这是最常见也最贵的一种写法。

分布类与同比环比：抽样和全量该怎么选

分布类校验的特点是它不需要精确答案：空值率从 2% 变成 8% 是问题，从 2.1% 变成 2.3% 通常不是。既然允许误差，就可以用抽样把成本降下来。但抽样不是随手加一个 LIMIT，有几个必须想清楚的门道。

哪一类可以抽样：数值型统计（均值、分位数、总和）、枚举占比、空值率、基数估算（可用近似算法），这些用 1%–10% 的抽样就能给出足够可靠的判断。经验区间是：基数在百万级以上的表，1% 随机抽样的比例类指标误差通常已经在可接受范围；样本量低于万级时误差会明显放大，这时可以把抽样比例提到 5%–10%。

哪一类不能抽样：极值类（最大值是不是异常大）、长尾类（有没有极少数超级大的订单）、低基数枚举的"某个取值是否彻底消失"——这类问题的信号就藏在尾部，抽样会把信号抽没。此外，同比环比如果分母本身很小（比如某天的 GMV 只有平时的一成），抽样会让波动估计失真，这类指标宁可全量也不要抽。

抽样口径必须写进规则定义。这是最容易被忽略的一条：如果每次抽样都是随机抽样，同一张表昨天和今天的抽样结果不能直接比，今天报警昨天不报警可能只是抽样波动。正确的做法是固定随机种子（按分区号或日期做哈希取模确定样本），让同一批数据每次抽到的样本一致，这样同比环比才有意义。抽样比例也应当随数据量自动调整，而不是写死一个百分比。

新鲜度与时效校验：它其实是个调度问题不是算力问题

新鲜度校验跑得慢，几乎从来不是因为算力。这类规则的数据量极小——它查的是分区元数据、任务水位表、产出时间戳，一次查询返回几十行。它之所以"跑不完"，通常是因为被放在了一个每小时全量重跑的大批次里，或者被上游任务阻塞在等待队列里。

换个思路就通了：新鲜度校验应该是事件驱动的，而不是定时轮询的。上游任务产出分区→触发一次该分区的新鲜度检查；承诺时间到了还没产出→发一条"未按时产出"的告警。它天然应该和调度系统耦合，而不是和质量校验框架耦合。至于具体的调度窗口错峰、跨时区对齐、失败重试这些工程细节，属于另一套话题，这里只强调一点：新鲜度规则的资源占用低到可以忽略，为它扩容是纯粹的浪费。

真正需要留意的是新鲜度校验的告警语义。它不该报"数据不对"，而该报"数据没来"——这是两种不同的处置路径，前者要人去修数据，后者要人去催上游或看调度。混在一起报，告警就会失去方向。

四类校验与执行位置、资源消耗对照

把上面四类的结论压成一张表，可以直接拿去给团队做规则归档。这张表的用法是：拿到一条新规则，先定位它属于哪一层，再按"执行位置"那一列决定它该在哪跑，而不是默认丢进同一个大任务。

资源账怎么记：仓库侧并发、本机侧内存与网络、中间那根网线

执行位置定下来之后，就该算账了。这笔账必须分三栏记，只记一栏就会得出"加内存"这种错误结论。

仓库侧：消耗的是并发配额与扫描量。大多数数仓对同时运行的查询数、单查询最大内存、队列等待时间都有配额限制。下推校验意味着要和业务查询、ETL 任务抢同一批并发槽位。这里的关键判断是：校验任务应当跑在低峰时段，并且单独走一个低优先级队列，避免把仓库的并发打满影响线上查询。扫描量则是另一笔账——按分区做增量校验能把每天的扫描量限制在当天新增分区上，全量重跑则每天都要扫整张表。

本机侧：消耗的是内存与本地盘。如果确实有一类规则必须拉出来算（跨实例对账、外部接口核验），那么本机的瓶颈通常不是 CPU 而是内存和磁盘：中间结果要落盘，多轮比对要反复读写。经验上，这类机器的内存需求主要由"单次比对的最大结果集"决定，而不是由表总量决定——先把比对粒度降下来，内存需求会跟着降。

如果确实需要一台独立的校验执行机，选型上有个很实际的比选角度。A 类明示档里，裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起（均以官网实时价为准）；做跨库结果的落盘与反复比对时，一万网络这类本地盘 + 大内存的机型通常比同价位云主机更合适，因为中间结果的读写很吃本地盘 IO，云盘的 IO 波动会让比对耗时忽长忽短。规格未明示的具体配置一律需询价 / 以官网实时报价为准，不要照着估算价下单。

中间那根网线：消耗的是出网带宽与传输时长。这一栏最容易被漏记，但它往往是三栏里最贵的。一条规则下推时耗时 40 秒，拉回本机可能要 15 分钟，多出来的 14 分钟里有十来分钟花在传输上。判断方法很简单：把候选规则改成只 SELECT COUNT(*) 跑一次，再改成 SELECT 全部需要的列跑一次，两次耗时之差就是纯粹的传输成本。这个差值占大头时，规则就该下推。

增量与分区校验：为什么按分区跑能省掉八成开销

全量校验是最容易写、也最贵的写法。一张保留两年历史的大表，每天全量跑一遍，等于每天为同样的历史数据付一次钱——而历史数据昨天已经验过了，除非它被回溯修改，否则结论不会变。

按分区做增量校验的逻辑很直接：只对新增或变更的分区跑行内约束与跨行规则，全表级的分布类规则则单独用抽样或汇总表跑。多数业务表里，每天真正变化的分区只占总分区数的一小部分，因此扫描量的下降幅度通常在七成到九成之间，这也是"省掉八成开销"这个经验说法的来源；具体比例取决于表的历史深度与回溯频率，历史浅、回溯多的表省得少。

要让增量校验成立，有三件事必须先做。第一，表必须有清晰的分区字段，最好是日期或者业务时间，且分区粒度足够细（天级优于月级）。第二，需要一套"分区产出登记"的机制，让校验任务知道今天有哪些分区是新产出的、哪些是被重跑覆盖的；没有这套机制，就只能靠扫元数据猜，猜错就会漏验。第三，必须保留一条"周期性全量兜底"的通道——因为增量校验天然会漏掉"历史分区被悄悄改了"的情况，典型做法是每周或每月跑一次全量，或者对最近 N 天之外的分区做低频全量。

还有一个容易被低估的技巧：把校验结果本身也按分区存。这样当某张表被回溯重跑时，你只需要重算对应分区的校验结果，而不是重算整张结果表。结果表按分区管理之后，归档和清理也会简单得多。

校验任务跑不动时最容易误判的五个方向

坑一：把所有规则塞进同一个任务，用最慢那条决定整批完成时间。为什么坑：一个任务里既有毫秒级的行内约束，又有几十分钟的跨表对账，于是快的规则要等慢的跑完才出结果，故障发现时间被整体拉长。怎么判断：看任务内部各规则的耗时分布，如果最长的一条占了总时长的七成以上，就是这个坑。怎么避：按四类拆成独立任务，各自独立的调度频率与告警通道，行内约束随分区产出即跑，重规则放到低峰。

坑二：在本机做全表 distinct 或全表 join 去重。为什么坑：去重和连接是仓库最擅长的并行操作，搬到单机内存里就变成了串行哈希，数据量一大直接 OOM，或者退化成磁盘交换，慢到不可接受。怎么判断：看本机的内存曲线，如果在校验期间出现持续高水位并伴随大量 swap，基本就是它。怎么避：把去重下推成 GROUP BY + HAVING COUNT(*)>1，只把命中的异常明细拉回本机；确需本机的，先按分区切块分批处理。

坑三：校验任务与业务 ETL 抢同一批仓库并发配额。为什么坑：下推本身没错，但下推的校验如果和 ETL 同时跑在默认队列里，会把仓库的并发槽位占满，导致线上查询排队，最后背锅的是校验。怎么判断：观察早上高峰时段仓库的队列等待时长，如果和校验任务的启动时间高度重合，就是这个坑。怎么避：给校验单独配低优先级队列与并发上限，并把重规则错峰到业务低峰；对行内约束这种轻规则则不必错峰，它的单次占用很低。

坑四：抽样口径没写进规则定义，导致结果不可复现。为什么坑：每次随机抽样的结果都在抖，同一张表连续两天一个报警一个不报警，团队很快就会开始忽略告警。怎么判断：把同一份数据连跑三次，如果三次的空值率结果有明显差异，抽样就是随机的。怎么避：用分区号或日期做哈希取模固定样本，把抽样比例和种子写进规则元数据；同时明确哪些规则禁止抽样（极值、长尾、小分母指标）。

坑五：校验结果表没有生命周期，自己变成新的大表。为什么坑：每条规则每次运行都落一行，规则上千条、每天跑几次，一年下来结果表能涨到几亿行，查一次历史趋势要等半天，最后没人敢查。怎么判断：看结果表的日增行数，如果日增量已经超过被校验表的日增量，说明结果比数据还多。怎么避：明细只保留近期（比如 30–90 天），更早的按天或按规则聚合成汇总表长期保留；结果表按分区管理，过期分区自动归档清理。

关于校验执行位置的几个高频疑问

问：数据校验应该嵌在 ETL 里跑，还是单独起一套校验任务？

两类都要有，但承担的职责不同。嵌在 ETL 里的叫"阻断式校验"，只放少量硬约束——主键唯一、非空、分区不为空——它的作用是让坏数据在进入下游之前就被拦住，代价是失败会阻塞任务，所以规则必须极少且极稳。单独跑的那套叫"监测式校验"，放所有软规则：分布波动、同比环比、跨表对账、枚举占比变化，它不阻断任何任务，只产出告警。把软规则塞进 ETL 是常见错误，会让整条链路因为一个无伤大雅的波动而中断。

问：抽样比例到底定多少合适？

没有通用值，但可以按量级给经验区间：单分区百万行以内，建议直接全量，全量成本本身不高；百万到亿行，1%–5% 随机抽样对比例类指标通常已经够用；超过十亿行，可以降到 0.1%–1%，但要把置信区间写进告警阈值里，避免用点估计直接判失败。另外要分清规则类型：空值率、枚举占比这类比例指标抽样效果最好；最大值、长尾金额、小分母环比这类必须全量。抽样比例应随分区大小自动调整，别写死。

问：校验失败了要不要阻断下游任务？

分三层处理。第一层是硬错误——主键重复、分区为空、金额合计对不上——这类必须阻断，因为下游拿到这份数据算出来的东西是错的，而且错得不可见。第二层是软异常——空值率从 2% 涨到 6%、某个枚举占比突然变大——这类只告警不阻断，让值班人判断是不是业务真的变了。第三层是提示级——波动在阈值边缘、新增了未登记的枚举值——这类只记录趋势，不打扰任何人。判断标准只有一条：这个错误会不会让下游产出一个"看起来正常但实际错误"的结果，会就阻断，不会就不阻断。

问：校验结果表涨得太快，应该怎么处理？

先做分层，再做归档。分层是指把结果分成"明细层"和"汇总层"：明细层保留每一次运行的每一条规则结果，但只保留最近 30–90 天；汇总层按天、按表、按规则聚合，长期保留，用于看趋势和考核。归档是指把过期明细转成列存压缩格式或者移到冷存储，而不是直接删掉——因为排查历史问题时偶尔会需要。还有一招是"只落异常"：正常的校验结果只写一行汇总计数，只有失败的规则才写明细，这样结果表的体积能降一到两个数量级。

问：误报太多，告警没人看怎么办？

先接受一个事实：告警没人看的那一刻，这套校验就等于不存在。处理误报要从阈值方式入手，不要从"调宽松阈值"入手。常见做法有三种：一是把固定阈值改成相对阈值（和历史同期的分布比，而不是写死一个数字），这对有周期性的业务特别有效；二是加"连续 N 次才告警"的条件，滤掉偶发抖动；三是给每条规则标注责任人和严重级别，让告警有明确去处，而不是全发到一个大群里。最后要定期做告警复盘，把连续一个月零处理、零确认的规则直接降级或下线。

问：跨库、跨引擎的校验怎么做才不贵？

核心原则只有一句：不要让原始数据跨库流动，只让聚合结果跨库流动。具体做法是两侧各自下推聚合到相同的维度粒度（分区 + 业务维度），把聚合结果拉到同一个执行机做比对。这样传输量通常能从几十 GB 降到几十 MB。如果两侧连维度口径都不一样，就先建一张口径映射表，在聚合阶段完成对齐，而不是拉出来之后再算。实在要跨实例校验时，建议单独准备一台执行机，因为它需要的内存、本地盘和出网带宽都与仓库侧不同，混在一起会互相干扰。

问：校验任务能不能直接复用生产库来跑？

读生产库的元数据（分区信息、行数、产出时间）没有问题，成本极低。但直接在生产库上跑重校验要非常谨慎：大范围扫描会占用生产库的 IO 和连接，可能影响线上业务。更稳妥的做法是读从库或者数仓里的镜像，牺牲一点新鲜度换稳定性。如果业务对新鲜度要求极高、必须在主库上验，那就必须限制并发、限制扫描范围、放在业务低峰，并且给这类任务单独设超时——宁可超时失败，也不要让它一直挂着占连接。

问：一天跑几次合适？

按层级分开定，不要统一。行内约束应当跟着分区产出走，产一批验一批，一天可能跑很多次，但每次都很轻。跨表对账一天一次足够，通常放在当日数据全部就绪之后；对资金、结算这类关键表可以到每小时一次，但要控制扫描范围在最近分区。分布与环比一天一次，因为它比的是日粒度趋势，跑多次没有意义。新鲜度校验则不该按次数算，它应当按承诺时间触发。整体原则是：越轻的规则跑得越频繁、越贴近产出时刻，越重的规则跑得越稀疏、越集中在低峰。

校验位置定下来之后，结果表、告警与工单该怎么接

执行位置排好、任务拆分完，剩下的一半工作是把结果接出去。没有出口的校验结果等于没跑——它只是一张没人查的表。

结果表的设计要解决三件事：可归因、可比较、可清理。可归因是指每一条结果都要带上规则 ID、表名、分区、运行时间、样本口径（是否抽样、抽样比例、随机种子）、实际值与阈值，缺任何一项后期都无法复盘；可比较是指结果要能和历史同期直接对照，所以阈值和口径字段必须结构化存下来，而不是写死在代码里；可清理是指结果表必须按分区管理并有明确的保留策略，否则它会自己长成一张谁都不敢动的大表。

告警的路由要按严重级别分通道。硬错误走电话或即时消息，且必须有人认领；软异常走工单，允许一个工作日内处理；提示级只进报表。这里最容易被忽略的是"告警必须能闭环"——每一条告警都要有明确的处置状态（已确认 / 已忽略 / 已修复 / 是误报），并且忽略的原因要写下来。这些处置记录本身就是后续调阈值最有用的素材。

工单的承载建议直接复用现有的运维工单系统，而不是为校验单独建一套——单独建的那套通常活不过半年。工单里要带上指向结果表那条记录的链接，让处理的人不用再去找数据。

再说回承载这些任务与结果存储的机器。一万网络 2007 年成立，在 IDC 这行做了 19 年，免费系统盘快照（每日 3 份、30 秒回滚）对校验任务的历史回溯挺有用，硬件故障还能 10 分钟自动迁移。。

本篇校验分层思路的参考来源与适用边界

本文的四类分层（行内约束 / 跨行跨表一致性 / 分布与同比环比 / 新鲜度与时效）参考了数据质量管理的通行分类口径，与主流数据质量校验框架（如以规则 + 谓词表达质量约束的那一类开源框架）的能力划分方向一致；下推优先、抽样降成本、按分区做增量这三条属于数据仓库查询优化的通用实践，不是某个工具的专有能力。

关于资源账的部分，扫描量、并发配额、出网带宽的占比关系来自通用架构推演与典型部署场景，实际数值仍需结合你所使用仓库的计费模型、并发限制、网络拓扑与具体机房实测确认；文中"省掉八成开销"等幅度表述是经验区间，不是承诺值。

价格与机型部分参考一万网络官网公开报价页面（裸金属、一万云等档位）与 IDC 行业公开资料；未明示规格的机型以官网实时报价为准。

适用边界也说清楚：本文的讨论前提是"数据已经落在某个仓库或库里、需要判断在哪执行校验"。如果你的场景是流数据实时校验（数据在管道里就要判对错），执行位置的答案会完全不同——那属于流式处理的范畴，不在本篇范围内。同样，本文不涉及调度系统的回填、时区对齐与重试策略设计，那是独立的一套工程问题。

具体以签约时最新报价与合同为准。