最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
打印 上一主题 下一主题
开启左侧

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

[复制链接]
跳转到指定楼层
楼主
发表于 2019-3-31 18:58:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
以前也玩过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,但总体上讲,导入数据还是需要有很多技巧的,上手慢。
   
    以上是我为了挑选合适的大数据库,所做的尝试和对比,上面只写了最关键的对比,细节没有再描述。其中付出了半年多的日日夜夜,即使如此,也仍然有不对之处,欢迎拍砖。

楼主热帖
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 赞 踩

168大数据 - 论坛版权1.本主题所有言论和图片纯属网友个人见解,与本站立场无关
2.本站所有主题由网友自行投稿发布。若为首发或独家,该帖子作者与168大数据享有帖子相关版权。
3.其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和168大数据的同意,并添加本文出处。
4.本站所收集的部分公开资料来源于网络,转载目的在于传递价值及用于交流学习,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
5.任何通过此网页连接而得到的资讯、产品及服务,本站概不负责,亦不负任何法律责任。
6.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源,若标注有误或遗漏而侵犯到任何版权问题,请尽快告知,本站将及时删除。
7.168大数据管理员和版主有权不事先通知发贴者而删除本文。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-4-29 03:58

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表