聊完搜索，我们再来聊聊比对。其实按照顺序应该是先有查询、再有比对。只不过在上一篇搜索中已经有了查询的一些内容，就不再单独拿出来讲了，紧接着聊比对正合适。（偷懒）
比对这个词在我们业务中概念范围比较广，比如人像比对、指纹比对、批量比对、多表比对等等。细研究会发现比对的含义会有不同，像人像比对、指纹比对是非结构化数据的匹配问题，然后根据与待比对数据的相似程度来反馈结果。而像批量比对、多表比对通常的含义是结构化数据的匹配问题，然后反馈的是精确的匹配结果。
通常来讲，当我们简单的讲比对时，我们指的就是批量的结构化数据比对。为什么说比对要放在查询后面来讲，就是一般所讲的比对可以看做是批量的查询。查询我们都知道，查一个姓名、一个公民身份号码，那么我们查一万个姓名、一万个公民身份号码就是比对了。
小明是派出所负责社区管理的片警，他拿到了一批社区租户的身份信息大约有两千余人，现在想落实下这两千多名租户的户籍情况。原来小明入户调查时，都是挨个查询的，单位后台有一个户籍查询系统，然后每次手输一个人的身份号码查询户籍信息。但现在突然有了两千多条信息，手动一条条查询显然工作量太大。自然而然，小明需要的就是批量查询功能，也就是比对两千多条数据的功能。
量变会引起质变，查询和比对也就出现了分化。一条查询和一百条查询可能没什么区别，但和一百万条区别可能就很大。比如系统的性能一次承载不了一百万条的量，那么就得有分割数据的策略，把数据分成几个批次。还得有等待机制，上一批比完了才能比对下一批，或者多线程的去比对，还有这大量的待比对数据如何在系统中存放等等问题，都要在系统前端进行设计和开发建设。
在系统后端，尤其在比对数据目的端（通常是数据库），针对比对也会有很多设计，比如对待比对的目标数据项建立索引并持续优化。如果确实需要频繁的进行数据比对的话，后台还要进行架构优化，如果仍是拆解成批量的查询，数据库的压力还是很大的。所以如果一个系统要经常性的进行数据比对，那么最好的设计是把比对目标数据放到内存里去，比如内存数据库或者相应的内存结构中。这样的话数据比对就可以直接在内存中进行了，会大大提升数据比对功能的速度和性能。
但这种架构对内存资源要求很高，如果我们要经常性的比对人口信息，我们要把十几亿人口信息都加载到内存中去，那么就得需要大量的内存资源，可能需要一个计算集群。而且我们为了存放的经济合理，我们可能只能加载有限的数据字段，比如公民身份号码、姓名、籍贯地等等，像家庭住址这种占用空间过多的数据字段我们可能就不会加载。但这样的话，前端用户在比对时，如果需要这个比对这个字段信息，那么就获取不到了。
由此可知，系统的建设和应用的需求是需要有机统一的，也就是说在系统设计时就要做大量的需求调研。在整个系统周期中，需求调研的时长要比设计开发时长要长。只要这样，我们才能建设一个好用的贴近实战需求的系统。（完了，聊跑偏了）
当我们的系统满足了小明比对数千条数据的需求后，小明在工作中又有了新的需求。现小明又需要掌握这两千多人的户籍变动情况，如果有人户籍进行了迁移，就要进行相关的工作。现在小明虽然有了同时比对数千条数据的能力，但要完成这项新工作，需要小明持续的进行比对工作，可能是每周进行一次比对工作，甚至是每天进行一次比对工作。这样的工作量还是很大，小明需要一项功能，能够记录他这两千多条的数据，然后每次有新的户籍迁移信息时，能够反馈给他他所关注的两千多人的户籍迁移情况。
我们业界一般把这个功能叫做数据订阅或者布控。抛开系统层面的外在功能，就数据层面来看，数据订阅或布控本质上还是数据比对功能。如果我们把数据比对的两侧数据做一下区分，把变化的，后加入的数据称为待比对数据，把不变的，先存在的数据称为比对目标数据，那么信息订阅或布控和一般的比对相比只不过是待比对数据和比对目标数据方面进行了置换。小明之前的比对需求中两千多人的信息是待比对数据，户籍变动信息是比对目标数据；而小明最新的比对需求中户籍变动信息是待比对数据，而两千多人的信息则是比对目标数据了。
如果我们的系统开发了数据订阅或布控的功能，当有新的户籍变动信息进到系统中来的时候，就会比对系统中已接收的譬如小明的那几千条数据，如果比中的话就会给小明留下记录。这样小明就不需要不断的去手动比对，而只需要关注系统里的订阅或布控结果就可以了。
当然这里面还有好多的细节，比如数据变化问题。小明隔两天又收到再比对一千条新数据的需求，那么数据就要进行追加。另外在系统后台这端，户籍变动数据的更新频率是怎么样的，比对频率是怎么样的，这些都需要就行具体的设置。统而言之，就是待比对数据是变化的，比对目标数据也是再变化的，我们要设计好比对的频率和数据的增量衔接。
我们再深入的走一步，如果我们对数据比对的实效性要求很高，这里指的就是布控的需求。原来我们设计的系统可能比对频次是一天一次，或者是根据数据更新的频次来进行。但是现在业务上需要进行实时的掌握，譬如小明还想实时获取他所关注的这两千多人的活动情况，如果有新的活动就要进行掌握。那么这时一天一次的频率也不能满足要求，一个小时一次可能也不能满足，我们得需要进行实时的数据比对。当然在这里，我们首先得保证活动信息来源得有实时或准实时的数据，另外在整个系统设计上得做大的调整。因为布控（实时比对）需要我们整个过程尽可能的降低数据的延迟，也就是越快越好，那么最好的方式就是在数据落地入库之前就把布控（实时比对）这件事做了。
在这方面比较好的实践探索是利用流式计算技术实现布控的需求，在后面的文章中我们可以试图讲一下。欢迎大家持续关注！
