聊完搜索，我們再來聊聊比對。其實按照順序應該是先有查詢、再有比對。只不過在上一篇搜索中已經有了查詢的一些內容，就不再單獨拿出來講了，緊接著聊比對正合適。（偷懶）
比對這個詞在我們業務中概念範圍比較廣，比如人像比對、指紋比對、批量比對、多表比對等等。細研究會發現比對的含義會有不同，像人像比對、指紋比對是非結構化數據的匹配問題，然後根據與待比對數據的相似程度來反饋結果。而像批量比對、多表比對通常的含義是結構化數據的匹配問題，然後反饋的是精確的匹配結果。
通常來講，當我們簡單的講比對時，我們指的就是批量的結構化數據比對。為什麼說比對要放在查詢後面來講，就是一般所講的比對可以看做是批量的查詢。查詢我們都知道，查一個姓名、一個公民身份號碼，那麼我們查一萬個姓名、一萬個公民身份號碼就是比對了。
小明是派出所負責社區管理的片警，他拿到了一批社區租戶的身份信息大約有兩千餘人，現在想落實下這兩千多名租戶的戶籍情況。原來小明入戶調查時，都是挨個查詢的，單位後臺有一個戶籍查詢系統，然後每次手輸一個人的身份號碼查詢戶籍信息。但現在突然有了兩千多條信息，手動一條條查詢顯然工作量太大。自然而然，小明需要的就是批量查詢功能，也就是比對兩千多條數據的功能。
量變會引起質變，查詢和比對也就出現了分化。一條查詢和一百條查詢可能沒什麼區別，但和一百萬條區別可能就很大。比如系統的性能一次承載不了一百萬條的量，那麼就得有分割數據的策略，把數據分成幾個批次。還得有等待機制，上一批比完了才能比對下一批，或者多線程的去比對，還有這大量的待比對數據如何在系統中存放等等問題，都要在系統前端進行設計和開發建設。
在系統後端，尤其在比對數據目的端（通常是數據庫），針對比對也會有很多設計，比如對待比對的目標數據項建立索引並持續優化。如果確實需要頻繁的進行數據比對的話，後臺還要進行架構優化，如果仍是拆解成批量的查詢，數據庫的壓力還是很大的。所以如果一個系統要經常性的進行數據比對，那麼最好的設計是把比對目標數據放到內存裡去，比如內存數據庫或者相應的內存結構中。這樣的話數據比對就可以直接在內存中進行了，會大大提升數據比對功能的速度和性能。
但這種架構對內存資源要求很高，如果我們要經常性的比對人口信息，我們要把十幾億人口信息都加載到內存中去，那麼就得需要大量的內存資源，可能需要一個計算集群。而且我們為了存放的經濟合理，我們可能只能加載有限的數據字段，比如公民身份號碼、姓名、籍貫地等等，像家庭住址這種佔用空間過多的數據字段我們可能就不會加載。但這樣的話，前端用戶在比對時，如果需要這個比對這個字段信息，那麼就獲取不到了。
由此可知，系統的建設和應用的需求是需要有機統一的，也就是說在系統設計時就要做大量的需求調研。在整個系統週期中，需求調研的時長要比設計開發時長要長。只要這樣，我們才能建設一個好用的貼近實戰需求的系統。（完了，聊跑偏了）
當我們的系統滿足了小明比對數千條數據的需求後，小明在工作中又有了新的需求。現小明又需要掌握這兩千多人的戶籍變動情況，如果有人戶籍進行了遷移，就要進行相關的工作。現在小明雖然有了同時比對數千條數據的能力，但要完成這項新工作，需要小明持續的進行比對工作，可能是每週進行一次比對工作，甚至是每天進行一次比對工作。這樣的工作量還是很大，小明需要一項功能，能夠記錄他這兩千多條的數據，然後每次有新的戶籍遷移信息時，能夠反饋給他他所關注的兩千多人的戶籍遷移情況。
我們業界一般把這個功能叫做數據訂閱或者布控。拋開系統層面的外在功能，就數據層面來看，數據訂閱或布控本質上還是數據比對功能。如果我們把數據比對的兩側數據做一下區分，把變化的，後加入的數據稱為待比對數據，把不變的，先存在的數據稱為比對目標數據，那麼信息訂閱或布控和一般的比對相比只不過是待比對數據和比對目標數據方面進行了置換。小明之前的比對需求中兩千多人的信息是待比對數據，戶籍變動信息是比對目標數據；而小明最新的比對需求中戶籍變動信息是待比對數據，而兩千多人的信息則是比對目標數據了。
如果我們的系統開發了數據訂閱或布控的功能，當有新的戶籍變動信息進到系統中來的時候，就會比對系統中已接收的譬如小明的那幾千條數據，如果比中的話就會給小明留下記錄。這樣小明就不需要不斷的去手動比對，而只需要關注系統裡的訂閱或布控結果就可以了。
當然這裡面還有好多的細節，比如數據變化問題。小明隔兩天又收到再比對一千條新數據的需求，那麼數據就要進行追加。另外在系統後臺這端，戶籍變動數據的更新頻率是怎麼樣的，比對頻率是怎麼樣的，這些都需要就行具體的設置。統而言之，就是待比對數據是變化的，比對目標數據也是再變化的，我們要設計好比對的頻率和數據的增量銜接。
我們再深入的走一步，如果我們對數據比對的實效性要求很高，這裡指的就是布控的需求。原來我們設計的系統可能比對頻次是一天一次，或者是根據數據更新的頻次來進行。但是現在業務上需要進行實時的掌握，譬如小明還想實時獲取他所關注的這兩千多人的活動情況，如果有新的活動就要進行掌握。那麼這時一天一次的頻率也不能滿足要求，一個小時一次可能也不能滿足，我們得需要進行實時的數據比對。當然在這裡，我們首先得保證活動信息來源得有實時或準實時的數據，另外在整個系統設計上得做大的調整。因為布控（實時比對）需要我們整個過程儘可能的降低數據的延遲，也就是越快越好，那麼最好的方式就是在數據落地入庫之前就把布控（實時比對）這件事做了。
在這方面比較好的實踐探索是利用流式計算技術實現布控的需求，在後面的文章中我們可以試圖講一下。歡迎大家持續關注！
