公司最近在研究多條件組合查詢方案，Google的一位技術專家Sam和我們討論了幾個備選方案。 Sam的信： 我做了進一步研究，目前有這麼幾種做法： 1） 最直接粗暴，只做一個主index，比如按行業＋地區做一個index，這樣來說的話，無論多少個標簽的查詢，直接先用主index做一個篩選，這樣下來可 ...
公司最近在研究多條件組合查詢方案，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。
(作者:卡爾 http://www.cnblogs.com/arli)
