118 | Dremio:在Drill和Arrow上的大数据公司

118 | Dremio:在Drill和Arrow上的大数据公司

朗读人:秭明    07′06′′ | 4.27M

今天这篇文章,我们来讲讲一个非常年轻的公司 Dremio 的故事。这个故事涉及了两个 Apache 开源项目 Drill 和 Arrow,和一家 Hadoop 发行商 MapR。

我们先从 MapR 公司开始讲起,MapR 在 2009 年成立,发展一直不错,在 CTO 的带领下,公司出品了一个自己的文件系统,取代了 HDFS,同时,它的 Hadoop 发行版也取得了不俗的成绩。

托马尔 · 希兰(Tomer Shiran)和雅克 · 纳杜(Jacques Nadeau),这两位都是 MapR 公司的核心员工。让我们记住这两个人的名字,因为他们与我们接下来的故事息息相关。托马尔是 MapR 的第一位产品经理,负责整个产品线的开发。雅克则是 Apache Drill 项目和 Apache Arrow 项目的主要负责人。

第一个项目:Apache Drill

让我们把时间倒回到 2013 年。当时 Hive 已经存在,但是很慢很不好用。谷歌的 Dremel 刚出来没多久,就掀起了交互式查询的风潮,随之而来的是 Cloudera 开始了它的 Impala 引擎的计划;而 MapR 也决定做一款查询引擎,自己主导开源项目,这就是后来的 Apache Drill。

当时筹建这个项目的人,是托马尔,而具体负责干事情的人,是雅克。我之所以知道这件事情的详细情况,是因为 2013 年的时候,这两位打电话给我,希望我加盟这个尚未展开的项目。

但是当时的我比较担心小公司不稳定,就没有去。不过,虽然我没有去,但还是获得了 Apache Drill 的一些内幕信息。

Apache Drill 是一个基于类 SQL 语言的查询引擎,它的第一个特点,也是最主要的特点就是可以通过连接器连接各种各样的数据源,这里包括了 HDFS、HBase、Hive 的表,关系数据库等等。

并且它可以跨多个数据源进行数据查询和分析。这些连接器是可扩展的,只要有人愿意替一个特定的数据源写一个连接器,那么 Apache Drill 就可以支持这个数据源。

Apache Drill 的第二个特点是:它使用了半结构化数据类型,类似 JSON。它的查询语法类似 SQL,但是引入了很多半结构化数据支持的新语法。当然,对于半结构化数据支持,在 Google 的 Dremel 以及 Hive 里面早就有了,所以这些新语法的扩展并没有那么让人吃惊。

Apache Drill 的第三个特点是:系统可以自动推导和识别“元数据”。这一点是 Apache Drill 独有的特性,其主要目的是解决半结构化数据中“元数据”难以确定的情况。

Drill 的理念无疑是非常先进的,可惜的是 Drill 并没有大红大紫过。可能的原因有很多,但在我看来,最大的原因是:这个系统很难做到高效。

在用户查询数据量大的时候,Drill 比其他系统要慢很多。好用却不高效,无法应对大规模的数据处理,在大数据的场景下就有些吃力不讨好了。

第二个项目:Apache Arrow

雅克致力于 Drill 的开发已经很多年了,肯定也意识到了这样的性能对于 Drill 是一个问题。但是性能问题要怎么解决,却不是一件容易的事情,雅克的做法是构建另外一个项目:Apache Arrow。于是 2016 年,Apache Arrow 诞生了。

简单来说,Apache Arrow 是一个内存数据结构,它的主要作用是在不同的数据源之间做快速高效的数据交换。这个项目吸收了 10 多个 Apache 顶级项目。它的主要目标有两个:

  1. 定义一个通用而高效的内存数据格式,方便数据查询引擎进行查询。

  2. 定义了从上述格式中载入数据的方式。任何支持这个格式的系统,都可以方便、高效地输入或者输出这种格式。

这两者放在一起,就使得从不同数据源读取和写入数据的效率得到大大的提高。这种提高,对于各个产品都是有意义的。然而更加有意义的并非各种产品之间,而是类似 Apache Drill 这样需要对不同数据源做联合查询的查询引擎。这种方式的交互数据已经把可能的消耗都降低了。对 Drill 这样的引擎才有可能实现高速查询。

Dremio 公司的核心产品

但是,这个时候,MapR 公司却出现了一些问题。MapR 经过了一轮大洗盘,创始人和早期高管纷纷被迫离职,连 CTO 也去了 Uber,托马尔和雅克,这两位 MapR 非常重要的早期员工也开始了他们的创业历程,他们创立了 Dremio 公司。

有了 Apache Arrow,托马尔和雅克就可以构建新一代的、类似 Drill 的查询引擎了。这就是 Dremio 公司的核心产品。它是一个有 UI,可以连接到不同数据源进行数据分析的软件。当然这个产品也是不开源的,所以我们就没办法了解到它的具体实现。

乍一看,Dremio 项目和 Drill 没有区别,但是它们内部其实是很不一样的。最大的区别在于,Drill 可以任意地连接各种数据源,所以它虽然灵活,但是效率低。

Dremio 公司的这款产品,只支持能输出 Apache Arrow 格式的数据源。但在内部,Dremio 这款产品统一处理使用 Apache Arrow 格式。因为不需要通过连接器进行数据格式转换,不需要对元数据进行推理,Dremio 的效率自然要高了很多。

Dremio 的这款产品并非没有缺点。和 Drill 比起来,它能够连接的数据源一下子少了很多,目前只有 Apache 的 10 余个顶级项目支持常用的数据源,比如各种开源和商业关系数据库都是不支持输出 Apache Arrow 的。这样一来,这些数据源也不支持连接了。这显然限制了 Dremio 这款软件在传统企业中的使用。

当然,除了这个优化以外,Dremio 的这款产品还进行了另外一个优化。简单来说,这和传统数据仓库的做法差不多,Dremio 会预先做一些计算,然后把计算的结果存起来。这样一来,当真正需要做查询的时候,可以在已经计算好的数据上查询,从而减少计算量,缩短查询时间。

这种效率的提升有可能是非常可观的,尤其是当预计算数据的结果可以存放在内存里的话,查询速度的提升是非常可观的。但是这种做法有一个大问题:我们到底如何才能做到空间与效率的平衡,需要用多大的空间来换取多少效率的提升呢?

这个问题,传统数据库厂商和数据仓库厂商已经研究了几十年,其实并没有一个通用解法。很多时候只能根据业务需求和查询的实际情况定制。但是对于 Dremio 这个初创公司来说,这个方面的积累到底怎么样,我不好判断。

数据分析市场现在风起云涌,类似的产品也不少。Dremio 从 Apache Drill 借鉴了连接的思想,又用 Apache Arrow 来提高系统效率的做法,的确是一个不错的折中方法。

但是在我看来,Dremio 的这个折中方式最大的问题是:如何支持一些极为常见的数据源。比如 Oracle,SQL Server。这些数据源并不支持 Arrow 格式的输出,可能 Dremio 在开源产品和 Hadoop 生态圈会有一片空间,但是对传统企业来说,恐怕不容易成为一个通用的数据平台。所以在我看来,Dremio 能不能生存下来,也是在模棱两可之间了。

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

通过留言可与作者互动