最近Hue+Solr 方案原型驗證有了一些進展。正好也收到了Google的大數據專家Sam的來件詢問進展，我答復如下：
Sam,
你好。
已經把Kafka＋flume＋solr的實時索引搭建起來了，
現在用實時事件統計的場景在測試數據(當前方案為kafka storm mysql)，solr現在數據量約為每天八萬條記錄，70M數據。
下面的頁面提供了hue訪問solr的地址，請通過頁面最下面的超鏈接看下我們做的demo。
(鏈接) 遇到的問題： 1.我們現在用的solr 4.10.3不支持修改時區，即只能把傳進來的時間識別成UTC時區。solr5版本有修復這個問題，我們現在通過添加一個timeInUTC的字段解決。 2.hue不支持顯示中文字段名，而標簽字段是帶中文的。 3.facet只支持顯示前10。 solr目測用起來性能還是很高的，我們還想做一下壓力測試。 除了多維標簽外，有一個用戶來電彈屏顯示用戶近期動作的需求，我最近也在考慮是否可以用solr來做？
(來自我的華為手機)
Sam的回信:
用戶來電彈屏的需求用solr來做的主要問題是latency延遲是否能滿足需求？我的看法（拍腦袋想的，不一定符合實際情況）是當用戶電話進來的時候，需要立刻顯示最近的歷史，並且需要比較精確，比如說，他剛打了一個電話，然后放下電話又打進來，那么solr很有可能來不及index最近那個call，並且話務員可能希望在接電話之前的那一秒鍾就顯示出來，如果這種query都用solr，那么到時候你們有幾千個話機中午在同時接的話是否對solr的壓力太大（當然solr可以scale up）。從這個角度我覺得用數據庫index可能更快點。或者用solr和本地cache（儲存最近的call以防止solr來不及index）的方式也能解決這個問題。
然后雞湯一下，前幾天聽了阿里在灣區做的一個技術講座，web技術不是發明出來的，是需求推動演化出來的。每種方式應該都能解決問題，選擇最合適自己業務的方案。
對於Sam說的來不及index最近的call，並且話務員可能希望在接電話之前的那一秒就顯示出來：這兩句話我作了考慮，一是kafka+flume+solr的index時間是在秒級的，二是話務員要求的並不是那么嚴格實時，因此感覺solr還是適用這種場景。
現在當務之急是解決Hue的solr模塊太慢的問題——第一次打開頁面時，加載js,繪圖等等要1分多鍾。想到公司運維在用的ELK平台，就到運維部門考察了一番，感覺Kibana速度和展示都還不錯，於是萌生了用Kibana代替Hue的想法。
Kibana支持ElasticSearch，卻沒聽說支持Solr，有個團隊做了個開源項目Solr版的Kibana,叫Banana，git地址:https://github.com/lucidworks/banana
這個團隊號稱擁有solr開源社區70%的貢獻者作為其雇員(如果是真的那還真是挺牛的)。
banana 1.6.3安裝過程(安裝到CDH的solr 4.10.3)：
1.下載打包版本https://codeload.github.com/lucidworks/banana/zip/release
2.拷貝到$SOLR_HOME/tomcat-deployment/webapps/ROOT下並解壓，CDH5.8.3的$SOLR_HOME一般在/var/lib/solr
$ cp banana-release.zip /var/lib/solr/tomcat-deployment/webapps/ROOT $ unzip banana-release.zip
3.訪問http://cdh-master:8983/banana-release/src/index.html#/dashboard 進入對應的頁面。(cdh-master為solr部署的主機)
使用的感受:
優點：
1.安裝很快，也不需要重啟任何進程。
2.打開速度比Hue快很多，3秒內就能打開。
3.展示功能比較豐富。
不足：
1.sunburst圖功能沒法用。
2.中文有些地方會顯示%2B%4C之內的一串字符。
3.facet功能沒Hue好看。(不過Hue只能顯示最多10條記錄,Banana沒有這個限制)
4.餅圖沒有Hue好看。(不過Hue的餅圖limit有bug。)
5.因為是輕量級web項目，沒有帶數據庫，所以保存一些配置沒有hue方便，但是可以保存到本地。
*以上的Hue是 CDH5.8.3對應的Hue3.10。
Banana的好處是比Hue更容易定制開發。后面有什么需求或者修改bug，可以直接在Banana源碼中改。
12月21日補充:如上問題的解決辦法在《再探banana》中。