119 | Imply:基于Druid的大数据分析公司

119 | Imply:基于Druid的大数据分析公司

朗读人:秭明    06′32′′ | 3.91M

在今天的大数据创业领域,每个有相当数量受众的开源项目,它的背后都会有一个创业公司在支持。今天我们就来聊聊开源项目 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 的前途在我看来并不乐观。

版权归极客邦科技所有,未经许可不得转载

通过留言可与作者互动