最近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源码中改。

Banana:Solr的Kibana