今天这篇文章，我们来讲讲一个非常年轻的公司 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 能不能生存下来，也是在模棱两可之间了。