093 Dremio_在Drill和Arrow上的大数据公司

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

今天这篇文章，我们来讲讲一个非常年轻的公司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顶级项目。它的主要目标有两个:

  • 定义一个通用而高效的内存数据格式，方便数据查询引擎进行查询。
  • 定义了从上述格式中载入数据的方式。任何支持这个格式的系统，都可以方便、高效地输入或者输出这种格式。

这两者放在一起，就使得从不同数据源读取和写入数据的效率得到大大的提高。这种提高，对于各个产品都是有意义的。然而更加有意义的并非各种产品之间，而是类似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能不能生存下来，也是在模棱两可之间了。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e6%8a%80%e6%9c%af%e4%b8%8e%e5%95%86%e4%b8%9a%e6%a1%88%e4%be%8b%e8%a7%a3%e8%af%bb/093%20Dremio_%e5%9c%a8Drill%e5%92%8cArrow%e4%b8%8a%e7%9a%84%e5%a4%a7%e6%95%b0%e6%8d%ae%e5%85%ac%e5%8f%b8.md