63 lines
7.1 KiB
Markdown
63 lines
7.1 KiB
Markdown
|
# 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顶级项目。它的主要目标有两个:
|
|||
|
|
|||
|
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能不能生存下来,也是在模棱两可之间了。
|
|||
|
|