gitbook/技术与商业案例解读/docs/10054.md

63 lines
7.1 KiB
Markdown
Raw Normal View History

2022-09-03 22:05:03 +08:00
# 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的这个折中方式最大的问题是如何支持一些极为常见的数据源。比如OracleSQL Server。这些数据源并不支持Arrow格式的输出可能Dremio在开源产品和Hadoop生态圈会有一片空间但是对传统企业来说恐怕不容易成为一个通用的数据平台。所以在我看来Dremio能不能生存下来也是在模棱两可之间了。