hive用模糊查询是否影响效率

举报
孙中明 发表于 2022/01/22 22:21:45 2022/01/22
【摘要】 hive具有sql数据库的外表,但应用场景完全不同,hive只适合用来做批量数据统计分析 查询语言。由于 SQL 被广泛的应用在数据仓库中,因此,专门针对 Hive 的特性设计了类 SQL 的查询语言 ...

hive具有sql数据库的外表,但应用场景完全不同,hive只适合用来做批量数据统计分析

查询语言。由于 SQL 被广泛的应用在数据仓库中,因此,专门针对 Hive 的特性设计了类 SQL 的查询语言 HQL。熟悉 SQL 开发的开发者可以很方便的使用 Hive 进行开发。
数据存储位置。Hive 是建立在 Hadoop 之上的,所有 Hive 的数据都是存储在 HDFS 中的。而数据库则可以将数据保存在块设备或者本地文件系统中。

索引

之前已经说过,Hive 在加载数据的过程中不会对数据进行任何处理,甚至不会对数据进行扫描,因此也没有对数据中的某些 Key 建立索引。Hive 要访问数据中满足条件的特定值时,需要暴力扫描整个数据,因此访问延迟较高。由于 MapReduce 的引入, Hive 可以并行访问数据,因此即使没有索引,对于大数据量的访问,Hive 仍然可以体现出优势。数据库中,通常会针对一个或者几个列建立索引,因此对于少量的特定条件的数据的访问,数据库可以有很高的效率,较低的延迟。由于数据的访问延迟较高,决定了 Hive 不适合在线数据查询。

举个例子,查询某个月份的用户登录次数。(表结构已脱敏)


select
  count(distinct f.user_id),
  substr(f.day_id,1,7)
from
  login_fact as f
where
  substr(f.day_id,1,7) = '2021-06'
group by
  substr(f.day_id,1,7)
   
-- 21/07/08 10:39:06 INFO SQLInterpreter: executed finished, 80655 ms costed.
-- 80655 毫秒=1.34425 分(分钟)


  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
select
  count(distinct f.user_id),
  substr(f.day_id,1,7)
from
  login_fact as f
where
  f.day_id BETWEEN '2021-06-01'
  AND '2021-06-30'
group by
   substr(f.day_id,1,7)
   
  -- 21/07/08 10:43:28 INFO SQLInterpreter: executed finished, 69647 ms costed.
  -- 69647 毫秒=1.1607833 分

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
select
  count(distinct f.user_id),
  substr(f.day_id,1,7)
from
  login_fact as f
where
 f.day_id like '2021-06%'
group by
   substr(f.day_id,1,7)
  -- 21/07/08 10:46:10 INFO SQLInterpreter: executed finished, 70170 ms costed.
  -- 70170 毫秒=1.1695 分

  
 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

对于关系型数据库来说,Like是否使用索引

1、like %keyword 索引失效,使用全表扫描。但可以通过翻转函数+like前模糊查询+建立翻转函数索引=走翻转函数索引,不走全表扫描。

2、like keyword% 索引有效。

3、like %keyword% 索引失效,也无法使用反向索引。

但是从hive 来说,hive 要访问数据中满足条件的特定值时,需要暴力扫描整个数据;也就是整个数据来说也就是。所以你看到上面的数据其实相差并不大。但是对字段如果是分区表的字段的话例如date,我觉得系统会自动去维护这个字段。


执行

Hive 中大多数查询的执行是通过 Hadoop 提供的 MapReduce 来实现的,而数据库通常有自己的执行引擎。

执行延迟

之前提到,Hive 在查询数据的时候,由于没有索引,需要扫描整个表,因此延迟较高。另外一个导致 Hive 执行延迟高的因素是 MapReduce 框架。由于 MapReduce 本身具有较高的延迟,因此在利用 MapReduce 执行 Hive 查询时,也会有较高的延迟。相对的,数据库的执行延迟较低。当然,这个低是有条件的,即数据规模较小,当数据规模大到超过数据库的处理能力的时候,Hive 的并行计算显然能体现出优势。

可扩展性

由于 Hive 是建立在 Hadoop 之上的,因此 Hive 的可扩展性是和 Hadoop 的可扩展性是一致的(世界上最大的 Hadoop 集群在 Yahoo!,2009年的规模在 4000 台节点左右)。而数据库由于 ACID 语义的严格限制,扩展行非常有限。目前最先进的并行数据库 Oracle 在理论上的扩展能力也只有 100 台左右。
数据规模。由于 Hive 建立在集群上并可以利用 MapReduce 进行并行计算,因此可以支持很大规模的数据;对应的,数据库可以支持的数据规模较小

文章来源: hiszm.blog.csdn.net,作者:孙中明,版权归原作者所有,如需转载,请联系作者。

原文链接:hiszm.blog.csdn.net/article/details/118759324

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。