公司最近在研究多条件组合查询方案，Google的一位技术专家Sam和我们讨论了几个备选方案。

Sam的信：

我做了进一步研究，目前有这么几种做法：

1） 最直接粗暴，只做一个主index，比如按行业＋地区做一个index，这样来说的话，无论多少个标签的查询，直接先用主index做一个筛选，这样下来可能只有少于10w个row，然后对这10w个一个个filtering，这种做法可能能够满足大部分需求。当然，这种做法需要用到cache来优化，否则每次都去DB load会影响数据库的performance。但是初期直接使用数据库做查询也不是不可以。（这取决于数据量和查询的频率）。

2）使用淘宝的做法， 这种做法是自己来做indexing然后merge，是最强大的，但是开发上可能需要时间较长。

3）使用search engine。我昨天碰上airbnb的一个工程师，正好是做搜索的，他们最开始就是使用的方式1），每个search用邮编filter后其实没有多少房子，所以最简单，后来改用了search engine能提供更多功能。http://www.solrtutorial.com/solr-in-5-minutes.html 是一个简单的tutorial，做一个prototype应该很快（一天？）。http://www.solrtutorial.com/solr-query-syntax.html 是solr engine的查询语法。也能支持 范围查询（比如，消费能力是150元到300元之间）

当然，从原理上来说，2）和3）其实是一样的，多个index的数据集做集合运算。不过3）是在2）上面包了一层。

上面是我的研究结果，供你们参考。

我的回信：

嗨，Sam:

  你好！

  上封邮件中提到的方案三，收到邮件后我就开始在基于Cloudera的Solr组件做原型验证。

  如下例子中拿call客记录当源数据：                       

  {"callSeconds":31,"phone":"189xxxxxxxx","callTime":1480398756000,"callerName":"张三","audioPath":"CB01216021100259_5791b1d70cf2c74aa63c0c25_18968168005_20161129135204.3gpp","canAssign":true,"intent":"B类接通无需求","id":"583d17a444f4f4cb88e3c778","callerId":"57a0678b44f468afd0ee0bac","account":"恒大","strId":"583d17a444f4f4cb88e3c778","merchantId":"5791b1d70cf2c7a4aa63c0c25"}

对每个字段都建索引，用Cloudera的图形化工具Hue可以连到solr查询数据和图表：

Filter过滤以及柱状图，折线图，饼图等主要展示形式都有，其他的还有几个功能暂时还没有用到。

例如查询某caller客的所有去电的意向分布情况：

先找出CallerId=57a0678b44f468afd0ee0bac的记录，再按intent查饼图。

待解决问题:

1.新增字段，新增Tag

新增字段:可以用DynamicFileds在导入数据的时候动态新增索引字段。

新增Tag:每个标签作为一个DynamicFileds。

2.历史数据和Kafka中的实时数据导入Solr

实时数据:

1)Kafka消费+SolrJ写入。(需要启额外进程)

2)Kafka+Flume+Morphline。(需定制实现一个Morphline)

方案2)比较好的点是由集群保证鲁棒性。

历史数据：原始数据先导入到HDFS，CDH有工具支持Spark/MapReduce+Morphline导HDFS数据到Solr。

Solr实战:使用Hue+Solr实现标签查询