如何实现搜索列表_万亿级记录数，如何实现高性能模糊匹配搜索？

模糊匹配在我们日常的数据筛选场景很常见。

常见模糊匹配方案

我们先从最简单的代码说起，对于模糊匹配的关键字like，SQL，java等很多语言中都很常见，配合两个百分号（如：like ‘%mp3%’），能对数据的某字段进行文本包含的筛选（将字段中包含mp3的数据筛选出来），完整的学名：正则匹配。先从简单的问题入手，从一批搜索原词中，抽取出包含mp3或者包含mp4的搜索原词，我们可以拿SQL来对这个问题做一个完美的诠释。

select kw from table where kw like '%mp3%' or kw like '%mp4%'

思路是，将每一个搜索词对mp3和mp4这两个核心词逐个做匹配后筛选，其最后的结果就是我们想要的，那么有1000个搜索原词，遍历完2000次就可以得到最终结果。

接着，我们将这两个核心词的体量放大，变成100个核心词，将1000个搜索原词对这100个核心词进行一次模糊匹配，并筛选匹配结果，按照刚才的思路，遍历次数就变成了1000x100 = 100000次，工程上就是需要将搜索原词表与核心词表做一次笛卡尔积以后，然后用原词去like核心词，在这样的一个量下，性能上还都是可以接受的。

万亿记录数的模糊匹配怎么做？

上述都是理想情况，现实社会总是会给你降维打击。

现在的场景是每天1500万的搜索原词与每天聚类后33万的中心词进行模糊匹配，按照常规思路，将原词和中心词做一次笛卡尔积后，结果数量集的记录数已经变成了10的12次，单位是万亿，预计每个分区占用的空间是30万GB。这是什么概念呢？目前国内某超级大型10多万人的企业，其最大的一个存储结果表的量级也才15万GB，而这个结果集的记录已经是其2倍。再直观一点，我们普通人电脑的硬盘一般都是512GB，30万GB相当于586台个人电脑加和起来的存储空间。

当然，此时15万GB只是在模糊匹配中的一个临时环节，同时，随着每天搜索原词的不断增加，这个空间还会不断飙升。退一步说，即使存储空间允许，那么在此基础上做模糊匹配，由于like是不走分区裁剪的，所以模糊匹配的过程也会消耗大量的计算资源，从而判断这个方法在整个工程上的可行性极低。

于是不得不换个思路来解这个问题，做一个简单的分析后，我们发现，核心词都较简短，通常由4个及以下数量的单词组成，若1个搜索原词是由5个单词拼成的，如下图，左边为原词，右边为中心词。

然后，为了避免做like，尽量往等值链接上去想，很容易可以发现，我们要把左边的原词尽量变成右边的样子，于是就有了类似下面两个图的变更。

第一个图中的原词在拆词后，我们在拆出来的其中4个词中发现了能与右边的中心词进行等值匹配的关系；而第二个图中的原词在拆词后，没办法与右边的中心词找到等值关系，于是我们成功的避免了工程上的like，而用拆词+等值连接实现了模糊匹配的功能。

在简单的理清了这个事件的原理后，我们再来对比几个数据，刚说了，每天1500万的搜索词和30万的中心词笛卡尔积后，数据量级到达了10 的12次，存储也预估会占用30万GB的临时空间。那么换成拆词以后，计算的数据量又是多少呢？1500万个搜索原词，每个搜索原词都是由几个单词组成的，因为中心词不会超过4个，于是在拆词的过程中不需要拆4个以上数量的组合，所以：

• 4个单词组成的原词，1变5
• 5个单词组成的原词，1变15
• 6个单词组成的原词，1变56

依次类推，我们保守的假定每个词被平均拆成50个拆词，于是总词量便是7.5*10的8次，7个亿，这已经比10的12次要好的多了（实际情况下拆词后的结果总量大约为1个亿左右），拿这样的结果再与33万的中心词做一次等值连接的计算，这就转化成了ODPS上最最常见的一个join计算，大大的减少了原来笛卡尔积方案的计算资源和存储资源。

另外这里的拆词，我们封装在一个Map Reduce里实现，在这个拆词的Map Reduce过程中，我们还可以将过滤停止词，过滤无效字符等逻辑全都加到Map Reduce里去。

于是利用等值连接的思路，我们实现了搜索原词对批量中心词的模糊匹配。

而对于许多数据产品，要么聚焦于原词，要么聚焦于行业，其实在行业和原词之前还有一个品的概念，如零售电子行业下的red mp3 player，mickey mp3 player，mp3 player bluetooth，往大里归类都是mp3 player，我们可以得知每一个mp3 player的单独的曝点反等一些列的指标，而没有办法看看他所属的大类品的一个总的曝点反指标，品的概念在某种程度上对卖家还是有很大的意义的，抢占商机在行业与词之间搭了一个品的桥梁，可以说在数据外显方面又做了一次更加准确的升级。