在两种情况下必须要做如此的验证：

a. 数据迁移

这个场景主要是DW环境从一种迁移到另一种，比如RAC迁到HIVE之类的，记录数对比是首要的，迁移的数据量都不对，具体的数据内容对不对就不用考虑了。

b. ETL转换

这种场景是更常见的，毕竟数据研发，ETL过程是必不可少的。那么，记录数对比主要涉及如下几类：

1). 从操作型数据库抽取数据到数据仓库，这个过程由于字符集、字段类型、系统软硬件等原因，不可避免数据会丢失，这个时刻不关注记录数的差异，后续如何能正确利用数据

2). 根据数据模型做数据处理和应用，这个过程任何做数据研发，数据分析的，都不陌生，在这个过程中估计也不可能没有人没有遇到过记录数不一致的情况。此过程，如果能解决记录数一致问题，其实顺带解决了很多数据逻辑问题，以关系型数据为例，任何数据的转换，都是从N张表关联得到M张表的过程，我们解决记录数一致问题其实就是解决：1.数据粒度验证；2.数据筛选过滤验证；3.关联错误产生数据重复等问题

此类验证是局部和整体的关系，局部要服从整体，也就是验证执行结果中可累加度量的总量。比如，一张反映网站访问量的表，此表每天的数据量是1个亿，如果我们按性别维度做汇总聚合，男性访问量是5千万，女性访问量是4千万，5千万+4千万 ！= 1个亿。很明显，这个数据肯定有问题，我的1千万流量去哪儿了？我们通过度量平衡验证找到了问题的现象，那引起问题的原因呢？这就要结合其他几类测试方法，针对这个例子，第一反应可能是性别字段为空，这1千万可能就是这样。

此类测试是最出力不讨好的体力活，抽样的成本比较高，但很多时候还发现不了问题。不过这类测试是最不能忽略的，因为真正能通过此类测试发现问题的，这个问题就比较隐晦，有时候搞不灵清到底是不是问题。

这类测试更重要的是有个提前判断，划定一个标准，比如，一个字段必须是非空的，我们抽样就是验证非空；一个字段必须是双精度数字类型，但是表结构定义为整型数字类型，精度丢失就会导致数据的异常，如果我们是算钱的，1.6块变成1块，当有1个亿这样的数据，你就真亏大发了。这类是值自身的问题。

还有类数据抽样可能和数据分析关系更深一点，而且这个会更隐晦了。比如一个指标在以往一个月的趋势里都平稳在500万左右，但是突然今天这个指标变成100万了，你就要怀疑是否存在问题，这种情况很有可能有人动了你刷新数据的代码。这类测试对我们数据研发人员有更高的要求，有的人总把自己定位为数据开发，其实玩数据，开发是本职，但是不懂分析，有时候开发还真会存在很大的陷阱。建议我们的数据研发人员也多关注下业务，了解些分析的技能。

此类测试主要是针对数据刷新代码开发完毕，开始自测这个过程，以后可能不用太关心这类测试。

我们不能避免我们永远不会犯错误，如果数据错了就要重新来过，但是我们的代码不支持重新跑，修正数据错误就比较麻烦，有时候可能就没办法修正。

首先，我们要在设计时，考虑如何写代码保证可以支持重跑，其次，就算我们设计的代码是支持重跑的，我们也要在自测阶段，重复跑几次代码，比对数据和逻辑，真正保证重跑是没有问题的

此类测试导致的影响可大可小，一般在越底层出现，问题越严重，绝对是蝴蝶效应的威力。如果一份数据的关联字段不一致，生成的数据就会产生笛卡尔积的数量效果，我有个同事一个笛卡尔积把整个系统hang住了。

我个人非常注重粒度，每个数据表是什么粒度的，一旦我知道这个表是什么粒度的，我就能知道这个表的唯一性是什么，对非表粒度级别的维度，我会很慎重，因为它不代表唯一性。所以，唯一性检查对我而言是水到渠成的事情，就是因为我首要关注粒度，理解粒度后就不会犯唯一性的错误。

此类测试和唯一性检查时对称的，非唯一，那肯定有重复。所以此检查和唯一性检查是如此的相辅相成。