第三章：初体验druid.io引擎

这篇文章整理的时间较长，目前我们已经使用此引擎，已经广泛覆盖到公司各业务系统中。

我们是在14年2月份选择druid.io作为我们的OLAP引擎，为什么选择它，主要基于以下考虑（应该是druid本身的特性也有说明）

1、时区范围查询

2、任意维度组合（即每个维度都是主键，类似groupby类型）

3、统计指标灵活配置，非常方便进行扩展及二次开发

4、内嵌支持javascript引擎

5、分布式系统该有的特性都具备

当时我们了解的时候，是从一篇文章了解到的《Real-Time Big Data Analytics》，里面就有提到druid.io。并且通过百度（不要吐槽了）搜索并不能发现相关的中文资料，绝大多数都是阿里巴巴的druid数据库连接池（到目前为止百度也还是很难搜出相关资料，所以gg还是靠谱多了）。因为此开源项目还是比较新的，在国内还没有广泛的应用。所以在选型的时候，也经历过反复验证和它的文档介绍，并结果具体的业务场景，发现此引擎很符合我们的需要。

通过一周左右的学习，在我自己的笔记本上，运行其demo程序（当时版本是0.6.52）通过了，不过第一次安装如果maven库不完善，还要重新下载一次。为了更加接近我们的业务使用场合，也模拟了几条记录导入后进行查询，也能得到正确的结果，这时候就申请几台机器，开始搭建真正的分布式集群（毕竟这么多服务都在笔记本上安装还是吃不消啊）。

机器分布如下：

kafka机器2台（版本0.8.0）

2台realtime节点，并安装了zookeeper节点（版本3.4.5）

1台broker节点，

3台historical节点，这几台机器比较独立

1台coordinator节点，并安装了mysql服务（版本5.5），zookeeper节点

因为我们申请的是aws云主机，所以deep storage就是用S3速度还是蛮快的。

第一次安装会比较慢点，因为maven仓库要拉去很多第三方依赖包（快捷的方式，就是将第一台下载好的maven库，拷贝到其它机器上面）。安装完成后，启动各服务（没有其先后顺序），导入自己生成的模拟数据，操作方式参考官方文档中Getting Startd部分，按此方式一个个步骤来，最终都验证成功了。

当时总体感觉还是半成品，例如启动和关闭，还需要自己写shell（虽然说明使用apache的whirr工具）；另外查询语句是json格式，虽然比较灵活，但可读性不强，没有用SQL语句的方式，降低其使用学习成本（因为有其特殊性，SQL语句的方式不能全部满足）；web管理界面非常简单；社区很薄弱及使用经验介绍较少，查询请求不能cancel等。

在操作的过程中，因配置参数还是蛮多的，稍不注意某些参数就会配置错误导致未知异常；还有就是有些节点使用没有详细的操作步骤，特别是overlord结合middleManager的方式进行批量导数（很多参数只有说明而无使用效果演示）。

源代码开源但绝大多数都是函数式编程并且注释很少。

最重要的实时OLAP要快，硬件资源不可缺少（内存要大，硬盘读写要快，CPU要强劲等）。

另外补充下，很多人在跟我聊到这块的时候，都提到了是否可以使用预先计算和预先设计的方式，这样可以提高计算的速度。但实际我们使用的场景是总共有60几个维度，用户在查询条件的选择上面，是任意选择几个或者几十个，非常随机。这样的场景就没法预先计算和设计了，这种使用的方式决定了与其它使用场景的异同点。也决定了后期需要进行大量的封装开发，最终形成可真正使用的产品。

还有些人问我为什么不用storm，它也是实时计算的，这是因为实时计算跟OLAP是两个场景。

总结：

每个开源都不能做到十全十美，能够满足最关注的需求，而其它的问题都可以通过时间来解决。另外druid.io还是蛮稳定的开源项目，比较严重的bug还是很少的。