spark、hive、impala、hbase、gbase在结构化数据方面查询原理对比(含parquet/orc)

    这几天恰巧来了4台服务器,还没有正式使用,所以赶紧加班安装调试了hadoop + spark 。

    以前也玩过spark,但这次玩,是因为spark从1.4版本后使spark sql独立出来,想必一定不赖;另外,还支持DataFrame,底层存储支持parquet,甚至orc file。

    一、parquet 和 orc 对比

    我专门查了查parquet 和 orc,网上很多,我只说关键的。

    1、parquet 和 orc 都是用于存储数据的底层格式,都是列式的。不难想象,对于单查某一个或2个列,因为不涉及其他列,所以速度会很快。

    2、都能实现列压缩。如连续3个一样的数据放在一起,他们可以只写一遍,标示上为3次即可。压缩不压缩,我倒不怕空间浪费,关键是因为减小了体积,所以查询速度势必加快,所以这是好的。

    3、在一定体积内(无论多少行),都是放在一起的,所以他们列式的前提,是先多行在一起,然后在多行内的列独立。

    4、不同:orc 格式,在文件头有一个粗粒度索引,如此列的最大值和最小值。如果您查询的值不在此列包,则跳过不查,所以orc格式在查询结果不大的情况下,会速度快很多。而parquet则没有此特征。

    5、parquet 不支持Update,不支持ACID。

    二、spark 和 hive 

    先说好的:如果查询结果非常大,且需要将这些大的查询结果来回倒腾对比,建议使用spark。 spark的 DataFrame也很好使,且支持lambda表达式,是完全的程序员式的数据检索方式,很符合我的风格要求(.NET早就有了)。还有,可以将DataFrame结果存储为parquet,甚至orc。

    但结果很让我失望,我想将结果存储为orc,但他要求先配置hive,要知道,安装一个spark就很得先安装hadoop,都是难安装的主,再安装hive,所以他们之间会很复杂,出错后,很难找原因。

    而且关键的是,hive必然用mapreduce,所以启动一次就会很慢,对于焦躁的用户来说,速度太慢了。

    Spark即使用parquet格式,也必须每次在用的时候重新抽取,而且他不管你数据在那台机器上,都统统检索一遍,所以,我想用不必每个数据包都检索的orc格式,但却非常困难。

    所以,对于结构化数据的快速查询,因为没有索引,所以是不理想的(如果需要全部检索,大批量和大批量迭代比对,准备花个几个小时的情况,是适用的)。特别是用作数据库来讲,单用spark来实现,结果是困难的。数据进库也比较麻烦,我倒是写了一个接口,但毕竟没有kettle等etl工具的支持啊。

    三、impala 和 hive 

    impala是为了实现实时查询的,没有像hive一样仅仅把SQL翻译成MapReduce,而是直接读取HDFS,所以速度是快的。甚至新版本可以parquet存储。但:

    1、impala不能实现删除数据。

    2、目前不支持orc 格式。平时都是行式查询,即使使用了parquet,也不能跳过不必要的行组。

    3、impala可秒级检索,但却不能将实时数据立即加载到数据集中,所以impala是准实时。

    毕竟 impala要用到 hive的表结构,所以,有人说,他们之间要是能底层一套数据,impala用做即时查询,hive(必须map + reduce,所以慢)用作批量离线分析,就好了。但他们之间却是:impala用parquet格式,hive用orc格式,所以是不能一个底层的。对我来讲最遗憾的是:如果他们的底层颠倒一下就好了:impala用orc,hive用parquet,那我就选择 impala 了。

    标准的Hive使用场景为:定期进行数据的批量加载,再进行批处理计算。这个数据加载周期短则一个小时,长的甚至每天才加载一次数据。更糟糕的是,分析计算本身也往往需要数分钟甚至数小时的时间。因此这种计算模式往往无法满足结果的时效性。

    四、hbase

    hbase是列式数据库,为了学习他,我还在当当上买了本书。hbase也是用于实时查询的,所以比一般的hadoop要快,当然了,他也是建立在hadoop上的。

    hbase是很多行组成一个region,每个region有一个rowkey(类似于rowid),这个rowkey可以自己定义,根据这个rowkey,可以实现最快速的定位。但:

    1、hbase还是在多行集合的内部,实现的列单独存储。所以要定位某个非rowkey,还是要启动所有的服务器来查找每个region内的某列的。

    2、没有列压缩,起码我没有找到这方面的资料。前面说了,列压缩可以实现减小体积,减小硬盘I/O,加快检索速度。

    五、gbase 8a MPP

    gbase 8a MPP,是国产的一个列式并行数据库。优点:

    1、纯列式,每个列在操作系统内,都是单独的文件,你可以看到的,所以检索是势必减少I/O。

    2、列式压缩。有很多种压缩方式,如NULL不实际存,只在包头内标注;多行连续一样时,可以只存一次,减小了体积。

    3、粗粒度索引。包头上注明了此列包,最大值和最小值是什么,如果你查的东西不在此列,则直接跳过此包。

    4、安装、维护极简单。由于不建立在hadoop上,所以虽然是安装在linux上,但即使不会linux的人,看了说明书,5分钟就可上手安装,连ssh都不用配,再5分钟就可安装完毕。因为有粗粒度索引,所以连数据优化工程师都可以免了,比oracle简单太多了。懒人的福音,当然如果懂得原理更多,速度也会有更好的优化。

    5、可以建立全文索引!

    缺点:

    1、只支持哈希索引。

    2、sql语句虽然支持的非常丰富,但在复杂查询时,后台的查询语句顺序,不是你想象的那样,甚至出现排序速度比不排序速度快的情况。

    3、导入数据较困难。虽然可可以支持kettle,但总体上讲,导入数据还是需要有很多技巧的,上手慢。

    

    以上是我为了挑选合适的大数据库,所做的尝试和对比,上面只写了最关键的对比,细节没有再描述。其中付出了半年多的日日夜夜,即使如此,也仍然有不对之处,欢迎拍砖。

                                                             党玉龙

                                                      2015年12月12日凌晨

没有更多推荐了,返回首页