|
|
# 094 | Imply：基于Druid的大数据分析公司
|
|
|
|
|
|
在今天的大数据创业领域，每个有相当数量受众的开源项目，它的背后都会有一个创业公司在支持。今天我们就来聊聊开源项目Druid，以及它背后的创业公司Imply。
|
|
|
|
|
|
Druid起始于2011年。它最初的开发商叫做Metamarkets，是一个籍籍无名的广告公司。这个项目于2012年8月份基于GPL版权开源，这一点和Hadoop生态圈里基于Apache版权开源的项目都不太一样。
|
|
|
|
|
|
Druid一开始并不是很有名，不过随着Airbnb的加入和推广，这个项目也逐渐在社区成名起来，但是GPL的开源方式始终不是社区开源的主体。
|
|
|
|
|
|
于是，在2015年2月，项目的开源方式转向了Apache版权，正式投奔了Hadoop生态圈。这算得上是Druid发展历程里最为重要的一步。
|
|
|
|
|
|
## Druid的优与劣
|
|
|
|
|
|
介绍完了Druid整个项目历程，接下来我就来聊聊这个项目的特点。
|
|
|
|
|
|
在诸多数据分析开源项目里，Druid有两个独具特色的优点。具体来讲，**Druid的第一个优点是：它的整个系统同时提供了对离线数据分析和在线实时数据分析的支持。**
|
|
|
|
|
|
它是通过冷热数据分离的方式做到这一点的。冷数据是已经写入到Druid存储的数据，这一类数据存在Druid的某个节点的硬盘上。
|
|
|
|
|
|
热数据是等待写入的数据，这类数据在内存里。 Druid对冷数据和热数据分别进行查询分析，再把查询分析的结果结合起来作为最终结果返回给用户。这种数据一经导入就立刻能被查询的特性，让Druid在很多企业里都十分受欢迎。
|
|
|
|
|
|
**Druid的第二个优点是：它是一个可插拔的查询系统。**
|
|
|
|
|
|
通常来说，一个查询系统需要实现存储和执行两个模块。而存储则依赖特定的存储系统，比如说内存、本地磁盘、网盘、Hadoop文件系统和云盘等等。
|
|
|
|
|
|
市面上大部分的查询系统是和特定的一个或者有限个存储系统绑定的，而Druid本身并不绑定特定的存储系统。它可以支持所有流行的存储系统，不论是本地磁盘、网盘、Hadoop文件系统或者是常见的云盘比如亚马逊的S3，都可以成为其存储系统。
|
|
|
|
|
|
当然，Druid作为一个查询引擎，也有着两个非常显著的缺点。
|
|
|
|
|
|
第一个缺点是它不支持Join。或者我们可以这样说，Druid只支持单表查询。也正因为这个原因，Druid可以在本地就处理掉本地存储的数据，无论是冷数据还是热数据，然后再把数据整合在一起给出结果。如果Druid支持Join的话，这种方式就不切实际。
|
|
|
|
|
|
Druid这个设计很像谷歌的BigTable。这说明在互联网公司，确实有很多业务可以只需要单表。但是谷歌的BigTable下一代产品Spanner已经过渡到了一个完整的关系数据库，也开始支持Join。所以我们可以认为Druid更像是一个过渡产品。
|
|
|
|
|
|
第二个缺点是Druid不支持SQL，只类似BigTable那样的API。这导致了Druid这个开源项目身上互联网公司的气味很重。而传统一些的需要SQL支持的公司并不愿意用不支持SQL的Druid。
|
|
|
|
|
|
## Imply公司与系统
|
|
|
|
|
|
说完了Druid，我们来看看它背后的公司。2015年8月，Druid最初的那些创始人离开了Metamarkets去创业，成立了Imply公司。这是诸多大数据创业公司里又一家提供在线分析报表服务的公司，这样类型的公司，我们一路走来也已经讲过很多。
|
|
|
|
|
|
Imply公司主要为Druid提供企业级应用的支持。它的产品也叫Imply。Imply公司的这套系统主要有两个版本。第一个版本是一套离线可以下载本地部署的系统，企业可以部署在自己的企业内部，叫Imply On-Premise。另外一个版本是基于亚马逊的云计算架构AWS的云版本，叫Imply Cloud。
|
|
|
|
|
|
Imply这套系统在Druid的基础上进行了两个方面的优化。
|
|
|
|
|
|
第一方面，它解决了开源的Druid为人诟病的问题：不支持SQL。Imply实现了一个新的、不开源组件，这个组件叫做SQL层。它的主要作用是允许外部系统通过ODBC或者JDBC连接进来，系统同时具备了把SQL翻译成Druid查询语言API的能力。
|
|
|
|
|
|
所以这样一来，外部系统通过标准的ODBC/JDBC连接，发送SQL语句，而这个SQL层则完成从SQL到Druid自己查询语言API的转换，从而连通内外系统。不过，这种连接方式依然不支持Join。
|
|
|
|
|
|
第二方面，Imply还增加了一个可视化查询模块。这是在用户本身没有Tableau或者Power BI等类似的可视化工具外部连接的情况下，系统本身提供一些简单的可视化操作和支持。
|
|
|
|
|
|
除去做可视化以外，这一层还提供了通过对数据的预先计算和处理，并存储中间结果的方式来加速查询。这一点和我在前面文章提到的Dremio的做法很像。
|
|
|
|
|
|
Imply公司的主要盈利模式还是通过出售他们的系统，以及为他们的系统提供支持来赚钱。鉴于开源版的Druid不支持SQL，所以传统企业如果想要使用Druid的整个技术栈的话，买Imply的版本比用开源的Druid会更方面好用。后者提供了SQL的支持，可以降低企业内部员工迁移的学习成本。
|
|
|
|
|
|
Imply的赚钱模式并没有和其他基于开源大数据的创业公司的赚钱模式有特别大的区别，区别的地方只是底层的产品换成了Druid。我个人并不看好这个公司，主要有两方面的原因。
|
|
|
|
|
|
第一是Druid的产品虽然比较适合互联网公司，但它不是一个通用的系统。互联网公司的自我开发能力强，用开源的Druid足够了，不会花钱去买Imply的增强版，所以Imply很难赚到互联网公司的钱。
|
|
|
|
|
|
第二是Druid本身不支持Join，这让它非常高效，可以同时提供离线和在线分析，但是也让它对传统企业来说，变得非常不实用。不支持Join的数据查询引擎在传统企业里要怎么用起来，是一个巨大的挑战，所以我觉得Imply也很难赚到传统企业的钱。
|
|
|
|
|
|
总而言之，我觉得不管在什么情况下，因为Druid的特殊性，Imply很难赚到任何一个企业的钱。我有理由相信这个公司是诸多开源项目背后的创业公司里最早倒下的那一批，所以，Imply的前途在我看来并不乐观。
|
|
|
|